局限性_Scrum框架的局限性

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Scrum框架的局限性相关的知识，希望对你有一定的参考价值。

在很多工作坊的讨论中，我经常被问及，“何处不应该运用Scrum？”，简短些的回答是有很多场景并不适用于Scrum。无论如何，为了给出一个更加全面和有效的针对这个问题的回答，首先我们需要知道为什么以及何时Scrum比较有效，还有其取得成功的必要条件。之后，我们可以列举一些不太适用的例子。

Scrum适用于何处？

Scrum是建立自主、自组织、高绩效的团队和组织的工具，能够成功地应对不断变化的业务环境。人们经常因为想要更高的质量或更快的速度而选择使用Scrum，但他们不知道这些是高绩效团队的成果，而不是Scrum自身的成果。

Scrum已被有效地应用于各种行业的团队，包括软件开发，硬件开发，制造，营销，HR ......甚至战斗机和天然气工厂设计！这些非常不同的行业的共同之处在于它们依赖于知识性工作的形式，这可以被理解为需要创造性思维来解决非常规问题的工作。知识工作受益于协作，这是Scrum团队的主要关注点，因此Scrum非常适合这些行业也就不足为奇了。

由于团队是Scrum的核心工作单元，Scrum的许多的限制都源自于组织中的团队是如何组织的这个关注点。

Scrum成功的关键条件

了解目前Scrum在何处是有效的，我们可以考虑它在给定的工作环境中运行良好所需要的基本要素。

知识性工作 - 看起来很明显，但值得一提的是：基于日常任务执行的组织（包括大多数零售和服务行业），不需要解决复杂的问题或创造性思维的组织并不会从使用Scrum框架中受益。

共同目标 - 一群人只有在他们试图实现共同目标时才成为“团队”。在软件开发中，共同目标来自产品愿景和战略。在营销团队中，这可能以品牌战略或营销活动计划的形式出现。无论是哪个行业，目标都必须将所有团队成员的工作统一到比他们个人贡献更大的事情上。没有一个共同的目标，就没有一个真正有凝聚力的团队，凝聚力是关键。

足够的挑战 - 与共同目标相关联的问题必须具有足够的挑战性，且人们单打独斗是无法完成该工作。如果人们可以在不与他人互动的情况下工作并仍能实现目标，他们通常会选择这样做。问题的难度必须保证只有团队才能解决，否则Scrum只是不必要的开销。

全职的团队成员 - 多任务的成本损耗在很多场合被记录在案，它不再被认为是理想的技能(曾经被认为是)。将人员分配到多个团队工作会迫使他们执行多任务，从而降低他们的工作效率。任何形式的多任务都会导致人们损失能力，将它们分配给多个团队注定是最糟糕的情况。由于他们在从一个环境切换到另一个环境时需要注意力的转移，他们的能力会降低，并且团队在等待人员轮转中也会存在瓶颈。最终，错误的数量将增加，部分原因是这些人在工作衔接上会忘记关键细节。有证据表明，将人员指派给唯一团队，可以使所有团队的生产率翻倍。如果没有专职的团队成员，所有团队都注定是低生产力团队。真正的团队（高绩效团队）永远不会形成。 Scrum会在这种环境中受到严重束缚。

稳定的团队成员 - 高效的团队需要时间来塑造，新团队需要6-8个月才能发展出真正有效的凝聚力。此外，每次团队成员发生变化时，团队的生产力都会暂时下降。几个月后其可能会恢复，甚至可能最终有所改善，但有些团队永远无法恢复。在团队成员频繁更换的情况下，团队将始终处于较低的绩效水平。

低成本的变更 - 敏捷会随着软件变更成本的急剧下降而愈加成熟。此后的大部分工作都集中在进一步降低变更成本 - 从持续集成和测试驱动开发到DevOps和行为驱动开发。现代软件开发工作的变化成本不是零，但它远低于绿屏和大型机。对于任何在新环境中取得成功的敏捷方式，降低变更成本都需要优先考虑。如果在进行更改时会产生巨大的成本，敏捷、Scrum就不会那么实用。

