M2 Postmortem
TeamSHIT
2013/01/07
设想和目标
我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们实现的软件是一个网上教学问答系统,具体负责数据Pipeline部分,即处理爬虫爬取的网页,按照UI组的要求提取相应的数据并写入数据库中。
具体要求是分析非问答型网页(type = webpage),提取网页标签,对每个标签抽取标签预览。
是否有充足的时间来做计划?
M2的开发周期是4周,第1周用来做计划。到M2我们对Pipeline的系统框架和功能已经了解足够详细,计划的内容主要是数据抽取部分的算法。
团队在计划阶段是如何解决同事们对于计划的不同意见的?
提出意见是一件非常宝贵的事情,任何意见都将得到团队足够的重视。在这个基础上请提出者将如果按照你这么做,实现难度多大,效果会怎么样,然后团队投票。
如果历史重来一遍, 我们会做什么改进?
加强团队之间的合作,主动联系其他团队,分配好多个团队相关的任务。在设计完了之后不要轻易该需求。
计划
你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
原计划的工作都已经做完。
有没有发现你做了一些事后看来没必要或没多大价值的事?
为了抽取关键字我们找了一些计算机领域的标签,但是在现在运行的效果来看这些标签基本没有用到,反而增加了每个网页分析的时间成本。但是从长远的角度考虑,这个工作还是必要的。
是否每一项任务都有清楚定义和衡量的交付件?
每一项任务都清楚的定义,衡量的交付件则没有。
是否项目的整个过程都按照计划进行?
是的。
在计划中有没有留下缓冲区,缓冲区有作用么?
有留下缓冲区,在最后的整合阶段。
将来的计划会做什么修改?(例如:缓冲区的定义,加班)
请小时成员如实地、及时地反正计划执行情况。
如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍,首先,我们在估计进度的时候要慎之再慎,同时确保能按着计划来展开工作,最后要及时调整不合适的计划。
资源
我们有足够的资源来完成各项任务么?
资源足够。
各项任务所需的时间和其他资源是如何估计的,精度如何?
时间估计靠PM的感觉,其他资源并未估计。时间分配在感觉的基础上放大一些。
用户测试的时间,人力和软件/硬件资源是否足够?
用户测试不好弄,只有自己的功能测试。
你有没有感到你做的事情可以让别人来做(更有效率)?
没有,我们团队的人员分配比较合理。
如果历史重来一遍, 我们会做什么改进?
多多利用可以利用的组员。
变更管理
每个相关的员工都及时知道了变更的消息?
住得都很近,有变更会第一时间通知所有组员。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
首先数据流一定要跑起来,所以这部分功能是“必须实现”的,其次是那些作为后续开发需要引用的功能,“必须实现”。其他功能理论上都可以“推迟”,到时候只要组员觉得需要“推迟”并能说服其他人就可以“推迟”。
项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
有定义,做完之后有验收。
对于可能的变更是否能制定应急计划?
应急计划没有,PM临时分配任务。感谢组员们无条件接受分配的任务!
员工是否能够有效地处理意料之外的工作请求?
虽然该需求是一件非常蛋疼的事情,但是我们还是解决了。
如果历史重来一遍, 我们会做什么改进?
这部分我们做得还是可以的。
设计/实现
设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
在最开始的一周做的设计,设计工作PM主导,所有人员都有参与。时间和人都是合适的。
设计工作有没有碰到模棱两可的情况,团队是如何解决的?
设计时没有碰到模棱两可的情况,碰到了通过明确每一个细节是什么、归谁来解决。
团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
这环节还是比较薄弱。
什么功能产生的Bug最多,为什么?
信息抽取。在处理过程中设计到很多字符处理,没处理好就会出现异常,最多的是引用没有实例化的变量。
代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
开发人员开些的时候旁边会做一个同伴。代码规范是口头约定的,负责开发的三个人的风格都较好。
如果历史重来一遍, 我们会做什么改进?
我们选择的是一个人负责开发一个功能的开发模式,所以在模块间整合的时候可能会出现信息不对口,这个需要在设计的时候定义情,同时组员见要加强联系。
测试/发布
团队是否有一个测试计划?为什么没有?
有测试计划。
是否进行了正式的验收测试?
有。
团队是否有测试工具来帮助测试?
Visual Studio单元测试。
团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
软件效能不太高,2s分析一个网页。
在发布的过程中发现了哪些意外问题?
没有处理好字符串异常。
如果历史重来一遍, 我们会做什么改进?
增加测试的比重,同时多关注测试计划的跟进情况。