模板
教程
環境
性能
功能
管理
軟件測試之采用敏捷需要面面俱到
關鍵字：敏捷 俱到
兩個月以前，InfoQ曾報道過Jim Shore的那篇廣受歡迎的文章《The Decline and Fall of Agile》，該文指出在日益增長的敏捷社區中有這樣一種傾向，組織只是在名義上采用“敏捷”，而沒有采用如何真正成為敏捷的實踐。InfoQ和Jim博客中的這篇文章，都引來了無數的評論，如果你還沒讀過則很值得一讀。
但是事情還在繼續。敏捷社區領導人比如Martin Fowler、Joshua Kerievsky、Ron Jeffries以及其他人在Shore的基礎上更進一步，紛紛就這一情況發表了自己的看法。
在Flaclearcase/" target="_blank" >ccid Scrum一 文中，Martin Fowler重復了Shore大部分的觀點：許多敏捷實施缺少了極限編程中強調的技術實踐，比如結對編程、持續集成、測試驅動開發。和Shore一 樣，Fowler也承認組織實施敏捷時普遍會優先選擇Scrum，但即使這樣，這也不是Scrum本身的錯。作為補救措施和對大家的提醒，他強調說那些領 導實施Scrum的人需要特別留心，要找機會推動合適的技術實踐：
Scrum社區需要加倍努力，確保大家理解技術實踐的重要性。無論何種類型的項目評審，都要檢查項目中使用了哪些技術實踐。如果你在參與或者接觸這樣的項目，當技術實踐被棄之不管時一定要跳出來。
Fowler發表此文后不久， Industrial Logic和IXP的創建者Joshua Kerievsky就在Yahoo極限編程討論小組中提出這個話題。在他的初帖the Whole Enchilada中，Kerievsky再次提起一個問題，他曾在2006年敏捷大會上提出這個問題并引發熱論，問題的主要內容是“做就全做，并且從一開始就全做?！?/P>
Scrum毫無生氣?敏捷逐漸衰落?
越來越多的證據表明，組織和開發社區需要面面俱到──管理的和技術的敏捷實踐，二者缺一不可。
以我之愚見，“他們會逐漸采用技術實踐”這種想法極其幼稚。大多數情況下，他們根本就不會采用技術實踐，即使采用也是少之又少，就好像根本沒采用一樣。
拿來即用的Scrum對技術實踐毫無提及，就像賣的轎車沒有安全帶以及其它關鍵的安全措施。如果有人愿意告訴你技術實踐也是必須的(雖然他們深信“后期逐漸采用技術實踐”這一想法)，你還算走運，總算知道了什么是正確的Scrum。
極限編程(像本討論組內眾所周知，不僅僅是技術實踐)、Scrum+極限編程、工業極限編程等等，都是面面俱到的例子。
我們一次又一次地發現，一開始就面面俱到的組織和開發社區要好得多，因為隨后他們就會發現自己的敏捷流程缺少了多少東西。
所以我們需要承認好的流程依賴一些關鍵因素，而技術實踐就是軟件開發中最關鍵的因素。把它推遲到敏捷后期實施絕對是一個壞主意。
Kerievsky的帖子引發了激烈的辯論，有大約90篇回帖討論了Joshua建議的價值和適用性，為什么要面面俱到的各種可能原因，以及是否真的有許多組織這么做了。此帖請務必一讀。
在Context, My Foot!文章中，Ron Jeffries同意Shore、Fowler和Kerievsky的觀點，認為多數敏捷實施失敗的本質原因是沒有采用那些必需的實踐：
要想成功，你得先做正確的事情，然后把事情做好。
...
為了正確實施Scrum、極限編程、或者任何形式的敏捷，你必須重構。很抱歉，這不是可選的，而是必須的。
...
極限編程以及其它地方列出了更多的實踐，它們都像重構一樣重要。所以要想成功，你毫無選擇，必須去實施這些實踐。
在重復了“要面面俱到”的觀點之后，后面才是Jeffries這篇文章的真正亮點所在。他解釋了什么才是組織實施敏捷失敗的真正原因：組織本身。直接針對刻意回避真相的事實，Jeffries說道：
極限編程/敏捷/Scrum越來越流行，許多團隊和個人都想這么做，或者想“成為”其一。這直接導致了稱之為“環境相關”的一些敏捷方法。其意思是任何類型的敏捷都“太死板了”，“不適合我們的環境”。所以我們不得不修改敏捷實踐，因為上帝也知道我們沒法修改環境。
親 愛的朋友們，真為你們感到難過。恰恰是你寶貴的環境拖累了你：是中央級別的執行官和高管們不能把職責和權利交給大家;是產品的人總是太忙，以致不能解釋真 正要做什么;是管理設施的人不能創建適合工作的環境;是程序員不愿意學習必須的技術;是經理和產品負責人不斷施壓，直到對項目的質量沒有任何關注。
所以這個討論值得花很大精力關注——敏捷已經到了關鍵時候。專家們仍在繼續討論這一話題，你也應該一起討論，其實我們都得討論。不如就在這里討論吧。
