Agile已死, Agility长存

简介: Agile Is Dead (Long Live Agility) ( Agile已死,Agility长存)

Agile Is Dead (Long Live Agility) ( Agile已死,Agility长存)


      13年前,我和17个中年白人在Snowbird(译者注:应该是一个开发者社区,此处应该亦是指其承办的一次开发者大会), Utah(美国犹他州)聚到了一起。我们之所以能走到一起,是因为我们对于软件开发有着共同的信仰,并试图找出一种方法来描绘我共同的信仰。


  我们用了不到一天的时间搞出了一套核心价值清单,然后我们将这套体系连同一些实践这个体系的清单列表作为《Manifesto for Agile Softwar (敏捷开发宣言)》发布了出来。即:


Individuals and Interactions over Processes and Tools   -> 人和交互      优先于过程和工具。

Working Software over Comprehensive Documentation   -> 可以工作的软件  优先于求全责备的文档。

Customer Collaboration over Contract Negotiation, and  ->  客户协作          优先于合同谈判。

Responding to Change over Following a Plan                  >   随时应对变化     优先于循规蹈矩。

  

      我对我们所做的事情,不论是过程还是结果,都感到十分自豪。并且我认为这套敏捷开发清单帮助开发人员挣脱了八,九十年代那些浪费和十分枯燥的开发流程。


  但是,自从Snowbird大会结束后,我再也没有参加任何和"Agile"相关的会议,没有作为会员加入任何敏捷开发协会,并且没有提供任何有关"Agile"的咨询服务。甚至没有参加10周年纪念庆典。


  为什么?因为我认为这些不符合我们的敏捷价值观。举办关于敏捷的会议就像举办芭蕾舞会,而围绕着这四条核心价值组成的产业小组在我看来更像是组建了一个贸易联盟。

 

 并且,不幸的是,我想,时间已经证明了我是对的。"Agile"这个词已经搅乱了人心,但实际上并没有产生多大的意义,而敏捷社区看起来更像是咨询师和小商贩们叫卖服务和产品的市场。


  所以,我认为是时候让"Agile"这个词退休了。


  我想不会有人反对禁用这个词当它已经被当成一个名词来使用。这是一个明显的错误。"Do Agile Right"和"Agile for Dummies"就是无数英文语法错误中的两个。它们毫无意义。"Agile"不是一个名词,这是一个形容词,它必须用来修饰某些东西。"Do Agile Right"就像是在说"Do Orange Right"。


  但是,除了语法错误以外,还有一个严重的问题。自从敏捷宣言流行起来之后,所有人(例如为了支持某个论点,为了某个宣传,为了销售某些商品)都把"Agile"一词作为宣传点。它已经成为一个被用来促进销售的市场营销的专业术语,就像"eco"和"natural"一样。如此滥用这个单词已使它毫无意义,当它成为一个商标时,它的作用已经结束了。


  这伤害了每一个人,但我更在意的是这伤害了开发人员。写代码并不容易,开发人员自然会寻找能帮助他们完成更有效交付的东西。我仍然坚信,坚持敏捷的核心价值并付诸实践将会对开发过程提供帮助。


  但是自从敏捷一词已经失去意义,开发人员不能再将它作为指导准则来找出到底什么在开发过程中是有用的。我们或许简单地在世界范围内把敏捷一词替换成空格(译者注:这样其他人就无法使用”“空白字符串来交流,也就无法被滥用。我是这么理解的。:P)。


Moving to the Right 回到正轨


让我们再看一下这4条核心价值:


Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation, and

Responding to Change over Following a Plan

  

左边的短语代表了一个理念 -> 如果能够在左侧或右侧的开发流程中选择的话,想要敏捷开发软件的人员更倾向于左侧的方式。


  现在,让我们看一下那些说自己能让你开始敏捷起来的咨询师和小商贩们。问问你自己,他们在 左-右 这条轴上到底处在什么位置。我猜你会发现他们会像你建议很多工具(提供更多文档式的建议以取悦项目经理)并且制定更多计划远远超出了敏捷所需的一个白板和一些粘到白板上的做记录用的磁贴,不论是过程还是工具都很繁重。


  如果你也发现了这些,那么这更加证明了"agile"一词已经腐败堕落。


  (当然,这些咨询师或许只凭一两天的培训课程就能赚很多钱。但我不行,所以他们是成功的,而我不是,某种角度来讲,我所言可能是错的。)

 

Back to the Basics 回归本质


下面讲述如何以敏捷方法来做一些事:


什么:

  • 搞清楚你在什么位置
  • 向你的目标迈出一小步
  • 在这个过程中,基于你所学到的东西重新整理你的认知
  • 重复以上步骤


怎么做:


在同一个结果面前,当你面对两条或更多可以让你选择的路时,选择那条将来更容易改变的。(译者注:此处不是说你选择的路将来发生变化,而是万一出现问题,你更容易换条路走。)

  

     这就是你所仅仅需要做的。上面这四条基本原则和一条实践路线已经包含了如何有效的进行软件开发所需要知道的一切。当然,这个过程蕴含了大量的思考,并需要将整个基本流程迭代无数次,很多时候,你所需要关注的甚至包括了从变量命名到持续交付过程中的所有事情。但是,记住,任何人提出更高级,复杂的东西,那他只是想向你推销,骗取你的钱财罢了。


  这篇文章所提到的都是当务之急--它们用一些动词来告诉我们做什么和怎么做。


    也正是这些促使我在此给出我的建议。


  让我们放弃使用那些不做实事的人所使用的词"agile"。


  相反,让我使用另外一个单词来描述我们所在做的事。


