油炸咸鱼24点APP项目Postmortem结果

1.总结的提纲内容

计划

1. 是否有充足的时间来做计划?  

时间不是很充足，在安排上也不是很合理。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

在QQ群里讨论或者直接召开会议

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

 大部分的都完成了，有些小细节没有完成，因为程序大部分已经完成，有些细节要更改就的把程序在大部分进行重写，非常麻烦。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

有。在编程的时候往往会有很多节外生枝的代码，后面发现并没有什么卵用，最后又删掉了。

5. 是否每一项任务都有清楚定义和衡量的交付件?

这个倒是没有。因为每个队员都有自己的见解，所以一般都没有强制的要求。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

项目的整个过程都按计划进行，大部分功能基本都实现了，在程序闪退的问题上低估了，开始以为闪退问题不大后面发现是个大问题

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，基于团队成员的能力水平参差不齐导致进度会有所偏差所以留下缓冲区是必要的

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

对缓冲区的长度进行更加精确的计算

资源

1. 我们有足够的资源来完成各项任务么?

因为团队里的人员充足，所以各自分配的任务也不紧凑，足够来完成各项任务。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

在任务中估计主要代码的编写时间会花比较多的时间，测试部分就相对快一点。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 

人力资源/硬件资源还是比较足够的。对于那些不需要编程的资源我们一开始以为比较简单，但实际操作中出现的问题难度超出了我们的估计。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

因为团队里个人的能力参差不齐，所以有些事情换成别人往往会有更快的效率，但是每个人有自己的任务，所以还是尽量做好自己事情比较好。

变更管理

1. 每个相关的员工都及时知道了变更的消息?

是的，因为在团队做出变更问题的时候我们都会在群上通知，让每个成员都知道。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

根据程序中重要程度的不同来决定。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

这个没有，一般觉得程序可以运行了，就认为好了。

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

没有。一般都是在问题发生的时候才会关注到。

5. 员工是否能够有效地处理意料之外的工作请求？

有时候有，有时候没有。突发事件往往是意想不到的，但是有些问题在编程的时候往往会有意识到，就会自然的有点防范的相对的措施。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在最初项目刚刚起步的时候就开始了，由我们的队长领导，团队成员一起讨论来完成。在适合的时间，适合的人员中完成了适合的事情。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有碰到一些比较难得部分，刚开始打算模糊一下过去，最后讨论觉得现在模糊混过去，等到实践的时候还是要来解决这些问题，所以当时就针对这些问题做了进一步的探讨，制定了一些详细的计划来执行。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

有运用单元测试，基本都是每个人测试自己的模块，在遇到实在不懂得问题，大家一起讨论，在测试结果符合后再合并到一起。测试过程没有采用工具，基本是手工测试，遇到问题就修改。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

app打开的时候闪退等的Bug最多，因为这一部分的代码相对复杂，有些地方没有考虑充分，导致运行的时候有较多的不足。当时在设计/开发的时候比较注重代码的编写了实现各个功能等，所以忽视了这一方面。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

因为代码是有团队成员一起写的，各自的编程风格不一样，为了能够在整合的时候比较容易理解，所以有严格执行了代码的规范。

测试/发布

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

刚开始测试阶段团队有计划讨论一个测试计划，但是在实际操作的时候因为编写代码的时候有进行部分的测试，加上测试的难度比较小以及一些其他的因素，最后测试计划没有实质的落实。

2. 是否进行了正式的验收测试？

正式的验收测试是没有，到了最后的测试阶段，我们的app在手机上进行了最后结果测试，但是并没有十分正式的验收，结果也是相对满意就过了。

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

没有。但是我们有针对许多用户之前提出的各个方面的意见进行测试，对于不满意的部分有进一步的修改。

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

我们团队主要是通过手动测试并跟踪软件的效能的。从实际运行的结果来看，这些测试工作多少还是有一点用的，但是仍然有很多的问题测试不出来，有些bug由于手动测试比较容易忽视掉。

5. 在发布的过程中发现了哪些意外问题？

在发布的时候有出现了闪退的一些意外，不过最终找到了问题的所在。

附件：

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
1． 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 

2． 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 

3． 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 目前，公司需要申请的就是已定义级别，通常称为CMMI3。由此，我们可知CMMI3是CMMI其中的一个等级。

4． 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 

5． 优化管理级
可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。

总结

 二级，已管理级

 目前团队已经完成了alpha阶段的冲刺，度过了磨合期正在走向规范阶段。

 一方面是经验方面的增长再着是团队默契的提升

 b. 博客要附上全组讨论的照片

2.团队成员在Alpha阶段的角色和具体贡献：

团队作业7——Alpha冲刺之事后诸葛亮