敏捷的灵活性：是缺陷还是优势？

“响应变化胜过遵循计划”的原则通常都被很多人认为是敏捷的优势。但是有些人却认为它是一种不切实际的灵活性。他们曾经都见证过那些存在变更管理困难的敏捷项目和抱有过多灵活性期望的用户，最终导致项目延期，质量存在问题并且团队难以交付价值。难道敏捷可以不兑现自己的承诺吗，还是团队和组织采用敏捷的方式不对才导致了这些问题的出现？

在 CIO.com 上的文章《为什么敏捷不起作用》里，Lajos Moczar 谈到，他认为是敏捷的方法论存在缺陷：

敏捷承诺了很多东西，但是实际上理想和现实总是相距甚远。

我断定，敏捷不仅像以前其他那些风靡一时的方法论一样失败，而且实际上，在 IT 界，它使事情变得更加的糟糕了。

他所讨论的缺陷之一就是“开发胜过计划”：

理论上，开发者可以在项目进行的过程中一边编码一边同利益相关者一起进行需求定义，重定义甚至改变需求。但实际上，该方法论并没有区分大变更和小变更。每一次变更都有代价，但是敏捷并没有考虑这些。结果呢？人们经常在项目快结束的时候进行非常大的变更，理由仅仅是因为这是一个敏捷项目，它是可以掌控的。项目能掌控这个变更的唯一方式就是增加迭代周期。这么做以后，那些一度很容易解决的缺陷将变得越来越难以搞定，因为代码库早已物是人非了。

这和传统实践截然不同，如果你有一个基于需求明确定义的项目，并且所有的变更都是在变更管理流程的掌控之下——虽然有时候显得有点呆板，但是最起码时间状态和成本都会变得更加清晰。

Shane Hastie 在他的文章《请别把敏捷和脆弱划等号》的文章中对 Lajos 的文章进行的反驳：

该作者曲解了敏捷宣言，并且对于敏捷实践有点以偏概全，他使用毫无根据的言论来证明他的结论。这篇文章就是我的回答，回应他所提出的观点，终结他所宣传的神话。

针对 Lajos 所提到的“开发胜过计划”的缺陷，他通过解释如何在预定义需求和变更管理的过程中解决遇到的问题来进行了回应。

在当下现实的业务环境中，业务需求是反复无常的。现在业务需求的半衰期大约是六个月，如果你已经确定了需求内容并且需要花费十二个月的时间来实现它，那么等你交付的时候 75% 的需求已经都失效了，而这一切纯碎是时间的流逝造成的。

敏捷通过一种严谨的方式来解决用户的需求，正如 Shane explains 所说，它也并不反对计划：

敏捷并不是用来忽略良好设计原则的借口，也不是不做影响分析就进行大规模改动的理由。敏捷就是在有限的范围内进行不断的改变，并且使人意识到当变更的规模之大以至于会影响到项目的业务价值的时候，我们就需要对这个变更进行评估和估价，而不是一味的反对。

在敏捷宣言里，从来就没有提过可以不需要在起初就对产品的总体架构进行设计，当然，也没有任何一个该领域的知名作者或思想领袖建议大家“像写自由体的诗歌一样”编写代码——任何项目都需要就进行一些预先设计，而在敏捷项目里，我们坚决反对进行预先的大设计，因为我们知道世事是无常的。

Esther Schindler 发表在 ITworld 上的文章《为什么你的用户如此厌恶敏捷开发（而你又该怎么办呢）》谈到了开发者和用户对于敏捷的不同视角。她提到的区别之一就是“你说是迭代，而他们却说是杂乱无章和遥遥无期”：

在敏捷史的早期（…）很多团队将敏捷视为开发团队用来躲避提供评估、文档和计划的借口，今天，这些情况已经好多了，但是我不得不说，这些坏名声潜伏的时间要比我们所预想的要长得多——甚至在开发者社区也是如此。

敏捷团队常常尽量保持灵活性以便满足用户的需求，但往往用户可能对这种灵活性又期望过高了，从而导致团队在持续交付价值的时候举步维艰：

有时候“敏捷就意味着混乱”的心态鼓励着用户和客户把流程理解为“反复无常是正常的”。是的，敏捷的确允许用户甚至能够在大型项目的后期调整优先级。但是开发者 Sorin Costea 却看到了事情顺利进行时其背后所隐藏的负面问题：“这些用户并不相信交付能力也是有上限的。他们并不能真正理解速度和时间的度量标准，但却总是期望可以随时添加新的需求而且能及时得到交付。”而他们的理由就是，“喂，我们很敏捷，不是吗？”

Corbin Norman 发表了一篇《承认敏捷的良好共性：歌颂敏捷的美好，消除它所带来的细微消极面》。他意识到人们有时候会对敏捷产生消极情绪：

敏捷的批评家说这种开发方法论使事情变得越来越糟糕了，因为有些软件人员会承诺一些无法实现的解决方案，并且表现出一种喜欢草率做需求，掩盖开发的真实代价以及妨碍有效管理的习惯。他们的争论最终导致项目周期越拉越长，客户失望，整个 IT 界的效率每况日下。

如今，实施敏捷开发实践的双方依然在争论不休，但是社区还是应该多关注敏捷所带来的好处，而不是那些细微的消极面。

如 Corbin 所说，敏捷所带来的好处之一就是灵活性：

通过敏捷，进度和成本将成为决定性的因素，它将界定出变更的范围以便可以调节那些可行的业务需求…用户的需求。对于成熟的敏捷团队，这种程度的灵活性需要多年一起的合作经验才能培养而成。而在传统的瀑布流模式中，一旦项目在开发进行中是不会允许这种程度的灵活性的，因为它严格遵循着如下原则：一旦某个阶段 / 流程结束了，就无法再回头进行调整了。

查看英文原文： The Flexibility of Agile: Flaw or Strength?

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。