打造敏捷的自組織團隊

敏捷思想的出現讓咱們看到了新的曙光——以更低的風險、更高的效率開發出更具質量的軟件產品。正因如此，敏捷方法獲得了業內足夠的重視並使各路團隊相擁實踐。然而，即使咱們對於各類敏捷原則、範式、方法和流程瞭如指掌，仍會發現其所給組織帶來的改善遠達不到咱們的預期。這到底是爲何？形成這種困境的根源並不是咱們學得不精，而是實踐不到位。

在我看來，敏捷宣言過於簡單（好吧，是宣言總得簡單一點！），以致於足以讓人對之產生誤解。好比：「能夠工做的軟件賽過面面俱到的文檔」容易讓人忽視對必要文檔的重視；「個體和交互賽過過程和工具」容易讓人誤覺得有了面對面的溝通就能夠忽視適宜的過程和易用的工具所帶來的巨大正面做用。就個人觀察，只要軟件開發活動中忽視了必要（言簡意賅）的文檔、適宜的過程及易用的工具就必定「敏捷不起來」，由於它們是塑造訓練有素的個體所需的重要素材，而個體正是敏捷原則中所提到的自組織（開發）團隊的組成單位。團隊是否作到自組織是檢驗敏捷思想是否真正落地的重要斷定依據。然而，團隊要真正作到自組織卻面臨很大的挑戰，讓咱們分別從幾個方面加以探討。

首先，從項目管理層面加以審視。最近面試了一個項目經理，他在華爲和騰訊兩家公司都幹過，從與之的交談中很明顯地看出他對於敏捷軟件開發有着良好的實戰經驗，也對實踐中所碰到的困境有着本身獨特的思考。然而，當我問他「實施敏捷軟件開發的最大挑戰是什麼」時，他的回答倒是「項目難以如期完成」。得知他的這一回答後，我當即告訴他「儘管你談起敏捷時頭頭是道，但你心裏深處並無真正擁抱和理解敏捷」。在告知他我爲什麼得出該結論後，他抱以微笑並對個人觀點加以承認。我估計與他有一樣想法的項目項目管理者大有人在！

「響應變化賽過遵循計劃」這條宣言告訴咱們，軟件項目的評估是爲了適應變化而非爲了遵循計劃。更深一層的含義是，項目計劃應當保持必定的彈性（指計劃時間能夠常常適時地調整，項目管理也得敏捷！），即如期完成項目計劃並不是是敏捷所倡導的，她所倡導的應是持續地以更高的效率完成高質的軟件開發工做。然而，受傳統項目管理思想的影響，咱們大部分管理者仍然以項目是否如期完成做爲一個重要的考覈指標。其實，對項目計劃要求越是精確（這裏的「精確」是指計劃一旦制定就得嚴格如期執行，或者咱們說項目計劃很具「鋼性」），實現自組織團隊的困難就越大。爲何？

事實上，不論軟件開發工程師的經驗多麼豐富，要真正精確評估實現一個軟件功能的時間在不少情形下幾乎沒有可能。固然，現實中存在另外一種「精確」，即經過更大的時間冗餘使評估顯得「精確」。這所致使的直觀結果就是，最終單從項目計劃上就能一眼看出「根本不敏捷」。項目計劃一旦不具必定的彈性，所產生的另外一個問題是開發工程師在實現功能時根本沒法將一個功能作到讓本身滿意，由於將時間評估得偏少這類事總在發生。緣由在於不少工程師迫於管理層的壓力，不會將時間評估得保守，而是報着「我加加班應當能夠搞定」的心態。最終的結果就是，工程師爲了按計劃完成工做只能「缺斤少兩」地作事。

讓項目計劃保持必定的彈性會讓不少管理者（包括項目經理本身）提出一個問題，即「那我如何知道項目是否進展順利呢？」事實上，項目是否真正進展順利並不能簡單地從計劃的執行狀況看出，由於軟件的真正質量和開發效率並不是體如今項目計劃的鋼性上，管理者在這種情形下能作的除了信任團隊外，去了解更多的團隊情況、技術細節或許有助於平復本身的焦慮情緒。千萬別忘記，沒有信任就沒有敏捷！也千萬別忘記，敏捷意味着更高的開發效率和軟件質量，而項目計劃是否如期執行根本沒有徹底表明這兩個訴求！

