20岁的敏捷:失败的反叛 - simplethread


今年敏捷宣言刚满20年,有两个事实似乎不言自明的:

  1. 敏捷,作为一个标签,赢了;没有人想被称为非敏捷。
  2. 敏捷在实践中远远低于其创始人的革命性思想。

我们是如何走到这一步的?每个人都说他们在做敏捷,但几乎没有人是敏捷的。
 
宣言从何而来
2001 年 2 月,一个由 17 位专家软件从业者组成的小组在犹他州瓦萨奇山脉雪鸟滑雪胜地的小屋会面。经过几天的讨论和辩论,他们共同撰写了“敏捷软件开发宣言”。
我不知道每个签名者的个人历史,但在我认识的那些人中,他们要么仍在积极编写代码,要么有一段很长的近期编程历史。
首先要强调的是,这些都是从业者。他们不是项目经理、CTO 或 VP Engs。他们是开发人员、程序员、科学家和工程师。他们仍在编写代码*并与利益相关者合作解决问题。这个很重要。
另一点是敏捷宣言不是凭空产生的。这些人中的许多人已经有了他们创造和/或正在传教的方法。我的时间可能有点偏离,但我认为所有这些方法论都预先存在“资本敏捷”:极限编程、Scrum、DSDM、自适应软件开发、Crystal、功能驱动开发、实用编程。我知道 Schwaber 和 Sutherland 在 1995 年公开谈论过 Scrum,而贝克和杰弗里斯在 1996 年开始谈论极限编程 (XP)。
这个小组中的每个人都有丰富的软件编写经验,他们都在寻找替代文档驱动的、重量级软件开发流程的方法。宣言的核心是四项价值陈述:
  • 个人和交互 胜过流程和工具
  • 工作软件 胜过综合文档
  • 客户协作 胜过合同谈判
  • 响应变化 胜过遵循计划

 
新希望
从我们 2021 年的角度来看,很容易将如此多的现代软件开发实践视为理所当然,但在 2001 年,这些想法非常激进:在收集所有需求并估算每项功能之前,您打算开始构建软件是什么意思?这太疯狂了!
被遗忘的重要部分是,敏捷一开始就公开、激进地反对管理。例如,肯·施瓦伯 (Ken Schwaber) 直言不讳地表达了他要解雇所有项目经理的目标——不仅仅是让人们离开他的项目,还要从我们的行业中根除这个职业。
我们发现项目经理的角色在复杂的创造性工作中会适得其反。以项目计划为代表的项目经理的思维将项目中其他人的创造力和智慧限制在计划中,而不是调动每个人的智慧来最好地解决问题。
Scrum Masters 几乎没有权威,没有投票权。他们是仆人式领导者,帮助保护和疏通团队,但不管理团队。XP 是类似的。如果我没记错的话,XP 最初有跟踪器和教练,它们具有类似的促进、支持氛围。
Alistair Cockburn 是水晶方法论和六边形架构 宣言签署人和创造者, 最近对此提出了一个奇妙的、有见地的想法:
Scrum 在其反对的敌对领域反而达成了一笔不菲的交易:
  • 在每次冲刺之后,管理层每年有 12 次以他们想要的任何方式改变方向。
  • 团队获得了整整一个月的安静时间,没有中断或方向的变化来进行繁重的思考和工作。
  • 团队必须宣布他们在本月可以做什么和不能做什么,而管理层不会干预他们的竞标。

 
敏捷成功的原因
在某些方面,敏捷是一场草根劳工运动。它当然从实地的从业者开始,然后被推到管理层。这是如何成功的?
部分原因是开发人员的数量和业务价值不断增长,影响力越来越大。但在我看来,最大的因素是传统的瀑布方法根本行不通。随着软件变得越来越复杂,业务步伐加快,用户的复杂程度不断提高,试图预先计划一切变得不可能。拥抱迭代开发是合乎逻辑的,如果对于习惯于计划一切的经理来说有点可怕。
 
存在问题
不幸的是,像许多革命一样,敏捷的历史并没有像创始人所设想的那样展开。
  • 事实证明,优先考虑个人和互动是一个很难推销的概念。反而有助于某些公司更方便推销流程和工具。
  • 事实证明,与不切实际的计划和大量文档相比,可运行的软件更难生产。
  • 事实证明,与客户合作需要信任和脆弱性,在商业环境中并不总是存在。
  • 事实证明,高管们想要掌控一切,但仍然需要为他们的业务制定长期计划,这往往比对变化做出反应更重要。

事实证明,敏捷做得不好常常让人感觉很混乱。
这并不意味着这四个值是错误的。这只是意味着整个事情需要一些努力才能正确,需要一些勇气来接受软件有时本质上是混乱和混乱的。你必须理解并相信,如果你不断学习、适应、改进和运输,你最终会到达一个更好的地方,一个 比瀑布更诚实、更现实、更高效的地方。
工具供应商、流程顾问和专家做出了永远无法兑现的承诺,已经超出了它的范围。这就是我们最终采用 SAFe 和 Scaled Scrum 以及所有其他企业敏捷风格的方式。这些框架不是出于恶意而创建的,它们甚至可能在正确的上下文中具有一定的价值。但我不会称它们为敏捷。试图扩展一种专注于个人和互动的方法论将不可避免地导致问题——并侵蚀该方法论的原始价值。
 
开发人员应该放弃敏捷
当“敏捷”理念应用不当时,往往会导致对开发人员的更多干扰、更少的工作时间、更高的压力以及“更快”的要求。这对开发人员不利,最终对企业也不利,因为“敏捷”做得不好,往往会导致更多的缺陷和更慢的进展。通常,优秀的开发人员会离开这样的组织,导致企业效率低于安装“敏捷”之前。
  
敏捷已死(敏捷万岁)
“敏捷”这个词已经被颠覆到了实际上毫无意义的地步,敏捷社区所传递的似乎主要是顾问和供应商兜售服务和产品的舞台……一旦宣言流行起来,敏捷这个词就成了吸引任何有支付钞票的磁铁。它变成了一个营销术语。
所以我认为是时候让“敏捷”这个词退休了。
 
现在谈论敏捷并不时髦或酷。敏捷是无聊的。每个人都做敏捷,对吧? 现在是反思过去 20 年并问自己几个问题的最佳时机:
  • 什么做对了?
  • 什么地方出了错?
  • 下次我们想做什么不同的事情?