为什么敏捷不适用于大多数 IT 专业人员：你越大，跌倒就越困难

虽然敏捷更加开放和协作的方法无法轻松扩展到更大的组织，但它仍然是带领各种规模的企业走向不确定的未来的最佳选择。

我们距离完全实现备受推崇的敏捷宣言的愿景还有很长的路要走——该宣言概述并鼓励与最终用户密切、非正式地合作以迭代构建软件的实践。这种更加开放和协作的方法只有一个问题——它无法轻松扩展到在全球范围内拥有多个站点、系统和团队的大型组织。

规模问题仍然阻碍着大型或成长型组织。 Digital.ai 最近对 758 名软件专业人士进行的一项调查显示，小型组织获得了巨大的商业利益，而大型组织却不断遇到障碍。

对敏捷感到满意的用户指出了诸如改进协作等好处（60%），而 57% 的用户看到了与业务需求的更好契合，四分之一的用户看到了交付的软件质量更高。

总体而言，虽然超过十分之七的 IT 专业人员（71%）在软件开发中使用敏捷，但只有 11% 的人对结果完全满意，而 33% 的人“有些满意”。 这意味着至少 56% 的人对结果不满意，或者可能不知道结果。

近一半（46%）的人指责公司中“太多混合系统”迫使他们采用混合方法进行软件开发。其他挑战包括孤立的团队和由此导致的延误（37%），而 34% 的人表示文化冲突、团队间使用不一致（30%）以及无法衡量业务价值（28%）。

人工智能正开始融入敏捷活动。在敏捷用户中，近 30% 的人正在积极探索使用大型语言模型 (LLM) 和代码助手来协助开发过程。

敏捷的后代 DevOps 也在讨论之中。两者都旨在提高端到端可见性以及测量周期时间、等待时间和瓶颈的能力。其他正在进行的领域包括在生命周期早期完成的持续测试 (29%)，以及法学硕士 (10%) 和代码辅助 (10%)。

敏捷的许多问题都是由规模造成的——混合的软件开发方法、组织对变革的抵制、领导者之间缺乏理解以及内部孤岛，这些都是大型多部门组织的标志。因此，大多数成功的敏捷实施都是在小公司中进行的。小型组织中的大多数专业人士（52%）认为敏捷是“强大的生产力和组织框架，可以增强协作、提高软件质量并更好地与业务保持一致”。只有 43% 的大公司专业人士同意这一观点。

近四分之三的小公司专业人士 (74%)（大公司的这一比例为 62%）表示，他们的大部分申请都按时且“高质量”交付，此外，71% 的小型组织——相比之下，大公司的这一比例为 53%——“能够完全了解整个软件开发生命周期中正在开发和交付的内容”。

此外，61% 的小公司受访者拥有可以监督整个渠道并衡量业务价值的产品经理，而大公司的这一比例仅为 43%。

这是这项研究开展的第 17 年。如果有人看过 2001 年编写的最初的敏捷宣言（按日期计算），这可能是情有可原的。从头开始埋头编码的情况正在消失。在过去的二十年里，我们看到了云、数字化转型、边缘计算、远程工作、人工智能的兴起，企业领导者更加依赖他们的技术团队来带领他们走向未来。技术和商业之间的界限已经模糊甚至完全消失。技术专业人士已成为商业推动者和推动者，商人也变得更加精通技术，

调查作者表示，敏捷团队领导者被要求做很多事情——“从展示商业价值和实现数字化转型，到整合人工智能和管理分散的劳动力。从人工智能到开发人员倦怠、混合工作环境和无情的需求，变化正在发生此时此刻，每个行业的每个组织都感觉敏捷很难适应。”

尽管如此，敏捷哲学仍然是带领企业进入以技术为主导的不确定未来的最佳选择。 Scrum 仍然是最流行的团队级方法，有 63% 的站点采用。规模化敏捷框架 (SAFe) 仍然是企业级的首选（26%），但 22% 的人表示他们根本不遵循强制的企业框架。

敏捷的好处——改进协作和更好地与业务保持一致——仍然遥不可及。 37% 的受访者提到的一个挑战是业务团队根本不了解敏捷是什么或者它能做什么。另有 27% 的人表示培训不足。该调查的作者报告说：“敏捷从业者与业务之间持续存在脱节，这体现在对组织变革的抵制、领导层之间缺乏理解以及业务方面的培训和支持不足。”