误区 1：项目增量计划是 Scrum 框架的一部分

项目增量 (PI) 规划不是 Scrum 框架本身的一部分，而是规模化敏捷框架 (SAFe) 的关键组件。

SAFe 是一个独立的框架，旨在将敏捷实践扩展到更大的组织。PI Planning 是 SAFe 内敏捷发布系列的基石，为多个团队建立同步节奏，共同努力实现共同目标。

它制定了发布路线图，确保它们以协调的方式逐步进展。值得注意的是，虽然 SAFe 是一种流行的扩展敏捷方法，但它只是众多可用方法中的一种。另一方面，Scrum 主要是为较小的团队设计的，不包括大规模规划和协调的具体规定。

误区 2：开始之前详尽的产品待办事项列表

Scrum 中一种可能对 Scrum 团队有害的流行做法是过度使用详细的前期计划。虽然规划是敏捷和 Scrum 的一个重要方面，但过分强调详细的前期规划可能会导致僵化的计划，可能无法适应不断变化的情况。

这可能会阻碍团队有效响应新信息、反馈或不断变化的优先事项的能力。在制定总体计划和保持足够的灵活性以根据实时反馈和新出现的需求进行调整之间取得平衡非常重要。

过于详细的计划也会导致错误的确定感，当计划不可避免地需要调整时，这可能会导致沮丧和失望。对于 Scrum 团队来说，接受“敏捷”原则非常重要。

在团队开始冲刺之前，不需要完全充实详尽的产品待办事项列表。事实上，产品待办事项列表是一个随着时间的推移而变化的动态文档。它作为功能、增强功能、错误修复以及可能为产品增加价值的任何其他内容的有序列表。

在产品被淘汰之前，产品待办事项列表永远不会完成，因为客户的需求随着时间的推移而变化，组织的优先级和技术也在变化。

从最初的优先级高的积压工作开始，并随着团队的前进对其进行完善，这不仅是可以接受的，而且确实是完全拥抱敏捷性的唯一方法。这可以实现对不断变化的需求和利益相关者反馈的灵活性和响应能力。

误区3：Scrum Master 只负责确保事件发生

消除 Scrum Master 的角色仅以促进活动为中心的误解至关重要。

虽然监督和确保 Scrum 活动的有效性是他们职责的一部分，但 Scrum Master 的职责还涵盖更多内容。Scrum Master 充当教育者的角色，传授有关 Scrum 框架的知识并阐明每个事件的重要性。它们有助于在团队内营造积极且富有成效的环境，确保会议在时间范围内且具有建设性。

他们在促进团队成员之间的协作、提供辅导和指导以增强他们对 Scrum 原则的理解和应用方面发挥着关键作用。除此之外，Scrum Master 还负责推动 Scrum 在整个组织中的采用，努力持续改进价值交付。

他们的影响力远远超出了单纯的活动促进，因为他们致力于提高 Scrum 团队和整个组织的整体熟练程度和有效性。

误区4：敏捷团队无法按时完成任务

敏捷团队不按时完成工作是一个常见的误解。事实上，Scrum 可以使团队更有可能真正达到严格的最后期限，因为团队可以随着学到的更多知识而适应。此外，敏捷框架通常强调设定可实现的、现实的目标的重要性，并为团队提供灵活性来找到实现这些目标的最佳方法。

Scrum 尤其可以帮助团队在每个 Sprint 中以较小的增量交付价值。通过将项目分解为可管理的块并根据反馈调整优先级，敏捷团队可以通过增强可见性、保持更高的改变方向的能力、更快地交付价值和降低风险来满足最后期限。

误区 5：敏捷只适用于软件

上图比较了 2020 年和 2021 年的“敏捷现状”报告。该图显示，敏捷的采用在许多业务领域（包括运营、营销和人力资源）都取得了显着增长。 

虽然敏捷框架植根于软件开发，但敏捷原则可以有效地应用于各种复杂问题。敏捷框架倾向于增强协作、适应性和持续改进，使其适合任何需要灵活响应不断变化的需求和客户需求的工作。从营销活动到产品开发等等，敏捷原则可以提高生产力并在各个领域创造价值。

END

消除这些常见的 Scrum 误解对于更深入地了解敏捷框架以及如何在各种环境中有效应用它们至关重要。通过认识 Scrum 的真正本质，团队可以释放敏捷实践的全部潜力，交付高质量的产品，同时在不断变化的业务环境中保持适应性和响应能力。请记住，采用敏捷并不是要遵循一套严格的规则，而是要拥抱协作、持续改进和以客户为中心的心态。

DoD和验收标准是产品开发中的两个基本概念。虽然 DoD 是 Scrum 的一部分，但验收标准是一种额外的实践。

它们在确保质量和满足利益相关者的期望方面都有不同的目的。

DoD适用于每个产品待办事项列表项。它是一个全面的清单，通过包括功能、性能、安全性、合规性以及适用于所有增量的其他必要标准来确保质量。

正如Scrum指南中提到的，当产品待办事项列表项满足DoD 时，增量就诞生了。

DoD 代码质量和完整性示例：

所有代码都必须通过同行评审流程，没有严重问题。

对所有代码编写单元测试，实现80%的代码覆盖率。

所有代码均符合团队的编码标准。

另一方面，验收标准是特定产品待办事项列表项必须满足才能被客户、用户或其他系统接受的条件。这些是针对单个项目量身定制的，并详细说明了该特性或功能的预期行为和要求。验收标准不是 Scrum 的一部分，而是有助于创建透明度的补充实践。

用户购物车结帐的接受标准示例：

结帐流程应处理购物车中的多个商品（至少十个唯一商品）。

在完成购买之前，用户必须可以选择输入折扣促销代码。

成功购买后，用户应收到确认号码和电子邮件订单摘要。

DoD和验收标准的关键差异

1. 它们是什么？ DoD是一个广泛的清单，适用于每个产品待办事项列表项目，确保一致性和完整性。验收标准特定于各个待办事项或功能，详细说明了要求被视为完整必须满足的条件。

2. 它们的范围是什么？ DoD通常在组织或团队级别进行定义，并在连续的 Sprint 中保持相对稳定。验收标准是在积压项目级别确定的，并且不同标准之间可能存在很大差异。

3.它们目的是什么？ DoD确保产品增量符合列出的质量标准，并且有用并为将来的发布做好准备。验收标准重点关注产品增量是否满足产品待办列表项的特定要求。

4. 谁创造了它们？ 创建DoD是一个涉及整个团队、有时甚至是多个团队或整个产品组织的协作过程。验收标准主要是产品所有者的责任，但也可以委托给开发人员，并且通常是与利益相关者合作制定的。

