项目最终复审

团队成员简介和个人博客地址

姓名	职务	主要工作	博客地址
程志	PM		www.cnblogs.com/chengzhi
张永强	Dev	问答对的提取	www.cnblogs.com/shoumu
王莹	Dev	文档元数据抽取	www.cnblogs.com/suneony
王伟东	Dev	关键词提取	www.cnblogs.com/qq453239635
刘昕	Test	测试	www.cnblogs.com/kxkxssz

更详细的内容大家可以看：http://www.cnblogs.com/fightingsnail/archive/2012/09/22/2698234.html

关于团队项目

团队项目的目标, 预期的典型用户，预期的功能描述，预期的用户数量在哪里? 

我们组是和其它6个团队共同完成。我们组的主要目标是要为UI组提供正确的问答对和PDF文档的数据。

团队的产品如何满足了用户的需求? 要看到目标用户使用产品的过程和评价 (视频或者活人上台介绍) ?

我们在项目开始之前就和UI组协商讨论了他们需要的数据格式，并且结合我们的技术能力，确定我们最终能够做的地方。

事先定义的软件下载量达到了么? 为什么没有达到?

目前没有数据。

团队的成员如何分工协作的? 如何在两次开发里程碑中总结经验的?

团队中分为了pm,dev,test。在项目开始之前就明确了每个人的任务。在M1阶段中，我们只是最开始确定了每个人要做的大的方向，然后就是让大家来做，效果不好。在M2阶段，我们将任务细分了，每个任务要求3到5天的时间要能够完成，完成了之后，继续下一个任务。

两次开发里程碑中存在很多的问题，特别是在M1阶段中，我们暴露了很多的问题，然后M2阶段我们首先是要解决这样的问题。应该说M1阶段相当于一个标杆。对于我们组而言，M2主要是在吸取M1阶段的教训。

团队如何平衡 时间/质量/资源 争取如期完成任务的?

这一点基本上是每个人自己掌握的。团队上没有做好这一块的工作，最后如果项目不能够如期完成，那么负责这一块工作的人就需要“加班”完成。

在产品之外, 团队代码的软件工程质量如何? 如何用数据来证明?

软件工程的质量仍然不是很好。同学们主要关注的还是编码的工作。对于测试，文档规范都没有做得很好。

    a. 测试用例数目, 代码覆盖率数目,

     32个测试用例，测试项目不在统一的解决方案下建立，代码覆盖率在25%~65%不等。

 　b. 运行测试用例得到代码覆盖率的视频录像，(需要现场看到。 没有诸如 “我的电脑没有装测试环境”, “文件不全” 等等借口)

每个测试用例是针对函数中的一个分支进行测试，没有覆盖全部情况的所有测试，所以覆盖率会比较低。

例如：

　 c. 代码规范在哪里?

基本上没有。都是大家按照自己的习惯来使用。

 　d. 齐全的文档在哪里?

技术说明文档：http://www.cnblogs.com/fightingsnail/archive/2012/11/06/2756363.html

用户测试报告：http://www.cnblogs.com/fightingsnail/archive/2012/12/17/2821873.html

关键词提取：http://www.cnblogs.com/fightingsnail/archive/2012/11/09/2762514.html

团队项目的实际进展

M1阶段燃尽图

M2阶段燃尽图：

团队成员在M2 的角色和具体贡献

名字	角色	具体的，可衡量的，可验证的贡献
程志	0.5PM	主要的工作就是完成了每天的燃尽图的更新
张永强	Dev+0.5PM	代码量：M2总共1000行左右，注释：300。文档是关键词提取的文档。 0.5PM：写了一些要求的团队博客内容，给大家分配任务，确定计划。
王莹	Dev	代码量：M2总共400行左右，注释没有具体统计。文档写了数据库接口设计的文档。
王伟东	Dev	代码量：M2：450，注释：150，文档无
刘昕	Test	代码量：M2：200行左右，注释，基本无，文档：用户测试文档

所做软件最有特色的功能

能够准确地提取出问答对。关键词的数量较多。

团队从用户那里得到了什么反馈, 有什么样的bug?  这是预料之中的还是没想到的?

由于我们组的主要工作是数据的处理，然后放到UI组的数据库中，所以我们组的主要用户就是UI组了。

他们那里的反馈有：PDF的文档的数据太少。

团队和M1 相比,  在软件工程方面有什么进步?

M2的Postmortem：http://www.cnblogs.com/fightingsnail/archive/2013/01/07/2848513.html

总结

1）学到了什么：

总体上说大家在这门课上的收获还是很多的。

首先是软件工程中的一些方法，一些需要注意的事项，做好的方面大家多有了一定的了解。

第二，有具体的相关的工具的使用。整个项目是基于VSTS开发的，这套敏捷开发的方法大家在以后的学习工作中都是适用的。

第三，团队的合作、分工，我想参加到这个项目中的每一个人都会有比较深刻的认识吧。让大家说一下感觉自己的团队怎么样都会说出一大堆东西。

第四，关于软件工程以及我们的学习的思考，最后一个团队博客，可以看出大家都有这方面的思考。

2）对于这门课的批评建议：

对于这个具体的课程，现在很多学校都把这门课上成了一门背诵课。这个是最无聊的也是最不应该的地方。

相对于其它学校，我们这学期上的这门课的形式我觉得还是非常好，我非常赞同的。但是，也完全体现了在这样的一个地方开设这样的要求的课程所暴露出来的问题：

1、  同学们的意志，不是所有的同学都想做好这门课的所有工作。都想从中接收到完整的训练。

2、  整个过程我觉得还是缺少一个持续的，有效的指导。我们每周就一次时间上这门课。课上会讲相关的内容，但更注意的是结果演示。但是忽略了同学们要怎样做这些任务。如何做才能做到最好。就我们组而言，现在我们做的工作都不是我满意的，但是我还是不知道要如何更有效，更好的完成。

3、  我觉得这样的一个团队项目的设计还是有一些问题的。对于学霸这个系统，本身的初衷还是很好。但是忽略了同学们能力的影响。我自己的观点，不赞成在这门课上就做这种几个小组合作完成的项目。而应该是每个小组自己确定自己的项目。这样的话我觉得效果可能会更好一些。

4、  这门课的改革、想法都非常好，但是我们也应该注意一个具体的执行环境。