敏捷思想的出現(xiàn)讓我們看到了新的曙光——以更低的風(fēng)險、更高的效率開發(fā)出更具質(zhì)量的軟件產(chǎn)品。正因如此，敏捷方法得到了業(yè)內(nèi)足夠的重視并使各路團隊相擁實踐。然而，即便我們對于各種敏捷原則、范式、方法和流程了如指掌，仍會發(fā)現(xiàn)其所給組織帶來的改善遠達不到我們的預(yù)期。這究竟是為什么？造成這種困境的根源并非我們學(xué)得不精，而是實踐不到位。

在我看來，敏捷宣言過于簡單（好吧，是宣言總得簡單一點?。?，以至于足以讓人對之產(chǎn)生誤解。比如：“可以工作的軟件勝過面面俱到的文檔”容易讓人忽視對必要文檔的重視；“個體和交互勝過過程和工具”容易讓人誤以為有了面對面的溝通就可以忽視適宜的過程和易用的工具所帶來的巨大正面作用。就我的觀察，只要軟件開發(fā)活動中忽視了必要（言簡意賅）的文檔、適宜的過程及易用的工具就一定“敏捷不起來”，因為它們是塑造訓(xùn)練有素的個體所需的重要素材，而個體正是敏捷原則中所提到的自組織（開發(fā)）團隊的組成單位。團隊是否做到自組織是檢驗敏捷思想是否真正落地的重要判定依據(jù)。然而，團隊要真正做到自組織卻面臨很大的挑戰(zhàn)，讓我們分別從幾個方面加以探討。

首先，從項目管理層面加以審視。最近面試了一個項目經(jīng)理，他在華為和騰訊兩家公司都干過，從與之的交談中很明顯地看出他對于敏捷軟件開發(fā)有著良好的實戰(zhàn)經(jīng)驗，也對實踐中所碰到的困境有著自己獨特的思考。然而，當(dāng)我問他“實施敏捷軟件開發(fā)的最大挑戰(zhàn)是什么”時，他的回答卻是“項目難以如期完成”。得知他的這一回答后，我立即告訴他“盡管你談起敏捷時頭頭是道，但你內(nèi)心深處并沒有真正擁抱和理解敏捷”。在告知他我為何得出該結(jié)論后，他抱以微笑并對我的觀點加以認可。我估計與他有同樣想法的項目項目管理者大有人在！

“響應(yīng)變化勝過遵循計劃”這條宣言告訴我們，軟件項目的評估是為了適應(yīng)變化而非為了遵循計劃。更深一層的含義是，項目計劃應(yīng)當(dāng)保持一定的彈性（指計劃時間可以經(jīng)常適時地調(diào)整，項目管理也得敏捷?。慈缙谕瓿身椖坑媱澆⒎鞘敲艚菟珜?dǎo)的，她所倡導(dǎo)的應(yīng)是持續(xù)地以更高的效率完成高質(zhì)的軟件開發(fā)工作。然而，受傳統(tǒng)項目管理思想的影響，我們大部分管理者仍然以項目是否如期完成作為一個重要的考核指標(biāo)。其實，對項目計劃要求越是精確（這里的“精確”是指計劃一旦制定就得嚴格如期執(zhí)行，或者我們說項目計劃很具“鋼性”），實現(xiàn)自組織團隊的困難就越大。為什么？

事實上，不論軟件開發(fā)工程師的經(jīng)驗多么豐富，要真正精確評估實現(xiàn)一個軟件功能的時間在很多情形下幾乎沒有可能。當(dāng)然，現(xiàn)實中存在另一種“精確”，即通過更大的時間冗余使評估顯得“精確”。這所導(dǎo)致的直觀結(jié)果就是，最終單從項目計劃上就能一眼看出“根本不敏捷”。項目計劃一旦不具一定的彈性，所產(chǎn)生的另一個問題是開發(fā)工程師在實現(xiàn)功能時根本無法將一個功能做到讓自己滿意，因為將時間評估得偏少這類事總在發(fā)生。原因在于很多工程師迫于管理層的壓力，不會將時間評估得保守，而是報著“我加加班應(yīng)當(dāng)可以搞定”的心態(tài)。最終的結(jié)果就是，工程師為了按計劃完成工作只能“缺斤少兩”地做事。

