事后诸葛亮分析
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
软件要满足的是低年级学生练习四则运算的需求。需求定义得不太清楚，中途还经历了一次变更，仍然需要在这方面进行改进。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划功能并未完全实现（排行榜），此次任务，花了较多时间磨合，所以进度较慢，故交付时间有延误。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
经过这次的项目，团队成员对软件工程的理解又进了一步，主要是在团队协作以及测试方面有进步，从完全不了解到入门水平。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在用户量上我们并未取得较大进步。但是我们希望下一个版本的四则运算能够取得较大进步，新版本将整合新模式以及新注册方式，项目也将转入闭源。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
计划
1. 是否有充足的时间来做计划?
并没有，花了太少时间来进行计划，导致后期很多问题的发生。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
投票，少数服从多数
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
还没有，主要是因为时间不够。
5. 是否每一项任务都有清楚定义和衡量的交付件?
没有，仍需改进。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目途中组员认为软件需求定义不清晰，中途讨论修改了软件需求，并对软件进行了较大改动。
资源
1. 我们有足够的资源来完成各项任务么?
我们最缺的资源就是时间以及注意力。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
资源的分配主要是靠空想来决定的，精度极其不准确。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，通知非常及时。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
不影响基本功能的运行的功能皆可推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
没有考虑到。
4. 对于可能的变更是否能制定应急计划?
有，加班
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，流程清晰。
2. 是否进行了正式的验收测试？
是的。
3. 团队是否有测试工具来帮助测试？
有，使用mocha来进行测试。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据各自擅长方向来决定的，人尽其才。
2. 团队成员之间有互相帮助么？
有的，沟通效率较高。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通过小型会议来解决管理问题。
|
名字 |
角色 |
贡献分 |
可验证的贡献 |
|
塗家瑜 |
组长 |
20 |
后端代码 |
|
陈宏辉 |
队员 |
40 |
前端代码、文档 |
|
张新磊 |
队员 |
20 |
数据库 |
|
姚燕彬 |
队员 |
20 |
测试 |