M1事后分析报告（Postmortem Report）

M1事后分析报告（Postmortem Report）

 

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

　　我们项目组所开发的软件为一个基于Android的手机端的时间管理软件，主要功能为时间管理软件，可以用于管理待办事项，记录一些需要提醒的信息等。有事件提醒、与Google账户同步、课程表等功能。TimeLine操作人性化，UI界面清新简洁，小而便捷，占用内存小。 最终计划实现管理待办事项，事件管理，课程表查询，与Google日历同步等功能。

　　我们对工作的还是很清楚，同时我们建立的软件需求与功能说明文档和软件的基本构架图。

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

　　由于大家都没有从事Android开发的经验，所以一切都得从零开始，刚开始做总体规划时，大家还是花了不少时间讨论一二轮迭代的目标，主要分工，与不同阶段任务的。较为明确，协调任务分配，以减少组员负担。

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

　　在开发过程中，当我们遇到的问题，或有什么意见不统一，我们会在每天会议中及时讨论提出，大家分别给出解决方案，再次讨论商榷，尝试解决问题，如不成功，我们会继续重复以上步骤。由于我们几个主要开发人员的寝室相距很近，因而，几乎在任何时候我们都可以迅速聚到一起，解决大家遇到的问题。

最后第一轮实现功能：

         1).添加任务，并设定时间，标签

         2).任务时间轴—当天任务概览

         3).任务日历—本月任务分析展示

         4).添加个人总结记录

　　我们第一轮迭代的主要目的就是实现学长软件的基本功能，并为其他的扩展功能搭起基本框架，扩展功能只有基本框架，因此第一轮迭代呈现出来的功能比较简单，基本可以用基本的手机备忘录的代替大部分功能，因此我们对第一轮迭代的用户下载量，不敢抱有太大期望。

计划

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

　我们第一轮迭代计划的工作全部完成了

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

　第一轮迭代可以不用急于搭建扩展功能的框架，可先集中精力在基本功能上多下些功夫。

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

　基本上每一项任务都有清楚定义和衡量的交付件。

4.是否项目的整个过程都按照计划进行?

　计划的中期任务被延后了一周。

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

　在计划中我们总是会留缓冲区，很多次任务，在完成过程中遇到了各种开始预期的事件，使得计划有所推迟，这时缓冲区会发挥很好的作业。

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

完善已有的四个功能；

　　美化UI，微调细节，完善用户体验；

　　添加功能：进程完成统计表,提醒功能，同步功能（谷歌日历)，导出功能…

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?、

     由于大家都没有从事Android开发的经验，所以一切都得从零开始，而且要求大家分工明确，协调任务分配，减少组员负担。由于跨平台，跨语言，导致我们几乎是重写了整个软件，要学习很多新东西才能完成学长代码中所实现的功能。不能总呆在一起实时共享资源分享经验，并且不能保证开发同步，各自的时间安排存在冲突，个人的任务也无法保证连续不间断。

      我们会在后面的工作中，确立个人任务之后，还不断根据反馈调整任务，让每个组员发挥各自最大能力，集合众多资源，通过查阅书籍，向同学请教，上网查询，开发过程中的困难都立即解决。

资源

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

　　首先我们的资源并不十分完善，一没有一个人是代码大神，二没有一个人有安卓开发经验。所以我们真可谓是白手起家，从零做起。不过我们大家还是克服了重重困难，完成了第一轮迭代的任务。

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

　　我们各项任务的完成时间是通过计算任务难度来进行的。从整体情况来看，我们的估计时间总是有些偏少。我们认为这样的原因是对困难的估计不足造成的。所以在第二轮迭代的时候我们应该在任务时间估计上更加保守一些。

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

　　由于我们的软件是一款应用软件，所以测试环节相对简单，我们的人手是足够的。对于那些不需要编程的资源，对我们来说并没有低估难度。

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

　　我们的任务分配都是按照每个人的能力和专长来分的。例如，相对编程能力好的就多分一些代码的任务，文档写得好的就多写一点文档。

历史的教训：

　　通过第一轮迭代，我们还是学到了许多东西的。在下一轮迭代时我们将会放更多的人手在代码的编写上。这样做的主要原因是第一轮迭代的经验证明我们完全无需在测试环节投入过多的人手，将测试人员放入代码编写组完善代码是十分有必要的。

变更管理

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

　　我们通过建立了QQ群和微信群来及时更新消息。所以我们的每个相关的员工都及时知道了变更的消息。

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

　　我们在事前将我们软件的整体功能规划好，以此来决定什么先做，什么后做。计划里写好就是“必须实现的”，暂时没有列入计划的就可以被“推迟”。

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

　　我们的出口条件就是我们一开始为第一轮迭代定的目标。所以，我们对于项目的出口条件是有清晰的定义的。

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

　　可以。对于可能的变更或是一旦有紧急情况，我们的组长会及时制定方案，并进行通知。

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

