Alpha阶段事后分析
设想与目标
1. 软件要解决的问题
我们要制作一个创意发布与合作实现的网站。
2. 是否达到目标
减量实现了原计划的Alpha阶段的功能，第一版本开发失败，没有达到原计划的用户数量。
3. 用户量, 用户对重要功能的接受程度
用户量没有达到预期。现有功能较为简陋，用户希望有功能扩增。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 多交流，落实每个人的进度。
- 尽早进行测试，否则最后发现不过对接全部重来。
计划
1. 是否有充足的时间来做计划?
有充足的时间来做计划，并在开发过程中微调。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
计划的产生本身是由全体团队成员一起讨论得出的，因实现功能较简单，目前并没有不同意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有完成，第二次开发时部分功能来不及完成了，时间不足。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
原附加功能繁多，可以先着眼现在，不必追求一次完工。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是。一般分为开发和测试。开发包括了API设计对接。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
API对接失败，前后端无法协调。当时没有制定统一的API标准，并没有尽早开始整合。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
Alpha阶段的计划中没有明确的缓冲区。开发时间一直很紧张。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
Beta阶段会完善上一阶段遗留任务，并进行新功能扩展。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 明确进度时间及任务分工
- 多了解每个人的开发状况，调控总体开发
资源
1. 我们有足够的资源来完成各项任务么?
Alpha阶段有六个人，五个人负责开发，一个人负责文档，资源充足但是调度不太好。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
前后端时间比预计长一些，但是忙等待与对接严重打乱了计划。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
Alpha阶段测试人力资源充足，硬件资源也充足。
Alpha阶段美工设计较为简陋，这也是后期完善的目标之一，难度并不小。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
没有。每个人时间有限，自己的事自己做好。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 尽早开始测试，也好提前预估好面临的困难。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
变更一般在集体会议或者微信群公布并通知相关人员。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
基本可使用功能最小集为“必须实现”功能，其余都归类在“推迟”功能里。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
实现了基本功能，基本可使用。
4. 对于可能的变更是否能制定应急计划?
在第一版本开发失败后紧急开发了简陋版第二版本。
5. 员工是否能够有效地处理意料之外的工作请求？
开发人员及时消除了第一版本开发失败的影响。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 会尽早进行发布和测试的相关工作，确保版本是可完成的。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在正式开发之前大家预选投票决定，代表了大多数人的想法。是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
少数功能的设计方面有不确定的地方，在后续的开发过程中再次确定多种方案的可行性，并选择最优进行详细设计开发。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
运用了单元测试，issues管理进度来实现，比较有效地处理了进度。并没有uml文档，感觉敏捷开发并不能提早确定要设计的具体内容，没有必要更新uml文档。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
因功能较简单，没有产生太多bug。bug的产生是无法预期的，产生bug是一种合理现象。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
开发同学在写完新代码后会进行复审并交付测试。
执行了约定的代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计不能好高骛远，一步一步从最基本的功能开始。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
团队在项目即将完成时确定了测试人员及测试计划。
2. 是否进行了正式的验收测试？
进行了场景测试、压力测试、兼容性测试。
3. 团队是否有测试工具来帮助测试？
使用了覆盖率测试工具进行辅助测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
网页测试，主要测试浏览器。测试过程基本没有问题，但是测试工作是有用的。目前无改进。
5. 在发布的过程中发现了哪些意外问题？
因为是网页发布，并没产生什么意外问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 进行更加详细全面的测试。
团队的角色，管理，合作
1. 角色确定
前期全力开发，pm文档；后期根据开发进度分化。
2. 互相帮助
一个功能通常会分解成2-3个任务，在开发过程中遇到问题时通常会在群内讨论，不能解决会留在例会进行讨论分析，并决定是否更改方向。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 严格管控每个人的进度，监督好每个人的工作质量。
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前处于第二级（管理级），在项目开发中将任务具体到了每个人，并进行了进度监督督促。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段。团队成员能够较好的进行合作，项目推进较为稳定；但是应对突变事件能力不足。
3. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 根据实际随时更改设计需求；例如当初设计了开发者功能，后来发现开发者还可以是发布者，多角色可以并存，于是重新划分了角色。
- 例会频繁，在一定程度上解决了交流不畅问题。
下一阶段改进：
- 更加重视测试工作，在整个beta阶段都要跟进测试任务，对应功能的开发人员配合测试人员进行更全面的测试。
- 增加风险管理，对开发环节可能出现的问题准备备选方案，避免影响开发进度。
- 增加缓冲区，避免意外情况出现时手忙脚乱。
讨论照片：