你认为自己的工作方式很敏捷吗？可能不是。

受到YouTube 上 Allen Holub 和 Dave Farley最近对话的启发，我开始思考那些声称“敏捷”的公司在开发过程中发生的各种事件。甚至连“以敏捷方式工作”的说法都可能受到质疑。

你在这样的公司工作吗？也许你会在这篇文章中找到自己的影子。

我要明确一点，我绝不是什么敏捷专家或教练之类的。我只是一个对敏捷感兴趣、希望探索更好工作方式的开发者，因为我见识过不同公司不同的工作流程。

敏捷

我们中的一些人曾经被一位经理介绍过敏捷，这位经理说：

我们这里实行 Scrum 模式。我们很敏捷。

就是这样。

组织中没有人会要求或告诉你去阅读敏捷宣言（位于此处）。为什么？因为大多数经理或主管根本不了解敏捷的真正含义。他们自己可能甚至都没读过这份宣言。他们宁愿给你一份 Scrum 指南，然后命令你照做。（实际上，在我工作过的组织中，从来没有人建议我阅读这份宣言。）

敏捷的定义非常简单。它听起来就是敏捷开发。你拥抱并适应变化。你与人沟通，而不是依赖项目管理系统。你与客户协作，尽早交付软件，而不是签订合同，规定在固定时间内以固定成本交付哪些内容。

我们大多数人都是通过 Scrum 了解敏捷的。但 Scrum 本身并不敏捷。如果你严格遵循它的指南，就不会。

Scrum 并不敏捷

正如Allen Holub多次提到的，宣言中从未提到必须进行冲刺、改进或规划会议，或者评审。这只是我们被教导的工作方式，因为Scrum在不同组织中的采用率很高。宣言中唯一提到的是定期举行某种类型的反思会议。在Scrum中，回顾会议是在固定时间（冲刺长度）之后的固定日期举行的。

然而，Scrum指南本身却与敏捷宣言截然相反。它实际上相当僵化。以下是指南中的几段引言：

改变 Scrum 的核心设计或理念、忽略某些元素或者不遵循 Scrum 的规则，都会掩盖问题并限制 Scrum 的优势，甚至可能使其变得毫无用处。

本质上，你必须严格遵循 Scrum，否则你就不是在实践 Scrum，甚至会给自己带来隐患。这不太敏捷。

Sprint 计划通过规划 Sprint 中需要执行的工作来启动 Sprint。

制定一个在固定时间段内完成工作的计划，并严格执行。如果计划有变，会怎么样？这听起来很像你在进行迷你瀑布式开发。

在 Sprint 期间：不会做出任何危及 Sprint 目标的改变；

所以，你的团队已经就接下来几周的冲刺目标（交付有价值的成果）达成了一致，并且不能对冲刺做出任何可能危及该目标的变更。你必须在规定的时间内，不惜一切代价完成该目标，即使你应该保持敏捷，并在学习新知识时进行调整。相信我，在这段固定时间内，肯定会有新事物出现。

所以Scrum不是敏捷。它不是一种软件开发方法。它只是一种项目管理。难道不是所有管理者都热爱管理吗？

敏捷，就是借鉴Scrum的理念，创建自己的开发流程，以便能够以敏捷的方式开展工作，并持续推进。你可以称之为借鉴Scrum理念的流程，但它并非Scrum。

“应对变化胜过遵循计划”

我们应该持续改进，以便更快地交付价值。然而，仍然有太多事情阻碍了你的进度。这些事情大多是公司设置的限制，因为那里的人不懂敏捷。他们想要固定的日期，他们想知道预算、成本……这就是他们的运作方式。不幸的是，这并不是敏捷。他们不是以敏捷的方式思考，而是以工业化的方式思考。

Scrum 本质上是一个小型瀑布式交付流程。它为固定的时间框架制定计划。我甚至不想谈论瀑布式交付流程更复杂的 SAFe。然而，使用 Scrum 或 SAFe，您的公司可以确定开发人员将在特定时间框架（2-4 周）内完成某些项目，即使时间框架较短，他们也能了解估算、交付日期并计算成本。

这也涉及到问责制。虽然我见过的大多数公司不会因为未能实现冲刺目标（或产品增量目标）而直接责怪员工，但我经常听到有人批评一个团队设定的目标超出了他们的能力范围。这其实是互相指责，只是规模小了点。在他们看来，如果某件事没有完成，就必须有人承担责任。

事情从来不会按计划进行。有些事情我们无法完成，因为我们学习了新知识，却无法调整。我们遇到了障碍。某个依赖项拖慢了我们的进度，导致我们错过了最后期限。我们偶然发现了一个 bug，必须修复才能交付。为了支持我们的工作，我们不得不重构一些实施不佳的结构，而且在计划会议之前，我们根本没有时间查看代码。

规划会议的目的是估计您在固定时间范围内可以完成的固定工作量。

无论我多少次尝试为规划会议做好准备，涵盖所有情况，但总会出现一些问题。我从来没有在规划会议上考虑过所有可能的情况。我自己也曾经违背过当年宣言的价值。

路障和减速带

