两个月以前， InfoQ 曾报道过Jim Shore 的那篇广受欢迎的文章《 The Decline and Fall of Agile 》，该文指出在日益增长的敏捷社区中有这样一种倾向，组织只是在名义上采用“敏捷”，而没有采用如何真正成为敏捷的实践。InfoQ 和 Jim 博客中的这篇文章，都引来了无数的评论，如果你还没读过则很值得一读。
但是事情还在继续。敏捷社区领导人比如 Martin Fowler 、 Joshua Kerievsky 、 Ron Jeffries 以及其他人在 Shore 的基础上更进一步，纷纷就这一情况发表了自己的看法。
在 _ Flaccid Scrum _ 一 文中，Martin Fowler 重复了 Shore 大部分的观点：许多敏捷实施缺少了极限编程中强调的技术实践，比如结对编程、持续集成、测试驱动开发。和 Shore 一 样，Fowler 也承认组织实施敏捷时普遍会优先选择 Scrum，但即使这样，这也不是 Scrum 本身的错。作为补救措施和对大家的提醒，他强调说那些领 导实施 Scrum 的人需要特别留心，要找机会推动合适的技术实践：
Scrum 社区需要加倍努力，确保大家理解技术实践的重要性。无论何种类型的项目评审，都要检查项目中使用了哪些技术实践。如果你在参与或者接触这样的项目，当技术实践被弃之不管时一定要跳出来。
Fowler 发表此文后不久， Industrial Logic 和 IXP 的创建者 Joshua Kerievsky 就在 Yahoo 极限编程讨论小组中提出这个话题。在他的初帖 the Whole Enchilada 中，Kerievsky 再次提起一个问题，他曾在 2006 年敏捷大会上提出这个问题并引发热论，问题的主要内容是“做就全做，并且从一开始就全做。”
Scrum 毫无生气？敏捷逐渐衰落？
越来越多的证据表明，组织和开发社区需要面面俱到──管理的和技术的敏捷实践，二者缺一不可。 以我之愚见，“他们会逐渐采用技术实践”这种想法极其幼稚。大多数情况下，他们根本就不会采用技术实践，即使采用也是少之又少，就好像根本没采用一样。拿来即用的 Scrum 对技术实践毫无提及，就像卖的轿车没有安全带以及其它关键的安全措施。如果有人愿意告诉你技术实践也是必须的（虽然他们深信“后期逐渐采用技术实践”这一想法），你还算走运，总算知道了什么是正确的 Scrum。
极限编程（像本讨论组内众所周知，不仅仅是技术实践）、Scrum+ 极限编程、工业极限编程等等，都是面面俱到的例子。
我们一次又一次地发现，一开始就面面俱到的组织和开发社区要好得多，因为随后他们就会发现自己的敏捷流程缺少了多少东西。
所以我们需要承认好的流程依赖一些关键因素，而技术实践就是软件开发中最关键的因素。把它推迟到敏捷后期实施绝对是一个坏主意。
Kerievsky 的帖子引发了激烈的辩论，有大约 90 篇回帖讨论了 Joshua 建议的价值和适用性，为什么要面面俱到的各种可能原因，以及是否真的有许多组织这么做了。此帖请务必一读。
在 _ Context, My Foot! _ 文章中，Ron Jeffries 同意 Shore、Fowler 和 Kerievsky 的观点，认为多数敏捷实施失败的本质原因是没有采用那些必需的实践：
要想成功，你得先做正确的事情，然后把事情做好。
…
为了正确实施 Scrum、极限编程、或者任何形式的敏捷，你必须重构。很抱歉，这不是可选的，而是必须的。
…
极限编程以及其它地方列出了更多的实践，它们都像重构一样重要。所以要想成功，你毫无选择，必须去实施这些实践。
在重复了“要面面俱到”的观点之后，后面才是 Jeffries 这篇文章的真正亮点所在。他解释了什么才是组织实施敏捷失败的真正原因：组织本身。直接针对刻意回避真相的事实，Jeffries 说道：
极限编程 / 敏捷 /Scrum 越来越流行，许多团队和个人都想这么做，或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”，“不适合我们的环境”。所以我们不得不修改敏捷实践，因为上帝也知道我们没法修改环境。 亲 爱的朋友们，真为你们感到难过。恰恰是你宝贵的环境拖累了你：是中央级别的执行官和高管们不能把职责和权利交给大家；是产品的人总是太忙，以致不能解释真 正要做什么；是管理设施的人不能创建适合工作的环境；是程序员不愿意学习必须的技术；是经理和产品负责人不断施压，直到对项目的质量没有任何关注。
所以这个讨论值得花很大精力关注——敏捷已经到了关键时候。专家们仍在继续讨论这一话题，你也应该一起讨论，其实我们都得讨论。不如就在这里讨论吧。
查看英文原文： Adopting The Whole Enchilada
评论