亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

為了賬號安全,請及時綁定郵箱和手機立即綁定

名不符實的敏捷

標簽:
雜七雜八
企业IT迷失了方向

Photo of a waterfall

照片由 Aditya ChinchureUnsplash 拍摄

二十年后,敏捷宣言承诺拯救瀑布式僵化之后,一个令人清醒的现实浮出水面……

虽然近70%的信息技术团队声称在实践敏捷方法论(Digital.ai, 2023),但深入挖掘后你会发现,期望破灭的景象比比皆是,特别是在大型企业中。只有43%的大公司报告说敏捷对他们“非常或相当有效”——这与小型公司52%的满意度形成了鲜明对比(Digital.ai, 2023)。

这种差距暴露了一个残酷的现实:许多组织只是名义上采用了敏捷。他们执行了仪式,使用了术语,购买了工具——却在真正的敏捷核心上失之交臂。企业 IT 是怎样彻底偏离了正轨的,我们能从这次集体的错误中学到什么教训?

结构反叛

企业架构在每个方面都与敏捷原则相冲突。虽然敏捷方法强调适应性和自我组织,但企业结构却要求控制、专业化和可预测性。这种冲突不仅仅是理念上的分歧——它制造了日常摩擦,使敏捷项目寸步难行。

敏捷遇到治理会怎样?监管要求、审计轨迹和风险管理框架并不会因为宣称我们是敏捷的而消失。Forrester Research 直接观察到了这种碰撞:即使那些尝试 Scrum 的组织,仍然需要在开发开始前因为合规需求而制定详细的规格和计划(Forrester Research, 2011)。结果是,团队花费数周时间制作瀑布模式需要的文档,然后假装发现了他们早已承诺要实现的需求。

决策层级也是一种结构性障碍。

敏捷方法期望团队在学习过程中能迅速调整方向。然而,在企业环境中,即使是微小的调整也需要经过多个审批层的批准。一项研究表明,42%的组织认为管理层对变革的抵制是实施敏捷方法的主要障碍(The Stack, 2022)。当每一个重要决定都需要委员会批准时,快速适应的循环就会完全中断。

或许最根本的是,企业预算流程不适应敏捷思维。年度资金周期将团队锁定在几个月前就已确定的交付成果之中。这种财政束缚将本应灵活、以价值为导向的开发过程变成了Scrum.org恰当地称为“迭代瀑布(迭代瀑布,即Scrumfall,Scrum.org这样命名它)”的过程,项目强加了固定的时限、范围和预算,几乎没有机会进行检查和调整,(Firlit, 2020)。日历决定了优先级,而不是客户价值的体现。

流水-敏捷开发-瀑布

当敏捷方法遇到企业限制时,就会出现一种变异混合体。Forrester Research 将这种模式称为“瀑布-Scrum-瀑布”(Water-Scrum-Fall),在这种模式下,项目从瀑布式的规划开始,通过Scrum冲刺进行,最后以瀑布式的发布管理结束(福雷斯特研究,2011)。

组织不是出于设计,而是出于自然趋势采取了这种妥协方案。

敏捷采用主要发生在开发团队内部,而“业务分析和发布管理等开发团队无法直接控制的领域仍然遵循传统的做法”。在压力之下,利益相关者和管理者倾向于回归命令和控制的行为模式,而不是接受敏捷的不确定性。2020年Scrum联盟的调查显示了这种倾向:“传统的、预测性的思维方式在大型组织中仍然占主导地位,尤其在执行层面,”通常导致团队在执行预定计划的同时进行敏捷仪式(Firlit, 2020)。仪式变了,心态却依然僵化。

遗留的绩效指标进一步固化了瀑布式思维。许多企业仍然根据按时交付预定义的功能来评估项目成功,而不是衡量实际为客户创造的价值。这种不一致让团队感到认知失调——一项研究显示,37%的受访者承认,尽管声称采用了敏捷方法,但仍感到必须遵守传统流程的压力(Zalavadia, 2015)。

信息变得越来越明确:我们谈论着拥抱变化,但我们实际奖励的是按部就班。

史蒂夫·Blank 用术语“敏捷瀑布”完美地描述了这种现象,指的是那些“试图变得敏捷和精益,但仍然坚持瀑布式开发方法”的组织(Blank, 2019)。团队发现自己陷入最糟糕的两难境地——既要应付敏捷的各种仪式,又要满足瀑布式开发的期望。

