本网站建立于2014年4月，历史比较悠久哟！
2021年8月31日 来源：彼岸教育BEACON
敏捷宣言20周年之际，有两个事实似乎不言自明。
1. 敏捷，作为一个标签，赢了；没有人想被称为非敏捷。
2. 但是，敏捷在实践中远远低于其创始人的革命性思想。
我们是如何走到这一步的？每个人都说他们在做敏捷，但几乎没有人是真正敏捷的。
注：敏捷宣言（Agile Manifesto），也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。
2001年2月，一个由17位专家软件从业者组成的小组在犹他州瓦萨奇山脉滑雪胜地的小屋会面。经过几天的讨论和辩论，他们共同撰写了“敏捷软件开发宣言”。
首先要强调的是，这些都是从业者。他们不是项目经理、CTO 或 VP Engs。他们是开发人员、程序员、科学家和工程师。他们仍在编写代码并与利益相关者合作解决问题。这个很重要。
另一点是，敏捷宣言不是凭空产生的。
这些人中的许多人已经有了他们创造或正在宣传的方法论。我的时间可能有点偏离，但我认为所有这些方法论都预先存在“资本敏捷”：极限编程、Scrum、DSDM、自适应软件开发、Crystal、功能驱动开发、实用编程。我知道 Schwaber 和 Sutherland 在 1995 年公开谈论过 Scrum，而贝克和杰弗里斯在 1996 年开始谈论极限编程 (XP)，我想。
这个小组中的每个人都有丰富的软件编写经验，他们都在寻找替代文档驱动的、重量级软件开发流程的方法。
宣言的核心是四项价值陈述：
官网信息中文译文
从我们 2021 年的角度来看，很容易将如此多的现代软件开发实践视为理所当然，但在 2001年，这些想法非常激进。
被遗忘的重要部分是，敏捷一开始就公开、激进地反对管理。
例如，肯·施瓦伯 (Ken Schwaber) 直言不讳地表达了他要解雇所有项目经理的目标——不仅仅是让这些离开他的项目，而是要从计算机相关行业中彻底根除项目经理这个职业。
我们发现项目经理的角色在复杂的创造性工作中会适得其反。以项目计划为代表的项目经理的思维将项目中其他人的创造力和智慧限制在计划中，而不是调动每个人的智慧来最好地解决问题。
Ken Schwaber，宣言签署人和 Scrum 共同创建者
Scrum Masters 几乎没有权威，没有投票权。他们是仆人式领导者，帮助保护和疏通团队，但不管理团队。
极限编程是类似的。如果我没记错的话，极限编程最初有跟踪器和教练，它们具有类似的促进、支持氛围。
Alistair Cockburn 是水晶方法论和六边形建筑的宣言签署人和创造者， 最近对此提出了一个奇妙的、有见地的想法：
Scrum 在充满敌意的领域达成了一笔为大的交易：
管理层每年有12次机会，在每次sprint结束后，以他们想要的任何方式改变方向。
团队获得了每月的安静时间，没有中断或方向的变化，专注于进行繁重的思考和工作。
每月管理层干预的情况下，团队必须宣布他们在本月可以做什么和不能做什么。
没有哪位高管得到过比这更好的交易。
没有开发团队得到过比这更好的交易。
我是一名经过认证的 Scrum Master，在敏捷团队工作了15年以上，阅读过该领域的许多流行书籍。我从未见过有人如此明确和简洁地描述这个想法（再次引用一句Cockburn的话）：
发明 Scrum 是为了在恶劣的环境中发挥作用。这是需要时间思考和探索的、强硬管理者和开发人员之间的契约。
在某些方面，敏捷是一场草根劳工运动。它当然从基层的工作者开始，然后被推到管理层。这是如何成功的？
部分原因是开发人员的数量和业务价值不断增长，影响力越来越大。但在我看来，最大的因素是传统的瀑布方法根本行不通。
随着软件变得越来越复杂，业务步伐加快，用户的复杂程度不断提高，试图预先计划一切变得不可能。拥抱迭代开发是合乎逻辑的，如果对于习惯于计划一切的经理来说有点可怕。
我记得2000年代中期的会议，你可以看出管理层并没有真正买账，但他们没有更好的想法。
——那就让我们试试工程师们一直在谈论的这个疯狂的想法吧。
然后令他们惊讶的是，它开始奏效了。
起初，团队会挣扎一段时间，然后慢慢成长，发现哪些模式对单个团队有效，从而获得动力。经过几次冲刺后，你会开始看到优先考虑工作软件、协作、花时间检查和适应以及所有其他方面的真正力量。
在大约5年的历程，敏捷已经从一个未曾实践的方法变成了人人都在做的事情。2005 年，我换了工作，我记得我对敏捷有一点了解，而 TDD 是一个真正的差异化因素。到2010年，人们认为现代软件团队正在进行某种形式的敏捷开发。
🎉🎉我们做到了！我们赢了！恭喜大家！🎉🎉
这就是故事的结局。
——如果你希望如此，那么到此结束吧，接下里发生的事，你可以选择不再看下去了。
获胜很容易，年轻人。治理更难。
诚如百老汇音乐剧《汉密尔顿》中乔治·华盛顿所言
不幸的是，像许多革命一样，接下来的故事并没有像创始人所设想的那样展开。
事实证明，优先考虑个人和互动是一个很难推销的概念。销售流程和工具要容易得多；
事实证明，与不切实际的计划和大量文档相比，可运行的软件更难生产；
事实证明，与客户合作需要信任和脆弱性，在商业环境中并不总是存在；
事实证明，高管们想要掌控一切，但仍然需要为他们的业务制定长期计划，这往往比对变化做出反应更重要；
事实证明……如果敏捷做得不好，就会让人感觉很混乱。
这并不意味着这四个值是错误的。这只是意味着整个事情需要一些努力才能做得正确，需要一些勇气来接受软件有时本质上是无序混乱的。
你必须理解并相信，如果你不断学习、适应、改进和提升，你最终会到达一个更好的地方，一个比瀑布方法更诚实、更现实、更高效的地方。
敏捷运动并不是反对方法论，事实上我们很多人都想恢复方法论这个词的可信度。我们想要恢复平衡。
我们接受建模，但不是为了在尘土飞扬的公司存储库中归档一些图表；我们接受文档，但不接受数百页从未维护和很少使用的大部头；我们指定计划，但认识到在动荡的环境中计划的局限性。
那些将 XP 或 SCRUM 或任何其他敏捷方法论的支持者称为“黑客”的人是对方法论和术语“黑客”的原始定义一无所知的人。
Jim Highsmith，《历史：敏捷宣言》
这些都是重点。我们仍然需要在敏捷中进行计划和记录并保持严谨。这关乎平衡。
但是，如果你的组织正在为敏捷转型而苦苦挣扎，陷入混乱，当有人以认证、流程和工具的形式为你提供救生艇时，你就会一跃而上。
高管们对流程和工具的了解远远超过他们对自组织团队的了解。
这是我的三幕结构有点崩溃的地方，因为不幸的是，我没有看到勇敢的叛逆者重新回到这个结构上，至少不是在敏捷标签下。
工具供应商、流程顾问和专家做出了永远无法兑现的承诺，已经超出了它的范围。这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的方式。这些框架不是出于恶意而创建的，它们甚至可能在正确的上下文中具有一定的价值。但我不会称它们为敏捷。
试图扩展一种专注于个人和互动的方法论将不可避免地导致问题——并侵蚀该方法论的原始价值。
此为Ron Jeffries 作为宣言签署人和极限编程的共同创始人在 2018 年发表的著名文章结语。
当“敏捷”理念应用不当时，往往会导致对开发人员的更多干扰、更少的工作时间、更高的压力以及“更快”的要求。这对开发人员不利，最终对企业也不利，因为“敏捷”做得不好，往往会导致更多的缺陷和更慢的进展。通常，优秀的开发人员会离开这样的组织，导致企业效率低于安装“敏捷”之前。
Dave Thomas 这样结束了自己作为宣言签署人和实用主义编程的共同创始人在 2014 年发表的著名文章。
“敏捷”这个词已经被颠覆到了实际上毫无意义的地步，敏捷社区所传递的似乎主要是顾问和供应商兜售服务和产品的舞台……
一旦宣言流行起来，敏捷这个词就变成了吸引任何有支持点数、账单时间或产品销售点的人的磁铁。它变成了一个营销术语。
所以我认为是时候让“敏捷”这个词退休了。
对我来说，真正令人难过的部分是看到年轻的开发人员诋毁敏捷，并将其视为管理层画饼并推动开发团队疯狂工作的一种手段。
他们所知道的唯一敏捷是强加于他们的控制机制，而不是他们欣然接受的自我赋权工具。但我希望围绕历史和原始愿景展开一些讨论可以帮助我们记住事情应该如何发展。
好消息是，敏捷宣言的原则在今天与20年前一样明智且有意义。甚至连那些所谓的反叛者也不得不承认这一点。
Jeffries 在上面提到的文章中说，“然而，敏捷软件开发宣言的价值观和原则仍然提供了我所知道的构建软件的最佳方式，并且根据我长期而多样的经验，无论大型组织使用什么方法，我都将遵循原这些原则。”
我同意。
现在谈论敏捷并不时髦或酷。敏捷是无聊的。每个人都做敏捷，对吧？ 现在是反思过去 20 年并问自己几个问题的最佳时机：
什么做对了？
什么地方出了错？
下次我们想做什么不同的事情？
一些 Simple Thread 的员工正在经历这场革命，他们计划在未来几个月内反思最初12条敏捷原则中的每一条，将它们的原始含义置于语境中，并考虑它们在当前软件开发环境中的价值。
我的希望是，通过研究基本原则，我们可以从过去中学习，就如Dave Thomas所言：我们可以保持我们的灵活性 ，即使我们选择放弃“敏捷”。
本文原作者为Al Tenhundfeld
原文链接：https://www.simplethread.com/agile-at-20-the-failed-rebellion/
END.