讓項目計劃保持一定的彈性會讓很多管理者（包括項目經(jīng)理自己）提出一個問題，即“那我如何知道項目是否進展順利呢？”事實上，項目是否真正進展順利并不能簡單地從計劃的執(zhí)行情況看出，因為軟件的真正質(zhì)量和開發(fā)效率并非體現(xiàn)在項目計劃的鋼性上，管理者在這種情形下能做的除了信任團隊外，去了解更多的團隊狀況、技術(shù)細節(jié)或許有助于平復(fù)自己的焦慮情緒。千萬別忘記，沒有信任就沒有敏捷！也千萬別忘記，敏捷意味著更高的開發(fā)效率和軟件質(zhì)量，而項目計劃是否如期執(zhí)行根本沒有完全代表這兩個訴求！

值得一提的是，我并非主張管理層該盲目、簡單地信任團隊，在之前一定要確保開發(fā)團隊中存在合適的人可能讓團隊自組織起來。但管理層一定需要意識到的是，即使團隊中存在那樣的人，也要配合適當(dāng)?shù)墓芾矸椒ú拍茏屇切┤苏嬲龑F隊帶向自組織。

其次，從基層技術(shù)管理的角度加以剖析。技術(shù)管理的核心內(nèi)容是提高團隊技能（參見《技術(shù)管理的核心內(nèi)容——提高團隊技能》），但不少基層技術(shù)管理者從技術(shù)走向技術(shù)管理崗位后，將（絕）大部分精力投入到項目管理事務(wù)中，忽視自己所應(yīng)承擔(dān)的團隊管理責(zé)任。更為可怕的是，這類人很容易將團隊的自組織能力放在一邊，既聽不進團隊發(fā)出的聲音，也不會去刻意培養(yǎng)，這種管理模式的造成我們永遠得不到真正自組織的團隊。

我在《如何做好基層技術(shù)管理工作？》一文中談及了動機與方法兩大方面，在本文討論的主題下需做一些補充。當(dāng)團隊還不具備自組織能力時，基層技術(shù)管理者起到至關(guān)重要的作用。第一，重視工作安排策略。大多情況下，由于項目的時間壓力，基層技術(shù)管理者很容易采取根據(jù)工程師的技能安排他做最能獲得效率的工作這一策略。然而，長期采用這一策略將導(dǎo)致工程師所熟悉的模塊趨于單一化，結(jié)果導(dǎo)致工作安排缺乏彈性，變成“每個蘿卜都挪不了坑”。這種境況很不利于團隊技能的發(fā)展，也使得團隊很難進入自組織的狀態(tài)。更為合適的做法是，在每次迭代中安排少數(shù)幾個工程師做他們不擅長的。多次迭代下來，工程師所涉功能面將更廣，這就為項目計劃時的人員安排帶來了更大的彈性，也使得各功能模塊的代碼能在多個工程師的視線范圍內(nèi)，從而更容易落實質(zhì)量。第二，如果不能營造一種讓工程師暢所欲言的團隊文化，則同樣沒有將團隊帶入自組織狀態(tài)的可能。在我看來，只要是一名管理者，如果你的下屬不愿向你吐露工作中的心聲，那證明你已失敗！第三，在制定開發(fā)計劃時，基層技術(shù)管理者一定要持續(xù)地將一只眼睛盯住改善部分，而不能只關(guān)注新功能開發(fā)。不斷改善的目的，是為了防止技術(shù)債高筑而使得程序變更缺乏彈性。第四，團隊在走向自組織的道路上，一定存在不少對既定目標(biāo)做適當(dāng)變更的情形，此時基層技術(shù)管理者一定要做好上下間的溝通工作，讓團隊的工作狀態(tài)對高層管理者更加透明。信息的透明化有助于管理高層真實了解團隊的現(xiàn)狀，為信任提供良好的支撐，讓他們不至于過于關(guān)注項目計劃的鋼性。第五，確保軟件設(shè)計質(zhì)量與編碼質(zhì)量落實到位。換句話說，確保在團隊中落實概要設(shè)計評審和代碼審查等工作流程。

