---
title: "RISE:适合复杂业务场景的版本迭代节奏"
url: https://www.agilean.cn/insights-new/42/
updated: 2023-12-13
description: "RISE 是 Agilean 针对金融科技等复杂业务提出的版本迭代节奏。本文分析双周迭代“小瀑布”和“死亡行军”的成因，给出版本与迭代解耦、需求澄清前置、回归发布后置的做法和详细的迭代运作日历。"
publisher: "Agilean（爱捷软件开发（深圳）有限公司）"
language: zh-CN
---

分析了众多敏捷实施失败案例，Agilean 发现大多数情况下，版本迭代节奏与组织、业务特点不匹配，是导致敏捷失败、「两头不讨好」的根本原因之一。因此，我们推荐了一种适合复杂业务场景的版本迭代节奏，以及详细的迭代运作日历。这也是 Agilean 基于十年来在企业内推动敏捷落地的实践总结，希望可以给有类似困扰的团队提供启发和思考

# RISE:适合复杂业务场景的版本迭代节奏

作者：编辑部 发布于 2022/4/18 更新于 2023/12/13

## RISE：适合复杂业务场景的版本迭代节奏

> 由于某些不恰当的实施方式，敏捷导入有时在企业里处于「两头不讨好」的尴尬状态：业务认为敏捷是造成低质量交付的推手，而研发觉得敏捷是管理者压榨团队的帮凶。
>
> 通过分析众多敏捷实施失败案例，我们发现大多数情况下，**版本迭代节奏不匹配组织和业务特点**是导致失败的根本原因之一。本文将结合 Agilean 咨询团队的实践经验，推荐一种适合复杂业务场景（如金融科技）的版本迭代节奏：RISE（Release-Iteration Schedule for Enterprise)。

介绍 RISE 之前，让我们先看一下，在复杂的业务场景中，传统的双周迭代会遇到什么问题。

## 双周迭代？还是死亡行军？

我们曾对一个采用「双周迭代」的研发团队进行了访谈：

> 双周迭代，指每两周进行一次发布。这意味着从业务侧承接过来的需求，要在1-2天内完成需求分析和澄清。但对很多复杂业务场景来说，需求澄清通常要花2-3天才能真正完成。现实中很多的交付质量不合格，就是由需求不清晰这个源头问题造成的。

> 交付质量差，会促使人们不断将「功能移交测试时间」前移，比如要求迭代第二周开始之前提测，以避免上线风险。于是，开发同学必须加班加点，自测、联调也只能对付了事，上线时候还是一堆的故障。

最后，他对当前状态进行了这样的评价：

> 做软件研发，大脑是我们最重要的生产工具。但团队一直处于又紧张又疲惫的状态，别说高质量交付了，连最基本的质量都难以保证。**这不是在做迭代，而是连滚带爬，「死亡行军」**。

在调侃的语气中，我们仍能感受到满满的无奈和倦意。仔细分析上面状况的产生，能发现两个主要原因：

- 团队将一个版本的所有活动，都**压缩进入了同一个迭代**。对于一些复杂业务和复杂系统，这样做往往导致**时间过于紧张**。
- 迭代内部以「一周开发，一周测试」的方式运行，这种情况下，**迭代变成了小瀑布**。

## 解决思路：用流式开发破解小瀑布

如何发现「小瀑布」？来瞧瞧下面这个看板：

![典型的小瀑布看板](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-1.png)

上图中，团队所有事项都集中在开发区域。有些卡片进入了开发的「已完成」列，没有任何卡片进入「测试」。**看板呈现了浪涌式流动**——这就是团队以小瀑布方式运行的表现特征（参考下图）。

![团队小瀑布方式表现](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-2.png)

在小瀑布模式下，为了避免资源浪费，往往将迭代时间按流程切开，比如上半周开发，下半周测试。

听起来很有「节奏」，对不对？问题来了，测试在上半周的时间里，要做些什么？在现实中，**上半周往往用来测上一个迭代的内容**，于是，**团队中开发测试的协作被强行割裂**（如下图）。

![小瀑布模式下，强行割裂了开发测试的协作关系](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-3.png)

**小瀑布模式的核心问题在于，「开发完成」并不是真的完成，还属于WIP（在制品），并不能产生真正的质量反馈**。开发完成的需求，在测试时可能暴露出大量缺陷，造成返工。迭代管理的核心目标是降低交付风险，确保质量可控，但小瀑布模式显然无法有效实现这点。

如何破解小瀑布？我们通常建议**团队采用「流式开发」**。即以小颗粒度需求（如用户故事）为单位，让需求像水一样不断向下个阶段流动，从而快速获取反馈，真正达到利用迭代管理降低风险的目标（如下图）。

