敏捷宣言告誡我們，要避免這樣的脫節(jié)。在選擇Agile Practitioners2016大會(huì)的主題時(shí)，我們希望找出危害組織的癥狀，看一下它們可能如何讓組織偏離敏捷的道路。我們希望突出可以幫助組織避免災(zāi)難的價(jià)值和原則。
本文面向初學(xué)者以及那些質(zhì)疑敏捷實(shí)施的敏捷懷疑論者。
本文提出了10條敏捷失敗之路，旨在說明采用相反的做法可以提高敏捷性和成功幾率。
1）缺少領(lǐng)導(dǎo)支持
管理層必須參與和投入。
在NASA，工程師知道密封圈有缺陷。顯然，不管是他們，還是管理層，都不想看到災(zāi)難發(fā)生。讓我們回歸根本，敏捷宣言告訴我們，“在整個(gè)項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。”“必須”一詞是經(jīng)過慎重選擇的。如果管理層最終代表業(yè)務(wù)，就意味著他們應(yīng)該花時(shí)間到開發(fā)人員中間去工作，感覺就像公司里的一名工程師。參與和投入意味著在同一個(gè)戰(zhàn)壕里——拿著項(xiàng)目自己的“O型圈”，了解工程師們正在談?wù)摰膬?nèi)容。
在一家獨(dú)立的軟件公司，研發(fā)部門副總裁引入了一家敏捷顧問公司幫助組織轉(zhuǎn)型。在最初培訓(xùn)期間，該副總裁表達(dá)了對(duì)Scrum概念的懷疑。她不想將自己的觀點(diǎn)強(qiáng)加給團(tuán)隊(duì)，就花時(shí)間和工程團(tuán)隊(duì)呆在一起，觀察他們?nèi)绾喂ぷ鳌Ｋ谝淮慰吹?，測(cè)試人員和程序員如何一起實(shí)現(xiàn)每周的增量?jī)r(jià)值。“我不明白”，她告訴我們，“但每個(gè)人，包括客戶，都很高興，像這樣，到了最后，與我無關(guān)了。”從那以后，她開始放棄她的命令式風(fēng)格，這種風(fēng)格在組織中非常普遍。
企業(yè)必須明確希望從敏捷得到什么。
“變得敏捷（Becomingagile）”是一項(xiàng)艱苦的工作。它需要不斷地實(shí)踐，打破舊習(xí)慣，采用新思維，這僅僅是其中的部分挑戰(zhàn)。它意味著組織需要投入大量的精力調(diào)整文化。
如果你連正在努力解決的問題都不清楚，那么就需要更多的精力來保持動(dòng)力。首先定義好你希望從敏捷得到什么，并不斷地改進(jìn)那些目標(biāo)。還有，是的——每個(gè)人都那樣做并不足以成為采用敏捷的理由。你必須眼睛盯著自己的問題，弄清楚為什么希望作出改變。
在大型企業(yè)中，最高管理層選擇敏捷是為了縮短上市時(shí)間、改進(jìn)質(zhì)量、加強(qiáng)溝通以及更好地適應(yīng)變化。但管理層并沒有給這些目標(biāo)指定一個(gè)優(yōu)先級(jí)，TTM和質(zhì)量相互矛盾，會(huì)妨礙溝通改善。由于變革目標(biāo)不條理，一段時(shí)間之后，這四個(gè)目標(biāo)就被人們完全遺忘了。
3）組織結(jié)構(gòu)與角色和敏捷不相容
現(xiàn)有的團(tuán)隊(duì)結(jié)構(gòu)必須不會(huì)妨礙“完工”。管理角色必須不會(huì)妨礙服務(wù)型領(lǐng)導(dǎo)/學(xué)習(xí)文化。
敏捷宣言告訴我們，“最好的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。”過分依賴其他團(tuán)隊(duì)的團(tuán)隊(duì)無法實(shí)現(xiàn)自組織——例如，如果開發(fā)團(tuán)隊(duì)依賴于測(cè)試團(tuán)隊(duì)來推動(dòng)工作“完工”，那么該團(tuán)隊(duì)可能會(huì)表現(xiàn)出對(duì)他人無益的行為，如歸咎文化或冷漠。
同樣地，強(qiáng)力或高壓領(lǐng)導(dǎo)很可能會(huì)導(dǎo)致對(duì)領(lǐng)導(dǎo)者的依賴，留給創(chuàng)新和創(chuàng)造力的空間很小。由于我們的行業(yè)依賴于創(chuàng)新和創(chuàng)造力，所以我們希望團(tuán)隊(duì)成為它們生長(zhǎng)的沃土。團(tuán)隊(duì)角色和任務(wù)的多樣性是關(guān)鍵。
根據(jù)你希望創(chuàng)造的價(jià)值建立組織結(jié)構(gòu)，這樣，人們就可以更獨(dú)立地工作，減少對(duì)管理人員的依賴——反過來，管理人員可以幫助那些人提高。
一個(gè)大型的政府組織在他們的軟件研發(fā)部門實(shí)施Scrum。軟件QA、BI和DBA分屬不同的部門。每當(dāng)研發(fā)團(tuán)隊(duì)需要其他部門的支持，研發(fā)團(tuán)隊(duì)負(fù)責(zé)人就不得不接洽其他部門的負(fù)責(zé)人，請(qǐng)求他們騰出時(shí)間。研發(fā)團(tuán)隊(duì)的成員覺得，他們必須尊重其他非敏捷團(tuán)隊(duì)，這讓他們覺得被推入了一種瀑布式文化。
不修復(fù)問題釋放了允許質(zhì)量糟糕的信號(hào)。
上世紀(jì)80年代的破窗理論指出，忽視像破壞公物這樣的小罪會(huì)向人們釋放更嚴(yán)重的犯罪也會(huì)被忽視的信號(hào)。后來，紐約市市長(zhǎng)RudyGiuliani采納了這種方法，應(yīng)對(duì)輕微犯罪。被破壞公物的人打碎的窗戶會(huì)及時(shí)得到修復(fù)。警察接受訓(xùn)練，對(duì)付罪犯，幫助社區(qū)處理輕微犯罪行為，而不是忽視它們。結(jié)果難以置信。紐約市臭名昭著的危險(xiǎn)區(qū)域成了最安全的區(qū)域之一。雖然有人批評(píng)這一研究不科學(xué)，但這種方法在其他城市也得到了成功應(yīng)用。
類似地，對(duì)于軟件組織而言，這幾乎是不言而喻的：如果你忽視了有問題的構(gòu)建，如Bug或者拼寫錯(cuò)誤，那么你就釋放出了可以不編寫單元測(cè)試、不重構(gòu)，或者不按照需求開發(fā)的信號(hào)。標(biāo)準(zhǔn)就是這樣形成的。
另一種選擇？不要厭煩查找問題原因，確保問題得到修復(fù)。成為你希望達(dá)到的標(biāo)準(zhǔn)的榜樣，并贊揚(yáng)那些追隨你的步伐的人。其他人也會(huì)這樣做。
一個(gè)軟件開發(fā)團(tuán)隊(duì)不斷地抱怨其他團(tuán)隊(duì)的工作如何導(dǎo)致他們失敗并偏離目標(biāo)：“當(dāng)他們改善了他們的工作，我們就可以開始著眼于自己的工作了。”有一天，Scrum管理員（SM）安裝了Jenkins，并借了一塊大屏幕展示構(gòu)建狀態(tài)。
第二天，構(gòu)建變紅了。SM和一名工程師開始調(diào)查原因，不到一個(gè)小時(shí)，他們就在另一個(gè)團(tuán)隊(duì)的代碼中發(fā)現(xiàn)了Bug。不到三個(gè)小時(shí)，Bug就修復(fù)了，在安裝Jenkins之前，這可能需要數(shù)周。
幾周之后，SM開始試驗(yàn)JUnit。等那一完成，他試驗(yàn)了RESTfulAPI自動(dòng)化（此前僅僅是測(cè)試人員的職責(zé)）。逐步地，這個(gè)團(tuán)隊(duì)的成員不斷打破界限，修復(fù)他們的破窗，增強(qiáng)他們的敬業(yè)精神。沮喪日益成為一種偶然，而不是一種心態(tài)。
傳統(tǒng)方法妨礙了任務(wù)完成。
這一條要追溯到17世紀(jì)或者更早的時(shí)候。“我思故我在”是笛卡爾二元論的一個(gè)來源，該理論認(rèn)為，精神和肉體是分離的；你要么想，要么做。19世紀(jì)末，科學(xué)管理之父FrederickTaylor將笛卡爾的觀點(diǎn)解釋為，思考和計(jì)劃應(yīng)該從體力勞動(dòng)中分離出來。在軟件開發(fā)中，這些觀點(diǎn)告訴你，你要么考慮設(shè)計(jì)、編碼和測(cè)試，要么就做——但不能同時(shí)。你應(yīng)該計(jì)劃如何以及何時(shí)做每一件事。這并不是真正的敏捷。
敏捷宣言指出，“敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開發(fā)速度”——不是一個(gè)階段接一個(gè)階段，而是一直。
“僵化的關(guān)口（Rigidgates）”，如市場(chǎng)（MRR）、需求（BRR）、測(cè)試（TRR）等，支持項(xiàng)目不同層面的“完工”。這里，敏捷與傳統(tǒng)存在沖突，有時(shí)候還很嚴(yán)重。
由于傳統(tǒng)通常不容易改變，所以只能一次處理一個(gè)關(guān)口。通往敏捷失敗的第一條路是缺少領(lǐng)導(dǎo)支持，因此，組織領(lǐng)導(dǎo)必須參與并投入消除無用的關(guān)口，一次一個(gè)。
政府組織已經(jīng)使用包含需求、分析、實(shí)現(xiàn)、測(cè)試和GA關(guān)口的關(guān)口系統(tǒng)很長(zhǎng)時(shí)間了。軟件研發(fā)團(tuán)隊(duì)已經(jīng)在他們的流程中實(shí)現(xiàn)了Scrum，并在每個(gè)沖刺中交付可以工作的軟件。但團(tuán)隊(duì)仍然需要和測(cè)試沖刺同步，在通過公司約定的審批關(guān)口之前，不能正式發(fā)布。
有時(shí)候，公司希望一次培訓(xùn)就讓所有人都知道如何實(shí)施敏捷。
比如你希望完成一次馬拉松。那需要能夠跑完42.2公里。假如你不是一名正式的運(yùn)動(dòng)員。你是從零起步。經(jīng)過一個(gè)為期三天的速成課程培訓(xùn)后，你能做好跑馬拉松的準(zhǔn)備嗎？你怎么可能在那三天里學(xué)習(xí)到所有可能的問題和情況呢？
從非敏捷到敏捷參與者的情況類似。在為期兩天的課程里變成一名專家的可能性幾乎為零。你必須投入更多的精力和資源來提高敏捷性。
“我們只有一次機(jī)會(huì)，預(yù)算就那么多，因此，我們能做的事情并不多。”這句話描述了一場(chǎng)面向多個(gè)團(tuán)隊(duì)的初步培訓(xùn)會(huì)議的背景，這些團(tuán)隊(duì)正著手開始他們的Scrum之旅。管理層決定舉辦一場(chǎng)為期一天的會(huì)議來教授Scrum，由發(fā)起敏捷并了解Scrum的常務(wù)副總授課。先不說人們?cè)诶斫?/span>Scrum的作用、儀式和人工制品方面存在差異，實(shí)際上，每個(gè)人都將Scrum視為另外一種項(xiàng)目管理技術(shù)，并不理解諸如自組織這樣的概念以及迭代工作的實(shí)證方法。通過努力，只有兩三個(gè)團(tuán)隊(duì)開始過渡到敏捷思維，但對(duì)于大多數(shù)團(tuán)隊(duì)而言，敏捷仍然只是微觀管理的一種新方法。
7）“敏捷只為圣誕節(jié)”的實(shí)施方法
敏捷不僅僅是待辦事項(xiàng)清單上的另一個(gè)項(xiàng)目。變得敏捷是一次旅行，不是一個(gè)一次性的項(xiàng)目，也不僅僅是另外一次實(shí)踐學(xué)習(xí)。
相當(dāng)直白地講，對(duì)于許多組織而言，變得敏捷意味著改變運(yùn)營(yíng)系統(tǒng)。是的，“達(dá)成敏捷（beingagile）”意味著采用新的運(yùn)營(yíng)方法，但更重要的變化是理念。許多組織的運(yùn)營(yíng)都遵循泰勒學(xué)派或笛卡爾的理念：管理層負(fù)責(zé)結(jié)果；其他員工負(fù)責(zé)執(zhí)行。
讓敏捷被接受需要自律和毅力?？赡苄枰ㄙM(fèi)數(shù)年的時(shí)間才能達(dá)到組織可以號(hào)稱自己敏捷的轉(zhuǎn)折點(diǎn)——并不是說那時(shí)你就可以停止那樣的工作方式。到那時(shí)，你們甚至不會(huì)再考慮其他的可選方案。你們已經(jīng)調(diào)整了文化。
有家大型的國(guó)際化企業(yè)踏上了敏捷之旅。工作現(xiàn)場(chǎng)會(huì)有一名教練，幫助團(tuán)隊(duì)和管理人員應(yīng)對(duì)他們每天的挑戰(zhàn)，并根據(jù)他們的成長(zhǎng)和興趣逐步實(shí)行Scrum。在這個(gè)過程進(jìn)行到大約兩個(gè)月的時(shí)候，一些痛苦的問題開始浮現(xiàn)：例如程序員不想測(cè)試，座位安排妨礙了有效工作，團(tuán)隊(duì)責(zé)備其他團(tuán)隊(duì)。接著，預(yù)算用完了。留給公司的是殘缺的Scrum和很多的失望。六個(gè)月之后，人們開始自己組織學(xué)習(xí)敏捷，這次沒有現(xiàn)場(chǎng)支持，為了獲得期望的結(jié)果，他們更加努力。
所有參與的部門必須遵循同樣的游戲規(guī)則。
在物理學(xué)中，當(dāng)波形產(chǎn)生一個(gè)恒定的相位差時(shí)，波源就是相干的。當(dāng)波源的頻率或方向不同，或者兩者都不一致時(shí)，它們不相干。在音樂方面，我們立即就可以知道我們聽到的聲音是否協(xié)調(diào)——可能只是聽錯(cuò)了。
對(duì)于組織團(tuán)隊(duì)而言，亦是如此。
如果組織的一個(gè)部分關(guān)注交付速度，另一部分專注質(zhì)量，即使他們步調(diào)一致，結(jié)果也不會(huì)一致。當(dāng)相互依賴的團(tuán)隊(duì)努力的方向不一致時(shí)，結(jié)果就會(huì)不一致。
成功的團(tuán)隊(duì)會(huì)統(tǒng)一他們的時(shí)間表、目標(biāo)和宗旨。
譬如，那不是說所有的團(tuán)隊(duì)都要統(tǒng)一他們的工作程序。只有當(dāng)兄弟部門需要統(tǒng)一他們的價(jià)值、標(biāo)準(zhǔn)和成功定義時(shí)，才需要進(jìn)行這種調(diào)整。如果那讓你想起了領(lǐng)導(dǎo)支持，說明你逐步理解敏捷了！
兩個(gè)從事同一款產(chǎn)品開發(fā)的部門已經(jīng)在他們的工作流程中實(shí)現(xiàn)了Scrum。一個(gè)部門正在開發(fā)提供產(chǎn)品KPI的度量工具。他們關(guān)注度量質(zhì)量。另一個(gè)部門正在增加新的產(chǎn)品特性。他們關(guān)注特性交付速度。兩個(gè)部門互相依賴：提供KPI需要調(diào)用產(chǎn)品特性的API；沒有KPI，新特性就沒有“完工”。兩個(gè)部門都對(duì)自己的敏捷實(shí)施以及敏捷對(duì)他們實(shí)現(xiàn)價(jià)值的助益感到滿意。但也只有當(dāng)兩個(gè)部門在一兩個(gè)沖刺中試驗(yàn)性地交換了專家，這兩個(gè)部門才真的彌補(bǔ)了他們之間的差距，制定出了包含對(duì)方需求的“完工定義”。
9）缺少足夠的適應(yīng)性指標(biāo)
使用虛榮指標(biāo)會(huì)導(dǎo)致失敗。
敏捷宣言的第七條“可工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)，”因此，不管你選擇了什么指標(biāo)，都應(yīng)該能夠度量工作如何對(duì)功能性產(chǎn)品有所貢獻(xiàn)。
打開或關(guān)閉的缺陷數(shù)量、速度、速度趨勢(shì)、“承諾-完工比（committed-versus-doneratio）”，諸如這些指標(biāo)都可以度量貢獻(xiàn)，但并不適應(yīng)于一個(gè)可工作的產(chǎn)品。
TheOrganisation Within一書的作者的LarryHirschhorn將這種指標(biāo)稱為“偶像”。它們或許可以代表實(shí)情，但基本上沒有。
相反，客戶滿意度、員工幸福感或者媒體報(bào)道可能是更好的指標(biāo)。
不過，按照MarkTwain的說法，指標(biāo)和尿不濕一樣，應(yīng)該經(jīng)常換。每個(gè)指標(biāo)都可能失效，因?yàn)槿藗儠?huì)根據(jù)你度量他們的方式行事。因此，不要試圖尋找一個(gè)可以裁定所有人的指標(biāo)。你度量的東西應(yīng)該和產(chǎn)品及團(tuán)隊(duì)的成熟度有關(guān)，而且你應(yīng)該盡可能經(jīng)常地替換它。
一家大型企業(yè)利用一系列工具來幫助敏捷實(shí)施，并且自己在上層構(gòu)建了一個(gè)報(bào)表工具。該工具已經(jīng)逐步發(fā)展成為一個(gè)BI平臺(tái)，可以隨意處理各種數(shù)據(jù)：速度、連續(xù)運(yùn)轉(zhuǎn)效率、WIP隨時(shí)間的變化（即CFD）、承諾準(zhǔn)確性，等等。于是，一種新的文化形成了：臨近每個(gè)季度末的時(shí)候，項(xiàng)目經(jīng)理花費(fèi)幾天時(shí)間，進(jìn)行周密地過濾，把最好的報(bào)表展示給利益相關(guān)者。不管車間里實(shí)際上發(fā)生了什么，只要報(bào)表看上去好看。
當(dāng)“技術(shù)性的”Scrum意味著“完工”的時(shí)候，這是成立的。
敏捷的范疇比Scrum要大得多。Scrum是最流行的開發(fā)周期框架，只處理一個(gè)方面：一個(gè)或多個(gè)團(tuán)隊(duì)接受一個(gè)需求積壓列表，并用一個(gè)較短的反饋循環(huán)完成它們。Scrum本身并不涉及工程卓越、總體目標(biāo)、擴(kuò)展（LeSS使用Scrum優(yōu)雅地處理了擴(kuò)展）或者長(zhǎng)期規(guī)劃，等等。
優(yōu)秀的Scrum管理員知道那些，并幫助他們的團(tuán)隊(duì)、產(chǎn)品經(jīng)理和利益相關(guān)者實(shí)現(xiàn)多方面的改善。
就是說，優(yōu)秀的Scrum管理員并沒有真正的踐行Scrum。他們是在Scrum環(huán)境里操作的敏捷實(shí)踐者。
一個(gè)中型組織希望實(shí)施Scrum。一場(chǎng)組織分析澄清了這個(gè)過程：從改善工程實(shí)踐入手，因?yàn)榻M織第一個(gè)可能遇到的問題會(huì)和代碼有關(guān)。盡管出現(xiàn)了發(fā)布過程痛苦冗長(zhǎng)、怪罪文化盛行等癥狀，但在接下來的多次會(huì)議中，組織領(lǐng)導(dǎo)者還是堅(jiān)持繼續(xù)推進(jìn)Scrum。這段旅程使得團(tuán)隊(duì)成員之間的關(guān)系不斷惡化，直到組織完全放棄了Scrum。
現(xiàn)在輪到你逆向分析這篇文章了。
這篇文章不是要讓你放棄敏捷之旅。
相反，它是要讓你堅(jiān)持下去。
如果你發(fā)現(xiàn)自己陷入了這里提到的一個(gè)或多個(gè)反模式，那么問下自己，你可以做點(diǎn)什么來改變它。你可以做點(diǎn)什么不同的事情，以一種你可以操作的方式，變得更加敏捷呢？哪里是你忽略了的O型圈，什么反模式促成了它，如何擺脫它？
一家大型企業(yè)在他們其中一個(gè)研發(fā)部門實(shí)施了Scrum和看板。接下來，產(chǎn)品經(jīng)理和團(tuán)隊(duì)之間的關(guān)系變得緊張，組織引入了一家外部供應(yīng)商就團(tuán)隊(duì)工作協(xié)議組織召開一場(chǎng)研討會(huì)。雖然預(yù)備會(huì)議表明團(tuán)隊(duì)層面存在一些挑戰(zhàn)，但更大的挑戰(zhàn)來自領(lǐng)導(dǎo)者。例如，雖然管理者相信敏捷，但他們沒有為團(tuán)隊(duì)工作樹立好榜樣。
團(tuán)隊(duì)研討會(huì)被一場(chǎng)管理團(tuán)隊(duì)組建會(huì)議所取代。研討會(huì)的結(jié)果是一份待變革事項(xiàng)列表：正式確定部門的目的和價(jià)值；澄清管理團(tuán)隊(duì)成員的角色；定義并擁有標(biāo)準(zhǔn)，尤其是對(duì)于外部依賴，等等。通過設(shè)置自己的變革看板及承認(rèn)運(yùn)轉(zhuǎn)問題，管理層開始消除導(dǎo)致敏捷失敗的方式，并代之以漸進(jìn)的步驟，為敏捷團(tuán)隊(duì)樹立一個(gè)榜樣。
聯(lián)系客服
