---
category: 翻译
tags: agile, tdd, manifesto
title: 「译」开发者是时候放弃敏捷了
---

【改我】敏捷宣言创始人之一 Ron Jeffries 告诫开发者，是时候抛弃你认为的所谓「敏捷」了。

> 原文地址：[https://ronjeffries.com/articles/018-01ff/abandon-1/](https://ronjeffries.com/articles/018-01ff/abandon-1/)
> 
> 原文日期：May 10, 2018

# Developers Should Abandon Agile

### Big Business

“Agile”1 has become big business. Led, no doubt, by the Scrum Alliance’s successful Certified ScrumMaster offering, we now see hundreds, perhaps thousands of so-called “Agile” coaches and trainers, and many competing frameworks and methods. We see “Agile” leadership training, “Agile” project management offerings, and on and on.

“敏捷”俨然已经成为一门有利可图的生意。毫无疑问，敏捷联盟（Scrum Alliance）成功兜售的 CSM 认证（Certificated ScrumMaster）扮演了重要的推手，在此之后，各种所谓的“敏捷”教练和培训员辈出，各种框架登场，各种方法论如雨后春笋一样冒出头来。我们见到“敏捷”领导力培训出来了，“敏捷”项目管理出来了，敏捷的七七八八都出来了。

### Good for the enterprise

### 对企业友好的“敏捷”

Now, many, perhaps most of these offerings are not bad things, at least for the enterprise. Organizations that try to improve usually do improve, and so even if “Agile” ideas are applied poorly, trying will almost always provide some benefits to the organization. The organization should at least get increased visibility into what’s going on, and that will often lead even the least enlightened management to make better decisions. That’s good, and I’m all for it.

这里，我并不是在说这些培训都是坏的、这些框架和方法论都有问题——至少对于企业来说，它们多少有点帮助。有意愿获得改善，并且真正付诸行动的企业，往往都能获得一些改善：即便他们尝试导入的与真正的敏捷可能相去甚远，只要企业真正付诸了行动，几乎总会获得或多或少的改善。它们至少能更好地可视化团队的事务，而有了可视化在手，即使再挫的管理层也往往能因此做出更好的决策。这都是好的方面，我也完全肯定它的积极作用。

### Not so good for developers

### 对开发者不那么友好的“敏捷”

The picture is not so attractive for developers, all the people engaged in actually building the products that the “Agile” enterprises are undertaking. When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.

然而，“只要做了就有改进”的美丽图景，对于那些奉命开发产品的、奋战在一线的开发者们来说，就是另一幅光景了。如果你导入的“敏捷”与真敏捷相去甚远，往往只会增加开发者的制约：他们的工作时间会减少，压力却更大，有更多人要求他们“快速前进”。这对于开发者来讲很糟糕，最终对企业也不利。错误地实施“敏捷”可能带来许多恶果，导致比之前更多的缺陷出现，大大降低团队的开发速率。好的开发者最后也多半会离开这样的组织，使得企业相比没有导入“敏捷”之前，组织效率反而更低了。

### Safe, not SAFe

### 安全感（safe），而不是 SAFe 框架

My thinking is taken from something Kent Beck said over a decade ago. I would like the world to be safe for developers. At my core, I am a developer, despite years of management, consulting, and writing. I worked with code earlier today, and do so every week if not daily. So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better. It also saddens me that the enterprise isn’t getting what it could out of the deal, but my main concern is for the people doing the work.

我之观点，Kent Beck 早在二十多年前就有过敦敦告诫。我希冀开发者的工作环境能够更有安全感。尽管有过管理的经验、咨询的经验，以及写作的经验，我曾经是——如今也仍然还是——一个软件开发者。我今天早上还写了代码哩，如果不能做到每天都写，我也会坚持一周至少写点代码。正因如此，当我察觉我们这群人当年在敏捷宣言里写下的话语只是使开发者的处境变得更困难了而已时，我的心痛无以言表。企业本来可以从敏捷中收获更多，但却没有；这也使我伤心，但一线开发者们的处境更使我感怀。

Over a period of years, I’ve heard from many developers who say that “Agile” sucks. (Usually they say that “Scrum” sucks, because most people in organizations trying to do “Agile” are in organizations trying to do Scrum.) I’ve tried to help those people understand that their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend. My hope was that people within the sound of my voice would help themselves, and their organizations, move closer to the real ideas behind Manifesto Agile and away from the many forms of Faux Agile or Dark Agile that we see around us.

过去的十几年里，我不止一次听到有开发者说，“敏捷”就是个垃圾。（他们其实是想讲“Scrum”是垃圾，因为通常做“敏捷”的公司真正想做的其实都是“Scrum”）我努力想让他们知道，他们的公司把“敏捷”都做错了：他们所做的既不是“敏捷宣言”的作者所推荐的敏捷，也不是 Scrum 所推崇的敏捷，当然也不是“敏捷软件开发联盟”的专家们所推荐的敏捷。我希望这段话能够帮助人们、帮助他们的组织与*宣言敏捷*中的真知灼见为伍，远离周围形形色色的*骗子敏捷*、_暗黑敏捷_。

That’s not really working out. Efforts like “Advanced” Scrum training and certifications, and leadership-focused efforts are good, and may bear fruit over time, but they will proceed at best slowly and may never really filter down to the poor developers in the “Code Mines of Ohio”.

光靠框架、方法论来鼓吹“敏捷”是不行的。花费心思举办“高级”Scrum 培训、签发敏捷证书、搞领导力培训等，是好事，也可能结出硕果，但这是个缓慢的进程，不可能一蹴而就，底层可怜的开发者们也可能永远享受不到敏捷化改革带来的利益。

It’s time to try something new, and here it is:

现在，是时候尝试些新的做法了。以下是我的几个“锦囊妙计”：

## Developers should abandon “Agile”

Mind you, developers will continue to find themselves working under Scrum conditions, or in organizations using SAFe. Some may even encounter more obscure “Agile” approaches like “DAD”, or, if they’re fortunate, more enlightened approaches like “Modern Agile”, or “Heart of Agile”. Some may even be lucky enough to find themselves doing Extreme Programming, also known as “The Scrum That Actually Works”.

不过嘛，短期来看，开发者们仍需继续在一些 Scrum 的环境下工作，也许他们的组织仍在使用 SAFe。不幸一点的开发者可能会遇见更令人费解的“敏捷”流派，比如“DAD”等；如果遇见更开化的“现代敏捷”、“敏捷之心”等流派，那就幸运一点。人品爆发的话，可以遇见一些在做极限编程（XP）的团队。XP正是那种被称作“真正管用的Scrum”。

### Detach from named methods

### 不要拘泥于招式

Be that as it may, I believe that developers should detach their thinking from any particular named “Agile” method. Instead, they should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods. Those development approaches, to me, involve use of practices such as, but not limited to, those of Extreme Programming. More generally, developers’ work should adhere to the foundational principles that support Agile Software Development, as we had in mind when we wrote the Manifesto. Today, I’d summarize the ideas this way:

虽然无法选择工作的环境，但我认为一位真正的开发者应该有独立的思考，而不应盲目遵守任何书本上的“敏捷”方法。相反，开发者应该真正关注和学习的应该是软件开发的正确方式——那些放诸任何“敏捷”方法而皆准的开发方式。对我而言，极限编程的实践是正确开发方式的一部分，但不是唯一的一部分。具体来讲，开发者应该遵循的是那些支撑着敏捷软件开发的基本原则，这些原则是我们起初写下敏捷宣言时的观点。今天，我愿意用以下方式重新总结这些观点：

No matter what framework or method your management thinks they are applying, learn to work this way:

不管公司的管理层认为他们在推行的是何种框架或方法论，请始终遵循以下方式开展工作：

* Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
* Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
* Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.

* 尝试以周为单位产出一个可运行的、经过完整测试和集成的软件。围绕“创建可工作软件”这个目标构建团队能力，不断缩短交付周期到每天一次、每天两次、每天许多次。
* 保证软件可工作的同时，保持其设计整洁。随着软件演进，其设计往往渐趋复杂。你需要抵抗这种趋势，使用细小的步子持续进行重构，如此才能反转软件腐坏的趋势，尽可能保持开发速率的平稳、一致。
* 与产品经理和领导层交流时，使用当前最新的软件作为沟通语言。沟通时，以“什么特性已经准备好上线”及“下一步要做什么”为重心。

This is the development team’s best hope for a reasonable life. By keeping the software always ready to go, we can hit any deadline with the best possible result. “Is today the deadline? Here’s what we’ve got, it’s ready to ship.”

要想体面地工作，以上建议是开发团队最合理的依靠了。只有保证软件随时都是可发布的状态，我们才能以最好的结果面对随时到来的上线。“今天就要上线吗？好的，这就是最新的软件，我们已经准备好交付它了。”

As we lead up to the deadline, and as we negotiate what to do next, the running software in our hands lets us keep the conversation focused on the next, most important thing to do, rather than the near-infinite list of things they think they want. It’s not easy to change the focus from “do all this” to “do this next”, but it’s our best chance for a decent life, and it’s often quite possible to get the focus to change, as we work to collaborate with our leaders rather than just work under them.

一旦我们开始直面死线，开始专注于“接下来要做的事”，手中那个可运行的软件就可以使对话聚焦于下一件真正最重要的事情上，而非跟一份长长的形似臆想出来的需求列表死磕。“做完所有固定的需求”到“接下来先做这一件事”的思维转变并不容易，但这是获得一个体面生活的最后机会；只要我们与领导们更紧密地协作，而非仅仅听从他们的命令干活，完成思维的转变往往指日可待。

## Under an imposed approach

Too commonly, the “Agile” approach a team uses has been imposed. Larger-scale “Agile” methods appear actually to recommend imposition of process. I include here the so-called “SAFe” method, Scaled Scrum, and LeSS among others. These are pitched to the enterprise, and the enterprise is expected to “install” them, or “roll them out”.

不幸的是，团队采用什么“敏捷”实践往往不由团队所控制。许多大型的“敏捷”方法论反而在倡导更重的流程，其中较有代表性的包括（所谓的）“SAFe”、Scaled Scrum、LeSS等方法论。这些方法论是针对企业级场景而生的，而企业不趋之、不用之好像也显得不够专业一样。

As a developer, you can be sure that this roll-out will not go smoothly nor in a truly Agile fashion. You’ll not likely be trained, much less educated, much less given the real help you need to do your job. Your leadership will perhaps have been trained, perhaps for as much as an entire week(!), to prepare them to bring about this sweeping change in the organization’s approach to product and software development. The road is likely to be a bit bumpy.

而作为开发者你很清楚，这样的“敏捷”导入不可能一帆风顺，也很难带来真正敏捷的工作方式。他们多半不会对你进行培训，不会教你必要的知识，更不太可能给到你日常工作中真正需要的一些帮助。但他们倒是很可能对领导层进行培训（也许是持续一整周的培训！），以

But if you can reliably select work to do over the course of a “Sprint” or “boxcar” or whatever your release train conductor starts calling the time period, and accomplish that work, packaging it up in a running, tested, integrated, ready-to-go new version of the system, you’ll be equipped to do the best it’s possible to do.

> Real software is your only hope
>
> * Leia (private communication)

If you can’t quite manage that, I’d advise you to take on less work in each time period, until you’ve taken on a small enough batch that you can actually get it done. This will be difficult! People will push you to “go faster”. Do your best! Under pressure to sign up for more than you can do, I’d suggest that you work on one or two of the items, complete those entirely — fully packaged, tested, and working — and then do another, so that at the end of the boxcar you have something that you can absolutely call completed. Take the inevitable abuse for not completing everything, and try to drive planning and expectations from reality, not the fantasy of what was demanded, that you never had a chance to do.

> Slow down to deliver

It won’t be perfect, and for a while at least, it probably won’t be fun. It’s just the best chance I know to survive down in that code mine. Having a completed running product slice is the best way I know to possibly turn the situation around. In a bad situation, all we can do is our best, and try to help things to get better.

Clearly, in a more enlightened organization, or one with ongoing learning, things will become more and more open to real Manifesto Agile ideas. Life can improve, and I hope it will.

I’ve been in those situations, and other than leaving, the best I know is to do good work, keep it visible, running, tested, and integrated, and help people to see reality.

## Choosing an approach

The Manifesto calls for “self-organizing” teams, and in the best case, that comes down to the team choosing its own process. If I were starting a company, I’d let the teams choose any process they wish.

> I’d ask for results, not a specific process

However, there would be constraints, not on how they choose to work, but what I need to see. I’d make it clear that every two weeks at most, I would like to review their running tested product slice. They’d show me what they had planned to build, and what they built. It would have to actually work, and to contain visible capabilities that I could understand. We’d talk about what they should do over the next interval. And I’d make it clear that one week would be better than two, and that one day would be better than one week.

> I’d provide help

I’d provide them with help. I’d provide someone with a solid connection to the business needs to be met by the product, who would help them decide what slice of work to do next. I’d provide access to training and support doing the work they need to do. I’d make sure they were equipped to do what I was asking them to do.

Of course, I’d do that because I know how to do this stuff. You might be lucky enough to be in a situation somewhat similar to that, at least to the point where you can choose your own process.

> Shhh. Maybe XP!

If you do get a chance to choose, I’d recommend that you start with something like Extreme Programming. It contains all the planning and feedback loops you need, and it includes the basic technical practices you need to do what we’ve been talking about here, and to do what I’d be asking for.

And I’d recommend that you stay alert at all times for signs of all the other things you need. “ATDD, TDD, and Refactoring” are things that, in my opinion, you need until you know something better. But there are tens, hundreds, thousands of other things you need as well. Stay alert for those, and when you identify them, get them.

Excellence in making software is a lifetime activity. Even Extreme Programming, the best officially named approach that I know of, just scratches the surface. Moving toward excellence is up to your team and its members.

## Summing up

Other than perhaps a self-chosen orientation to the ideas of Extreme Programming — as an idea space rather than a method — I really am coming to think that software developers of all stripes should have no adherence to any “Agile” method of any kind. As those methods manifest on the ground, they are far too commonly the enemy of good software development rather than its friend.

However, the values and principles of the Manifesto for Agile Software Development still offer the best way I know to build software, and based on my long and varied experience, I’d follow those values and principles no matter what method the larger organization used.

I offer that opinion as advice. Do with it as you see fit.

---

1: Here and in other writings, I use the quoted word “Agile” to refer to the many instances, approaches, and processes that use the word “agile” to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to “Faux Agile” for emphasis, or to “Dark Agile”, which I use to describe so-called “Agile” approaches that have really gone bad. I might refer to “Manifesto Agile” to mean the core ideas from the Manifesto, in which I still believe.