事后诸葛亮

设想和目标

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

帮助解决福大学生遇到的各种疑问，定义的算是清楚，有

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

并没有达到目标，原计划的功能大概完成了百分之七八十左右，现在还只是Alpha阶段，还没有交付时间。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

现在完成的内容和预想还有所偏差，主要功能实现还有问题，当然离目标更近了。

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

设想的很美好，现实很骨感，在我们设想的初期想了很多可以加的内容，刚开始想的时候比较有激情，高估了自己，想到什么功能都一直往上加，然后后面在完成的过程中，发现实力跟想法相差悬殊，很多都舍弃了，没有开发经验，太天真。
如果历史重来一遍，会根据自己的实际能力去设想一些功能，不要是太复杂的那种，否则既耗时耗力了，又没有什么成效，这样对项目进度有很大的影响。

计划

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

时间肯定不会充足，没有人会觉得时间太多。在平时还有其他的课程要上，也不能把所有的时间都投入给软工实践，加上是第一次进行项目开发，所以我们的计划就不是很细致也不完善。

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

对于计划的不同意见，有进行相关的讨论分析，如果有反对意见会再进行商量，然后看情况整改。

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

没有。
一开始的分工没有特别明确，没有将功能模块分配到个人，每个人都集中在同一个模块，导致项目卡壳的时候每个人都没有什么新的进展了，没有经验，要花费的时间太多，一边学习一边做，一直有问题的时候激情就少了很多，进展就慢了，使很多原计划的工作没时间可以完成。

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

现在暂时没有吧。

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

定义的不是很清楚，一开始划分的任务都是一整个模块的大任务，没有细化到小版块，而每个人负责的也比较模糊，通常都是在完成的过程中才进行分配。

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

没有按照计划进行，计划的完成时间和实际的完成时间不一致，导致很多原定计划不得不推迟或者舍弃。andriod的页面跳转有点问题。风险现在还暂时没发现。

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

没有，课业太多，一般的时间都是在晚上，也没有其他空余时间可以挤出来了。
缓冲区可以在一些意外发生的时候减少对实际进度的影响。

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

可以增设计划缓冲区，然后将计划的分工内容细致一下。

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

一个良好的项目计划是很重要的，这样项目的执行过程也会更加有条不紊，有效率。
如果历史重来一遍，将对计划表做更详细的规划，分配好每一个环节，以及每个人负责的模块，每个人完成自己的模块后再进行整合改进，就不会出现一个环节停滞，所有人都一起停滞的现象了。

资源

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

现在任务量还比较小，资源还是够用的。

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

按照任务的分类来估计，如果是同一个模块相似内容用时就估计少一点，但是由于我们是Learning by doing，在某些任务上就经常会遇到瓶颈卡壳了，一开始是估计每天平均完成三四个任务这样的，但是现实却是有些任务花费了两三天研究才解决，或者还未解决，所以在各项任务时间的估计上精度不是大。

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

现在还没有进行测试，感觉人力上还是不够的，没有更加专业的人员，大家都是从起点开始一边学习一边完成的，力量还不是特别大。还好吧。

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

团队成员现在拥有的能力还是不够的，如果让能力更强的人来做，当然会更有效率。

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

合理分配好每个人力资源。

变更管理

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

有团队的群聊，消息传送很方便，如果是重大的变更，会讨论研究让每个相关人员都知道，如果只是一些细小的，只有负责该模块的人知道。

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

看功能的复杂程度，按照项目的计划安排，一般从使用app的习惯顺序来进行功能实现的排序，决定必须实现的功能，如果是一些比较复杂的模块，这个阶段感觉来不及完成的，就推迟了。

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

emmmm，没有清晰的定义，觉得实现的功能和预想的差不多，然后在测试环节没有什么出错，就感觉做好了吧。

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

尽自己所能制定。

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

经验不足，不能有效处理，耗费的时间较多。

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

在项目的完成过程中，肯定会发生一些意外，不得不对项目某些模块进行变更，但是处理却不够有效率。会先预想有什么可能发生的变更，制定相应的应急计划。

设计/实现

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

在项目开始的初期，由团队成员分工共同完成，要先设计再实现功能，所以时间应该合适吧，因为都是新手，所以合不合适还需要时间磨合。

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

没有遇到什么比较模棱两可的情况

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

还没有运用单元测试和测试驱动的开发。有利用UML帮助设计，将设计都梳理了一遍，但是在开发的过程中也很少利用它了，通过安排表完成任务更加清晰一些。UML文档没有什么变化。

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

现在功能内容还比较少，产生的bug主要是数据显示上有问题，代码方面有问题，在研究中。

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

现阶段还没有进行代码复审，代码规范上每个人都有自己的编码习惯，没有在一开始就制定严格的代码规范。

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

在实现的一开始就要制定严格的代码规范，在之后的整合过程中才能避免出现更多问题。

测试/发布

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

现在还没有测试计划，因为项目还没有开发完全，就没有去想测试的事情。

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

没有

团队的角色，管理，合作

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

是在项目开发过程中慢慢确定的，边学边做，谈不上每个人有什么特别的才。

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

有的

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

分析问题，然后进行讨论，看问题出现的原因，商议后共同解决问题。

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

分配好每个团队成员的角色，对每个人的任务有清晰的定义，让项目的分工更加明确，才能更好的进行，加强沟通和交流。

总结:

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

CMM

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

磨合

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

团队每个成员的分工需要更加细致一些。

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

1、以有进取心的人为项目核心，充分支持并信任他们

我们的组长非常有进取心，我们非常支持信任她，组长经常用她的进取心来感染我们，鼓励我们继续前行！

2、无论团队内外，面对面的交流始终是最有效的沟通方式

在项目的开发过程中，我们每一天都有进行面对面的沟通交流，了解每一个成员所遇到的问题，并一起解决。