CODING 告訴你如何創建一個 Scrum 團隊

原文地址：www.atlassian.com/agile/scrum…
翻譯君：CODING 敏傑小王子

Scrum 當中有三個角色：PO（product owner），敏捷教練（scrum master）和開發團隊。雖然這看起來很清晰，但如何處理現有職位的問題可能會讓人感到困惑。許多團隊詢問在採用 scrum 時是否須要更改崗位名稱？最簡潔的答案是「不」。在本文中，咱們將討論 scrum 的角色定義以及如何將它們融進你的組織中，而你無需打印新的崗位名片。

Scrum 角色 VS 崗位職稱

這三個 scrum 角色描述了 scrum 團隊成員的主要責任，他們並非崗位職稱。這意味着任何職稱，即便是現有職位，也能夠承擔其中一個角色。由於 scrum 的本質是經驗主義、自我組織和持續改進，因此這三個角色給出了責任的最小定義，以容許團隊有效地工做。這使得團隊能夠對他們的自我組織和持續改進負責。
參考閱讀：scrumguides.org/scrum-guide…

創建一個 Scrum 團隊

Scrum 是一個團隊構建運做流程的框架。它提供了按期會議和誰作什麼的基本結構。 它不爲團隊提供一個適合全部人的模型。例如，若是團隊正在開發 Web 保險應用程序，他們須要瞭解技術、後端系統和業務領域的人員。另外一方面，若是團隊正在研究下一代大金剛，那麼所需的技能將會大不相同。他們須要平面設計師，音響工程師和圖形開發人員。因爲問題不一樣，所需的團隊結構和技能也不一樣。

團隊試圖解決的問題越複雜，團隊運做就變得愈來愈困難。正如那句老話：「你不知道你不知道什麼，直到你知道你不知道」。團隊可能不知道預先須要的技能或工做量，而且須要具有必定的靈活性，一旦他們瞭解更多後就能夠輕鬆地改變學習方向。

爲了給這個複雜、不斷變化且常常使人討厭的世界提供一些結構，scrum 提供了輕量級團隊結構，包括開發團隊，PO 和敏捷教練的三個 scrum 角色。

開發團隊：從新定義「開發人員」

開發團隊是開展工做的人員。乍一看可能認爲「開發團隊」意味着工程師。但狀況並不是老是如此。根據 scrum 指南，開發團隊能夠由各類各樣的人組成，包括設計師、文檔工程師、程序員等。

你能夠像進行一個房屋項目聘請開發人員同樣考慮它。這可能意味着他們須要鋪磚，作管道，甚至挖洞，這我的被稱爲開發商。所以，scrum 中的「開發人員」角色意味着擁有合適技能的團隊成員，做爲團隊的一部分來完成工做。
參考閱讀：www.scrum.org/resources/w…
Scrum 指南：www.scrumguides.org/

Scrum 神話：Scrum 開發人員意味着只有編程人員才能成爲 Scrum 團隊的一員。

開發團隊應該可以自我組織，這樣他們能夠本身作出決定來完成工做。能夠將開發團隊視爲相似於由於出現了問題而被夜間呼叫的生產環境支撐團隊。與生產環境支撐團隊同樣，開發團隊能夠制定決策併爲手頭的問題提供修復/價值。自組織不意味着對組織不尊重，而是爲了讓最接近工做的人可以爲解決問題採起實質行動。

開發團隊的職責包括：

• 經過迭代交付工做。
• 爲了確保衝刺期間的工做透明度，他們天天都會在晨會中碰頭（有時稱爲站立）。站立會議爲工做提供透明度，併爲團隊成員尋求幫助、談論成功經驗以及突出問題和障礙提供了一個專門的場所。敏捷教練可能會促進站立會議，但最終由開發團隊負責運行此會議。他們的會議是幫助他們做爲一個總體，以更有效的方式檢查和調整他們正在作的工做。

PO：明確方向

敏捷團隊在設計上具備靈活性和快速響應的特質，PO 有責任確保團隊提供的價值最大化。業務由產品全部者（即 PO）表明，他會告訴開發什麼是重要的交付內容。這兩種角色之間的信任相當重要。

PO 不只要了解客戶，還要了解 scrum 團隊爲客戶提供的價值。PO 還能夠平衡組織中其餘利益相關者的需求。

所以，PO 必須掌握對全部工做的輸入並肯定優先順序。這多是他們最重要的責任，由於衝突的優先級和不明確的方向不只會下降團隊的效率，還會破壞業務人員與開發團隊之間的重要信任關係。

敏捷團隊旨在即時檢查和隨時調整，這意味着優先級的變化可能會致使團隊結構、工做產出以及最終結果的巨大變化。所以，對於 scrum 團隊而言，成功的關鍵是隻有一我的可以肯定優先權，那我的是 PO。

Scrum 指南將 PO 的職責定義爲：

