（小剧场：某天午饭时间）
“最近怎么有这么多会议！上午开了两个小时的会，需求又做不完了 。”
“别提了，我今天排了三个会，根本没时间处理其他工作，还不知道几点能下班呢……”

根据微软对全球 31, 000 名员工开展的一项调查，低效的会议是影响工作效率的第一大干扰因素，其次是召开过多的会议。

大大小小的同步会、讨论会、审查会、复盘会不仅将工作时间拆解得支离破碎，还会让成员因「会议恢复综合症」而无法立即从无效会议中恢复过来，重新集中注意力投入工作。无法打造沉浸式工作时间，维护深度专注状态，极大地影响了个人和团队的工作效率。

为了克服会议疲劳，Shopify 在今年一月份宣布取消所有三人或三人以上的定期会议，并禁止周三举行所有会议。该举措涉及大约 12, 000 次的日程安排和活动，相当于节省了 322, 000 个员工工时。

大刀阔斧地砍掉会议是不是提高团队效率的灵丹妙药？ 或许，首先要弄清楚「我们为什么要开会？」

我们为什么要开会？

我们为什么要开会？

这个问题看似简单，但却值得深思。我认为开会是为了推进工作、完成工作，尽管实际情况并不总是如此（或者说，通常不是这样），但会议声称旨在推进目标、完成工作、共享信息、做出决策，或者至少要以一种异步沟通无法实现的方式取得进展。

毕竟，这就是会议的独特之处：大家聚在同一个物理或虚拟空间里，能够进行实时对话。这应该是非常高效的——不是文档或邮件、没有滞后的反馈信息，只有进展。

我们选择开会，因为这是更好的协作方式。

以上是会议应该达成的目的，但却不是我们开会的真正原因。你是否也曾对着自己的日程安排感到沮丧和无奈？因为你充分意识到自己会在一种效率极低的状态下忙得不可开交，却对此无能为力。我有过，那真的太糟糕了！

这种看似无解的「会议滥用症」，实际上是其他更糟糕的问题的表征。

问题一：协作流程支离破碎

频繁开会是流程瓦解的表现。我们把开会当成倚仗和退路，每当不知道该如何完成工作，或者不愿意投入真正能够推进目标的流程时，就安排一场会议。我敢打赌，那些对流程嗤之以鼻或者不愿参与其中的管理者们，正是导致会议泛滥的元凶。

问题二：对工作内容一无所知

频繁开会也是对工作内容茫然不知的表现。这通常是因为没有人愿意花时间弄清楚并解决这个问题。

我们将「会议」与「生产力」混为一谈，如果不开会，就不知道该做什么（或者不知道如何证明自己的工作价值）。 于是，我们说服自己「开会就是我的工作内容」，或者「无法提高工作效率是因为我没有参加会议」。即便真的是这样，那也更像是对会议的控诉，而不是疯狂开会合理化的理由。

问题三：职场权斗的必然结果

频繁开会也可以是权力斗争的表现。「接连不断的会议邀请不就说明‘我很重要’吗？每个人看到我满满当当的日程表都会这么想的。」

这种情况下，在踏进会议室的那一刻起，会议桌上的位置就比任务完成的实际效果更重要了。

是时候该反抗了！

几年前，当我意识到自己究竟在为什么而开会（还参加了如此多的会议）后，我开始了「会议抗争之旅」。

我拒绝参加那些我认为无须出席或者浪费时间的会议；我取消了所有单纯为了彰显身份地位的会议。 我深刻意识到我拥有着怎样的特权——大多数人都不能直接取消或拒绝出席会议。

我分享这个经历，是因为它让我认识到会议对我们的影响。虽然花了六个月的时间，但我逐渐将会议减少到原来近一半的数量。作为团队负责人，我本该频繁地参加各种会议，但我没有。

与我的同事和大多数直属下级相比，我参加的会议要少得多。坦白说，一开始的感觉并不好，我觉得自己一天什么事都没干成，总害怕错过什么；我担心砍掉会议实际是搞丢了自己的工作。但慢慢地，我意识到我为自己创造的所有时间都是一份礼物。砍掉会议并不代表与团队脱节，而是可以着手解决潜在问题的信号灯。 我有更多时间思考、设计、做出贡献，还可以处理那些需要我的问题。

我仍有一半以上的时间穿梭在各个会议室，但在这些会议中，我变得更加专注，准备也更加充分。我能够花更多的时间进行有效沟通，虽然会议减少了，但高效的即时通话增加了。

为了达成这一目标，我不得不重新学习一些东西，但我意识到砍掉一半的会议是一种提高管理效率的策略。

「会议滥用症」的疗愈之法

我对自己的日程安排有一定的控制权，但并不是每个人都能这样，而且一个人的日程表也不能解决真正的问题。一个急需解决的结构性问题是，管理者该做什么？

大多数人指出，优化会议规范是解决办法。问题的关键不在于会议过多，而在于「无效会议」太多，即会议效率低下。如果能够提前发送议程、阅读材料，并严格控制会议节奏和进程，那么所有会议都将变得极其高效。

我非常喜欢这个想法，但我从未见过它真正奏效——可能是因为这种方式就像在用创口贴和消炎药治疗复合性骨折。不过，如果你认真对待它，了解真正的隐藏病灶，或许能够摆脱「会议滥用症」。

下面是我实践过的具体做法。

最重要的治疗方法是建设优秀的流程。
无论你在做什么——产品、营销、研究、政策或服务——你都需要一个清晰的、完整的、端到端的流程路径将它实现。否则在此之前，你可能会陷入会议泥潭。

开会就像用仅有的锤子砸东西——用它，是因为没有其他工具了。良好的流程应该是轻量的、高效的、有强适应性的。 你需要清晰的项目计划流程以及井然有序的全功能产品开发与设计流程；你还需要专门负责处理这些事务的项目经理。一个优秀的项目经理可以通过减少会议，证明自己的价值。

你还需要改进开会的方式。会议中存在许多浪费时间的情况，以下是三个减少会议时间浪费的技巧。

1. 专注实时讨论，提高会议质量

用其他方式完成所有与高质量开会无关的事情。会议的独有优势是可以展开实时讨论，所有与此无关、与会议无关的部分，比如更新、参考信息同步、文档整理、幻灯片更新等等都应该去掉（全员会议和庆祝活动等文化会议除外）。

在取得项目进展上，实时对话和讨论比其他任何方式都更加高效。

2. 开门见山，才是高效的开始

立刻解决最难的问题。在会议开始的 5 分钟后，请开始讨论最困难的问题。我参加过很多长达一小时的会议，其中大部分是在前 55 分钟浪费时间，直到最后 5 分钟才进入重头戏。那为什么不直接从这开始呢？

3. 有效的会议，离不开信息透明

关于会议规范，有一点我完全认可——会议总结与共享。你需要记录会议纪要，然后同步给所有人。如果一个会议产出了决策，但没有让该知道的人都知道，那还算有效开会吗？

以前，我曾专门开会了解其他会议的情况……不能重蹈覆辙了，真的！

写在最后

即使你无法控制所有会议，了解会议泛滥和滥用的原因及解决方法也非常有用。你可以为解决「会议泛滥」创造条件，采取行动使会议变得不再必要，并让每一个人都注意到这点，还可以对自己的日程安排有更多的掌控权。

请记住，除了极少数的例外，你的本职工作不是参加会议，而是取得进展，达成目标。如果开会是你知道的唯一实现途径，那么你将不得不安排一次会议来讨论这个问题。

（原文作者为 Judd Antin，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

宁波银行：在「金融科技」引擎上，沉浸式提效减负

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

“为什么呢？”我开口问道，“难道联合创始人看不到这些变化吗？”
几杯啤酒落肚，一位程序员同事给出了回答：“他真的很擅长向上管理！”

而后几年，我一直将「向上管理」与「拍马屁」「职场政治」和「出馊主意」联系在一起。

是的， 我错了。

大错特错。

向上管理——此处定义为「知道如何成功与上级互动和交流」——有助于推动公司和组织的发展。 它还能为你的职业成长提供助力，而无需阿谀奉承或使用暗中操控等不光彩的手段。

下面分享向上管理中，你可以立刻行动起来并看到效果的三个技巧。它们将对你、对你的上级以及你所在的团队都产生益处。

首先，注意力和精力是最稀缺的资源。

管理者认为自己的时间很紧张，但其实，他们最稀缺的资源是注意力和精力。

无论什么时候都有大量的进行中的事件，任何管理者都无法将它们一一照顾到；许多与人有关的事件会同时发生，大部分管理者也很难全都深入参与、处理。而随着管理者权力范围的扩大，该感受会越来越强烈。

以我所在的组织为例，我目前管理着 12 个产品和近 700 名成员，而我的上级管理的产品和人员数量是我的两倍。我通常知道这一年要发生的所有事情：目标、战略计划、进度指标、关键阻碍因素，甚至每个产品的月度/季度进展，但我能够（或者说应该）更加深入参与的部分却很有限。对我的上级来说，情况更是如此。

因此，从逻辑上讲，管理者取得成效的关键在于，选择那些能吸引极大注意力和精力的领域。实现的方法有很多种，管理者工具箱中也有一个重要工具：定期与直属下级进行一对一沟通。

这正是向上管理发挥关键作用的地方，它有助于将管理者的注意力和精力引导至效益最高的事情上。具体该如何操作？