Let’s develop with agility (让我们"敏杰"开发


  • 你不是一个敏捷程序员--而是一个写程序很敏捷的程序员。
  • 你不是在一个敏捷团队工作--而是你的团队表现的很敏捷。
  • 你不是使用敏捷工具--而是你使用工具让你更加敏捷。

 

人们很容易把"agile"一词用到任何地方,但"agiility"不易被胡乱挪用。


这一点很重要--标签是可以进行买卖的。参加一个简短的培训,瞬间你就可以给你的职位贴上敏捷的标签。但是你不能买到经验--你只能学到经验。


And let’s protect our investment (让我们保护我们的付出)


  归根结底,我们做什么,怎么做远比我们怎么称呼它更重要。但是一个好的词语帮助我们更有效的沟通。


  我们已经失去了"agile"一词。让我们尝试使用"agility"。让我们保住它的真谛,别让那些别用用心的人窃取敏捷的灵魂思想,转手再把它卖给我们。

相关文章
|
10月前
|
Java 数据挖掘 项目管理
【Java开发工作者如何提升自己的商业 sense?】
【Java开发工作者如何提升自己的商业 sense?】
|
3月前
|
缓存 API 开发工具
2024 Flutter 一季度热门 issue/roadmap 进展和个人感触闲聊
Flutter 已经和 Android Team 沟通并推进相关 Android 14 的 patch 落地:
41 2
|
2月前
|
测试技术 自然语言处理 人工智能
从80个模型中构建Scaling Law:华人博士生新作,思维链提出者力荐
【6月更文挑战第3天】华人博士生团队联合斯坦福、多伦多大学和Vector Institute提出观测缩放律,通过分析80个语言模型构建通用缩放模型,预测LM性能。研究显示,模型能力可用低维空间表示,与计算量呈对数线性关系。通过主成分分析,他们揭示了模型的通用、推理和编程能力。此方法能预测复杂现象和未来模型如GPT-4的性能,低成本评估后训练干预效果。然而,模型局限性在于可能不适应未来显著不同的模型和任务,也无法完全考虑所有影响性能的因素。[链接](https://arxiv.org/pdf/2405.10938)
36 2
|
3月前
|
大数据 数据处理 云计算
道家学派创始人老子,对 SAP ABAP 这门编程语言的客观评价
道家学派创始人老子,对 SAP ABAP 这门编程语言的客观评价
|
3月前
|
缓存 安全 测试技术
「译文」Google SRE 二十年的经验教训
「译文」Google SRE 二十年的经验教训
|
存储 自然语言处理 运维
MetaForce佛萨奇(2.0)系统开发(原力元宇宙开发)丨佛萨奇MetaForce马蹄链2.0系统开发(稳定版)
 自然语言处理是人工智能技术中的另一个分支,主要应用于机器与人之间的语言交互。在工业领域,自然语言处理可以用于实现自然语言的输入、理解和生成。例如,在工业设备维护领域,可以使用自然语言处理技术来实现设备的语音控制和故障诊断。
|
人工智能 区块链
MetaForce马蹄链佛萨奇2.0系统开发正式版丨MetaForce佛萨奇马蹄链系统开发技术详细及源码
 原力元宇宙MetaForce是在Polygon马蹄链上部署的一个智能合约,Polygon马蹄链,是基于ETH开发的一个独立公链,用于构建和连接与以太坊兼容的区块链网络,智能合约可以直接在马蹄链上部署,百分百开源,百分百去中心化,一旦运行,不可篡改。佛萨奇forsage2.0-“Meta Force原力元宇宙”之所以如此受欢迎,是因为它使用了智能合同技术和独特的矩阵系统,
MetaForce马蹄链佛萨奇2.0系统开发正式版丨MetaForce佛萨奇马蹄链系统开发技术详细及源码
|
敏捷开发 架构师 测试技术
2022年下半年 系统架构师,论文-软件开发模型(Software Development Model)
2022年下半年 系统架构师,论文-软件开发模型(Software Development Model)
270 0
|
机器学习/深度学习 安全 程序员
产品设计不是命题作文:Design Hackathon 方法介绍
在产品的定义阶段,产品发展形态的可能性是最多的。对于当前国内绝大多数移动互联网创业公司来说,在产品定义初期,往往都是由个别产品负责人或者创始人「决定」产品方向的。这种「命题式」的传统方法,会导致产品的大部分可能性被早早扼杀,很容易让产品设计陷入程式化的思维或是已有的产品模式。在这种方式下,不能说诞生不了好的产品,但突破和创新的难度将会大大提高。传统的「头脑风暴」,在发散思维时往往失于天马行空,忽略了落地的可行性。
294 0
产品设计不是命题作文:Design Hackathon 方法介绍
|
机器学习/深度学习 安全 算法
豌豆荚Design Hackathon 工作法分享
提起豌豆荚,相信安卓用户都并不陌生,截止近日,豌豆荚已经收录超过100W款不重复的应用和游戏,同时在视频领域也拥有超过1000万的用户积累,作为国内最早的「应用搜索」也是第一个战略进阶为「手机上内容发现和获取的入口」的产品,豌豆荚绝对是安卓平台里的一个非常经典的成功案例。
185 0
豌豆荚Design Hackathon 工作法分享