Sprint

Sprint 原本是 Scrum 专有的术语，后来渗进日常用语，泛指任何短的、时间盒式的工作单元。原始定义要求三件事：一个固定长度、开头的一次计划会议、结尾的一次评审。多数团队保留前两个、去掉了第三个，所以很多团队把节奏叫「Sprint」，却产不出可演示的增量。没有演示的 Sprint 只是一个截止日期；没有回顾的 Sprint 是一台跑步机。

时长很重要。一周 Sprint 强迫范围收紧，能很快暴露交付问题。两周 Sprint 留出做实质工作的空间，但吸收更多偏移。三周 Sprint 几乎一定会变成两个糟糕计划的 Sprint。

沉默的失败，举个实际例子：一支团队跑了六个月的两周「Sprint」，每场计划会议都开了，却没发布出任何一个利益相关者能点击的东西。董事会不断滑坡，因为工作是按希望来估的、而不是按装得下的来估，而且没有一次评审强迫团队去直面一个可运行的增量。修法既残酷又简单：每个 Sprint 结束时，团队之外的某个人必须能用上造出来的东西。如果他用不了，那这个节奏就是表演，缩到一周 Sprint 通常会在两周内暴露出原因。

诚实的取舍与创始人最常犯的错误：把 Sprint 当成命中一个固定外部截止日期的方式。这个节奏是围绕「固定时间盒、浮动范围」来构建的，恰恰与「硬上线日期加固定范围」相反。对真正由日期驱动、范围固定的工作，你要的是一份带明确 SDLC 里程碑的固定价格计划，而不是一块 Sprint 看板。Sprint 适合持续的 Agile 交付和朝 MVP 的迭代工作；它不太适合研究和设计工作，那种场景下一段带书面总结的时间盒探索胜过一次被强加的演示。它们还依赖 CI/CD 的健康，因为一个在结束时无法发布的 Sprint 不是 Sprint。