翻译《Developers Should Abandon Agile》 #199
Comments
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. 由 SA 联盟领导的已经成功的 CSM offer，我们现在可以看到 多亏了 SA 联盟成功领导的 CSM offer，。。。 “敏捷”俨然已经成为 big business。有了 Scrum联盟® 在推动（毫无疑问）成功发起的 CSM 认证 offering，我们现在有了成百上千个的所谓“敏捷”教练和训练员，有了此起彼伏、此伏彼起的各种框架和方法论。我们有“敏捷”的领导力培训，有“敏捷”项目管理服务，如此种种。
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. 其实，这些服务很多（或许是几乎所有的服务）都不算太坏，至少对大企业来说并不坏。愿意做出尝试的企业往往都能得到确实的改善。即便 "Agile" ideas are applied poorly，勇于尝试本身多多少少都会为企业带来好处。至少企业对当前活动的可视化程度提高了，而可视化几乎总是能帮助哪怕最乏新意的管理层做出更好一些的决策。
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”. 然而，对于开发者而言，对于所有为这些“敏捷”企业工作、实际参与产品开发的人而言，这宏伟愿景则不一定是那么回事了。When “敏捷” ideas 真的被 applied poorly，一般只会导致开发者受到更多的干扰，工作时间减少，压力变大，以及被要求「更快地开发」。这对开发者来说很不好，最终也会损害企业，因为 doing “敏捷” poorly 多数时候只会比以前带来更多的缺陷、导致更慢的开发进度。好的开发者最终也会离开这样的组织，这又使得企业的效率相比导入“敏捷”前降低许多。
Safe, not SAFe安全，而非 SAFeMy 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 所推荐的做法背道而驰，与 Agile Software Development 的专家们所推荐的做法也背道而驰。我希望的是，我所说的这些人，能够起来帮助自己，帮助你们的公司：向 Manifesto 敏捷 背后真正的思想靠近一些，离身边那些假敏捷、黑暗敏捷 及其许多的变种做法远一些。
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 培训、Scrum 证书，以及领导力培训的做法和想法是好的，最终可能也会开花结果，但这一定是个长期的过程，并且可能最终都无法解救到底层那些可怜的开发者，那些 code mines of ohio。
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”. Mind you 啥意思？？有些人可能会遇到一些让人费解的“敏捷”，比如 DAD 等；幸运一点的可能遇到一些好点儿的，比如「现代敏捷」、「敏捷之心」等。更幸运一点的呢遇到了极限编程——也被称为「那种真正有用的 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: be that as it may，我认为开发者应该有独立的思考，而不应执着于任何“敏捷”的方法论本身。他们应该将注意力转移到正确的软件开发方法——那些放诸任何“敏捷”实践上都能有效工作的开发方法上。这些编程实践，对我而言， involve use of practices such as but not limited to，也意味着合理应用极限编程的实践。或者这么说，开发者应该遵循一些基本原则，这些基本原则是支撑敏捷软件开发的基石，也是我们当初编写敏捷宣言时想要表达的东西。今天，我将这样来表达这些基本原则： No matter what framework or method your management thinks they are applying, learn to work this way:
无论你们的流程或管理者认为他在推动的框架或方法论是什么，请尝试按如下的方式工作：
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.” 对于开发者来说，这应该是他们所能拥有最好的 life 了。如果我们能让软件随时处于可发布状态，那么对于任何可能的 deadline 我们都能拿出当下最好的可工作的软件来。「今天就要上线么？这是我们最新的软件，我们已经准备好发布了。」 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. 一旦我们随时能够面对最后期限，并且对下一步做什么有沟通空间，手里这个随时可运行的软件将让我们可以专注在最重要的工作上面，而非一个几乎没有终点的需求列表，一个他们觉得他们需要的需求列表。将关注重心从「做完这些」转移到「接下来做这个」上来并不容易，但这是我们拥有一个 decent life 的最大可能了。如果能与我们的领导一起工作，而不是在他们领导下工作，那就很可能让关注重心真正地转变过来。
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（大型 Scrum） 方法论，以及 LeSS 方法论。这些方法论为自己打上「企业级」的标签，并认为企业理应导入它们，or roll them out。
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. 作为开发者，你可以十分确定，这些方法论的导入必不顺畅，也一定不会带来真正的敏捷fashion。他们不太可能会培训你，更不太可能让你真的学到些什么，更不可能对你的日常工作有什么实质性的帮助。你领导可能会有一些培训，可能是那种一整周的培训（！），以使他们做好准备，来为组织的产品和软件开发过程推行这种影响重大的方法论。转型之路很可能会有一些崎岖。
Real software is your only hope - Leia (private communication)真正的软件是你唯一的依靠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.
Slow down to deliver降低一些交付速度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. 如果承诺的东西太多，我建议你在每个迭代少承诺一些工作，少到你有信心真正完成承诺的那部分工作为止。这是很困难的！别人会 push 你多做一些。尽可能不要屈服。与其顶着压力，承诺超过你真实工作量的工作，我建议你不如一次只专注在一到两个事情上，把他们完全完成——完全打包、测试、可工作——之后，再做下一件事情。这样在迭代结束时，你才能有一些可以百分百叫做完成了的工作。take the inevitable abuse for not completing everything, 尝试以现实出发来驱动计划和期望设置，而不是别人幻想中的那些要求，那些你根本不可能做完的事情。
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. 这样做可能不是很完美，至少最近一段时间内，它也不会很好玩。但它是我所知道能从 code mine 中爬出来的最好方法了。有一个可工作的软件，是我所知道能翻转现状的最好的方法了。在不好的现状下，我们只能把自己做到最好了，同时尽量让事情变得更好一些。
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!唔…不如选 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. 同时，我推荐你对其他可能用得上的技术也随时保持敏感。「ATDD、TDD、重构」这三样技术，我认为，是你遇见更好的实践前会一直需要的东西。但还有其他许多的技术你也会需要。对它们保持敏锐，如果你看到了有用的东西，马上学起。 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. 软件卓越是一生的事情。即便是 XP，这项我所知最好的方法论，也只触及了软件卓越的皮毛而已。对卓越的追求，与团队与每位成员息息相关。
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. 但是，敏捷软件开发宣言（Manifesto for Agile Software Development）的价值及原则，依然是我所知道最好的构建软件的方法。依我多年的从业经验，我仍然会坚定不移地实践这些价值观和原则，而不管那些大公司用的是什么方法。 I offer that opinion as advice. Do with it as you see fit. 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. 在本文及我的其他作品中，我使用加了引号的「敏捷」一词，用以指代各式各样使用「敏捷」一词自称的变种、方法论、流程等，它与我们在敏捷宣言中所撰写的敏捷软件开发的单词或精神本身，并无必然的关联。有时为了强调，我会用「假敏捷」一词；有时我会用「黑暗敏捷」来描述那些已然面目全非的所谓「敏捷」。我可能会用 Manifesto Agile 一词来指代敏捷宣言的那些核心思想——那些我至今仍然坚信的思想。
|
|
@JimmyLv @Kevin170113664 求个草草 review~ 不用太严肃的那种~ 呃，稍等我再润色下。 |
对软件开发的卓越追求乃终身事业。 | 卓越软件开发乃毕生追求。 突然有一感悟：字越少，竟然越精准。（英文亦然。） Mind you， 说真的。 更接地气的是：讲真，有些开发者…… |
“敏捷”俨然已经成为大生意。毫无疑问，在Scrum联盟® 推出的ScrumMaster证书推动下，我们能看到数以百计，甚至是数以千计的所谓“敏捷”教练和训练员，能看到此起彼伏竞争激烈的框架和方法论。我们能看到“敏捷”领导力培训，“敏捷”项目管理服务，诸如此类。 感觉，we now see, we see这样的翻译，还是翻译为当前比较好，而不是过去式的“我们看到了” |
其实，很多…或许是几乎所有的这些服务并非坏事，至少对于大企业来说是有益的。即便实施“敏捷”的过程很糟糕，但能尝试做出改进的大组织通常都能取得好结果，这是因为勇于尝试往往都会为组织带来或多或少的好处。这些组织至少应该能获得更好的视野来看待接下来的事情，这经常能在糟糕的管理方式下迸发出高明的决策。这是好事，我完全同意。 |
|
@JimmyLv 你这两点补充简直太好。感谢 |
|
@Kevin170113664 谢谢少年 review。预感到你要帮忙做全面 review，可等我把一些词句润色以后，你两天后再看，以免浪费表情…随缘…我对你帮忙 review 没什么期望…随意就好…怕占用太多时间啦~ 然后本来我想拖更了的。看来找个 reviewer 是 push 自己快快搞完的好方式哈哈哈。 |
|
@linesh-simplicity 原来如此，那我就养肥再看 |
校对了两段，花去一小时。我感觉我这个处女座不适合做快速翻译然后出版的活…或许是我 TDD 技能还不够… |
https://ronjeffries.com/articles/018-01ff/abandon-1/
这篇文章，看了前三段，简直不要太好。今晚译完。
PS. 顺便看到了《敏捷开发遵循的原则》的翻译，可以学习学习对比对比：http://agilemanifesto.org/iso/zhchs/principles.html 。全国敏捷爱好者们的翻译智慧哟。
PS. 感觉翻译之前，可以先上 Youtube 看看作者的视频，感受一下风格。
The text was updated successfully, but these errors were encountered: