扫码阅读

手机扫码阅读

【2019全球最佳敏捷文章精选】敏捷社区信奉着某种不切实际的幻想

616 2023-07-22

敏捷团队组织 DevOps 格言

“ 几乎所有敏捷宣言的论断都暗示着一种权衡，以便决定适合当时场景的最佳路径。”

本文来自于“2019全球最佳敏捷文章精选”，由全球最资深的敏捷从业者编辑评选，2018年中文版已由志愿者授权翻译成集，本着对行业的热爱，2019年更多的志愿者加入了，本人有幸参与其中，这是其中一篇，作者Cliff Berg勇敢地指出了目前敏捷社区存在的一些不切实际之处，读来深有同感。--译者注

The Agile Community Embraces an Unworkable Fantasy

敏捷社区信奉着某种不切实际的幻想

Written by Cliff Berg

翻译：胡杰

I am an Agilist. The company that I co-founded in 1995, with almost 200 employees by the year 2000, adopted eXtreme Programming (XP) that year. My 2005 book High-Assurance Design interpreted secure and high reliability engineering practices in an Agile context, proposing a concrete answer to the question, “How can organizations build highly reliable and secure systems using Agile methods?” Since then I have helped more than ten large organizations to move to Agile and DevOps approaches.

我是一名敏捷工作者。我在1995年和人合伙创立了一家公司，到2000年差不多有200名员工，那一年公司开始采用极限编程（XP）。2005年我出版了“高可靠性设计”，介绍了如何在敏捷环境下开展一些稳定且高可靠的工程实践，这实际上回答了一个问题，即“组织如何用敏捷方法来构建高可靠性和高稳定性的系统？”。从那以后，我帮助了十多家大型组织开展敏捷和DevOps的转型。

But the Agile community is very off the rails. It teaches people an ideal model that does not work. This model is like a sacred calf: its elements are discussed by Agile coaches as if they are truisms. One challenges it at great peril: if one speaks against the model, one can be labeled an “Agile doubter”, or someone who is “not really Agile” - a mark of death in the Agile community. The Agile community has historically been very closed minded, and not able to debate Agile ideas in an open-minded and healthy way. My editor at Pearson described it as “insular”. It was DevOps that burst through the Agile doors and humbled the community into accepting more open debate.

但敏捷社区却严重脱轨，因为它只给大家传授了一个无法落地的理想模型。这个模型就像一头饱受惊吓的牛犊，一群敏捷教练围绕着每一个部位展开讨论，好像把这些细节都当成不明而喻的真理。于是任何挑战都是需要面对极大风险的，如果某人挑战了这个模型，他就会被贴上“敏捷质疑者”的标签，而这在敏捷社区简直就是死亡标签。敏捷社区历来思维固化，在这里并不能坦诚布公地、有理有据地辩论敏捷的理念。我在培生出版社的编辑朋友，用“狭隘之极”来形容这种现象。直到DevOps冲破了敏捷的大门，并且让这个社区开始接受更多的公开辩论。

Indeed, writing about this is always a personal risk for me: those who don’t agree will refer to me as “that anti-Agile” guy. I know because it has happened. They are wrong though: I was an early adopter of Agile, and am fully committed to the core ideas of Agile; and I have been immensely successful in implementing Agile - but not in the typical manner of adopting out-of-the-box standard Agile practices.

实际上，撰写这样的文章对我来说也充满风险，那些不认同的人会把我归为“反敏捷”，我这样说，是因为这种事情已经在发生。但他们错了，作为最早的敏捷方法实践者，我十分认同敏捷的核心理念，也主导过非常成功的敏捷实施，不过并非只用那些日常的“开箱即用”的敏捷实践。

My approach is more of a DevOps approach: to always look at the uniqueness of each situation and consider it as a system: Consider what behavioral changes will achieve the business goal, whether it is shorter time to market and building the right things, or higher quality and building things that can be trusted to work. I always start from a business driver perspective and draw from Agile ideas, Lean ideas, behavioral therapy ideas, and many others, rather than trying to force-fit the sacred calf idealist model on every situation.

我的方法更贴近DevOps的理念，即始终关注每个场景的独特之处，并且把它当做一个系统来看待，考虑怎样的行为改变会帮助达成商业目标，是否能否缩短上市时间并符合市场期待，或者能够产出高质量且值得信赖的产品。我始终从商业领导者的角度出发来落地敏捷思想、精益思想、行为治疗思想等等，而非试图削足适履，用“受惊牛犊”的理想模型去适配所有场景。

