一、总结提纲内容

a. 项目管理之事后诸葛亮会

RunningGuys约跑项目Postmortem结果

整理：曾丽君

设想和目标

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

我们的产品约跑APP是为了更好释放学生压力，为学生的身体素质着想，让更多的学生走向操场，体验运动的乐趣。现在市面上有很多类似APP，但是现有的方案虽然有在一定程度上解决这些需求，但我们也要与其竞争，向其学习，取其精华去其糟粕。我们会从我们的身边开始，鼓励同学朋友使用我们的APP，一起“约跑”，快乐运动，互相PK，激情跑步。学校本身也有推行“三走”活动，我们可以争取和学校合作，把APP向全校推广，同时也能争取与其他学校的合作。我们自己也要上街区、社区等地方进行线下推广，让更多的人了解到我们的APP。

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

有时间，老师整整留了一周来给我们做产品需求规格说明书，这期间我们经过了相当详细的考虑，而且在第一次展示了说明书以后我们也根据老师的建议将计划进一步修改完善。

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

目前为止还没有什么特别意见很不一样的地方，因为成果不多，大家都是在学习相关知识。如果遇到有不同意见的地方，我们会采用每个人认真的阐述自己的观点并指出为何别人的观点不适宜于我们的项目，而自己的观点高明在哪里。在所有人阐述完以后我们再举行民主投票，采用支持者最多的观点的方法。如果有不可调和的地方，最终一般是由组长来决定。

4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

用户量因为没发布的原因暂时还不明，用户对于重要功能的接受程度我们暂时无法得知。  这里面的经验教训就是我们在人手、资源完全不足的情况下 不应该选择一个过于宽泛的产品定位，而应该做精做好。  如果历史重来一遍，我们会认真考虑好我们的产品与类似的产品差异化的点在哪里，而不是像现在这样差异化不够明显。

计划

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

很多事情都没做完，本来大家商讨的事能够在Alpha阶段能够完成登录注册聊天定位功能的，但是定位功能并没有很好的实现。团队队员都是第一次接触APP开发，完全陌生的Android，所以最近大家都在看相关的书籍进行一定的补充，但是学习速度较慢，导致任务进度较慢，但大家都在抓紧时间努力学习中，希望接下来能够更加顺利。项目信息量大，对代码能力的要求高，知识面广，而且大多数都是我们从未接触过的，难度很大；再加上时间很短，还有其他学科的学习压力大，调整好队员们的心态也是最重要的。在做一个项目的路途中，我们最不缺的就是遇到问题，每次解决一个问题，学习一个知识点，都是一种收获。做项目不简单，但是只有我们不放弃，才能成功。

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

很多，比如Alpha冲刺阶段的每天站立式会议，老师要求的，但是并不能感觉出作用有多大，每天大家站在那都不知道该怎么些讨论。

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

因为我们的项目经验缺乏，规划不够成熟。我们经常遇到在实现代码时才发现预想的实现方法无法达到目标，需要改变策略。同时为了完善项目，网络接口也变更了多次，这导致我的前端代码在编写时变化较大，所有不是每一项都有清楚的定义。

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

没有，开始大家都很有激情的把目标定制的太高，但是能力还是有限，不能如期达到。

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

有留下缓冲区，是为了应对可能的突发情况，比如遇到一个功能需要学习一下知识才能完成的情况，或者遇到比较难改的BUG

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

设置时间点，定时定点检查功能及其成果。将来我们将会把缓冲区定义为在完成一个大的功能后留下一天的时间来回头自己查看自己编写的功能是否不慎留下了没有实现的点，又是否留下了遇到过的BUG而忘记修改了。

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

我们学到了在项目中尽量为日后可能出现的变故留出时间空间。学到了计划并不能完美地执行，过程中可能会遇到许多的问题需要重新讨论解决，如果重来一遍，我们不会过分地注重计划，而是注重过程。

资源

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

有，但是能力有限。

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

开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。

3.用户测试的时间，人力和软件/硬件资源是否足够?

时间不够，其他学科的学习压力大，导致很难达到预期目标。

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

