本文面向初學(xué)者以及那些質(zhì)疑敏捷實施的敏捷懷疑論者。

本文提出了10條敏捷開發(fā)失敗之路，旨在說明采用相反的做法可以提高敏捷性和成功幾率。

1）缺少領(lǐng)導(dǎo)支持

管理層必須參與和投入。

在NASA，工程師知道密封圈有缺陷。顯然，不管是他們，還是管理層，都不想看到災(zāi)難發(fā)生。讓我們回歸根本，敏捷宣言告訴我們，“在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作?！薄氨仨殹币辉~是經(jīng)過慎重選擇的。如果管理層最終代表業(yè)務(wù)，就意味著他們應(yīng)該花時間到開發(fā)人員中間去工作，感覺就像公司里的一名工程師。參與和投入意味著在同一個戰(zhàn)壕里——拿著項目自己的“O型圈”，了解工程師們正在談?wù)摰膬?nèi)容。

在一家獨立的軟件公司，研發(fā)部門副總裁引入了一家敏捷顧問公司幫助組織轉(zhuǎn)型。在最初培訓(xùn)期間，該副總裁表達了對Scrum概念的懷疑。她不想將自己的觀點強加給團隊，就花時間和工程團隊呆在一起，觀察他們?nèi)绾喂ぷ?。她第一次看到，測試人員和程序員如何一起實現(xiàn)每周的增量價值?！拔也幻靼住?，她告訴我們，“但每個人，包括客戶，都很高興，像這樣，到了最后，與我無關(guān)了?！睆哪且院螅_始放棄她的命令式風(fēng)格，這種風(fēng)格在組織中非常普遍。

2）轉(zhuǎn)型目的缺失或不明確

企業(yè)必須明確希望從敏捷得到什么。

“變得敏捷（Becoming agile）”是一項艱苦的工作。它需要不斷地實踐，打破舊習(xí)慣，采用新思維，這僅僅是其中的部分挑戰(zhàn)。它意味著組織需要投入大量的精力調(diào)整文化。

如果你連正在努力解決的問題都不清楚，那么就需要更多的精力來保持動力。首先定義好你希望從敏捷得到什么，并不斷地改進那些目標。還有，是的——每個人都那樣做并不足以成為采用敏捷的理由。你必須眼睛盯著自己的問題，弄清楚為什么希望作出改變。

在大型企業(yè)中，最高管理層選擇敏捷是為了縮短上市時間、改進質(zhì)量、加強溝通以及更好地適應(yīng)變化。但管理層并沒有給這些目標指定一個優(yōu)先級，TTM和質(zhì)量相互矛盾，會妨礙溝通改善。由于變革目標不條理，一段時間之后，這四個目標就被人們完全遺忘了。

3）組織結(jié)構(gòu)與角色和敏捷不相容

現(xiàn)有的團隊結(jié)構(gòu)必須不會妨礙“完工”。管理角色必須不會妨礙服務(wù)型領(lǐng)導(dǎo)/學(xué)習(xí)文化。

敏捷宣言告訴我們，“最好的架構(gòu)、需求和設(shè)計出自于自組織的團隊?！边^分依賴其他團隊的團隊無法實現(xiàn)自組織——例如，如果開發(fā)團隊依賴于測試團隊來推動工作“完工”，那么該團隊可能會表現(xiàn)出對他人無益的行為，如歸咎文化或冷漠。

同樣地，強力或高壓領(lǐng)導(dǎo)很可能會導(dǎo)致對領(lǐng)導(dǎo)者的依賴，留給創(chuàng)新和創(chuàng)造力的空間很小。由于我們的行業(yè)依賴于創(chuàng)新和創(chuàng)造力，所以我們希望團隊成為它們生長的沃土。團隊角色和任務(wù)的多樣性是關(guān)鍵。

根據(jù)你希望創(chuàng)造的價值建立組織結(jié)構(gòu)，這樣，人們就可以更獨立地工作，減少對管理人員的依賴——反過來，管理人員可以幫助那些人提高。

一個大型的政府組織在他們的軟件研發(fā)部門實施Scrum。軟件QA、BI和DBA分屬不同的部門。每當(dāng)研發(fā)團隊需要其他部門的支持，研發(fā)團隊負責(zé)人就不得不接洽其他部門的負責(zé)人，請求他們騰出時間。研發(fā)團隊的成員覺得，他們必須尊重其他非敏捷團隊，這讓他們覺得被推入了一種瀑布式文化。

4）破“構(gòu)建”理論

不修復(fù)問題釋放了允許質(zhì)量糟糕的信號。

