事后诸葛亮分析报告
| 作业所属班级 | https://edu.cnblogs.com/campus/gdgy/SoftwareEngineering2024 |
|---|---|
| 作业要求 | https://edu.cnblogs.com/campus/gdgy/SoftwareEngineering2024/homework/13143 |
| 作业目标 | 召开事后诸葛亮会议，发布一篇事后分析报告 |
一、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件 - 我们达到目标了么？
只达到部分，仍有需要改进的地方。 - 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
没有。 - 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
应该一致，基本的游戏功能已完成，或许近了，但仍感觉任重道远。 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
要合理确定目标，量力而行。
二、计划
- 是否有充足的时间来做计划?
否。 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
协商统一。 - 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
否，技术层面的缺陷加上时间安排不恰当。 - 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。 - 是否每一项任务都有清楚定义和衡量的交付件?
否。 - 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，部分功能碍于能力有限实现不了。技术难题，高估自身能力。 - 在计划中有没有留下缓冲区，缓冲区有作用么?
没有。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划书对一个项目的重要性，如何合理地规划时间，如何进行清晰的分工，如何推动团队在规定的时间内完成工作。再来一遍，会合理安排时间完成计划。
三、资源
- 我们有足够的资源来完成各项任务么?
有。 - 各项任务所需的时间和其他资源是如何估计的，精度如何?
通过任务分解，过去项目经验，专业知识，风险考虑，团队成员的工作负荷等进行估计。精度不高。 - 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
人力资源不够。是。 - 你有没有感到你做的事情可以让别人来做（更有效率）
有。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要有明确的需求分析，进行相关文档记录。
四、变更管理
- 每个相关的员工都及时知道了变更的消息?
是。 - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
线下讨论。 - 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
各个功能模块都基本完成，测试后没有bug。 - 对于可能的变更是否能制定应急计划?
否。 - 员工是否能够有效地处理意料之外的工作请求？
否。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在团队合作中，每个人之间进行及时的沟通是必要的。
五、测试/发布
- 团队是否有一个测试计划？为什么没有？
没有。时间安排不合理。 - 是否进行了正式的验收测试？
否。 - 在发布的过程中发现了哪些意外问题？
略。 - 我们学到了什么? 如果重来一遍, 我们会做什么改进?
软件需要测试才能保证质量。
六、团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队就两个人，角色的确定不是很明确；应该不是。 - 团队成员之间有互相帮助么？
有。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级别。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽。
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用 GitHub来管理代码的版本。定期进行代码复审、持续改进代码规范。 - 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
通过重构代码、采用合适的设计模式、编写全面的单元测试、定期进行代码审查、对程序进行性能优 化等方式进行提高。代码覆盖率、缺陷率、代码复杂度等方面。 - 其它软件工具的应用，应该如何提高？
通过实践中的使用加深团队对工具的理解和熟练度。 - 项目管理有哪些具体的提高？
明确项目目标和范围；定期进行项目回顾。 - 项目文档的质量如何提高？
使用简洁清晰的语言表达全面的信息；在编写完成后，进行审查和反馈。 - 对于人的领导和管理，有什么具体可以改进的地方？
明确团队共同目标和期望；建立开放沟通；设定清晰的角色和责任。
