作者简介
都云霞，Agilean 公司管理顾问、敏捷教练，CSM 、PMP 、CSPO 认证。近 10 年金融软件项目管理背景，曾服务於穆迪等国际金融咨询公司，参与中原银行、平安银行等的敏捷精益辅导。本文转载自公众号Agilean。
由于某些不恰当的实施方式，敏捷导入有时在企业里处于「两头不讨好」的尴尬状态：业务认为敏捷是造成低质量交付的推手，而研发觉得敏捷是管理者压榨团队的帮凶。
通过分析众多敏捷实施失败案例，我们发现大多数情况下，版本迭代节奏不匹配组织和业务特点是导致失败的根本原因之一。本文将结合 Agilean 咨询团队的实践经验，推荐一种适合复杂业务场景（如金融科技）的版本迭代节奏：RISE（Release-Iteration Schedule for Enterprise)。
介绍 RISE 之前，让我们先看一下，在复杂的业务场景中，传统的双周迭代会遇到什么问题。
双周迭代，指每两周进行一次发布。这意味着从业务侧承接过来的需求，要在1-2天内完成需求分析和澄清。但对很多复杂业务场景来说，需求澄清通常要花2-3天才能真正完成。现实中很多的交付质量不合格，就是由需求不清晰这个源头问题造成的。
交付质量差，会促使人们不断将「功能移交测试时间」前移，比如要求迭代第二周开始之前提测，以避免上线风险。于是，开发同学必须加班加点，自测、联调也只能对付了事，上线时候还是一堆的故障。
最后，他对当前状态进行了这样的评价：
做软件研发，大脑是我们最重要的生产工具。但团队一直处于又紧张又疲惫的状态，别说高质量交付了，连最基本的质量都难以保证。这不是在做迭代，而是连滚带爬，「死亡行军」。
在调侃的语气中，我们仍能感受到满满的无奈和倦意。仔细分析上面状况的产生，能发现两个主要原因：
团队将一个版本的所有活动，都压缩进入了同一个迭代。对于一些复杂业务和复杂系统，这样做往往导致时间过于紧张。
迭代内部以「一周开发，一周测试」的方式运行，这种情况下，迭代变成了小瀑布。
如何发现「小瀑布」？来瞧瞧下面这个看板：
上图中，团队所有事项都集中在开发区域。有些卡片进入了开发的「已完成」列，没有任何卡片进入「测试」。看板呈现了浪涌式流动——这就是团队以小瀑布方式运行的表现特征。
在小瀑布模式下，为了避免资源浪费，往往将迭代时间按流程切开，比如上半周开发，下半周测试。
听起来很有「节奏」，对不对？问题来了，测试在上半周的时间里，要做些什么？在现实中，上半周往往用来测上一个迭代的内容，于是，团队中开发测试的协作被强行割裂。
小瀑布模式的核心问题在于，「开发完成」并不是真的完成，还属于WIP（在制品），并不能产生真正的质量反馈。开发完成的需求，在测试时可能暴露出大量缺陷，造成返工。迭代管理的核心目标是降低交付风险，确保质量可控，但小瀑布模式显然无法有效实现这点。
如何破解小瀑布？我们通常建议团队采用「流式开发」。即以小颗粒度需求（如用户故事）为单位，让需求像水一样不断向下个阶段流动，从而快速获取反馈，真正达到利用迭代管理降低风险的目标（如下图）。
以「流式开发」运行的迭代，看板往往呈现下面的变化形式：
诚然，流式开发对需求拆分提出了更高要求，需求要被拆解成可测试可验收的细小单元。其实，这是敏捷产品经理和敏捷教练需要具备的硬核技能，也是敏捷需求管理的基础。
另外，为了减少开发测试工作的并发打扰，开发人员要采取开发自冒烟、代码评审等质量措施，来保证需求的顺畅流动（这方面的详细内容可以参见FLEET的「润滑」原则）。
针对复杂业务研发场景，RISE 倡导在流式开发基础上，将版本和迭代解耦。延长版本存续时间，将一个版本分成需求迭代和研发迭代，前一个版本的研发迭代和后一个版本的需求迭代并行。
上面描述的版本迭代节奏，使团队可以实现需求澄清前置，即由产品经理提前一个迭代与业务人员进行需求细化。在研发迭代开始时，团队拿着已经充分细化澄清的需求，直接投入开发工作。
对于发布流程复杂、生产质量要求高的情况，RISE 版本迭代节奏同时提倡，通过回归测试和版本发布后置进行优化。即在研发迭代之后，再进行回归测试和版本发布活动。这样做的前提是「需求澄清前置、流式开发、质量内建」等实践已经建立，移交质量能够得到充分保障，因此，回归测试阶段发现缺陷的概率变得很低。
综合前面描述，下图为详细到每日安排的 RISE版本迭代日历：
按上面迭代日历所示，对研发团队来说，在一个研发迭代内将拥有：
已经得到充分澄清的需求
8 天的开发时间
6 天的测试时间
2 天的缺陷修复时间
这样的时间分布，对于以双周迭代运行的团队来说，保障交付质量的各阶段时间已经相当充足了。并且，由于整个开发过程中并行事项较少，团队可以减少相互间的打扰，更加专注，交付效率也随之获得提升。
按照上面的迭代日历，进行双周迭代时，需要注意下面两点：
合适的需求粗细粒度。把需求拆成合适的粒度以便于其流动，单个粒度需求尽量控制在2-3人天完成。
对当前迭代的需求进行分步移测。让测试可以从第一周的第3天至第二周的第4天，持续测试不同的需求，而非堆积到一个时间点，一次性移测。
读者可能会有疑问，增加了一个完整的需求迭代，是否相当于开发后置了？会不会减慢整体交付时效？
首先，我们要引入前置时间（Leadtime）这个概念。需求前置时间指从需求提出到完成上线的整个时间周期。它包含意向形成、需求讨论、设计定稿、开发、测试、上线发布几个时间段（如下图），Agilean 自研的敏捷组织管理工具知微，已经可以实现需求前置时间的分段统计：
需求前置时间能够很好地反映研发的响应速度，是我们倡导优化的核心指标之一。通过缩短需求前置时间，持续进行高质量、有价值的研发交付，也是组织推进敏捷的重要目的。
让我们推演一下，RISE版本迭代节奏在现实中的运行方式：
运行双周迭代的团队，在第一周的第1天收到一个复杂业务需求。首先，由产品经理进行需求澄清，与业务讨论并梳理业务规则。通常情况下，这个需求会在第三周（即开发迭代的第一周）投入开发，经过 10 天的开发和测试后，进入回归测试，并在第五周上线。
可以看到，该需求从想法提出到上线发布，一共耗费 4 周 + 4 天 = 32 天。对大部分团队、大部分复杂业务需求来说，32天的需求前置时间已经很快了。
另外，因为采用了流式开发模式，在迭代运行过程中，业务方可以加入紧急需求，顺延一些还未进入开发的低优先级需求。确保团队对紧急需求，有更快速、更灵活的响应能力。
本文以一个不理想的双周迭代案例开始，分析了团队在迭代过程中时常遇到的问题以及背后成因，并介绍了稳定高效的 RISE版本迭代节奏，以及详细的迭代运作日历。这是Agilean基于十年来在企业内推动敏捷落地的实践总结，希望可以给有类似困扰的团队，提供一些启发和思考。
在迭代落地的过程中，架构设计、流程控制、资源配置、人员能力等很多因素，都可能影响其效果。如果您的团队在迭代运作过程中遇到问题，欢迎随时与我们展开讨论。
随着Scrum框架的大量使用，敏捷团队面临的第二大挑战就是如何将业务分析师和架构师组合成活跃互动的团队成员。任何面临这一挑战的Scrum Master、经理、决策者都应该阅读本书。另外，所有参与敏捷项目的团队成员也将从本书获益。
可执行需求说明提炼方法要求人们在思维方式上做出改变。本书的重点也在于此。可执行需求说明提炼方法有助于缩小干系人希望软件能做什么（什么）和该软件的确能做什么（如何）之间的差距。可执行需求说明以一种使开发团队很容易根据可执行需求说明来验证软件的方法澄清需求，而这跟需求变更一样在频繁地发生。
部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们撤除。
本文分享自微信公众号 - 互联网PMO（tech_pmo）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。