很多团队上线了研发管理平台，迭代仍然跑在群聊里：需求记在文档中，代码提交不写单号，构建产物落在某个服务器的目录下。等要验收，谁也说不清这个包是哪一次提交构建出来的，出了问题只能翻聊天记录对时间。
平台里的功能都在，链路却没接通。在敏捷研发管理平台上跑通第一个迭代，实际要做的事并不多：五个步骤，两条中途分支，加一份可逐项核对的验证清单。目标只有一个------让一条需求走完全程，并且每一步都能查到对应的代码、构建和制品记录。
一、先定义"跑通"：最小闭环要闭环哪三段
先给判断：最小闭环指一条需求从提出到验收，全程的动作和数据落在同一条链路上，并且这条链路能被反向查证。
具体看三条线索是否查得通：
- 给一个需求单号，能查到它对应的代码提交、合并请求和评审记录；
- 给一个上线制品，能查到它是哪次提交构建的、对应哪条需求；
- 给一个缺陷单，能查到它是哪一轮验收发现的，以及修复它的那次提交。
三条都查得通，才算跑通。只要有一条断掉，功能开得再多，也只是把工作换了个地方做。
DORA（DevOps Research and Assessment）在软件交付绩效指标指南中，把变更前置时间、部署频率、失败部署恢复时间归为吞吐量，把变更失败率和部署返工率归为稳定性，并指出速度与稳定性在多数团队身上并不互相取舍，改进通常从缩小单次变更的批量开始。这条结论落到第一个迭代上很直接：把迭代范围压到能在一个周期内完整交付并验证的规模，比拉长周期、多塞需求更容易出结果。
二、动手前先定三件事
- 迭代长度固定下来。 一周或两周都可以，关键是固定，让团队对"什么时候必须把风险说出来"形成约定。
- 写清完成定义。 建议拆成四项：代码已合并、构建已通过、制品已入库、验收已通过。四项缺一，这条需求就不算完成。
- 空间、代码库和权限先建好。 这里要分清分工：禅道负责项目、需求与缺陷的管理，GitFox 承担从代码托管到制品发布的交付链，两者原生打通，需求单号可以直接关联到代码和制品。GitFox 是禅道 DevOps 方案内置的一体化交付引擎，底层自研，不依赖海外开源内核，支持私有化部署并适配国产服务器、操作系统和数据库。落地时先按产品线或事业部划独立业务空间，空间之间代码逻辑隔离；创建代码库时强制关联禅道中的产品，需求、代码和制品从源头就能对上号。主干分支提前设好保护规则，明确谁有合并权限、谁负责验收。
中国信通院牵头编制的《研发运营一体化（DevOps）能力成熟度模型》把成熟度划分为五个级别，覆盖敏捷开发管理、持续交付、技术运营、应用设计、安全及风险管理、组织结构、系统和工具等部分。第一个迭代不必对着整套模型铺开，先跑通其中从需求到发布的交付链路，其余能力后续按需接入。
三、五步跑通第一个迭代
这五步的顺序不能换，上一步的产出就是下一步的输入。
1. 建空间、产品与代码库
在敏捷研发管理平台里新建业务空间，把这一轮要做的产品建起来，再创建对应的代码库并关联到该产品。主干设为受保护分支，禁止直接推送。
产出：一个产品、一个代码库、一条可用的分支规则。
通过信号：开发在受保护分支上直接推送会被拦下，必须走合并请求。
2. 用一个迭代目标收住需求范围
迭代开始前先写一句迭代目标，说明这一轮要改善什么。需求从待办列表里挑，不临时抓取；每条需求写清验收条件，再拆成可执行的任务。判断一条需求能不能进本轮，问三个问题：是否服务于本轮目标，验收条件是否清楚，扣掉休假和维护工作后团队还有没有容量。
产出：一句迭代目标、一组带验收条件的需求、拆解后的任务。
通过信号：团队和业务方能用同一句话复述本轮目标；每条需求都能说出怎么算验收通过。
3. 提交、评审并绑定单号
开发在特性分支上提交，通过合并请求进入主干，评审通过才能合并。GitFox 提供双层评审：推送请求做推送前初审，合并请求做合入主干终审，支持多人会签和行内批注，未通过的代码无法合并。配合 Fit 客户端，本地 git push 会被拦截，必须先发起评审，提交备注需要绑定需求或缺陷单号。
产出：一次带单号的合并请求，以及对应的评审记录。
通过信号：主干上的每次合并都能追到一次评审记录和一条需求单号。
4. 让流水线产出制品
流水线支持按代码提交、合并完成、定时或手动触发，自动完成编译、单元测试和静态扫描；测试不通过或扫描命中高危规则时阻断构建。构建产物写入制品库，与本次代码提交、需求单号和版本标签绑定归档。
产出：一个可部署的制品和一条构建记录。
通过信号：在制品库打开这一轮的产物，能看到它对应的提交记录和需求单号。
5. 按约定验收并复盘
按第二步写下的验收条件逐条核对。不通过的转为缺陷单，指定修复人，走同一条链路修复后重新构建；通过的标记为可发布。复盘只回答两个问题：这一轮哪一步等得最久，下一轮改哪一个动作。
产出：明确的验收结论、闭环的缺陷单、一条可验证的改进行动。
通过信号：迭代结束时能说清本轮解决了什么问题、产出了什么、还留下了什么。
四、中途遇到两种情况怎么处理
1. 有人要插需求
先把新需求放进待办列表排队，由负责人重新排序，不直接塞进当前迭代。确实必须插的，就从本轮置换掉等量工作，而不是把总量往上叠。判断能不能插，用三道闸门：是否服务于本轮目标、验收条件是否清楚、剩余容量是否够。
2. 发布失败要回滚
先回滚到上一个稳定版本的制品，把服务恢复，再回到缺陷单上做定位。定位路径是反向的：从缺陷单找修复提交，从提交找构建记录，从构建记录找制品，确认受影响的版本范围。回滚能力要在第一个迭代里实际验证一次，哪怕是演练，等真出故障时再第一次尝试就来不及了。
五、第一个迭代结束后的验证清单
下表从链路可追溯的角度逐项核对，五项全部通过，才算最小闭环跑通。
| 检查项 | 核对动作 | 通过标准 |
|---|---|---|
| 需求到代码 | 从需求单号打开关联的代码提交 | 能查到本轮全部提交和合并请求 |
| 代码到制品 | 从制品库打开本轮制品详情 | 能看到对应提交、版本标签和需求单号 |
| 制品到发布 | 核对发布记录 | 线上发布的制品来自制品库，版本一致 |
| 缺陷到代码 | 从缺陷单反查修复提交 | 能找到修复提交和对应的评审记录 |
| 链路数据 | 打开效能看板 | 能看到本轮的提交、评审耗时和流水线成功率 |
五项里可以有一项暂时查不到，但要记录在案并排进下一轮；全部能查到之后，再考虑接入代码扫描、安全门禁和更细的效能度量。
如果希望先确认链路能跑通，可以申请试用环境，用一个示例项目走完这五步，再决定是否在本项目上铺开。
六、常见问题
**第一个迭代要不要把平台模块都开一遍？**不用。先开需求、代码库、评审、流水线、制品库这五块，能把一条需求从头走到尾就够了。代码扫描、效能度量这类能力放在第二个迭代之后接入，避免第一轮就在配置上耗掉全部精力。
**迭代长度定一周还是两周？**取决于团队能不能在一个周期内完成从需求到验收的全过程。跨团队协作多、依赖外部接口的，两周更容易留出缓冲；需求拆得足够小、验收条件清楚的，一周拿到的反馈更快。定了就不要频繁改。
**开发习惯直接推主干，不愿意走评审怎么办？**把评审变成流程动作，而不是靠自觉。主干设保护规则禁止直接推送，配合 Fit 客户端拦截本地推送，提交备注绑定需求或缺陷单号。规则卡住的是不合规的入口，评审通过后合并的路径并不比手工合并慢。
**没有专职 DevOps，流水线搭得起来吗？**流水线支持可视化拖拽编排，不必手写 Yaml；同类项目可以把通用构建、扫描流程保存为模板，新项目直接引用。
七、结语与下一步
第一个迭代的价值不在于交付了多少条需求，而在于团队第一次拿到一条完整可查的链路：需求、代码、构建、制品、验收，环环对得上。这条链路一旦跑通，后面的评审门禁、安全扫描、效能度量才有地方落。
下周可以做的三件事：
- 把迭代长度和完成定义写下来，让团队确认；
- 建好业务空间、代码库和主干保护规则；
- 挑一条小而独立的需求，用它完整走一遍五步，迭代结束时对着验证清单逐项核对。
若希望先看敏捷研发管理平台的链路实际怎么串起来，可以通过在线试用环境用示例项目跑一轮，或预约一次演示，按你们当前的研发流程走一遍从需求到制品的路径。