空洞的仪式:敏捷的假象

也许最微妙的敏捷失调是纯粹的形式主义实施——业界人士称其为“敏捷表演”。

团队每天举行站立会议。项目经理改名为Scrum大师。工作任务变成了“用户故事”,并在数字看板上进行追踪。然而,这些表面术语背后,工作规划、优先级排序和交付方式在本质上并没有改变。

《Stack》杂志将这一现象描述为“表演性敏捷品牌”的部署……而不对项目管理的根本方式做出任何实质性的改变(The Stack, 2022)。团队则按照既定流程行事,却仍然受困于传统的权力结构和交付期望之中。这营造了一种变革的假象,却没有实质性的改变。

为什么这种戏剧性的方式还在被使用?

组织领导者常常要求进行“敏捷转型”,但却并不真正理解这意味着什么。可见的标志——仪式、看板、调整职位名称——提供了变革的直接证据。而真正的挑战——去中心化的决策制定、适应不确定性、真正授权团队——则需要深层次的文化变革,许多领导者对此却犹豫不决。正如德勤顾问们所观察到的那样:“表演‘敏捷戏剧’固然容易,但真正使其发挥作用却很难”(Celi et al., 2021)。

后果表现在团队士气和工作效率上。“僵尸式Scrum”出现在团队机械地执行仪式而没有与敏捷的目的联系起来时。没有真正的客户反馈来决定优先事项。产品负责人更像是需求记录员而不是价值最大化者。速度成为目标,而真正的目标应该是产生影响(Firlit, 2020)。

缺乏真正的授权和支持,热情慢慢消退,仪式却依然如故——这正完美地体现了形式大于内容的行动。

规模的怪圈

这时,当组织意识到需要协调多个敏捷团队的需求时,许多组织会转向扩展敏捷框架——尤其是被37%的敏捷组织采用的规模化敏捷框架(SAFe)(The Stack,2022)。

更讽刺的是,这些框架往往重新引入了敏捷想要消除的那种官僚主义。

SAFe 引入了多层次的协调(团队、项目、大型解决方案、投资组合层),这可以在新名称下迅速重建传统的层级结构。正如一位从业者在《堆栈》中指出的,SAFe 往往是“自上而下强加的,以层级的方式——这与敏捷的原则相违背”(《堆栈》,2022)。团队发现自己花在管理 SAFe 框架上的时间比为客户创造价值的时间还要多。

汤姆·格拉赫蒂的批评切中要害:“SAFe鼓励自上而下的大规模规划,而不是小规模、迭代的反馈循环……这一点被凸显出来,即SAFe不是真正的敏捷的”(格拉吉蒂,未注明日期。)。尽管如此,SAFe采纳了敏捷的术语,但其实施通常更注重可预测性和协调性,而非自主权和灵活性。

这个框架之所以有吸引力,正因为它为那些对敏捷方法的固有模糊性感到不适应的企业提供了结构上的舒适感。

领导者追求所谓的敏捷好处而不愿放弃控制权。结果变成了“瀑布模型的新标签”——部门改称“价值流”,项目阶段重新命名成“项目增量”,但仍主要由预定的计划驱动,而不是根据客户的实际需求。

操作差距

敏捷开发每次冲刺都会产出可发布的代码。但是当运营团队依然依赖于传统的、风险规避的部署方法时,会发生什么?

代码得等着数周或数月,才能进入部署窗口,而价值则在这期间被搁置。

福雷明确指出了这一模式(2011年):开发团队可能采用Scrum,而发布管理和运维则继续沿用传统方法,完成了“Water-Scrum-Fall”(瀑布部分)中的“瀑布”。这种脱节导致开发速度虽然加快,但交付速度却没有相应提升,从而产生了日益增长的挫败感。

这种DevOps差距体现在手动流程、部门壁垒和断裂的反馈回路中。缺乏自动化测试和部署流水线,操作变成了一个即使采用最敏捷的开发方法也无法克服的瓶颈。当开发和运维作为两个独立部门各自为政,激励机制相互冲突——一个因功能交付而受到奖励,另一个则因系统稳定性而受到奖励——在最需要协作的地方,反而出现了合作障碍。