01 做好信息的过滤、组织与结构化

第一步，会前做好信息过滤。 许多一对一的会议充斥着杂乱无章的更新、对棘手问题的抱怨，以及脑海中突然冒出的想法。更好的做法是，退一步，像老学究一样思考如何在有限的关注和空间内，向忙碌的上级领导展示信息。

• 当下哪些事情最值得管理者关注并投入精力？
• 哪些事情可以暂缓？
• 哪些内容即使当下很重要，也可以忽略不提？
• 哪些更新或参考信息未来需要进一步讨论？

充足的信息过滤能有效引导管理者关注最重要的事情，也会对你自身的成长和发展带来好处。我和我的上级每 2-3 周会进行一次 30 分钟左右的一对一沟通。在这几周的时间里，我会把在团队合作中想到的主题收集起来，并在会议开始前，对内容进行筛选和优先级排序，以确保我们能专注讨论「应该讨论」的内容，而不是很多「可以讨论」的事情。

除了精心准备会议内容，优秀的信息组织和结构化也至关重要。在复杂的、快速变化的环境中，你所选择的每一个议题都是富有深度和内涵的，可能需要花费好几小时才能彻底解读清楚。而时间非常宝贵，所以向上管理要求你需要像写文章一样思考，

• 哪三个要点（Bullet point）可以传达大部分内容，推进你与上级的沟通？
• 信息应该以何种顺序呈现，才能易于理解？
• 1-2 个需要上级提供意见的重点问题是什么？

从我的经验来看，大部分人很少或几乎不会考虑信息的组织和结构化——这会导致对话效果变差，也会降低上级领导的工作效率。对我来说，虽然会议只有 30 分钟，但我可能会花上 90 多分钟整理并记录信息要点，以求能够充分利用时间。

02 高质量的问题比解决方案更重要

你听过这种说法吗？

除非你有解决方案，否则不要给你的上级带来问题。

同所有「至理名言」一样，这句话被广泛地传播，然后以分毫之差被逐渐误解和曲解。爱因斯坦曾说过——也可能是杜撰的——如果给我一个小时拯救地球，我会用 59 分钟定义问题，用 1 分钟解决问题。不管爱因斯坦有没有说过，我们都可以在向上管理中实践它。

实际上，向管理者提出高质量的、明确的问题，远比向他们同步无关紧要的更新、说明你已经解决/有能力解决的问题重要得多。

棘手的问题会让管理者化身参谋长。又因为大多数管理者会与每位直属下级进行交流，因此从不同来源听到类似的问题能够凸显其重要性，并引起管理者的关注。此外，高质量的问题还能让管理者充分发挥经验、模式匹配能力以及情感距离方面的优势，以辅助找到问题潜在的解决方案。

对信息进行过滤、组织和结构化处理时，一定要带着定义明确的问题工作，这样才能让管理者和自己都更加高效。问题列表必须经过筛选、排序和整理；在管理者的协助下，我们也要找到「应该讨论」的问题范围。

03 做管理者和团队之间的桥梁

于所有管理者而言，如何在提供指导或反馈的同时，与整个组织保持沟通是一个永恒的挑战。组织规模越大，挑战难度也越大。

管理 5 人团队时，你可以同每位成员详细交流，确认大家都了解你的期望，并定期监控进展；

管理 25 人时，你仍然可以采取一对一的沟通方式，但不得不将详细的期望设定和后续工作留给管理人员；

如果是 700 人甚至几千人的团队呢？你无法与每个人一对一交谈，甚至无法确保所有人都会阅读你的通知和消息。

好的向上管理能为管理者和团队架起桥梁。

• 你如何将从管理者那获得的信息，翻译成团队/同事最容易理解的内容，并传递给大家？
• 当上级要求的一项工作进展不顺利时，你如何代表团队收集和综合管理者需要的反馈意见？
• 当管理者做出不受欢迎但正确的决策时，你如何利用同上级的直接联系，缓和同事与上级之间的微妙氛围？

糟糕的向上管理表现为盲目地为管理者背水一战——一个经典槽点是 「老板是这么说的，所以我们必须这样做」。另外，不加筛选地传递信息，像搬运工一样、不作任何处理地同步一切管理者的声音，也是错误的。同样，受家长作风影响或出于对权力的渴望，不将信息共享出去，只让自己知道，也是向上管理的错误模式。

如同桥梁一般的向上管理是怎么做的？管理者不必依赖自上而下的指令，而是知道你会以正确的方式帮助他们实现目标——提供正确的背景，会根据对象的不同做出正确的差异化，有正确的后续行动——并基于进展和问题向他们提供反馈。

# LigaAI 总结

虽然所有管理者都有自己独特的工作习惯和协作偏好，但本文提到的三个向上管理的技巧在某种程度上是普遍适用的。

• 价值导向的信息过滤、组织和结构化
• 提供高质量的问题描述
• 成为管理者和团队之间的桥梁

最后，希望你能在永无止境的任务和工作中，不懈努力并持续进步，以更好地方式管理工作、管理团队、管理上级。

（原文作者是 Saumil Mehta，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

如何提高技术领导力？与你分享 5 个心得

产品路线图如何制定？斯坦福大学产品管理课程前来支招

「程序员转型技术管理」必修的 10 个能力提升方向

如何用 NPS 确定研发优先级，打破技术与业务的次元壁？

了解更多 程序员成长、技术管理进阶、研发管理实践等干货内容 ，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

本篇文章将与你分享，我在斯坦福大学「产品管理加速课程」中习得的产品路线图制定方法。

01 在决定策略前，要先有目标

在制定产品路线图之前，必须先有一个产品策略，而策略是以达成某目标而组织的一连串行为，因此我们得先有一个「目标」。

产品经理们在提出解决方案（Solution）之前，需要清晰地了解待解决问题 （Problem） ；否则很可能在原地打转，或无法知道项目是否真的有进展、以及是否解决了真正的问题。

设定目标的重点是「简单易懂 Simple and Understandable」。 只有足够简单、清晰易懂，组织内成员才可以快速抓到要点。

大目标通常由 CEO 或 C-Level 等高层管理者设定。它们可能是增加营业额、提升客户满意度、提高客户留存率等；要达到这些目标通常需要多个部门共同努力。

02 产品策略前，必须先有企业战略

先有目标，后有策略，懂了。那产品经理应该如何拆解高层管理者制定的企业战略，进而设定产品策略呢？

In order to have a product strategy, you MUST start with a company strategy to set the objectives!

产品管理加速课程的教授如是说道。制定产品策略之前，公司必须要有「清晰的目标」和「明确的优先级」。如果你要绘制产品路线图，但对企业战略还没有清晰的理解，那请把路线图放一放，先问问老板对企业战略的想法吧！

笔者小记：上课讲到这里时，我真是点头如捣蒜，实在是太切合实际了！不知道读到这里的伙伴是否也跟我一样深有感触？我们有时会不知道组织策略是什么，而常见的失败原因可能是组织目标模糊不清楚，或各部门关起门来制定自家策略，但彼此的策略却不相融，甚至互相抵触。那就真的像是多头马车，哪也去不了。

03 拆解企业战略，以制定产品策略

明确企业战略后，我们可以逐步将战略拆解成产品策略。下面我们用一个例子详细说明。

Step 1：找出 3~5 个关联度最高的战略

制定产品策略的第一步就是找出企业战略中与「产品」最相关的 3~5 项，比如「提高客户满意度，以增加业务收入」。

专注于 3~5 个战略完全足够。如果我们将所有目标都纳入考量，那最后可能什么也做不成——我们必须明确优先级，并专注最重要的目标。

Step 2：将战略细分为 3~5 个小目标

接下来，产品经理们请思考：产品可以从哪几个方面增加客户满意度？这里我将按新/老用户角度拆分出 4 个分支。

（客户→新客户）

• Onboarding 是新用户体验、认识产品的过程。

（客户→老客户→如何让客户开心→产品顺畅好用）

• Bugs / Issues 已知问题：如果生产问题很多，那么客户可能转移去其他产品。
• Performance 产品性能：如果产品太慢，用户可能会气到离开。

（客户→老客户→如何让客户开心？→解决客户问题）

• New Features 新功能：哪些功能是客户特别想要的？增加功能能否让客户更开心？

将一个大而抽象的目标拆解成多个明确的小目标，并没有一套固定的行为公式。你也可以拆分成两项、三项或者更多，其关键在于产品经理们要坚持练习战略拆解，并列出可执行的任务（Actionable Items）。

斯坦福大学「产品管理加速课程」中特别提到一个拆解标准：相互独立，完全穷尽（Mutually Exclusive Collectively Exhaustive） ，即 MECE 分析法。麦肯锡尤其推崇这个思考方法，它可以帮助我们把复杂的大问题拆解成小问题。

• Mutually Exclusive：拆解得到的小问题之间相互独立、没有重叠，且有排他性；
• Collectively Exhaustive：所有部分穷尽， 没有遗漏；小问题加总能得到最初的大问题。

Step 3：写下各细分目标的假设

将大目标拆解为多个小目标时，我们需要了解「为什么要这样拆分」，不能为了拆分而拆分。结合用户反馈、调研数据等，产品经理们会明确每一步拆解的诉求和理由、每个细分项目的意义以及它们如何帮助达成公司的战略目标。

举个例子：我们从客户反馈中发现，许多用户认为「系统响应太慢」，那么我们尝试假设「提升产品性能可以提升客户满意度，进而提高业务收入」。