开发流程可能并非唯一拖慢你进度的因素。在正常的公司环境中，我们通常会遇到各种不同的障碍。它们可能会阻碍我们的开发，或者只是减慢开发速度。

这些年来，我遇到过各种各样的事件和组织挑战，这些都拖慢了我的工作进度。其中一些你可能也遇到过。

• 在处理该项目之前，您必须考虑与其他团队的依赖关系，并且可能在开始工作之前需要他们的意见。
• 你必须“仅仅因为”就参加回顾展和其他仪式，尽管多年来没有人为其做出贡献。
• 你花了好几天的时间做未来三个月的PI规划，因为某个天才突然冒出个绝妙的点子，想用SAFe“为企业带来规模化的敏捷性”。但到了下周，当你开始着手下一个冲刺的项目时，却把这个计划忘得一干二净。
• 您在开发过程中发现了依赖性，这可能会导致您停止工作，因为您必须去询问另一个团队的意见。
• 您拥有独立的 IT 部门，为您提供所需的资源。例如访问权限、凭证、云资源……
• 您有一个单独的 OPS 团队，他们有自己要处理的积压项目，您必须要求他们为您分配所需的资源，无论是他们团队的成员还是他们日程安排中的时间。
• 您有一位架构师/高级开发人员，他必须告诉您如何开展工作，因为他们会告诉您要做什么以及如何做，以便正确完成工作。
• 使用功能分支，你的工作会被放到开发/质量保证环境中进行测试，然后再“过一段时间”投入生产。这些测试会针对每个工作项手动运行。
• 在你的工作合并到开发分支之前，它必须经过另一个开发人员的审查，可能来自另一个团队，而该开发人员对你所解决的问题一无所知
• 您的经理会提交您下一个冲刺的工作量，因为他是与客户交谈的人，并且知道如何确定工作的优先级。
• 在那里工作时，你实际上从未见过任何客户或用户，而当你想与这些实体进行对话时，你的经理/产品负责人充当了中间人的角色。这会导致延迟，因为信息需要不断传递。这还可能导致你浪费整个冲刺的时间去做一些错误的事情，最终在2-4周后的评审中被发现，因为在传达客户/用户的意愿时出现了错误。
• 您必须使用 Jira，这样您的公司就可以将所有内容集中在一个地方，并且可以监控您的工作并将讨论转移到工具上，而不是人们彼此交谈。

这些只是我在开发过程中遇到的一些拖慢进度的问题。该如何解决呢？

让您的团队创建自己的开发流程

上面提到的大多数障碍都可以通过一件事来解决：团队自主。

团队应该自主创建自己的开发流程，而不是公司，更不是某些高级开发人员，因为某个团队的流程在其他地方行得通，就想把这个流程强加给所有团队。团队自己应该找到最佳的工作方式。

正如敏捷宣言中所说：

围绕有上进心的个人构建项目。为他们提供环境，支持他们的需求，并相信他们能够完成工作。

团队应该在这方面拥有自主权。自主探索最佳工作方式。自主构建自己喜欢的解决方案。他们还应该相互交流，不断改进工作方式。

您应该组建一支拥有所需专业知识的跨职能团队。这通常意味着每个人都应该了解什么是软件或基础架构。他们应该知道如何将安全性融入到开发流程中。他们应该直接与利益相关者沟通，并尽早交付有价值的软件。他们应该能够将所需的资源部署到他们选择的环境中，而无需请求他人的许可或访问权限。

然而，大多数公司都固执地认为，员工不可能在无人监督和监控的情况下完成工作。当然，确实存在这样的人，但团队本身应该有一套坚守的标准，确保这种情况不会发生。

我推荐你读一读帕特里克·兰奇奥尼的《团队的五大障碍》，这是一本团队建设策略书。其中之一就是低标准和逃避责任。

团队应该严格控制质量和工作水平，确保每位成员都能完成团队设定的目标。在制定标准之前，你需要建立信任的基础，并确保每个人都全身心投入。

抛弃 Scrum

大胆一点！创建你自己的开发流程。以下是我脑海中浮现的一些想法：

• 停止使用具有固定工作量的固定冲刺，而是选择更连续的看板风格流程，其中您将获得一个不断优先考虑的工作项列表。
• 作为一个团队，一起处理最重要的项目，直到项目清单完成为止。
• 也许每天早上和团队一起花5-10分钟查看待办事项列表，思考一下优先级，但先这样吧。如果出现新情况导致你调整优先级，你可以轻松地调整。
• 永远不要积压超过三个月的故事。超过三个月的故事都是过时的知识。
• 当某些项目看起来太大而需要削减时，就设置改进会议。
• 不要在每个冲刺后都进行回顾。设置一条安灯线。这是一种机制，团队成员可以在感觉到需要立即解决的问题时互相提醒。不要在这个问题上纠结两周。这样你就可以立即学习并调整方向。
• 在每日站立会议上分享你的成功经验。别像机器人一样，列出你昨天做了什么、今天在做什么以及遇到了什么阻碍。
• 每天都要进步，而不是只在冲刺结束时才进步。

玩得开心就好！没人想以痛苦的方式工作。