• 管理 backlog —— 這並不意味着他們是惟一一個將新的 backlog 項目放入待辦事項的人。但他們對開發團隊須要交付的 backlog 事項負責。這意味着 PO 應該瞭解待辦事項中的全部內容，當其餘人將添加事項到產品 backlog 當中時應確保他們與 PO 溝經過。
• 發佈管理 —— 迭代不是發佈週期，而是計劃週期。這意味着 scrum 團隊能夠隨時交付產品。理想狀況下，他們會在整個迭代中頻繁交付，能夠在迭代回顧查看真實的客戶使用狀況和反饋。可是持續交付並非總能保持的一種狀態，而且其它發佈模型也是必要的。PO 必須知道何時可以而且應該發佈。
• 利益相關者管理 —— 任何產品都會涉及許多利益相關者，包括用戶、客戶、公司高層和組織領導。PO 必須與這些人合做，以確保開發團隊提供真正的價值。這可能意味着 PO 須要與各個利益相關者進行溝通。

Scrum 神話：PO 制定全部要求，編寫全部驗收標準並建立全部需求。

Scrum master：把它們融合在一塊兒

Scrum 管理員負責把 scrum 相關的一切都融合在一塊兒，並確保 scrum 在團隊中運做良好。這意味着他們能夠幫助 PO 定義價值，幫助開發團隊交付商業價值，幫助 scrum 團隊運做地更好。敏捷教練是一個僕人式的領導者角色，這個角色不只描述了支持性的領導風格，還描述了他們平常工做的內容。

敏捷教練經過幫助 PO 更好地理解和傳達價值、管理 backlog、與團隊一塊兒規劃分解工做輸出最有效的經驗，來更好地爲 PO 服務。敏捷教練也爲開發團隊服務，幫助他們自我組織，專一於結果，實現「增量式工做」，並管理工做中的障礙。敏捷教練還爲整個組織提供服務，幫助他們瞭解 scrum 是什麼，建立能夠良好運做 scrum 的環境。

Scrum 神話：敏捷教練必須每日運行 scrum 相關機制。實際上，敏捷教練不運行任何事務只是確保它們可以正常運行。

敏捷教練專一於：

• 透明度 —— 爲了支持團隊可以有效地自我檢查和調整，對應的人員須要看到對應發生的事情。但這事作起來比看起來難。敏捷教練的任務是確保 scrum 團隊以透明的方式工做。好比建立故事地圖和使用回顧性思惟來更新彙總信息頁面。
• 經驗主義 —— scrum 和敏捷的一個基本方法是，達到目標的最好方式是去作並從中學習。積累經驗的過程並不容易，須要敏捷教練指導團隊分解工做、描述明確的結果並回顧這些結果。
• 自組織 —— 告知開發團隊他們能夠自我組織，那麼他們就會去自我管理。事實上，團隊在自我組織的過程當中隨着時間的推移，會須要幫助和支持。敏捷教練會鼓勵團隊成員走出他們的溫馨區並嘗試不一樣的事情，並使用諸如「委託撲克」之類的作法來揭露和挑戰有關角色界限和職責的預設想法。 參考閱讀：management30.com/product/del…
• 價值觀 —— scrum 定義了勇氣、專一、承諾、尊重和開放的 5 個價值觀，不是由於它們很友善，而是由於它們創造了安全和信任的環境。這種環境對於團隊的茁壯成長很是必要。遵循這些價值觀是 scrum 團隊中每一個人的責任，而敏捷教練在鼓勵和提醒每一個人遵照這些價值觀的方面發揮了積極做用。

敏捷教練在迭代規劃和迭代回顧中爲 PO 提供服務，確保描述準確並設置方向。他們經過維持事務正常運做、移除工做阻礙爲平常的開發團隊服務。他們還對團隊沒法解決的障礙負責。敏捷教練確保每一個改進的機會都對 scrum 團隊透明，而且有一系列明確的結果可供回顧。

開始使用敏捷 Scrum 角色

在只描述任何 scrum 團隊中三個主要責任區域時，這三個 scrum 角色理解起來很是簡單。但一般很難將它們映射到企業當中的崗位職稱。因此下面的實踐將幫助你更好地開始：

• 若是你擁有很多提供客戶價值的優秀技能，而且提供價值這件事令你無比興奮，那麼你應該成爲一名 scrum 開發團隊成員。實際上，團隊是任何敏捷組織中最重要的元素，由於他們爲客戶和利益相關者提供了價值。這意味着你的資歷取決於你能提供多少價值或幫助他人作到這一點。
• 若是你對客戶、企業利益相關者和業務領域充滿熱情，那麼 PO 最適合你的需求。在大多數組織中，這我的須要獲得業務方面的尊重和信任，所以他們能夠作出決策。當你權衡利弊並但願讓每一個人都開心時，這個角色就須要必定程度的「政治活動技巧」。
• 若是你想幫助團隊有效地一塊兒工做，並但願經過 scrum 和敏捷改變世界，那麼敏捷教練的角色非你莫屬。這是一個以人爲中心的角色，很是注重指導、教學和輔導。

CODING 敏捷模塊幫助 scrum 各個角色輕鬆搞定敏捷項目管理。