Step 4：确定优先级

确定出可执行的小目标后，我们可以根据各种质化或量化分析（费米估算、客户反馈、甚至是一般常识）来确定项目重要性和优先级。

如果已知 75% 的受访用户评价 Onboarding 体验不好，却没人提及性能问题或生产缺陷，那么 Onboarding 就应该作为第一优先级的目标。

Step 5：制定产品策略

下一步，为每个假设提出至少一个可行的解决方案，绘制产品策略清单。也许我们还不确定是否每个方案都必须执行，也不知道它们是否都能达成目标，但这能为后续打下一个好的基础。

Step 6：制定产品路线图

有了产品策略清单，我们便可以开始制定产品路线图！产品管理加速课程的教授指出：

A roadmap is a living document that communicates a prioritized list of projects to achieve the product strategy.

• 产品策略：我们想做什么（What）？
• 产品路线图：我们如何达成（How）？什么时候达成（When）？

产品策略经历一系列拆解和细化，最终成为产品路线图。产品经理们需要确定最终呈现的产品路线图具备以下 3 个特点：

• 灵活：要能随时调整。组织内有明确流程，大家知道什么时候/多大频率会更新路线图，以及如果有想法应该如何反馈。
• 优先级明确：项目要明确优先级，并提供清楚的上下文/原因。
• 项目规模：有大有小，不应该只限于功能。

许多公司习惯于先画出产品路线图，再从中列出产品策略，这其实把前后顺序颠倒了，我个人不是很推荐这种方式。

最后将前面 6 个步骤汇总，我们便得到了从企业战略到产品路线图的逐级拆解方法图。

（原文作者为 Jean Huang，经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

「程序员转型技术管理」必修的 10 个能力提升方向

如何用 NPS 确定研发优先级，打破技术与业务的次元壁？

这 4 个系统可靠性评估指标，可能比 MTTR 更靠谱！

LigaAI：从效率、度量和价值维度，成为研发团队的智能医生

高绩效团队的 5 个优秀习惯，看看你占了几个？

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

原则上，践行敏捷开发很简单：构建一个增量；测试这个增量；了解需要改变的信息；将信息反馈到第一步中，并重复步骤。

整个过程可以从两个方面，将敏捷开发与瀑布开发彻底区分开：第一，尽早且频繁地交付小批量的可工作的产品；第二，根据（一）得到的新变化和信息，对产品进行恰当的调整。

如下图所示的敏捷路线图很常见。时长一年的甘特图上堆满了功能，并提前完成了任务分配。研发团队只能在一个个不间断的迭代中，实现所有的功能；他们还没有机会总结已交付的工作并作出调整，就必须立刻进入下一个功能开发。

如果前两个产品功能交付后被证明是错误的（这非常有可能发生），难道我们还要按原计划迭代下去吗？继续遵循上面的甘特图，可能会一错到底。因为计划好的路线图无法帮助我们评估交付效果，识别问题并及时调整。

敏捷开发刻意只关注下一次迭代的即时计划，但许多团队构建了一年甚至更长时间的甘特图，并且罗列了无数个待开发功能和完成截止日期。这样怎么会敏捷呢？

01 前瞻性计划：敏捷刻意忽略的部分

除了当前迭代正在构建的产品外，敏捷方法论不太关注前瞻性的计划。因为只有这样才能做到「实时计划」——我们应该看到什么是可行/不可行的，并根据反馈的数据决定下一步该怎么做。

敏捷意味着「能够快速轻松地行动」，而敏捷开发需要被持续引导，逐步提供价值，再根据市场反馈的情况快速调整策略和方向。这是一个建立在洞察与反应几乎同步的快速反馈周期，而不是基于前期的大计划。

但是，组织（尤其是大型或传统组织）通常不喜欢没有计划地工作。没有计划的组织会陷入「计划缺失焦虑症」；更准确地说，组织的领导者会很焦虑。因此，他们会制定一个功能列表，提前做好分配，以确保每个人都能按预定的方式有序地工作。

敏捷的组织应当正面解决计划缺失的焦虑，但许多团队没有这样做。反而是领导者们认为，过去路线图和甘特图很有用，那就应该继续使用它们。慢慢地，敏捷就变形成「Water-Scrum-Fall」，就像下图这样。

不幸的是，敏捷的核心——灵活自由地根据新信息进行调整——被完全忽略了。许多团队实践的敏捷并不是真的敏捷，而过去的瀑布式任务列表也演变成了「用户故事」列表。

02 SAFe：敏捷适配器

敏捷框架没有提供任何当前迭代以外的具体规划建议，而扩展框架正填补了这一空白。SAFe 有一个优点：作为从前期瀑布式大计划到团队敏捷执行的适配器，它可以很容易地被理解。

使用 SAFe（或其他扩展框架），产品管理团队提出功能，设计团队绘制 UI 模型，再发送给管理层审批。当工程师开始编写代码时，管理层会很放心。因为他们已经做好了充分的计划，而成百上千名程序员都会尽职尽责地工作。通过敏捷扩展框架，管理人员可以看到所有计划中的功能，而开发人员可以在迭代中专注地写代码。

这也是敏捷扩展框架受欢迎的原因：它们将领导者熟悉的大型计划，转换为研发团队可执行的敏捷迭代。在一些高级管理者看来，这就是最重要的。事实上，工程团队已沦为「功能工厂」，他们几乎失去了所有学习、快速调整和改变的能力。管理者却真诚地相信，团队已经完成「敏捷转型」。

03 敏捷性需要空间来操作

回到前面提到的两个决定性敏捷特征：尽早且频繁地交付小批量的可工作的产品；根据（一）得到的新变化和信息，对产品进行恰当的调整。

第一点比较好理解，几乎所有资料也都集中在这上面；能够正确掌握第二点的人要少很多。如果团队没有从早期部署的迭代中学习，也没有将洞察力融入后续的迭代优化，那么就没有正确地践行敏捷——这其实只是「增量瀑布」。

正确的敏捷要求组织多次发布和重新发布相同的功能，并且每次都要从早期的经验中吸取教训，使该功能更易于使用、更强大、性能更好或在某些方面更好。这需要时间，而且这些时间无法在前期被充分估计和预先承诺。因此，要想成功地洞悉变化，完成迭代优化，团队需要在计划中做到以下三点。

1. 计划实现的路径必须是可塑的。定义一个愿景或最终目标，但允许具体的功能和内容在执行时可以有所变化。我们无法准确预测一个功能会如何运转，所以需要测试它。敏捷团队要允许每个功能能被反复加工、打磨或扩展几次，直到真正实现它。
2. 计划需要为调整和优化留出弹性空间。如果时间已经全部按计划分配完，就需要删掉一些东西。正确的策略是在一开始就不要填满所有时间，让它保持开放状态；可以为新想法整理一个新队列，直到时间允许，再进入迭代分配。后文的 「Now-Next-Later」也会详细讲解这一方法。
3. 领导的支持。这通常是三点中最难实现的。

04 领导力是敏捷性的关键

最具影响力的成功因素是组织展示和激励的领导范式。—— Agile 2

很多领导层都认为敏捷是团队内部的事情。这种假设肯定是错误的，而领导们也需要以敏捷的方式行事。在项目过程中，如果要为团队提供调整的空间，领导者就要接受临时的计划。「可塑性强的路径」和「允许调整的弹性空间」印证了这点。

管理者要有足够的勇气和决心，才能对团队说：“我们不打算在这个迭代将你们的工作填满；你们需要跟着数据走，看看自己的工作成果。” 如果领导者要真正拥抱敏捷，他们就需要做出根本性的改变。这遵循精益创业的精神：建立一个项目、测试它、从数据中学习、并将这些经验直接反馈到后续的项目中。

同时，领导者也要有勇气，接受这些事实：团队不会在外部干扰下提前确定工作，也不会一轮接一轮无缝地进行功能开发。团队需要更多实验性、创造性和跨职能的工作。

这同样意味着，领导者需要快速响应、批准通过更多碎片化的需求变更。他们要探索出更灵活地工作方法，以便为团队提供及时审批。这无疑会打破官僚主义的枷锁，而由领导者们组成的小团队则能更快、更独立地监督和批准自己团队的工作。

05 Now-Next-Later 模型

更常用的敏捷路线图工具是「Now-Next-Later」模型。甘特图中层层叠叠的功能集可以归纳总结为三个模块。

• Now：我们正在积极工作的事情。
• Next：「Now」完成后，即将开始的工作。
• Later：其他所有未分配和未承诺的功能。

将新的需求、功能和工作按模块规划好，比挤进拥挤的甘特图要容易得多。我们可以很轻松地在每个模块中留出弹性容量空间，以便后续根据最新信息做出调整。

可以看到，「Now」中的项目定义得比「Next」更加详细，「Later」是定义和描述最少的。每个模块的时间跨度可以自由决定，但最好跨度大一些，尽量覆盖多个迭代和优化周期；建议的时间周期是每个模块 6 周或者一个季度。

正确地使用「Now-Next-Later」，既能让我们适应短期变化，为后续工作和 Bug 修复留出空间，也能适应长期变化，改变我们对哪些功能要从模块中取出的想法。

但它不会消除干系人要求尽快交付功能的压力。这也是为什么领导者需要自己拥抱敏捷，才能让团队成功。领导者需要通过自己的努力，倡导敏捷的工作方式，并以同样的标准要求自己。