不会，团队中的人员对这个项目都有一定的了解，就像是自己的孩子，会认真对待。

变更管理

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

是的，我们建立了一个群，有问题随时发到群里，大家都会经常查看群，看到问题都会尽快做出反应，寻找解决办法；代码使用GIT管理，大家都可以看到最新的代码。

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

功能基本上是刚开始就确定好要做哪些功能，所以都是必须实现的；我们主要根据难易程度和重要程度决定先实现哪些功能。

3.项目的出口条件（Exit Criteria）是否得到清晰的定义?

大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。

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

我们的人员比较少，大家各负责一部分，所以变更属于谁负责的那部分，谁解决。

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

这种问题我们都会先反馈到群里然后大家讨论解决问题。

设计/实现

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

是大家一起讨论出来的，大多数都是王钧任同学完成，该同学是后期开发主要任务，是合适的时间，合适的人。

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

有，比如说我们在用户名到底是用来作为登录的账号还是仅仅作为除账号以外的身份标识有了分歧。这一分歧直接导致数据库的设计和前端要求的不一致，最后我们是尽量减少数据库的修改，另外添加了一个属性达成目的。

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

我们有使用UML以及思维导图来展示我们的设计成果。这些工具很有效，能够直观的表示功能而不会出现语言上的分歧。

4.什么功能产生的Bug最多，为什么？

定位功能出现的Bug最多。还不能实现精确定位，没有找到原因。

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

我们组人手不足，所以没有能够进行代码复审，更多的是依靠测试时发现BUG并修复。代码规范执行不严格，注释的编写细致度不一致。

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

我们学到了实现时也要抽时间去整理出简洁但是描述了所有必要信息的文档。如果重来一遍我们会要求所有人都对自己的代码作出细致描述。

测试/发布

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

我们有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇胡乱测试。

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

有

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

没有

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

团队是使用人工使用来测量软件效能的，从结果来看，这些工作还是起到一定的作用的，但是效率不高，后面会考虑利用工具来实现。

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

还没有发布，不过在测试过程中有找到一些BUG

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

我们学到了测试是一个很重要的环节，因为在测试的过程中会发现开发过程中没有发现的问题。如果再来一遍，我们会事先做好测试的计划，并且准备好测试的工具。

团队的角色，管理，合作

1.团队的每个角色是如何确定的，是不是人尽其才？

团队的每个角色是根据团队成员能力，讨论而确定的。有人尽其才

2.团队成员之间有互相帮助么？

有互相帮助，互相监督，互相学习，讨论。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

如果遇到有不同意见的地方，我们会采用每个人认真的阐述自己的观点并指出为何别人的观点不适宜于我们的项目，而自己的观点高明在哪里。在所有人阐述完以后我们再举行民主投票，采用支持者最多的观点的方法。如果有不可调和的地方，最终一般是由组长来决定。

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

我们学到了团队合作中任务分配出现问题时，大家要一起沟通，一起解决，团队的力量是巨大的。如果再来一遍，老师每次任务发布会更加明确团队成员的任务，各司其职。

总结

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

我觉得团队目前的状态基本处于可重复级(Repeatable)。

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

磨合

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

团队成员分配工作更加明显，各司其职

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

能够按时完成所计划的功能需求目标，多提交代码,不拖拉，提高团队的沟通交流

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

1.业务人员和开发人员在项目开发过程中应该每天共同工作。---小组成员都是班级同学，熟悉，交流起来方便。2.以有进取心的人为项目核心，充分支持信任他们---组长及其主要编程人员都特别的热爱学习，可以带动其他团队成员。3.无论团队内外，面对面的交流始终是最有效的沟通方式---按照老师要求，天天站立式会议讨论，沟通。

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

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

名 字	角色	团队贡献分	可验证的贡献
胡丹丹	Test	19	代码测试、博客撰写
曾丽君	Test	20	代码测试、博客撰写、评论回复
王艳秋	Test	19	代码测试、博客撰写
陈 雄	Dev	19	部分代码
骆杰宁	PM	21	任务分配、部分代码
王钧任	Dev	22	主要代码