Let’s look at what the Agile sacred calf model is.

If one takes a training course in Agile “basics”, one will be taught the Agile Manifesto - a brilliant and timeless document - but then one will be taught the Scrum process - even though Kanban is arguably a much better fit for today’s DevOps methods. In addition, one will be told the following falsehoods:

我们一起来看看 “受惊牛犊”的敏捷模型：如果参加敏捷基础课程，敏捷宣言作为一个伟大且不过时内容是一定会有的，然后开始Scrum流程的学习，尽管如今Kanban无疑更适合当下的DevOps方法。另外，他还会被教授如下的错误知识：

1. Self-organizing autonomous teams are the best way to organize programmers.

2. Managers are an “anti-pattern”; ideally there should be no hierarchy, and no one should have explicit authority. All authority and all leaders should emerge through self-organization.

3. No individual should be accountable: only entire teams should be accountable.

4. Failure is the best way to learn.

5. One should always trust the team, even if you have never worked with the team before.

6. All development teams should be feature teams that work across the entire set of technology stacks of the product.

7. Anyone should be able to work on anything.

8. An open team room is the best arrangement, so that people can collaborate most easily and will benefit from “osmotic” communication.

9. More collaboration is always better, and verbal communication is always best.

1. 自组织自运转的团队是开发团队的最佳方式。

2. 经理是一种“反面模式”，理想情况是消除层级组织，没有人具备绝对权力，所有的权力和领导应应在自组织的过程中浮现出来。

3. 个人不应该承担责任，只有整个团队可以承担责任。

4. 失败是成功之母。

5. 始终信任团队，就算从来没和团队合作过。

6. 所有的开发团队都必须是特性团队，能够在产品的所有技术栈中展开工作。

7. 所有人都无所不能。

8. 安排一个开放空间来工作最好不过，因为大家可以最便捷地合作，且团队可以从这种“渗透性”的交流中受益。

9. 合作越多越好，口头交流永远是最佳方式。

The Agile Manifesto does not say any of these things. Let me repeat that:

The Agile Manifesto does not say any of the nine things in the list.

While the Manifesto mentions elements of some of these things, it never says “do only this” or “always do that”. Nearly every statement in the Agile Manifesto is written to imply a tradeoff, so that one can decide what approach is best for a situation.

可是敏捷宣言并没有提到以上任何一件事情。我再重复一遍：

敏捷宣言并没有提到这九条中的任何一条。

当敏捷宣言提及这些细节时，从未说过“只能这样做”或“最好那样做”。几乎所有敏捷宣言的论断都暗示着一种权衡，以便决定适合当时场景的最佳路径。

The above nine axioms form a model that is taken as truth by most of the Agile community at large, despite lots of evidence that the model is wrong. People who really understand Agile don’t make the above nine absolutist claims, but those people are a small percent, and they know to not openly criticize the sacred calf model, unless they are speaking privately with someone else who truly understands Agile.

Books debunking the above model abound, although they do so in a careful and politically correct way, tiptoeing around the model and claiming instead that one needs to “augment” typical Agile practices. A recent one is Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility, by Klaus Leopold. In that book, Leopold expertly connects the dots on the leadership gaps that tend to exist in organizations that create autonomous self-organizing teams and then expect that they will be Agile as a result.

尽管有大量事例说明了这个模型的荒谬之处，但上述的九条格言实际很大程度上已经被敏捷社区视为真理。真正理解敏捷本质的人，不会申张这九条绝对主义格言，但这些人只是少数，并且他们不会公开批评 “受惊牛犊”的敏捷模型，除非是在私下和真正理解敏捷的人沟通的时候。其实反对崇拜经典模型的书也有不少，尽管他们都小心翼翼，尽量用一种政治正确的方式来指出该理想模型的问题，但也仅是在原来的经典敏捷实践上去做“增补”。最近由克劳斯·利奥波德撰写的一本书，“重新思考敏捷：为什么敏捷团队与业务敏捷无关”，将领导力差距的缺陷清晰的指了出来，即组织创立了自组织的自运转团队后，就期望他们自然就能够敏捷了。

Despite the attention-getting title, the book does not directly criticize the nine-axiom Agile model, but instead shows how the adoption of that model by organizations leaves huge gaps, and Leopold explains how to fill those gaps.

