在很多研发团队中，都会存在一个问题：研发团队超负荷运转，但好像依然无法交付一个令人满意的完整功能。
人们在迭代跟进和日常站立会时的焦点，集中在看板和任务积压上。用户故事（或者说需求）的完成情况是整个团队关注的核心问题，大家的讨论集中在：怎么能快速实现所有的需求，事务之间的依赖关系和顺序是怎样的。
然而这是有问题的：团队会因为眼中只有树木而失去对森林的认知。我们很容易忘记：用户故事只是完成一项计划所需的一个或一组工作项，而非价值本身。 但工作只有在交付了最终价值时才是重要的。
只见树木不见森林
一个团队中，如果大家只关注自己当前的需求积压情况，是很难将自己的工作与公司的整体战略联系起来的。（就算有Okr也很难 by 小编）
项目负责人们经常发现自己处于一种艰难的境地：看不到真实的进度看板。他们往往难以确切地知道项目何时能完成开发，毕竟看板≠交付进度。有时候任务早就完成了，看板还停在todo阶段；有时候工作还没收尾，任务卡就已经被拖到了完成列……
于此同时，当需求被拆分成N个用户故事后，在迭代规划中产研团队经常会忽略掉「胶水步骤」，即：在故事开发完成后到可以正式发布前的“最后一公里”，对产品功能进行润色、微调，使之具有更高可用性的步骤。
这就好比拼乐高。在一月份，团队达成了一致的目标：Q1我们要建立一座神话般的城堡。接着，我们估算了搭建城堡所需要的乐高积木的类型及数量（就像用户故事），并把它们都挑出来堆在房间里。然后，我们开始疯狂拼装，并相信等到到三月快结束的时候，只要把各个部分组装到一起，城堡就能成型。结果是到了三月份，城堡各部件可能进度不一，其衔接方案也并未真正就绪。
在这篇文章中，我希望给研发团队提供一种新的思路：让阶段目标成为迭代规划的牵引绳。
在做迭代规划和跟进开发节奏的时候，这是一种微妙但宝贵的转变，让「阶段目标」去主导大家的交流。用户故事对于估算、分配、协调工作，仍然是至关重要的，但整个团队都需要意识到，用户故事只是一种工具，是开发的过程，而不是交付的终点。
「故事」和「阶段目标」
一堆“用户故事”是很难直接拼合成“产品价值”的。
如果一个研发团队认为自己的工作就是翻来覆去地“做需求”，那么他们将给其他岗位的同事（通常是项目经理或产品经理）带来相当沉重的负担去填补空白、修正问题、适应变化。结果往往是项目会在“几乎完成”的状态下停留过长时间。
当迭代规划会只是为了从积压列表里砍需求的时候，“我们已经决定要做某个需求”的想法会压过“我们需要交付怎样的价值”。也因此，“打造一个相对完善的功能并对客户发布”的目标就可能被弱化，甚至变得遥遥无期。
但「阶段目标」是不同的，它在有目的地叙述：“我们想做这件事，是为了达到什么目标、交付怎样的价值。”「阶段目标」的核心信息是：专注于价值。
填补需求之间的空白，将成为每个人工作的一部分。团队成员将能依据价值目标，拒绝不相关的任务，或者自由地做出合理的调整。这时，成员们才能感知到项目整体状态，并能对此持有更积极的态度。
我们可以将「阶段目标」看做一系列小的里程碑，他们是产品实现价值交付的基本单位，也利于简单地向内部成员和外部利益相关者解释自身的进度。这些小的里程碑像是你要求团队攀登的山；当他们到达一个顶峰时，团队可以一起庆祝阶段的胜利，并把目光投向下一座高山。
为什么不用「史诗」？
看到这里，一些熟悉敏捷概念的人或许已经想问：这不就是史诗（Epic）吗？
一定意义上，是的。如果用法正确，史诗Epic确实可以用于标识「阶段目标」。毕竟史诗的定义就是：一个由故事集合而成的可交付目标。
然而，在实践中，史诗或者被误解或者被滥用，导致它的概念变得含混不清。许多团队并不在用史诗管理目标，而是把它们视为执行计划。甚至由于史诗这个舶来词难以理解，导致很多国内的敏捷团队直接跳过了这个概念；或简单粗暴地将其理解为产品模块、功能集等等。
在规划迭代时，大多数团队只是使用史诗作为项目管理机制的一部分，来过滤看板信息或显示甘特图式的进展。那么问题来了：如果史诗中8个故事有5个是完整的，这真的意味着我们已经完成了实现价值的63%吗？答案可能是否定的。毕竟在交付过程中肯定会有一些额外的步骤或工作量。
由于在实际工作场景中，史诗已经被错误理解的这一特殊性；为了避免歧义，我决定用用「阶段目标」这个词，让文章更好理解。换句话说，当然，你的团队可以用史诗来管理阶段目标。
如何管理好「阶段目标」
通过「史诗」或「阶段目标」来管理的团队，可以一定程度上减少额外工作步骤。
作为一名项目经理，我维护着一份动态文档，其中列出了我们当前阶段所关心的几个关键目标；同时，我还有一份未来的「规划目标」或者你可以理解为里程碑，以向业务方或客户证明我们正在跟进他们的需求。
每个节点上都会描述我们计划交付的价值；哪个项目或模块将更多地与目标相关；在必要时，提供一些具体任务（用户故事）的参考。
例如：
目标：与Sendrid集成，并使用它发送我们的欢迎邮件。这为将为营销部门自助编辑营销邮件模板奠定了基础；
阶段1、我们将让Sendrid在开发和生产中工作；
阶段2、决定模板将如何工作；
阶段3、由营销部门自主设计我们的第一个模板。
在每次迭代中，我和我的产研团队都会回顾这些交付阶段，并根据需要重新确定优先顺序。我们经常把利益相关者拉到一起讨论，这有助于他们更好地参与项目过程。
迭代计划从讨论我们的阶段目标开始，这样每个人都知道“为什么”；然后我们将围绕支持这些目标，为用户故事建立一个跟进看板。为了更精确地预估工作规模，也为了鼓励人们说出缺失的细节或提出更好的实现目标的方法，将小任务分解还是很重要的。
划重点！我们只思考支撑我们「阶段目标」的故事，而不是让积压决定我们的工作。值得一提的是，保持团队的良性运转也很重要也是一个关键目标，因此，团队需要就迭代结束时将朝着「阶段目标」前进多远达成一致。
一旦迭代结束，我们应该根据最初的期望评估实际进展。我们将此作为数据来重新校准我们对下一次迭代的规划，并向利益相关者传达最新的状态。这种持续的可见性和反馈机制可以建立内外部相关人员的信任和信心。
最后可能也是最重要一点：在繁重的积压中机械地“做需求”只会让我们忘记最初的梦想。
我们人类是擅长和热爱讲故事的物种，但所谓的“用户故事”并不能以这种方式激励我们。只有当人们专注于目标，将任务视为有方向性的和局部性的过程，而非单纯的工作对象时，他们才真正被赋予了实现自我价值的能力和动力。
如果你想建造一艘船，不要鼓动人们去收集木头，分工，发号施令。相反，请教会他们向往广阔而无边无际的大海。— 安托万·德·圣·埃克苏佩里
原文编译自：https://cgroom.medium.com
作者：Chuck Groom