R2.12.1design one iteration ahead设计
设计提前一个迭代交付可减少互相等待
别名: 设计领先一个迭代 · 管道式交付 · design lead time
概念解释
设计和实现若在同一个迭代里同时开工，两边都会卡在对方还没给的东西上：实现等可建造的稿，设计等做出来才暴露的约束。设计提前一个迭代交到「可建造」，实现做本轮时设计已经在做下一轮，队列里的互相等待会缩短。
提前的是一份实现可以开工的交付物，不是把探索时间也硬塞进领先位。仍在比方向的稿提前交出去，只会把等待换成返工。
机制
同一条目上，实现的开工条件是足够明确的结构、状态和文案范围；设计要吸收实现反馈，又依赖实现已经开始。两边对准同一条、同一天，形成的是环形等待：实现空转，设计也因为没有建造中的问题而停在猜测里。把设计输出错开一个迭代，环被拆成管道——实现消费上一轮已经签字的稿，设计生产下一轮的稿，中间用「可建造」而不是「还在探索」做交接。
等待来自同时开工造成的排队，不是来自谁更勤奋。领先过量（两三个迭代的存货）会让设计在实现碰到问题之前走得太远，管道同样会堵，只是堵在下游的大改。一个迭代的领先对应的是「实现正在消化的那一份」和「下一份正在被写完」刚好衔接。
边界
人手不足以分出两条并行工作的两人小组，同一人既画又写，提前一个迭代没有独立的消费者，节奏规则用不上。线上故障、当天必须修的缺陷，没有「下一轮」可领先。实现若被接口、数据或发布窗口挡住，设计提前交稿也消不掉那段空档，空档不在设计队列里。探索还没收敛的条目放进领先位，实现拿到的是未完成输入，等待会变成来回打回。周期短到只有几天的团队，一个迭代的领先可能过长，改成按可建造队列而不是按日历迭代来错开。
怎么落地
- 迭代计划只从「可建造」列拉设计已签字的条目；本轮设计位留给下一轮要实现的条目。
- 给「可建造」写明门槛：主路径、关键状态、真实文案或已标明的变量范围；缺门槛的稿不准提前交。
- 控制存货：可建造列保持大约一轮的量，不要堆成三轮以后的设计库存。
- 验证：连续两个迭代统计「实现第一天有没有可开工的稿」和「设计是否在等实现先做完才能继续」。前者为否或后者为是的次数，就是错位没形成管道。