团队作业9——事后分析（Beta版本）

事后诸葛亮分析

---

设想和目标

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	测试