敏捷开发中，做 Sprint 计划的致胜要素
拳王迈克·泰森曾经说过：
军事领域也有类似的说法：
「没有哪条作战计划，在遭遇敌人之后依然奏效」
—赫尔穆斯·冯·毛奇
不管你投入了多少时间，你永远也无法制定出涵盖一切可能的计划。计划无法覆盖所有情景和敌人的每一次行动。现实太过复杂，不可预测。
除非你是一流的团队。
为了应对现实的复杂和不确定性，所有的作战计划都会伴随着一条「指挥官意图」（CI）。
盟军在 D 日（军事术语：战斗打响的当天，此处特指诺曼底登陆战役）的指挥官意图是：
当一切陷入混乱，计划被现实打破，指挥官意图依然可以为军队提供支持。CI 传达的是任务目的和目标。即便最初的计划已经失效，目的和目标依然有效。
指挥官意图的存在意义就是避免让计划变得目标更重要。
通过对任务目的和目标的了解，执行人员享有按照原计划精神作出决定的自由，它能够促进团队合作，并将新的信息纳入战场决策。
结果就是更好的计划和更好的产出。
在 Scrum（迭代式增量软件开发过程，通常用于敏捷软件开发）中， 每个Sprint（1 个 2-4 周的开发周期，开发团队承诺交付一定的可用软件增量）， 团队都会制定计划来完成一定的 Product Backlog（产品需求）。每个 Sprint 的「指挥官意图」被称为 Sprint 目标。
Sprint Planning（冲刺计划）抵制专注于产品需求列表的冲动
作为产品负责人，我们会花大量时间制订完美的 Product Backlog（产品需求列表），一个精心规划的 Product Backlog 能够让我们的产品愿景成为现实。
当 Sprint Planning （冲刺计划）开始时，注意力会不由自主聚焦在产品需求列表上。最终只产出完成所选需求项的排期。毕竟我们已经在整理清晰完善的需求列表上花了很多的时间和精力。
从产品需求列表开始本身就是个错误。
如果把需求列表放在 Sprint Planning （冲刺计划）的第一位，那么计划和接下来的工作就会比目标更重要。冲刺目标就会变成由所选的工作所产出的结果。
作为产品负责人，我们有责任从目标结果开始我们的思考。专注于 Sprint 的产出，而不是展示完成目标的步骤和计划。
通过制定明确的冲刺目标（Sprint Goal ），我们得以清楚的表达我们的指挥官意图-在这个 Sprint 中我们要达成的目的。从而授权团队成员在冲刺的过程中作出正确的决策，而无需依赖产品负责人。
Sprint Goal（冲刺目标）冲刺的指挥官意图
任务清单、待办事项以及交付计划应该是灵活可变的。Sprint Goal (冲刺目标)，在 Scrum 团队达成一致后，是不可变的。
这就是为什么只有当 Sprint 目标失效时，Sprint 才会被取消。因为只要目标存在，就像北极星一样可以为团队决策提供方向。
讨论过 Sprint 内需要完成的工作项就启动冲刺，几乎没有时间制作工作项的完成计划—这是新手团队。
更进一步，制定可以跟踪冲刺每天进度的计划，但是目标就算存在也只是完成后总结—这是一般团队。
从 Sprint Goal （冲刺目标）出发，协同团队产出最终的目标，按照目标的需求确认需求列表并制定计划-这是伟大的团队。
下次准备做冲刺时试着从 Sprint Goal 冲刺目标开始
目标将闲逛转变为追逐—Mihaly Csikszentmihalyi （芝加哥大学心理学教授「心流」理论提出者）
José Francisco Carle Carrera 制作了一张图片，用更好更直观的方法总结了这篇文章， 在接受他的祝福之后，我决定把他的作品也放进来。
接下来我们回到原来的结论：
军队了解现实太复杂，充满了不确定性，计划往往无法执行。
为了解决这个问题，所有作战计划都对应有明确的指挥官意图（CI） 。指挥官意图解释原计划的目标和目的。
指挥官意图确保：
它允许团队制定计划，选择满足 Sprint Goal 的 Product Backlog Items 需求进行开发。
从冲刺目标出发有许多的益处：
所以下次开始准备冲刺的时候，不用急于展示漂亮的开发需求列表。提出明确的冲刺目标，然后和团队共同制定最终版本。 通过目标来产出开发清单和执行计划。 计划会更好，结果会更好，人们也会更快乐。
原文：https://productcoalition.com/the-only-thing-that-matters-when-planning-a-sprint
标题： The only thing that matters when planning a Sprint
作者：Maarten Dalmijn
翻译：金玉