可计划性 -  Scrum团队通常在两周的Sprint中工作，因此他们需要能够至少提前计划这段时间的工作，并允许适应新的小变化。例如，软件开发团队为自己提供了足够的灵活性，可以在sprint中修复生产环境突发问题，而不会破坏Sprint的主要工作。营销团队可以根据收到的有关客户行为的新数据调整其广告方案。实践证明至少有一半的团队工作需要进行规划。所有业务模式都在应对不可预测的客户需求的公司将无法使用Scrum来组织其未来的工作。警告：在维护行业之外，很少有企业能够在完全被动的基础上长期生存。

赋权 - 只有在团队成员认为自己拥有自主权时才能形成团队，Scrum通过让团队自组织来明确这一点。希望这不是团队缺少的一个关键条件，但如果是这样（即团队缺少赋权Empowered），即使尝试应用Scrum也将无助于团队的自我组织和高效，并且问题可能会暴露出来，因此需要在继续推进之前解决。

技术共享是可能的 -  Scrum（和看板团队）通过技术共享消除瓶颈，直到问题最终能够被多个团队成员解决。瓶颈是高绩效的根本障碍，组织最终必须解决这些障碍。丰田的方法是向人们支付更多，使其能够处理多个领域的问题。在医疗保健方面，有些司法管辖区域内的、以前只允许由医生完成的一些工作，现在可以由护士或执业护士来解决这个问题。同时，在某些工作环境中，由于法规，法律或完全不同的技能领域（例如艺术家和金属工人），交叉技能可能在其适用性或价值方面受到限制，同时也限制了Scrum的价值。 

尽早交付和测试 - 在Scrum中，我们不认为我们对用户需求的期望是正确的。相反，我们更愿意尽早交付产品并收集反馈。我们以产品发现而非创造的模式运营。我们不能在每个Sprint结束时交付工作产品的环境中，就无法收集反馈。解决方案是在每个Sprint结束时找到要展示的内容并获得反馈。

坐一起 - 让所有团队成员都在同一个场地办公仍然是最佳选择。人类已经进行了数百万年的面对面互动，因此这仍然是建立团队协作的最佳方式。虽然远程工作和分布式团队目前在许多企业中都很流行，但这也带来了很多重大挑战，并且会导致团队中的高绩效需要更长的时间才能实现。如果分布式团队完全无法避免，那么应用Scrum实践（例如每日站会）将更具挑战性并需要进行调整。在分布式团队中有效地实践Scrum仍然是可能的 - 只是这要困难得多。

非理想的Scrum场景

所以现在我们理解Scrum的工作原理及其成功的条件，如下这些都是Scrum最不可能提供帮助的或极具挑战性的团队，但Scrum仍然可以贡献一些好处。

建筑 - 铺设道路时，变更的成本实际上是工作成本。一般而言，敏捷方法仍然可用，但它会增加成本。可以考虑精益建筑以及帝国大厦和伦敦碎片这种方法的例子。

后台业务 - 许多组织都有执行所有后台工作的小组，例如财务和其他相关部门。大部分工作 - 发票，费用跟踪和其他簿记 - 都是由工作人员自己有效完成的。虽然这项工作是以知识为基础的，但它往往是重复性的，所以不具备挑战性。这些群体往往缺乏连贯的愿景或共同目标。再次考虑看板而不是Scrum作为更好地理解这些组内部工作流程的工具。

基础架构和技术 - 大多数组织还有配置笔记本电脑，服务器，安全，网络，防火墙和其他技术基础架构的人员。这种知识工作比后台工作更少重复，更具挑战性，并且它可以从协作中受益，因为问题通常需要多个技能组才能解决。这些群体通常也有共同目标（例如，保持内部用户的生产率和安全性）。但在许多情况下，他们的计划外工作超出了他们的可计划工作。但是，Scrum可能有助于将团队计划外工作集中在一起，帮助他们有效减少它。

