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阶段遗留下的一些问题,譬如数据库处理太慢。

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

 

附图:

 

posted @ 2012-11-26 01:42  teamshit  阅读(262)  评论(0编辑  收藏  举报