M2postmortem

设想和目标

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

答：我们的软件主要解决信息提取的问题。定义清晰：要提取的内容包括于计算机科学相关内容的标题、作者、关键字和问题答案对等。信息的存贮媒介以html，pdf，word和excel等为主。这是一个专用软件，其上下游接口都是数据库。我们的用户是学霸网站的开发者，由他们来使用我们处理后存放在数据库中的信息。

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

答：有 也对每个阶段的工作做了计划

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

答：首先我们进行了讨论，持有不同观点的人都充分表达了自己的观点，这样下来大家最后能形成比较一致的认识，细节问题用投票的方式解决

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

答：我们组的用户只有学霸网站小组和app小组。整个学霸项目的用户有多少我们并不清楚。

　　在M2阶段，一个比较重要的功能是问答对的提取。在M1阶段，因为整合较晚，对真正的需求并不明确。在M2阶段，我们和网站组较早地关于问答对在数据库中的存储样式达成了共识，也实现了他们的需求。所以，我们离目标更近了。

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

　　经验：需求分析早做，能使项目进展更为顺利。

　　教训：单元测试要早作，可以尝试使用测试驱动的开发模式。

改进：可能会尝试测试驱动的开发。事实上我们在开发过程中一直进行了测试，但测试的不够规范、高大上。比如问答提取的函数，我们会新建一个vs项目，测试是否能提取到需要的信息，然后才会把函数加到软件中。但比较可惜的是，这些测试都没有记录下来。

计划

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

原计划的工作都做完了，但是在比较晚的时间节点有增加了关于文档的需求，这方面的实现还在进行中。

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

暂时没有，我们认为在软工实践中的尝试都是有意义的

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

算是吧，我们的最终衡量就是能用。

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

整个项目的主体部分是按照计划进行的，或者说得到了及时的完成。风险在于需求上。还是之前提到的文档的需求。在和网站组的交流中得知他们不需要文档，所以没有做。在比较晚的时间节点，在老师的推动下，增加了这个需求。在数据库中增加了新的表，一些数据需要迁移。

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

有留下，当然有作用，由于并不是每个成员都能及时地完成任务，尤其是大家都有其他任务在身，留下缓冲区可以为以后的任务调整留出时间

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

已经到了收尾阶段，后面把一些文档整理好。

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

　　比较可惜的是，对于迭代项目，我们没有机会体验软件工程的整个流程。同时由于历史遗留下来的文档缺乏问题，我们也没能体验到软件迭代开发的好处。主观感受上我们更像是消防员的角色，拿到缺乏注释的代码，在没有其他信息和帮助的情况下将代码调通并进行优化和功能的增加。因此，更多地，我们是通过反例而来学习软件工程的。

　　另外，在M2阶段也出现了需求分析方面的问题，但原因和第一阶段是有区别的。在学霸团队的内部已经定义好了需求，但在外部力量的推动下增加了需求。不知道这种情况在真实的软件项目中是不是也时有发生。

资源

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

是的，需要我们及时查阅相关的技术网站，了解我们需要实现的功能的最新方法，修改自己的代码。

老师提供的服务器性能上略有欠缺，我们每次编译程序都要等待较长的时间。

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

初步主要是凭我们自己对某个任务的难易程度进行估计的，估计的时候都考虑了一些机动时间，总体来讲这些估计偏差不大。

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

a.可能测试是大家都不想做的事情，以至于在M2阶段我们的测试工作开展的仍然比较晚。但我们会坚定地将单元测试推动下去。

b.因为这是一个后台软件，美工完全不需要考虑，而文案是每个软件项目都十分需要的。足够详细的文案使软件的开发和维护都能得到极大的方便。在文案方面，我们面临的困难不大。原因基于以下几点：1.这是一个功能集中的专用软件，不需要根据用户的不同情况书写数以万字或更多的使用文档。2.在开发过程中，因为读懂代码本来就是我们工作的基础，所以为代码留下详细的注释也不造成挑战。

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

我们都感到自己在完成自己的任务时还未能尽全力，又总是觉得别人做的很快，从这个角度来讲，是的。

 

变更管理

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

是的，我们充分利用了tfs的项目管理

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

a.根据项目交付时间和任务预估时间的比较

b.根据同前后两个组交接的必要性来看

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

将提取到的信息存入数据库中是基本的出口条件。

信息的准确程度是更高要求的出口条件。目前，我们只能通过直观感受判断准确程度。

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

事实上，对于专用的软件，我们预期不会有很大的变更。如果发生了变更，我们会根据时间的紧迫程度确定是走一遍完成的需求分析+设计流程还是直接着手完成最基本的要求。

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

　　我们在实现过程中确实遇到了一些情况需要对计划进行改变，通过PM的及时沟通，大家都能完成。比如由于服务器端没有office相关插件导致office相关转换不能使用时，及时删减了发布版本的功能。

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

 

设计/实现

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

由PM主持，后来大家开会进行了确定，是合适的。

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

有。第二阶段的需求很清晰，相应地，设计也很清晰，没有模棱两可的情况。

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

没有使用TDD和UML。运用了单元测试，感觉vs提供的工具挺好用的。

因为这不是一个很大的项目，也不需要重头设计，我们认为不需要使用TDD和UML

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

数据库连接  这是三个组共同使用的地段,大家存在沟通的问题,所以不兼容的情况更多.

另外，我们发现，当多个组共同使用数据库时，当连接过多会出现异常。这个问题我们无法解决，我们能做的只有每次打开连接都及时关闭。

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

首先是采用了结对编程的形式,从编程开始就减少了代码规范和bug等的出现,另外,任务组之间交叉进行了黑盒测试,PM也对主要功能进行了测试.

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

 

测试/发布

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

有测试计划，但测试展开的较晚。

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

进行了.在发布前,编程人员坐在一起按程序流程走了一遍,将各种情况都做了测试,保证发布时程序能够正常运行

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

　　我们使用vs提供的单元测试工具对一些核心功能相关的函数进行了测试

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

我们的软件效能的关注较少。从实际的运行结果看，完全可以再可接受的时间内完成数据的处理。但要说明的是，如果爬虫和数据处理同时运行，我们处理一个文档的速度要远慢于爬去一个文档的速度。

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

暂时没有遇到。

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

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

规范.

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

大家能够以一个团队的姿态在一起工作,也开始懂得按照事先约定的规定来写程序

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

整个团队都需要以一种更紧凑的方式运作.