　　我们的员工能够有效地处理意料之外的工作请求。

历史教训：

　　通过第一轮迭代，我们认为我们在变更管理上做的还不错，经验还是值得保留的，即在迭代前将整个计划目标定下来，作为迭代过程中的参考。由此可见在事前定好计划的重要性。

 

设计/实现

1.设计工作在第一轮迭代的第一周完成，后端设计由汪仁贵完成，前端设计由居玉皓完成。是软工课规定的设计周期内进行的。汪仁贵细致地读了学长代码，最了解原始软件的实现。同时他也是PM，可以对整体进行把控。居玉皓曾做过交互设计的一些小项目，有一些UI方面的经验，所以设计的人选基本合适。

2.碰到过模棱两可的情况。比如验证用户输入的时间是否合法，可以在表现层去验证，同时可以在业务层。遇到这种情况会在设计阶段的每日Scrum中提出来，由大家共同商讨解决。

3.团队没有采用单元测试，而是针对安卓软件的各个功能进行了测试，测试了不同版本的安卓系统下软件的应用情况，没有采用其它测试工具。

4. 不同的activity之间传输数据部分Bug最多，因为不同的activity由不同的人来编码，在一些细节方面需要不断的沟通、调试才能解决数据传输的问题。发布之后没有发现重要Bug。

5.代码复审由PM汪仁贵采用面对面的进行，每个交给他代码的人控制代码的流程，展示测试效果，他可以随时打断并提出问题，如发现严重问题两个人共同商议讨论后由代码编写者解决，并等待下一次复审。如果只存在小问题，则代码编写者将代码改好后，直接交给PM，不需要再次复审。

 

测试/发布

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

　　我们有一个简单的测试计划，首先是在各个不同配置的AVD下进行测试，然后在不同型号的实体机下进行测试，然而由于实际可供调试的机器还是比较少，所以，测试计划其实也并不完整。但是在所有android3.0以上版本的机器中，软件运行正常。

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

　　实际测试结果验证软件运行正常，我们在开发过程中即逐步测试，在最后的验收测试中，我们组内所有人都在体验产品以提出建议为下一轮开发做准备，所以最后的验收是组内人员一起见证的。

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

　　由于我们没有VS那样的IDE提供测试方案，所以我们的软件并没有使用测试工具来帮助测试，我们只能简单的通过ADT带的DDMS来进行内存监控以及响应时间监控，但这些太基本，对我们的测试并没有太大帮助。而测试结果也显示软件运行正常。

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

　　首先是依靠DDMS监测运行状况，由于我们的软件比较简单，所以占用内存以及响应时间都比较正常，与其他软件相比也没有毛病。。。在团队成员的实机上体验，也没感觉到问题。DDMS粗略的给我们提供了软件运行的健康程度，但是软件的不足还得靠实际上手体验，然后进行调整

至于改进，我们认为DDMS没有像VS单元测试那样详细的报告，如果我们能了解关于代码本身的信息，对于我们进行代码优化会很有帮助。

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

1)．由于Alpha版本到deadline才完善发布，时间仓促，客观条件不允许我们再提交到正规的App商店，我们只能通过放在网盘提供下载并以个人方式进行推广。

2)  程序有些功能细节处理存在问题，到最后关头只能选择展示丢弃这个功能。

总结

　　我觉得团队目前的状态属于 CMM/CMMI 中的初始级，目前处于萌芽阶段。现在还是第一轮迭代，目前最需要改进的一个方面是UI.

　　在第一轮迭代中，我主要负责安卓软件的UI开发。在软件设计阶段，我先用photoshop做了各个界面的示意图出来。

　　

　　而在实际开发期间，完全没有安卓开发经验的我发现要真的实现其界面并不容易，很多时候实现一个功能就需要尝试各种方法，而更没有精力去追求美观了，所以最后做出来的软件和最初的设计相差很大。

　　在学习安卓开发过程中，我首次接触到xml布局文件与.java文件结合使用的功能，这和以往用java写界面有很大的差别。开始时候我一直不清楚它们之间具体是怎么联系起来而实现最终效果的，开发进度也一直停滞不前。直到有一天看其它人的代码终于明白它们之间的关系，而后才真正开始了自己的开发。

　　另外遇到的一个阻碍是安卓虚拟机在我的电脑上运行十分缓慢，并且不时出现各种问题，而安卓开发就是要需要不断地调试以及刷程序的，这是我开发的进度十分缓慢。有一次我反复调了一晚上都没能把一个开发中的问题解决，那之后的几天都很沮丧，没有积极开发的心情。后来经同学的建议改在自己的手机上调试程序，这才把问题解决。

　　总而言之，第一轮迭代结束，我才刚刚进入开发的状态，之前的精力大多用于开发之外，而在第二轮迭代中我希望能认真进行开发工作，争取将UI做的更美观实用。

 

最后的最后，附上小组讨论照片：