除了抓人眼球的标题，这本书并没有直接批评敏捷模型的九条格言，而是指出在采用了这个模型之后留下的大问题，以及如何去解决这些问题。

Agilists (including me) are quick to point out that one cannot simply “insert” Scrum or self-organizing teams: one must “change the organization’s culture”. But what does that mean? The very same people who stand by the above nine prescriptions seldom have a good answer for what a culture change means. They say platitudes like, “One must get managers to embrace failure”, and “The organization needs to learn to experiment”.

包括我在内的敏捷实践者，都能很快指出一点错误，就是不能直接在组织中“嵌入”Scrum或自组织团队，而是必须“改变组织文化”。但那是什么意思呢？拥护九条格言的人，很少能回答好文化变革的意义是什么，他们只会重复那些陈词滥调，比如“必须让管理者拥抱失败”，或者“组织本身需要学着尝试”。

Fine, but that kind of advice is too vague, and abstract advice that ends in a platitude tells me that someone does not really know what they are talking about - that they learned something in a book but have not actually solved that problem.

没问题，但这种建议太虚了，这种抽象的套话让我感觉，他们并不知道他们在说什么，似乎只是纸上谈兵，但并不知道如何解决问题。

I have helped more than ten organizations “go Agile” or “go DevOps”, and I have seen every permutation of this. I have also seen common patterns that are usually present. These are,

1. Organizations keep their existing market research and product definition methods, which have a long lead time, and which “hand off” product requirements to “IT” to build.

2. Organizations dismantle old style program-level or product-level leadership, but don’t replace it with an Agile equivalent.

3. Organizations try to “roll out” Agile, treating it like a process change, when in fact it is mostly a learning journey.

4. Organizations fail to put sufficient emphasis on the technical side of Agile, which today is “DevOps”.

我帮助过10多个组织开展“敏捷转型”或“DevOps转型”，目睹过几乎所有的情形。我也见过现存的几种常见模式，比如：

1. 组织延续原有的市场调研和产品定义方式，这通常需要很长的前置时间，并且常常是将产品需求“转手”给“IT”部门来开发。

2. 组织放弃了原有的系统级或产品级的开发模式，但是并没有替换为敏捷模式。3. 组织试图“切换”到敏捷模式，认为这不过是一种流程变革，但到临到切换，却陷入了长时间的学习过程。

4. 组织充分重视技术敏捷，即我们现在所说的DevOps。

Many organizations try to “roll out” Agile by adopting SAFe, or some variation of that. This actually helps somewhat because it fills some gaps pertaining to item 2 above, and possibly even impacts 1 - although that is less common. But the huge Product Increment planning exercise that SAFe prescribes is unnecessary, in my opinion.

许多组织试图用SAFe或类似的方法来“切换”到敏捷模式，这确实在一定程度上有利于组织转型，因为它弥补了许多以上第二部分谈到的差距，甚至有可能影响到第一部分，尽管这很少见。但是SAFe规定的大规模产品增量规划活动，在我看来并非必要。

The biggest leadership gaps that I usually see pertain to technical leadership. Organizations might adopt a “Lean portfolio” process (which SAFe recommends) and a product “release train” structure, but they fail to address how the many components of their product integrate. They dismantle their traditional approach of having a separate QA team focus on “system integration testing” but they don’t replace it with an Agile and DevOps equivalent, which ideally is frequent, cadence-based on-demand automated integration testing, backed by “shift-left” local integration testing.

我常看到的最大的领导力问题在于如何发挥技术领导力。组织可能采用了“精益组合（Lean portfolio）”流程（SAFe框架所荐），以及产品“发布火车（release train）”，但是仍然难以解决如何集成众多系统的问题。SAFe放弃了传统的方式，比如设置单独的QA团队专注在“系统级集成测试”上，但是并没有采用敏捷或DevOps的模式，即持续的、有节奏的、按需进行的自动集成测试，以及支撑其“测试左移”的本地集成测试。

They often put a development manager in charge of the product teams, but the manager has heard the message that teams should be “self-organizing and autonomous”, and so he or she fails to step in and provide the leadership that is needed. The result is that the teams tend to operate in a highly independent manner, and fail to adequately address integration across teams. The sacred calf model is then the direct cause of the ensuing dysfunction.