5. 何时进行评估？ 在冲刺结束时引用并应用国防部来评估工作是否完成。验收标准在整个冲刺过程中用于指导开发和测试。

END

DoD和验收标准可以相辅相成。DoD确保整个产品开发的统一质量和完整性，而验收标准则提供具体的项目级要求，以满足利益相关者的需求。两者对于提供符合用户期望和目标的高质量产品至关重要。

本文以面试题的视角，帮助团队选择合适的候选人以及面试者作为复习题进行参考。这些题目源于我在XP和Scrum方面18年的实践经验，担任产品负责人和Scrum大师，并代表我的客户面试数十名Scrum大师候选人。

到目前为止，这份Scrum Master面试指南已经被下载了超过27,000次。

这些答案反映了作者的个人经历，可能对每个组织都无效：对组织A有效的答案可能对组织B无效。

考虑到将“敏捷”应用于任何组织的复杂性，没有合适的多项选择题来确定候选人的敏捷心态。

本文是作者对敏捷实践有着全面的看法：敏捷涵盖了从产品愿景到产品发现（构建什么）再到产品交付（如何构建）的整个过程。

作为Scrum Master（或敏捷教练）如何创造价值？

以下问题和回答旨在对候选人在应用敏捷产品开发原则以提高客户价值和交付经济性，并增强各种组织环境中的可预测性以应对当前经济环境方面的经验和技能进行细致的理解：构建。

精选面试题

1.如何定制Scrum实践以提升客户价值，特别是在对敏捷实践抵触的行业中？

背景：此问题探究候选人将Scrum原则应用于敏捷不是常规的行业的能力，强调客户为中心的产品开发。它寻求候选人在挑战环境中创新应用Scrum以促进客户参与和满意度的见解。这也是候选人在面试过程中建立自信和与面试官建立融洽关系的机会。

可接受的回答：出色的回答将详细描述候选人如何通过小规模试点项目或研讨会展示敏捷的好处来应对抵触，他们可能会描述特定的调整Scrum事件或制品以与行业特定的约束相一致，最终增强客户反馈循环，并最终导致直接解决客户痛点的产品特性。

2.在不影响产品质量的情况下，如何通过战略Scrum应用显著降低了生产成本？

背景：这涉及到候选人在支持团队容量分配的优化和在Scrum框架内优化工作流程以降低成本方面的熟练程度。这是关于在维持高质量标准和通过敏捷实践实现成本效益之间取得平衡。

可接受的答案：寻找一个候选人确定开发过程中的浪费性实践或瓶颈，并实施有针对性的Scrum实践来解决它们的叙述。例子包括优化产品积压列表以专注于高影响功能，改善跨功能协作以减少依赖性，或利用自动化测试来加速交付时间同时保持质量标准。答案应突出候选人的分析性解决问题的方法和帮助团队接受以节约成本为导向的企业家立场来解决客户问题的能力。

3.请分享一下在变动频繁的市场中使用Scrum来提高产品交付可预测性的经验？

背景：这个问题探讨了候选人在市场波动中利用Scrum提高交付可预测性的能力。它涉及利用敏捷的灵活性来适应不断变化的优先级，同时保持稳定的交付速度。

可接受的答案：候选人应该讲述一个实例，在这个实例中，他们利用Scrum工件和事件在不断变化的环境中更好地预测交付时间。这个例子可能涉及调整Sprint长度，更动态地确定产品待办事项列表项的优先级，或者在Sprint评审或其他创建一致性的机会（例如用户故事映射会议）期间，让利益相关者更密切地参与进来，以重新评估优先级。故事应该强调他们在平衡灵活性和可预测性方面的战略思维，以及他们在与利益相关者设定现实期望方面的沟通技巧。

4.如何在领导层和中层管理人员对敏捷实践持怀疑态度的情况下，在组织中推广Scrum的价值？

背景：这个问题考察的是候选人在抵制变革的环境中支持Scrum的能力。这样的环境需要对敏捷原则有深入的理解，并具备强大的倡导和教育技能。

可接受的答案：成功的候选人将描述一个多方面的策略，包括向领导层宣传敏捷的好处，组织互动研讨会以揭秘Scrum实践，并确保快速取得成功以展示价值。他们还可能讨论建立一个实践社区以维持敏捷学习，并分享成功案例以建立动力。答案应反映他们的毅力、有说服力的沟通以及他们作为变革推动者的角色（在此处了解更多关于转型期间成功的利益相关者沟通策略）。

5.请描述如何进行有效的Sprint回顾，以推动持续改进？

背景：该问题旨在考察应聘者促进回顾会的技术，这些回顾会对团队成长和产品改进做出真正贡献。该问题旨在了解他们如何确保这些活动有成效、包容性和可操作性。

可接受的答案：一个全面的回答将概述一个结构化的回顾方法，包括准备、促进、后续实践和对框架的有价值的增强，例如，接受直接负责的个人推动团队认为有益的变革的想法。候选人可能会提到使用各种格式来保持会议的参与度，确保所有团队成员贡献的技术，以及优先行动项目的策略。他们应该强调他们跟踪改进的方法，以确保问责制，并展示回顾对团队绩效和士气的影响。同样，这个问题可以让候选人区别于任何Scrum Master的核心能力。

6.如何平衡利益相关者的需求和敏捷原则，以帮助Scrum团队有效地优先处理工作？

背景：此问题旨在了解候选人支持Scrum团队以及特别是产品负责人在竞争性需求、将利益相关者期望与敏捷原则对齐以便让团队将精力集中在最具影响力的工作上，从客户和组织的角度来看。

可接受的答案：候选人应提供一个支持产品负责人的例子，通过采用优先级确定技术（如用户故事地图）与利益相关者合作，以达成最有价值的优先级，从而在此过程中形成有价值的产品目标和路线图。他们应强调自己的谈判技巧、促进共识的能力以及透明沟通的熟练程度，以管理期望并为团队保持可持续的工作节奏。

7.枯燥项目与动力 在存在高度重复任务的长期项目中，如何保持团队动力和参与度？

背景：此问题探讨候选人在持续项目或重复任务的单调环境中保持团队参与度和动力的策略。虽然我们都喜欢一直从事尖端技术工作，但日常运营通常包括我们认为繁琐复杂但却被认为有价值的工作。这个问题衡量了候选人在可能不那么激励人心的环境中保持热情并保持高绩效的能力。

可接受的答案：期望候选人讨论创新的方法，如引入游戏化元素来处理乏味的任务，通过在团队内轮换角色来提供新的挑战，并建立定期的技能增强研讨会。他们还可能提到庆祝小胜利的重要性，例如通过赞扬卡片，以及确保团队的工作与个人成长目标保持一致。回答应强调他们对于在具有挑战性的环境下保持积极和激励的工作环境的承诺。

8.引入新团队成员 请描述整合新团队成员到已建立的Scrum团队中的经验，确保过渡无缝，并保持团队的生产力？

背景：此问题评估候选人将新团队成员引入团队的方法，以最小化中断并最大化整合速度。这种方法对于保持现有团队的凝聚力和生产力动态至关重要，承认Scrum团队会定期变换成员。

可接受的答案：期望答案详细说明一个有结构且包容性强的引入计划，例如包括：

导师计划， 伙伴制度， 团队规范和期望的清晰文档，例如工作协议和“完成定义”， 团队活动，以及 逐渐融入Scrum团队项目的过程，通过配对编程或跟踪。

候选人应强调培养一个包容性团队文化的重要性，该文化欢迎问题，并在新成员的学习旅程中给予支持，确保他们从第一天开始就感到受到重视并成为团队的一部分。

9.冲突解决 您如何处理Scrum团队内部或团队与利益相关者之间的冲突，以确保持续进展和合作？

背景：在任何团队动态中，冲突是不可避免的。这个问题探讨了候选人在导航和解决分歧方面的技能，以一种加强团队和利益相关者关系而不是削弱它们的方式。

可接受的答案：候选人应描述他们作为中立调解人的能力，积极倾听理解所有观点，并促进以利益为重点而不是立场的问题解决会议。他们还可以讨论创建开放对话的平台，例如以冲突为主题的回顾会议，以及培养信任和心理安全文化的重要性，其中冲突可以被建设性地表达。回答应传达他们将冲突转化为增长和更深刻理解机会的能力。然而，候选人还应明确表示，并非所有团队成员之间的争议都可以解决，一旦所有团队内的选项都已耗尽，Scrum Master 需要请求管理支持以结束冲突。

10.回顾一次在跨多个团队扩展Scrum时遇到重大挑战的经历。如何解决挑战，以确保组织在敏捷转型中取得成功？

背景：扩展敏捷实践是一项复杂的任务，可能突显出组织的障碍和抵制。这个问题探讨了候选人在成功扩展Scrum方面的经验，确保多个团队之间的对齐和凝聚力，并帮助每个人看到转型的价值。

可接受的答案：这个开放性问题允许候选人讨论他们对像LeSS等框架的熟悉程度，或者分享他们对SAFe是否有用的观点。此外，在哲学层面上，它也打开了讨论“敏捷”是否可扩展的话题，因为大多数扩展框架对问题应用了更多的流程。此外，反对意见指出了有必要通过赋予最接近问题的人在给定的约束和治理规则内做出决策来减少组织的规模。候选人应强调保持共享愿景和目标的重要性，创建实践社区以分享知识和最佳实践，并解决文化障碍以促进变革。他们还应反思高管赞助的重要性，主要利益相关者的战略参与以支持和推动扩展工作的必要性，以及失败文化的必要性。

如何使用Scrum Master面试问题

如何使用Scrum Master面试问题 Scrum一直是一项实践性很强的业务，要在其中取得成功，候选人需要对“动手做”有激情。虽然基本规则简单易懂，但要让具有不同背景、参与程度和个人议程的一群人组成并发挥团队的作用却是一项复杂的任务。此外，组织规模越大，管理层级越多，失败的可能性就越大。

从我的面试经历来看，或许是我见过的优秀公司还不够多，几乎没有公司能正确使用TDD的。

首先绝大部分公司都没有做单元测试，原因几乎众口一词是没有时间，我们很忙，似乎是测试驱动开发是个浪费时间的工作。

诚然，在写代码的时候，需要额外写一堆测试代码，这当然需要时间。但这边你不写测试代码省下的时间，会在你集成测试的时候加倍偿还。就好比你现在要出去跑步，你说换个跑鞋太浪费时间，决定穿拖鞋去跑？

一些做了单元测试的公司，是把单元测试用来做类似协议测试的作用。比如测试的时候并不隔离数据库访问，而是需要在数据中伪造数据。这样的单元测试不具备可重复性，往往测试一次验证完功能后即成为废代码。

由于Maven等工具在编译的时候缺省自动跑单元测试，为了避免出错在持续集成环境还需要手工Skip单元测试。这样的单元测试也起不到多大作用。

单元测试应该怎么做

那么究竟单元测试应该怎么做？应该测试哪些东西呢？

首先单元测试应该是测试业务逻辑。业务逻辑是我们用来实现我们业务的东西，包括业务实体、业务用例。而这部分，严格来说来是和数据库、协议不相关的。数据库只是我们为了实现对业务实体的持久性存储而采用的工具，这个工具可以根据需要随时替换。

而数据库的正确性不是我们要测试的，这个由数据库厂商保证。因此我们的单元测试，应该不依赖数据库，因此也不需要启动数据库。有些为了能快速测试，在单元测试的时候启动内存数据库，我觉得这个是点错了科技树，跑偏了。

其次单元测试是每次测试尽量小的一个单元，往往是一个业务用例中的某个特性。比如一个单元测试方法，测试的可能是新增用户这个用例中手机号码为空的情况。

当你一个单元测试很难写的时候，往往要反思一下：我的这个单元（方法）是不是违反了单一职责原则，实现了太多的东西？一个方法可能有多个业务分叉，这时候我们需要写多个测试方法，对各个业务分叉分别进行测试。

然后要注意测试代码的质量。比如可以把测试某一个用例的放一个测试类，每个测试方法命名都考虑测试目的，比如testCreatUser_mobile_is_null这样，一眼就能看出你的测试目的。

测试代码也要具有可读性、高聚合性，符合DRY原则，否则测试代码如果不可维护，久而久之也就容易被荒废。

弄清了要测试什么，那么我们的测试方法就很清楚了。为了测试业务用例，我们需要用Mock来模拟数据库访问接口（如果有的话），然后对测试用例的逻辑进行测试，保证100%代码覆盖。在Java可以用Junit配合Mockito来实现，使用coverage来查看代码覆盖程度。

在DDD的开发中，由于业务领域、业务实体都集中在Domain层，因此单元测试变得更加清晰：只要在Domain层进行单元测试即可，并且要保证100%的覆盖率。因此，有了DDD，TDD变得更加容易、更加明确。

训练营课程大纲

模块一：通识掌握TDD基础概念与规则

带教练习：FizzBuZZ

模块二：理清业务规则，梳理代码逻辑

带教练习：网球记分

模块三：设计测试用例，学习代码重构

带教练习：生命游戏

训练营收益

理解TDD以终为始的开发思维；

整体掌握TDD基本理念与规则；

通过FizzBuzz练习理解TDD流程；

通过网球记分练习理解TDD逻辑；通过生命游戏练习设计测试用例识；

别坏代码，理解代码重构手法。

面向对象

有基本Java或Javascript编程能力的程序员
想进一步提升自己编码水平
想编写更好的更容易维护的代码
不想在代码屎山上打滚了

授课讲师

训练营日程安排

 Day1 直播(晚8点)

开营；

讲解TDD基本概念与规则。

 Day2 练习

练习1 FizzBuzz；

群内答疑。

 Day3 直播(晚8点)

FizzBuzz练习讲解+作业点评；

知识点讲解：如何梳理业务规则。

 Day4 练习

练习2 网球记分；

群内答疑。

 Day5 直播(晚8点)

网球记分练习讲解+作业点评知识点；讲解：识别代码坏味道、介绍重构手法。

 Day6 练习

练习3 生命游戏；

群内答疑。

 Day7 直播(晚8点)

生命游戏讲解+作业点评；

知识重点回顾串讲；

结营。

扫描上方二维码即可报名

在软件开发过程中，工作量评估是必不可少的一步。大多数的工作量评估，采用是绝对时间，如人天、人时。这时候就会陷入小马过河的困境：究竟河水是老牛说的那样浅，还是松鼠说的那样深？

团队中人员能力、技术偏好各有不同。对大牛来说，某个Feature可能需要4小时搞定，对初级工程师，可能8小时也不够。如果按绝对时间来评估，究竟以谁的为准？按平均数？似乎总不合理。

再次，人的大脑的进化，对事物的绝对大小，总是难以估计。

我一个朋友，说去美国旅游的时候，看到一个悬崖，估计了一下大约100多米，结果别人告诉他高达900米。他作为一个很有山地户外经验的人，为何会出现如此大的偏差？答案是树。当地很多美国红杉，树木高达上百米，他的估算是根据悬崖和树的比例进行。当树的大小出现严重偏差，他的结果也就出现严重偏差了。

我们大脑对绝对值难以估计，对相对值倒是擅长。只要有一个可靠参照物，在比例不是特别悬殊的情况下，总是可以得到比较接近的结果。

但这个比例不能太大，你不能给一个细菌的重量，然后让我去估算鲸鱼。但给一颗小树的高度，去估算一栋房屋，大部分人就没问题了。

估算：用户故事

因此，用户故事点数估算的发明，解决了我们的人月神话陷阱。首先选择一个比较适中的用户故事，把他的复杂程度、工作量评估为1（也可以是其他数字）。

然后其他的用户故事，和这个基准用户故事进行比较，得出其他用户故事的点数。

由于人擅长估算相对值，而且对不同水平的开发人员，相对值是比较接近的，也不会带来人员上的偏差。那么最后，就可以得到一个比较客观的用户故事点数估算结果。

那么这个结果究竟如何转换为时间呢？毕竟，我们最后是要给出实际时间上什么时候可以完成，你给一个无单位的数字恐怕产品要揍你。

答案是经验。我们先尝试1-2个冲刺，由于每个冲刺的时间长度是固定的，在团队固定的情况下，1-2个冲刺后，我们就可以知道我们一个冲刺能做多少用户故事点数，然后用这个做预测，就可以比较准确知道我们的生产力了。

随着团队的变化、生产力提高，每次冲刺的用户故事点数可能会有波动，但会在一个相对可控的范围变动。我们因此变得对生产力比较有掌控，可以做出承诺并比较能确保完成承诺。

团队持续改进的十大行动

为了培养持续改进的文化并拥抱改善实践，对于希望提高效率、建立与利益相关者的信任以及交付能够显著影响客户生活的产品的Scrum或敏捷团队的改进建议：

定期反思与回顾

重要性：定期进行回顾能够让团队停下脚步，反思过去的行动、实践和工作流程，找出优点和改进的空间。这种持续的反馈循环对于调整流程、提升团队动力并确保团队保持敏捷、应变能力强至关重要。

步骤：确保在每个迭代结束时都能保持回顾的一致性。在这些会议之前，共同制定一个促进开放和包容性的议程。组织者应该采用匿名反馈机制和引人入胜的游戏等实践，以确保诚实和建设性的讨论，为有意义的进步和团队发展奠定基础。

执行改进行动

重要性：实施已确定的改进措施表明团队致力于持续改进，并确保从回顾和反馈中获得的见解得以付诸实践，从而产生实实在在的收益和进展。

步骤：在每次回顾结束时，共同努力确定改进行动的优先级并确定明确的责任归属。将这些行动整合到团队的工作流程中，在看板或任务列表中像处理其他任务一样跟踪它们。定期在后续的回顾中审查它们的进展，确认它们是否在完成的轨道上，并评估它们的影响，确保这些努力能够为您的流程和结果带来有意义的改进。在负责人遇到困难时提供支持。

拥抱Scrum价值观

重要性：将Scrum价值观深入融入团队的理念中，促进了一个有利于持续改进的工作环境。这些价值观指导着行为和决策过程，确保每个团队成员都与Scrum原则保持一致和承诺，从而增强了合作和效率。

步骤：举办一次专门的会议，团队共同讨论每个Scrum价值观，并确定在日常工作中体现这些价值观的具体行动或行为。创建一个团队章则或工作协议，将这些价值观纳入其中，并承诺互相对彼此负责——就像专业人士一样。

建立心理安全

重要性：心理安全是团队创新、冒险和开放沟通的基础，让团队成员能够毫无顾忌地分享想法、挑战和反馈，而不必担心负面后果。对于营造一个持续改进蓬勃发展的环境至关重要。

步骤：通过匿名调查启动团队当前心理安全状况的评估。之后，进行一次专注于积极倾听、建立共鸣和解决冲突技巧的研讨会。定期跟进进展，并将心理安全设定为回顾中的一个经常议程项目。此外，当团队的安全在组织层面受到威胁时，与领导层联系，启动关于如何改善情况的讨论。

促进利益相关者合作

重要性：有效的利益相关者合作确保团队的努力与更广泛的业务目标和客户需求保持一致。在整个开发过程中吸引利益相关者参与，可以引入多元化的观点和反馈，这些反馈可以突显出改进的未预见领域，并确保产品开发走在正确的轨道上。

