事后诸葛亮

1.会议截图

事后诸葛亮_第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 地图结构编写,部分棋子的逻辑

你可能感兴趣的:(事后诸葛亮)