他们通常会指派一名开发经理来负责产品开发团队，但是这名经理因为听说过团队要“自组织自运转”，所以他不会在团队需要的时候及时介入，并提供领导力支持，导致的结果是各团队试图用一种高度独立的方式来运作，从而无法充分解决跨团队集成的问题。这种情形下， “受惊牛犊”的敏捷模型，成为了系统失效的直接原因。

Agile methods include having regular retrospectives, and most organizations do this at a team level because Scrum prescribes it, but they fail to institute it at a product or program level. Agilsts will point out that this is a symptom of “not having an Agile culture”, because an Agile culture would surely think to have retrospectives at every level. But when an organization is trying to adopt Agile methods, they cannot magically “become an Agile culture”. They need guidance on what practices to install. Eventually those practices will foster more Agile thinking, but that change in thinking will take a long time.

敏捷方法包括召开常规的回顾会议，大多数组织是在开发团队层面来举行，因为Scrum就是如此规定的，但是组织却难以组织起产品级或项目集级的回顾。敏捷实践者会指出这是一种“缺乏敏捷文化”的症状表现，因为真正的敏捷文化必然会指向各个层级的回顾会议。但是当某一组织开始采用敏捷方法的时候，他们并不会神奇地“变成敏捷文化”，而是需要原则来告知采取何种实践。最终这些实践会引发更多的敏捷思考，但是思想的改变总是漫长的。

And this is where the Agile community, in general, is confused: the claim is that organizations must change their culture to be Agile. Yet the reality is that to change an organization’s culture, one must first change behavior - not the other way around. Culture change follows behavior change, and if the behavior change is maintained for long enough, the change becomes self-sustaining and becomes the new culture. (In the behavioral therapy community, this change lifecycle is described by the “transtheoretical model”.)

这也是敏捷社区主要困惑的一点：声称组织必须变革至敏捷文化，但现实是，改变组织文化又必须首先改变组织行为，别无二路。组织行为的改变带来文化的变革，如果行为的改变维持得足够持久，这种改变会自我持续并最终成为组织的新文化（在行为治疗领域，将这种改变周期形容为“跨理论模型”）。

In other words, it is unreasonable to expect organizations to come up with Agile approaches just by learning the Agile Manifesto: they need help in defining new processes and practices, that over time will become the new normal; and in the course of those behavioral changes, they need Agilists to interpret the changes for them, to help them to see the behavioral changes through an Agile lens - that way, their thinking begins to change. But the behavioral changes must come first. People go from concrete to abstract, not abstract to concrete.

换而言之，期待组织通过学习敏捷宣言来习得敏捷方法是不切实际的，他们需要在设定流程和实践方面得到帮助，久而久之成为团队的新规范。在行为改变方面，团队需要敏捷实践者来帮他们诠释这些改变，协助他们通过敏捷的视角来看到这些行为的改变，这样团队的思维才能开始转变。但是行为改变肯定是先发生的，人倾向于从具体到抽象，而非从抽象到具体。

Thus, it is the Agile community’s fault for popularizing the overly simple model of autonomous teams and not helping organizations to anticipate all of the new processes and practices that they will need so that those teams will work together. Telling them that they should have a collection of self organizing teams and that they should “start to think Agile” is not enough. The teams need explicit methods for organizing their collective behavior: they will not adequately self organize around a product or value stream, and most development managers will not know how to stimulate the required level of cross-team collaboration: they will stand back and watch, and expect the teams to magically start collaborating - because that is how they have been told Agile works - but it doesn’t happen.

所以，这是敏捷社区的错，普及了过于简单的自治团队模型，却没有帮助落地组织所需新流程和新实践，而这正是团队能够共同合作的前提，仅告知他们要有一批自组织团队，这批团队应该“开始思考敏捷”，这是不够的。团队需要明确的方法来组织集体行为，因为他们不会自发的围绕产品或价值流进行合理地自组织，而且多数开发经理也不懂如何激发所需的跨团队合作水平，他们通常会退后，观察，并且期望团队能够神奇地开始合作，因为他们被告知敏捷就是如此运作的，但这通常不会发生。

A failure to have retrospectives at a product or program level blocks the improvements that Agile might bring: product feature cycle time cannot be substantially reduced, nor can the rate of escaped product defects, unless one focuses on end-to-end improvement, spanning the many teams of a product or value stream.