06 结论

许多自称敏捷的组织，他们提前计划了大量功能列表——通常提前一整年——并告诉团队要以小批量的方式交付。这不是敏捷，这是增量瀑布。

敏捷开发的核心特征是小批量地交付可工作的产品，从早期迭代中获得洞察力，并在后续迭代中进一步完善和优化相同的功能。其中的关键在于我们无法预知和确定什么是可行的，什么是行不通的；这需要洞察和跟踪数据。打造一款优秀的产品，我们要一边走，一边制定计划。这与一年长的甘特图完全不同。

「Now-Next-Later」只有与团队自主权相结合时才有意义。这样才能使团队发现计划的调整空间，及时做出应对。想要灵活地工作，在做计划时要注意建立高度灵活的路线图、留出充足的弹性空间用于响应调整，以及获得领导层的积极支持。利用好这三点，就可以持续地引导项目，而不是在前期就将它固定下来。这就是敏捷真正的意义所在。

原文作者：Raj Nagappan

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

多个服务器如何跨命名空间，访问公共服务？

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

多测试环境的动态伸缩实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

高层管理者总觉得自己很了解应该做什么，并希望产品经理服从他们的命令。所以在现实场景里，产品专家们只能根据指令完成「废话管理 Bullshit Management」，而不是产品管理。

没有决策权，产品经理就无法茁壮成长。

可要小心了！有些公司「说的」和「做的」总是截然相反。说是扁平化管理，但你可能会发现公司内部有层层决策链，最终还会因此陷入分析瘫痪；

你可能会被授予一定的决策自主权，但绝不会超出特定范围。比如你可以敲定如何更好地实施解决方案，但却无法决定先解决哪个问题。

凭借主观想法和管理层级推动业务，是让人震惊的。我特想知道，领导层聘请产品经理究竟是为了执行废话，还是管理产品。

下面我将举例说明什么是「废话管理」，以及产品经理们可以如何避免这些可怕的陷阱。

一、一直被误解，从未被实践的产品管理

随着公司的发展，内部政治化会逐渐加强，而敏捷性则越来越弱。有些时候，最重要事成了取悦内部的关键干系人，而不是弄清楚哪些终端用户的问题值得解决。

此时，你可能就会从「产品经理」降级为「待办所有者 Backlog Owner」或「故事写手 Story Writer」。这种情况下，取悦利益相关者比改善用户体验更有利于职业发展。

我时不时会看看招聘广告，了解企业如何看待「产品经理」一职。遗憾的是，我在其中看到了许多岗位误解，下面是我在最近发现的一些奇怪的要

您将会与组织中的利益相关者合作，获取他们的支持并满足他们的需求。

我以为产品经理必须要满足的是用户的需求，而不是内部利益相关者的需求

您需要在全球/区域基础上，制定商业计划和产品推广计划。

认真的吗？大多数商业计划本质都是瀑布式思维；创建一个计划、做几个漂亮的 PPT 和在线表格。那只能用来骗自己，计划越多，失败越大。

好的产品管理要有明确的愿景，能用很少的资金测试各种想法，并在得到客观的佐证后，逐步提升它们。目标服务于愿景，但也要拥抱试验才能发现隐藏的机会。

制定用于提高开发效率的工具和流程。

这点让我很困惑。我从没想过产品经理需要负责制定流程，提高开发效率。这是典型的产出导向（Output-oriented）的要求，而不是结果导向（Outcome-oriented）。

您需要为您的产品小组规划活动和资源，并与工程、市场、质量或销售等跨职能团队进行协调。

产品经理不计划具体的活动，而应该设定目标，并授权团队做出决策。这要求听着更像项目管理，而不是产品管理。

同「Context, Not Control」一般，优秀的产品经理主张情景管理，绝非控制管理。

使用全面的验收标准，定义史诗和用户故事。

将产品经理视作需求工程师是一个常见的陷阱。一些公司希望产品经理可以架起业务端和技术端的沟通桥梁。瀑布开发就是这样，但我们都知道它的效果并不好。

卓越的产品经理应该打造一个可以滋养伟大想法的环境和氛围，而不是设定实施要求。

您将确保整个公司展开强有力的协作和沟通，并就产品路线图达成共识。

追求共识除了会让团队速度变得超级慢之外，还会让大家趋于平庸。产品经理争取的从来不是共识，而是承诺。大家同不同意都没关系，经验和客观证据永远比主观想法和职位更有说服力。

我在阅读以上这些产品经理的岗位描述时，我知道我们还有很多机会，可以帮助公司实践良好的产品管理。尽管这极具挑战，但回报很可观。

其中的关键就在于了解预期的可能结果并调整方法，帮助企业取得产品管理方面的进步。过程可能会挑起一些争吵，但这听起来就很刺激。

二、什么是「废话管理」？

花时间做与产品管理无关的事情，我都称之为「废话管理」。展开详细解释之前，我想先分享一下「什么造就优秀的产品经理」。

通过确定要解决的重大问题，发现未开发的潜在机会，领导团队为终端用户和业务创造价值。

在我看来，一个优秀的产品经理善于鼓舞人心。TA 会舞动大家行动起来，有些事情甚至连行为人都不知道自己能做成；TA 还会设定振奋人心的目标，授权团队决定如何实现目标；TA 不是老板，而是团队追随的领导者。

如果你的日常工作与上面提到的有关，我相信你在做产品管理；但如果不相关，那大概率就在进行「废话管理」，就像这些常见情况一样：

• 收集和解决干系人的需求，而不与他们建立关系，满足终端用户的需求。
• 保留大量的产品待办列表，只为了告诉干系人「需求已登记」，却不删除与当前目标无关的待办事项。
• 频繁地为管理层准备绩效报告，却不评估交付物的效果。
• 努力地追求共识，取悦所有干系人，却不为产品找一个最优选择。
• 签署团队交付的所有项目，以确保他们符合你的质量控制标准，而不授权他们实现目标。
• 参加会议只是为了避免激怒干系人。
• 害怕拒绝无意义需求，因为你的老板可能因此收到「问候」。
• 承担业务干系人和开发人员之间的沟通，而不是成为促进协作的催化剂。
• 不了解终端用户的意见，基于主观想法就完成需求的优先级排序。
• 专注于功能模块的交付，却不追求价值最大化。
• 花时间为计划失败找原因，从不分享从失败中学到的经验和教训。

每当看到任何一个「伪产品管理」的迹象，产品经理都应该站出来，帮助团队扭转功能失调的管理，向可靠和稳固靠拢。别向错误模式低头，莽它！

三、如何避免陷入「废话管理」？

前面列举了一些常见的产品管理的错误模式，下面将提供一些纠正错误的实践技巧。

01 改掉主观想法，追求客观证据

干系人可能会步步紧逼，要求产品经理实现他们想要的功能。在做出任何决定前，你可以向他们提出以下问题：

• 这个功能与我们的目标有什么关系？
• 哪些证据能说明此功能解决了用户问题？
• 您想用这个功能解决哪个问题？
• 如果实现了这个功能，该怎么评估它的效果？
• 如果不做这个需求，会发生什么？

这些问题的答案可能会让你和干系人都大吃一惊。也许他们会撤回之前的请求；如果在缺乏有力证据的情况下他们仍旧坚持，那么坚持客观证据就是你的职责。主观想法不应该成为产品团队的驱动力。

产品经理要带领团队为终端用户提供解决方案。通过打造产品和服务，让用户的生活更美好。想要获得成功，就要从「取悦利益相关者」，转变为「帮用户获得进步」。

02 避免成为「传话筒」，鼓励直接交流

将产品经理视为业务团队和技术团队的桥梁，是一个常见的错误。更好的方法是为技术团队提供正确的上下文信息，授权他们自主决策，并鼓励他们在需要时，与业务利益相关者直接沟通。

你可能认为，让开发人员与干系人直接交流有点危险，他们可能尝试将干系人的需求劫持到冲刺中。

这确实有可能发生，但相比敢于解决问题的伙伴，循规蹈矩的团队更为危险。如果干系人试图劫持某些东西，请及时给予反馈，鼓励开发伙伴将此类讨论重定向给你，因为他们可能也不愿意处理它。

03 聚焦用户学习，摆脱无效计划

每个人都喜欢安全感，没有什么比为面前的一切制定一个按部就班的计划更好了。干系人会要求你制定规范性计划，并对截止日期做出承诺。

不要掉入这个陷阱！

没有任何计划能在与用户接触后还继续存在。与其费劲做计划，不如拟定一个假设清单，将想法实现必须要完成事情都列出来。再找一条能快速验证假设的捷径，你越快地了解清楚用户，就能越早迎来产品成功。

可靠的产品管理与计划无关。不要沉迷计划；把你的精力放在确定着陆点，和迈向它的第一步上。

除此之外，你的项目启动无需任何东西。之后根据你了解到的内容，调整具体行动。下面是聚焦用户学习，摆脱无效计划的几点标志：

• 产品待办列表很精简，工作量不超过几个月。
• 删除了待办列表中与学习成果无关的事项。
• 叫停了某些功能和需求，因为证据表明它们不会创造任何或令人满意的价值。

# 写在最后

产品经理的竞争比以往任何时候都要激烈，许多公司都在向优秀的专业人才抛出橄榄枝。如果你想加入，没有比现在更好的机会。

