簡介： 本文分析了跨區(qū)域特別是跨時區(qū) Scrum 團隊項目中容易遇到的問題，并根據(jù)筆者的實際經(jīng)驗，提出了相應(yīng)的解決方案。雖然跨區(qū)域開發(fā)團隊與本地開發(fā)團隊在應(yīng)用 Scrum 上存在一些重要的差異，但這些差異造成的問題都可以通過適當(dāng)?shù)姆椒ǖ靡皂樌鉀Q。

Scrum 團隊項目基本特性

Scrum 是一個敏捷開發(fā)框架，在這個框架中，整個開發(fā)周期被分為若干個小的迭代周期，每個小的迭代周期稱為一個 Sprint，每個 Sprint 的建議長度為 2 到 4 周。Scrum 以經(jīng)驗過程控制理論為依據(jù)，采用迭代、增量的方法來提高產(chǎn)品開發(fā)的可預(yù)見性，并控制風(fēng)險。

Scrum 團隊中的主要角色包括：

產(chǎn)品負責(zé)人（Product Owner，以下簡稱為PO） 負責(zé)確定產(chǎn)品的方向和愿景，維護產(chǎn)品Backlog（按照商業(yè)價值排序的需求列表，列表條目的表現(xiàn)形式通常為 User Story），定義產(chǎn)品發(fā)布的內(nèi)容、優(yōu)先級及交付時間。在每個 Sprint 開始前，PO 應(yīng)整理產(chǎn)品 Backlog 條目，以確保其定義清晰且分解適當(dāng)，并調(diào)整 Backlog 條目的優(yōu)先級；在 Sprint 結(jié)束時，PO 有權(quán)接受或拒絕接受開發(fā)團隊的工作成果。

Scrum Master 作為 Team Leader 和 PO 緊密合作，負責(zé)確保 Scrum 被理解并實施，是 Scrum 團隊中的服務(wù)型領(lǐng)導(dǎo)。Scrum Master 應(yīng)及時地為團隊成員提供幫助，移除項目實施中遇到的障礙，保證各個角色及職責(zé)的良好協(xié)作，同時作為團隊與外部的接口，屏蔽外界對團隊成員的干擾，從而保證開發(fā)過程按計劃順利進行。

開發(fā)團隊 (Team) 一個跨職能且自組織的小團隊，人數(shù)一般建議為 5 - 9 人。整個團隊需擁有交付可用軟件所需要的各種技能，團隊成員應(yīng)協(xié)同配合，在每個 Sprint 中將選定的產(chǎn)品 Backlog 條目轉(zhuǎn)化為潛在可交付的功能增量。

下面的圖形反映了Scrum 團隊中各個角色的基本關(guān)系：

圖 1. Scrum 團隊

Scrum 短周期迭代，小步快跑的開發(fā)模式?jīng)Q定了開發(fā)目標(biāo)必須明確，同時對所有開發(fā)過程中遇到的問題必須盡快解決。為此，Scrum Master 需負責(zé)發(fā)起并組織以下活動：

Sprint 計劃會議 (Sprint Planning Meeting)

每日站會 (Daily Scrum Meeting)

Sprint 評審會議 (Sprint Review Meeting)

Sprint 回顧會議 (Sprint Retrospective Meeting)

在 Sprint 計劃會議中，PO 根據(jù)團隊的能力及以往的表現(xiàn)，與團隊成員一起從產(chǎn)品 Backlog 中挑選最有價值（或風(fēng)險最大）的條目，經(jīng)過初步估算，確定出下一個 Sprint 的工作目標(biāo)（即明確做什么），進而由開發(fā)團隊對挑選出的條目進行分析、討論和進一步估算形成任務(wù)列表（即明確怎么做）。

每日站會中，每個團隊成員通過回答“從上次會議到現(xiàn)在都完成了哪些工作”，“下次每日會議之前準(zhǔn)備完成什么工作”，“工作中遇到了哪些障礙”，來加強團隊成員的交流溝通，提高每個成員對項目的認知程度，檢驗項目實施情況，并通過快速決策，排除開發(fā)過程中遇到的障礙，保證項目的順利進行。

