事后诸葛亮分析报告

一、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   我们的软件
2. 我们达到目标了么？
   只达到部分，仍有需要改进的地方。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
   没有。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   应该一致，基本的游戏功能已完成，或许近了，但仍感觉任重道远。
   5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   要合理确定目标，量力而行。

二、计划

1. 是否有充足的时间来做计划?
   否。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   协商统一。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   否，技术层面的缺陷加上时间安排不恰当。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
   否。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   否，部分功能碍于能力有限实现不了。技术难题，高估自身能力。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   没有。
   8.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   计划书对一个项目的重要性，如何合理地规划时间，如何进行清晰的分工，如何推动团队在规定的时间内完成工作。再来一遍，会合理安排时间完成计划。

三、资源

1. 我们有足够的资源来完成各项任务么?
   有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   通过任务分解，过去项目经验，专业知识，风险考虑，团队成员的工作负荷等进行估计。精度不高。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   人力资源不够。是。
4. 你有没有感到你做的事情可以让别人来做（更有效率）
   有。
   5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   要有明确的需求分析，进行相关文档记录。

四、变更管理

1. 每个相关的员工都及时知道了变更的消息?
   是。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   线下讨论。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
   各个功能模块都基本完成，测试后没有bug。
4. 对于可能的变更是否能制定应急计划?
   否。
5. 员工是否能够有效地处理意料之外的工作请求？
   否。
   6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   在团队合作中，每个人之间进行及时的沟通是必要的。

五、测试/发布

1. 团队是否有一个测试计划？为什么没有？
   没有。时间安排不合理。
2. 是否进行了正式的验收测试？
   否。
   3.在发布的过程中发现了哪些意外问题？
   略。
   4.我们学到了什么? 如果重来一遍, 我们会做什么改进?
   软件需要测试才能保证质量。

六、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？
   团队就两个人，角色的确定不是很明确；应该不是。
2. 团队成员之间有互相帮助么？
   有。

总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级别。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽。

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
   使用 GitHub来管理代码的版本。定期进行代码复审、持续改进代码规范。
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
   通过重构代码、采用合适的设计模式、编写全面的单元测试、定期进行代码审查、对程序进行性能优 化等方式进行提高。代码覆盖率、缺陷率、代码复杂度等方面。
3. 其它软件工具的应用，应该如何提高？
   通过实践中的使用加深团队对工具的理解和熟练度。
4. 项目管理有哪些具体的提高？
   明确项目目标和范围；定期进行项目回顾。
5. 项目文档的质量如何提高？
   使用简洁清晰的语言表达全面的信息；在编写完成后，进行审查和反馈。
6. 对于人的领导和管理，有什么具体可以改进的地方？
   明确团队共同目标和期望；建立开放沟通；设定清晰的角色和责任。