事后诸葛亮（团队）

班级：软件工程1916|W
作业：事后诸葛亮（团队）
团队名称：Echo
作业目标：完成Alpha冲刺的事后诸葛亮

目录

• 设想和目标
• 计划
• 资源
• 变更管理
• 设计/实现
• 测试/发布
• 团队的角色，管理，合作
• 总结
• 照片
• 组员交接工作及方案

设想和目标

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

• 我们的软件主要针对福州大学的物业管理，用于解决目前福大物业消息通知不及时、水电缴费麻烦的痛点。

• 对于定义，我们觉得很清楚。

• 对于用户和场景，我们也做了较详细的描述。

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

基本达到，详见总结随笔

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

上一阶段主要都在做设计、需求这块，如果硬要说提高，那就是有产品成果了。

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

还没推广，暂时没考虑用户量

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

在实现过程中没有出现大问题，但如果历史重来一遍，我们会将文档等写的更加详细一些。

计划

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

我们在alpha冲刺前就完成了计划，所以是有充足的时间来做计划的

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

我们如果出现不同意见，主要采用了集体讨论的方式，在每天的会议中提出并讨论审议。

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

没有全部做完，物业管理端的缴费信息导入、人员导入都还没做，主要是因为时间以及对文件读取不熟。

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

没有

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

是的，基本都有

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

整体上按照计划有序推进，没有什么大的意外。主要遇到的问题是在前后端对接时发现了一些bug。在一开始就有估计到会出这些bug了。

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

有的，我们提前预留出了时间给对接工作

8、 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

因为我们的得力干将kwm被迫换组，后续的管理端计划可能会根据具体情况稍作修改。

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

• 学会了如何进行团队协作，以及如何更加合理的安排时间。
• 如果再重来一遍，我们应该还是会按照原来的计划走。

资源

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

有的，前端后端以及测试用的工具都比较成熟，有大量的学习资源。

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

首先确定我们的任务，再根据任务难度和任务类型分配以及每个人想要的发展方向，给每个人分配任务，最后确定每个任务的完成时间。

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

• 人力、软件资源充足，硬件上，由于是使用腾讯云的学生机，所以配置较低
• 美工等资源，由于在前期原型设计的时候已经较为完善，所以也没有什么问题

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

我们团队成员都是按照自己能力来分配任务，所以似乎没有出现这样的情况。

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

• 团队之间要多多交流，尤其是遇到问题的时候，可能其他人那就有好的解法。
• 如果再重来一次，我们还是会继续好好利用这些资源的

变更管理

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

因为每天都会开会，有什么问题也会在群里讨论，所以消息传递效率还是有保证的。

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

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

3、 项目的出口条件（Exit Criteria）是否得到清晰的定义?

在需求报告里的性能、界面需求等模块中有比较清晰的定义。

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

基本没有。

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

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

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

• 目前除了在alpha阶段后kwm被迫换组，没有遇到什么变更情况
• 如果在重来一遍，可能就是会提前做好这种换人的准备吧

设计/实现

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

设计工作在一开始的选题及原型设计的时候就完成了，由团队所有人员共同参与完成，是合适的人和合适的时间。

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

没有碰到模棱两可的情况，一般一起讨论后就会有结果。

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

• 团队运用了单元测试、UML等工具帮助实现。
• 有效。单元测试有效地帮助测试了每个类的debug，uml帮助我们理清用户、需求、系统功能单元之间的关系。
• uml文档暂时还没有区别。
• 可能需要完善下uml文档。

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

• 在报修投诉模块的bug最多，主要是一些边界条件没考虑清楚
• 发布之后，发现有的报错信息未处理，直接提示给用户，不够友好。因为时间比较赶，没有注意到这些方方面面

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

• 代码复审由队员随机抽查github上的代码的格式、风格、命名是否符合规范。
• 除了管理员后端外，严格执行了代码规范。

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

• 代码规范很重要
• 如果重来一遍，我们会强制给每个人的idea上装上阿里巴巴的插件

测试/发布

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

有。

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

还没有到验收阶段

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

有，使用了Junit和Robot Framework等工具进行测试

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

还未进行软件的效能测试。

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

没有遇到问题

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

• 我们学到了测试的重要性。
• 如果历史重来一遍，我们会花更多一些的时间在学习自动化测试上。

团队的角色，管理，合作

1、 团队的每个角色是如何确定的，是不是人尽其才？

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

2、 团队成员之间有互相帮助么？

有。

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

还未出现过这样的问题。

4、 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 黄少勇
  感谢kwm在我完成任务过程中给予的帮助，即使被迫离开团队，也要继续指导我完成团队布置任务

• 黄种鑫
  感谢kwm在前端给我的帮助，虽然小程序开发和web开发有一定的差别，但是框架的一些思想还是相同的，kwm对于我对框架的理解有了进一步加深

• 孔伟民
  感谢kwm对我的帮助（你问kwm是谁？我不懂别问我我不知道），他在我玩手机的时候叫我起来干活，在我遇到问题的时候帮我百度...即使离开团队，也身在曹营心在汉。

• 李东权
  感谢kwm对我的帮助，即使离开团队，也能超额完美的完成团队安排的前端任务，并且能正常与我的后端相对接，合作愉快

• 林弘杰
  感谢kwm对我的帮助，在进行接口对接时及时发现了问题，对我进行反馈，让我发现了我测试脚本的不足

总结

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

我觉得团队目前的状态属于成熟度级别2 － 已管理，正在迈向级别3

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

我觉得我们到了磨合期，正在迈向规范期。

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

我觉得目前最需要改进的方面是前端和后端之间报错信息的统一。

照片

组员交接工作及方案

1. 熟悉项目：查看alpha冲刺前的需求文档、设计文档等
2. 熟悉开发内容：查看API相关文档、前端代码相关说明等
3. 开始接手前端开发工作