COTS应用程序 - 组织经常将大量后端软件（例如：Gmail，QuickBooks，Expensify）外包给云供应商。这很棒，但最终每个应用程序都需要偶尔进行更改（新用户，新会计规则等）。这些应用程序并不需要全职人员维护，因此最终可能会有6-7人维护10-15个独立的应用程序。由于缺乏明确的共同目标，该小组不太可能成为一个团队。 Scrum可以工作，但价值可能有限。基础设施团队和应用程序支持团队面临的挑战是他们的知识可能会很零散，因为人们没有理由去学习另一个团队成员的领域技能。无论团队选择Scrum，看板还是其他框架，都仍然可能存在问题。考虑是否可以重新组织该团队以创造可以实现共同目标的空间，另一种选择是团队可以努力创造一个在他们的环境中可能实现的目标。这些笔记的灵感来自与Petri Heiramo的对话：

“鉴于他们所处理的“产品”显然不足以使他们团结起来，讨论需要转移到比他们正在做的工作更大的事情上。他们想成为有史以来最好的支持团队吗？他们想只用一半的时间完成他们需要的事吗？他们是否想要尝试尽可能多地自动化他们的工作？他们是否知道自己的生活会变得更好并且可能从中获得一些有价值的目标？

一种可能性是问他们工作是否开心。如果他们不开心，接下来的问题可能是他们是否愿意努力让自己变得开心。毕竟，他们的三个主要选择是：1）继续做他们正在做的事情但不快乐，2）做一些可以让自己更快乐和自豪的工作，或3）离开公司做其他事情。显然，3是不可取的也不是一个很好的起点，因此选择应该在1到2之间。然后下一步可能是问他们是什么让他们在工作中感到高兴和自豪，或是什么让他们感到不快和羞愧。这可以帮助他们建立一个变得更快乐的共同目标，并找到纠正措施的起点。可以讨论如何衡量幸福感和自豪感（即如何知道他们正朝着目标迈进）。只要他们在工作中取得了一些他们引以为荣的具体改进，就可以达成一些自我奖励的协议（比如周五的啤酒），例如：

消除那些妨碍他们从工作中脱离开去度假的最深层的信息瓶颈。

解决他们最严重的技术问题。

让一个脾气暴躁的客户对他们的团队、服务感到高兴甚至兴奋。

建立一些新的实践来提高生产力或缩短反馈周期。”

个人工作 - 任何没有合作前景的业务问题（每个人都孤立地工作）都不会直接受益于Scrum。毕竟，没有团队可以提升。在这种情况下，请考虑个人敏捷和个人看板。

团队成员隶属于多个团队并且没有稳定的团队从属 - 我不认为这是一个可取的商业环境。如果是这种情况，Scrum将非常有效地凸显组织障碍，但不能帮助解决问题。在每个研讨会上，我们都会讨论Scrum是一个发现问题工具的事实。从长远来看，当组织采取实际行动解决Scrum发现的问题而不仅仅是管理它们时，Scrum才会成功。

我们可以使用Scrum的范围是有限的，但它们比大多数人想象的要广泛得多。

感谢Petri Heiramo为COTS团队提出的建议和展望。

---

Certified ScrumMaster 

(CSM中文认证课) 

- 北京（还剩6位早鸟票）

时间: 2019.3.8-2019.3.9

https://yihuode.io/activities/747

Certified ScrumMaster 

(CSM中文认证课) 

- 上海（还剩6位早鸟票）

时间: 2019.4.19-2019.4.20

https://yihuode.io/activities/729

---

敏捷变革中心 CAT

- Center for Agile Transformation

• 是中国第一家专注于组织敏捷转型及敏捷领导力发展的咨询公司。
  




• 我们由中国第一批受过美国敏捷联盟专业认证的敏捷教练所组成。
  




• 我们具备丰富的敏捷实践经验，也都热爱分享和服务我们的客户。

联系我们

info@centerforagiletransformation.com