无法在产品级或项目集级开展回顾会议，会阻碍敏捷可能带来的改进，包括产品功能的开发时间并不会因此缩减，产品缺陷率也不会因此减少，除非团队真正专注在端到端的改进上，让围绕产品或价值流本身的众多团队可以有效运作起来。

Improving individual teams will not unlock the benefits of Agile. And Agile coaches, who tend to be non-technical, shy away from discussing technical issues during retrospectives, so don’t rely on them to help you improve your end-to-end technical flow. They will tell you that you need to identify dependencies and reduce your “WIP”, but they won’t have any ideas about how to manage the dependencies so that integration happens frequently and tests at all levels of integration are sufficient. (See this article on dependency management, and this article series on defining a testing strategy.) Nor do most teams know the CI/CD practices that are needed for rapid integration - they don’t know what they don’t know: thus, the adage “trust the team” fails to account for the DevOps mentoring that teams need.

改善单个团队并不能够解锁敏捷的收益，而敏捷教练，通常不关注技术领域，避免在回顾会议中讨论技术问题，所以不能依赖他们来帮助改进端到端的技术流程。他们会告诉你需要识别依赖并减少“在制品（WIP）”，但是他们不会告诉你如何管理依赖，让所有层级的集成能够持续，测试也能有效进行（可以参考这篇关于依赖管理的文章链接，这个文集定义了测试策略）。大多数团队并不了解快速集成所需的持续集成/继续发布实践（CI/CD），针对这点他们并不知道自己的无知，所以“信任团队”的格言，并不能在团队所需的DevOps领域给出指导。

The fact is, someone needs to be accountable for the product level technical flow. Otherwise, there is no product level leadership around things like end-to-end testing. The leadership style should be servant leadership, so that it is collaborative and enabling - not autocratic and fear based. But someone needs to have their eye on that ball all the time: the integration level issues that come up are complex and numerous, and they will totally block substantial improvement if you don’t address them.

事实上，需要有人对产品级的技术流程负责，否则会导致在产品级层面的事务缺乏领导力，比如端到端测试。这种领导力类型应该是公仆领导力，基于合作和赋能，而非专制和恐惧。但是需要有人自始至终关注这点：不同层级的集成业务是十分繁杂的，如果不能处理好这些问题，毫无疑问将阻碍后续的改进。

A person who has accountability needs to have actual authority: accountability without authority is a terrible situation to be in. But a servant leader will not exercise their authority most of the time: they will save it for rare occasions when they need to make a decision about something that cannot be resolved collaboratively, such as the need to re-organize some teams. The rest of the time, they are watching for things that are falling through the crack, and making sure that issues are being discussed and resolved - mainly by asking questions and making suggestions, but sometimes - hopefully rarely - by insisting that something be addressed, and asking the team to trust them.

权责必须对等，有责无权，境况惨烈。但是公仆领导者多数时间并不会行使这种权力，他们将权力保留至一些特殊情境，譬如组织重组这种仅靠协作无法达成一致的情况。他们大多数时间都只是观察即将发生的问题，以提问和建议的方式，确保问题得以讨论和解决，仅在个别情况下有不得不坚持解决某些问题，并且让团队信任他们的决定，当然希望这种情况越少越好。

So much for the falsehood that one should have autonomous self-organizing teams! What teams need is servant leadership, at all levels: the team level, the product level, and the program or value stream level.

Then there is the claim by Agilists that failure is the best way to learn. No one likes to fail. A market facing failure is never a good thing. The idea of “fail early, fail often” pertains to controlled experiments, which might be market-facing if they need to be. SpaceX uses the “fail early, fail often” technique: they build lots of rocket engines and run them to failure, to learn how they fail. They even do that for whole rockets. But the last thing they want is a failure during a mission!

关于自组织自运转理团队的谬误真的太多了！其实团队需要的是公仆领导，来自所有层级的公仆领导力，包括产品级、项目集级，甚至价值流级。但是敏捷实践者们会说，失败是最好的学习方式。其实没有人喜欢失败。市场上的失败从来不是一件好事。“早失败、多失败”的理念适应于可控的试验场景，当然需要的时候也可以是面向市场的失败。SpaceX就采用了“早失败、多失败”的策略，通过制造大量的火箭引擎，让它们工作至失效，来了解产品的缺陷，他们甚至在整个火箭产品上也采用这种策略。但是他们绝不想在任何一次发射任务中也尝试这种失败！

