项目回顾总结

项目回顾

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

答：我们的软件是俄罗斯方块游戏，给玩俄罗斯方块的玩家做的，定义的很清楚

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

答：有

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

答：通过例会讨论，商讨出令大多数人满意的方案

用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？

答：一致，更近了。应该从多角度考虑问题，从多方面共同着手，不要走一步看一步

如果历史重来一遍，我们会做什么改进？

答：更细致和更有针对性的分配任务

2.计划
你原计划的工作是否最后都做完了?

答：已经完成了

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

答：没有，因为我的任务比较简单，并没有做什么没必要的事

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

答：是，任务都交代的很清楚，都经历过细致的讨论

是否项目的整个过程都按照计划进行?

答：是，一直按照任务分配的步骤进行

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

答：有，在没能按时按量完成任务时，通过缓冲区对任务进行调整

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

答：暂时不清楚，应该由组长和pm决定

如果历史重来一遍，我们会做什么改进？

答：更细致和更有针对性的分配任务

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

答：有，组内一些成员的水平较高，大部分问题都能有效解决，小部分不能解决的问题通过老师和其他有能力的同学的帮助解决

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

答：任务的前期大家都在摸索，一些定义比较模糊，中后期对时间和精度的把握还不错

用户测试的时间，人力和软件/硬件资源是否足够?

答：相对足够

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

答：有，但是我的任务相对简单，由我来做比较合适，让其他更有能力的成员能有更多的时间和精力去解决更困难的问题

如果历史重来一遍，我们会做什么改进？

答：简单的问题应该尽快解决，把更多的时间留给较复杂的问题

4.变更管理

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

答：是的，群里会及时进行通知

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

答：通过讨论功能的必要性和实现难度来衡量，结果应得到大多数成员的支持

项目的出口条件（ExitCriteria）有清晰的定义吗?

答：不太清楚，我并没有涉及到这部分任务

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

答：能，组长和pm总能及时制定计划和发配任务

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

答：不是总能，因为水平有限，在一定时间内不一定可以完美处理好突发状况

如果历史重来一遍，我们会做什么改进？

答：应该考虑更多的可能性，对紧急问题和突发状况要及时讨论和处理

5.设计和实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

答：在分到项目后由组长和pm完成，时间和人员都很合理

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

答：有，群里讨论解决，选择更让大家接受的方向

团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？

答：不太清楚，我并没有涉及到这部分任务

什么功能产生的Bug最多，为什么？

答：运行机制，因为代码部分本来就容易出现问题

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

答：由代码部分的负责人进行复审，严格的执行了代码规范。

如果历史重来一遍，我们会做什么改进？

答：我个人没什么有效的建议

6.测试和发布
团队是否有一个测试计划？为什么没有？

答：有

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

答：有

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

答：通过手机和夜神模拟器测试

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

答：不清楚，有用，代码不太懂，所以不清楚

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

答：并没有发布

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

答：学到了配合和任务划分的重要性，如果重来一遍，要更细致的划分任务

---

总结：

应该更细致的划分任务，更精准的定义时间，团队配合很重要，有问题要及时沟通

在本次课程中，我发现自己的各方面能力都有所不足，大多数问题都由队友解决，在此非常感谢组里的每一位成员，谢谢大家的帮助