但是，准备好应对许多「伪产品管理」和实践挫折。尽管公司会招致优秀的产品专家，但这不意味着他们会提供一个良好的发展环境；你必须与错误模式对抗，帮助他们克服功能障碍。

伟大的产品经理永远不会向错误模式低头。他们将始终保持战斗状态，以确保能够为用户带来改善和提升。

原文作者：David Pereira

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

多测试环境的动态伸缩实践

被忽悠入坑后，我如何让产品「起死回生」？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

不幸的是，于我们而言——作为产品经理的我们——我们或许有远见和决心，但却很可能缺乏无穷无尽的可消耗的劳动力（和时间）。这就是为什么我们要对团队的工作进行优先级排序。我们必须确定哪些成果唾手可得：相较预期的成果而言，这些工作可以轻而易举、不费吹灰之力地完成。

几年前，我编译了这个优先级排序框架的早期版本，并将它投入Voice123，Bunny Studio和Torre等多家公司的团队进行测试。经过多年的调整、改进和验证，我想公开分享它——Prioridad。

一、需求、事务和缺陷 如何确定三者的优先次序？

产品经理和研发团队通常会处理三种类型的工作：需求、事务和缺陷。

缺陷（Bug）是与规格相比，会导致意外行为的产品漏洞，通常由开发团队产生；而事务是产品设计中导致用户体验不佳的缺陷，通常由产品经理或产品设计师产生。

首先，我们需要一个用于确定需求、事务和缺陷三者优先次序的方法——这很大程度上取决于业务性质、产品所处的阶段（跑通PMF前/后）和团队规模。两种常见的方法分别是基于产品卓越性，或基于时间分配确定优先级。

01 基于产品卓越性排序

这种排序基于一个前提：拥有一个（近乎）完美无缺的产品，至关重要。对于「产品即业务」的公司而言，这很常见，比如SaaS产品和视频游戏。基于产品卓越性的工作优先级也很容易确定：

• 总是先修复缺陷
• 然后处理事务
• 最后再开发新需求

它对产品经理和研发成员都适用；但是，对尚未跑通PMF的产品不太适用：默认情况下，此时产研团队应该专注于实现达到市场需要的新需求，而事务和缺陷往往只在需求完成后才解决。

02 基于时间分配排序

这种排序方法的前提是，即使产品存在一些缺陷，持续推出新的产品功能依旧是必不可少的。它适用于「产品是业务推动者，而非业务本身」的公司，例如Steam V.S. 羊了个羊——前者属于服务型产品，后者属于流量型产品。

对于这种情况，可以尝试在三种工作之间平均分配精力，将产品团队和研发团队的可用时间划分为三周的循环：

在某些情况下，比如实现复杂功能或偿还大量技术债务时，这样的循环是行不通的。需要注意，尽管开发团队可以在解决事务和实现新需求时修补技术债，但仍需要时常为它分配特定的解决时间。

无论你采用哪种方式，每组任务、需求、事务和缺陷都有自己的优先级排序逻辑。

二、如何确定需求/事务的优先次序？

确定多个需求/事务的优先级，可以结合优先级系数辅助完成。优先级系数的计算公式如下：

核心KPI（Core KPI ）反映的是产品的核心交互。于Bunny Studio而言，核心KPI是完成的项目数量；对Voice123来说，核心KPI则是提交的项目和提交的信息。

核心效果指标（Effect in core KPI）指新需求/功能或事务发布后，核心KPI的预期增量，可以用一段时间内核心KPI的绝对数量、与之相关的收入增长或各自的百分比来估计。下面是一些参考指标：

• 50, 000 次授权/年
• 300 万项目收入/月
• 提升 20% 的功能使用率
• 线上收入占比提升 20%

此外，核心效果指标也可以是一个结合多个因素计算得出的指标。因子是否相乘或相加取决于它们是否相互复合。

如果需要相加，那么所有因子在相加前，都需要遵循统一的数据基准进行标准化，比如使用 1 到 10 的评分体系。 举个例子，Torre的大多数团队会为每个新需求，分析下面这些复合因素：

• 与用户用途的相关性：使用 0-10 的衡量等级，0 代表「没有解决用户需求」，10 代表「总能解决用户需求」。
• 用户粘性：每周潜在的互动数量。
• 新功能的总可寻市场：以可能使用新功能的人数为计量单位。
• Wow因子：用 1-10 的评分衡量，1 分代表「不怎么样」，10 分代表「和我第一次看到iPhone一样令人印象深刻」。
• 转化率提升：指增加的访客成为注册用户的可能性，测量范围可以从 0 到 100% 或更多。
• 价值感知速度：以 1/d 为单位，其中d是新用户在注册后感知价值所需的天数。
• 病毒式传播：一个普通用户在使用Torre的前 30 天内会给Torre带来多少新用户。
• 病毒传播速度：以 1/d 为单位，其中d是新用户发送第一个邀请给其他人可能需要的天数。
• 公关潜力：以 1-10 的评分衡量，1 分代表「没啥可吹的」，10 表示「媲美首次登月」。

这些因素适用于Torre大多数团队，但并不适用于所有团队。例如，SEO团队就使用每月搜索量、竞争力、用户生成内容（UGC）等其他因素指标。

成功几率（Chance of success）是一个 0%-100% 的估计值，用于捕捉交付的努力能够达成核心效果指标的可能性。这最开始会是一个大胆的预估，但通过后续的原型设计和分割A/B测试，可以降低其不确定性。

实现复杂度（Implementation complexity）用于衡量实现新功能或事务所需的工作量。理想情况下，这个估计值会受到产品经理、产品设计师和技术主管意见的影响。这个值可以是工时，也可以是斐波那契数列。

例如，预计能将核心KPI提高 30%、成功几率仅为 10%、需要耗费 15 个工时的工作，其优先级系数将如下所示：

无论为每个变量选择怎样的计量单位和度量标准，确定优先级顺序时，对所有新需求/事务应用相同的单位和参考标准是最重要的。

三、如何确定缺陷的优先次序？

确定缺陷修复的优先级时，一个最重要的判断因素是该缺陷是否阻碍了用户。在本篇指南的语境中，用户无法继续完成预期的使用，就是被阻挡了。

• 最高级：妨碍大多数用户使用产品的缺陷
• 高级：妨碍少数用户使用的缺陷
• 中级：大多数用户遇到但不妨碍使用的缺陷
• 初级：少数用户遇到但不妨碍使用的缺陷

四、关于优先级排序的实用技巧

1. 始终使用相同的公式进行优先级排序。用相同的计算公式比较多项工作，优先级排序才能奏效。

2. 在每项工作的标题上添加优先级值。这将能让你更轻松地根据优先级系数，完成项目/产品管理面板的排序。

3. 每项工作都要记录下计算方式、计算者以及结果日期。这会帮助其他成员更好地理解你的预估值来源，并对估算结果提出质疑；还将帮你确定估算是否过时，以及是否需要更新。

4. 培养直觉。进行数百次数学运算后，你将会发展出无需手动计算，就能确定工作优先级的能力，并且结果仍然具有很高的准确性。

# Liga总结

Prioridad是一个经过多次实践和验证的框架，通过引入「优先级系数」概念，量化并确定新功能、产品设计缺陷（事务）和产品使用缺陷（Bug）的优先次序。 优先级系数通过综合新功能的预期效果、成功几率和工作量等指标，帮助敏捷团队更直观地掌握和分析研发工作的重要性。

原文作者：Alexander Torrenegra

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

迭代评审会的七宗罪，你知道吗？

优秀的程序员如何提升个人能力？

每日站会能不能取消？

如何消减协同合作中的认知偏差？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

• 展示结果：开发团队检视当前迭代的最初计划，展示每个需求/故事的工作结果及变化；
• 评审反馈：产品负责人进行确认，收集反馈，并记录进一步的改进设想为新需求/故事；
• 调整方案：产品负责人及关键干系人介绍有关后续迭代的新信息/设想，为接下来的迭代计划会议提供有价值的输入信息。

基于清晰的会议目的和讨论重点，如何更好地完成迭代评审会？高效的迭代评审会又有哪些不为人知的事半功倍小技巧？

本期敏捷实践，LigaAI联合潮海项目教练团队的资深敏捷教练，一一为你解答。

一、 每个迭代结束都要进行评审吗？

作为Scrum五大事件之一，迭代评审会通常在产品增量完成后、正式发布前举行，但在实践经验中，并非每个迭代完成都必须要进行评审。依据时间频率的不同，迭代评审会分为高频评审和低频评审。

• 高频评审适用于产品增量复杂的情况。通过将产品增量拆分成若干个关键需求，并在每个关键需求完成后，邀请重要干系人参与检验，以分散一次性评审的会议压力。
• 低频评审适合产品增量对干系人的感知价值不大（比如长流程的端到端需求）或干系人时间紧张等情况。通过多个增量的合并评审，减少频繁会议对工作的占用和干扰。

此外，以迭代周期/固定周期作为举行迭代评审会的标志并非最优解。迭代周期是团队内部的开发管理单位，在可感知价值增量层面或有不稳定性。

更好的做法是基于里程碑/史诗的完成情况，以增量结果为指标，按需开展迭代评审会。研发里程碑一般分为「内部里程碑」和「外部里程碑」两种。

• 内部里程碑常指项目关键决策点，如需求阶段完成、设计阶段完成，主要用于评估项目内部风险，一般不涉及用户反馈，无需迭代评审；
• 外部里程碑是涉及对外发布的重大功能/模块的完成，需要在产品发布前邀请关键干系人参加迭代评审会，并贡献真实的使用反馈。