最具有破坏性的影响是,偶尔的部署延迟了来自实际用户的宝贵反馈。

当这些结果仍停留在理论层面而未被实际观察到时,团队就无法真正根据结果检查和调整。研究证实了这种整合的重要性在于:同时采用敏捷和DevOps方法的组织实现预期成果的可能性比只采用敏捷方法的组织高出一倍(《加速:2019年DevOps状态报告》)。

米制狂

组织衡量敏捷成功的标准或方法反而可能破坏了他们所期望的好处。

速度,最初作为团队容量规划的工具,现在却变成了生产力的衡量标准。故事点数,原本用于相对规模的估算,却常常被误用来作为合同承诺或成本计算的依据。

当管理层将速度作为绩效指标时,团队会像预期那样通过操纵系统来应对。他们要么夸大估算,要么优先处理简单的故事而不是有价值的任务。正如一位敏捷教练警告的那样,“当速度用于容量规划之外的任何用途时,速度就成了最危险的敏捷指标。”Balegar(n.d.)

更根本的是,组织更注重输出指标(如完成的功能和完成的故事点),而不是结果指标(如客户满意度和业务成果)。Scrum.org 发现,那些苦苦挣扎的组织往往过于关注速度、完成的故事点和输出交付,而忽略了交付一个可发布的版本和客户满意度。(Firlit, 2020)

这种度量偏差造成了一个有害的循环。

团队放弃了技术卓越和创新——虽然从单纯的速度上看,它们短期内显得不那么有效率——去追求任意的数字目标。管理层看到速度上升,便认为敏捷方法有效,而技术债务却在累积,客户价值停滞不前,甚至下降。组织优化了能量化的部分,而不是真正重要的部分。

管理层断层:领导空缺

领导层的协同最终决定了企业敏捷转型的成败。

没有来自高层和中层管理的支持,敏捷项目不可避免地会遇到无法克服的组织障碍。由Scrum联盟发布的《商业敏捷报告》指出组织面临的主要挑战是“领导力作为实施敏捷的障碍”(The Stack,2022)。VersionOne的调查同样强调了“管理层支持”的重要性;其缺失与敏捷项目失败密切相关(Zalavadia,2015)。

中层经理最有可能强烈反对敏捷管理变革。

在传统结构中,它们控制工作分配和进度跟踪的责任——而在敏捷环境中,而这些职责则主要由自管理团队承担。这种抵抗源于“对失去工作、权力或控制的恐惧”,正如一位转型教练所指出的(Firlit, 2020)。由于没有提供地位和价值的明确替代角色,管理者自然会抵制威胁其身份的变化。

激励结构往往会与敏捷价值观相冲突。当经理们按时完成预定工作获得奖金时,他们就没有动力去接受变更需求——即使这些变更能更好地满足客户需求。个人绩效评估和强制排名同样破坏团队合作,通过鼓励内部竞争而非共同协作来妨碍团队合作。

正如一位专家简明地说,“敏捷转型常常出问题不是因为团队,而是因为团队周围的组织没有进行相应的变化。”

领导者不仅要推动敏捷,还必须通过他们的行为来体现敏捷的价值观。

固定的协议,变化的需求

企业对外部服务商的依赖给真正的敏捷实施增加了另一个障碍。

传统合同——固定范围、固定价格、固定时间表——从根本上与敏捷拥抱发现和适应的理念相矛盾。当合同规定范围后,团队失去了根据学习情况调整的自由。他们必须交付几个月前已经确定的内容,而不顾在开发过程中发现的新情况。正如Scrum.org的Firlit所指出,‘传统的合同施加了固定的限制,多年期合同尤其难以用敏捷方式进行工作’(Firlit, 2020)。

采购流程也加重了这个问题,因为它们要求在工作开始之前有详细的规格要求。

RFPs通常要求供应商提前承诺交付成果、时间表和成本——从而产生与敏捷不符的文档,在写第一行代码之前就已经如此。供应商通过承诺瀑布式的确定性,同时又宣称敏捷执行,这使项目一开始就充满困惑和失望。

多供应商的情况会让事情变得更复杂。研究发现,对于多组织的敏捷团队来说,当这些成员来自不同公司且每个公司有不同的合同目标时,“团队其实并没有真正成为一个有着共同目标的团队……很多目标不同的‘游戏’正在进行中”(Zalavadia, 2015)。