![Agilean 建议流式开发模式，快速流动获得反馈](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-4.png)

图 / Agilean 建议流式开发模式，快速流动获得反馈

以「流式开发」运行的迭代，看板往往呈现下面的变化形式：

![采用流式开发后迭代看板的变化](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-5.png)

图 / 采用流式开发后迭代看板的变化

诚然，**流式开发对需求拆分提出了更高要求，需求要被拆解成可测试可验收的细小单元**。其实，这是敏捷产品经理和敏捷教练需要具备的硬核技能，也是敏捷需求管理的基础。

另外，为了减少开发测试工作的并发打扰，开发人员要采取开发自冒烟、代码评审等质量措施，来保证需求的顺畅流动（这方面的详细内容可以参见[FLEET 框架](https://www.agilean.cn/insights/fleet/)）。

## 解决思路：将版本和迭代解耦

针对复杂业务研发场景，**RISE 倡导在流式开发基础上，将版本和迭代解耦**。延长版本存续时间，**将一个版本分成需求迭代和研发迭代**，前一个版本的研发迭代和后一个版本的需求迭代并行。

![RISE 框架推荐版本迭代解耦，需求澄清前置](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-6.png)

图 / RISE 框架推荐版本迭代解耦，需求澄清前置

上面描述的版本迭代节奏，使团队可以实现**需求澄清前置**，即由产品经理提前一个迭代与业务人员进行需求细化。在研发迭代开始时，团队拿着已经充分细化澄清的需求，直接投入开发工作。

对于发布流程复杂、生产质量要求高的情况，RISE 版本迭代节奏同时提倡，**通过回归测试和版本发布后置进行优化**。即在研发迭代之后，再进行回归测试和版本发布活动。这样做的前提是「需求澄清前置、流式开发、质量内建」等实践已经建立，移交质量能够得到充分保障，因此，回归测试阶段发现缺陷的概率变得很低。

![质量要求高时，RISE 建议回归发布后置进行优化](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-7.png)

图 / 质量要求高时，RISE 建议回归发布后置进行优化

综合前面描述，下图为详细到每日安排的 **RISE版本迭代日历**：

![Agilean 推荐的 RISE 版本迭代日历](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-8.png)

图 / Agilean 推荐的 RISE 版本迭代日历

按上面迭代日历所示，对研发团队来说，在一个研发迭代内将拥有：

- 已经得到充分澄清的需求
- 8 天的开发时间
- 6 天的测试时间
- 2 天的缺陷修复时间

这样的时间分布，对于以双周迭代运行的团队来说，保障交付质量的各阶段时间已经相当充足了。并且，由于**整个开发过程中并行事项较少**，团队可以减少相互间的打扰，更加专注，交付效率也随之获得提升。

按照上面的迭代日历，进行双周迭代时，需要注意下面两点：

- 合适的需求粗细粒度。把需求拆成合适的粒度以便于其流动，单个粒度需求尽量控制在2-3人天完成。
- 对当前迭代的需求进行分步移测。让测试可以从第一周的第3天至第二周的第4天，持续测试不同的需求，而非堆积到一个时间点，一次性移测。

## RISE 能否满足业务时效要求？

读者可能会有疑问，增加了一个完整的需求迭代，是否相当于开发后置了？会不会减慢整体交付时效？

首先，我们要引入\*\*前置时间（Leadtime）\*\*这个概念。**需求前置时间指从需求提出到完成上线的整个时间周期**。它包含意向形成、需求讨论、设计定稿、开发、测试、上线发布几个时间段（如下图），Agilean 自研的敏捷组织管理工具知微，已经可以实现需求前置时间的分段统计：

![知微对需求前置时间进行分段统计](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/RISE/RISE-9.png)

图 / 知微对需求前置时间进行分段统计

需求前置时间能够很好地反映研发的响应速度，是我们倡导优化的核心指标之一。通过**缩短需求前置时间，持续进行高质量、有价值的研发交付**，也是组织推进敏捷的重要目的。

让我们推演一下，RISE版本迭代节奏在现实中的运行方式：

> 运行双周迭代的团队，在第一周的第1天收到一个复杂业务需求。首先，由产品经理进行需求澄清，与业务讨论并梳理业务规则。通常情况下，这个需求会在第三周（即开发迭代的第一周）投入开发，经过 10 天的开发和测试后，进入回归测试，并在第五周上线。

可以看到，**该需求从想法提出到上线发布，一共耗费 4 周 + 4 天 = 32 天**。对大部分团队、大部分复杂业务需求来说，32天的需求前置时间已经很快了。

另外，因为采用了流式开发模式，在迭代运行过程中，业务方可以加入紧急需求，顺延一些还未进入开发的低优先级需求。确保团队对紧急需求，有更快速、更灵活的响应能力。

本文以一个不理想的双周迭代案例开始，分析了团队在迭代过程中时常遇到的问题以及背后成因，并介绍了稳定高效的 RISE版本迭代节奏，以及详细的迭代运作日历。这是 Agilean 基于十年来在企业内推动敏捷落地的实践总结，希望可以给有类似困扰的团队，提供一些启发和思考。

在迭代落地的过程中，架构设计、流程控制、资源配置、人员能力等很多因素，都可能影响其效果。如果您的团队在迭代运作过程中遇到问题，欢迎随时与我们展开讨论。

Agilean 方法论

## 本文相关的 Agilean 方法框架

- [迭代与版本管理](https://www.agilean.cn/methodology/rise-release-iteration-schedule/)：RISE 版本迭代节奏；版本与迭代解耦、需求澄清前置，破解复杂业务下双周迭代的“小瀑布”。

## 订阅洞见

新文章发布时，通过邮件第一时间收到。

推荐阅读

- [DEF 面向研发团队的绩效指标框架](https://www.agilean.cn/insights-new/43/)
- [精益研发效能提升框架 FLEET：提速增质的无限可能](https://www.agilean.cn/insights-new/44/)
- [DEER：研发效能提升路线图](https://www.agilean.cn/insights-new/45/)
- [ADAPT-中国金融企业规模化敏捷框架](https://www.agilean.cn/insights-new/46/)
- [聚焦研发效能度量5年时间，6点思考与沉淀](https://www.agilean.cn/insights-new/47/)
- [OKR的组织落地之旅：一步天堂，一步地狱](https://www.agilean.cn/insights-new/48/)
- [Agilean 2020年终巨献：数智化敏捷银行路线图](https://www.agilean.cn/insights-new/49/)
- [金融组织数字化研发管理的12种武器](https://www.agilean.cn/insights-new/50/)
- [数字时代组织效能的秘密](https://www.agilean.cn/insights-new/51/)
- [研发组织该如何设计绩效体系？](https://www.agilean.cn/insights-new/52/)
- [Google的软件工程概述](https://www.agilean.cn/insights-new/53/)
- [首发！第15份中文版全球敏捷状态报告来了](https://www.agilean.cn/insights-new/54/)
- [从0-1做产品快速启动，大型干货案例分享](https://www.agilean.cn/insights-new/55/)
- [你理解的精益可能是错的！——从源头重新解读精益](https://www.agilean.cn/insights-new/56/)
- [9个从零开始的B端产品自动化测试实践](https://www.agilean.cn/insights-new/57/)
- [金融组织做规模化敏捷怎么划小队，一文讲清](https://www.agilean.cn/insights-new/58/)
- [银行规模化敏捷速赢术第一式：部落制](https://www.agilean.cn/insights-new/59/)
- [从进化角度看规模化敏捷，上海银行4500+人实施案例——2023RSG大会演讲实录](https://www.agilean.cn/insights-new/60/)
- [软件国产化大潮下，这家金融企业是怎么替换Jira的](https://www.agilean.cn/insights-new/61/)
- [交付时效提升21%，宁波银行规模化敏捷试点这一年](https://www.agilean.cn/insights-new/62/)
- [上海银行｜用知微支撑全行2500人研发数字化管理转型](https://www.agilean.cn/insights-new/63/)
- [万字长文，细说长沙银行的数字化研发管理转型之路](https://www.agilean.cn/insights-new/64/)
- [日产万行业务代码背后，我们真正修的是一条 Harness 公路](https://www.agilean.cn/insights-new/65/)
- [AI强了，为什么组织还没变快？](https://www.agilean.cn/insights-new/66/)
- [当 AI 开始理解企业：金融复杂系统下的智能体实践](https://www.agilean.cn/insights-new/67/)
- [利用本体论和 EntClaw 构建软件开发生产线](https://www.agilean.cn/insights-new/68/)
- [别再拿“随缘发版”当版本火车了：跨越研发管理中“知道”与“做到”的生死线](https://www.agilean.cn/insights-new/69/)
- [从工作流到价值流：组织效能提升成不成，关键看这步 “转场”！](https://www.agilean.cn/insights-new/70/)
- [研发价值流：回退不是“后悔药”，警惕异常状态拖慢交付效率](https://www.agilean.cn/insights-new/71/)
- [AI时代的研发效能进化：从单点提效到组织重塑](https://www.agilean.cn/insights-new/72/)
- [对话吴穹：软件开发的终局，是我们将迎来自己的“黑灯工厂”](https://www.agilean.cn/insights-new/73/)
- [当CIO回答“我回去了解一下”的时候，科技就已经输了](https://www.agilean.cn/insights-new/74/)
- [研发的结构性拥堵，版本火车如何建立节奏与共识？](https://www.agilean.cn/insights-new/75/)
- [AI时代科技组织该怎么做？——先提质，再增效](https://www.agilean.cn/insights-new/76/)
- [最新预测：DeepSeek时代，科技组织即将发生的12大变化](https://www.agilean.cn/insights-new/77/)
- [破局研发管理困境：敏稳双态下的研发效能洞察](https://www.agilean.cn/insights-new/78/)
- [BizDevOps：从理念到实践，贯通企业全链路协同](https://www.agilean.cn/insights-new/79/)
- [解锁研发效能：平台工程的建设策略与实践](https://www.agilean.cn/insights-new/80/)
- [揭秘科技组织度量中心：构建透明、量化、高效的科技管理新体系](https://www.agilean.cn/insights-new/81/)
- [研发效能度量中心的底层逻辑](https://www.agilean.cn/insights-new/82/)
- [从测试本质看质量](https://www.agilean.cn/insights-new/83/)
- [管好研发团队四大要义](https://www.agilean.cn/insights-new/84/)
- [规模化敏捷下小队的协作机制](https://www.agilean.cn/insights-new/85/)
- [科技团队治理能力成长路线图](https://www.agilean.cn/insights-new/86/)
- [什么是引导？引导能为你带来什么？](https://www.agilean.cn/insights-new/87/)
- [提升代码质量：代码检查工具规模化使用实践](https://www.agilean.cn/insights-new/88/)
- [一窥科学管理：从误解到理解、再到构建](https://www.agilean.cn/insights-new/89/)
- [战略管理：质疑模型，理解模型，构建模型](https://www.agilean.cn/insights-new/90/)
- [6个原则+15项举措，重塑敏捷组织的绩效管理（下）](https://www.agilean.cn/insights-new/91/)
- [6个原则+15项措施，重塑敏捷组织的绩效管理（上）](https://www.agilean.cn/insights-new/92/)
- [合作模型与组织设计思考](https://www.agilean.cn/insights-new/93/)
- [渐进与激进的舞台，变革管理的艺术](https://www.agilean.cn/insights-new/94/)
- [管理变革思想，竟藏在运动康复之中？](https://www.agilean.cn/insights-new/95/)
- [看板方法：始于可视化，成于管理机制](https://www.agilean.cn/insights-new/96/)
- [数字化转型，组织架构先行](https://www.agilean.cn/insights-new/97/)
- [从推动到拉动：研发效能提升的第一性原理](https://www.agilean.cn/insights-new/98/)
- [3步，手把手教你用数据开好回顾会](https://www.agilean.cn/insights-new/99/)
- [一法则，一定理，数据驱动管理必备理念](https://www.agilean.cn/insights-new/100/)
- [魔幻的数字7±2 ——小队规模的底层逻辑](https://www.agilean.cn/insights-new/101/)
- [要管理，先可视](https://www.agilean.cn/insights-new/102/)
- [详述银行业数字化转型中的敏捷变革](https://www.agilean.cn/insights-new/103/)
- [数字化金融企业的产品体系长啥样？](https://www.agilean.cn/insights-new/104/)
- [研发效能度量的两大法宝、四大法门和七种武器](https://www.agilean.cn/insights-new/105/)
- [敏捷与规模兼得的高绩效组织打造](https://www.agilean.cn/insights-new/106/)
- [踩了那么多坑后，我们为什么还是要做目标管理？](https://www.agilean.cn/insights-new/107/)
- [从Cynefin框架重新理解不确定性管理](https://www.agilean.cn/insights-new/108/)
- [AI时代更需要敏捷组织](https://www.agilean.cn/insights-new/ai-era-agile-organization/)
- [WorkBuddy正当红，但Agent的未来不在聊天框](https://www.agilean.cn/insights-new/workbuddy-agent-future-not-chatbox/)

联系我们

发送邮件

联系方式

地址

深圳市南山区粤海街道南油社区建南路15号恒大天璟A座A2902

邮箱

contact@agilean.cn

---

来源：[RISE:适合复杂业务场景的版本迭代节奏](https://www.agilean.cn/insights-new/42/)（更新于 2023-12-13）