二、 干系人一定要参与会议吗？

在《每日站会能不能取消？》一文中，我们曾提到「非必要情况下，Scrum Master可以不参加每日站会」。那么，迭代评审会是否也可以不需要关键干系人的参与呢？

答案是——不可以。

迭代评审会的核心目标是收集用户反馈，所以关键干系人的参与极其重要。但在实际中，不可避免地，干系人可能因各种原因无法参加会议，可以采用以下几种方式解决：

第一，由干系人授权的决策代表代替干系人参加会议。决策代表需要具备对产品增量贡献反馈的能力，并且要能够提出「通过与否」的关键性意见。

第二，如果干系人无法分出大块时间参与评审，那Scrum团队可以采用高频小模块的方式完成反馈，遵循「价值原则」——先展示最急需反馈的功能。

第三，将干系人的会议预约列入待办。避免临期预约的冲突和缺席隐患，产品负责人可以在迭代规划期，就提前锁定关键干系人的会议时间，或将迭代评审会以定期形式常态化（比如安排在每双周的固定时段），确保干系人可成功出席。

贡献反馈的干系人必须参加，而执行反馈的技术人员也同样不能缺席。开发团队应在现场直面用户，聆听最真实的用户声音，才能更好地理解业务、理解需求。

理想情况下，开发团队应全员参与迭代评审会，同干系人一起协作讨论，在认同中建立工作价值感；

如果团队规模较大，也可以轮流派代表或者安排技术骨干参与会议，负责本次产品增量的开发人员必须出席会议，以减少一手反馈的传递偏差。

三、迭代评审会的多种打开方式

01 合而为一

践行Scrum的过程中，敏捷四会（即计划会、每日站会、评审会和回顾会）不必是完全独立的。

例如，对于每周一迭代的短周期敏捷团队，可以考虑将评审会和计划会合为一次会议，以减轻会议负担。会议中，应先评审、后计划：关键干系人在评审结束后先行离场，Scrum团队继续进行新一期迭代的计划会议。

迭代回顾会则不建议与其它会议合并，因为这是敏捷团队复盘和经验总结的宝贵机会；但可以考虑将多个迭代的回顾会合并一次举行。

02 一分为二

对于产品增量价值低、客户感知影响不大、或有高质量要求，需先进行内部评审的迭代而言，可以采用「一分为二」的低频评审形式，将迭代评审会分为「Scrum团队的内部会议」和「与干系人协作的外部会议」两次进行。

• Scrum团队的内部评审侧重于完整的功能展示，重点审查关键功能能否跑通、是否存有Bug尚未修复/发现等；
• 有关键干系人参与的外部评审以收集用户真实反馈为主，重点验证产品增量是否满足客户需求、是否达成真正的产品价值。

03 直面客户是最好的形式

远程办公和异地协作盛行的今天，共享式的文档/表格/问卷协作免去许多会议，但是迭代评审会以获取用户真实反馈为核心，面对面沟通却是不可省去的重要仪式——直面客户、观察用户的使用和体验是获取有效反馈的主要途径。

对于重要且急需用户反馈的功能，Scrum团队应主动安排产品负责人和功能相关的技术骨干前往干系人公司，进行一对一展示和沟通；

面对无法克服的时差或时空问题，也可以采用线上视频会议的形式，但是建议要开启摄像头和麦克风，并使用共享屏幕，让Scrum团队「看到」干系人的使用反馈。

四、迭代评审会的四个黄金搭档

高效的迭代评审会一般包含功能演示、体验试用、讨论反馈和待办优化四个环节。

01 功能展示

述清会议内容与目的后，开发成员结合迭代计划与产品增量，向产品负责人和关键干系人展示已经完成的产品价值。

看似简单的功能展示，也存在一些共性的改进空间——《深入核心的敏捷开发》提出「展示会七宗罪」以描述功能展示过程中的七大问题，并针对性地提出了高效展示会的七个技巧。

七宗罪之一：准备工作没做好，空耗会议时间

正确做法：主讲人在正式展示前，应该做好充分的准备工作——预演演示步骤，准备测试数据，提前部署演示环境等等，避免手忙脚乱和空转浪费，提高会议效率。
七宗罪之二：没有说明铺垫，云里雾里不知所以

正确做法：在开始演示之前，主讲人应当简要地介绍会议目标和所要展示的功能，并说明功能给用户带来的价值。清晰的上下文能让产品负责人和干系人更快地进入状态。
七宗罪之三：逐条过验收标准，缺失业务完整性

正确做法：不要逐个演示用户故事/验收标准。主讲人应以功能为单位，将完整的产品/功能/模块串起来展示；最好定义出单独的业务场景，使用业务语言让业务成员更有代入感。
七宗罪之四：相同/类似的功能，演示所有路径

正确做法：只演示最关键的路径。遇到多个路径实现相同或相似功能时，选择其中一条最复杂/重要的路径详细演示，其他路径指出不同的地方，点到为止，无需覆盖全部路径。
七宗罪之五：过多提及跟演示功能无关的内容

正确做法：专注于最有价值/重要的功能演示，不要让小反馈/未完成的模块耽误会议时间；尽量不提及技术难题或技术方案等业务人员不感兴趣的内容。
七宗罪之六：认为展示仅仅是BA或QA的事情

正确做法：不让某个角色独占功能展示，人人都应该参与进来；可以采用人员轮换的方式进行展示，这样可以提升成员的业务意识，更熟悉整个系统功能。
七宗罪之末：不熟悉的新人负责展示，重点模糊

正确做法：新人展示前应充分了解业务和系统，确保能够应对和解答业务的挑战和疑问；也可以让新人在结对编程、Story Kickoff等多做主导，具备一定的系统和业务意识后再向干系人展示。

02 体验试用

开发成员完成功能演示后，更重要的是要让关键干系人亲自体验和试用系统功能/Demo。用户亲自下场试用和检验，是获取反馈中必不可少的一环。

产品负责人也可以邀请真实的用户参加评审会，让其在开发的指导下体验演示的功能和系统。需要注意，此时开发团队应该为干系人和用户留出足够的自主探索空间，引导他们重现最真实的使用习惯和场景，避免成为「产品推销员」。

03 讨论反馈

产品负责人要收集关键干系人（和用户）的反馈，及时记录最新的改进与设想为新的需求。在体验试用环节，Scrum团队可以通过以下几种方式，观察用户体验，洞悉真实反馈。

• 注重整体的展示，避免成为验收测试

让干系人和用户体验功能并非授权全自主探索——开发成员需要提供必要的场景描述，还原功能使用场景，让用户更有代入感；但，切忌进行步骤指导，过多的干预反而不利于观察真实反馈。

另外，不要逐一演示用户故事。开发成员应尽可能引导用户对整个产品/功能模块进行试用，并关注基于产品整体的功能完整性和衔接流畅性，观察和分析可能存在的优化空间。

• 细心观察用户表现，敏感捕捉使用障碍

在用户体验功能时，Scrum团队应该留心观察他们自然表达和流露的语言、表情、操作和使用习惯等，要具备捕捉异常的敏感度。

比如用户是否在使用期间出现困惑表情、在无反应的地方反复点击等等。通过深入挖掘用户行为背后的原因，了解最真实的行为反馈。

• 使用开放性问题，引导用户自主表达

与干系人和用户协作、沟通和讨论时，避免使用「是不是」、「有没有」等封闭性问题；多用开放性问题，一步步引导用户表达出最真实的想法。

发现用户频繁点击某个按钮，或浏览选项的时间过长时，可以通过抛出「你希望这个按钮提供什么功能/选项（但没有满足）吗？」等问题，鼓励用户主动说出对系统功能的期待，为后续的迭代贡献有价值的意见和改进空间。

04 待办优化

在评审会的最后，产品负责人及关键干系人介绍有关后续迭代的新信息或新设想，结合当前产品或市场环境的变化，讨论即将发布的版本的产品功能，为接下来的迭代计划会议提供有价值的输入信息。

通常在会后，产品负责人会结合迭代评审会的结果，对产品待办列表和需求优先级进行重新评审和整理——这也是衡量会议成功的关键。

为了更准确地完成待办列表调整，开发团队应对未完成的工作保持开放和透明，以便产品负责人能制定更全面的决策；

产品负责人可以结合不同决策依据，应用优先级排序的三个模型和四张画布，更高效地完成调整。

更多阅读请点击：

不同决策应参考什么指标进行优先级优化？

做优先级排序时使用最多的三个模型

译文 | 四张画布教你判断「产品开发优先级」

# Liga总结

迭代评审会的核心目标是为了获取真实的用户反馈，为后续的迭代和研发工作贡献有价值的意见。

高效的迭代评审会要抓住功能展示、体验试用、讨论反馈和待办优化四个关键环节。Scrum团队以专业、高效的姿态，向干系人和用户呈现研发成果；通过引导和观察，洞悉真实场景下的使用反馈，更好地服务后续迭代。

>> LigaAI 往期精彩阅读 <<

优秀的程序员如何提升个人能力？

每日站会能不能取消？

如何消减协同合作中的认知偏差？

敏捷实践 | 《需求拆分流程图》详解

垂直切片是敏捷需求拆分的最佳实践 | 敏捷实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

