zoukankan      html  css  js  c++  java
  • 团队作业第六次—事后诸葛亮

    格式描述


    项目 内容
    这个作业属于哪个课程 2019秋福大软件工程实践Z班 (福州大学)
    这个作业要求在哪里 团队作业第六次—事后诸葛亮
    团队名称 灯塔
    这个作业的目标 组织事后诸葛亮会议进行总结
    作业正文 团队作业第六次—事后诸葛亮
    其他参考文献 项目管理之事后诸葛亮会议

    设想和目标


    1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?

    • 我们的软件要解决高三毕业生以及在校大学生不知道如何选择方向,或者是知道了方向但不知道如何学起的问题。
    • 定义得挺清楚的。
    • 对转专业这样的典型用户和典型场景有清晰的描述,但没有去深入分析更多的典型用户和典型场景。

    2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)

    • 没有达到目标,原计划的功能做到了5个,还有一些功能尚未实现
    • 已按照原计划交付时间交付
    • 未达到原计划的用户数量

    3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?

    • 和上一个阶段相比,团队软件工程的质量提高了,特别是在完成一定任务量的工作时每个人的开发效率都提高了,团队交流得更多,考虑得更加周到,配合也更加紧密。以提交任务的时间和效果为标准来衡量。

    4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    • 用户量, 用户对重要功能的接受程度未达到事先的预想,但我们离目标一步步更近了

    有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 加强团队成员间的交流
    • 加强对用户需求的调查和分析
    • 对软件的框架、功能进行更清晰、更详细的定义

    计划


    1. 是否有充足的时间来做计划?

    • 没有,时间挺紧张的

    2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?

    • 大家讨论觉得哪个意见更合理就采取哪个,基本没出现争执不下的情况。可能也是由于大家在开发前对软件的框架没有很深入的思考,所以没有很多的不同意见。偶尔出现各持己见的情况,就少数服从多数。

    3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?

    • 没有都做完,因为开发的时间不够充足,大家的技术水平也有待提升。

    4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

    • 有。出现这种情况可能是由于没沟通好、没计划好、知识不足等原因。不过好好总结反思这些事后看来没必要或没多大价值的事,可以帮助我们积累经验,收获成长。

    5. 是否每一项任务都有清楚定义和衡量的交付件?

    • 基本没有

    6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

    • 没有整个过程都按计划进行,出现了技术遇到瓶颈、在项目验收前误删库函数导致虚拟机不能运行等意外。基本风险都估计到了,但没想好怎么处理。

    7. 在计划中有没有留下缓冲区,缓冲区有作用么?

    • 有留下缓冲区,不过很少。事后发现缓冲区有很大的作用,可以帮助大家调整进度,进行总结,也可以预防意料之外的情况。

    8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

    • 计划的时间要细化要明确,留下一定的缓冲区
    • 计划的内容要细化要明确,每一项任务都要有清楚定义和衡量的交付件

    我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 计划要充分,计划的时间和内容要细化要明确。每段时间要好好的进行总结。如果再来一遍,我们会制定充分的计划,并严格执行,也会留下一定的缓冲区来灵活调整。

    资源


    1. 我们有足够的资源来完成各项任务么?

    • 没有

    2. 各项任务所需的时间和其他资源是如何估计的,精度如何?

    • 开始精度很粗略,后来随着项目任务的加重,大家只顾得上干活,没时间考虑精度问题。

    3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    • 测试的时间、硬件资源足够,但是人力和软件资源不足够。团队里后端开发人员不足,导致组长一人承担了较多的后端开发任务。
    • 对于那些不需要编程的资源 (美工设计/文案)没有低估难度,因为有之前的开发经验,知道这些还是有一定难度的。

    4. 你有没有感到你做的事情可以让别人来做(更有效率)?

    • 比如引导页逻辑的编写,由组长(后端相比之下较熟练)来写肯定更快,但是组长已经有一定的任务,而且不能因为他更熟练就都由他来写,每个人都有从熟练到不熟练的成长过程。当然在分配任务的时候,肯定会根据每个队员的能力和各自擅长的方面来分配。

    有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 合理利用资源,物尽其用。分配任务时要明确且尽量均等,注意提升团队的整体效率。
    • 如果再来一遍,我们会多分配一些后端开发的人员

    变更管理


    1. 每个相关的员工都及时知道了变更的消息?

    • 还算及时,但团队成员的沟通还有很大的提升空间。

    2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    • 通过开会讨论共同商议决定。

    3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

    • 在需求报告里的功能、界面、验收标准等模块中有比较清晰的定义,但仍不够完善。

    4. 对于可能的变更是否能制定应急计划?

    • 基本没有,紧急情况全靠加班。

    5. 员工是否能够有效地处理意料之外的工作请求?

    • 还没碰到意料之外的工作请求。

    我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 要加强团队成员间的沟通。
    • 要提前做好应对变更的准备。

    设计/实现


    1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

    • 设计工作在需求分析后,项目开发前,由做原型的同学来完成的。
    • 是合适的时间,合适的人。

    2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

    • 有碰到模棱两可的情况,团队共同商讨解决。

    3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

    • 团队运用了单元测试、UML等工具帮助设计和实现。
    • 有效。单元测试有效地帮助测试了每个类的debug,uml帮助我们理清用户、需求、系统功能单元之间的关系。
    • 主要是类图变化比较大。
    • 需要更新uml文档。

    4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    • 计划社区由于牵涉的面较多,bug也最多。
    • 未发布。
    • 对用户需求考虑的不够周到、测试的时候想的不够周全。

    5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

    • 代码复审只走走形式,但编写过程中严格执行了代码规范。

    我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 软件开发从设计、实现到测试,每一步都要非常的严谨,要考虑的十分周全。

    测试/发布


    1. 团队是否有一个测试计划?为什么没有?

    • 团队有测试计划。

    2. 是否进行了正式的验收测试?

    • 没有。

    3. 团队是否有测试工具来帮助测试?

    • 没有,就是利用编写工具进行测试。

    4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

    • 每次做出一个新的功能,就会发给测试人员进行测试,看看有没有遗漏不完善的地方。这些测试工作有起到作用,帮助我们改进了一些之前没有注意到的细节。

    5. 在发布的过程中发现了哪些意外问题?

    • 还未发布

    我们学到了什么? 如果重来一遍, 我们会做什么改进?

    • 在每个步骤都要注意细节,测试时固然会找出一些问题,但还有更多是我们应该前期设计实现的时候应该考虑到的。

    团队的角色,管理,合作


    1. 团队的每个角色是如何确定的,是不是人尽其才?

    • 团队的角色是根据团队成员各自选择喜欢或熟悉的方向确定的。
    • 基本上做到人尽其才。

    2. 团队成员之间有互相帮助么?

    • 有。

    3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

    • 还没出现这方面的问题,大家都互相帮忙,合作得挺愉快的。
    • 每个成员明确公开地表示对成员帮助的感谢:
      何云鹏:我感谢林德辉对我的帮助,正式分工开始冲刺时,我依旧对自己的学习和工作方向依旧很迷茫,感谢他帮我了解了方向。
      李中瑾:我感谢小组的每个成员,犹其是队长的帮助。因为小组的热烈讨论及有计划有组织的行动使我受到青春热血激情的感染,同时提供了一个友好的团队合作的机会。队长持续不断地推动着项目进行的同时,也针对我遇到的困惑给予解释。
      余泓:我要感谢团队的每一位成员,大家都很厉害,特别要感谢组长和彭文泽同学,组长每次都很仔细地帮我们分配任务,并且自己总是承担很困难的任务,也常常会帮助每个组员,十分辛苦;彭文泽同学在ui设计方面给了我很大的帮助。
      张成德:我感谢林德辉对我的帮助,他让我学会了AS的基本操作,以及解决了一些相关的问题。
      王茜葶:我感谢组长林德辉对我的帮助,因为帮助我许多AS的使用方法,帮助我进行测试工作。
      林德辉:我感谢团队的每一个成员,是大家的积极配合、共同努力,完成了最终的成果。
      彭文泽:我感谢组长和余泓同学的帮助,组长每天要完成的任务都会认真落实,余泓同学在ui设计方面给了我很大的帮助。
      叶心言:我感谢小组的每一个同学,尤其是组长的帮助。在AS上有个问题卡了很久,后来请教了组长,帮我绕过了很多坑。

    总结:


    你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

    • 我们认为目前团队还处于CMMI一级,执行级的档次。因为大部分同学没有太多开发经验,很多开发上的问题还是第一次接触,还是只能奔着实现项目需求出发。

    你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

    • 我觉得团队目前处于磨合阶段。

    你觉得团队在这个里程碑相比前一个里程碑有什么改进?

    • 相较于之前,前期的需求分析更周到,设计更详细,团队成员的配合更紧密,技术方面也进步了不少。

    你觉得目前最需要改进的一个方面是什么?

    • 我觉得目前最需要改进的方面是技术方面的提升和团队成员间的沟通。

    各组员对于最终项目成果的贡献度


    组员 学号 工作量比例
    林德辉 031702142 17%
    叶心言 031702108 17%
    彭文泽 031702140 11%
    张成德 031702130 11%
    王茜葶 031702101 11%
    余泓 031702409 11%
    何云鹏 031702327 11%
    李中瑾 031402112 11%

    照片


  • 相关阅读:
    SCM基础之SCM配置管理计划重要性
    SCM基础之合理设计配置库
    SCM英文术语
    中国歼20隐形战机首飞成功
    SCM基础之过程描述
    SCM基础之基线审核
    SCM基础之组织结构设计
    SCM基础之如何做到配置管理
    配置管理介绍
    软件配置管理的任务
  • 原文地址:https://www.cnblogs.com/deng-ta/p/12044164.html
Copyright © 2011-2022 走看看