我相信很多基層技術(shù)管理者想將團隊帶好，但不少人受能力、惰性和胸襟所限，根本不理解什么是自組織團隊，也不愿意學(xué)習(xí)與自我改善，還放不下自己是“領(lǐng)導(dǎo)”的架子。然而，這類人正是自組織團隊要“消滅”的。于是，我們面臨這樣一個悖論——“為了自己不被‘消滅’，這類人一定帶不出自組織的團隊”。不難發(fā)現(xiàn)，合適的基層技術(shù)管理者是打造自組織團隊關(guān)鍵中的關(guān)鍵！

再次，我們從工程師的角度給予考量。自組織團隊對于工程師來說究竟意味著什么？第一，技能多樣化。技能過于單一往往會造成項目計劃的實施瓶頸在于某個人無可替代地處于項目的關(guān)鍵路徑上，這使得項目的人員安排缺乏彈性。要實現(xiàn)技能的多樣化首先要從管理著手，即需要基層技術(shù)管理者有意識地通過工作安排加以培養(yǎng)，這一點我們前面已談及。另一方面，工程師也得有意識自我培養(yǎng)，千萬不要將自己的工作錨定在很窄的范圍。為了避免出現(xiàn)這種境況，工程師對自己的工作內(nèi)容應(yīng)通過編寫言簡意賅的文檔（比如概要設(shè)計、指南等）的方式讓他人可以方便地接手。顯然，文檔的編寫能力也涵蓋于技能多樣化之中。第二，律己和律他?！白越M織”這個詞從表面就向我們傳達了“紀律”，紀律意味著質(zhì)量與效率。工程師個體首先需有良好的自律能力，對于團隊所達成的各種共識（規(guī)范、流程等）努力實施到位，對于已存在的好方法、好習(xí)慣積極地模仿并跟隨，而不是簡單地打破并自立門戶。除了良好地律己我們還得關(guān)注律他，通過指出他人不足并給予幫助的方式讓整個團隊維持良好的工作紀律。第三，良好的方向感。這種方向感源于清楚地知道產(chǎn)品的定位與戰(zhàn)略，并基于此而形成的、清晰的軟件開發(fā)策略。良好的方向感使得工程師清楚地知道技術(shù)的真正價值在于為產(chǎn)品的核心競爭力提供強有力的支持，并努力在產(chǎn)品與技術(shù)之間獲得平衡。在我看來，簡單地偏向產(chǎn)品或技術(shù)，從長遠來看對于整個團隊都會是一種災(zāi)難。第四，主動承擔(dān)責(zé)任。面對責(zé)任，與“主動承擔(dān)”相反的方式是“防御”或“逃避”。自組織團隊一定不會害怕責(zé)任，當(dāng)出現(xiàn)問題時工程師會主動承擔(dān)責(zé)任或幫助他人解決，呈現(xiàn)的是一種互幫互助的良好協(xié)作氛圍。第五，自發(fā)地持續(xù)改善。在具有良好方向感的自組織團隊中，工程師會時刻關(guān)注開發(fā)工作中的點滴改善，通過持續(xù)改善的方式從技術(shù)層面不斷地將產(chǎn)品推向更高的品質(zhì)。

從項目管理、技術(shù)管理和工程師三個緯度的分析可以看出，真正的敏捷自組織團隊需要從上到下、各工種的理解與配合才有可能打造出來?！懊艚荨彼鶑娬{(diào)的更多的是“彈性”，因為具有良好彈性的團隊在面對各種壓力時才具韌性。試想想，如果個體被桎梏于只能容下身體的空間中，那么我們有可能做到（伸手）“敏捷”嗎？

真正的敏捷不是形式，而是團隊的文化與能力。如果不注重從文化與能力上去塑造，無論我們對于敏捷之形多么在意和刻意臨摹，我們永遠只能游離于表面。

本文出自 “至簡李云” 博客，請務(wù)必保留此出處http://yunli.blog.51cto.com/831344/1432103