这削弱了实现敏捷成功所必需的集体所有权。

重拾敏捷承诺:前行之路

企业在采用敏捷方法时常常遭遇失败,因为没有解决这些流程运行的环境问题就改变了流程。

在传统结构、指标、领导方式和合同之上增加Scrum仪式无法实现真正的转型。正如一位受访者坦率地说:“如果你的组织文化不支持敏捷原则和价值观,成功超越孤立试点项目的可能性很小”(Zalavadia, 2015)。

成功应对这些挑战的组织们认识到了一些关键的原则。

  • 文化超越流程: 企业需要从重视可预测性和控制转向拥抱学习和适应的能力。这需要领导层通过示范对不确定性的舒适度,创造让团队敢于实验的心理安全环境。
  • 结构需重新配置: 扁平化层级,打破部门壁垒,从项目资金转向产品资金,所有这些都能真正实现敏捷性。仅仅在僵化结构上叠加敏捷术语的组织最终会感到失望。
  • 技术必须促进流畅: 没有对DevOps能力的投资——如持续集成、自动化测试、部署流水线——敏捷仍然是一种与价值交付脱节的开发方法。
  • 衡量真正重要的: 组织应通过客户成果和业务影响来评估成功,而不是仅依赖速度或产出指标。奖励团队学习和适应,而不是仅仅执行计划,这强化了敏捷的核心优势。
  • 领导承诺必须超越言辞: 高层管理必须将治理、资金、绩效管理和组织设计与敏捷价值观保持一致,而不是期待团队在相互矛盾的期望中摸索前行。

这不符的状况很深,但不是无法解决的。

愿意进行全面变革的组织可以做到同时解决结构、文化和技术难题,调整指标,提升领导力,以及优化外部关系,可以实现敏捷方法所承诺的好处:更快的市场响应,更高产品品质,更积极投入的团队以及真正的顾客导向。

那些不愿进行这些系统性变革的人将继续进行“名义上的敏捷实践”——走过场,却困惑为何在案例研究中看到的转型总是难以触及。

罗兰·汤姆森是法尔科普科技公司的高级产品设计师。他帮助团队设计出既能满足商业目标又能贴近真实用户需求的产品,帮助团队跨越设计、商业策略和技术之间的鸿沟。

参考文献

DevOps现状报告:加速。(2019)

巴勒加尔,P. (日期不详) 在领英上发了一篇关于速度指标的帖子。

Blank, S. (2019年9月5日). 瀑布原则如何悄悄融入敏捷工作流程中。哈佛商业评论。https://hbr.org/2019/09/when-waterfall-principles-sneak-back-into-agile-workflows

Celi, J., Kambil, A., & Mudhar, R. (2021). 敏捷的艺术:构建灵活企业的成功因素 (财务总监观点).

Digital.ai. (2023, 第17届). 敏捷报告。

Firlit, M. (2020年10月18日). 为什么敏捷转型有时会失败。Scrum.org 博客文章。https://www.scrum.org/resources/blog/why-agile-transformations-sometimes-fail

Forre Research (West, D.). (2011). Water-Scrum-Fall 事实上是今天多数组织采用的敏捷方法的实际形态。Forre报告。

Geraghty, T. (未注明日期). 对SAFe的批评——规模化敏捷框架。

The Stack. (2022年2月). 敏捷精神的争夺战:敏捷剧场真的在接管吗?The Stack.

Zalavadia, S. (2015年12月1日). 为什么敏捷在大型企业中会失败。InfoQ.https://www.infoq.com/articles/agile-fails-enterprise/

點擊查看更多內容
TA 點贊

若覺得本文不錯,就分享一下吧!

評論

作者其他優質文章

正在加載中
  • 推薦
  • 評論
  • 收藏
  • 共同學習,寫下你的評論
感謝您的支持,我會繼續努力的~
掃碼打賞,你說多少就多少
贊賞金額會直接到老師賬戶
支付方式
打開微信掃一掃,即可進行掃碼打賞哦
今天注冊有機會得

100積分直接送

付費專欄免費學

大額優惠券免費領

立即參與 放棄機會
微信客服

購課補貼
聯系客服咨詢優惠詳情

幫助反饋 APP下載

慕課網APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網微信公眾號

舉報

0/150
提交
取消