- 设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的主要任务是将35w+个符合条件的网页，问答，文章放入数据库；爬取功能定义为以下几种：通用型爬取，聚集型爬取，综合型爬取，问答页爬取，pdf爬取，doc爬取，ppt爬取；对于典型用户和典型场景有清晰的描述，这从我们爬取的类型分类就可以看出。
2. 是否有充足的时间来做计划？
大三上后期时间略有些紧，有编译和数据库大作业，还要准备期末考试，不过组员们还是抽出了不少时间来完成beta版本的各项任务。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会协商讨论，一般情况下会通过讨论得到一致意见，少数情况则按照少数服从多数的原则来进行取舍。
- 计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本上都按照计划完成了，后面下游小组又向我们提出了一些新的要求以及相应是需求变更，我们也都完成了相应的修改与调整。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
在alpha版本之后，我们深入的思考和反思了自己的得失，发现一些功能的确多余了，在beta版本中，我们事先进行了功能的分析和取舍，基本上我们的工作都有其用处。
3. 是否每一项任务都有清楚定义和衡量的交付件?
大部分时候是有的。
4. 是否项目的整个过程都按照计划进行?
基本上是，一是大家比较自觉，团队凝聚力比较强，二是PM与DEV之间，DEV相互之间都会互相督促。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，在吸取了alpha版本的经验教训后，我们组留下了大约一周的时间作为缓冲时间，来进行和其他学霸团队的协调和对自身功能的完善。
- 资源
1. 我们有足够的资源来完成各项任务么?
有，网上的爬虫软件很多，能够供我们参考学习的样例也不少。我们团队还有2名参加过实验室爬虫项目的队员，他们给我们提供了不少宝贵的经验。
网上pdf、ppt和doc的数量比较少，但是在罗杰老师的帮助下，还是爬取到了不少专业的文档。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据M1阶段完成任务的时间和效率，给每位dev分任务，并在每次daily scarm上进行调整，精度由于daily scarm基本可以接受。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
足够。有三个测试分别从不同的方面做黑盒以及白盒测试，充分模拟了用户的情况。
- 变更管理
1. 每个相关的员工都及时知道了变更的消息?
每天都有daily scarm，我们QQ群会经常聊天以沟通最新的变化或进展，同时出现重大的bug的时候会召集成员进行面对面的交流。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
参考不断完善中的需求分析文档来判断哪些功能是“必须实现”的功能，通过分析功能的紧急程度，任务的时间剩余以及人员能力来讨论哪些功能必须做哪些可以推迟。
3. 对于可能的变更是否能制定应急计划?
可以，我们留出了足够的缓冲时间来应对可能出现的种种问题。
4. 员工是否能够有效地处理意料之外的工作请求？
能，新的意外的工作请求会发到群里讨论分配给新的人做或延长原负责人的规定时间。
- 设计/实现
1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了单元测试，我们会对不同的模块进行测试，看他是否已经完善没有bug且符合规格。这些工具都是比较有效的。
2. 什么功能产生的Bug最多，为什么？
主要是爬虫频繁访问造成的503错误以及使用多线程所产生的bug。
我们后期基本上修复了各种类型的bug，目前发现的bug基本上都能够很好地避免或修复。
3. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
这个是从头到尾一直在进行的，测试人员和开发者A,B,C会对开发者D写的代码进行审核，因为首先复审是测试分内的事，而A,B,C一是要二次检查D的代码是否有一些幼稚的错误，二是确定D写的代码有没有对整体代码架构造成不良的影响，确保整体代码保持一个高内聚、低耦合的特质。
- 测试/发布
1. 团队是否有一个测试计划？为什么没有？
我们有测试计划，而且测试的效果比较好。
2. 是否进行了正式的验收测试？
进行了。
3. 团队是否有测试工具来帮助测试？
单元测试使用了Junit以及Emma工具。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
TFS 还是很有用的，至于改进，有这样一些建议：
（a）输入Bug 还是步骤比较多，很多需要手动重复填写的字段。
（b）不是所有的Bug 或 task 都记录在TFS中。
5. 在发布的过程中发现了哪些意外问题？
基本上没有出什么意外。
会议讨论图片记录：
