【翻譯】團隊達成一致：如何幫助團隊進行自管理

來源：https://www.scrumalliance.org/community/articles/2015/february/team-agreements

---

 

爲什麼須要團隊決策？

Scrum團隊是自組織、跨功能的。自組織團隊內部決定如何來完成工做，而不接受上級指派。要能達到自組織水平，團隊應經歷團隊發展的不一樣階段。

---

 

Tuckman的團隊發展階段

Tuckman在1965年第一次提出了團隊發展的「造成期、風暴期、規範期、執行期」模型，他認爲：這些階段對團隊可以成長、面對困難、解決問題、計劃、交付成果等工做來講是必不可少的。

Scrum團隊要確保在第一輪Sprint就能交付正確，故沒有太多時間爲團隊發展作工做。因此在早期階段團隊應對如何決策達成共識。Sprint0是一個理想的時機來幫助團隊快速完成這些階段。Scrum是迭代和增量開發，因此團隊再每一輪sprint中都會經歷Tuckman階段並不斷改進。

團隊應明白哪些團隊決策方法對他們更適用，從而避免衝突。在Sprint0時創建團隊決策的方法，可避免中後期臨時抱佛腳。

應在ScrumMaster協助召開的會議中來定義團隊決策的方法。會議步驟可包括：準備，頭腦風暴、排序、分類、達成一致、精化。

 

Scrum團隊的決策

團隊本身決定如何達成一致。ScrumMaster能夠協助這些討論會議，但應由團隊成員來決定如何決策，並在各個階段的回顧會上不斷改進。

 

召開會議的最好時機

Sprint0是最好的時機來決定團隊決策方法。回顧會可幫助不斷改進決策的方法。

---

 

團隊決策——Backlog提煉會議

Backlog提煉的目的是爲了避免斷改進產品backlog。Backlog提煉應在當前sprint開發用戶故事以前完成。一般，提早1~2個sprint，團隊就應坐下來討論下一步工做內容。

活動召開的合適時機和持續時間

Backlog提煉在Scrum中並無明確的時間安排。最難的是：團隊必須在sprint中抽出時間來召開這類會議，就像每月存工資的10%以備後用。ScrumMaster必須盡力協調團隊和產品負責人時間，有時在sprint中間召開。這些可幫助團隊策劃當前sprint的工做。

誰應參加？

理想中，整個Scrum團隊都應參加backlog提煉會。若是不能全體參加，應考量你們的工做量和任務安排，而後選擇合適的參加人。

產品負責人與團隊之間就用戶故事、線框圖、原型圖等達成一致

團隊應與產品負責人就用戶故事的細節達成一致，並可考慮將其做爲用戶故事質量的度量指標。

用戶故事應寫多長？

當提煉backlog時，用戶故事的長度很重要。團隊應該慎重選擇其長度。理想中，用戶故事應在sprint中25%的時間內完成。

選擇基線中用戶故事和故事點的基線

用戶故事應該基線化並得到故事點的估計。全部團隊成員應對基線用戶故事有一致的理解。

哪些估算技術可用？

團隊應對選擇哪一種估算方法達成一致。專家意見、類比和分解（disaggregation）是可選的方法，也可結合多種估算方法得到更好的結果。對敏捷團隊而言，最好的估算方法是用撲克牌。撲克牌結合了專家意見、類比和分解，並用你們喜聞樂見的方式快速得到相對可靠的估算結果。

如何定義「準備就緒(DOR)」？

準備就緒的用戶故事可在sprint計劃會議中討論並用於下一個sprint。

產品負責人和團隊應該對用戶故事的DOR的準則達成一致。如下是重要的準則：

• 用戶故事知足INVEST準則
• 用戶故事明確了誰的立場（The user story must have clarity from the "what" point of view.）
• 全部假設、約束和依賴必須被識別並知足。

---

 

團隊決策——sprint計劃會議

每一個sprint開始，團隊和產品負責人召開sprint計劃會議，討論產品backlog中哪些應在本輪sprint交付。會議結束前，團隊把選擇的條目分解爲sprint task，並達成一致。

Sprint計劃會的時間

對於30天的sprint而言，最大的sprint計劃會議長度是8個小時。團隊可根據實際狀況商量來減小時間。團隊成員應都在sprint的第一天前來參加計劃會，產品負責人也應確保能參會。

若會議時間較長，團隊應贊同將會議分紅兩部分。一部分，產品負責人將用戶故事展現給團隊，基於capacity/velocity，同時團隊一致贊同sprint backlog並定義sprint goal。在第二部分，團隊成員把用戶故事分解爲任務。

產品負責人應承諾能夠演示用戶故事，以後最好能參加任務分解活動，並提供相對的解答和排序建議。團隊可在20~30%功能完成後短暫休息。

Sprint計劃會議的輸入準則

