通过这样的方式,可以节省 PO 详细需求文档的时间,同时将需求的责任分担到每个角色的身上。因为,即使再详细的文档,研发和测试人员 还是需要阅读消化同时也需要多次找 PO 确认。直接通过讲解确认,我们也称为"需求的三次握手"过程,开发、测试、需求人员,实际完成了对需求的传递、需求验证规则的统一,这时测试就可以再前期介入到项目中,对业务理解与研发处于同一水准,可以在业务层面帮助研发来纠正需求理解的偏差,考虑对异常场景的处理。www.mypm.net
通过这种方式,研发的详细设计文档基本可以省略,但对于复杂性比较高超过实现需要 8 人时以上的 story 还是需要给出简要的设计文档,需求详细文档可以裁减掉,而且测试用例通过验收准则可以很快就转换出来。通过需求的澄清过程,而不是需求文档的传递来沟通,大大提升了项目前期的进展。项目管理者联盟
缺陷的处理项目管理者联盟
通过厘清需求的过程,整个团队开发比较顺畅了,但是在迭代中我们发现对于缺陷的处理存在问题。有一次项目整体的回顾会,各特性团队,均顺利完成了各自的 sprint 的任务,但有个团队却没有完成而且是 0 完成率,但是我们发现他们遗留的问题并不多,那么是什么原因导致的呢?经过分析我们发现,他们在 sprint 中对缺陷的处理确实是缺乏处理策略。如图3所示,story遗留缺陷对应图:项目管理论坛
项目管理者联盟
我们在定义story的验收条件,是要求每个story不能遗留一般级别以上的缺陷。但该团队对缺陷的处理是:项目管理者联盟
先处理严重级别的缺陷;www.mypm.net
缺陷集中到迭代后期再进行修复。training.mypm.net
所以,当他们进行缺陷修复的排序时,将所有的严重缺陷都进行了修复,但是导致最后却是一个story都不能交付。因为,每个story都还剩一个一般级别的缺陷。而且,由于不是立即处理缺陷,导致缺陷处理周期变长,修复缺陷占用较大比例时间。等严重缺陷都修复完,已经到迭代结束期。导致所有的story都无法交付。项目管理者联盟
在此次,我们必须要认识到一点,我们每个迭代都要进行增量的价值交付,作为研发团队应该考虑如何在一个迭代中尽可能多的交付,而不是为了修复缺陷。所以,如果研发团队,在进行缺陷修复时,考虑先把一个story的缺陷全部修改完,再修订其他story的缺陷,应该可能交付2个story的,虽然对软件整体而言,缺陷没变,但是交付的商业价值却是更多的。项目管理者联盟
因此在后期,我们确定在迭代过程中:项目管理者联盟
必须树立尽量多交付价值的观点;service.mypm.net
缺陷必须在发现时立即修复,不建议集中进行修复,因为缺陷的定位时间会随时间逐渐加长的,立即修复才是对进度、质量最有利的方式;项目管理者联盟
实在无法修复或确实需要时间修复的bug,需要进行分析和规划,不能仅仅以故障的级别为修复的优先项,而是增量交付为核心关注点。PgMp.mypm.net
在团队中增加一个专职的bug修复人员,就是一旦bug出现,由专职的bug修复人员进行修复,其他人员继续story的开发,这个人员可以在不同迭代轮换。起初是在一个团队中采用,后来发现,这种方式也取得了很好的效率,所以,在所有特性开发团队中都采用起来。项目管理者联盟
Story的切分项目管理者联盟
见下图4,一般的业务系统都是按如下的方式进行横向的切分,也就是我们常说的流式结构,当某一层发生变动时,其他层可以保持不变。项目管理者联盟
项目管理者联盟
当到敏捷开发中队story的切分是基于纵向的切分如图5所示,也就是每个story都可以方便的从系统中整合与拆并。项目管理者联盟
项目管理者联盟
采用这种结构,可以方便的进行增量交付,而且当一个有问题时,可以拆开不影响其他部分,非常适合敏捷开发增量的要求。项目管理论坛
但在实际中需求并不是由一个个孤立的"用户故事"组成的,业务概念、业务流程其实是贯穿多个用户故事的,软件设计应该多从业务概念、业务流程的角度来思考;表面上看上去一个用户故事对应一组界面,其实界面之间是很可能有重用和共享部分的;业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应,存在交叉、共享和重用的可能;数据层中的某张表,通常会支撑多个用户故事而不是一个用户故事。项目管理者联盟
例如,以下列出来的可能都需要从软件架构上做一个整体的考虑:项目管理者联盟
权限控制;项目管理者联盟
性能要求;bbs.mypm.net
|