Put-Me-Down项目Postmortem2

一.设想和目标
二.计划
三.资源
四.变更管理
五.设计/实现
六.测试/发布
总结

一.设想和目标

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

我们的软件要帮助低头族控制使用手机时间。功能很明确，对典型用户和典型场景有清晰的描述，在需求规格说明书中。

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

有，但是因为对开发不熟悉，计划是一步一步摸索出来的。

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

成员脾气好，商讨接纳合理的意见。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

首先应明确整个开发过程大体要做哪些事，将较大的模块落实到个人负责，如文档由某成员专门负责。

二.计划

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

没有，大部分做完了，我们原本想将数据备份到数据库，后来因为申请的原因、我们的APP在Alpha阶段实现功能可以不需要服务器、安卓方面功能较多、服务器方面不熟悉，所以程序重心放在安卓；

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

基本没有。美工有时候越用心会适得其反，走到极端。

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

没有每项，代码提交是明显的可衡量交付件。但是成员在学习过程中没有设定交付件，导致学习效率不高。

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

没有完全按原计划，计划在整个过程中有变动，项目有计划地进行。初始计划我们是想将程序方面分为安卓和后台，主要是程序方面的工作。我们对项目的认识是模糊的。经过alpha阶段前2天的摸索，基本上知道整个完成这个APP要做什么。将程序重心放在安卓；后来意识到界面的重要，以及原本负责服务器后台的人员会PS，所以我们在界面设计方面加入了自己制作的符合我们APP主题的图标；

博客的内容有助于每个成员把握自己的时间，清楚整个项目，把握到整个项目的过程，以及记录每个人在这一阶段的成长（困难、总结），所以博客内容的收集、整理是很重要，我们有2个人可以负责文档。一开始对博客的内容提纲不清楚，摸清提纲后一个人负责就可以了，另一个人可以负责其他事务。

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

有考虑到缓冲区，缓冲区有作用，可以应付紧急情况，如bug修复。

6. 将来的计划会做什么修改？

会留出更多缓冲区，不将时间按事务排满。

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

应该明确整个项目的事务，清楚定义每个任务，包括学习任务，设定衡量的交付件，提高学习效率。写出代码框架，大家坐在一起打代码。

三.资源

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

有资源，但没有足够的资源，我们最好的资源是有一位开发安卓经验的组长，他写了整个代码的结构；拥有PS技能的人员；文档编写人员；缺少的资源是测试经验、界面设计知识；但我们有学习资源，却没有安排好学习任务以及学习衡量交付件。

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

我们将任务切分，基本是一天完成几个任务，没有具体到小时，精度不高。

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

测试是薄弱的一块，我们是手动测试，用例测试，测试方面花的时间少。对于美工设计和文案我们有重视，也认识到美工是一大重点以及弱项。

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

有，我们有2个人可以写文档，后来让一个人做，另一个人做其他事，充分利用人力，提高效率。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

我们会多面对面交流，坐在一起学习，制定学习验收计划，提高效率。

四.变更管理

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

知道，通过博客的任务安排知道。

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

主体功能实现，如将服务器推迟到下个版本，计时以及记录、结束时强制手动停止必须实现。

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

有，组长很注重细节，结合用户场景来考量项目是否做好了。

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

项目变更可能性小，没有考虑到变更，如果有变更都是积极地想办法解决。

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

能。有时候临时出现新的事物，如界面整合需要修改，大家都积极配合。

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

原本对项目的认识不够，所以出现了变更。组长都是根据每个人意愿让大家自主选择，大家不知道自己想做什么，具体角色是做什么，如果重来一次让组长明确每个角色要做什么，再结合成员志愿及组长考量，将角色及责任落实到个人。

五.设计/实现

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

项目的整体结构则由李坤隆先僧完成，李先僧之前有参与过开发，相比其他成员更熟悉开发的套路，所以由他来完成项目的架构是合适的。

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

因为其他小组成员刚开始学习开发，不懂套路，所以代码结构的设计是由李先僧一人完成的。小组项目最终采用mvp模式，根据李先僧的描述，这也是他第一次使用这个模式，对这个模式并不熟悉，和其他成员一样也是摸着石头过河。一开始对代码的分包是像传统的‘activities’，‘adapter’这样根据每个文件的所属类别分包，还是像google官方的mvp例子那样根据模块分包犹豫不决。最终看了一篇博文按照应用功能来封装，而非所属类别决定按模块分包。（只是把文件按模块分了下包，实际分工的时候是按m-v-p来分的，并不是某个人把某个功能模块的mvp三层全包了。mvp三层间依赖于接口而非具体的实现类，只要接口在一开始的时候商定好，三个层之间完全可以异步并行开发，不是很懂栋哥评测那天说的“伪按层分工”是什么意思）

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

团队没有单元测试，由于项目开始的比较晚，预留的时间比较少，大家都不懂得测试代码怎么写。有尝试着学习怎么写android的单元测试，但是由于最终时间太紧没有完成测试（这是个教训，以后要预留好足够的时间，在做中学）有使用uml工具画项目的用例图和类图。

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

暂时没发现产生很多bug的功能，在发布前发现多用户登入的情况下，还是保有之前用户的数据，发布后发现如果在零点的时候使用计时功能可能会导致每日计时统计结果又偏差。都是逻辑上的错误

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

李先僧没有让大家重写代码，而是自己把代码修改了一下（命名并没有改:(），我认为这是不利于初学者成长的，如果李先僧个大家指出不规范的地方，并说明该怎么写，这样学习效果会更好！

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

如果重来一次，让李先僧更多地给其他组员加油打气写代码，指出代码不规范的地方，并说明该怎么写。一开始就重视测试工作，就像对界面一样。

六.测试/发布

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

有测试计划

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

是的，针对各项功能都进行了测试

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

没有用到测试工具，因为第一次进行测试，所以就先采用了人工测试

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

在alpha版本完成后，将各个模块的测试进行分配，每个组员进行用例测试。最后的运行结果证明了测试工作还是有用的，发现了很多之前没发现的潜在问题，下次要再细心点

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

意外问题倒是没有，和原本设想的差不了太多

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

人工测试可能还是会有些缺陷，用测试工具测试可运行更多、更繁琐的测试，且快速高效，可执行一些人工测试执行相当困难或者做不到的测试，如大量的用户并发、更好的利用资源，具有一致性和可重复性的特点。所以下次可能更倾向于工具和人工结合。

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

二级

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

萌芽，还要多学习，每个成员都要增强实力。

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

回首总结了整个过程，发现有许多bug，这些bug从另一个角度看是别样的收获，如果能修复了这些bug、漏洞，收获更多。最需要改进的地方：团队应多面对面交流，提高效率，不拖延。