Pipeline组项目Postmortem

1、     设想和目标

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

我们的项目是学霸系统PipeLine，软件主要解决学霸系统的内部操作问题，优化后台操作，优化代码，提高执行效率，而非界面抑或整个软件，因此，我们的整个工程面向的用户群体不是传统意义上的用户，而是学霸系统UI组。

2）预期

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

整个工程给予了3周的工作时间来完成，相对比较紧凑，每周都会安排每人组员进行为期20个小时的工作任务。

3）团队关系

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

大家通力合作，在合作的工作任务中，一旦出现不同的意见，都会和团队的PM说，PM做相关的记录，等到例行的团队会议时候提出，大家一起讨论最后表决，决定相关的内容。

我们的目标是从根本上提高学霸系统的性能，极大地提升学霸系统的应用情景。目前我们成功地做出了中科院ictclas中文分词算法，朴素贝叶斯英文分词算法，tf-idf关键词提取算法，google机器翻译，数据库重复信息处理，做完这些我们已经为工程提升了极大的性能，虽然不够完美，但是已经很完美了！

2、计划

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

很多事情都没做完，大家认为最后没做完的事情，都是可有可无的。

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

我们时候发现我们完全没有必要每个人都详细地看学长的代码，只要学长给我们讲过他的代码的功能后我们可以根据我们的改进直接在相应的模块上改进。

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

大部分都没有，因为我们大家都不知道做到多少才叫“好”。有些情况下，大家对细节过早地进行讨论，花了很多时间。不如等到后来再讨论。

是否项目的整个过程都按照计划进行?

基本上都是按照计划进行的。

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

有缓冲区，而且我们到后面也应用到了，防止工程因中间出错导致后期无法按时交付。

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

应该明确缓冲区的长度，并且根据实际情况不定期地调整。

3、资源

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

很多情况下是有的，，但是有些时候我们不能再同一时间聚在一起，导致有些工作需要同时做的延后进行。

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

开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。

用户测试的时间，人力和软件/硬件资源是否足够?

测试时间足够，人力足够，软件的话我们没有使用专业测试软件，因此测试起来比较吃力。

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

有，比如算法设计人员需要一些测试的数据，可以由别的工作相对较少的同学来进行就比较有效率。

4、变更管理

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

大家的寝室都比较近，容易沟通，交流方便，另外团队有一名女生，可以利用各种上课后，中午一起吃饭时间等进行有效地沟通。一旦有变更事宜，能够很快地通知所有人。

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

我们看类之间的依赖关系，被依赖的功能就必须要先实现。

项目的出口条件（Exit Criteria）是否得到清晰的定义?

对于我们而言，“做好了”就是提高代码的运行效率，要达到客户需求。

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

能，对于变更，我们会根据每个人不同的擅长进行合理分配 。

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

规定所有请求都转到PM那里处理，同时如果有需要会合理地给大家分配一些既定工作外的工作，大家也能够接受。

5、设计/实现

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

整体设计工作在最初的团队会议上由大家各抒己见，进行讨论。具体到算法的设计则是由开发人员开发的时候设计。

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

有时候会有，一些算法改进就会遇到这样的情况，可以有多种不同的优化，各有优劣，于是就不好拿主意了，，这个时候就发挥团队的作用，设计人员相互讨论，最后决定。

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

没有单元测试和测试驱动开发，利用UML帮助设计类及类间关系的设计非常有效。

什么功能产生的Bug最多，为什么？

中文分词，由于利用中科院的API，很多函数不知道怎么实现的，直接调用出现不少bug。尤其是C#的API使用网上介绍比较少，（网上基本上都是Java版的），因此学起来比较吃力。

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

我们的代码复审进行地比较粗略，复审后来就比较匆忙，因此多流于形式了。

6、测试/发布

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

我们的团队有测试计划。团队的测试人员对程序进行了验收测试，发现bug就会立即改进。并且我们有多个测试人员分别进行测试，发现的bug进行比对，尽量减少忽略bug的可能性。

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

进行了正式验收测试。我们测试之后写了测试报告

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

没有使用测试工具进行测试，都是测试人员进行的手动测试和监控。

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

测量并跟踪软件效能方面并没有使用什么专业的软件，而直接是人工去观测的。这些测试工作可以让我们更好的了解软件的效能，以便作出对症下药的改进。改进就是在下次迭代时，要适应更专业的测试工具。

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

由于用户使用时不用再去修改路径和数据库的服务器和密码，因此我们还要临时去修改代码以适应发布后用户的使用。

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

我们学到了测试也是非常重要的，只有这样才能及时发现软件中的问题，并作出相应的改进。我们会利用与写代码同等的重视去看待测试。

我们会应用N-Gram算法进行分词操作，主要解决N-Gram算法的数据稀疏性问题，提高分词算法的智能。其次，我们在最初的时候不应该花大量的时间在看学长的代码上，我们可以直接向学长询问代码功能等问题，直接了解所做工程的具体内容。