AbsoluteDefense 项目Beta版本Postmortem结果

设想和目标：

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

没有足够的时间，有大量的其他科目的大作业和小作业，以及必须参加的课外活动（如实验室开会、干活、社团组织开会等），还有更多的软工作业，如第二次Pair work等。

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

在一开始的游戏设计阶段，我们采用的是举手表决的方式决定采用一个方案的。在之后的阶段，我们采用的都是最符合框架的设计，争议用事实证明并解决。

如果重来一遍？

我们会将项目设计的简单一些，并且尽早确定项目的框架。

计划

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

前阶段的工作都做完了，但是后面的工作大家都有些没有做完，因为没有足够的时间，还有对项目当前框架的理解不够深刻。

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

很多，一开始设计的框架中有许多是没有必要的，反而是一些很有必要的设计没有加入到框架之中。还有许多软件工程中的过程也许并不适合我们，如Daily Scrum，如果换成Weekly Scrum可能更加合适。

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

大部分都有，我们将任务提交到TFS中，项目组员都可以对其进行查看、更改、完成。但是，大家交付的内容质量有所差异，在项目完成之前很难衡量其好坏。

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

基本上是，因为黄杨大神的“光环”，大家大部分情况下都听他的。

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

有缓冲区，在一开始的项目安排中，我们规定要在一个星期内完成编码工作，其实两个星期内完成即可，但是我们留下了一个星期的缓冲区。事实证明这个缓冲区作用很大，因为大家几乎都没有在一个星期以内完成。

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

应该明确缓冲区的长度，减少一些项目内容以更快的完成该项目，不采用加班（刷夜）策略，害人害己。

如果重来一遍？

我们会增强对项目组员的管理和对项目的管理。

资源

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

时间资源不是很够。很多情况下，花了不少时间来设置机器，以及设置用来测试的数据，也花了不少时间用来学习有关Cocos2d-x、C++的内容。硬件资源足够，我们有几个Android设备和一个IPhone4s，以及N台电脑。

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

开始精度很粗略，大家自己去修改自己的预计时间。后来随着项目任务的加重，大家只顾得上干活，没怎么修改TFS上的所需时间，没时间考虑精度问题。

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

人力和软件、硬件资源应该足够，但是还需要在后期测试工作中根据工作情况看是否需要进行调整。

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

有，若是要求更有效率的话，让大神们（有实际工作经验的人）来做全部的事情应该最有效率。但是这是学校，不是万恶的资本主义企业。我们更应该看重学习的效果和过程。

如果重来一遍？

我们要让更多的人才加入我们。

变更管理

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

由于大家都住得比较近，消息传播得比较快，大家都可以很快的得知一些变更的消息。但是由于作息时间不同，上的课程也不同，有时也会吃到闭门羹。

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

必须实现的功能由大家讨论而得，大家在试用Demo的过程中选出了一些需要“推迟”和“必须实现”的功能。另外，没有完成的任务只好推迟。我们不是同事，没办法“降工资”或者“炒鱿鱼”。

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

基本没有，但是我们有一定的缓冲时间。

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

项目组员有不明白的问题，会去问两个PM，PM如果觉得确实有问题，会更改项目的需求。

如果重来一遍?

我们会采用一个对于我们更加熟悉的框架进行开发，这样可以减少需求变更的情况。

设计/实现

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

游戏的设计工作在项目刚开始的时候，由黄杨来完成的；项目框架的设计工作在游戏设计完成之后，由王安然来完成的。是合适的时间，王安然不是很适合设计基于cocos2d-x的框架，也应该由黄杨完成。

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

有，我们采用的是放任自由的原则，发挥组员的创造力，看具体执行的人是如何解决的。

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

我们有专门的测试人员使用单元测试来对项目进行测试；TDD 要求PM要清楚地确定功能说明（spec），我们也已经做到；我们在昨晚项目的具体框架设计之后便导出了UML图。但事实证明，UML图用处不大，UML无法对项目中隐藏的问题进行表示。

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

关于物理的一些功能产生的Bug最多。因为这比较考验数学功底。

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

我们在整个项目中一直采用了代码复审，较为严格的执行了代码规范。

如果再来一遍？

我们会加紧工作，引入绩效和优胜劣汰的思想，或者加入奖金这一因素。

关于敏捷开发

1. 对比敏捷的原则, 你觉得你们小组做得最好的是什么?

我觉得我们小组都做得比较一般。因为，敏捷开发需要一心一意的开发项目，并且有一定的激励，这对我们来说比较困难。

2. 什么是在下个阶段 m2 要改进的地方? 越具体越好。

下个阶段要在游戏Demo的基础上加上道具、武器、积分、记分板功能，增强AI功能。最后在m3阶段，我们要加入应用内支付功能，对其在Android市场和IOS市场中进行发布。

一起讨论的照片：