冲刺规划：敏捷团队最佳实践

规划基础

一次高质量的冲刺规划需要有章法：回顾之前的冲刺，评估团队的实际能力，把目标定清楚。了解更多：IT团队的IT项目管理软件。

1. 规划的准备要提前开始。Product Owner至少要在会议前一天整理好backlog并排好优先级。开发团队也应该有机会提前看一遍user story，把不清楚的地方提出来。
2. 经典的时间分配规则：冲刺每持续一周，规划就安排两小时。两周的冲刺就是四小时，不过实践中，把这段时间拆成几次短会，通常比一口气开一场长会效果更好。

准备阶段

准备做不好，冲刺规划就不可能改进。这个阶段常常被轻视，可整个流程成不成，恰恰取决于它。

• Definition of Ready (DoR)规定了user story要达到什么标准才能放进冲刺。每个故事都应该有明确的验收标准、复杂度估算，并标出它依赖哪些其他任务。不遵守DoR，规划会议就会乱成一团，团队把时间都花在澄清需求上，真正的规划反而没做。
• Backlog refinement应该定期做，而不只是在冲刺规划前临时突击。通常的做法是拿出冲刺时间的10%来做这件事。团队可以每周开几次简短的细化会，把后面冲刺要用的故事逐步理顺。
• Velocity分析能让团队准确看清自己实际能交付多少。除了看最近3-5个冲刺的平均Velocity，还要考虑哪些因素会影响下一个冲刺的产出：已经安排的休假、节假日、积压的技术债，以及外部依赖。

规划会议

冲刺规划分两个有明确结构的阶段：先确定这个冲刺要交付什么，再确定选中的工作怎么做。两个阶段需要的输入不同，产出也不同，混在一起开，哪一段都开不好。

1. 团队和Product Owner一起定下冲刺目标，把选中的所有user story统一到这个目标下。目标要具体、可衡量，而且对每个参与者都有意义。不好的目标：“改善用户体验。”好的目标：“用户可以通过社交媒体一键注册。”
2. 开发团队把选中的故事拆成任务，并按小时估算。拆的过程中，常常会冒出在故事层面看不到的复杂度和依赖关系。单个任务不应超过8小时，超过的要继续拆成子任务。

角色与职责

冲刺规划要开得好，每个参与者都得清楚自己的角色，并在这个角色范围内做事。

• Scrum Master负责推动流程，把控时间盒，帮团队做出决定。Scrum Master不替团队拿方案，而是提出对的问题，让讨论始终有成效。
• Product Owner负责backlog的优先级，决定哪些功能先做。他们要讲得清每个故事的业务价值，回答开发团队的问题时也要足够具体，让大家能据此估算。
• 开发团队承诺交付结果。这份承诺必须由团队自己做出，不能从外面指派下来。团队自己许下的承诺，带来的动力和责任感跟被强加的目标完全不是一回事。

常见错误

• 高估自身能力，是冲刺规划里最常见的错误。团队总会揽下超出能力的工作，项目刚开始时或者某个冲刺刚顺利结束后尤其如此。执行上的原则是：宁可少承诺、多交付。承诺做不到，会消磨利益相关者的信任，也会打击团队在后面几个冲刺里的士气。
• 不留时间缓冲，是结构上的硬伤。冲刺计划应该预留10-20%的缓冲时间，用来应付意料之外的任务、bug和技术支持请求。这部分余量不要事先塞满额外的故事，它的作用就是消化每个冲刺里都会冒出来的计划外工作。
• 忽视依赖关系，会让冲刺进行到一半就卡住。所有外部依赖都要在规划时找出来并解决掉。如果任务要依靠其他团队或外部供应商，就得提前约定好时间，并在冲刺开始前拿到确认。

过程监控

不断改进规划过程本身，是成熟的Agile实践里的常规动作。复盘时，团队不仅要分析冲刺执行得怎么样，还要把规划质量当作一个单独的输入变量来审视。

分析指标：

• 估算准确性：对比每个故事和任务的计划用时与实际用时
• 完成故事的百分比：冲刺结束时，承诺的故事实际交付了多少
• 规划后冲刺中的变更次数：用来衡量规划是否稳定、需求是否清晰
• 规划花费的时间：对照标准的时间分配来跟踪，看是长期投入过多还是投入不足

Burndown图贯穿整个冲刺跟踪进度，问题能早早暴露出来，留出纠正的余地。一旦图上显示团队完不成计划的工作，就要及时调整：给剩下的任务重新排优先级，或者把优先级最低的user story移出冲刺。

调整规划

• 远程团队的冲刺规划需要专门调整。要配好专门的协作工具，并主动照顾到每个远程参与者，让大家都有发言的机会。在分布式团队里，把规划拆成几次短会，而不是一场长会，参与度和产出质量总是更好。
• 多个团队参与的大型项目，需要在项目层面做协调。Scrum of Scrums或SAFe(Scaled Agile Framework)提供了一套结构化的机制，让存在共同依赖的各个团队同步冲刺规划。
• 维护类项目的冲刺里有很大一部分时间花在支持和修bug上，所以要明确给计划外工作预留产能。常见做法是拿出冲刺产能的30-50%用于支持工作，其余用于开发新功能。如果把支持工作当成额外负担，不算进计划产能，交付就会出问题，这样分配正好能避免。

相关文章:

想了解项目管理框架和约束之间的平衡，可以读一读项目管理三角形:平衡范围、时间和成本。

想看Kanban看板和可视化工作流管理的实用介绍，可以阅读什么是Kanban看板?可视化工作流管理指南。

想看Kanban看板和可视化工作流管理的实用介绍，可以阅读什么是Kanban看板?可视化工作流管理指南。

Agile团队如何借助用户画像贴近真实的用户需求，可以参考Agile人物角色:在Agile项目中增强以用户为中心的开发。延伸阅读：看板。

结论

有效的冲刺规划需要系统的方法和持续的改进，而且要当作一项有意识的日常实践来做，不能等项目结束后才补上。复盘提供了一套结构化的机制，不仅能分析冲刺的执行结果，还能分析决定这些结果的规划输入。这样一来，规划过程本身也会经历Agile在产品开发中所用的那种迭代改进。