步骤：将利益相关者作为一个团队进行参与，从Sprint评审开始。此外，建立清晰的沟通渠道和反馈机制，以促进持续的对话；你希望在Sprint评审之外也能获得来自利益相关者的反馈。记住要根据利益相关者的需求量身定制沟通方式；有时，这可能需要一份书面报告。

赋予团队决策权

重要性：允许团队就他们的工作做出决策，增强了他们对结果的拥有感和责任感。这种自我管理的程度对于营造一个由最接近工作的人推动持续改进的环境至关重要，从而实现更加有效和及时的改进。

步骤：首先制定一个决策框架，鼓励协作，并力求达成一致，而不是采用基于同意或多数决策的模式。直接采用同意或多数决策可能会妨碍团队的统一性，并导致派别的形成。在回顾中确定决策时应用这种包容性方法。这为团队提供了一个平台，让他们练习和完善集体决策能力，确保每个团队成员的观点都得到认可和重视。

利用视觉管理工具

重要性：像看板板这样的视觉管理工具提供了关于工作进展、优先事项和瓶颈的透明度。这种可见性有助于团队更有效地管理其工作流程，识别改进机会，并做出明智的决策。

步骤：共同建立或完善看板板，确保它真正代表团队的工作流程。它应该用于工作进行中的限制、阻塞任务和质量控制检查点。养成在回顾中评估和更新看板板的习惯，根据不断发展的团队需求和流程进行调整。在每日Scrum会议期间考虑使用“遍览看板”的技巧。

专注于客户反馈

重要性：优先考虑客户反馈可以使团队的努力立足于真实的用户需求和体验，直接推动与客户满意度和产品成功相关的改进。这确保了团队始终专注于提供价值并解决正确的问题。

步骤：建立一个系统的反馈收集流程，这可能涉及组织用户访谈、部署调查或进行Beta测试会议。将定期的反馈审查周期纳入到回顾、冲刺规划和冲刺评审会议，或产品待办事项完善会议中，以确保客户见解持续地融入到开发周期中。

培养成长型思维

重要性：在团队内部鼓励成长型思维，促进学习和适应能力的态度。它帮助团队成员将挑战和挫折视为成长的机会，推动个人和团队的发展和创新。

步骤：组织一个关于理解和接受成长型思维的研讨会，包括拆除固定思维信念的练习。激励团队成员确定并追求个人发展目标，并经常交流见解和成就，可能通过像“学习日志”或在Sprint回顾的情境中进行。

持续学习和技能发展

重要性：投资于持续学习和技能发展，确保团队保持适应能力，能够克服新挑战。它支持团队能力的发展和创新解决方案的引入，使团队和产品始终处于行业趋势的前沿。

步骤：每个迭代为团队成员安排特定时间参与学习活动，如在线课程、研讨会和午餐袋、配对或集体编程会议。通过“学习展示”或内部迷你研讨会传播新获得的知识和能力，促进共享增长和专业知识文化。

Scrum框架的存在是为了尽快向利益相关者交付价值。听起来不错，对吧？但什么是“有价值的”？对于Scrum似乎如此核心的东西，却很少有关于“价值”含义的指导。我们担心，如果没有对其进行有意义的定义，它将仅仅是一个词而已。

在这篇文章中，我们提供了一个更细致的方法来理解“价值”对于你的产品和产品待办事项的意义。

在Scrum中最大化价值

在Scrum框架中，对于Scrum团队尽可能频繁地交付有价值的增量是很重要的——至少每个冲刺一次。每个增量都使团队及其利益相关者离有价值的产品目标更近一步。没有这一点，就很难了解还需要什么，以及降低复杂工作的风险。产品负责人负责最大化开发人员完成的工作的价值。

虽然这听起来是个好主意，但在现实世界中这到底意味着什么呢？

你如何确切地说出你的Scrum团队交付了价值？你需要观察或看到发生了什么？

你的团队交付的所有工作是否都应立即对利益相关者有价值？或者可以有一些延迟吗？

“最大化价值”在Scrum团队做出的行为和决策方面意味着什么？

产品目标如何指导什么是有价值的？

Scrum团队如何决定产品待办事项中哪些项目比其他项目更有价值？他们基于什么做出这些决定？

在决定什么具有“价值”时，你采取的是哪个角度？

这些问题很难回答。Scrum指南巧妙地避免了对“价值”进行定义，并认为它取决于为其完成工作的上下文和利益相关者。但是，当一个Scrum团队缺乏对价值的工作定义时，它如何能够有效呢？我们很容易想象到一个Scrum团队通过完美地完成他们的冲刺，每个冲刺向利益相关者交付高质量的增量，但实际上却没有交付任何有价值的东西。

事实上，在僵尸Scrum的情况下，我们经常看到这种情况；尽管每个人都在按部就班地工作，但最终却没有任何有价值的东西。仅仅“做Scrum”并不能神奇地产生价值。

让我们从两个角度来理解价值：价值与利益相关者。

每当Scrum框架谈到“价值”时，它指的是Scrum团队与其利益相关者之间的交易。换句话说，只有当交付并得到利益相关者的验证时，某物才有价值——在此之前，任何价值都是纯粹假设的。

利益相关者是对产品有实际利益的人——而不是仅仅转达或代理他们个人没有的需求的人。当Scrum团队交付的工作对利益相关者有价值时，他们将获益；当团队没有交付有价值的工作时，他们将损失。

因此，尽管积极使用你的产品或用他们的资金投资于其发展的人可能是你的利益相关者，但你的市场部门同事可能不是。虽然你的同事可能对你的产品或如何营销它有有用的意见，但他或她可能并不使用它，也没有投资于其发展。

这给了我们一个重要的见解：我们需要从实际利益相关者（而不是代理人）与Scrum团队之间发生的交易的角度来看待价值。这也突显了大型组织中的Scrum团队经常面临的挑战之一。他们的实际利益相关者通常隐藏在组织的后面，有价值的问题经常被完全忽视，因此重点转向尽可能完成更多的工作（而不考虑这些工作有多有价值）。

价值与长期性

通过利益相关者和Scrum团队之间的交易的这种视角也引起了对未来交易的可持续性的关注。毕竟，如果一个Scrum团队把所有工作都免费提供，他们或他们的产品将不会长久存在。

同样，预算可能不允许团队满足利益相关者的任何潜在需求。这显然更多地关系到投资于产品开发的利益相关者（例如投资者或支付Scrum团队工资的组织）而不是主要使用它的人。但最终，这两个群体都会从可持续发展中受益。

