团队作业6——事后诸葛亮分析报告（Vitamin C）

[张琳英]

目录

目录

• 目录
• 作业详情
• 一、设想与目标
• 1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
• 1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
• 1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
• 1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？
• 1.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进？
• 二、计划
• 2.1 是否有充足的时间来做计划？
• 2.2 团队在计划阶段是如何解决成员对于计划的不同意见的？
• 2.3 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么?
• 2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?
• 2.5 是否每一项任务都有清楚定义和衡量的交付件?
• 2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
• 2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
• 2.8 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 三、资源
• 3.1 我们有足够的资源来完成各项任务么?
• 3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
• 3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
• 3.4 你有没有感到你做的事情可以让别人来做（更有效率）？
• 3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
• 四、变更管理
• 4.1 每个相关的员工都及时知道了变更的消息?
• 4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
• 4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
• 4.4 对于可能的变更是否能制定应急计划?
• 4.5 员工是否能够有效地处理意料之外的工作请求？
• 五、设计/实现
• 5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
• 5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
• 5.3 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
• 六、测试/发布
• 6.1 团队是否有一个测试计划？为什么没有？
• 6.2 是否进行了正式的验收测试？
• 6.3 团队是否有测试工具来帮助测试？
• 6.4 在发布的过程中发现了哪些意外问题？
• 6.5 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 七、总结
• 7.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
• 7.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
• 7.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
• 7.4 你觉得目前最需要改进的一个方面是什么?
• 八、讨论照片
• 九、团队成员在Alpha阶段的角色和具体贡献

作业详情

作业所属课程	软件工程
作业要求	团队作业6——复审与事后分析
作业目标	Alpha阶段项目复审（单独一篇博客）、事后诸葛亮分析报告（单独一篇博客）

一、设想与目标

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

A： 我们要解决的问题是要让我们的目标用户：学生和教师使用该软件时能尽可能的简单而又清晰，无论是学生测试单词拼写还是教师查询成绩。定义得很清楚。对典型用户和典型场景有清晰的描写

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

A:部分目标未能实现，如当以老师身份登录后，可以给其所管理的班级布置作业的功能。基本功能都以实现并按时交付了。原计划达到的用户数量也达到了。

1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

A： 和上一个阶段相比提高了。在代码的后期扩展性和维护性提高了不少，代码结构清晰明确，便于以后增加功能或修改

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

A： 基本一致，用户对核心功能基本满意，离最终目标更进一步

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

A: 时间安排不够合理，预期与现实实际相差较大，未考虑技术基础，计划赶不上变化；如果历史重来一遍，前端方面可以做的更好。

二、计划

2.1 是否有充足的时间来做计划？

A：在时间上是比较充足，但是每名队员都有自己的学习规划，因此需要先进行队员讨论和分工。

2.2 团队在计划阶段是如何解决成员对于计划的不同意见的？

A：通过开展团队会议，就不同意见的讨论、分析，最后达成共识。

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

A： 原计划工作大部分已经完成，但仍有一小部分功能没有完善好，原因是队员们对于相关页面渲染技术涉猎较浅，经验不足。

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

A：没有，在项目开始前已经对要做的事情进行分析。

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

A： 是，基本都具有一定价值

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

A： 基本按照计划进行，意外是在项目开发时会出现较多bug，需要队员间相互检查解决。没有预估到风险是由于缺乏项目经验以及对本团队开发人员的技术水平考虑不全。

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

A：有预留缓存区，缓冲区可以有效保证项目按期完成。

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

A：我们学到了相关的编程经验和相关文档编写能力，学到了团队合作、制定计划的相关知识。
改进：针对出现的问题需要队员间调用积极发言。

三、资源

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

A： 项目的各项任务基本已经完成，在项目开发过程中队长提供了项目的初始命令行版本（用C++编写），利用已有资源和队员们的编程能力和文档归纳编写，我们基本完成各项任务。

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

A：主要是根据任务的难易程度，所实现功能的复杂度来分配时间，精度一般。

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

A：对于测试的资源，人力/软件/硬件资源足够，对于不需要编程的资源，没有低估其难度，对于存在的疑问队员讨论加以解决。

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

A：有，因为队员的技术栈可能并不相同，所学技术的应用实践能力强弱不同，因此，需要团队在计划任务分工时一定程度地考虑了队员技术栈、时间等相关因素。

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

A:首先，在项目开始之前可以提前了解各位队员之后的时间安排以及所学技术，以便于后面进行更好的分工合作；其次，对于在项目开发过程中所出现的问题，队员间讨论难以解决，应当主动请教周围老师和同学，提高自己的学习和开发效率。

四、变更管理

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

A:每个成员都及时了解到项目的进展和、变更及阶段效果。

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

A:我们采用面对面开会及微信群讨论的方式决定，由于我们的项目是智贤同学高中时期自己的项目，功能上已有一些计划与部分实现雏形，所以基本经过开会及讨论可以确定往后的大概项目进程。

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

A: 当改程序可以完成所有功能完善及测试即“做好了”。

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

A：事先有对一些较为复杂的功能有计划，比如单词测验和成绩那块有些字段是可能需要，后续经过开发对其进行了优化。

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

A：都可以，大家相互帮忙，不懂的地方都积极提问讨论，经过讨论及资料查阅，很快可以化解问题。

五、设计/实现

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

A：设计工作是在第一次集体会议的时候大家集体决定的。是在空闲时间 对某些技术比较熟悉的人完成相应模块。

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

A：有，把问题在集体会议中提出来，一起讨论应该怎么解决，最后确定方向。

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

A：单词测试功能BUG最多，因为当时设计的时候不够细心。发布之后没有暂时发现重要的BUG。

六、测试/发布

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

A:有，在项目安排里就有测试计划，这样子才能让项目更加完整。

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

A：对几个主流的浏览器进行了各个功能的验收测试

6.3 团队是否有测试工具来帮助测试？

A：有

6.4 在发布的过程中发现了哪些意外问题？

A：没有。

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

A：测试对于一个项目产品来说格外重要，它能更好得展现出我们平时没有发现的bug，可以避免不好的用户体验以及用户隐私泄露等问题。以后可以采用测试工具帮助测试。

七、总结

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

A：2级

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

A：萌芽

7.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

A：凝聚力更强了，大家之间的交流也更有效率了

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

A：对未来功能的扩展以及HTML页面的设计

八、讨论照片

九、团队成员在Alpha阶段的角色和具体贡献

姓名（学号）	角色	贡献分	可验证的贡献
林智贤（3120004933）	后端开发	20	后端开发
林俊宇 (3119000392)	后端开发	20	后端开发
马佳武 (3120002439)	前端开发	16	博客编写、前端开发
何智勇 (3120005337)	测试	8	测试
苏松炜 (3120005354)	后端开发	20	后端开发
张琳英 (3220005324)	博客编写	8	博客编写
孔家振 (3120005385)	页面设计	8	博客编写