许多编程团队遵循敏捷宣言，这是一套旨在提高质量和用户满意度的软件团队管理原则。其中原则包括：频繁交付价值、保持可持续的工作节奏、保持简单，并定期反思和调整开发实践以提高效率。

前提是开发者、他们服务的用户和业务利益相关者通过合作都能受益。敏捷开发者迭代工作，逐块创建功能软件，并在进入路线图的下一步之前确认结果符合预期。

这种实践在开发社区中变得非常流行。软件开发公司 Digital.ai 1 月发布的敏捷状态调查收集了 788 名技术人员的信息，69%的受访者表示他们的 IT、软件开发和交付团队现在使用敏捷方法。

但很多时候，组织只是在旧的软件开发实践上贴上新标签来假装真正的改变，比如瀑布模型，而敏捷宣言正是最初为了解决瀑布模型的缺陷而产生的。如果他们对敏捷的“调整”不起作用，这些组织就会得出结论，实施敏捷实践是浪费时间。

“敏捷为沟通、协作、迭代和适应的重要性提供了一个有力的视角，”2001 年敏捷宣言发布时 Devise Consulting 的 Elizabeth Bacon 解释道。然而，正如她所指出的，人们在模糊中感到不安。他们的不确定性导致他们想把“真理”钉在墙上。“因此，一些‘最佳实践’变成了‘仪式’，然后这些‘仪式’变成了‘这就是必须的方式’。”

什么是敏捷……以及不是什么

为了追求这些真理，许多公司最终制定了偏离敏捷开发原始目标的政策和实践。这种情况持续的时间越长，就越难纠正。

软件架构师 Michael Richmond 表示，敏捷是关于清晰的沟通、赋予个人行动的权力以及最小化沉没成本，如时间。并且它需要接受任何重要长度的项目在执行过程中都必须处理变化。

敏捷方法可能有其弱点——包括向打算实施和使用它的人传达“什么是敏捷”——但太多公司，对一直以来的方式感到舒适，未能遵循其指导方针。宣言签署人 Ron Jeffries 在 2006 年的一篇文章“我们尝试了棒球但不起作用”中出色地捕捉到了这些问题。

根据敏捷状态调查，47%的调查受访者将敏捷“失败”归咎于对组织变革的普遍抵制或文化冲突。其他因素包括领导参与、管理支持和业务团队对敏捷能做什么或应该做什么的理解失败。

管理层很少知道开发者在做什么，所以他们奖励工作的表象。

结果呢？不遵循敏捷实践的会议、组织不善的冲刺，以及构建应用程序的最终用户被边缘化。

《计算机编程心理学》一书的作者 Gerald M. Weinberg 在 2005 年的一次敏捷会议上表示，管理层很少知道开发者在做什么，“所以他们奖励工作的表象。”

这不是站立会议的工作方式

在遵循敏捷开发过程的公司内部，团队成员每天开会讨论进展、同步正在进行的任务并确定障碍。这个聚会，有时被称为“冲刺”，应该很短，以便参与者可以舒适地站着进行。

然而，大型官僚机构有时会将此解释为，“哦，太好了，又一个会议！”Remove My Mugshot 的首席执行官 Alex Adekola 表示，“站立会议变成了状态会议，重点是向经理报告进展，而不是团队成员之间的协作。”

站立会议可能会变成政治或情感表演。目前在约克大学攻读博士学位的 Shahpour Akhavi 描述了在一家公司的经历，“每日站会是不受控制的抱怨会议，有 20 多人参加。它们毫无意义地持续了几个小时。”

敏捷原则建议团队一次只在一个项目上合作。但在假敏捷中，“冲刺团队”的人在单独但有些相关的项目上工作。

另一个敏捷罪过是，站立会议参与者被期望通过从跟踪系统（如 Atlassian 的 Jira）中读取来分享每日更新。然后，“经理会私下 Slack 你询问交付日期和你在做什么，因为他们很快要和老板开会。这意味着他们在站立会议期间没有得到任何信息，”长期承包商 Pere Villega 说。

冲刺不应该那样工作

高效的敏捷团队在短时间内（通常为两周）进行“冲刺”，在此期间，参与者设定目标，将其分解为通过票证跟踪的功能任务，并自我组织以实现目标。在每个冲刺结束时，团队会反思工作，并确定改进的方法，这被称为“回顾”。

然而，在强调“关闭票证”而不是软件质量的公司中，这个过程会崩溃。在这些公司中，“没有团队，更不用说自治、自我组织的团队了。没有有动力的个人，只有票证处理器，”Industrial Logic 的高级顾问 Tim Ottinger 解释道。

在“假敏捷”公司中看到的另一种行为是采用围绕故事点估计和速度跟踪建立的僵化流程，但未能使用数据推断出任何有意义的东西。在其他敏捷不起作用的地方，开发团队经常将未完成的工作从一个冲刺转移到下一个冲刺，而不评估工作拖延的原因，或者他们放弃正在进行的工作，因为高管一夜之间重新确定了一个功能的优先级。

“任务定义得好吗？成功标准定义得好且合理可实现吗？开发者是否有权标记问题、将工作分解为有意义的块并（找到解决方案？）”Richmond 问道。在敏捷不起作用的公司中，没人知道。

另一个常见的陷阱是票证比软件质量更重要。最糟糕的情况可能是在那些员工根据完成的票数量进行堆栈排名评估的公司。

