关键字：敏捷 俱到
两个月以前，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越来越流行，许多团队和个人都想这么做，或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”，“不适合我们的环境”。所以我们不得不修改敏捷实践，因为上帝也知道我们没法修改环境。
亲 爱的朋友们，真为你们感到难过。恰恰是你宝贵的环境拖累了你：是中央级别的执行官和高管们不能把职责和权利交给大家;是产品的人总是太忙，以致不能解释真 正要做什么;是管理设施的人不能创建适合工作的环境;是程序员不愿意学习必须的技术;是经理和产品负责人不断施压，直到对项目的质量没有任何关注。
所以这个讨论值得花很大精力关注——敏捷已经到了关键时候。专家们仍在继续讨论这一话题，你也应该一起讨论，其实我们都得讨论。不如就在这里讨论吧。
文章来源于领测软件测试网 https://www.ltesting.net/