值得一提的是，我並不是主張管理層該盲目、簡單地信任團隊，在以前必定要確保開發團隊中存在合適的人可能讓團隊自組織起來。但管理層必定須要意識到的是，即便團隊中存在那樣的人，也要配合適當的管理方法才能讓那些人真正將團隊帶向自組織。

其次，從基層技術管理的角度加以剖析。技術管理的核心內容是提升團隊技能（參見《技術管理的核心內容——提升團隊技能》），但很多基層技術管理者從技術走向技術管理崗位後，將（絕）大部分精力投入到項目管理事務中，忽視本身所應承擔的團隊管理責任。更爲可怕的是，這類人很容易將團隊的自組織能力放在一邊，既聽不進團隊發出的聲音，也不會去刻意培養，這種管理模式形成咱們永遠得不到真正自組織的團隊。

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

我相信不少基層技術管理者想將團隊帶好，但很多人受能力、惰性和胸襟所限，根本不理解什麼是自組織團隊，也不肯意學習與自我改善，還放不下本身是「領導」的架子。然而，這類人正是自組織團隊要「消滅」的。因而，咱們面臨這樣一個悖論——「爲了本身不被‘消滅’，這類人必定帶不出自組織的團隊」。不難發現，合適的基層技術管理者是打造自組織團隊關鍵中的關鍵！

再次，咱們從工程師的角度給予考量。自組織團隊對於工程師來講究竟意味着什麼？第一，技能多樣化。技能過於單一每每會形成項目計劃的實施瓶頸在於某我的無可替代地處於項目的關鍵路徑上，這使得項目的人員安排缺少彈性。要實現技能的多樣化首先要從管理着手，即須要基層技術管理者有意識地經過工做安排加以培養，這一點咱們前面已談及。另外一方面，工程師也得有意識自我培養，千萬不要將本身的工做錨定在很窄的範圍。爲了不出現這種境況，工程師對本身的工做內容應經過編寫言簡意賅的文檔（好比概要設計、指南等）的方式讓他人能夠方便地接手。顯然，文檔的編寫能力也涵蓋於技能多樣化之中。第二，律己和律他。「自組織」這個詞從表面就向咱們傳達了「紀律」，紀律意味着質量與效率。工程師個體首先需有良好的自律能力，對於團隊所達成的各類共識（規範、流程等）努力實施到位，對於已存在的好方法、好習慣積極地模仿並跟隨，而不是簡單地打破並自立門戶。除了良好地律己咱們還得關注律他，經過指出他人不足並給予幫助的方式讓整個團隊維持良好的工做紀律。第三，良好的方向感。這種方向感源於清楚地知道產品的定位與戰略，並基於此而造成的、清晰的軟件開發策略。良好的方向感使得工程師清楚地知道技術的真正價值在於爲產品的核心競爭力提供強有力的支持，並努力在產品與技術之間得到平衡。在我看來，簡單地偏向產品或技術，從長遠來看對於整個團隊都會是一種災難。第四，主動承擔責任。面對責任，與「主動承擔」相反的方式是「防護」或「逃避」。自組織團隊必定不會懼怕責任，當出現問題時工程師會主動承擔責任或幫助他人解決，呈現的是一種互幫互助的良好協做氛圍。第五，自發地持續改善。在具備良好方向感的自組織團隊中，工程師會時刻關注開發工做中的點滴改善，經過持續改善的方式從技術層面不斷地將產品推向更高的品質。

從項目管理、技術管理和工程師三個緯度的分析能夠看出，真正的敏捷自組織團隊須要從上到下、各工種的理解與配合纔有可能打造出來。「敏捷」所強調的更多的是「彈性」，由於具備良好彈性的團隊在面對各類壓力時才具韌性。試想一想，若是個體被桎梏於只能容下身體的空間中，那麼咱們有可能作到（伸手）「敏捷」嗎？

真正的敏捷不是形式，而是團隊的文化與能力。若是不注重從文化與能力上去塑造，不管咱們對於敏捷之形多麼在乎和刻意臨摹，咱們永遠只能遊離於表面。