Sprint 評審會議在 Sprint 的末尾舉行，通過成果展示，圍繞團隊在 Sprint 內(nèi)完成的可交付物來確定目標(biāo)完成情況，并為后續(xù) Sprint 計劃提供參考。

Sprint 回顧會議通過回顧已經(jīng)完成的 Sprint，總結(jié)經(jīng)驗教訓(xùn)，確定做出什么樣的改善可以使接下來的 Sprint 更加高效、更加令人滿意，從而實現(xiàn)對開發(fā)過程的持續(xù)改進。

跨區(qū)域Scrum團隊面臨的挑戰(zhàn)

Scrum 通過加強溝通快速解決項目實施過程中遇到的問題，同時通過對各個 Sprint 的回顧和評審，來改進開發(fā)過程，并為后續(xù) Sprint 提供參考，有效地保證了 Scrum 短周期迭代的順利進行。

但是，對于跨區(qū)域 Scrum 團隊，尤其是分布在不同時區(qū)的 Scrum 團隊（如筆者參與開發(fā)的項目，就涉及分布在亞洲和北美洲的 3 個時區(qū)的數(shù)個開發(fā)團隊）而言，則面臨著許多新的問題，主要表現(xiàn)在：

會議成本增加，有時很難進行面對面溝通，每日站會往往無法全員參加。

項目啟動的 Sprint 計劃會議往往需要相對較長時間（數(shù)小時到一天），處在其他區(qū)域的 PO 往往在時間上無法保證。
由于無法進行實時溝通，一旦項目進行過程中出現(xiàn)之前無法預(yù)料的問題，尤其是是功能模塊或接口的相互依賴問題，所造成的時間延遲往往比本地項目出現(xiàn)類似問題所造成的延遲要多得多，從而直接影響受影響團隊 Sprint 目標(biāo)的達成。

解決方案

在筆者參與的跨區(qū)域 Scrum 開發(fā)團隊中，為了解決以上問題，項目團隊以 Scrum 指導(dǎo)原則為基礎(chǔ)，對項目團隊的工作作出調(diào)整，并提出了幾個有針對性的解決方案。

團隊代表制，解決跨區(qū)域 Scrum 會議問題

組成 Scrum of Scrums 團隊，采用 Weekly Scrum Meeting（每周電話或電視會議）同步各 Scrum 團隊項目進展情況，并重點解決團隊依賴問題；同時成立獨立的架構(gòu)咨詢團隊，負責(zé)協(xié)助在會后討論并解決（主要以郵件的形式）在該會議上無法快速解決的團隊依賴問題。

由于涉及多個時區(qū)的原因，每周電話或電視會議無法保證在工作時間舉行，因此，由各團隊成員輪流參加，各 Scrum 團隊每周派一名代表提前收集意見，為會議作準(zhǔn)備，并代表本 Scrum 團隊在會議上發(fā)言。會議的內(nèi)容除匯報各 Scrum 團隊的進度外，還包括：是否對產(chǎn)品的公共模塊作出了重大修改，是否有大量的代碼提交，是否在某一方面依賴于其他 Scrum 團隊的工作，是否需要其他 Scrum 團隊提供技術(shù)支援（就某一技術(shù)問題提供專家意見，并非直接參與項目的實施），并預(yù)告重大的架構(gòu)調(diào)整及受影響的模塊，預(yù)告即將引入的新技術(shù)或功能及可能帶來的影響等等。

此外，架構(gòu)咨詢團隊還負責(zé)為各開發(fā)團隊提供架構(gòu)設(shè)計方面的指導(dǎo)，最大程度上減少團隊依賴問題的產(chǎn)生。

對于 Scrum 團隊的設(shè)置，雖然本地團隊可以更好地保證溝通的質(zhì)量和效率，但在大多數(shù)的情況下，并不要求同一 Scrum 團隊的所有成員處在同一地點或同一時區(qū)?，F(xiàn)代通信手段豐富多樣，只要保證溝通順暢，Scrum 團隊的設(shè)置應(yīng)以相互配合、相互補充為主要考慮因素，保證團隊自我管理、獨立解決問題的能力，這在一定程度上也可以解決前面提到的團隊依賴的問題。

