团队作业6——事后诸葛亮分析报告

1.设想与目标

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

• 我们的软件主要服务于学生党与上班族，在他们遇到饭点吃什么的问题时，能够使用我们的APP，帮助他们作出决定。我们的对典型用户和典型场景描述的十分清楚，具体描述可参考需求规格说明书

1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?）

• 总体来说目标达成。

• 功能有一两个未实现，能够按照原计划时间交付。

• 用户数量暂时未达到目标。

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

• 对我们而言，和上一个阶段相比，团队软件工程的质量自然是有所提高。
• 面对一个问题，不再是一个人冥思苦想，而是可以各抒己见。
• 完成一个功能的效率也加快了。

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

• 虽然上线了，但用户量还远远没到。部分功能还没完善好，系统比较简单。
• 系统功能比较少，和系统一些软件自然无法比较，但是我们一直在向目标靠近。

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

• 教训：
  • 时间安排还不够合理。
  • 团队分工不够细致。
  • 队员之间沟通不够顺畅。
• 改进：
  • 在完成团队项目工作安排时，应严格设计好交付时间。
  • 应分析了解每个成员的代码水平。

2.计划

2.1 是否有充足的时间来做计划？

• 时间比较充足。

2.2 团队在计划阶段是如何解决成员对于计划的不同意见的？

• 通过线下、线上讨论，针对不同意见进行权衡取舍。

2.3 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？

• 与最初的计划相比，完成度尚可。
• 部分功能未完成，因为队员第一次合作，彼此间不是特别熟悉，经验也不足，面对一些问题解决较慢，导致时间不是特别充足。

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

• 暂时没有发现，我认为我们所做的事情都是有意义且有价值的。

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

• 基本上是的。

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

• 整个过程基本能够按计划进行。
• 但是在冲刺阶段属于五一假期期间，一些成员回家了，导致进度有所拖慢，最后完成有点赶。

2.7 在计划中有没有留下缓冲区，缓冲区有作用么?

• 有预留。起到了一定作用，能够把一些细枝末节的任务完成。

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

• 学到了如何高效地完成团队合作。
• 我们会预想可能出现的一些问题，并计划好相应的补救措施。

3.资源

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

• 资源足够。

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

• 根据任务难易程度估计。
• 针对任务的难易程度，我们会安排好时间和相应的完成人员，但是精度不算高。

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

• 人力和软件/硬件资源足够。
• 对于不需要编程的资源，例如博客的编写，UI页面的设计，确实低估了难度，最后分配了一些资源，才能按时交付完成。

3.4 你有没有感到你做的事情可以让别人来做（更有效率）？

• 团队在计划任务分工时一定程度地考虑了队员技术栈、时间等相关因素，任务分工基本较为合理，队员大多未出现这种想法。

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

• 应该充分预估好每项任务的完成难度，并多与其他队员沟通交流，了解他们的时间安排，以便合理分配任务。

4.变更管理

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

• 是的。有需要变更的消息，我们会在微信群及时通知。

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

• 根据任务的完成进度，以及任务量，和功能的重要程度确定。

4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

① 具有健硕性：产品能经受各种奇怪的非法输入而不崩溃；
② 具有正确性：在输入正常的情况下系统能做出相应的反应，提供相应的功能而不出错，没有较大的bug；
③ 具有合理性：各页面间的跳转，接口的进入与连接，页面设计都有较好的逻辑性，连接顺畅不突兀，页面跳转符合预期。

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

• 是的。我们有设立缓冲区。预留部分时间用于应急。

4.5 员工是否能够有效地处理意料之外的工作请求？

• 基本可以。

5.计划/实现

5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

• 在第一次会议时候决定。
• 由队长在了解各个成员情况，以及沟通交流、协商之后决定。
• 基本合适。

5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 有的。我们会在集体会议中提出，并商量协商解决。

5.3 团队是否有测试工具来帮助测试？

• 没有。

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

• 在生成随机结果产生的Bug最多，因为它牵扯到其它功能的逻辑，较为复杂。
• 发布之后暂时没有发现重要的bug。

5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 使用阿里巴巴的代码规划，代码大都能按照规范进行。

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

• 学到了一个真正的项目的开发流程经过，了解团队合作的意义。
• 再来一遍，我们会吸取上述提出的一些经验教训，在项目开发过程中做得更好。

6.测试/发布

6.1 团队是否有一个测试计划？为什么没有？

• 有。针对不同的功能，我们有设计测试的计划，确保各个功能能正常使用。

6.2 是否进行了正式的验收测试？

• 是的。我们在发布前，测试了系统中所有功能，能正常使用才发布。

6.3 团队是否有测试工具来帮助测试？

• 没有。
• 软件本身功能不多，团队可以自己完成测试。

6.4 在发布的过程中发现了哪些意外问题？

• 在选择发布方式时，我们发现原先的方式无法正常安装，最后找到了新的安装方式。

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

• 测试对于完成并发布合格的产品来说十分重要，它能发现很多在单独编写一个接口代码时未出现的bug,可以避免糟糕的用户体验以及用户隐私泄露等严重问题。如果之后有较为复杂的程序，我们可以了解一些自动化测试工具来提高测试效率。

7.总结

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

• 二级。

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

• 磨合阶段。这是我们团队合作完成的第一个项目，总体来说，还有很多不足需要完善。

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

• 通过系统的事后总结和整理，我们能够更进一步了解项目结果、团队技术水平的不足以及团队合作暴露出的一些不够完善的地方，也能够在一定的成果展示里提高我们对团队合作的自信心。

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

• 这次开发的过程中，总感觉时间不够，东西很多，开发团队的技术水平，需要各个成员自己认真去下功夫精进自己的技术水平，才能推动项目的完成速度和完成质量。

8.团队贡献分计算

姓名	学号	分工	贡献分
黄翊森	3121005168	开发	90
王宗奎	3121005183	博客编写、测试	87
陈浩杰	非本校学生	开发	85
欧景林	3121005003	开发	85
吴雨晨	3121005012	UI设计、开发	85