这种长期性和可持续性的方面是为什么“商业价值”可能比“价值”更准确，尽管Scrum指南只谈到后者。商业价值的一个常见定义是：“决定公司长期健康和福祉的各种价值形式”。

这种长期性的视角也解释了为什么2020年的Scrum指南正式规定了一个单一的产品目标，以便在大量冲刺的开发中集中注意力。很可能会有比可以或应该解决的更多需求，产品目标为团队提供了一个基准，以便根据什么是有价值的和什么不是（至少目前不是）做出决策。

一个特定的利益相关者需求可能非常有用，但如果它与产品目标不符，那么它就不足以花时间处理，而这些时间本可以用在更有价值的项目上。

现在所有这些考虑仍然是抽象的。当我们开始详细设置产品待办事项并确定每个项目的商业价值时，这将无济于事。你如何确定产品待办事项中的某些项目是“正确的东西”还是“错误的东西”呢？

五种价值类型

考虑到这一点（利益相关者和长期性），我们继续分析了我们与Scrum团队开发的（商业）产品的产品待办事项。我们将这些项目分类为不同类型的价值，并最终得出了五种似乎相当好地描述大多数情况的类型。我们将在下面无特定顺序地讨论这些。

注：由于我们的个人经验主要与商业组织有关，我们的大多数示例也来自这方面。并非所有类型对非商业组织同样相关，尤其是“商业价值”。但即使对于非商业组织，从经济角度看项目仍然是有意义的。

1.商业价值

商业价值是最直接的价值类型，包括产品待办事项中直接为开发产品的组织带来收入的所有项目。在其他所有条件相同的情况下，这项工作将产生净利润。

例如，当一个项目交付后，客户支付以获取它时，这个项目就产生了商业价值。这可能是你产品的新版本、一个新功能或可解锁的附加组件。

也可能是一段新的付费可下载内容、网店中的新产品，或者其他客户直接支付的项目。尽管交付和付款之间可能存在一些层次，但我们喜欢将这些项目看作是发送给客户的发票上的项目。

在这里要问的关键问题是：“（考虑产品目标）这个项目如何增加我们的收入或利润？”回答这个问题越容易，它就越清晰地提供商业价值。如果很难确定，你可能在处理另一种价值（见下文），或者该项目实际上可能根本没有价值，你需要将其移除。

2.效率价值

产品待办事项中并非所有项目都会产生收入。但项目也可以通过直接降低生产、维护和交付成本来直接影响利润。这些项目代表着简化、自动化、减少或平滑产品所需的其他工作的工作；它使其他工作更高效。

从经济角度来看，这些项目通过花费更少的资金为交付给利益相关者的相同价值提高了你的成本效率。或者，如果你不是商业企业，它节省了你多少时间。这就是效率价值。

例如，如果对代码库的更改使您能够用更少的服务器运行相同的产品，那么您就产生了效率价值。但它也可能涉及自动化或简化必要的开发、运营或交付过程中繁琐和重复的任务。

对于我们帮助开发的产品之一，我们在产品待办事项中有减少在客户现场设置产品所需时间的项目。尽管这个项目本身并没有产生收入，但它确实为我们（和客户）节省了金钱。

更间接地，项目也可以减少其他地方的工作，从而降低成本。例如，当一个项目增加了应用程序的稳定性，从而减少了每周帮助台的大量来电。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何为我们节省金钱或时间？”如果情况不明显，你可能在处理其他类型的价值。或者该项目根本没有价值，你需要将其移除。

3.市场价值

一个产品的成功程度取决于知晓它的潜在用户和客户的数量。通常情况下，产品开发涉及大量工作来增加这种认知度，进入新市场，或与竞争产品区分开来。这项工作代表了市场价值。

市场活动是这种工作的一个很好的例子。例如，这可能是为推广你的产品而设置和撰写简单网站的工作。或在LinkedIn上启动一项营销活动。甚至写一篇博客文章、录制一期播客或视频也可以从这个角度被视为“市场价值”——只要它主要关注于为你的产品创造认知。

从软件开发的角度来看，这可能是将应用程序移植到其他平台（例如从iOS到Android，或从Steam到Xbox Live）。或者添加功能以吸引新的客户群。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何让我们吸引更多用户或客户？”如果很难证明这个项目如何吸引新用户，你可能在处理其他类型的价值。

4.客户价值

即使你的产品正在产生收入，具有高效率，并且为用户所熟知，但如果客户不继续使用你的产品，或者一有机会就转向竞争对手，要成功仍然很困难。因此，使你的产品对其客户更有用和有价值的工作是有价值的。这实际上增加了你的产品的“粘性”，正如埃里克·里斯在《精益创业》中所说的那样。这就是客户价值。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何增加客户继续使用我们产品的可能性？”如果你无法清楚回答这个问题，你可能在处理其他类型的价值。

5.未来价值

最后，你的产品必然会有一些工作在完成后并没有产生任何明确的价值，但在（近）未来如果不完成可能会导致巨大问题或显著成本。这就是未来价值。

研究和创新是这一类工作的例子。有时候你需要研究与当前技术堆栈面临的问题的替代技术解决方案。或者你想要改进团队的实践和流程，这需要你花一些时间学习。

减少技术债务似乎也是这一类别的一个例子。技术债务包括在产品之前应用的所有捷径和快速修复——可能在紧要关头——这些可能当时效果很好，但现在却带来了问题。例如，一些重要部分的代码可能缺少自动化测试。或者文档没有更新。或者代码块已经变得像意大利面条一样纠结，开发人员不敢触碰它，担心它可能像代码的竞技塔一样全部崩塌。

未来价值的一个风险是所有时间都花在了可能在未来有价值的事情上，而没有考虑到现在什么是有价值的。虽然将这类工作从产品待办事项中移除可能很诱人，但这些项目可能代表着对未来灾难的防范。即使未来仍然大部分未知，但其中一些防范措施可能是明智的保留——即使它们不会立即产生价值。

对于每个项目，关键问题是：“（考虑产品目标）这个项目如何在未来为我们节省金钱或时间？”如果你无法清晰回答这个问题，你可能在处理其他类型的价值。一个良好的产品待办事项应该只有少数这样的项目，而且不要太多。

合规性呢？

当我们首次分享这个分类时，最常见的问题之一是如何处理现有法规、协议和认证的合规性。有人建议“合规性价值”是否应该成为其自己的类型？

我们当时对这个问题感到困惑，现在仍然如此。我们在这里的担忧是合规性本身并不真正有价值。相反，它是一种手段，希望是有价值的。例如，当客户要求遵守某个协议并为此付费时，这显然是商业价值。

