事后诸葛亮分析

1.总结

a. 项目管理之事后诸葛亮会

·设想和目标

（1）我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
博客查重系统，旨在帮助老师和同学们对自己写有的博客和其他同学的博客进行比较，获得重复率，囊自己老师对学生博客是否抄袭进行判断。方便同学对自己的博客与他们博客的重复进行比较，造福广大学子。

（2）我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
原来我们计划实现1对1，一对多，多对多的博客查重功能，目前完成了一对多和多对多这两项功能，虽然还存在一定的瑕疵，但已经是我们共同努力的结果。博客查重功能旨在帮助老师和学生两个群体，但同学好像并不依赖博客查重的功能，可能是我们对于博客查重的实现还存在问题。

（3）用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
不太一致，由于我们提供的功能不够全面，加之查重功能的实现存在一定的瑕疵，比如：查重过程比较慢，博客抓取下来的数据在后台需要手动清理，如果未能及时清理，会对查重效率造成比较大的影响；（有什么经验教训）由于我们自身编程水平有限，一些预想的功能的实现由于自身能力的限制未来得及实现。（如果历史重来一遍，我们会有什么改进？）主要是希望能让用户用起来更加的简单快速和方便吧。我们虽然对博客查重的功能有实现，但提供给用户使用时由于各种不便运行缓慢导致口杯不好吧。

·计划

（1）是否有充足的时间来做计划?  
有足够的时间来做计划，万事开头难，一个科学合理的计划对我们的项目顺利的进展是很有利的。

（2）团队在计划阶段是如何解决同事们对于计划的不同意见的？
在团队计划阶段各个小伙伴对项目有各自的理解是一种正常的现象，这也表明每个组员对项目都是负责的都希望可以高效地做好这个项目，因而对与组员提出的不同的意见我们是采取积极响应的态度，共同商量采取对项目实现最优的方案。

（3）你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作量没有完全的完成，因为时间以及组员能力有限的情况下，还不能十分完善项目。

（4）有没有发现你做了一些事后看来没必要或没多大价值的事?
在整个项目施行的过程中，确实有许多低效的事，但这并不能说是没有价值的事，即使花了很多的时间也没有做出一个功能，但在其过程中还是多多少少有学到一些东西的。即使是失败了还是有些许收获或者是经验的。

（5）是否每一项任务都有清楚定义和衡量的交付件?
在每周的小组会议中我们对每项任务的分工以及交付时间都是有清楚的定义的。

（6）是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整体来说最基本的功能有实现，但是我们做的还不够完善，我们有些好的点子便于用户使用的想法没有实现，一些举得简单的功能，在实现的时候才发现并不容易。

（7）在计划中有没有留下缓冲区，缓冲区有作用么?
在计划的过程中有留下缓冲期，如果时间进度太赶的话，而在实践的过程中遇见瓶颈时，这将会影响明天的进度。所以缓冲期还是必要的。

（8）将来的计划会做什么修改？（例如：缓冲区的定义，加班）
先对大体的进度有个粗略的计划，详细分工，安排合理时间的缓冲区。

改进：对与需求分析的理解组员们需要一致，分工之后，组员间还是需要时不时的交流互动一下过于代码衔接的问题。

·资源

（1）我们有足够的资源来完成各项任务吗？
团队人数上来说是足够的，但由于大三比较忙碌加之能力有限，所以可能从时间上来说我们没有规划的很好，其他方面，还OK吧

（2）各项任务所需的时间和其他资源是如何估计的，精度如何？
由于是第一次合作，对于团队方面的问题上大家的经验都是有所欠缺的，时间上安排起来精确度不高吧，普遍是以一天两天为单位完成任务

（3）测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源，是否低估难度？
足够吧；没有低估难度。

（4）你有没有感觉你做的事情可以让别人来做（更有效率）？
这种感觉不存在的吧，我们都是各司其职吧，互相帮助，尽量发挥各自的长处。

·变更管理

（1）每个相关的员工都及时知道了变更的消息?
因为大家都是一个班的，而且现在通信都很发达，所以变更的消息传播得很快，大家都能及时知道

（2）我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们在QQ讨论组或者开临时性战略性会议的时候决定，采纳占大多数人同意的意见