通常來講，在各項目的sprint計劃會議中，總有一些團隊成員沒有閱讀或理解用戶故事。全部參加sprint計劃會的人都應該至少閱讀或理解高優先級的產品backlog中的故事，以此做爲sprint計劃會輸入的準則。產品負責人應確保提供這些內容。

選擇本輪sprint中選擇故事的數量

團隊應瞭解本身的能力（capacity）和速率（velocity），並一致贊成被選擇的用戶故事數量。

任務如何分解

任務分解的方法應提早被定義好，以避免執行時相互衝突。任務分解通常在計劃會議的第二部分來作。團隊成員應一塊兒來作任務分解，而不是每一個人作本身負責的故事的任務分解。

如何處理大的用戶故事？

產品負責人和團隊應共同決定在sprint backlog中選擇的用戶故事的大小。若是用戶故事規模不合適，應決定是把其繼續分解而後在本輪sprint中交付，或之後sprint再處理。

什麼是對完成的定義（DoD）？

DoD是產品負責人和團隊之間最重要的準則。每一個用戶故事均可能有不一樣的DoD，通常來講團隊和產品負責人應在sprint0中定義高層次的DoD準則，並在每輪sprint計劃中增長特殊DoD的要求

團隊決策----每日會議

天天，在相同的時間和地點，Scrum團隊大概花費15分鐘通報各自進展。每一個成員陳述昨天完成了什麼，今天作什麼，遇到什麼障礙。每日會議可摒除舊的陋習。團隊成員應警戒陋習帶來的信號。

每日例會地點

每日例會應在同一地點舉行。分佈式團隊可用在線會議形式。

每日例會時間

對大概7人的團隊，應不超過15分鐘；團隊可根據成員多少，地點和每日例會的方法，來決定每日例會時間的時間盒長度。

---

 

團隊一致----sprint期間

Sprint期間，團隊基於承諾交付用戶故事的優先級來安排工做。產品負責人要解答全部的需求疑問和業務邏輯。團隊遇到障礙應及時與ScrumMaster交流，ScrumMaster協助團隊集中精力解決問題。

編碼規範

在Sprint0時應明確編碼規範。有時，少數團隊成員可能沒有閱讀編碼規範，整個團隊應安排會議來討論並理解編碼規範。

結對編程

結對編程技術並不常見。一般要花費很多時間才能讓團隊成員看到結對編程的好處，但團隊應實踐結對編程。

障礙（Impediments），擴大（escalations）和風險處理

ScrumMaster和團隊應共同創建一套過程來溝通和處理障礙、擴大和風險。

「軟技能」一致

有各類不一樣的一致承諾其實並無明確提出，可是團隊應常常回顧。團隊應確保進行中的工做最少化、應確保專一sprint backlog而不是其餘非相關內容，應確保不斷遵循敏捷的價值觀和原則。

---

 

團隊一致----sprint評審會

團隊應向產品負責人和關心產品的人演示每輪迭代完成的產品特性。產品負責人驗證sprint計劃中的承諾，並決定是否完成。

誰負責演示demo？

理想中，demo中的功能誰實現誰演示。但也可讓業務分析師一我的演示demo，而不是每一個人演示不一樣部分。

誰來搭建演示環境？

應確保評審會以前搭建好演示環境

誰記錄干係人的反饋？

演示期間會獲得用戶反饋，團隊應作好記錄。團隊中的人，或者每一個人，均可以記錄。產品backlog應根據記錄及時更新。

---

 

團隊一致----sprint回顧會

每一輪sprint結束時舉行sprint回顧會。團隊成員檢查本身的方法，並採起適當的措施來改進。一個深刻回顧須要團隊創建一種心理安全的環境，這在多數組織中很難見到。

Sprint回顧的技術和方法

回顧有多種方法。團隊應瞭解一些方法，如timelines, triple nickels, team radar, and force field analysis，這些能幫助團隊成員進行回顧，並達成一致。

除了團隊，哪些人被邀請參加？

有一些團隊在召開回顧會時，由於ScrumMaster和產品負責人在場，而感受不舒服。團隊應決定選擇哪些人蔘加回顧會，不一樣sprint可能不一樣。

計劃改進活動

並非全部sprint回顧會上討論的改進項能在下一個sprint變成行動項。團隊應按照優先級排列行動項，並決定哪些在下一個sprint被執行。

維護團隊的承諾

達成一致的決策，可能並未文檔化。一些決策，如編碼規範，應該文檔化，其餘的，例如會議的時間控制和時間盒，可能不須要文檔化。

一旦造成決策並記錄下來，應按期回顧。可在每一個sprint的結尾回顧，可在回顧會上回顧，或者在任何須要作的時候回顧。決策只有被團隊執行的很好後，才能進行替換。

---

 

總結

有一些決策團隊很輕易達成一致，有一些則否則。團隊成員會有意見衝突。ScrumMaster在這起到了關鍵的做用。團隊一旦達成一致決策，並按其執行，就可以讓工做環境更適應，並幫助團隊創建自組織的文化。