如果客户不为此付费，但他们仍然要求这样做以保持他们的支持，那么这就是客户价值或市场价值。如果合规性涉及安全或加固，那么是为了防止潜在的安全漏洞造成的损害。这就是未来价值的例子。

我们看到太多的例子，即为了合规性而遵循合规性，结果导致了巨大的成本、效率降低，并使发布变得更加困难。虽然在某些发生这种情况的情况下是合理的，但在其他情况下却并非如此。因此，为了避免这种情况，我们鼓励你深入挖掘合规性，确定为什么合规性有价值。

此外，我们认为合规性更适合于“完成定义”。除非你谈论特定的功能或功能，否则大多数合规性通常包括质量指南。这难道不正是“完成定义”所用之处吗？

开始关于价值展开对话

我们在这里提出的分类法当然不是完整的。各种类型在几个方面有重叠，有些项目可能并不明确地属于任何一种类型，但仍然具有价值。

但这并不是重点。重点是你应该与你的团队和利益相关者就产品待办事项中每个项目的价值展开对话。对于那些你可以轻松分类到这些类型中的一个或多个的项目，你可能正在处理有价值的东西。

如果你不能，你的团队，尤其是你的产品负责人，需要有一个异常有说服力的理由，解释为什么它仍然在产品待办事项中。毕竟，产品负责人如何通过保留看似没有价值的项目来最大化Scrum团队完成的工作的价值呢？

我们希望这篇文章激发了你与利益相关者就价值展开对话，并对在产品待办事项中保留什么和丢弃什么做出有意义的决定。

“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由 此我们建立了如下价值观：

  个体和互动 高于 流程和工具
  可用的软件 高于 详尽的文档
  客户合作 高于 合同谈判
  响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

