事后诸葛亮分析
1.总结
a.项目管理之事后诸葛亮会
·设想和目标
（1）我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件要解决博客作业存在抄袭的问题；因为功能比较明确，对博客作业进行查重，因此定义比较清楚；
典型用户：老师和助教
典型场景：当前教师检查学生博客作业，以手工汇总方式来判断学生的作业质量。而手工汇总存在耗时长，工作量大，容易出错等因素。该系统将采用由机器来完成汇总计算学生作业的重复率以此来避免学生作业抄袭的现象，能明显地提高教师判断学生作业的重复率，与作业质量，并且节省教师批改作业的时间。
（2）我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
做到的功能：博客地址的导入；博客作业一对多查重，批量查重。
由于对后台与web的交互的出现了些困难，因此没有按原计划时间交付。
用户数量应该还未达到。
（3）用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
不一样，整个项目的实施过程中发现了更多的问题，感觉离目标越来越远了。
·计划
（1） 是否有充足的时间来做计划?
有。
（2）团队在计划阶段是如何解决同事们对于计划的不同意见的？
大家认为与其不断地争论某些事情有没有必要，不如做了再说。
（3）原计划的工作是否最后都做完了? 如果有没做完的，为什么?
有些没做完。有些情况下，大家查询资料花费了很多时间。
（4）有没有发现你做了一些事后看来没必要或没多大价值的事?
沟通方式不对，效率不高，拖延症。
（5）在计划中有没有留下缓冲区，缓冲区有作用么?是否每一项任务都有清楚定义和衡量的交付件?
有缓冲区，是有用的，因为实际完成的时间>预估时间。有进行交付，但是各人进度不一，有些模块不断地有一些小问题，花了很长时间才能做好。
（6）将来的计划会做什么修改？（例如：缓冲区的定义，加班）
给出适当的缓冲时间，但是要增加工作效率，防止加班情况的发生。
·资源
（1）我们有足够的资源来完成各项任务么?
没有。
（2）各项任务所需的时间和其他资源是如何估计的?
开会讨论，大家提出相对应所需的时间，综合考虑得出。
（3）测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
相对足够。美工方面打算在beta版本逐步完善。
（4）你有没有感到你做的事情可以让别人来做（更有效率）?
有，也许别人的技术或者沟通比我们更好，会更有效率。
·变更管理
（1）每个相关的员工都及时知道了变更的消息?
有的时候变更消息不够及时通知，沟通不够。
（2）我们采用了什么办法决定“推迟”和“必须实现”的功能?
基础功能必须实现，强化功能根据技术水平决定是否适当推迟。
（3）项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
运行时没有明显bug，不会出现404错误，能够进行基本的查重功能，计算出博客作业一对多的重复率。
（4）对于可能的变更是否能制定应急计划?
没有制定紧急计划，根据实际情况及时调整。
（5）员工是否能够有效地处理意料之外的工作请求？
比较困难，要根据时间的松弛程度来决定，如果自身工作结束可以适当处理。
·设计/实现
（1）设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在实现功能之前，由小组一起讨论出基本模板，web界面负责人完成实现。
是合适的时间、合适的人。
（2）设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到，团队成员一起出来开会讨论，具体情况具体分析解决。
（3）团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有用TDD。有效，能够快速的对一个单元模块进行有效测试。
（4）什么功能产生的Bug最多，为什么？
主要是前端和后台的接口问题，因为对于web开发充满困难。
（5）代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
将代码传到coding上，大家一起看。有执行。
·测试/发布
（1）团队是否有一个测试计划？为什么没有？
有。
（2）是否进行了正式的验收测试？
有。发给助教使用，但测试没有通过。
（3）团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
有用到TDD，有用，没有发现什么bug。
（5）在发布的过程中发现了哪些意外问题？
跟用户的实际需求有偏差；没有购买服务器，tomcat不稳定。
·团队的角色，管理，合作
（1）团队的每个角色是如何确定的，是不是人尽其才？
团队的角色是根据团队成员编写代码的能力确定的，大家都尽力去做。
（2）团队成员之间有互相帮助么？
成员间有互相帮助。
（3）当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队间会沟通协调，决定出大多数人同意的意见，虽然花费的时间会有点多，但是会协调好。
（4）对成员帮助的感谢
a.王婧：在这里我感谢钱惠同学对我的帮助，因为在用户需求的分析上，帮助我们做好了方向，以及功能的整合上对我们团队有很大的帮助。
b.柯怡芳：我感谢陈艺菡同学对我的帮助，因为在我对系统设计比较不清楚的时候，主动帮助我，向我说明，并且经常帮助我完成博客内容。
c.陈艺菡：我感谢柯怡芳同学对我的帮助，因为项目进展的协调和沟通，原型设计的改良。
d.钱惠：我感谢王婧同学对我的帮助，在alpha版本中 我负责查重模块，在我遇见瓶颈时，她与我耐心积极沟通，并给我具体的支持。
e.尼玛：我感谢钱惠同学对我的帮助，因为我们这个项目中我的分工是访问客户的需求这方面，所以其他的我有很多不懂的，然后很多关于项目里查重的问题我都不懂，而且有时客户的好多问题我都不怎么了解，所以我都问她，她帮我解决有关我不懂得地方。
f.林凯：我感谢柯怡芳同学对我的帮助，因为她在我无法预期完成我的任务的时候，及时协调跟进，为我提供足够的时间。
总结:
（1）你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于基本级。
（2）你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于规范阶段。
（3）你觉得团队在这个里程碑相比前一个里程碑有什么改进?
大家更加熟悉了，合作更加顺利了。
（4）你觉得目前最需要改进的一个方面是什么?
团队沟通不够，不能较好的利用时间，效率较低。
（5）对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例
我们小组做的最好的是“以有进取心的人为项目核心，充分支持信任他们”与“保持简明--尽可能简化工作量的技术--极为重要”，对于团队成员，我们都有充分的信任与支持，对于团队的工作也尽量的简明扼要。
b.照片~
2.团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
| 王婧 | 开发人员（后台） | 21 | 编写查重功能以及前端与后台的接口 |
| 柯怡芳 | PM | 19 | 跟进任务，编写博客 |
| 陈艺菡 | 开发人员（后台） | 21 | 编写导入博客地址功能，编写博客 |
| 钱惠 | 开发人员（后台） | 22 | 编写查重功能，整合导入和查重功能 |
| 尼玛 | 测试人员 | 18 | 进行需求分析以及测试 |
| 林凯 | 开发人员（前端） | 19 | 编写web界面以及前端与后台的接口 |