事后诸葛亮
一、团队讨论照片
二、设想与目标
1、我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述
- 我们的软件主要是做一个闯关类游戏,加入自己的特有元素,对操作有一定的改进。
- 定义清楚,核心就是做一个有特色的闯关类游戏。
- 对典型用户及典型场景描述清晰,主要针对有闯关游戏爱好的人群,是一款休闲娱乐的小游戏。
2、 .我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么?原计划达到的用户数量达到了么?)
完成了大部分的玩法,但仍有少部分操作方面的bug。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于未对软件进行发布,所以用户量和用户对功能的接受程度无法估计,所以我们并没有离目标更近。
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们没有做好需求分析,对具体功能的实现没有概念.以至于开发过程非常混乱
如果再来一次,我会预想想好每个功能实现的细节,确定好每一个函数。
三、计划
1、是否有充足的时间来做计划?
有。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
集体讨论,统一方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
大多完成了。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
把一些简单的问题想的太过复杂,导致代码量多出许多,后面又删改了。
5.我们学到了什么? 如果历史重来一遍,我们会做什么改进?
计划应该在开发前就做的非常详细,而不是模糊的定一个功能。
四、资源
1. 我们有足够的资源来完成各项任务么?
有
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
通过任务的复杂程度和人员的能力来估计,精度实际上很粗劣.对队员的实际速度也不了解。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
较为足够,在预估范围内
五、变更管理
1. 每个相关的成员都及时知道了变更的消息?
是的
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
采用四象限法则,在时间紧急的情况下,召开全体线上会议对剩余未实现功能进行“重要紧急”、“重要不紧急”、“紧急不重要”、“不重要不紧急”的分类,排出优先级。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
没有bug,能够正常运行
4. 对于可能的变更是否能制定应急计划?
能
六、设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计功能在需求分析的阶段和冲刺阶段,需求分析阶段仅仅由队长完成,冲刺阶段一起讨论.
队长的设计不够清晰,应该和队友多讨论,多花时间确定一个清晰的方案.
冲刺阶段需要做的设计反而太多了,而且一直在修改,时间不合适.
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有,大家一起经过讨论后得出结果
4. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
代码在提交之后,会有人阅读.但实际上规范性不是很强.
七、测试/发布
1. 团队是否有一个测试计划?为什么没有?
有
2. 是否进行了正式的验收测试?
是。
3. 团队是否有测试工具来帮助测试?
无
4. 在发布的过程中发现了哪些意外问题?
没有
5、我们学到了什么? 如果重来一遍,我们会做什么改进?
要善用工具进行自动化测试,扩大试用的用户范围。
八、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段
3.你觉得目前最需要改进的一个方面是什么?
沟通
成员名称 | 角色 | 团队贡献分 | 可验证的贡献 |
---|---|---|---|
李兆海 | 开发 | 21.5 | 游戏备份,博客撰写 |
卢柏铖 | 开发 | 20.5 | 登录界面的设计 |
陈家健 | 开发 | 21 | 添加障碍物,碰撞检测 |
陈健 | 开发 | 20 | 制作精灵,音效管理 |
陈乙鑫 | 开发 | 22 | 地图设计,游戏ui的制作 |
陈蜀毅 | 开发 | 19.5 | 障碍的多样性,博客撰写 |
杜仲谋 | 测试 | 19 | 测试,博客撰写 |