M1事后分析汇报以及总结
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：我们的软件主要解决信息提取的问题。定义清晰：要提取的内容包括于计算机科学相关内容的标题、作者、关键字和问题答案对等。信息的存贮媒介以html，pdf，word和excel等为主。这是一个专用软件，其上下游接口都是数据库。我们的用户是学霸网站的开发者，由他们来使用我们处理后存放在数据库中的信息。
2.是否有充足的时间来做计划?
答：有 也对每个阶段的工作做了计划
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：首先我们进行了讨论，持有不同观点的人都充分表达了自己的观点，这样下来大家最后能形成比较一致的认识，细节问题用投票的方式解决
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：第一阶段还没涉及这个问题。
计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大体上做完了，有一两个本来想要实现的功能由于并没有和下一组衔接好，暂时搁置了
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有，我们认为在软工实践中的尝试都是有意义的
3.是否每一项任务都有清楚定义和衡量的交付件?
算是吧，我们的最终衡量就是能用。
4.是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?
整个项目主体按照计划进行，中途遇到的一些bug通过大家的努力都得到了解决。为了降低风险，我们首先在保持接口不变的情况下对程序的性能进行了改进。对于新增的功能，我们依然选择嵌入到原有的接口上。这在很大程度上保证了软件的稳定性。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
有留下，当然有作用，由于并不是每个成员都能及时地完成任务，尤其是大家都有其他任务在身，留下缓冲区可以为以后的任务调整留出时间
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
计划可能会更加紧凑一点，PM也会将任务更加细化。
同时我们会加强对组员的督促，以是的软件的质量更高。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
比较可惜的是，对于迭代项目，我们没有机会体验软件工程的整个流程。同时由于历史遗留下来的文档缺乏问题，我们也没能体验到软件迭代开发的好处。主观感受上我们更像是消防员的角色，拿到缺乏注释的代码，在没有其他信息和帮助的情况下将代码调通并进行优化和功能的增加。因此，更多地，我们是通过反例而来学习软件工程的。
资源
1.我们有足够的资源来完成各项任务么?
是的，需要我们及时查阅相关的技术网站，了解我们需要实现的功能的最新方法，修改自己的代码。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
初步主要是凭我们自己对某个任务的难易程度进行估计的，估计的时候都考虑了一些机动时间，总体来讲这些估计偏差不大。
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
1)事实上，我们缺少对一些好用的测试工具的掌握，这也是在下一阶段我们要解决的问题
2)因为这是一个后台软件，美工完全不需要考虑，而文案是每个软件项目都十分需要的。足够详细的文案使软件的开发和维护都能得到极大的方便。在文案方面，我们面临的困难不大。原因基于以下几点：1.这是一个功能集中的专用软件，不需要根据用户的不同情况书写数以万字或更多的使用文档。2.在开发过程中，因为读懂代码本来就是我们工作的基础，所以为代码留下详细的注释也不造成挑战。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
我们都感到自己在完成自己的任务时还未能尽全力，又总是觉得别人做的很快，从这个角度来讲，是的。
变更管理
1.每个相关的员工都及时知道了变更的消息?
是的，我们充分利用了tfs的项目管理
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
1)根据项目交付时间和任务预估时间的比较
2)根据同前后两个组交接的必要性来看
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
将提取到的信息存入数据库中是基本的出口条件。
信息的准确程度是更高要求的出口条件。目前，我们只能通过直观感受判断准确程度。
4. 对于可能的变更是否能制定应急计划?
事实上，对于专用的软件，我们预期不会有很大的变更。如果发生了变更，我们会根据时间的紧迫程度确定是走一遍完成的需求分析+设计流程还是直接着手完成最基本的要求。
5. 员工是否能够有效地处理意料之外的工作请求？
我们在实现过程中确实遇到了一些情况需要对计划进行改变，通过PM的及时沟通，大家都能完成。比如由于服务器端没有office相关插件导致office相关转换不能使用时，及时删减了发布版本的功能。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
由PM主持，后来大家开会进行了确定，是合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有。开始的时候对任务了解不够，设计了一些不需要的功能，后来在实现过程中，随着对代码的了解加深，我们及时纠正了设计，也重新安排了任务。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
受限于数据库连接的问题，我们只测试了除了数据库连接以外的一些方法，对于发现bug是一个好办法，但是仍然存在构建测试用例比较麻烦的情况。
后面TDDUML我不懂``这你都不懂，太渣了
因为这不是一个很大的项目，也不需要重头设计，我们认为不需要使用TDD和UML
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
数据库连接 这是三个组共同使用的地段,大家存在沟通的问题,所以不兼容的情况更多.
目前还没有发布后的情况
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
首先是采用了结对编程的形式,从编程开始就减少了代码规范和bug等的出现,另外,任务组之间交叉进行了黑盒测试,PM也对主要功能进行了测试.
测试/发布
1.团队是否有一个测试计划？为什么没有？
没有.我们在本阶段对测试的重视不够.
2.是否进行了正式的验收测试？
进行了.在发布前,编程人员坐在一起按程序流程走了一遍,将各种情况都做了测试,保证发布时程序能够正常运行
3.团队是否有测试工具来帮助测试？
我们使用vs提供的单元测试工具对一些核心功能相关的函数进行了测试
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们的软件效能的关注较少。从实际的运行结果看，完全可以再可接受的时间内完成数据的处理。
5. 在发布的过程中发现了哪些意外问题？
出现了一些和文件相关的bug，比如文件不存在，内容无法读取，部分循环的效率过低等，我们都逐一解决了这些问题
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范.
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
大家能够以一个团队的姿态在一起工作,也开始懂得按照事先约定的规定来写程序
你觉得目前最需要改进的一个方面是什么?
整个团队都需要以一种更紧凑的方式运作.
附成员讨论照片：
