Scrum 适用于哪些团队和项目？要想成功实施 Scrum 必须具备哪些条件？有哪些 Scrum 转型的反面案例？为什么需要用到 Scrum 管理软件？本文将围绕以上问题进行阐述，一起来看看吧。
我经常在研讨会上被问到：“Scrum在哪里不适用呢？”简短的回答是，在很多情况下Scrum框架都不适合。但是，为了更加全面和有效的回答这个问题，首先，我们需要知道Scrum为什么和什么时候有效以及成功的关键条件是什么。然后，我们可以展示Scrum不适用的一些例子。
一、Scrum 适用于哪些团队和项目？
Scrum是一种工具，用于建立能够成功应对不断变化的业务环境的自治，自组织，高绩效团队和组织。人们通常选择使用Scrum的原因，是因为他们想要更高的质量或更快的速度，而不明白这其实是高绩效团队的成果，而不是Scrum本身。
Scrum 已在各行各业的团队中得到有效利用，包括软件开发（其成长起来的行业），硬件开发，制造[1]，市场营销[2]，人力资源…甚至战斗机[3]和天然气厂设计[4]！这些截然不同的行业的共同点是它们依赖一种知识工作形式，这可以被理解为主要涉及的非常规问题解决的工作，而这些问题通常需要创造性思维。知识工作得益于协作，这是Scrum团队的主要重点，因此Scrum非常适合这些行业也就不足为奇了。
由于团队是Scrum的核心工作单位，因此Scrum的许多局限性源自去关注一个组织是如何构建团队的。
二、Scrum良好运行的关键条件
现在了解Scrum在哪里有效，我们可以考虑在给定的工作环境中Scrum正常运行需要哪些结构基础。
知识工作–看起来似乎显而易见，但值得说明的是：组织（包括大多数零售和服务行业）基于日常任务的执行而无需执行复杂的问题解决或创造性思维，就不会从应用Scrum框架中受益。
共同目标——一群人只有在有共同目标时才成为一个“团队”。在软件开发中，共同的目标来自产品愿景和策略。在营销团队中，这可能以品牌策略或营销活动计划的形式出现。无论从事哪个行业，这个目标必须使所有团队成员的工作团结在一起，比他们各自的做出的贡献更重要。没有一个共同的目标，就没有真正的凝聚力团队，凝聚力是关键。
足够的挑战——与“共同目标”并驾齐驱的是问题必须具有足够的挑战性，以至于人们独自一人无法完成工作。如果人们可以在不与他人互动的情况下工作并且仍然实现自己的目标，那么他们通常会选择这样做。问题的难度必须保证使用团队，否则Scrum只是不必要的开销而已。
专注的团队成员关系——在许多场合下多任务处理的成本已显而易见，并且不再像从前那样被视为一种理想的技能[5]。指派人员到一个以上的团队中工作会迫使他们执行多项任务，从而降低他们的生产力。任何形式的多任务处理都会使人们降低生产力。将他们分配给多个团队是最糟糕的事情。由于他们从一种工作环境切换到另一种环境时的延误和重新集中精力的消耗而降低了他们的生产力，并且团队在等待该人员投入工作前将遇到瓶颈。最终，犯错误的数量将增加，部分原因是这些人切换环境时候会忘记关键细节。
有证据表明，人员专注在一个团队（只有一个团队）会使所有相关团队的吞吐量提高一倍[6]。没有专注的团队成员关系，所有群体注定会降低生产力，而真正的团队（还不算指高绩效团队）就永远不会成立。在这种环境下，Scrum将受到极大的束缚。
稳定的团队成员关系——高效的团队是需要时间积累的。新团队需要6到8个月的时间才能形成真正有效的凝聚力。此外，每次成员变更时，团队的生产力都会暂时下降。几个月后，他们可能会恢复实力，甚至可能最终有所提高，但是有些团队永远都无法恢复。在团队成员频繁更换的情况下，团队将始终处于较低的绩效水平。
较低的变更成本——敏捷时代已经来临，因为软件变更的成本已大大降低。多年来许多工作都集中在进一步降低进行变更的成本上——从持续集成和测试驱动开发，再到DevOps和行为驱动开发。现代软件开发工作中的变更成本不是零，但比绿屏机[7]和大型机要低得多。为了使任何情况下的敏捷都能在新环境中取得成功，降低变更成本（甚至是在项目后期）必须成为重中之重。如果进行变更时在工作中会产生大量成本，那么敏捷/Scrum就不太适用了。
可计划的——Scrum团队通常以两周的Sprint进行工作，因此他们需要至少能够提前计划那么长时间的工作并允许进行小的更改。例如，一个软件开发团队拥有足够的灵活性，可以在Sprint中期解决一个生产支持问题，而不会影响Sprint的主要工作。营销团队可以根据收到的有关客户行为的新数据来调整其营销活动。实际的限制是至少有一半的团队工作是可计划的。整个商业模式都是为了响应不可预测的客户需求的公司，如果使用Scrum来组织未来的工作，是无法从中受益的。注意：在维修行业之外，很少有企业能够在纯粹的基于响应的业务上长期生存。
被赋能的——只有在团队成员觉得他们有自治权时他们才能形成真正的团队。Scrum通过建立自组织的团队来明确了这一点。希望自治权不会成为团队缺少的关键条件，但是，如果确实如此，尝试采用Scrum并不会帮助团队变得自组织和高效，但可能会暴露出一些问题，因此可以先解决此类问题，然后再继续进行。
跨技能是可能的——Scrum（和看板团队）通过共享技能消除瓶颈，直到一个延迟总是可以由多个团队成员解决。瓶颈是实现高绩效团队的重要的、根本性的障碍，组织必须最终解决它们。丰田的方法是向人们支付更多报酬，以便能够处理多种工作。在医疗保健领域，有些司法管辖区开始通过允许以前仅由医生完成的某些工作，现在也允许由护士或执业护士来解决。同时，在某些工作环境中，由于法规，法律或根本不同的技能领域（例如，艺术家和金属工人），跨技能的适用性或价值可能受到限制，Scrum的价值也受到限制。
尽早交付和测试——在Scrum中，我们不假设我们对用户需求的理解是正确的。相反，我们希望尽早交付产品并收集反馈。我们以产品探索而非产品创造的模式工作。如果我们不能在每个Sprint结束时交付可工作的增量，我们就无法收集反馈。解决方案是在每个Sprint结束时，找到要展示的内容并获得反馈。
同地办公——让所有团队成员在同一房间里工作仍然是优异选择。人类已经经历了数百万年的面对面互动，因此这仍然是组建协作团队的优异实践。尽管远程工作和分布式团队目前在许多企业中很流行，但这些所带来的挑战却是巨大的，并导致高效能团队需要更长的成长时间。如果绝对不可避免地要采用分布式团队，那么应用Scrum实践（例如每日站立）将更具挑战性，并且需要适应。在分布式团队中仍然可以有效地实践Scrum——只是难度要大得多。
三、Scrum 实施的反面案例
因此，既然我们了解了Scrum的工作原理以及成功的条件，以下是从Scrum最不可能提供帮助的团队，到虽有挑战性但仍然可以受益的团队的排序：
建筑施工——当一个团队负责浇筑混凝土或铺路时，变更的成本实际上就是工程成本。总体而言，敏捷方法仍然可以使用，但是会增加成本。这种情况可以考虑精益建设、帝国大厦[8]和伦敦碎片[9]这类方法。
服务台和维修服务——组织中的人员提供数字或基于电话的支持服务时，他们的工作确实涉及“知识型工作”的关键条件，但这完全是由中断驱动的。他们可以开始处理一个问题，但是当打来的电话涉及到更重要的问题时，他们必须进行切换。这种模式在一天中可能会重复多次。这不符合“可计划的”条件，因此Scrum在这种情况下将无效。考虑使用其他工具（例如看板）来改善通过任何系统的流程。看板可能也适用于其他组织和服务——基本上在知识是主要要求但工作不可计划的任何地方。
后台运营——许多组织都有从事所有后台工作的小组，例如财务和其他相关部门。其中大部分工作（发票，费用跟踪和其他簿记工作）都是由个人有效完成的。尽管这项工作是基于知识的，但它通常是重复性的，因此不具有挑战性。这些小组通常缺乏清晰的愿景或共同目标。我们仍然考虑使用看板而不是Scrum作为更好地了解这些小组内部工作流程的工具。
基础设施和技术——大多数组织还拥有配置笔记本电脑，服务器，安全性，网络，防火墙和其他技术基础设施的人员。与后勤工作相比，这项知识型工作重复性更少，而且更具挑战性，并且它可以从协作中受益，因为问题通常需要多个技能来解决。这些小组通常也有一个共同目标（例如，保持内部用户的生产力和安全性）。但是在许多情况下，他们的计划外工作超出了计划内工作。但是，Scrum可以通过关注团队计划外工作的数量，从而帮助他们减少这些工作量。
现成的商业应用（COTS，Commercial Off The Shelf）[10]——组织经常将许多后端软件（例如Gmail，QuickBooks，Expensify）外包给云供应商。这很好，不过最终，会有足够多的应用程序需要偶尔更改（新用户，新记帐规则等）。这些应用程序都不需要一个全职个人来维护，因此最终可能需要6-7个人来维护10-15个单独的应用程序。因为他们缺乏明确的共同目标，该小组不太可能成为一个团队。Scrum可以工作，但价值可能有限。对于基础设施和团队而言，挑战在于他们的知识可能会分散，因为人们没有理由学习另一位团队成员所在的领域。无论团队选择Scrum，看板还是其他框架，这将仍然是一个问题。考虑问问该小组是否可以重组以创建一个可能实现共同目标的空间。另一种选择是，团队可以根据自己的情况来制定目标。
这些灵感来自与Petri Heiramo的对话：
鉴于他们工作的“产品”显然不足以团结他们，因此讨论需要转移到比他们正在做的工作更伟大的事情上。他们想成为有史以来较好的支持团队吗？他们愿意有一半的时间做自己想做的事情吗？他们是否想通过尽可能地自动化来减少他们所做的工作？他们是否知道自己正在改善别人的生活，他们是否可以为此目的制定一些有价值的目标？
一种可能是问他们工作的快乐程度。如果他们不快乐，那么下一个问题可能是他们是否愿意努力使自己快乐。毕竟，他们的三个主要选择是：
1）继续做自己在做的事情，并仍然不快乐；
2）做一些使自己更快乐，为自己的工作感到自豪的事情，或
3）离开公司去做其他事情。显然，3是不理想的，也不是一个很好的起点，因此选择实际上应该在1到2之间。
然后下一步是问他们是什么使他们对工作感到高兴和自豪，是什么使他们对工作感到不快乐和羞愧。这可以帮助他们建立共同的目标，使他们变得更快乐，并找到纠正措施的起点。可能会讨论如何衡量幸福和自豪感（即如何知道他们正在朝着自己的目标迈进）。
只要他们在工作上取得了一些引以为傲的具体进展，他们可能会达成一些自我奖励的约定（例如星期五的啤酒），进展可以是：
– 消除那些使们休假时还带着工作压力的最深层次的信息瓶颈。
– 清除他们最严重的技术问题。
– 使脾气暴躁的客户对其团队/服务感到满意甚至高兴。
– 建立一些新的实践来提高生产效率或减少反馈周期。
个人的工作——任何没有合作前景的业务问题（每个人或公司都孤立工作），也不会直接从Scrum中受益。毕竟，没有团队可以成长。在这种情况下，请考虑“个人敏捷”和“个人看板”。
团队成员分成多个团队，没有稳定的成员关系——我无法想象在商业环境中这是可取的。如果是这种情况，Scrum能非常有效地突出组织障碍，但不能帮助解决问题。在每个研讨会中，我们都讨论Scrum是发现问题的工具这一事实。从长远来看，当组织认真对待去解决Scrum发现的此类问题（而不仅仅是管理它们）时，Scrum就能成功。
对Scrum的使用会有很多限制，但它比大多数人想象的要广泛得多。
四、关于 Scrum 落地的辅助工具
根据敏捷调研报告，调研人员曾这样总结敏捷软件的价值：用正确的工具使敏捷更容易实施。
国内非常专业的 Scrum 管理软件 PingCode
根据36氪企服点评发布的榜单，PingCode 是2021年国内研发项目管理榜单名列前茅的研发项目管理系统，具有国内标准的 Scrum、Kanban 等敏捷项目管理功能。
这是一款覆盖研发全生命周期的敏捷项目管理平台，被广泛用于需求收集、需求管理、需求优先级、产品路线图、项目管理（含敏捷/kanban/瀑布）、测试管理、缺陷追踪、文档管理、效能度量等领域。
并且集成了github、gitlab、jinkens、企微、飞书等主流工具，也就是说我们能在需求下面关联代码，关联集成信息，在飞书查看通知等。
有非常多团队使用 PingCode 进行研发过程管理、产品管理。它可能是国内近几年较受欢迎的研发项目管理工具。
PingCode 支持私有部署、定制开发、SAAS等版本；价格仅是Jira的30%-40%。
【PingCode 功能体验通道】
其他不错的Scrum 管理软件，比如jira、clickup等等，大家也可尝试。
内容整理自：小船哥说敏捷 ；作者：Zeeshan Amjad
如有侵权请联系删除
参考资料：
- Webinar – “Joe Justice on Agile Manufacturing”
- Hacking Marketing by Scott Brinker
- “Owning the Sky with Scrum” – Saab Designs Fighter Planes with Scrum
- “Designing gas plants with Scrum” by Simon Orell
- Multi-tasking and Interruptions resource links and “Multitasking Gets You There Later” by Roger Brown
- “The Impact of Agile Quantified” by Larry Maccherone
- Not familiar with green screens? See: https://www.quora.com/What-is-a-green-screen-application and https://en.wikipedia.org/wiki/IBM_3270
- “The Tyranny of ‘The Plan’” Presentation by Mary Poppendieck on the construction of Empire State Building
- “The Shard: Foot of the mountain” by Stephen Kennett
- https://en.wikipedia.org/wiki/Commercial_off-the-shelf
