十條敏捷失敗之路

2016-06-23 極客學院 極客weekly

在The Workplace Within這本優秀的著作中，Larry Hirschhorn用很長的篇幅分析了挑戰者號災難。在導致墜毀的許多事件中，讓我們感觸最深的是，NASA的管理層認為，航天飛機的每次成功發射都降低了災難發生的風險。在NASA，許多人都知道，那個導致災難發生的、有缺陷的O型密封圈可能會出故障，但管理層的樂觀情緒隨著一次次發射日益高漲，讓工程師們倍感沮喪和無奈。

敏捷宣言告誡我們，要避免這樣的脫節。在選擇Agile Practitioners 2016大會的主題時，我們希望找出危害組織的癥狀，看一下它們可能如何讓組織偏離敏捷的道路。我們希望突出可以幫助組織避免災難的價值和原則。

本文面向初學者以及那些質疑敏捷實施的敏捷懷疑論者。

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

1）缺少領導支持

管理層必須參與和投入。

在NASA，工程師知道密封圈有缺陷。顯然，不管是他們，還是管理層，都不想看到災難發生。讓我們回歸根本，敏捷宣言告訴我們，“在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。”“必須”一詞是經過慎重選擇的。如果管理層最終代表業務，就意味著他們應該花時間到開發人員中間去工作，感覺就像公司里的一名工程師。參與和投入意味著在同一個戰壕里——拿著項目自己的“O型圈”，了解工程師們正在談論的內容。

在一家獨立的軟件公司，研發部門副總裁引入了一家敏捷顧問公司幫助組織轉型。在最初培訓期間，該副總裁表達了對Scrum概念的懷疑。她不想將自己的觀點強加給團隊，就花時間和工程團隊呆在一起，觀察他們如何工作。她第一次看到，測試人員和程序員如何一起實現每周的增量價值。“我不明白”，她告訴我們，“但每個人，包括客戶，都很高興，像這樣，到了最后，與我無關了。”從那以后，她開始放棄她的命令式風格，這種風格在組織中非常普遍。

2）轉型目的缺失或不明確

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

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

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

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

3）組織結構與角色和敏捷不相容

現有的團隊結構必須不會妨礙“完工”。管理角色必須不會妨礙服務型領導/學習文化。

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

同樣地，強力或高壓領導很可能會導致對領導者的依賴，留給創新和創造力的空間很小。由于我們的行業依賴于創新和創造力，所以我們希望團隊成為它們生長的沃土。團隊角色和任務的多樣性是關鍵。

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

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

4）破“構建”理論

不修復問題釋放了允許質量糟糕的信號。

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

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

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

一個軟件開發團隊不斷地抱怨其他團隊的工作如何導致他們失敗并偏離目標：“當他們改善了他們的工作，我們就可以開始著眼于自己的工作了。”有一天，Scrum管理員（SM）安裝了Jenkins，并借了一塊大屏幕展示構建狀態。

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

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

5）嚴格把關的過程

傳統方法妨礙了任務完成。

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

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

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

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

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

6）培訓不足

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

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

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

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

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

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

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

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

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

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

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

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

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

如果組織的一個部分關注交付速度，另一部分專注質量，即使他們步調一致，結果也不會一致。當相互依賴的團隊努力的方向不一致時，結果就會不一致。

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

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

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

9）缺少足夠的適應性指標

使用虛榮指標會導致失敗。

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

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

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

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

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

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

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

當“技術性的”Scrum意味著“完工”的時候，這是成立的。

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

優秀的Scrum管理員知道那些，并幫助他們的團隊、產品經理和利益相關者實現多方面的改善。

就是說，優秀的Scrum管理員并沒有真正的踐行Scrum。他們是在Scrum環境里操作的敏捷實踐者。

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

接下來做什么？

現在輪到你逆向分析這篇文章了。

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

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

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

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

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

關于作者

Ilan Kirschenbaum——自從擁有了一臺Sinclair ZX81，Ilan就知道他想成為一名程序員——他投入了極大的熱情。一天，他發現自己服務的小公司已經變成了一個過程豐富、文檔饑渴的龐然大物。編程和軟件不再那么有趣。然后他發現了敏捷（確切地說，是敏捷在他工作的地方發現了他）。這個概念讓他回想起來軟件開發可以有多少樂趣。如今，Ilan熱衷于幫助高科技專業人士愛上自己的工作場所，那樣，他們就能幫助他們的客戶愛上他們生產的產品。

Oren Kdoshim是以色列特拉維夫-雅法市政當局的一名高級項目經理。他有超過15年的軟件開發管理、系統分析、項目管理和敏捷實踐（近年來）經驗。Oren有幸福的婚姻，是5個孩子的父親。他還是波斯菜的狂熱愛好者和一名敏銳的自然攝影師。他將外出拍攝罕見的蝴蝶孵化。

本文來源：

http://www.infoq.com/cn/articles/successfully-fail-agility?utm_source=tuicool&utm_medium=referral

作者：Oren Kdoshim and Ilan Kirschenbaum

譯者：謝麗

版權歸原作者所有，本文有改動。

總結

以上是生活随笔為你收集整理的十条敏捷失败之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。