油炸咸鱼24点APP项目Postmortem结果
1.总结的提纲内容
计划
1. 是否有充足的时间来做计划?
beta版本时间与alpha冲刺时间是一样的，但是安排上比第一次更合理，所以完成的任务与预期相差无几。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在QQ群里讨论或者每日会议上讨论
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分的都完成了，有些小细节没有完成，因为程序大部分已经完成，有些细节要更改就的把程序在大部分进行重写，非常麻烦。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
与上一阶段类似，没办法避免。在编程的时候往往会有很多节外生枝的代码，后面发现并没有什么卵用，最后又删掉了。
5. 是否每一项任务都有清楚定义和衡量的交付件?
这个倒是没有。因为每个队员都有自己的见解，所以一般都没有强制的要求。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程都按计划进行，大部分功能基本都实现了，到后面出现了BUG在修复上有比较大的问题。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，基于团队成员的能力水平参差不齐导致进度会有所偏差所以留下缓冲区是必要的
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在不影响进度的情况设定更为合理的缓冲区，尽量不要加班。
资源
1. 我们有足够的资源来完成各项任务么?
因为团队里的人员充足，所以各自分配的任务也不紧凑，足够来完成各项任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
在任务中估计主要代码的编写时间会花比较多的时间，测试部分主要是人工测试，会比较快。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
人力资源/硬件资源还是比较足够的。对于那些不需要编程的资源我们一开始以为比较简单，但实际操作中出现的问题难度超出了我们的估计。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
这种问题可以适当向组长提议，但是如果其他人的任务已经在进行，如果交换的话还需要进行交付可能会花费更多的时间，所以又需要考虑更多的细节，所以即使有这种感觉最好是请教你认为能更有效率完成的那个人来让自己变得更有效率吧。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，因为在团队做出变更问题的时候我们都会在群上通知，让每个成员都知道。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
要具体根据程序里面的衔接关系，一般是先要把主要功能给实现了。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
这个没有，一般觉得程序可以运行了，相应的任务完成了就OK了。
4. 对于可能的变更是否能制定应急计划?
没有。一般都是在问题发生的时候才会关注到。
5. 员工是否能够有效地处理意料之外的工作请求？
有时候有，有时候没有。突发事件往往是意想不到的，但是有些问题在编程的时候往往会有意识到，就会自然的有点防范的相对的措施。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在最初项目刚刚起步的时候就开始了，组长采
集各组员意见进行安排的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
模棱两可的工作是可以模糊的混过去，但是在alpha阶段吃过亏了，虽然说过程比较重要，但是分数多少会影响到自身的心态，所以在beta阶段模棱两可的情况团队比较认真对待，通过组内讨论来决定一个方向的。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
主要是人工测试。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在主界面的数字使用问题，发布之后的重要BUG倒是没有发现，在开发的时候我们主要是去实现功能的，没有考虑到这些数字的多次使用情况，把情况过于理想化导致没有考虑到这些可能出错的环节。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们严格执行了代码规范，在复审上没有话太多的功夫，主要是对有BUG的部分代码进行了多次审视试图修复。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
测试计划是由，但是与alpha阶段一样进行的是人工测试，落实情况在这一阶段并没有说比上一阶段优越多少，这点做得不够好。
2. 是否进行了正式的验收测试？
正式的验收没有进行，是通过APP在手机上安装运行。
3. 团队是否有测试工具来帮助测试？
没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们团队主要是通过手动测试并跟踪软件的效能的。从实际运行的结果来看，这些测试工作多少还是有一点用的，但是仍然有很多的问题测试不出来，有些bug由于手动测试比较容易忽视掉。
5. 在发布的过程中发现了哪些意外问题？
发布过程的意外问题没有发现。
附件：
CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
1． 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
2． 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3． 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 目前，公司需要申请的就是已定义级别，通常称为CMMI3。由此，我们可知CMMI3是CMMI其中的一个等级。
4． 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5． 优化管理级
可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。
总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级，已管理级
2.你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
目前团队已经完成了beta阶段的冲刺，我觉得我们进入了不成熟的规范阶段。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队的任务分配和积极性比上一阶段好多了，beta阶段进行会比alpha更得心应手。
4.你觉得目前最需要改进的一个方面是什么?
组内成员要对程序提出自己的意见尽量去实现。
b. 博客要附上全组讨论的照片
2.团队成员在Alpha阶段的角色和具体贡献：
|
名字 |
角色 |
团队贡献分 |
可验证的贡献 |
|
陈麟凤 |
PM |
21 |
主要代码撰写，分配工作 |
|
陈宇杰 |
Dev |
17 |
部分代码，博客 |
|
黄海鸿 |
Test |
20 |
测试，博客 |
|
康建灿 |
Dev |
18 |
部分代码，测试 |
|
许明涛 |
Test |
19 |
测试，博客 |
|
张志杰 |
Dev |
25 |
主要代码撰写，博客 |