提前準(zhǔn)備，保證跨區(qū)域情況下 Sprint 的順利啟動

采用多核制，除整個產(chǎn)品的 PO 外，設(shè)立本地 PO（一般由 People Manager 兼任）。結(jié)合上面提到的 Scrum of Scrums 的組織形式，整個 Scrum 團隊的結(jié)構(gòu)如下圖所示：

圖 2. 本地 PO 及 Scrum of Scrums 團隊

在下一 Sprint 計劃會議開始前數(shù)天，由本地 PO 及其他核心成員與產(chǎn)品 PO 討論下一個 Sprint 需要完成的 Backlog 條目，對所有備選 Backlog 條目排列優(yōu)先級（由于各 Scrum 團隊在設(shè)立時在技術(shù)上往往有所偏重，某一 Scrum 團隊備選 Backlog 條目應(yīng)該是全部有效 Backlog 條目的子集），指出哪些條目必須在下一個 Sprint 內(nèi)完成，哪些條目應(yīng)盡可能安排進下一個 Sprint，哪些條目可以視情況而定，作為本地 Scrum 團隊 Sprint 計劃會議的前期準(zhǔn)備，即 Sprint 計劃會議需要解決的“做什么”的問題在會議開始前已經(jīng)基本明確。

實際的 Sprint 計劃會議將由本地 PO 負責(zé)，從已由產(chǎn)品 PO 確定優(yōu)先級的條目中根據(jù)團隊的容量（即 Capacity，由于休假、培訓(xùn)、人員變動等因素，團隊的容量在不同 Sprint 間往往是變化的）選取待完成的條目，進行評估與分解，并于 Sprint 計劃會議結(jié)束后進行整理，并交由產(chǎn)品 PO 確認。如果必要的話，可以在次日或當(dāng)日晚些時候由本地 PO 與產(chǎn)品 PO 舉行較為簡短的會議，來審查經(jīng)過本地 Scrum 團隊二次討論過的 Sprint 計劃，得到產(chǎn)品 PO 的確認或局部調(diào)整意見。由于之前已經(jīng)經(jīng)過產(chǎn)品 PO 的初步確認，此時需要進行調(diào)整的可能性往往很小。這樣，Scrum 團隊就可以快速開始新的 Sprint 的開發(fā)工作，避免不必要的延遲。

充分調(diào)研，未雨綢繆，避免架構(gòu)缺陷及團隊依賴

各區(qū)域由核心成員組成核心團隊，將調(diào)研及討論工作提前，在前一個 Sprint 的中后期開始下一個 Sprint 可能需要完成的 Backlog 條目的分析調(diào)研工作，以達到在前一個 Sprint 結(jié)束前充分理解下一個 Sprint 需要完成的工作的目的。

對于重要的架構(gòu)設(shè)計問題，應(yīng)與架構(gòu)咨詢團隊協(xié)商討論決定；對于存在團隊依賴的情況，也應(yīng)通過 PO（或技術(shù)負責(zé)人）協(xié)調(diào)各 Scrum 團隊的工作安排，將相互依賴的兩個模塊安排在兩個 Sprint 內(nèi)完成（必要時，也可以安排在一個 Sprint 的前期和后期完成，但這種情況下，需要兩個團隊加強配合，及時溝通進度，并盡可能留出緩沖時間），從而最大程度上降低后期架構(gòu)風(fēng)險出現(xiàn)的可能，并避免團隊依賴。

總結(jié)

跨區(qū)域開發(fā)團隊，特別是跨時區(qū)開發(fā)團隊，與一般的本地開發(fā)團隊存在一些重要的差異，但只要我們采用適當(dāng)?shù)姆绞絹斫鉀Q這些差異所造成的問題，跨區(qū)域開發(fā)團隊也可以適應(yīng)短周期迭代的開發(fā)模式，順利采用 Scrum 進行產(chǎn)品開發(fā)。