M2事后会议报告

设想和目标

---

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

　　Beta阶段的爬虫需要更稳定、更高效、操作更便捷。在定义中爬取对性能和功能的要求高，典型用户和场景的描述较为清晰。

　　2. 是否有充足的时间来做计划?

　　有一周的时间来进行计划，这个时间还是很充裕的。

　　3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

　　与Alpha阶段不同，因为Alpha阶段大家对于计划还不太熟悉，最后都会听从PM。这次迭代中我们意见相左的次数较多，经常会有争论，最后听从争论结果。

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

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

　　我们组安排了一名成员专门进行爬取动作。虽然其积极性不是很高，但是最终也能接近预想。如果历史重来，我们会更重视爬取动作，在实际爬取的过程中去发现问题，而不是一味地依赖单元测试和代码修改。

计划

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

　　原计划的工作最后都做完了，还额外实现了一些功能。但是主要计划工作最终的结果略显粗糙，达不到设想的目标。一方面是因为在最后的开发阶段遭遇数据库和编译课设及考试的轮番出击，另一方面是在Beta阶段后期我们的时间规划出现了较为严重的问题。

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

　　Beta阶段的工作计划都是根据Alpha阶段遗留的较为严重的问题所设计的。

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

　　有。迭代二把每项功能的开发任务都分为三个阶段，每个阶段都有完成的衡量标准。例如在异常清理器的第一阶段需要能够准确定位数据库或文件的异常的错误信息并显示出来。

　　4. 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?

　　数据库和编译的大风浪让我们猝不及防。因为当时没用想到这两项科目的任务会这么紧张。

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

　　周日是我们小组成员自由工作的缓冲时间，能够减轻一下压力。

　　6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

　　将来我们组还会有合作的机会吗。我们需要请教一下其他小组，参照一下他们的计划设定。

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

　　要充分做好风险的评估工作，不能像这样被编译和数据库弄得措手不及；

　　规划好时间，当时我们小组就是认为时间很充分，结果在一段时期工作成果不理想。

资源

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

　　资源不尽人意，由于我们的项目对网速的要求较高，但是服务器上的网页访问奇慢无比。所以我们大多数还是通过数据库连接用PC爬取的。希望能够改善一下服务器的网页访问速度。

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

　　每项任务的时间根据成员能力和任务难度来定，一般成员一天任务时间不会超过三小时。

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

　　测试伴随这开发进行，这一阶段我们在测试方面较为理想，充分做了单元测试，但是后期由于时间的仓促，没有制定系统性的测试计划，整个系统的测试做的并不是很好。

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

　　不同的人做事有不同的特点，效率上可能有差别，但是在某一方面也许会凸显优势。

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

　　不再应所剩的时间丰富而降低了开发的速度。

变更管理

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

　　是的，每个成员编码前都要获取最新版本。

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

　　根据每周阶段性总结会议的讨论和与数据处理小组协商他们的需求。

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

　　定义较为清晰，主要有3点要求：

　　1.更稳定地爬取：线程池

　　2.更高效地爬取：动态爬取

　　3.更健康地爬取：异常清理

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

　　一般如果有突发情况，都是由包括PM的个别成员熬夜完成。

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

　　可以处理。例如连接数据库的各种权限问题，成员能自行登录服务器进行权限的分配。

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

　　更规范地使用TFS。

设计/实现

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

　　设计工作是在迭代一开始的一周时间里。通过小组讨论，最终由PM和主DEV共同完成。

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

　　Beta阶段的工作计划都是根据Alpha阶段遗留的较为严重的问题所设计的。

　　3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

　　运用了单元测试，主要在开发阶段的两周里进行测试，边开发边测试。单元测试能够从最底层帮我们发现问题，不至于到系统测试时还需要排查测试问题出现在什么地方。

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

　　解决了线程问题之后产生BUG较多的就是多台电脑工作操作数据库的情况了。发现这一BUG的时间比较晚，目前已经没有时间再调试了。所以Beta阶段的爬虫只能由一台电脑进行爬取动作，否则有可能产生数据库方面的BUG。

　　5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

　　迭代二阶段的代码复审分为两部分，第一部分是开发人员自主复审，第二部分向PM进行复审报告，由PM进行第二次复审。

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

　　重视代码规范和系统性测试，以防对BUG措手不及。

测试/发布

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

　　测试计划是较为完善的，计划要求对功能性、可靠性、可使用性、安全性和性能进行测试，并给出了测试基本要求。

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

　　是的。最终进行大数目的爬取测试，达到了验收的数量。

　　　

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

　　Junit。

　　4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

　　与上一版本的爬虫进行了单次最大爬取数目和单位时间爬取数目的比较，从运行结果来看，新版本的爬取性能更优。

　　5.在发布（部署）的过程中发现了哪些意外问题？

　　缺乏种子URL导致爬取的ppt、doc数目较少。

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

　　重视种子URL的收集。

总结

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

　　CMMI。

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

　　规范。

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

　　1.计划更充分：开发计划和测试计划。

　　2.态度更积极：更多的成员参与到开发工作中。

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

　　PM对基础每日工作的统筹、监督和交付评定。