Instead of the very misleading “fail early, fail often”, the maxim should be, “try things - experiment a-lot and expect many experiments to fail - that way you will learn, and you won’t fail when it counts”.

The other items in the list of nine Agile falsehoods can be summarized as extremes that contain good ideas but that usually don’t work in their extreme form - the form that is usually explained during an “Agile Basics” course and which is advocated by a large percent of Agile coaches.

除了 “早失败、多失败”这种误人子弟的说法，还有一条格言是“尝试一些事情-大量尝试，并且预料到大量尝试都将失败-这样你才会开始学习，在关键时刻才不会失败”。其他九条谬误格言理由可以总结为，究极求胜，但通常极端方式毫无作用，但这种方式却在“敏捷基础知识”中提及，并被多数敏捷教练所推崇。

Self-organization? Sure - to a degree, but better to have a true servant leader who can help the team to organize and to have high quality dialectic discussions. Anyone can work on anything? Maybe - but sometimes business-critical core microservices need to be maintained by a single team in order to ensure their design cohesion. Open team room? No one actually seems to like that, but maybe the “coffeehouse” format is a good compromise - thus we come full circle to the old “caves and commons” idea. In-person communication is always best? For simple things yes, but for very complex issues, some people communicate better by writing their thoughts down first: that is a matter of personality.

And so on.

自组织? 当然在一定程度上是好的，但最好是有一位合格的公仆领导，能够帮助团队组织起来，引发高质量的辩证讨论。每个人无所不能？有可能，但是有时业务敏感度高的核心微服务，需要由一支独立的团队维护更好，以保持设计思路的一致性。开放办公空间？好像没有人真正喜欢，但“咖啡馆”似乎是一个较好的折中，这样我们形成了既有私密空间，又有公共空间的“洞穴和客厅”模式。当面沟通永远是最好的方式？对于简单的事情没问题，但是如果是高度复杂的事情，先把想法写下来，会帮助有些人更好的沟通，这和人的个性相关。

Extremes don’t work, except in extreme circumstances. Most organizations are not in extreme circumstances. The Agile Manifesto was about balance and judgment - not about extremes. Those who teach the nine falsehoods do not really understand Agile: they are cargo-cult① Agilists. All those nine ideas are extreme variants of good ideas, but the extremes don’t make any sense most of the time.

Each of the nine maxims should be taught as an idea to be considered, and nothing more, with the caution that the right approach depends on the situation.

极端主义只在极端环境下有效，而大多数组织都不是极端环境。敏捷宣言寻求平衡和判断，而非极端主义。传授九条谬误格言的敏捷教练并不真正懂得敏捷，他们是“货物崇拜”者① 。这九条谬误格言都源自对好想法的极端曲解，但多数时候却毫无意义。这九条格言仅供参考，实践中都应深思熟虑、因地制宜。

It is time to dismantle the false ideal model of extremes that is being taught in Agile Basics courses and that does not actually work, and bring judgment and reality back into Agile.

是时候在敏捷基础课程中放弃充满谬误的极端模型了，这在实际工作中毫无用处，将判断力和现实带回敏捷本身吧。

----------------------------------------------

① 译者注：cargo-cult，货物崇拜，是一种宗教形式，特别出现于一些与世隔绝的原住民中。当货物崇拜者看见外来的先进科技物品，便会将之当做神祗般崇拜。

About Cliff Berg

Cliff has helped more than ten organizations adopt Agile and DevOps methods, working with leadership and teams to move the needle.

Cliff has experience with Agile and DevOps in a wide range of contexts, from large multi-product digital platforms to embedded systems.

Cliff works with senior leadership to understand goals and help to define transformation strategies. He also supervises coaches to provide a second pair of eyes and make sure that work is aligned and effective.

原文链接： http://mp.weixin.qq.com/s?__biz=MzI3MDg3MjQ1Ng==&mid=2247483664&idx=1&sn=da9652bba169176138c8532c99aaac74&chksm=eacb3bf7ddbcb2e1fed90039ca7d55527ec9544960953878852c662d7e7f0e825e154b36713b#rd

【2019全球最佳敏捷文章精选】敏捷社区信奉着某种不切实际的幻想

The Agile Community Embraces an Unworkable Fantasy

Written by Cliff Berg

联系我们

融实践库

微信公众号

微信视频号

社区微信群