（圖片來源：https://unsplash.com/photos/RxOrX1iW15A）
4月18日早上9點30分，團隊跟着大屏計時器整齊地喊出倒計時，“五、四、三、二、一”，Tech Lead 強哥和 PO 小楠相對看了一眼，一起按下了earth系統發佈的回車鍵。隨着app和web系統用戶登錄的叮咚聲不斷響起，earth系統正式上線成功。會議室裏也再次響起了團隊的掌聲和歡呼聲。
那曾經是我職業生涯中爲數不多的高光時刻，讓我至今記憶猶新。
在我們每個人的職業生涯中，也總是希望能加入一個優秀的團隊，一起經歷這樣的高光時光，項目成功自己也有所成長。而當自己成爲團隊Leader之後，也希望自己能夠帶領出這樣優秀的團隊，乘風破浪，創造這樣高光時刻。
那麼，如何實現呢？作爲團隊新任Leader，可以從以下5個問題入手，爲自己的團隊把把脈。
問題1： 團隊目標和交付價值是什麼，團隊成員是否知曉且對此有一致的共識？
“如果沒有目標，那麼任何風向都是逆風；”——摘自網絡
明確的目標會爲團隊的工作引導方向，就像航行不能少了羅盤，再大的船也需要有明確的航行目標和方向，再強的出海艦隊也需要對去往的方向和如何應對險阻有一致的共識。
沒有了目標和共識，團隊不僅會偏離行駛的目標，也會在一望無邊的任務中忙亂、彷徨、失措而最終黯淡離場。
作爲團隊Leader，首要任務是從繁雜的信息中明確目標，並清晰地傳達給團隊每一個人。如果說一個Leader只做一件事，我認爲是設置清晰明確的目標，並讓目標在團隊中達成共識。
然而，能做到這一點的團隊並不多。
我觀察到最常見的問題不在於有沒有，而是在於新Leader多無意識地忽略了這一行動舉措，僅傳遞我們要完成的任務。很多團隊中開發人員在寫代碼時並不知道這個迭代的交付優先級和業務價值，已是常態。
敏捷諺語：“所有的Story缺省都是無效需求，除非它有明確的價值”
團隊成員作爲執行個體不知道目標和價值，就只能儘可能根據自己的理解去優化自己的執行過程和結果。這往往會導致：
- 反覆執行方案的浪費
- 追求任務本身優化和細節盡善盡美，導致未預期的開發過程蔓延
- 或出現與目標不匹配的結果偏差
- 乃至導項目的延期交付、成本蔓延、目標偏離等問題
曾經有這樣一個心理學家的試驗（摘自網絡）：
這個心理學家組織了三組人，讓他們分別向着10公里以外的三個村子進發。
第一組的人既不知道村莊的名字，也不知道路程有多遠，只告訴他們跟着嚮導走就行了。剛走出兩三公里，就開始有人叫苦；走到一半的時候，有人幾乎憤怒了，他們抱怨爲什麼要走這麼遠，何時才能走到頭，有人甚至坐在路邊不願走了；越往後，他們的情緒就越低落。
第二組的人知道村莊的名字和路程有多遠，但路邊沒有里程碑，只能憑經驗來估計行程的時間和距離。走到一半的時候，大多數人想知道已經走了多遠，比較有經驗的人說：“大概走了一半的路程。”於是，大家又簇擁着繼續往前走。當走到全程的四分之三的時候，大家情緒開始低落，覺得疲憊不堪，而路程似乎還有很長。當有人說：“快到了！快到了！”大家又振作起來，加快了行進的步伐。
第三組的人不僅知道村子的名字、路程，而且公路旁每一公里都有一塊里程碑，人們邊走邊看里程碑，每縮短一公里大家便有一小陣的快樂。行進中他們用歌聲和笑聲來消除疲勞，情緒一直很高漲，所以很快就到達了目的地。
在這個心理學試驗中顯示，當人們的行動有了明確目標的時候，並能把行動與目標不斷地加以對照，進而清楚知道自己的行進速度與目標之間的距離，人們行動的動機就會得到維持和加強，就會自覺地克服一切困難，努力到達目標。
以上試驗向我們證明了目標對於團隊的重要。在一個敏捷團隊，產品需求不明確，價值交付是唯一方法時，就更需要有明確的目標和價值主張。這樣才能指導團隊用“簡單足夠”的設計去“敏捷地”爲客戶交付可工作的軟件，儘快驗證價值獲取反饋。
與此同時，當一個明確而又看得見的目標在團隊內的時候，還會成爲激發團隊的動力，甚至會讓團隊煥然一新，創造奇蹟。目標有時候不在於多高大尚，而在於團隊是否清晰明確的知曉，它的力量甚至超出你的想象。
那麼，一個項目的目標包括什麼？
- 項目畫布（Project Canvas）包括項目的目標/願景/MoS/價值主張
- 工作說明書（SOW-Statement of Work）中的交付承諾
- 服務框架協議（MSA-Master Service Aggreement ）中定義的客戶信息安全要求及其政策
- 項目的交付週期、關鍵交付里程碑
又如何讓大家看得見且形成共識？
第一，構建信息輻射體（Information Radiator），比如利用物理牆、jigsaw電子牆、團隊會議模板等可視化渠道傳遞項目的關鍵目標。
第二，使用下面這個問題詳單幫你在日常工作中融入目標的維持和加強：
- 是否在Onboarding的時候向新人介紹項目的目標、關鍵里程碑、MVP。
- 是否在Onboarding的時候向新人介紹交付承諾，實現舉措以及優先級。
- 是否有階段性的組織項目Update，及時傳遞和更新變更，始終保持團隊在目標上的同頻。
- 是否在迭代計劃會議（IPM-Iteration Planning Meeting）的時候向團隊清楚的澄清本迭代的目標和優先級，以及原因，確保團隊衝向同一終點。
- 是否在Retro的時候回顧本迭代目標和完成情況。
- 目標和進度是否有足夠的可視化，讓團隊可以看得見找得見。
- 是否每個人都清楚自己的職責和任務，並知道與目標關聯關係
孫子曰：上下同欲者勝。
“當一個人知道自己想要什麼，整個世界都會爲他讓路”。團隊也是一樣。
如果團隊成員沒有共同認可的目標或對目標缺乏清晰的理解，就會影響到集體決策和協同行動，損及團隊以及團隊的業務成果。而團隊Leader不懂目標的力量，可能累死自己還拖垮了團隊。
因此，團隊新Leader需要善用目標管理，清楚設置項目目標，並堅信這一目標富有的意義和價值，竭盡全力地始終保持團隊在目標的共識，且團隊中每個成員都知道自己做什麼和怎樣做可以共同完成任務。這也決定了在困難來臨的時候團隊是否有乘風破浪的勇氣和動力，也是團隊成爲王者的前提條件。
在新建一個團隊時候，前四個迭代是你做好目標建設的最好時機。
問題2：團隊成員是否可以及時獲取完成開發任務所需的信息？
（圖片來源：https://www.sohu.com/a/203790693_187697）
在《技控革命(從培訓管理到績效改進)》一書中引用了托馬斯.吉爾伯特績效行爲工程模型中，它指出環境因素佔組織績效的75%，在環境因素中信息因素佔35%，包括：
- 是否被清晰、明確地告知做好工作的標準和期望
- 是否得到做好工作的各種信息，能及時、明確的獲得工作的反饋
對於從事敏捷軟件開發的知識工作者來說，及時獲取完成任務所需的信息輸入及實現共識-包括業務價值、技術方案、驗收標準以及反饋-顯得更爲重要。因爲這些決定了他/她將以什麼樣的方法、多少成本去交付什麼樣價值的可工作軟件。
敏捷諺語：“再詳盡的文檔也無法替代個體和互動”
如果沒有及時獲取這些信息和共識，就會出現如下問題：
- IPM估算時每個人的理解不同，無法達成一致，最後倉促了事。
- 有時候開發了好長時間的用戶故事，突然在溝通中發現根本不是客戶想要的，只能重做。
- 用戶故事沒有DoD（Definition of Done）、技術方案、接口設計，經常做到中間才發現需要推倒重來。
- 代碼寫到快完成了，發現字段命名不符合規範，聯調失敗，不得不返工。
- 花費了四天終於把模型和複雜邏輯搞定了，突然發現其它同事已經做過了。
- 同一個bug經常反覆出現，改了一個bug又可能引起了新的bug
- 每個人說法都不一樣，而且有時候自己都忘了當時的決策是怎麼回事。
……
那麼，當我們進入迭代開發後，需要哪些信息和共識？以及在什麼時候？
迭代過程也是團隊對交付工件逐漸達成共識的過程。在迭代的窗口內需要確保需求和計劃是明確的，以便團隊可以快速的完成和持續驗證。
迭代開始，PO與團隊TL/PM/BA需要就交付範圍的優先級達成一致，而開發團隊則需要就本迭代開發的工作內容、DoD(完成標準）的要求、以及如何實現（接口設計、多系統處理的集成設計、組件結構、複雜流程處理和組件、邏輯數據庫設計、測試策略、編碼規範等）獲得相同的理解，以便爲本迭代的目標進行全力衝刺。
作爲團隊的Leader需要確保以上任務信息及時給到團隊，以實現團隊績效的最大化。可喜的是，Scrum、XP、精益中的工程實踐已經幫助我們定義了清晰的迭代結構和信息流，你需要的是合理的遵循和發揮它們在團隊信息和共識的價值。
問題3：團隊是否可以有序地開展價值交付活動？
（圖片來源：https://unsplash.com/photos/M3cxjDNiLlQ）
疫情時代的到來，我們可以看到不確定性將會是最大的確定。對於交付團隊而言，面對的挑戰也不僅僅是需求的不確定，還有客戶從成本效率向速度及快速適應變化的訴求。對於團隊則意味着一切可能都會變，時間緊、壓力大會成爲常態。
接下來我們來談談在這樣一個常態下，團隊如何從忙亂到有序的這個問題。
1969年塔克曼先生在《小型團隊的發展序列》文中指出，團隊發展存在五個階段：組建期（Forming）、激盪期（Storming）、規範期（Norming）、高效期（Performing）和休整期（Adjourning）。這五個階段在團隊的發展過程中都是必須且不可逾越的。
在今天這樣的挑戰下，留給團隊從組建到高效的時間並不多。
一個優秀團隊就體現在是否可以快速地從組建的忙亂進入到規範有序。時間越緊壓力越大的項目，越需要有經驗的Leader站出來，積極主動地通過應用敏捷精益的工程實踐構建團隊契約、流程機制、可視化價值看板、知識共享等來促成團隊在不確定中從無序忙亂到規範有序，而這種適應性的能力和文化也會是未來團隊致勝的關鍵。
1.爲什麼有序這麼重要？
雜亂無序會導致效率低效、士氣低下、重複-多頭甚至錯位管理。無序狀態持續越久團隊的情況越糟，疲憊不堪，結果也可想而知。而新手Leader容易出現的誤區就是缺乏對敏捷精益工程實踐的理解、缺乏系統思考、缺乏有效舉措，往往導致越管越亂，看不到有效的價值收益。
團隊無序的一系列特徵可能包含：
- 每個人似乎都有做不完的事
- 任務總在不停的變，團隊成員的安排也總在變，隨意無邏輯，一切以進度爲導向
- 進度遲緩出現救場明星或微管理，結果卻越管越亂，系統的負反饋被加強
- 總是被動的響應變化，又馬上爲了響應被迫做出偏面的決策
- 成員不清楚什麼樣的事情由誰負責，應invovle誰，好像這算是他負責，也好像是她
- 成員不清楚決策的流程和溝通機制，看到問題也無力解決
- IPM還沒有理解清楚業務和方案，也沒有清楚的驗收標準，趕緊開發吧
- 返工、開發中途的不同反覆頻繁出現
- 等不了後端了，這幾張卡有些複雜我也一起做了
- Bug似乎越來越多
- 人也不少，感覺總是做不完，團隊處在緊張加班的焦慮之中
- 反覆共識，隨隨便便就做出決定然後又隨隨便便推翻，不知道找誰，等待，浪費
2. 如何理解有序？
有序指物質的系統結構或運動是確定的、有規則的。序是事物的結構形式，指事物或系統組成諸要素之間的相互聯繫。有序是動態的、變化的有序。當事物組成要素具有某種約束性、呈現某種規律時，稱該事物或系統是有序的。人們通過認識客觀世界，認識各種事物和對象的組成要素、相互聯繫、結構功能及它們的發展演變規律，即事物的有序性，來促成事物不斷從無序向有序方向轉化。
有序是動態變化的，隨着新事物以及組成要素的變化，有序可能轉向無序，也有可能促成有序向更高能力的有序變化。
那麼，在敏捷團隊價值交付的上下文中，有序意味着什麼？
在我看來，在敏捷交付活動的有序代表了以下三個有秩序的活動閉環：
- 價值驗證閉環，從想法提出到生產環境客戶驗收的價值流轉是否有序。
- 圍繞迭代的團隊協作閉環，從迭代計劃、迭代啓動、Story開卡和關卡、Showcase和Retro這些活動中的任務分工和人員協作是否有序，遇到問題知道找誰，幾時站會，幾時code review，如何決策，以及代碼的規範有序可依。
- 新人融入閉環（能力提升閉環），在新人被捲入快節奏交付前可以有明確步驟的融入和快速勝任上崗。
2.1 價值流閉環指？
我們需要明確，敏捷團隊想要交付的是產品價值的最大化，而不是最多的功能點。團隊希望可以將客戶最初的想法隨着需求到上線發佈的快速流動轉化爲可工作的軟件產品，從而給客戶最初的想法提供反饋和價值驗證的閉環——產品價值指所開發的產品或服務對最終用戶的價值，它是用戶選購或使用該產品的首要因素，也是企業盈利的本質。
團隊可以根據所做產品和客戶的訴求，組織和設計流程與任務，確定上下游的關係，並按時間順序排列起來就形成了該產品的價值流圖。
價值流圖對團隊有什麼樣的啓示？
1）聚焦價值成果（Outcome）而非僅僅產出功能點（Output）的流動
構建一個順暢、一致經各個步驟的價值流，使得我們能夠持續地、有節奏地、沒有非必要的延遲、並以最優的資源使用方式來交付成果，它的好處還包含：
- 讓整個流程可視化，團隊可以聚焦在被創造的價值上（outcome），而不是日復一日交付了多少個功能點（output)。
- 有利於從全局視角去分析問題，識別和消除瓶頸，從而避免局部優化的陷阱—指把時間和精力花費在根本沒有效果甚至帶來負面效果的管理行爲上，尤其在忙亂的時候。
同時，基於此也可以促使團隊建立如下的迭代交付物理看板牆，可以從全局上從迭代的角度對交付過程進行管理和優化：
- 進行價值優先級的排列Story和開發任務
- 顯示化價值流的運轉規則
- 管理負荷，控制在製品數量，降低浪費，促成小批量的交付和驗證
- 管理拉式的流動，建立反饋和持續的推動價值閉環的改進
2）促使BA將隱性的業務價值知識從無序拆解到有序且足夠小的用戶故事，提升它被下游消費的效能傳遞和消費
我們必須要承認業務價值是隱性知識。不管是大到EDGE價值投資管理框架、還是小到用戶故事Story的編寫實踐和可視化工具，它們都可以幫助我們與客戶一起協同，從複雜的業務價值識別出最簡可行產品（MVP），並將大塊的價值需求進行拆分，從EPIC到用戶故事地圖，再到按迭代優先級排序的用戶故事堆。其中，Story在進入迭代前需要足夠小以支持團隊持續批量的交付，這是實現快速價值流轉的基礎。
最近在一個項目走查時也發現了業務價值作爲隱性知識傳遞的特點：它的傳播成本是距離的衰減函數。
作爲BA，在端到端的交付中，除了將業務價值從無序拆解到有序以Story方式輸入給交付團隊外，還承擔了業務知識傳遞載體的關鍵職責。因此，需要積極組織有效地社會化學習活動，向交付團隊傳遞隱性的業務知識，且傳遞的效果要以知識消費者的角度去檢驗。
這也是因爲軟件產品開發的好與壞依靠交付團隊整體的認知水平。爲了交付成功，團隊在這方面花再多的時間也不爲過。
2.2 圍繞迭代的團隊協作閉環？
團隊最重要的特徵在於成員之間存在分工和協作，良性分工和有效地協作創造協同效應，即1+1>2。在Thoughtworks，我們採用的是Scrum與極限編程XP的工程實踐組合，一個典型的交付團隊內有PM、BA、UX、TL、前後端開發、QA多個角色。
那麼他們分別負責什麼，在什麼時候，什麼樣的任務如何協作？
以下以Scrum團隊的三個角色Scrum Master、Product Owner、Scrum Team描述了團隊的相關職責，在不同的項目通常還會根據具體的交付任務和團隊情況設置對角色職責進行調整，比如增加面向產品的特性開發團隊及Feature Owner、促進每日站會的主持、迭代的交付負責人IM等。
Scrum Master，通常會有PM或IM負責：
- 組織團隊按敏捷過程規範高效運作，促進內外溝通協作；
- 管理進度、風險，協調解決敏捷運作過程中各種阻礙，推動持續改進。
Product Owner:
- 負責產品業務設計、需求提出、驗收、運營分析和產品改進；
- 建立產品Backlog，排優先級；
- 與BA緊密溝通、澄清業務需求；
Scrum Team：
- 作爲PO和開發團隊的溝通橋樑，協助PO分析需求和確定優先級
- 編寫和拆分用戶故事(含驗收條件AC)，維護產品Backlog；
- 交互體驗設計和高保交互設計圖，確保設計與實現一致和優化
- 給開發團隊澄清需求，支持迭代開發
- 負責業務建模、技術架構方案設計，測試策略、梳理技術性故事，管理技術債務；
- 推進單元測試、代碼評審、持續集成和自動化部署等工程實踐能力提升
- 參與迭代計劃，演示，回顧等關鍵活動；
- 應用和選取技術工程實踐，負責故事開發、單元測試，自動化測試、代碼評審等活動構建可工作的軟件；
- 立即修復持續集成發現的問題；
- 參與迭代計劃，評審，回顧等關鍵活動
- 編寫用戶故事測試案例（以GWT格式: Given、When、Then）；
- 負責迭代開發過程中的各個故事的測試，迭代增量的集成測試和迴歸測試；
- 自動化測試用例的編寫和維護
- 搭建和維護適合團隊的CI（Continuous Integration）系統，實現自動部署流水線；
除了敏捷團隊角色分工，促進團隊協作還需要建立Team Contract。團隊規範制度是團隊成員聚集在一起，爲了達成共同目標追求而產生的，它是用語言、非語言的溝通 規則來影響團隊成員行爲。通常從團隊的工作規範、DoD、團隊紀律協作章程（Ground Rule）幾個方面建立團隊契約。
敏捷諺語：CI 紅燈不過夜
協作紀律包括提交紀律、移卡紀律、集成規範、站會紀律、DC（Desk Check）時間、遠程協作紀律等。
那麼團隊協作中會遇到哪些挑戰呢？
如果把團隊交付比喻爲一場4*100的接力賽，那麼團隊勝出的關鍵就在於交接棒的技術。這也是我們發現協作有序最大的障礙在於上下游的接力棒交接不暢，出現信息的不對稱和信息空隙。而這些是混亂、脫節、甚至造成團隊犯錯的根源，但常會有相當一部分人意識不到這是一個問題。
《賦能-打造應對不確定性的敏捷團隊》作者在第七章中也指出信息空隙是無效組織的根源。要打造應對不確定性的敏捷團隊，需要打破信息壁壘，連接上下游信息斷點，建立共享意識和文化，獲得更大的團隊協同效應。
2.3 新人融入閉環（能力提升）
Onboard的流程是以終爲始的拉動式學習，旨在幫助團隊新人刻意練習來完成快速上崗。通常，TL 或者 Senior Dev 需要爲 團隊新人的On Boarding 準備材料，其中主要包含業務背景介紹、架構設計、測試策略、用戶故事和上崗的勝任要求。準備好相關材料後，安排一位Buddy 對新人進行 On Boarding和有結構的學習，完成第一個用戶故事的編寫，並通過上崗勝任練習後，即可融入團隊開發節奏。
總結
有序的流程和團隊協作是團隊進入規範期重要標誌。規模大、節奏快的交付團隊，越要需要可以有序穩定的”部隊作戰“。小且目標行動一致，並且能夠將業務價值、迭代協作、新人Onboard多個價值流閉環從無序到有序快速打通的團隊，是在當下時間緊壓力下應對不確定性的最好策略。越亂越忙反而越需要這樣堅守正確的實踐、原則和價值觀才能致勝。其它的任何形式都只可能是一地雞毛。
當下一個迭代開始的時候，你的團隊應該已經可以做到規範且行動有序了。那麼，恭喜你，開啓團隊發展的下一個階段！
文/Thoughtworks 禚嫺靜
原文鏈接：如何高效管理一支開發團隊（上）