（3）项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
没有得到清晰的定义，我们定义得比较模糊

（4）对于可能的变更是否能制定应急计划?
能，对于变更，我们通常通过讨论组进行协商，基本都能根据所学只是重新安排人员编写，部分地方则会“扬弃”——即砍掉部分功能或加强部分功能

（5）员工是否能够有效地处理意料之外的工作请求？
可以的，额外的任务根据组员的特长分配任务，所以对于组员来说都是比较轻松有效率的

·设计/实现

（1）设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在实现功能之前，由小组一起讨论，web界面负责人完成实现。
是合适的时间、合适的人。

（2）设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到，团队成员一起出来开会讨论，具体情况具体分析解决。

（3）团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有用TDD。有效，能够快速的对一个单元模块进行有效测试。

（4）什么功能产生的Bug最多，为什么？
主要是查重功能，因为对于开发充满困难。

（5）代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
将代码传到coding上，大家一起看。有执行。

·测试/发布

1.团队是否有一个测试计划？为什么没有？
我们团队有测试计划，所以测试人员都能根据目的测试所需项目，这样阶段测试和后期测试都能清晰的明白

2.是否进行了正式的验收测试？
没有正式的验收测试，但是组员有合作尝试运用调试

3.团队是否有测试工具来帮助测试？
有的，能够解决一些常识引起的bug，减少了人力，提高了效率

4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
主要是通过人员检测，实际效能和预期效能决定性能；测试工作还是很有帮助的，就是后期应该多借助点测试软件帮助可能会提高效率

5.在发布的过程中发现了哪些意外问题？
部分功能不能在不同机器上不能正常运作，没能达到预期目标，存在bug

·团队的角色，管理，合作

（1）团队的每个角色是如何确定的，是不是人尽其才？
团队的角色是根据团队成员编写代码的能力确定的，大家都尽力去做。

（2）团队成员之间有互相帮助么？ 
成员间有互相帮助。

（3）当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队间会沟通协调，决定出大多数人同意的意见，虽然花费的时间会有点多，但是会协调好。

（4）对成员帮助的感谢
a.王婧：我感谢陈艺菡同学对我的帮助，因为在对她负责的代码上，她进行了详细的注释与讲解，有利于我们加快对项目算法部分的理解与使用。

b.柯怡芳：我感谢陈艺菡同学对我的帮助，因为在我对系统设计比较不清楚的时候，主动帮助我，向我说明，并且经常帮助我完成博客内容。

c.陈艺菡：我感谢王婧对我的帮助，在代码复审和bug修复的讨论方面。

d.钱惠：我感谢王婧同学对我的帮助，在我遇见瓶颈时，她与我耐心积极沟通，并给我具体的支持。

e.林凯：我感谢柯怡芳同学对我的帮助，因为她在我无法预期完成我的任务的时候，及时协调跟进，为我提供足够的时间。

f.吴伟君：我感谢柯怡芳同学对我的帮助，在对软件测试方面提供基本常识方面的工作。

·总结:

（1）你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于可重复级。

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

（3）你觉得团队在这个里程碑相比前一个里程碑有什么改进?
大家更加熟悉了，合作更加顺利了。

（4）你觉得目前最需要改进的一个方面是什么?
大家时间不能好好地利用，会浪费在一些零零碎碎的事情上。

（5）对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 
我们小组做的最好的是“以有进取心的人为项目核心，充分支持信任他们”与“保持简明--尽可能简化工作量的技术--极为重要”，对于团队成员，我们都有充分的信任与支持，对于团队的工作也尽量的简明扼要。

b.照片

2.团队成员在Beta阶段的角色和具体贡献

名字	角色	可验证的团队贡献	团队贡献分
王婧	开发人员	编写多对多查重功能	21
柯怡芳	PM和编辑博客	跟进任务和编辑博客内容	20.5
陈艺菡	开发人员）和编辑博客	完善web界面以及编辑博客内容	22
钱惠	开发人员	编写多对多查重功能	19.5
林凯	测试人员	进行测试	19
吴伟君	编辑博客	编辑博客内容	18

#项目复审 http://www.cnblogs.com/rgxz/p/6960966.html