Pipeline Postmortem M1

现代软件工程

模板From 邹欣

开发团队：TeamSHIT

2012/11/23

 

设想和目标

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

我们实现的软件是一个网上教学问答系统，具体负责数据Pipeline部分，即处理爬虫爬取的网页，按照UI组的要求提取相应的数据并写入数据库中。

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

M1的开发周期是四周，小组用了一周的时间来计划，但是由于刚上手都没什么经验，不知道一个好的计划需要做到什么程度，也没有去找相关的资料学习下，最后导致出来的计划有点大而泛，没有落实到细处，对任务的难以程度估计不到位，执行起来存在漏洞。

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

有件怪事是我们团队在计划的时候基本没有提出什么不用意见，这个不好！

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

 M2阶段我们需要把任务计划放到一个更高的战略地位，同时不要直接计划完整个M2，每次计划未来三天应该是不错的节奏，保证计划不大，但是必须完成。

另外，我们在M1阶段碰到什么问题基本就是去网上找补救方案，而不是系统的去分析解决问题。M2我们要抱着做研究的心态进行Pipeline的进一步开发，第一件事从读论文开始！

最后，加强小组之间的合作。

 

计划

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

原计划的工作有部分没做完，原因是对负责程度计划不精确，以及没有严格按照原定计划展开工作。

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

没有，做的基本都是要的，做的还不够。

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

   每一项任务都清楚的定义，衡量的交付件则没有。

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

很遗憾，没有。

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

有留下缓冲区，最后在整合的时候还发现不够使。

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

未来对计划的描述，要加上一个明确的截止时间。

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

     如果历史重来一遍，首先，我们在估计进度的时候要慎之再慎，同时确保能按着计划来展开工作，最后要及时调整不合适的计划。

 

资源

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

资源是足够的，就是没利用好，几乎不去图书馆找过资料！

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

M1的时候只是凭PM的感觉和经验估计，精度不好。

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

没有安排用户角度的测试，M2会按照要求加上。

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

没有，我们团队的人员分配比较合理。 

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

如之前说的，首先是加上用户测试，然后是多利用可以利用的资源。

 

变更管理

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

住得都很近，有变更会第一时间通知所有组员。

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

首先数据流一定要跑起来，所以这部分功能是“必须实现”的，其他功能理论上都可以“推迟”，到时候只要组员觉得需要“推迟”并能说服其他人就可以“推迟”。

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

有定义，但是没做好，没有满足UI组的需求是我们最大的失败。

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

基本没有，PM负责调节。

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

有一个请求，没能处理好。 

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

变更在开发过程中是在所难免的，有变成其实不可怕，缺少沟通就完了，特别是小组间的沟通。

 

设计/实现

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

 在最开始的一周做的设计，设计工作PM主导，所有人员都有参与。时间和人都是合适的，不合适的地方在于计划跟进和根据具体情况修改。

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

设计时没有碰到模棱两可的情况，碰到了通过明确每一个细节是什么、归谁来解决。

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

没有，所以有效性也不好回答。

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

信息抽取。这部分是整个Pipeline的核心，设计时却把它交给一个人，那位同学直接给我一个正则表达式的算法也是情有可原的。

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

 没有代码复审。代码规范在开题的时候有特别强调，执行情况良好，就是注释少了些。

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

     M1   我们选择了一个人负责开发一个功能的形式，所以会出现各模块实现的水平参差不齐。M2我们选择所有人同时开发同一个功能，数据库仍交给一个人运行维护。

 

测试/发布

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

有测试计划。

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

有，测试结果因为平时关系都不错没明确的说出来。

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

没有这些工具。

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

这方面涉及不多，我们的测试主要是针对功能。

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

数据库读写太慢。

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

首先，增加测试工作的比重；第二，增加从用户的角度开展测试；第三，事情对事不对人。

 

附加的问题：

1) 对比敏捷的原则, 你觉得你们小组做得最好的是什么? 

答：我们小组做的最好的地方有两点。首先，在计划阶段分配任务时，PM征求了每个人自己的意见，每个组员思考自己对什么感兴趣，希望做什么，在这个基础上分配任务，大家的热情比较高昂。第二，我们对Pipeline定义了一系列文档和框架图，大家对我们的工作在整个班级开发的系统中处于什么位置，被谁服务，服务谁，实现每个功能的流程和方法比较清楚，最后搭起了整个Pipeline的框架。

2) 什么是在下个阶段 m2 要改进的地方? 越具体越好。 

 答：最核心的一点改进是重写信息抽取部分的内容，能处理RanHtml，争取完整对ppt以及pdf文件的处理。

第二，重新定义数据库，从爬虫到Pipeling以及从Pipeline到UI的交互都基于数据库实现，首先是要定义一个统一的数据格式。

第三，优化M1阶段遗留下的一些问题，譬如数据库处理太慢。

最后，增加代码复审，增加测试的比重。

 

附图：