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市场中进行发布。

 

一起讨论的照片:

AbsoluteDefense 项目Beta版本Postmortem结果_第1张图片

转载于:https://www.cnblogs.com/buaashine/archive/2012/11/26/2788756.html

你可能感兴趣的:(AbsoluteDefense 项目Beta版本Postmortem结果)