【小剧场】 上午 10:00 – 会议室 – 每日站会

“人到齐了，开始吧。”

“任务顺利完成，没遇到什么问题。”

“好，下一个吧。”

……

“都说完了吗？还有没有补充？”

……

“有什么问题，需要协助吗？”

……

“都没有吧。好，那今天就先到这。”

如果你在上述小剧场产生了强烈的共鸣，那可能说明，你的站立会出现了大问题！

每日站会即站立会，是Daily Scrum应用最广泛的形式。开发团队每天会利用固定时间的 15 分钟举办内部短会，用于同步项目进展，识别和解决进度障碍。

但是在许多团队中，本应该解决障碍的站立会却变成了障碍本身：会议充斥着机械的工作汇报，对协作提升没有任何帮助；或者会议内容发散拖沓，15 分钟的站立短会经常变成 1 个多小时，成员苦不堪言。

“既然站立会没什么用，为什么不把它取消呢？”

站立会能不能取消？要不要取消？本文将从会议的内容、形式和目的三个方面，解读这个问题。

一、 站立会 ≠ 工作汇报会

站立会上有三个众所皆知的问题：

• 我昨天做了什么（以完成迭代目标）？
• 我今天打算做什么（以完成迭代目标）？
• 我（在完成迭代目标过程中）遇到了什么问题、需要什么帮助？

许多人认为，站立会就是在向Scrum Master汇报前一天的工作进度。事实上，Scrum Guides明确指出，Daily Scrum是面向开发者的会议，而不是面向Scrum Master的。

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

站立会的关键角色是开发者。在非必要情况下，Scrum Master可以不参加会议；在会议中，Scrum Master应该起到把控会议方向和解决困难的作用，而不是接受成员的工作汇报。

与过去工具匮乏的时代不同，当代的敏捷团队可以运用各种工具或方法直接、清晰地呈现每位成员的工作任务和完成进度，并且保持信息公开和同步，比如 LigaAI 的「跟进迭代」功能。

因此，「同步迭代进度」的本质，是让任务上下游的成员获取有关迭代事项的最新信息，以便对方能对接下来的工作做出及时、适当的调整。在站立会上，同步的一定是与他人工作有关的信息，而不是纯粹的「我做了什么」和「我要做什么」，比如：

• 任务A的工作量比较大，预计在今天上午才能完成，下游的同学请再等等；
• 任务B存在技术难点，具体是XX问题，需要大家的协助推进；
• 我今天准备着手解决工作C，需要和下游成员开会讨论。

站立会的第二个会议重点是主动减少障碍，即对工作中遇到的问题主动地进行求助，并寻求解决。通过回答「遇到了什么困难」，主动地寻求团队其他成员和Scurm Master的协助并解决问题，实现短周期的「自查-修复-优化」，消灭迭代风险，以更快、更好地状态开启新的工作。

在敏捷协作中，切忌埋头苦干。只有所有成员齐心协力地达成迭代目标，提升价值交付的速率，才符合敏捷开发的要求。

二、 Daily Scrum ≠ 站立会

另一个误区是，Daily Scrum就是开站会。

Daily Scrum是将每日工作视为一个小迭代，通过定期发起 15 分钟的集体活动对已完成的工作进行反馈和优化，完成「计划-实践-检查-优化」循环。而站立会只是实践Daily Scrum的一种形式。

在Scrum Guides中，对Daily Scrum的形式说明是这样的：

The Developers canselect whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

也就是说，开发者可以选择以任何形式完成Daily Scrum，只要能更快地完成迭代目标。

站立会之所以被广泛应用，是因为比起舒适、轻松的坐姿开会，站立姿势天然附加的「不适感」和「紧迫感」更容易让人集中注意力，提高会议效率。但这不意味着「站立会」是Daily Scrum的唯一解。

依旧是老生常谈的道理：条条大路通罗马。只要能够实现信息高效同步，优化协作方式，提升迭代效率，不管Daily Scrum是躺着开、坐着开还是站着开，哪怕是改站立为平板支撑、深蹲、马步、哑铃托举都是可行的。

不拘泥于形式，只做最正确的事。敏捷开发本就应该竭尽全力，寻求最佳的路径持续改进工作。

三、Daily Scrum ≠ 每天开会

Daily Scrum将每日工作视为一个小迭代，通过「计划-实践-检查-优化」循环，减少迭代进度的风险，更快地实现迭代目标。

· 敏捷团队为什么要每天开会同步进度？

敏捷开发通过短周期、快速地向用户提供价值交付。在时间紧、任务重的多人协作语境下，团队成员各自认领了组成用户故事的部分子任务，彼此的工作紧密关联。敏捷团队需要通过每日会议，及时同步迭代进度，更好地管理迭代目标。

第二，攻破技术难题需要及时反馈和集思广益。跨职能的自组织团队和Scrum Master存在，都能帮助成员更高效、快速地解决工作问题，扫清迭代风险。

第三，集体出席会议是早期实现信息同步的最佳实践。在那个异步/远程协作工具匮乏的时代，发起会议和面对面沟通是保证有效传达和注意力集中最有用的途径。

· Daily Scrum一定要每天开会同步进度吗？

正如前面所说，现在有非常多简单易用的协同工具（比如LigaAI）可以轻松实现团队内的信息共享和同步，在线会议和即时通讯工具等远程办公工具也能随时随地为解决问题提供服务。

因此，在工具的有效帮助下，Daily Scrum可以不用每天开会。换句话说，站立会的频率是可以调整或者取消的。

敏捷团队可以根据任务关联强度、团队工作节奏和进度同步需求等综合判断，调整Daily Scrum的周期，适当地拉长集体反馈和优化的间隔，更好地服务团队。

· 取消每日站会，进度同步该如何实现？

每日站会的目的是通过及时的进度同步和问题反馈，优化协作方式，追求并实现更快的价值交付。在定期的群策群力来临前，敏捷团队可以使用各种方式，实现迭代进度的有效同步。比如：

• 在LigaAI的规划迭代或者Kanban中同步信息
• 使用共享表格或文档，下班前完成内容同步
• 配置全员可见的物理看板，手动完成内容更新
• 用简单的格式，群发工作日报/周报邮件
• 建立Done-List，通过群接龙完成进度同步

团队协作没有标准答案，最适合团队的决策就是最正确的决策。早上开站立会，或者晚上九点开远程会议，亦或者用共享文档代替开会，都没有优劣之分。Daily Scrum只为了同步迭代进度，推进更好的敏捷协作，更快地实现价值交付。

· 如果成员不愿意主动获取/同步进度信息，怎么办？

在《自组织是管理者和成员的双向奔赴》一文中，LigaAI创始人 Ryan 已经做出了解答。

自组织团队非常强调付出。其一，每个人都关心团队目标中未完成的工作，并主动承担任务。其二，成员会观察除自己手头工作外，团队其他人是否有人需要帮助，而不是只在乎自己眼前的“一亩三分地”。

如果成员一直不能履行承诺，或者经过几次培训支持仍然没办法跟上大部队的节奏，那管理者就需要做出成员优化。同样的，成员也会主动表示，团队中有成员长期拖后腿，我们需要管理者介入招募能够一起合作的伙伴。

# Liga总结

不在每日站会上做工作汇报。高效的站立会只传递与他人有关的进度信息，以促进更紧密、更顺畅的合作。

不拘于形式，做最正确的事情。只要能够提升成员的专注度，高效完成会议目标，提升会议效率，无论是舒服地坐着，或是痛苦地平板支撑，都是可行的。

选择最适合团队的Daily Scrum运行模式。根据团队规模、任务关联强度、沟通需求等综合判断，选择最适合团队协作方式。

>> LigaAI 往期精彩阅读 <<

验收标准，用户故事的第三个 Checklist

如何消减协同合作中的认知偏差？

敏捷实践 | 《需求拆分流程图》详解

垂直切片是敏捷需求拆分的最佳实践 | 敏捷实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

在敏捷开发中，想要评估一个故事是否达到客户对需求的期待，就要让它去接受「验收标准」的考验：用户故事必须「通过」所有的验收标准，才算是真正地产生价值。

DoD 是对迭代中「所有」工作事项或用户故事的「基本要求」，而验收标准则是对「特定」用户故事的「需求细节」进行的逐一验证。

一个工作项目是否能如质如期地完成，最重要的部分就取决于开工前是否有明确的「验收标准」。

一、 验收标准的目的

01 描述明确的需求范围

通过对验收标准的讨论，团队可以了解产品负责人与利益关系人对需求的期待，也能更明确地掌握需求的范围，方便估计时程与测试涵盖范围。

02 描述错误的案例处理

编写验收标准条例可以全方位地考虑需求可能会出现的限制与错误情况，并延伸对应的处理方式。在开发过程中，实现快乐路径（Happy Path）相对简单，但「错误／例外处理」却常常被遗漏掉。

03 增加共识的讨论模式

透过对验收标准的讨论，产品负责人和开发团队能够一次又一次地理解需求目的，确保对需求持有相同的理解，才能在最后的展示阶段完整地呈现结果。

04 提早列举出测试案例

书写验收标准的过程也是测试人员和产品负责人向开发团队说明和同步测试最低标准的过程。这样才不会出现开发产出越过测试，或待测试项目未完成开发等情况。

05 时程工期的有效估计

只有完成验收标准的讨论后，开发团队才能更好地明确需求和测试的范围，对需求开发做出更准确的估计，其中包括时间、人力的绝对估计，以及点数、大小的相对估计。