(https://agilemanifesto.org/iso/zhchs/manifesto.html)

个体与互动高于流程与工具

无论你的流程有多么深入和巧妙的设计，你的工具有多么高科技，最终决定成功与否的是你与团队已经团队本身的协作方式。你的团队以及他们有效高效沟通的能力比他们遵循的流程或所使用的工具更有价值。

这并不是说敏捷哲学不鼓励形式化的流程或工具。它们都可以为你的团队提供结 构和促进互动。但归根结底，它们排在次要位置。

毕竟，如果你的团队不能有效沟通，流程和工具就毫无价值。但如果让一个聪明、有动力的团队去完成任务，有时虽然没有任何流程或工具来管理项目，他们很可 能会找到一种合适的方式来达致成果。

可用的软件高于详尽的文档

传统的产品开发流程通常在编写一行代码之前需要大量的文档。在敏捷哲学下，让软件（或者任何产品成果）尽快进入客户手中是最重要的。毕竟，如果你不让产品投放市场并从真实用户那里收集反馈，你怎么能改进你的产品呢？

虽然这个价值观强调了在让文档成为瓶颈之前尽快推出软件（或者任何产品）的重要性，但需要注意的是，文档本身并不是一件坏事……只要你不过度去做，并且能持续去更聪明的使用文档及改进你做文档的方式来带来最优产品成果的交付。你的最终成败在于是否给客户/用户提供价值，而且最好是早一点能做到。

客户合作高于合同谈判

敏捷哲学强调以客户为中心的产品开发实践，而不只是以交付物为中心的方法。虽然合同及法务条款在业务中始终有其存在的位置和必要性，但若只是列出你会向客户提供的东西，其并不能替代与他们实际沟通，了解他们的真正需要和面临 的挑战及要解决的问题本身。

传统的以交付物为中心的流程允许合同决定最终交付什么，这为双方期望的一致性留下了很大的缝隙和潜在偏差。敏捷哲学（以及由此产生的许多形式化流程）鼓励在开发周期中建立一个持续的客户/用户反馈循环。

在敏捷哲学下，与客户的协作在开发过程的早期就开始，并在整个过程中频繁发生。与真实客户/用户密切协作及互动的这种文化帮助产品团队确保他们向客户提供有效、有用的解决方案。当你经常与客户交流并将反馈纳入你的开发过程中时，你减少了风险，消除了猜测，最终一起实现共赢。

响应变化 高于 遵循原计划

复杂事物及工作中，唯一不变的是变化本身，以及各种在行动前无法完全把握及预测的偏差和不如意。敏捷方法的一个重要好处是它鼓励团队根据持续收集和分析的新信息频繁地审查和调整当前的计划。因此，产品或者项目路线图不再是一份静态文档，而是一项动态的战略，而且更有潜在最终成效。

在敏捷环境中，产品经理或者任何负责人（通常也鼓励和团队一起）需要学会以充分透明的方式向利益相关者展示他们的目前的真正进展（当前交付物增量及动态路线图），以反 映基于最新所学习和掌握到的变更可能性。

换句话说，敏捷方法允许产品或者项目团队根据战略需要随时调整其优先事项和计划。这些团队不会因为承诺要完成原计划而陷入已经过时的计划中。

总结

通过遵循敏捷宣言的价值观，我们相信可以更好地应对软件开发的挑战，提供更有价值的产品和解决方案。无论是个体和互动、可用的软件、客户合作还是响应变化，我们都将以这些价值观为指导，不断改进和创新。

尽管敏捷工作方式、持续交付和产品导向已经得到广泛应用，但仍有许多公司仍然采用项目管理的方式进行工作。实际上，项目管理永远不会完全消失。

在很多大型企业中，跨团队的协调工作始终是必要的。项目的进展与RAG（红、黄、绿）状态保持一致，就像繁忙路口的交通随着红绿灯的节奏运行一样。绿灯表示一切顺利。黄灯表示需要关注，也许可以要求团队提供额外的每周状态报告（就像额外的官僚手续能够帮助团队一样）。红灯表示情况不妙，内部审计要求采取行动，管理层派人介入协调危机。

困境

大多数企业组织只在出现问题时才关注IT交付，而数字化领导力则强调持续改进。这种模式反复出现。管理层太忙，无法关注绿灯时的状态问题。团队找到了改进方向，但因为没有专注于交付更多功能而备受指责。团队也发现了系统性挑战的微弱信号，但被忽视，直到错过了里程碑。一旦状态变为红色，才全员动员起来解决危机。

我多次站出来，因为我知道系统性问题不会得到关注。最近，我与一位正在进行敏捷转型的高级项目经理讨论了这个问题。他告诉我，最近他们经历了一些意外事件，危机模式下的协作非常有效。我感叹道：“良好的敏捷领导力应该让这种协作在日常工作中解决混乱的问题，而不需要费太多力气”。

混乱中的领导与敏捷组织的挑战

尽管全世界都喜欢英雄，但敏捷组织并不需要他们！

通常，领导者在混乱中扮演前线指挥官的角色，强调命令与控制的风格。带领团队从混乱中恢复是令人满足的，但这种模式不可持续。组织喜欢英雄，但那些能够保持项目状态为绿色的人往往被认为缺乏战斗经验。这种情况会持续下去，并深入到企业文化中。

业务部门在数字化转型中必须认真对待这种情况，否则会加剧混乱。在混乱的循环中前进是不可持续的，这样的企业面临风险，会经历一个又一个的危机，耗尽人才。

我们如何扭转这种文化？

我们可以很容易批评一些人的行为和对问题的贡献，但责备并没有任何建设性。

那么，我们来思考：应该如何解决？如果真运作一个绿色RAG状态的更高效的IT团队会带来什么回报呢？

开始向改变并拥有以上这种状态，实际上是成功的数字化变革的起点：

1.系统性管理

2.持续改进的文化

3.追求卓越

团队的系统性管理

敏捷思维强调良好协作的必要性，这是非常正确的。数字化组织也努力复制互联网独角兽公司的组织模式，采用更扁平化的结构和自主的团队，以加快决策速度。然而，许多人仍然将团队视为个人的集合，并专注于任务。我们难道看不出其中的矛盾吗？

如果我们从个人层面进行管理，我们就需要微观管理者来组织和协调任务。领导者为自己的价值辩护，坚持站在每个决策的十字路口，并成为前进的瓶颈。团队成员在一朝被蛇咬，十年怕井绳的基础上，放弃了自主性和协作性，倾向于盲从领导者的指示。如果没有系统性管理的方法，团队就无法达到期望的自主和协作水平。

系统性管理始于管理者与团队在工作现场的连接（例如，在团队所在的空间，而不是在管理者的玻璃办公室）。这个概念从丰田生产系统中的“Gemba”开始已经存在了几十年。“Gemba”的意思是去到工作发生的地方。

在制造业中，由于生产流水线的物质性，这一点非常明显，但在数字化团队中就不那么明显了，因为数字化团队中的一切都是虚拟的。在IT团队中使用“Gemba”，强调了在可视化管理的支持下进行信息辐射的需求。过程流程和质量进展可以张贴在墙上（或在线可视化板上），团队可以基于此展开改进的讨论。

管理者还需要具备与整个团队合作的技能和技巧。倾听系统的声音（VoS）可以产生透明性，并能够及早发现系统性挑战。此外，对问题的预期可以促进更好的工作流程。通过采用这些实践，团队变得更加自治，领导者与团队融为一体，从而大大减少了对中间过程微观管理的需求。

持续改进

为了避免自满并推动持续的绩效，丰田生产系统采用了Kaizen，这是一个持续改进的流程。每个人的工作不仅仅是完成自己的任务，还要思考如何改进工作方式，提高工作成果。这种持续努力是一种非常好的刺激大脑的方法，尤其是在生产流水线上的工作可能非常枯燥。

新技术Kaizen的创始人中尾千寻（Chihiro Nakao）坚持推动不需要投资的简单改进。他的目标之一就是激励人们，以防止自满。好的Kaizen还可以在领导层和团队之间创造出一种不同的动态。团队不断发展自主、自立和协作的能力，而管理层变得更注重引导和教练，以及激发创造性思维。我们今天在IT行业中追求的目标，难道不正是40年前丰田公司发明的吗？

许多人很快指出，制造业的生产和IT行业不同。这是事实。然而，在IT的虚拟环境中进行持续改进实际上更容易。与生产流水线上的工人相比，IT人员更自然地扮演知识工作者的角色。真的没有什么可以找的借口。

问题在于，公司的IT部门一直忙于跟踪处于红色RAG状态的问题，而我们忘记了对绿色RAG状态进行持续改进的锻炼。现在是时候重新启动了。让我们重新关注持续改进，为IT行业带来更大的进步。

追求卓越

有组织会反对追求卓越，但很少有组织真正在IT领域做到这一点。DevOps运动在推动这个主题上做出了贡献，但这种努力仍然局限在IT范围内。质量是每个人的责任，从业务需求的启动开始。

在实体商品上，缺乏质量很容易被发现，但在虚拟软件上却很难被发现。你可以从前端的可用性或测试一些边缘情况中得到一些关于质量的想法，但这只是冰山一角。隐藏在表面之下的代码质量是什么？它什么时候会回来咬你一口？RAG状态并不能解决这个问题，事实上，它通常会使问题恶化。

我曾经参与过一个项目，在黄色和红色之间徘徊。业务部门和管理部门不断向团队施压，要求按时完成项目。他们唯一能牺牲的就是质量。有人在意吗？团队在意，但没有人听得进去。

因此，对于任何不符合团队期望的工作标准的东西，我们让团队开始捕获产生浪费的实践，并记录技术债。团队感觉好多了，信息得到了传播，它变得不容易被忽视。然而，我们不应该走到这一步。

IT领导者和产品经理应该高度关注质量。通过项目的方式组织工作并不会促进这种行为。项目本质上是短暂的，交付项目的人很少会成为维护项目的人。质量、可持续性和可维护性在日常决策中很少被高度优先考虑。

关注项目所带来的只关注短期结果的态度，并不支持为公司的数字化打下坚实的IT基础。有效的Kaizen也不太可能发生，除非团队和领导层有长期的承诺。

除了更好地与客户保持一致外，基于产品/服务的一致性还可以维持长期存在的团队和领导力。这促使对人员进行投资，让他们理解工程，并在决策中考虑质量的优先级。然而，这种一致性与传统组织的建立方式在很大程度上是相违背的（这是由规模经济而非流动经济继承而来），这构成了在数字化绩效方面取得进展的重大系统性挑战。

许多公司的IT功能障碍是由基于项目的工作和错误的激励所导致的。这促使了与建立成功的数字化业务基础不相容的行为。为了解决这种情况，需要领导者迈出一小步，领导力才能迈出一大步（借用了这句话…:-)）。

数字化变革始于与团队合作，以理解如何让明天比昨天更好：更智能的流程、更大的自主权、更好的产品/服务、更强的技术能力。这是一个根本性的转变，转变为促进产品和工程性能的IT领导力，其中包括系统性管理、产品/服务和流程的持续改进、卓越的工程能力以及解决阻碍我们的系统性障碍。