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