敏捷强制
2006年10月2日
根据敏捷联盟现任董事会的说法，敏捷方法已经“跨越鸿沟”，我认为这意味着它们正变得越来越普遍。虽然这有其优势，但也带来了问题。当一种方法论或设计方法变得流行时，我们就会看到很多人在使用它或教授它，他们关注的是时尚，而不是真正的细节。这可能导致以敏捷的名义做的事情与运动创始人的原则截然相反。
我在网上看到了一些评论，说敏捷方法是被高层管理人员强加给开发团队的。将流程强加于团队完全违背了敏捷软件的原则，而且从一开始就是这样。
对我来说，敏捷方法的一个关键特征是它们是以人为本的。他们认识到人和他们如何协作是软件开发的主要因素，而流程是次要因素。这反映在敏捷宣言的第一个价值观中，即“个体和互动高于流程和工具”，并得到了宣言的两条原则的强化。
- 围绕有积极性的个人构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
- 最佳的架构、需求和设计来自于自组织团队。
这些价值观和原则的一个重要结果是，团队应该选择自己的流程——一个适合他们工作的人员和环境的流程。从外部强加敏捷流程剥夺了团队的自主权，而自主权是敏捷思维的核心。
这种理念在宣言的另一条原则中得到了进一步的体现：“团队定期反思如何变得更有效，然后相应地调整其行为。” 团队不仅应该选择自己的流程，还应该控制该流程的演变方式。
这种使流程适应团队（而不是反过来）的理念是敏捷方法的必要条件，但显然还不够。团队可能会选择一个完全瀑布式的、非敏捷的流程。在这种情况下，很明显，这个过程就像苹果尝起来像草莓一样不敏捷。但敏捷方法并不适用于所有情况，我个人宁愿团队以他们自己选择的非敏捷方式工作，也不愿将我最喜欢的敏捷实践强加给他们。
所以我希望我已经说清楚了，强加敏捷方法是一个非常危险的信号。然而，当我听到它的时候，我通常并没有得到全部的故事。有些情况从外部看起来很相似，但实际上并不相同。
一种情况是学习。引入敏捷方法通常需要一次性学习一大堆新东西，其中许多东西都是反直觉的。极限编程尤其如此。在这种情况下，在你使用一个流程一段时间之前，很难对其进行调整（几年前我写过关于这方面的内容）。在这一点上，团队处于守破离的守阶段，因此需要相当奴隶地遵循这些实践，直到他们掌握了这些实践是如何运作的。在这种情况下，教条主义和不灵活是一种（暂时的）学习工具。
我们在Thoughtworks经常遇到的另一种情况是，我们与客户团队进行合作项目。在大多数情况下，我们负责软件的交付，但我们需要与客户人员合作，以便提供良好的交接，并让客户人员了解我们的工作方式。在这种情况下，我们被支付的报酬是为了尽可能地提高效率，所以我们会使用对我们有效的流程。这并不意味着我们不根据客户的环境调整流程，这始终是必要的，但在合理的调整和放弃让我们成功的实践之间存在一条微妙的界限。
这些情况表明，强加并不像听起来那么简单，但基本点仍然存在——强加敏捷方法会与敏捷方法背后的价值观和原则发生冲突。
这种问题是不可避免的。我清楚地记得有一段时间，面向对象很流行，各种奇怪的事情都是以对象的名义完成的。这都是正常采用过程的一部分。没有什么可以阻止敏捷这个名字被用于非常不敏捷的行为——没有敏捷警察来执行严格的敏捷。我们所能做的就是，我们这些关心的人要不断地解释敏捷的真正含义。我更喜欢解释而不是说服。