数据处理项目Postmortem

1、 设想和目标

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

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

2）预期

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

整个工程给予了4周的工作时间来完成，相对比较紧凑，所以安排每位组员进行为期23.5个小时的工作任务。

3）团队关系

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

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

我们的目标是从根本上提高学霸系统的性能，极大地提升学霸系统的应用情景。目前我们成功地做出了多种分词器分词比较算法，tf-idf关键词提取算法，google机器翻译，数据库重复信息处理，实时查看算法，做完这些我们已经为工程提升了极大的性能，虽然不够完美，但是已经很完美了！

2、计划

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

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

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

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

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

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

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

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

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

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

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

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

3、资源

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

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

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

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

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

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

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

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

4、变更管理

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

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

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

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

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

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

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

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

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

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

5、设计/实现

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

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

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

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

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

我们的代码复审进行地比较精细，复审完全按照要求来做。

6、测试/发布

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

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

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

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

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

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

我们会直接摒弃学长的代码，然后自己重新规划，重新来做!

警戒下一届的学弟学妹们：

请推倒我们的代码，重新架构！一开始与所有组进行沟通，了解所有情况之后再来着手，否则就会陷入泥潭之中不可自拔。谨记谨记。。。。。