上世紀80年代的 破窗理論 指出，忽視像破壞公物這樣的小罪會向人們釋放更嚴重的犯罪也會被忽視的信號。后來，紐約市市長Rudy Giuliani采納了這種方法，應(yīng)對輕微犯罪。被破壞公物的人打碎的窗戶會及時得到修復(fù)。警察接受訓(xùn)練，對付罪犯，幫助社區(qū)處理輕微犯罪行為，而不是忽視它們。結(jié)果難以置信。紐約市臭名昭著的危險區(qū)域成了最安全的區(qū)域之一。雖然有人批評這一研究不科學(xué)，但這種方法在其他城市也得到了成功應(yīng)用。

類似地，對于軟件組織而言，這幾乎是不言而喻的：如果你忽視了有問題的構(gòu)建，如Bug或者拼寫錯誤，那么你就釋放出了可以不編寫單元測試、不重構(gòu)，或者不按照需求開發(fā)的信號。標準就是這樣形成的。

另一種選擇？不要厭煩查找問題原因，確保問題得到修復(fù)。成為你希望達到的標準的榜樣，并贊揚那些追隨你的步伐的人。其他人也會這樣做。

一個軟件開發(fā)團隊不斷地抱怨其他團隊的工作如何導(dǎo)致他們失敗并偏離目標：“當(dāng)他們改善了他們的工作，我們就可以開始著眼于自己的工作了?！庇幸惶?，Scrum管理員（SM）安裝了Jenkins，并借了一塊大屏幕展示構(gòu)建狀態(tài)。

第二天，構(gòu)建變紅了。SM和一名工程師開始調(diào)查原因，不到一個小時，他們就在另一個團隊的代碼中發(fā)現(xiàn)了Bug。不到三個小時，Bug就修復(fù)了，在安裝Jenkins之前，這可能需要數(shù)周。

幾周之后，SM開始試驗JUnit。等那一完成，他試驗了RESTful API自動化（此前僅僅是測試人員的職責(zé)）。逐步地，這個團隊的成員不斷打破界限，修復(fù)他們的破窗，增強他們的敬業(yè)精神。沮喪日益成為一種偶然，而不是一種心態(tài)。

5）嚴格把關(guān)的過程

傳統(tǒng)方法妨礙了任務(wù)完成。

這一條要追溯到17世紀或者更早的時候?！?nbsp;我思故我在 ”是笛卡爾二元論的一個來源，該理論認為，精神和肉體是分離的；你要么想，要么做。19世紀末，科學(xué)管理之父Frederick Taylor將笛卡爾的觀點解釋為，思考和計劃應(yīng)該從體力勞動中分離出來。在軟件開發(fā)中，這些觀點告訴你，你要么考慮設(shè)計、編碼和測試，要么就做——但不能同時。你應(yīng)該計劃如何以及何時做每一件事。這并不是真正的敏捷。

敏捷宣言指出，“敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度”——不是一個階段接一個階段，而是一直。

“僵化的關(guān)口（Rigid gates）”，如市場（MRR）、需求（BRR）、測試（TRR）等，支持項目不同層面的“完工”。這里，敏捷與傳統(tǒng)存在沖突，有時候還很嚴重。

由于傳統(tǒng)通常不容易改變，所以只能一次處理一個關(guān)口。通往敏捷失敗的第一條路是缺少領(lǐng)導(dǎo)支持，因此，組織領(lǐng)導(dǎo)必須參與并投入消除無用的關(guān)口，一次一個。

政府組織已經(jīng)使用包含需求、分析、實現(xiàn)、測試和GA關(guān)口的關(guān)口系統(tǒng)很長時間了。軟件研發(fā)團隊已經(jīng)在他們的流程中實現(xiàn)了Scrum，并在每個沖刺中交付可以工作的軟件。但團隊仍然需要和測試沖刺同步，在通過公司約定的審批關(guān)口之前，不能正式發(fā)布。

6）培訓(xùn)不足

有時候，公司希望一次培訓(xùn)就讓所有人都知道如何實施敏捷。

比如你希望完成一次馬拉松。那需要能夠跑完42.2公里。假如你不是一名正式的運動員。你是從零起步。經(jīng)過一個為期三天的速成課程培訓(xùn)后，你能做好跑馬拉松的準備嗎？你怎么可能在那三天里學(xué)習(xí)到所有可能的問題和情況呢？

從非敏捷到敏捷參與者的情況類似。在為期兩天的課程里變成一名專家的可能性幾乎為零。你必須投入更多的精力和資源來提高敏捷性。

