事后诸葛亮分析
1. 设想和目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决查询物流信息步骤繁琐的问题。定义还算清楚。典型用户主要针对一些不熟悉淘宝等查询物流步骤的中老年人。
1.2 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的？
- 由于是第一个阶段，所以不存在上个阶段。
1.3 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 我们基本上达到了目标，计划做3个功能，在规定时间内完成了，但是预计的用户数量还没达到。
1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量也就熟悉的几个人在使用，用户对重要功能的接受程度和我们事先的预想一致，我们离目标更近了。
2. 计划
2.1 是否有充足的时间来做计划?
- 有。我们进行了好几次站立式会议以及在QQ群上做计划，所以时间还算充足。
2.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 如果有不同的意见，可以在QQ群上发表自己的意见，大家一起讨论解决。
2.3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 我们计划做的工作剩一个备注功能仍未实现，原因是时间不过。在下一阶段我们会实现这个功能的。
2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 暂时没有发现没价值的事情。
2.5 是否每一项任务都有清楚定义和衡量的交付件?
- 是的。我们在冲刺阶段初期就已经分配好了每个人的任务。
2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 基本上是根据计划进行的。项目在中途打算加几个小任务，打算添加几个leangoo的卡片，但发现这会出现错误，所以后来也删除了。没有估计到原因是不熟悉leangoo。
2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
- 有留下缓冲区，主要应对一些突发的情况。比如成员生病等不确定的因素。
2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 将来按照原先的计划进行工作，不做修改。
3. 资源
3.1 我们有足够的资源来完成各项任务么?
- 我们组虽然大腿不多，但是通过互帮互助，还是能完成相应的任务的，所以资源不多，但是够用。
3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 各项任务所需的时间一般是按照任务的难度进行预估的，像是比较难得语音输入和扫码输入就要花费较长的时间，精度不是很高。
3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试时间有点不够，如果有更长的时间，相信可以做的更好，人力和软硬件资源还是够的。
- 不需要编程的其他事情也是要花费时间和精力的，所以不能低估难度。
3.4 你有没有感到你做的事情可以让别人来做（更有效率）?
- 即使让别人来做更有效率，但是自己的工作还是要自己做。
4. 变更管理
4.1 每个相关的员工都及时知道了变更的消息?
- 我们通过qq群和微信群及时分享消息。
4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 软件本身功能并不多，不过麻雀虽小却五脏俱全，我们采用从核心功能着手，其他功能逐步实现的办法。核心功能就是从网络中的快递查询接口中获取快递信息，其他的诸如历史查询都是基于此的。关于扫码输入和语音输入是在核心功能实现后才去考虑的。
4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 基本功能可以实现
- 项目可以正常运行，无运行BUG
4.4 对于可能的变更是否能制定应急计划?-
- 无明确计划，但是出紧急情况就是PM上，能处理就处理，处理不了在通知大家一起来。
4.5 员工是否能够有效地处理意料之外的工作请求？
- 没遇到过，不是很清楚
5. 设计/实现
5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 原型设计是在做需求分析后，项目开始敲代码前做的，组员一起商量的做的。
5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 第一次做，很多情况都没遇到过，当时只能先做，比如在做界面的设计时，界面跳转和按钮的布局等等，当时没有想的全面，正在实施的时候才发现问题。前期自己挖的坑，只能后期自己填。
5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 无
5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 查询功能时和语音输入时，比较多的BUG。因为功能比较复杂，都要接入API接口，连接网上服务器，其中传输数据功能比较容易出错。因为没做过，不知道，
5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 检查代码规范
-测试功能
6. 测试/发布
6.1 团队是否有一个测试计划？
- 没有很规范明确测试计划，但有各个功能的测试计划，虽然没有文案或纸质形式
6.2 是否进行了正式的验收测试？
- 有，在项目复审时
6.3 团队是否有测试工具来帮助测试？
- Emmagee，夜神安卓模拟器，android Studio自带测试工具等
6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 通过反应时间来查看性能，帮助不大，可能是自身原因，不知道如何从测试报告上发现并改进。
6.5 在发布的过程中发现了哪些意外问题？
- 再将项目放到应用商店时，审核不通过。
7. 总结
7.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。
7.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合
7.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 确实做出东西来了，项目可运行，功能可实现
7.4 你觉得目前最需要改进的一个方面是什么?
- 功能上的完善，比如语音输入时，应该限制条件，输出只能是数字，
- 功能上的增加，单号备注功能，历史单号删除
7.5 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 以有进取心的人为项目核心，充分支持新人信任他们
PM为我们项目的核心，别人家的PM工作是指挥大部队写代码，我们的PM不仅要做一系列安排的预期规划，还要为我们做善后工作，弥补我们在进行任务缺失遗漏的，并时刻督紧进度。
- 快速反馈
面对面的交流为我们工作的共同进行加快了脚步，我们团队在开发的过程都会合理的将大家集中到一个地方，然后进行各自的任务，有不懂的地方可以直接进行交流讨论，因为有一些比较棘手而又是团队经常会出现的小问题就可以提出来，少走了很多弯路。
- 主张简单
我们团队在进行任务的分工时，先大概进行了小组成员的综合能力的评估，然后进行任务的安排，并且各自的任务有对应的侧重点，不会导致各个成员都需要摸透各种才能下手，在任务进行中如若发现任务负担过重或是过轻则适当进行调整才不会导致整个进度的滞后。
- 递增的变化
我们有一个总计划表，但不是绝对的，负责指明方向。我们还有一个个小目标和计划，用来处理每个阶段遇到的困难
8. 团队会议照片
9. 成员贡献
| 姓名 | 角色 | 可验证的贡献 | 贡献分（共6*20=120分） |
|---|---|---|---|
| 林健 | PM | 项目经理，项目主负责人，主要负责扫码输入模块和物流接口的实现 | 24 |
| 曾飞远 | 前端 | 主要负责语音输入模块的设计和博客园的撰写 | 21.6 |
| 戴建钊 | 前端 | 主要负责扫码输入模块 | 20.4 |
| 张文博 | UI | 主要负责界面和logo的设计 | 19.2 |
| 黄绍桦 | 后台 | 本地数据库建立，实现与服务器的连接 | 18 |
| 周颖强 | 测试员 | 主要负责代码测试和后期的改善 | 16.8 |