设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的爬虫现阶段解决的就是文件爬取的问题。在定义中爬取对性能和功能的要求高，典型用户和场景的描述较为清晰。
2. 是否有充足的时间来做计划?
有一周的时间来进行计划，这个时间还是很充裕的。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
异议者可以对PM和主DEV提出质疑，但是最终还是由PM决定计划。
用户量（爬取数目）, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
从发布部署到项目展示，我们的爬取时间不多，但是由于对性能的改进，我们最终的爬取数目喜人。网页及问答页的爬取全部达到要求。但是由于种子URL的缺乏以及爬取时间的限制，我们的doc和ppt的爬取数目离目标数据差距较大。如果历史重演，我们会对这两项目标进行调整，并积极收集相关种子URL，在发布前这两项爬取功能完善时就开始进行爬取。
计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作有性能和功能两个方面。性能方面改进进行的较好，爬取效率大有提高。但是由于个别成员积极性和人员分配统筹的问题，新功能方面还是做得不够完美。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
基本上没有。
3. 是否每一项任务都有清楚定义和衡量的交付件?
否。这点是PM的疏忽，PM进行任务的分配，对于任务完成的交付衡量定义不是特别的清晰。
4. 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?
大体上是按照计划进行的。没有估计到的风险主要还是个别成员的任务完成情况距离要求差距较大。例如UI的设计。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
周日是我们小组成员自由工作的缓冲时间，能够减轻一下压力。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
首先在分配任务时清楚定义和衡量交付件；其次如若成员消极随意对待工作，不延长其交付时间，他之后的工作照常加上，由该成员自己统筹时间全部完成，否则进行相应的贡献分处分。最后是保证每周的一个阶段性工作总结会议的质量。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划要考虑各项指标，不能只分配任务，例如任务的交付，成员对任务的完成能力等等。其次要重视风险评估，让我们不至于在突发情况时措手不及。
资源
1. 我们有足够的资源来完成各项任务么?
资源不尽人意，由于我们的项目对网速的要求较高，但是服务器上的网页访问奇慢无比。所以我们大多数还是通过数据库连接用PC爬取的。希望能够改善一下服务器的网页访问速度。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
每项任务的时间根据成员能力和任务难度来定，一般成员一天任务时间不会超过三小时。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于部署的较晚，测试时间还是偏少。人力和软件资源都足够，硬件资源还是服务器网速的问题。对于设计文档等各种文案的难度没有低估。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
不可能。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
资源方面应该是没什么教训。如果历史重来，死缠烂打找老师提升服务器网速。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，PM会及时在TFS,QQ群上通知。由于寝室离得比较近，PM会奔走相告。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据每周阶段性总结会议的讨论和与数据处理小组协商他们的需求。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
定义较为清晰，主要有3点要求：1.能够爬取网页、问答页、pdf、ppt、doc；2.根据关键字爬取；3.信息入库，提供给数据小组使用。
4. 对于可能的变更是否能制定应急计划?
一般如果有突发情况，都是由包括PM的个别成员熬夜完成。
5. 员工是否能够有效地处理意料之外的工作请求？
可以处理。例如连接数据库的各种权限问题，成员能自行登录服务器进行权限的分配。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
由于M1阶段中变更情况较少，所以这方面对我们的影响不太大。需要改进的是我们可以评估和准备可能到来的变更，减少成员熬夜的情况。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在迭代一开始的一周时间里。通过小组讨论，最终由PM和主DEV功能完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，并且对现在的版本发布造成了较大的影响。分配给成员的一个分类功能，在当时设计时没有说清楚，最终成员仅实现了分类统计，没有时间分类存储和管理。从现在来看应该是都要实现，团队对当时这一情况解决得不好。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了java unit test。由于当时有很多新功能没实现的搁置代码，所以覆盖率不高。在M1测试阶段junit对我们的作用不是很大。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
爬取线程产生的Bug最多。因为我们缺少线程管理的方案。发布之后也有发现在爬取数目较大时偶会发生线程Bug,在设计时由于我们缺少长时间大数目的评估测试，导致了这一Bug的存在。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
这一点我们团队没有做到。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在设计中缺少一些任务的评估和代码复审。在设计时进行一些系统性的测试对我们项目的进行是有帮助的。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
测试计划是较为完善的，计划要求对功能性、可靠性、可使用性、安全性和性能进行测试，并给出了测试基本要求。
2.是否进行了正式的验收测试？
是的。最终进行大数目的爬取测试，达到了验收的数量。
3.团队是否有测试工具来帮助测试？
没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
与上一版本的爬虫进行了单次最大爬取数目和单位时间爬取数目的比较，从运行结果来看，我们的爬取性能更优。
5.在发布（部署）的过程中发现了哪些意外问题？
缺乏种子URL导致爬取的ppt、doc数目较少。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
这一方面我们小组做的比较好，不足的还是URL的收集不够积极有效。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
我们这是第一个里程碑。
你觉得目前最需要改进的一个方面是什么?
PM对基础每日工作的统筹、监督和交付评定。
Postmortem 会议成员照：
