版本火车怎么做？

• “每周至少一个版本，还有一堆临时版本”不是版本火车，而是“随缘发版”：需求做完才考虑集成和发布，版本计划频繁变动，缺少集体约束力。
• 版本火车追求“目的地参团”：有明确的集合时间（版本发布日期）和统一的行程（版本计划），所有团队按约定时间汇合，过程灵活、结果对齐。
• 在 SAFe 中，Agile Release Train（敏捷发布火车）指一般 50–125 人、长期存在的“团队之团队”；Agilean 文章中的版本火车侧重跨团队共同排期、按时到站的机制，两者用词相近但关注点不同。

多团队版本火车特别适合金融等大型企业中既有高速响应的敏捷团队、也有稳定支撑系统的传统团队的“敏稳双态”场景。

• 宁波银行试点的版本节奏为：2 周需求准备 + 2 周开发测试 + 2 天新增回归 + 2 天全量回归 + 4 天版本准备。
• 投产日在排期中最先确定；回归完成当天为封版日，即投产日 T-4。非常规版本从投产日向前倒推，研发和测试时间等比例缩放。
• 开发测试同频、形成双周发布节奏，需要把用户故事拆小，研发工作量尽量控制在 3–10 人天，形成流式提测。
• RISE 迭代日历给出团队层的另一种安排：版本与迭代解耦、需求澄清前置，一个研发迭代内为 8 天开发、6 天测试、2 天缺陷修复。

1. 01

   确定投产日历

   先定投产日，再倒推封版、回归、开发测试和需求准备的时间点。

2. 02

   容量优选

   透明各团队产能，只承诺当前或下一个版本能完成的需求，不做全量承诺。

3. 03

   需求准入与澄清前置

   建立需求准入和变更规则，在研发开始前完成需求澄清。

4. 04

   共排期

   版本启动前，相关团队共同协商并约定抵达版本发布的时间。

5. 05

   重承诺 + 主辅机制

   强关联的跨团队需求赋予最高优先级；每个关键需求明确牵头团队（主）负责计划拉齐、协调、状态检查和风险预警，配合团队（辅）积极响应。

6. 06

   补齐工程实践

   制定分支策略、环境管理、自动化测试、测试数据等细则，排除版本火车的落地障碍。

7. 07

   用需求前置时间检验

   以需求从提出到上线的时长（DEF 的“快”）检验节奏是否满足业务时效，并持续回顾改进。