团队作业9——事后分析（Beta版本）

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
　　我们的软件叫博客作业采集系统，主要的服务对象和是老师，用于解决老师收集博客作业比较麻烦的问题。通过对学生博客信息的采集达到较为简单和方便的收集学生的作业完成情况。由于目的明确，用户也只有老师一类，所以用户需求较为清晰。

是否有充足的时间来做计划?
　　介于课程原因还有考研、实习等额外因素的影响，实际用于项目上的计划时间较为仓促，很多计划都是匆匆定下来的，在之后时间较为充裕之后才开始慢慢查缺补漏，最后也终于顺利完成项目。总的来说时间是比较赶的，用于计划的时间也不够。

团队在计划阶段是如何解决同事们对于计划的不同意见的？
　　我们团队的成员都是大学的舍友和相邻宿舍的人，彼此之间比较熟悉，计划产生不同意见时，讨论讨论就解决了，并不会出现什么意外情况。

用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
　　用户（即老师）有评价过我们的这个项目，在整体上来说，用户对于我们这个项目的接收程度还是比较满意的，跟我们的预想情况也差不多，算得上达成了目标了。

计划

你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
　　在整个的功能模块是基本完成了，主要的功能全部都实现，只是有一些辅助功能还有一些关于页面上的处理方面并没有完成，这其中一部分原因是由于时间上的限制，还有其余一小部分原因则是涉及到了我们的能力问题。

有没有发现你做了一些事后看来没必要或没多大价值的事?
　　我们团队是按照功能块去进行代码的编写的，所以并没有一些没必要的事。至于那些功能是否有价值的问题，那应该由用户来决定。

是否每一项任务都有清楚定义和衡量的交付件?
　　实际上对于每项任务的定义和衡量都是比较模糊的，只是大体方向上的，主要原因还是实施的情况很可能与预想的不同，所以并没有清楚的定义和衡量。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
　　项目的整个过程实施情况还是较为艰辛的，不过还是按照计划在进行，意外情况倒是没有，如果要说风险的话，那就是服务器在中途有出错了一点时间，原因到现在都不大清楚。

在计划中有没有留下缓冲区，缓冲区有作用么?
　　计划上是有的，不过实际上并没有。

将来的计划会做什么修改？（例如：缓冲区的定义，加班）
　　将界面更加优化，然后尽量的简化用户操作。

资源

我们有足够的资源来完成各项任务么?
　　我们的团队成员有4个，总的来说还是有足够的资源完成各项任务的。

各项任务所需的时间和其他资源是如何估计的，精度如何?
　　按照我们大概的能力范畴，然后初略的进行估计的，精度比较不准确。

测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
　　人力和软件/硬件资源是足够了，不过在页面设计这一块上，我们并没有擅长前端的小组成员，所以在进行前端设计时，还是比较困难的。最开始已经认为页面的设计是一大难题，但没想到比预想的糟糕。

你有没有感到你做的事情可以让别人来做（更有效率）?
·　　这倒是没有，小组的任务分工还是挺合理的。

变更管理

每个相关的员工都及时知道了变更的消息?
　　在变更的第一时间就会通知各个组员。

我们采用了什么办法决定“推迟”和“必须实现”的功能?
　　由团队探讨决定。

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
　　项目的目标较为明确，所以定义是否做好了也比较清晰。

对于可能的变更是否能制定应急计划?
　　项目变更需要让团队成员添加额外的目标，我们会通过讨论，快速地制定计划，然后将任务进行分配，完成变更的目的。

员工是否能够有效地处理意料之外的工作请求？
　　除了那些超过自身能力范畴的工作请求，其余的还是可以的。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
　　设计工作在选定项目后的两周内，由团队成员共同讨论，时间上来说还是比较合理和充足的。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？
　　并没有遇到之类情况，不过如果有，我认为应该从用户角度和团队能力这两方面考虑具体的情况。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
　　有使用这些测试和工具，对我们团队进行项目开发有很显著的作用。

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
　　爬虫拉取学生博客信息产生的bug最多同时也是最重要的bug，主要是因为博客园的用户页面设计有好几种，要按照这几种去分别进行页面采集。在最开始设计的时候，没有想到博客园的用户界面设计这么奇怪，估计是多个人设计的页面，在后来测试拉取的时候才发现并解决。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
　　按照自己审核，总的来说还是执行了代码规范的。

　　 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　　　 学到了计划的重要性。重来一遍的话会先尽可能的先了解可能会出现的bug，只有在开始时就解决了各类bug才能更快地进行项目开发。

测试/发布

团队是否有一个测试计划？为什么没有？
　　有是有，不过最后没有时间去实行。

是否进行了正式的验收测试？
　　依据功能进行了正式的测试。

团队是否有测试工具来帮助测试？
　　运用了JUnit进行测试。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
　　按照功能是否实现和实现时间来决定效能。测试工作还是有很大的帮助的，帮助我们排除了一些bug。

在发布的过程中发现了哪些意外问题？
　　在爬虫获取博客园的用户数据出了一些问题。

总结

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

达到CMMI中的三级，定义级别

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

规范阶段。

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

团队的凝聚力更加的强大，对于任务的分工更明确。

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

提高我们自身的编码水平。

我们小组什么地方做的比较好？

在团队合作方面很成功，每个人都各司其职，中途完全没有出现团队人员进行争吵等问题。

下个阶段需要改进什么？

需要在效率上进行改进。

名字	角色	团队贡献分	可验证的贡献
许猛棕	组长	25%	博客爬虫bug修复
陈志钦	组员	27%	主页设计、博客排序
雷源城	组员	24%	博客编写、博客搜索
宋浩	组员	24%	功能完整测试、修复bug