• 设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们组要爬取网上的内容供下一组使用，定义的不太清楚，因为用户只有下一个团队所以没有进行详细的需求分析,而且和下一个团队做的交流也有限，没有及时得到下个团队的需求反馈。
2. 是否有充足的时间来做计划？
有时间，我们组在展开工作之前总共开了两次很长会，进行了大量的讨论。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会协商讨论，直到计划得到大家的认可。

• 计划

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
学长遗留下来的诸多bug均已经修复，而且所有几个新增功能都做完了，但有些功能模块没做好，仍有BUG需要改。因为剩下的时间不太够了。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有。比如选择存储路径的功能我们做了之后又删掉，因为我们一开始对总体规划不够，而且与下一个组沟通欠佳。
3. 是否每一项任务都有清楚定义和衡量的交付件?
有些有，比如爬虫爬取数据量的要求（十万级页面）、过滤无关页面的准确率这些都能从已经存在的一些爬虫软件中获得清楚定义和衡量的交付件；而有些没有，因为一些新增功能的评判我们大家都不知道做到多少才叫“好”。有些情况下，大家对细节过早地进行讨论，花了很多时间。不如等到后来再讨论。
4. 是否项目的整个过程都按照计划进行?
基本上是，一是大家比较自觉，团队凝聚力比较强，二是PM与DEV之间，DEV相互之间都会互相督促。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有，因为展开工作之前我们已经开了两次长会，充分考虑了各个功能的完成时间，功能我们觉得自己可以按时写完,而且事实上我们也实现了所有预计的功能。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
首先我们要留下缓冲区，以备进度完成情况不好。
然后是要在动手开发前做更多的计划，避免开发过程中做无用功。

• 资源

1. 我们有足够的资源来完成各项任务么?
有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
足够。有三个测试分别从不同的方面做黑盒测试，充分模拟了用户的情况。

• 变更管理

1. 每个相关的员工都及时知道了变更的消息?
我们QQ群会经常聊天以沟通最新的变化或进展，同时出现重大的bug的时候会召集成员进行面对面的交流。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
综合1、紧急程度（讨论协商定） 2、时间剩余 3、人员能力 来讨论哪些功能必须做哪些可以推迟。
3. 对于可能的变更是否能制定应急计划?
一般不能，直接告诉具体负责人要做哪些变更，没有应急计划。
4. 员工是否能够有效地处理意料之外的工作请求？
能，新的意外的工作请求会发到群里讨论分配给新的人做或延长原负责人的规定时间。

• 设计/实现

1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了单元测试，我们会对不同的小模块进行测试，看他是否已经完善没有bug且符合规格,前者是比较有效的(无法下载pdf功能)，但是我们没有做UML的测试。
2. 什么功能产生的Bug最多，为什么？
url爬取识别过程的BUG最多。因为这是我们最难的核心功能，总不同的URL有不同的形式，容易出现各种BUG。
3. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
这个是从头到尾一直在进行的，测试人员和开发者A,B,C会对开发者D写的代码进行审核，因为首先复审是测试分内的事，而A,B,C一是要二次检查D的代码是否有一些幼稚的错误，二是确定D写的代码有没有对整体代码架构造成不良的影响，确保整体代码保持一个高内聚、低耦合的特质。

• 测试/发布

1. 团队是否有一个测试计划？为什么没有？
我们有测试计划，而且测试的效果比较好。
2. 是否进行了正式的验收测试？
进行了，发现了bug，于是又清空了数据库并修改了bug。
3. 团队是否有测试工具来帮助测试？
单元测试使用了Junit工具。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
TFS 还是很有用的，至于改进，有这样一些建议：
（a）输入Bug 还是步骤比较多，很多需要手动重复填写的字段。
（b）不是所有的Bug 或 task 都记录在TFS中。
5. 在发布的过程中发现了哪些意外问题？
比如，由于我们采用的是google pagerank算法，他是根据网页之间相互的超链接计算每个网页的热度，录视频的时候由于时间不够，所以爬取了很少url，我们发现热度排序功能的算法在抓取数据量不大时迭代次数较少，不能很好地将网页都按热度排序，算法适用性低。

• 两个问题：

1) 对比敏捷的原则, 你觉得你们小组做得最好的是什么？
我们觉得我们小组做的最好的地方是敏捷原则中的“拥抱变化”。
每当有新的问题出现时，我们都可以最迅速地解决。
在代码刚拿到手我们大概读了一遍后，我们发现整个项目与我们想象的完全不同：代码质量没想象中的好，功能实现差的很多，没想到的还有要学服务器、数据库还有TFS得使用。但是我们通过1次网上讨论，两次全员会议和多次部分人员会议迅速地制定了下一步地方向。
开发过程中，我们又遇到很多没想到的新问题：1最开始测试的时候，发现怎么爬都爬不到pdf文件，即使爬到的pdf也只是数据库中的坏项，最后发现是学长保存pdf文件的bug2由于是多线程程序，新增的热度排序功能实现起来难度很大，BUG很多、3临展示发现选择本地文件功能没用、4临展示下一组告诉我们数据库有问题
可我们都通过及时地内部讨论、变更计划、重新规划计划完成了最终的ALPHA版本，这是我们小组最棒最自豪的地方。

2) 什么是在下个阶段 M2 要改进的地方？越具体越好。

下一阶段我们必须改进的是要做好整体地规划：
在这一阶段，我们需求讨论阶段做了大约两天，讨论出结果后以为可以开始干活了，可是之后进行过程中发现事实不是如此。或者是做的功能多余，或者是做完已有功能后不知道下一阶段干什么，导致软件开发过程中走了很多弯路。
因此，我们下一阶段必须在整体地架构上多费功夫。这个不是会不会的问题，而是用心不用心的问题。我们要花大约3天的时间来仔细地探讨我们得需求，尽可能多地罗列，然后为每个需求得重要性、可行性进行评估，得出实现每个需求的性价比。然后结合我们可以开发的时间，来确定最终需求。同时留出缓冲区时间，以防止意外需求或某些不可控因素干扰进程。这样我们就可以保证我们的需求对症下药、药到病除，以最少地精力达到最好的效果。

会议讨论图片记录：

M1阶段事后总结