大型项目中的敏捷项目管理实践
2019-12-09
来源： 宋荆汉
中，对业务理解与研发处于同一水准，可以在业务层面帮助研发来纠正需求理解的偏差，考虑对异常场景的处理。
通过这种方式，研发的详细设计文档基本可以省略，但对于复杂性比较高超过实现需要 8 人时以上的 story 还是需要给出简要的设计文档，需求详细文档可以裁减掉，而且测试用例通过验收准则可以很快就转换出来。通过需求的澄清过程，而不是需求文档的传递来沟通，大大提升了项目前期的进展。
缺陷的处理
通过厘清需求的过程，整个团队开发比较顺畅了，但是在迭代中我们发现对于缺陷的处理存在问题。有一次项目整体的回顾会，各特性团队，均顺利完成了各自的 sprint 的任务，但有个团队却没有完成而且是 0 完成率，但是我们发现他们遗留的问题并不多，那么是什么原因导致的呢？经过分析我们发现，他们在 sprint 中对缺陷的处理确实是缺乏处理策略。如图 3 所示，story 遗留缺陷对应图
图 3 .某 Sprint 的 story 与缺陷的对应关系
我们在定义 story 的验收条件，是要求每个 story 不能遗留一般级别以上的缺陷。但该团队对缺陷的处理是：
先处理严重级别的缺陷；
缺陷集中到迭代后期再进行修复。
所以，当他们进行缺陷修复的排序时，将所有的严重缺陷都进行了修复，但是导致最后却是一个 story 都不能交付。因为，每个 story 都还剩一个一般级别的缺陷。而且，由于不是立即处理缺陷，导致缺陷处理周期变长，修复缺陷占用较大比例时间。等严重缺陷都修复完，已经到迭代结束期。导致所有的 story 都无法交付。
在此次，我们必须要认识到一点，我们每个迭代都要进行增量的价值交付，作为研发团队应该考虑如何在一个迭代中尽可能多的交付，而不是为了修复缺陷。所以，如果研发团队，在进行缺陷修复时，考虑先把一个 story 的缺陷全部修改完，再修订其他 story 的缺陷，应该可能交付 2 个 story 的，虽然对软件整体而言，缺陷没变，但是交付的商业价值却是更多的。
因此在后期，我们确定在迭代过程中：
必须树立尽量多交付价值的观点；
缺陷必须在发现时立即修复，不建议集中进行修复，因为缺陷的定位时间会随时间逐渐加长的，立即修复才是对进度、质量最有利的方式；
实在无法修复或确实需要时间修复的 bug，需要进行分析和规划，不能仅仅以故障的级别为修复的优先项，而是增量交付为核心关注点。
在团队中增加一个专职的 bug 修复人员，就是一旦 bug 出现，由专职的 bug 修复人员进行修复，其他人员继续 story 的开发，这个人员可以在不同迭代轮换。起初是在一个团队中采用，后来发现，这种方式也取得了很好的效率，所以，在所有特性开发团队中都采用起来。
Story 的切分
见下图 4，一般的业务系统都是按如下的方式进行横向的切分，也就是我们常说的流式结构，当某一层发生变动时，其他层可以保持不变。
图 4 .常见业务系统的结构
当到敏捷开发中队 story 的切分是基于纵向的切分如图 5 所示，也就是每个 story 都可以方便的从系统中整合与拆并。
图 5 .敏捷开发的纵向切分
采用这种结构，可以方便的进行增量交付，而且当一个有问题时，可以拆开不影响其他部分，非常适合敏捷开发增量的要求。
但在实际中需求并不是由一个个孤立的"用户故事"组成的，业务概念、业务流程其实是贯穿多个用户故事的，软件设计应该多从业务概念、业务流程的角度来思考；表面上看上去一个用户故事对应一组界面，其实界面之间是很可能有重用和共
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
