流式开发
以用户故事等小颗粒度需求为单位，让需求像水一样持续流向下一阶段，快速获得质量反馈，避免看板上的“浪涌式流动”。
Agilean 方法论 / 迭代与版本管理
RISE 版本迭代节奏
定义
RISE（Release-Iteration Schedule for Enterprise）是 Agilean 针对金融科技等复杂业务场景提出的版本迭代节奏。它在流式开发的基础上将版本与迭代解耦：把一个版本分成需求迭代和研发迭代，前一个版本的研发迭代与后一个版本的需求迭代并行，实现需求澄清前置；在发布流程复杂、生产质量要求高时，再将回归测试和版本发布后置，从而缓解双周迭代中的“小瀑布”和“死亡行军”。
- 英文全称
- Release-Iteration Schedule for Enterprise
- 框架类型
- 版本迭代节奏 / 迭代日历
- 适用场景
- 金融科技等需求复杂、质量要求高的业务
- 核心做法
- 流式开发、版本迭代解耦、需求澄清前置、回归发布后置
- 研发迭代时间
- 8 天开发、6 天测试、2 天缺陷修复（原文日历）
解决的问题
RISE 要解决什么问题
- 双周迭代要求需求在 1–2 天内完成分析和澄清，而复杂业务的需求澄清通常要 2–3 天，需求不清导致交付质量不合格。
- 交付质量差促使提测时间不断前移，开发只能加班赶工、自测联调敷衍，上线时仍然故障频发，团队“连滚带爬”。
- 一个版本的所有活动被压缩进同一个迭代，时间过于紧张。
- 迭代内部“一周开发、一周测试”，迭代变成小瀑布：开发完成的需求仍是在制品，测试被迫在上半周测上一个迭代，开发与测试的协作被割裂。
组成要素
RISE 的核心做法
版本与迭代解耦
延长版本存续时间，把一个版本分成需求迭代和研发迭代，前一个版本的研发迭代与后一个版本的需求迭代并行。
需求澄清前置
产品经理提前一个迭代与业务细化需求，研发迭代开始时，团队拿着已充分澄清的需求直接投入开发。
回归测试与版本发布后置
发布流程复杂、生产质量要求高时，在研发迭代之后再进行回归测试和版本发布。前提是需求澄清前置、流式开发、质量内建等实践已经建立。
RISE 版本迭代日历
细化到每日安排：一个研发迭代内拥有已澄清的需求、8 天开发、6 天测试、2 天缺陷修复；需求粒度尽量控制在 2–3 人天，并分步移测。
速查
双周迭代常见问题与 RISE 的对应做法
| 常见问题 | RISE 的做法 |
|---|---|
| 需求澄清时间不足，源头质量差 | 需求迭代与研发迭代并行，需求澄清提前一个迭代完成 |
| 迭代变成“一周开发、一周测试”的小瀑布 | 流式开发：小颗粒需求持续流动、分步移测 |
| 版本所有活动挤在一个迭代内 | 版本与迭代解耦，延长版本存续时间 |
| 上线前质量风险集中暴露 | 在质量内建基础上，回归测试与版本发布后置 |
| 担心整体交付变慢 | 用需求前置时间（Lead Time）衡量；原文推演一个复杂需求从提出到上线约 32 天 |
适用场景
什么时候适合使用 RISE
适合的情况
- 金融科技等复杂业务场景中，以双周迭代运行的团队长期加班、质量不稳定
- 需求澄清经常不充分，测试被迫压缩，迭代内部呈现小瀑布
- 发布流程复杂、生产质量要求高，需要在速度与质量之间取得平衡
使用边界与注意事项
- 流式开发对需求拆分提出更高要求，需求要被拆成可测试、可验收的细小单元，这是敏捷产品经理和敏捷教练需要具备的能力。
- 回归测试和版本发布后置的前提，是需求澄清前置、流式开发和质量内建已经建立。
- 架构设计、流程控制、资源配置、人员能力等因素都可能影响迭代落地效果。
框架关系
与其他 Agilean 方法框架的关系
延伸阅读
相关服务、产品、案例与延伸阅读
常见问题
关于 RISE 的常见问题
RISE 是什么？
RISE（Release-Iteration Schedule for Enterprise）是 Agilean 针对复杂业务场景推荐的版本迭代节奏：在流式开发基础上将版本与迭代解耦，需求澄清前置，必要时回归测试和版本发布后置。
为什么双周迭代在复杂业务中容易变成“死亡行军”？
双周迭代要求 1–2 天完成需求澄清，复杂业务往往不够；需求不清导致质量差，又促使提测前移、开发加班。同时一个版本的所有活动被压进同一迭代，迭代内部变成“一周开发、一周测试”的小瀑布。
如何识别迭代变成了“小瀑布”？
看板上所有事项集中在开发区域，部分卡片进入开发“已完成”列却没有卡片进入测试，呈现浪涌式流动；测试在上半周测上一个迭代的内容，开发与测试协作被割裂。
增加需求迭代会不会拖慢交付？
应以需求前置时间（从需求提出到上线）来衡量。原文推演：复杂需求在第一周提出并澄清，第三周进入开发，经 10 天开发测试后回归，第五周上线，共约 4 周加 4 天、32 天。流式开发还允许业务插入紧急需求、顺延尚未开发的低优先级需求。
实施 RISE 需要哪些前提？
需求要拆成可测试、可验收的小单元（单个需求尽量 2–3 人天），开发要采取自冒烟、代码评审等质量措施并分步移测；回归和发布后置则要求需求澄清前置、流式开发、质量内建已经建立。
RISE 和 ADAPT 是什么关系？
ADAPT 在规模化层面提出版本与迭代双维管理和需求澄清前置，RISE 则聚焦团队层面的版本迭代节奏，给出详细到每日安排的迭代日历，两者思路一致、可以配合使用。
想判断 RISE 是否适合你们的组织？可以从一个真实问题开始讨论。