“我們只有一次機會，預(yù)算就那么多，因此，我們能做的事情并不多?！边@句話描述了一場面向多個團隊的初步培訓(xùn)會議的背景，這些團隊正著手開始他們的Scrum之旅。管理層決定舉辦一場為期一天的會議來教授Scrum，由發(fā)起敏捷并了解Scrum的常務(wù)副總授課。先不說人們在理解Scrum的作用、儀式和人工制品方面存在差異，實際上，每個人都將Scrum視為另外一種項目管理技術(shù)，并不理解諸如自組織這樣的概念以及迭代工作的實證方法。通過努力，只有兩三個團隊開始過渡到敏捷思維，但對于大多數(shù)團隊而言，敏捷仍然只是微觀管理的一種新方法。

7）“敏捷只為圣誕節(jié)”的實施方法

敏捷不僅僅是待辦事項清單上的另一個項目。變得敏捷是一次旅行，不是一個一次性的項目，也不僅僅是另外一次實踐學(xué)習(xí)。

相當(dāng)直白地講，對于許多組織而言，變得敏捷意味著改變運營系統(tǒng)。是的，“達成敏捷（being agile）”意味著采用新的運營方法，但更重要的變化是理念。許多組織的運營都遵循泰勒學(xué)派或笛卡爾的理念：管理層負責(zé)結(jié)果；其他員工負責(zé)執(zhí)行。

讓敏捷被接受需要自律和毅力。可能需要花費數(shù)年的時間才能達到組織可以號稱自己敏捷的轉(zhuǎn)折點——并不是說那時你就可以停止那樣的工作方式。到那時，你們甚至不會再考慮其他的可選方案。你們已經(jīng)調(diào)整了文化。

有家大型的國際化企業(yè)踏上了敏捷之旅。工作現(xiàn)場會有一名教練，幫助團隊和管理人員應(yīng)對他們每天的挑戰(zhàn)，并根據(jù)他們的成長和興趣逐步實行Scrum。在這個過程進行到大約兩個月的時候，一些痛苦的問題開始浮現(xiàn)：例如程序員不想測試，座位安排妨礙了有效工作，團隊責(zé)備其他團隊。接著，預(yù)算用完了。留給公司的是殘缺的Scrum和很多的失望。六個月之后，人們開始自己組織學(xué)習(xí)敏捷，這次沒有現(xiàn)場支持，為了獲得期望的結(jié)果，他們更加努力。

8）與兄弟部門目標不一致

所有參與的部門必須遵循同樣的游戲規(guī)則。

在物理學(xué)中，當(dāng)波形產(chǎn)生一個恒定的相位差時，波源就是相干的。當(dāng)波源的頻率或方向不同，或者兩者都不一致時，它們不相干。在音樂方面，我們立即就可以知道我們聽到的聲音是否協(xié)調(diào)——可能只是聽錯了。

對于組織團隊而言，亦是如此。

如果組織的一個部分關(guān)注交付速度，另一部分專注質(zhì)量，即使他們步調(diào)一致，結(jié)果也不會一致。當(dāng)相互依賴的團隊努力的方向不一致時，結(jié)果就會不一致。

成功的團隊會統(tǒng)一他們的時間表、目標和宗旨。

譬如，那不是說所有的團隊都要統(tǒng)一他們的工作程序。只有當(dāng)兄弟部門需要統(tǒng)一他們的價值、標準和成功定義時，才需要進行這種調(diào)整。如果那讓你想起了領(lǐng)導(dǎo)支持，說明你逐步理解敏捷了！

兩個從事同一款產(chǎn)品開發(fā)的部門已經(jīng)在他們的工作流程中實現(xiàn)了Scrum。一個部門正在開發(fā)提供產(chǎn)品KPI的度量工具。他們關(guān)注度量質(zhì)量。另一個部門正在增加新的產(chǎn)品特性。他們關(guān)注特性交付速度。兩個部門互相依賴：提供KPI需要調(diào)用產(chǎn)品特性的API；沒有KPI，新特性就沒有“完工”。兩個部門都對自己的敏捷實施以及敏捷對他們實現(xiàn)價值的助益感到滿意。但也只有當(dāng)兩個部門在一兩個沖刺中試驗性地交換了專家，這兩個部門才真的彌補了他們之間的差距，制定出了包含對方需求的“完工定義”。

9）缺少足夠的適應(yīng)性指標

使用虛榮指標會導(dǎo)致失敗。

敏捷宣言的第七條“可工作的軟件是首要的進度度量標準，”因此，不管你選擇了什么指標，都應(yīng)該能夠度量工作如何對功能性產(chǎn)品有所貢獻。

