Alpha阶段项目Postmortem会议总结
（一）设想和目标
1.我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要解决总是不知道在什么时间该做什么事情，或是老是忘记做一些事情的问题，通过添加事件，选择提醒模式进行提醒。定义清楚，通过分析，对典型用户和典型场景有较清晰的描述。
2.是否有充足的时间来做计划？
完成项目的时间不是很短，做计划的时间足够用，但是我们没有很仔细的做出详细的计划，在完成项目的过程中，也在不断的做着计划。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
在PM的领导下，每一个成员都能认真的听取其他成员给出的不同意见，并通过相互讨论协商解决问题，达到意见的一致。
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
经过给一些用户使用Alpha版本，发现用户对软件重要功能的接受程度和我们事先预想的差不太多，对重要功能还是很感兴趣的，用户感兴趣，也实现了一部分功能，觉得离目标更近了。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
没有明确了解用户对软件的真实想法，也没有很好的了解用户的需求。首先要向用户详细介绍软件的功能，让他们了解我们想要做成的软件是什么样的，让他们做出基于用户的真实的评论，给我们一些有用的建议，站在用户的角度做出用户愿意使用的软件。
（二）计划
1.你原计划的工作是否最后都做完了？如果有没做完的，为什么？
原计划的工作最后基本上都做完了。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事？
这一阶段做出的闹钟功能基本与手机自带的一致，不能吸引用户，没有太大的价值。
3. 是否每一项任务都有清楚定义和衡量的交付件？
有比较清楚的定义和衡量的交付件
4. 是否项目的整个过程都按照计划进行？
没有按计划进行，在安卓手机端进行软件开发部分的知识学起来比较困难，所以这部分进度比较慢。
5. 在计划中有没有留下缓冲区，缓冲区有作用么？
没有，在展示的前一天晚上才勉强完成并可以使用。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
对下一部分制定适应小组成员完成能力的计划，严格按照计划实行，留出一定的缓冲期进行测试。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
首先要制定好计划，严格按照计划实施。小组成员每天要讲一下自己的进展情况，杜绝不做实事的情况发生。
（三）资源
1. 我们有足够的资源来完成各项任务么？
没有，主要是在安卓手机开发方面完全空白，需要从头开始学习，比较盲目，感觉看的多，但是最后学到的却很少，没有实质性的了解，不会运用。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
没有什么明确的依据进行估计，全凭讨论觉得大概可以需要多少时间和资源就制定了计划，因此并没有什么精度。
3. 测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
没有缓冲区进行测试，所以没测试。
低估了难度，本以为美化很简单，结果做出来达不到预期的效果。
4. 你有没有感到你做的事情可以让别人来做（更有效率）？
有，对于熟悉安卓或是有点经验的人来说，整个第一阶段实现的功能，可能不到一天就可以完成，效率很高。
有什么经验教训？ 如果历史重来一遍，我们会做什么改进？
首先要找好资源，了解相关的技术难度，根据时间和能力预测能不能完成这个软件。
（四）变更管理
1. 每个相关的员工都及时知道了变更的消息？
变更都是小组成员一起讨论的结果，所以变更的消息都能及时知道。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
根据完成需要的技术难度来决定先后顺序，简单的必须实现，难的可以推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
有，预期的功能基本实现就算是做好了。
4. 对于可能的变更是否能制定应急计划？
没有应急计划，没有考虑过会出现紧急情况。
5. 员工是否能够有效地处理意料之外的工作请求？
一直按照最初的计划进行，没有提出意料之外的请求。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
事先要想好可能出现的变更情况，并针对每一种情况做出应急计划，定期找用户调研意料之外的请求，并小组讨论是否添加。
（五）设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是最初由小组一起讨论得出的。是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，在用户调研的时候，没有了解用户真实的想法，我们大都是通过自己想象中的情况来分析的。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
没有用过。应该比较有效吧。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？
跳转页面部分产生的Bug最多，主要是不太熟悉函数的使用。发布之后发现添加的闹钟关不上，进程关闭不了。当时实现功能就可以了，没有关心这些情况。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有进行代码复审，代码不规范。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
要对程序进行单元测试，每完成一部分测试一部分，及时修复Bug。
（六）测试/发布
1. 团队是否有一个测试计划？为什么没有？
没有计划，就只是看一下能不能实现功能。第一次团队合作，不知道还要有测试计划。
2. 是否进行了正式的验收测试？
没有，就只是在班级演示了一下功能。
3. 团队是否有测试工具来帮助测试？
虚拟机和手机。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
只在虚拟机和手机上进行了测试，没有用过测量并跟踪软件。有用，多运用测量和跟踪软件，可以更加及时的发现软件的问题并改进。
5. 在发布的过程中发现了哪些意外问题？
添加之后闹钟关不上，进程关闭不了。
我们学到了什么？ 如果历史重来一遍，我们会做什么改进？
测试很重要，要学会用一些有助于优化功能的软件帮助我们改进。
（七）总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
属于CMM阶段。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
目前正处于磨合阶段，正相互之间进行磨合，沟通还是不够。
你觉得团队在这个里程碑相比前一个里程碑有什么改进？
认识成熟了，发现问题不是想象中的这么简单，考虑问题比之前稍全面，有了一些沟通。
你觉得目前最需要改进的一个方面是什么？
计划方面，注重用户体验，根据他们的需求和意见修改计划。
