Alpha事后诸葛亮

Aruba小组Cento项目Postmortem

队员：

设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
主要解决文字摘录爱好者的摘录痒点——应用间切换的不方便。定义清楚，我们知道要做的东西会是个什么样子。需求分析阶段，典型用户和典型场景有清楚的描述，在alpha 阶段，我们先实现了最基本的便签功能

2.是否有充足的时间来做计划?
有，在还没开始编码的前前期老师要求做需求分析，那时就有一个较完善的计划

3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
首先是讨论，不同的意见谁提出的谁描述清楚，由于我们没有什么经验，拿捏不准好坏，大家意见说完后投票表决，少数服从多数

计划

1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分队员的事情都没做完，还差一点，总的来说是因为不懂

2.有没有发现你做了一些事后看来没必要或没多大价值的事?
有，但是绕了弯路积攒了或多或少的经验

3.是否每一项任务都有清楚定义和衡量的交付件?
大部分没有。除了UI设计完给出了图示以及标注以外，后面的工作都是一步一步往后走，任务的定义也不是特别明确

4.是否项目的整个过程都按照计划进行?
没有全部实现计划的目标

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

6.将来的计划会做什么修改？
需要计划得更细致，进度合理分配

资源

1.我们有足够的资源来完成各项任务么?
物质资源：我们有几台电脑、几本书
精神资源：我们有足够的信心

2.各项任务所需的时间和其他资源是如何估计的，精度如何?
凭感觉大概估计，没有项目经验，不太好估计时间和资源

3.用户测试的时间，人力和软件/硬件资源是否足够?
这次没有时间找来用户测试，只是组内测试。资源方面应该是够的

4.你有没有感到你做的事情可以让别人来做更有效率?
队友们都觉得自己做得更有效率。

“如果一开始让别人做，我不懂会不会更有效率，但是现在，我觉得我比较有效率。”

变更管理

1.每个相关的员工都及时知道了变更的消息?
开发人员比较及时知道变更。第一次的代码提交冲突后，都会相互提醒，push后也会在群里打个招呼。

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
从基本使用的角度出发，不影响使用的功能推迟

3.项目的出口条件（Exit Criteria）是否得到清晰的定义?
不懂

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

5.队员是否能够有效地处理意料之外的工作请求？
可以。目前还没有遇到意料之外的事

设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在需求分析的时候完成。a版本看来，都是非常合适的

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有很多，经常“我”描述的跟“你”设想的不太一样的时候，讨论协商解决，不能协商的就投票，少数服从多数

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没有用单元测试。
有UML用例图和类图，挺有效的，能帮我们明确功能需求是什么

4.什么功能产生的Bug最多，为什么？
瀑布流实现比较复杂，参数不知如何去改
数据传递功能，因为逻辑有些复杂，容易搞错

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
只是敲代码的人自己检查，代码规范不是非常严格也没人纠正

测试/发布

1.团队是否有一个测试计划？为什么没有？
有计划

2.是否进行了正式的验收测试？
由于时间比较紧，不够正式

3.团队是否有测试工具来帮助测试？
有

4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用测试工具测量跟踪效能

5.在发布的过程中发现了哪些意外问题？
要说有就是当时一个演示用的软件不能安装在实验室电脑上，后来换了某助手后就ok了。其他没有发现什么意外的问题。

总结:

团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级
团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
萌芽阶段
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
从无到有
目前最需要改进的一个方面是什么?
任务和分工需要更明确