开发者 Sharon Cochran 在这样一个团队中工作。在每个两周的冲刺结束时，未完成任务的票被标记为完成，而不是延续到下一个冲刺，从而创建了全新的票。“所以，每个冲刺，我们的团队都神奇地有了一个完美的燃尽图，我们总是完成所有的工作。整个系统变得完全没有意义，”她说。

用户，空谈者

敏捷开发应该基于客户反馈进行迭代。每个冲刺都应该添加新功能，以响应“用户故事”，即从最终用户角度编写的高级应用程序需求。例如，一个典型的用户故事可能是“作为电子商务客户，我希望找到我的订单状态，以便我知道我的巧克力何时送达。”

但当产品路线图的输入来自用户社区之外时，这个过程就会失败。一名营销人员可能会指定自己来代表最终用户的担忧，但他们不能代表这些用户发言。一名 IT 高管很少足够了解业务运营的细节来创建现实的用户故事，甚至很少采访用户以了解他们真正想要什么。

团队完成冲刺后，回顾应该促使参与者思考如何改进业务流程或之前冲刺的交付物是否满足要求。根据 Villega 的说法，回顾通常需要一个破冰活动来建立友谊。

然而，在一个功能失调的团队中，这个破冰活动在 40 分钟的会议中占用了 15 分钟。随后是一个代表通用敏捷场景的模板大纲，讨论的重点被塞进了 5 分钟。最后是对团队对共享大纲的评论的背诵。“然后什么都没做[关于任何事情]。下一个冲刺重复，”Villega 回忆道。

关注系统的行为而不是程序员的输出很重要。

这是一个团队未能迭代的迹象。“不是真正的敏捷方法，项目通常以瀑布式布局，其中冲刺只是毫无顾忌地一个接一个执行的项目的小块，”首席工程师 Josh Wickham 说。

做工作的人应该选择谁来做工作，iDIA Computing 的软件开发教练 George Dinwiddie 说。识别假敏捷组织的一种方法是坚持所有团队都应以完全相同的方式工作。

“关注系统的行为而不是程序员的输出，”Dinwiddie 说。当团队通过“符合计划”来衡量进展时，他们经常将工作分配给并行的、独立的团队或个人。“这是这些模块不能很好地协同工作的一个主要原因。”

软件工程顾问 Steve Mosley 提供了一个例子：为数据库任务分配一个用户故事，为编写代码分配另一个故事，但客户只有在两者都交付后才能获得价值。

“人们自然希望关注资源利用率[而不是]流程效率，”Mosley 指出。将工作拆分为后端、前端和基础设施很容易，每个个体都专注于他们孤立的部分。但这意味着只有团队的一个子集参与每个故事的会议讨论。因此，Mosley 建议，工程师得出结论，“Scrum 有太多会议。”

《现代 C++ 编程与测试驱动开发》一书的作者 Jeff Langr 有一张旧照片，显示在一次会议中两到三个人积极参与，可能是项目经理和一两个开发者。“其余的人则不参与，交叉着双臂或靠墙站着，”他说。“他们可能正在关注，‘轮到我时我该说什么？’”

可以做什么？

这些假敏捷实践的最终结果是口惠而实不至，以牺牲原始宣言的原则为代价的仪式，Bacon 说。当你错误地使用某样东西时，它就会失败。她最喜欢的例子：适合大型笨重企业的大型敏捷框架。

为了使敏捷正确，Wickham 建议在组织中基于敏捷实践相对有效的情况进行建设。通常，这涉及团队构建内部工具，如客户支持的管理面板或CI/CD 管道。这些用例对“让我们提出一些东西，征求反馈，迭代，重复”有更多的容忍度，他说。

毕竟，内部客户期望接受最初不完美的东西。“这表明人们理解敏捷，至少对如何使用它有基本的理解，但在涉及外部客户时缺乏使用它的意愿，”Wickham 说。通过花更多时间计划如何交付小块内容，以尽早并经常获得反馈来克服这种态度，他建议。

团队经理可以通过强调“频繁交付价值”和“定期反思和调整你的工作方式以提高效率”等事项来调整日常工作的执行方式，Wickham 说。

“如果高层领导不支持或公开违背敏捷原则并且不会改变他们的想法，就必须有一种‘恶意合规’，在他们不知情的情况下秘密实施敏捷，”Wickham 说。

记住，大多数公司真正关心的是业务成果，而不是流程，Richmond 说。他们只是想要一个关于如何做才能改善对这些成果的执行的食谱。

“敏捷是一个容易被当作‘解决方案’扔来扔去的术语，”Richmond 说。“但有效的敏捷没有一个一刀切的解决方案来改善执行。”要使其正确，需要关注必须发生的事情，以了解公司的挑战、这些挑战如何从业务环境中体现出来、这些挑战如何影响业务成果，最后，确定如何将敏捷概念应用于业务。

但即使有敏捷培训和经验，“如果组织沟通不畅，沟通问题将仍然是成功的障碍，”Richmond 说。“同样，如果组织不信任他们的人，信任问题将仍然存在。如果缺乏沟通和信任，敏捷方法很可能使执行比其他方法更糟。”

最终，敏捷不是关于仪式、冲刺或工具，Richmond 说。敏捷实践很重要，可以帮助构建其使用，但它们不是方法。