打開或關(guān)閉的缺陷數(shù)量、速度、速度趨勢、“承諾-完工比（committed-versus-done ratio）”，諸如這些指標都可以度量貢獻，但并不適應(yīng)于一個可工作的產(chǎn)品。

The Organisation Within一書的作者的Larry Hirschhorn將這種指標稱為“偶像”。它們或許可以代表實情，但基本上沒有。

相反，客戶滿意度、員工幸福感或者媒體報道可能是更好的指標。

不過，按照Mark Twain的說法，指標和尿不濕一樣，應(yīng)該經(jīng)常換。每個指標都可能失效，因為人們會根據(jù)你度量他們的方式行事。因此，不要試圖尋找一個可以裁定所有人的指標。你度量的東西應(yīng)該和產(chǎn)品及團隊的成熟度有關(guān)，而且你應(yīng)該盡可能經(jīng)常地替換它。

一家大型企業(yè)利用一系列工具來幫助敏捷實施，并且自己在上層構(gòu)建了一個報表工具。該工具已經(jīng)逐步發(fā)展成為一個BI平臺，可以隨意處理各種數(shù)據(jù)：速度、連續(xù)運轉(zhuǎn)效率、WIP隨時間的變化（即CFD）、承諾準確性，等等。于是，一種新的文化形成了：臨近每個季度末的時候，項目經(jīng)理花費幾天時間，進行周密地過濾，把最好的報表展示給利益相關(guān)者。不管車間里實際上發(fā)生了什么，只要報表看上去好看。

10）“將Scrum和敏捷等量齊觀”的實施方法

當(dāng)“技術(shù)性的”Scrum意味著“完工”的時候，這是成立的。

敏捷的范疇比Scrum要大得多。Scrum是最流行的開發(fā)周期框架，只處理一個方面：一個或多個團隊接受一個需求積壓列表，并用一個較短的反饋循環(huán)完成它們。Scrum本身并不涉及工程卓越、總體目標、擴展（ LeSS 使用Scrum優(yōu)雅地處理了擴展）或者長期規(guī)劃，等等。

優(yōu)秀的Scrum管理員知道那些，并幫助他們的團隊、產(chǎn)品經(jīng)理和利益相關(guān)者實現(xiàn)多方面的改善。

就是說，優(yōu)秀的Scrum管理員并沒有真正的踐行Scrum。他們是在Scrum環(huán)境里操作的敏捷實踐者。

一個中型組織希望實施Scrum。一場組織分析澄清了這個過程：從改善工程實踐入手，因為組織第一個可能遇到的問題會和代碼有關(guān)。盡管出現(xiàn)了發(fā)布過程痛苦冗長、怪罪文化盛行等癥狀，但在接下來的多次會議中，組織領(lǐng)導(dǎo)者還是堅持繼續(xù)推進Scrum。這段旅程使得團隊成員之間的關(guān)系不斷惡化，直到組織完全放棄了Scrum。

接下來做什么？

現(xiàn)在輪到你逆向分析這篇文章了。

這篇文章不是要讓你放棄敏捷之旅。

相反，它是要讓你堅持下去。

如果你發(fā)現(xiàn)自己陷入了這里提到的一個或多個反模式，那么問下自己，你可以做點什么來改變它。你可以做點什么不同的事情，以一種你可以操作的方式，變得更加敏捷呢？哪里是你忽略了的O型圈，什么反模式促成了它，如何擺脫它？

一家大型企業(yè)在他們其中一個研發(fā)部門實施了Scrum和看板。接下來，產(chǎn)品經(jīng)理和團隊之間的關(guān)系變得緊張，組織引入了一家外部供應(yīng)商就團隊工作協(xié)議組織召開一場研討會。雖然預(yù)備會議表明團隊層面存在一些挑戰(zhàn)，但更大的挑戰(zhàn)來自領(lǐng)導(dǎo)者。例如，雖然管理者相信敏捷，但他們沒有為團隊工作樹立好榜樣。

團隊研討會被一場管理團隊組建會議所取代。研討會的結(jié)果是一份待變革事項列表：正式確定部門的目的和價值；澄清管理團隊成員的角色；定義并擁有標準，尤其是對于外部依賴，等等。通過設(shè)置自己的變革看板及承認運轉(zhuǎn)問題，管理層開始消除導(dǎo)致敏捷失敗的方式，并代之以漸進的步驟，為敏捷團隊樹立一個榜樣。

 

 

文章來自： InfoQ