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阶段。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？

 目前正处于磨合阶段，正相互之间进行磨合，沟通还是不够。

你觉得团队在这个里程碑相比前一个里程碑有什么改进？

 认识成熟了，发现问题不是想象中的这么简单，考虑问题比之前稍全面，有了一些沟通。

你觉得目前最需要改进的一个方面是什么？

 计划方面，注重用户体验，根据他们的需求和意见修改计划。