团队作业9——事后分析（Beta版本）
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要解决的是小学生通过一个比较好的方式来训练四则运算能力的问题，定义的算是比较清楚，对典型用户和典型场景有着比较清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的目标基本达到，选择题目的难度功能没有做到；按照原计划的时间交付了；原计划达到的用户数量没有达到。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
团队软件工程的质量提高了，主要是在于大家对于软件工程这一流程上的理解和合作方面有了比较大的提升，合作的更加顺利了；这是从团队合作的角度衡量的。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量没有达到我们事先预想的程度，用户对于重要功能的接受程度和我们实现预想的基本一致；我们离目标确实更近了。
计划
1. 是否有充足的时间来做计划?
做计划的时间还是相当比较充足的。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段，面对同伴之间不同意见，我们首先是相关人员之间讨论协商，如果他们都不愿意让步，我们会让各自完整地阐述出自己的想法，然后进行集体投票。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作最后并没有全部做完，没有做完的原因是时间问题，到了项目后期，各种考试以及结课项目来临，使得时间很紧。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
不是，小部分任务的临时修改和提出使得并没有这样。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目整体上基本按照计划进行，部分任务由于计划没有做好，存在临时更改和提出的情况；大家对于项目投入的精力和时间是没有提前估计到的，到了项目后期，因为各种原因，使得大家对于项目的心态不一样；没有被估计到是因为，做计划的时候把一切想的太理想了。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
在计划中没有留下缓冲区。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在将来的计划中，会尽量做到考虑的全面一些，同时留下缓冲区，加强风险管理。
资源
1. 我们有足够的资源来完成各项任务么?
有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据大家各自不同的能力来估计，精度一般。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间和人力和软硬件资源基本足够；对于不需要编程的资源确实存在低估难度的情况。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
这个问题存在两面的情况，有些人的事情交给其他人来做确实会更有效率，但是质量往往无法保证；所以在我们的项目过程中我们选择了质量保证优先，所以一些事情看起来并没有那么高效，但是质量有保证。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
对，相关人员的任何变更消息，我们都及时在讨论组做了声明。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们从系统的核心功能出发来看这个问题，如果它是核心功能，则它属于必须实现的功能，如果是外围扩展的功能，则在时间紧迫的情况下我们做了推迟处理。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
系统的核心功能和主要基本功能实现，并且不存在影响用户使用的bug。
4. 对于可能的变更是否能制定应急计划?
能，出现变更情况，我们立刻制定应急计划快速通知到相关人员，进行计划变更。
5. 员工是否能够有效地处理意料之外的工作请求？
基本可以做到。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在需求确定之后，有团队中擅长这一方面的同学来完成的，是合适的时间和合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，负责设计的同学在遇到这种情况，会向大家提出来，然后团队讨论之后做出决定。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
运用的单元测试，但是并不是很熟练。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
生成四则运算表达式的功能产生的Bug最多，因为在这个过程中需要注意到很多细节，比如除数不能为0等；在发布之后没有发现重大的bug。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由全组一起进行，是。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有。
2. 是否进行了正式的验收测试？
是。
3. 团队是否有测试工具来帮助测试？
没有。
4. 在发布的过程中发现了哪些意外问题？
没有出现意外。
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前的转台属于CMM/CMMI 中的可重复级。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得团队目前仍然处于磨合阶段，但正在越来越接近规范阶段。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
相比前一个里程碑，团队这这个里程碑中分工更加明确，合作的更加顺利，大家的集体意识和责任感都变强了。
4. 你觉得目前最需要改进的一个方面是什么?
最需要改进的还是大家整体的编程能力。
成员贡献
|
名字 |
角色 |
贡献分 |
可验证的贡献 |
|
郭达 |
队长 |
19 |
代码整合、语言选择 |
|
石浩洋 |
队员 |
22 |
PHP后台的四则运算生成 |
|
曾繁钦 |
队员 |
20 |
界面设计与优化 |
|
刘德培 |
队员 |
19 |
数据库模块与界面优化 |
|
孙斌 |
队员 |
20 |
排行榜模块 |
会议照片：