二、 验收标准的写法

常见验收标准的写法有三种，分别是情景式、规则式和习惯式。

01 情境式写法 Scenario-based

「情境式写法」是面向场景的，其信息描述最为完整，也因此在敏捷团队中被更广泛地传播和应用。

情境式写法的结构包含了以下五个元素，传递了「测试用例」和「价值交付」两方面信息。

• 情境 Scenario：描述用户使用的场景／情景
• 假定 Given：描述验收标准的预先设定条件
• 当 When：描述用户在什么情况／操作下
• 然后 Then：描述预期会发生的结果
• 而且 And：描述预期会发生的更多结果

举个例子说明一下

情境 用户帐号登录
Given 用户进入「账号登录」页面，
When 用户输入错误的用户名或登录密码时，
Then 登录页面会弹出「密码错误」的提示，
And 登录页面也会呈现「忘记密码」跳转入口。

02 规则式写法 Rule-based

「规则式写法」是用条列的方式列出所有需要验证的测试案例，通常是一份清单形式的文件。相比情景式写法，规则式的验收标准能覆盖更多、更广的测试范围，但也省略了对需求价值的描述和说明。

测试案例「用户账号登录」的验证规则如下：

• 用户输入正确的账号、密码时，可以登入账号页面查看账号信息；
• 用户输入存在的账号、错误的密码时，需要出现提示信息「密码错误」；
• 用户输入不存在的账号时，需要出现提示信息「该账号不存在」；
• 用户连续输入错误的密码超过三次时，需要出现提示信息「密码已错误三次，请重设密码（附跳转）」。

03 用户角度的习惯写法 Customer-based

有些测试人员可能会用流程图、思维导图、检核表等方式书写验收标准，但写法不是重点，能清楚呈现「验收标准」，说明客户需求期望的就是好方法。

三、 验收标准的八点误区

1. 工作项目完成后才进行验收标准的讨论。

2. 验收标准事无巨细，单一功能就有不同组合的测试。

3. 验收标准范围太广，已经超过本次要进行的范围。

4. 验收标准不是用户看到的情境，而是底层的技术细节。

5. 团队对验收标准还没有达成共识就开始工作。

6. 验收标准无法独立，需要其他验收标准的配合才能进行测试。

7. 测试的条件是充满变数的，无法模拟的。

8. 只由测试人员或产品负责人单向设计出的验收标准，开发团队事前不知情。

原文作者：Vince Huang

文章来源：Medium【文思不藏私】专栏

>> LigaAI 往期精彩阅读 <<

如何消减协同合作中的认知偏差？

敏捷实践 | 《需求拆分流程图》详解

垂直切片是敏捷需求拆分的最佳实践 | 敏捷实践

Liga妙谈 | 自组织是管理者和成员的双向奔赴

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

今天跟大家介绍敏捷开发中共识建立的两大神器：DoR 和 DoD。

​

一、 DoR 是什么？

DoR = Definition of Ready，即对「准备就绪」的定义，是敏捷开发中把控研发质量的第一道门。DoR 关注研发起点的质量，定义了用户故事可以被研发团队接受并进入开发阶段的最小要求，是需求准入的标准。

DoR 的价值在于，它规范了开发对象的质量底线，能够有效防止开发侧的资源、时间或精力的浪费：如果一个待开发的用户故事不符合 DoR 要求，那么研发团队有权将其退回，不在最近的迭代中开发它。

01 Garbage In, Garbage Out

引用 Brian Will 的观点：“用户故事「准备就绪」非常重要——将不完整或未优化的用户故事放入冲刺中会出现问题，因为它会遵循「Garbage In, Garbage Out」原则：如果开发人员处理的是不够详细或定义不充分的用户故事，他们就不会产生高质量的代码。”

Brian 认为一个「准备好的 Ready」待办事项应该是清晰、可行和可测试的。

• 清晰（Clear）意味着团队所有成员能够对同一个用户故事达成共同的理解。通过协作编写用户故事，并为高优先级添加验收标准，需求的清晰度可被提高。
• 可行（Feasible）要求用户故事能够依照 DoD 在一个冲刺中被完成，否则，该故事需要被进一步分解。
• 可测试（Testable）指用户故事可以使用某种方法确定其是否按照预期工作。验收标准确保每个故事都是可测试的。

02 DoR 的参考例子

• 用户故事符合 INVEST 原则
• 用户故事是清晰的
• 用户故事是可测试的
• 用户故事是可行的
• 用户故事已定义
• 用户故事验收标准已定义
• 用户故事依赖已明确
• 用户故事已由开发团队做过粒度划分
• Scrum 团队已接受 UI 原型设计
• 指定场景的性能指标已明确
• 指定场景的可扩展性指标已明确
• 指定场景的安全指标已明确
• 验收用户故事的人已明确
• 团队都清楚用户故事所表达的意思

二、 DoD 是什么？

DoR 关注待开发的用户故事，而 DoD 则更多地聚焦待发布的价值增量。

DoD = Definition of Done，译为完成定义，是用于把控研发质量的第二道门。它是需求准出的标准，通常呈现为一份清单形式的简短文档，定义了用户故事被视为「完成」所需要达到的最低验收条件，常由产品负责人 PO 和开发团队共同协商决定。

DoD 通过建立通用的标准，确保团队每位成员对价值增量的完成具有相同的理解，避免了团队内外潜在的认知偏差；同时，清单内容还能提升团队的信息透明度，辅助工作点数的评估和计划制定，推进故事的完成。

01 DoD 的内容范围

在敏捷开发中，「完成」意味着「无需进行更多工作，可直接交付」，因此 DoD 内容至少应涵盖设计、编码、集成、测试和记录等全套产品开发流程。

Brian Will 指出 DoD 通常会说明以下内容：

• 用户故事所处的操作环境和集成级别（哪个特定版本的 Linux、Android、iOS 或浏览器）？
• 需要输出什么级别的文档（自动生成的 Javadoc，还是完整的终端用户手册）？
• 有什么质量期望（用于演示的基本功能，还是功能完整且健壮的应用程序）？
• 有什么安全期望（无需安全审查，还是需要从代码审查、代码扫描到网络安全配置等各方面都要进行安全审查）？
• 有什么可扩展性期望（用于演示的 10 个并发，还是扩展至10 万个并发用户）？

02 DoD 的不同维度

Scrum 联盟按照需求的不同层次，将 DoD 分成三种级别：用户故事DoD、冲刺DoD 和发布DoD。

用户故事DoD，也称功能/需求DoD。它声明了故事可交付的底线，即用户故事应完成哪些事情才可以被判定为开发完成，达到可交付的标准。

用户故事DoD 的制定可以从以下两方面考虑：

• 用户故事的描述及拆解符合 INVEST；
• 用户故事有验收标准，即 Acceptance Criteria。

冲刺DoD，或迭代DoD，定义了每个 Sprint 需要完成哪些事情，其输出才是可交付的。通常包含以下内容：

• 所有代码通过静态检测，严重问题都已修改；
• 所有新增代码都经过 Code Review；
• 所有完成的用户故事都通过测试；
• 所有完成的用户故事得到 PO 的验证。

发布DoD 定义了增量交付的最低要求，可以参考以下内容辅助制定。

• 完成发布规划所要求的必须具备的需求；
• 至少完成一次全量回归测试；
• 符合质量标准 (Quality Gate)，譬如所有等级为 1、2 的缺陷均已修复，3、4 级缺陷不超过 10 个；
• 有发布通知，即 Release Notes；
• 有用户手册；
• 产品相关文档已全部更新；
• 代码已部署到发布服务器上，并冒烟通过；
• 原始需求提交人完成 UAT；
• 对运维、市场、客服的新功能培训已完成。

此外，在子任务层面，敏捷团队也可以通过开发任务DoD 更好地规范任务完成，比如：

• 代码已经提交到 Git；
• 代码通过单元测试；
• 代码经过 Code Review；
• 代码通过集成测试。

03 DoD 的参考例子

• 代码已完成（所有代办事项已经完成编码）
• 代码已注释、已提交，版本库当前版本能正常运行
• 结对检视已完成（或者采用结对编程），代码符合开发标准
• 构建没有错误
• 单元测试全部通过
• 部署到测试环境并通过系统测试
• 通过 UAT（用户验收测试）并签字确认符合需求
• 任何编译/部署/配置变化都已实现/记录/沟通
• 相关文档/图表已完成或已更新
• 任务剩余的小时数已设置为 0，任务已关闭

三、 Liga 总结

1. DoR 把控研发起点，是需求准入的标准。用户故事必须符合团队要求才能进入待开发列表。

2. DoD 把控研发终点，是需求准出的标准。它定义了价值增量交付的最低验收条件，适用于所有用户故事。

3. Garbage in, garbage out. 敏捷团队必须严格把控需求准入的标准，才能更顺利地推进后续工作，保证研发质量。

参考资料

1. https://resources.scrumalliance.org/Article/definition-dod

2. https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will

>> LigaAI 往期精彩阅读 <<

敏捷实践 | 《需求拆分流程图》详解

垂直切片是敏捷需求拆分的最佳实践 | 敏捷实践

Liga妙谈 | 自组织是管理者和成员的双向奔赴

敏捷之道 | 敏捷开发真的过时了么？

如何串连三个「语言工具」描述简洁清晰的需求？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。