1.会议截图
2.设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们的软件是一个翻翻棋游戏,规则具有一定是改良
典型的用户场景:能够使用电脑的人,可以在等待某些事情的时候玩一下.
2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
完成了大部分的玩法,但是没有实现网络对战的功能
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量无法统计,但一定少于预想的用户量.
4.有什么经验教训? 如果历史重来一遍,我们会做什么改进?
我们没有做好需求分析,对具体功能的实现没有概念.以至于开发过程非常混乱
如果再来一次,我会预想想好每个功能实现的细节,确定好每一个函数.
3.计划
1. 是否有充足的时间来做计划?
有
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
发表意见之后看其他大多数成员的意见.
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
没有全部做完,因为开发中才发现很多细节没有计划到,做了之后又改,以至于负责其他模块的人也要一起来做迫切需要完成的功能.
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有些只要一些很短的代码就能解决的功能,强行分解成很多部分,最终代码也没有用上.
5.我们学到了什么? 如果历史重来一遍,我们会做什么改进?
计划应该在开发前就做的非常详细,而不是模糊的定一个功能,想着实现的人自然会有办法.
4.资源
1. 我们有足够的资源来完成各项任务么?
有
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
通过任务的复杂程度和人员的能力来估计,精度实际上很粗劣.对队员的实际速度也不了解.
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
有点不足,不需要编程的资源在预估的难度之内.
5.变更管理
1. 每个相关的成员都及时知道了变更的消息?
是的.
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
"最小系统法"
要运行起来所需的功能是必须实现的功能.
虽然有作用,但是缺了也可以运行的功能可以推迟.
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
没有bug,能够正常运行
4. 对于可能的变更是否能制定应急计划?
能,但是仅限于阉割功能
6.设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计功能在需求分析的阶段和冲刺阶段,需求分析阶段仅仅由队长完成,冲刺阶段一起讨论.
队长的设计不够清晰,应该和队友多讨论,多花时间确定一个清晰的方案.
冲刺阶段需要做的设计反而太多了,而且一直在修改,时间不合适.
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有,只有在实现时再和其他队员讨论确定.
4. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
代码在提交之后,会有人阅读.但实际上规范性不是很强.
7.测试/发布
**1. 团队是否有一个测试计划?为什么没有? **
有,
3. 团队是否有测试工具来帮助测试?
无
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
我们只在实现时通过代码时空复杂度来预测效能.实际运行起来效率在可接受范围.
我们应该使用一些自动化的工具,做更大量的测试.
5. 在发布的过程中发现了哪些意外问题?
部分成员电脑打包时有时会缺少.dll文件,要发送给其他人来确定是否可以执行.
6. 如果重来一遍,我们会做什么改进?
自己体验总是会有没发现的bug.
再来一次我们会学习一些自动化的测试工具.
8.总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段
3.你觉得目前最需要改进的一个方面是什么?
沟通
成员 | 角色 | 团队贡献分 | 可验证的贡献 |
---|---|---|---|
钟智锋 | PM,开发 | 20.5 | 博客撰写,游戏逻辑开发 |
岑健昆 | 开发 | 19.5 | 测试,代码复审,git管理 |
庄诗楷 | 开发 | 21 | 博客撰写,UI开发 |
易德康 | 开发,测试 | 19.5 | 部分棋子的逻辑,测试 |
朱杰辉 | 开发 | 19.5 | 部分棋子的逻辑,测试 |
张宇芃 | 开发 | 20 | 地图结构编写,部分棋子的逻辑 |