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阶段遗留下的一些问题，譬如数据库处理太慢。
最后，增加代码复审，增加测试的比重。
附图：
