Nexus 指南 以 Nexus 規模化 Scrum 的權威指南 : 遊戲規則 2018 年 1 月 由 Ken Schwaber 與 Scrum.org 開發並持續維護 繁體中文 /Chinese-Traditional 0
目錄 Nexus 概觀... 2 Nexus 指南的目的... 2 Nexus 的定義... 2 Nexus 的背景... 2 Nexus 框架... 3 Nexus 流程... 4 Nexus... 5 Nexus 角色... 5 Nexus 整合團隊... 5 Nexus 整合團隊的產品負責人... 6 Nexus 整合團隊的 Scrum Master... 6 Nexus 整合團隊組員... 6 Nexus 活動... 6 需求精煉... 6 Nexus 衝刺規劃... 7 Nexus 衝刺目標... 7 Nexus Daily Scrum... 7 Nexus 衝刺評審... 8 Nexus 衝刺回顧... 8 Nexus 工作物件... 9 產品待辦需求... 9 Nexus 衝刺待辦需求... 9 整合遞增成品... 9 工作物件透明度... 10 完成 定義... 10 結語... 10 致謝... 10 翻譯... 10 Nexus 指南在 2015 版與 2018 版之間的變更... 11 Page 1
Nexus 概觀 Nexus 指南的目的 Nexus 是一個用來開發與維護規模化產品與軟體交付的框架 Nexus 由 Scrum 建構而成 本指南 涵蓋了 Nexus 的定義 這個定義由 Nexus 角色 活動 工作物件 與整合這些內容的規則所組 成 Ken Schwaber 與 Scrum.org 發展 Nexus 框架, 並且編寫及提供 Nexus 指南 Nexus 的定義 Nexus ( 名詞 ): 一種人或物之間的關係或連結 Nexus 是一個包含了角色 活動 工作物件 及規則的框架 結合約三至九個開發同一產品的 Scrum 團隊的工作, 建造整合遞增成品以滿足一個跨團隊的共同目標 Nexus 的背景 軟體交付是複雜的, 一個 完成 的成果須要整合協調許多的工作物件與活動 這些工作需要被組織 安排順序 消除依賴 並設立階段產出成果 許多開發者使用 Scrum 框架協同合作, 開發並交付可用的軟體遞增成品 然而, 當兩個以上 Scrum 團隊使用同一份產品待辦需求與產品程式碼, 共同開發一個產品時, 常會面對新的困難 如果這些開發者分別處在不同位置的團隊, 他們要如何溝通工作中對彼此的影響? 如果他們在不同的團隊中工作, 他們要如何整合產出 測試整合遞增成品? 兩個 Scrum 團隊協同開發同一產品時會面臨這些挑戰, 在三個或更多 Scrum 團隊協同開發同一產品時明顯地更加困難 為了在至少每個衝刺, 協作產出 完成 的遞增成品, 團隊間工作會產生許多依賴 這些依賴涉及 : 1. 需求 : 需求之間可能有重疊的範圍, 實作方式可能彼此影響 在排序產品待辦需求與挑選產品待辦需求項目時應該考量這些重疊與影響 Page 2
2. 領域知識 : 團隊成員擁有不同的商業與電腦系統知識 他們的知識應被分散至各 Scrum 團隊, 確保各團隊有完成工作所需的知識, 將衝刺進行中 Scrum 團隊間的干擾降至最低 3. 軟體與測試工作物件 : 需求最終會以軟體的形式來實現 在需求領域中, 分配團隊成員的知識與軟體工作物件來組成多個相似的 Scrum 團隊, 讓團隊可以降低彼此間依賴的數量當運用 Scrum 進行規模化軟體交付時, 開發團隊的組成應該優先考量需求 領域知識 軟體工作物件等依賴性, 這樣的團隊組成能夠將生產力最佳化 Nexus 框架 Nexus 是一種多 Scrum 團隊共同建立整合遞增成品的程序框架 Nexus 與 Scrum 有一致性, 使用過 Scrum 的人會對它的內容非常熟悉 不同之處在於 Nexus 更加關注 Scrum 團隊間的依賴與互動, 確保每個衝次都能交付 完成 的整合遞增成品 Nexus 框架, 規模化 Scrum 如圖所示,Nexus 的組成包括 : 角色 :Nexus 中有一個新的角色 - Nexus 整合團隊, 負責協調 指導 與監督 Nexus 的實施以及 Scrum 的運作以利交付最好的產出結果 Nexus 整合團隊由產品負責人 Scrum Master 及 Nexus 整合團隊組員所組成 Page 3
工作物件 : 各 Scrum 團隊使用同一份產品待辦需求 產品待辦需求項目經過精煉並準備完成, 讓衝刺中各團隊應執行的工作變得透明 Nexus 以一個新的工作物件來提高衝刺中的透明度 - Nexus 衝刺待辦需求 各 Scrum 團隊則維護自己的衝刺待辦需求 活動 :Nexus 活動新增 擴充 或取代 ( 如衝刺評審 ) 一般 Scrum 中的活動 這些調整是為了兼顧 Nexus 中各別 Scrum 團隊, 以及所有團隊的總成果 Nexus 流程 一個 Nexus 由多個協同工作並在每個衝刺結束前交付潛在可發佈整合遞增成品的跨功能 Scrum 團隊所組成 各團隊可基於依賴關係進行自我組織並選擇最合適的成員來執行特定工作 精煉產品待辦需求 : 產品待辦需求須要經過分解來辨識其中的依賴性, 並且把它消除或最小化 透過精煉讓產品待辦需求項目的功能性變得單純, 此外應該識別出可能執行這項需求的團隊 Nexus 衝刺規劃 : 各 Scrum 團隊的適當代表進行討論與檢視精煉過的產品待辦需求 這些代表選擇各自團隊預計執行的產品待辦需求項目 各 Scrum 團隊依此規劃各自的衝刺並適當地與其它團隊互動 這個程序的產出結果是支撐起 Nexus 衝刺目標的各別衝刺目標 每個 Scrum 團隊的衝刺待辦需求 以及一份 Nexus 衝刺待辦需求 Nexus 衝刺待辦需求可以讓所有 Scrum 團隊選擇的產品待辦需求項目工作與依賴關係透明化 開發工作 : 所有團隊頻繁地將它們的工作整合至一個可以進行整合測試的共用環境 Nexus Daily Scrum: 各開發團隊的適當代表每天討論以確認是否有整合上的議題 如果有發現整合議題, 將這個資訊帶回各別 Scrum 團隊的 Daily Scrum 確保在各別 Scrum 團隊的 Daily Scrum 時有提出這些整合議題 Nexus 衝刺評審 :Nexus 衝刺評審在衝刺結束前舉行, 提供對這個衝刺 Nexus 建置的整合遞增成品的回饋 所有的 Scrum 團隊與利害關係人一起檢視整合遞增成品 產品待辦需求可能因此進行調整 Nexus 衝刺回顧 : : 各 Scrum 團隊的適當代表進行討論以辨別出共同面臨的挑戰 各 Scrum 團隊接著舉行各自的衝刺回顧 然後各 Scrum 團隊的適當代表基於各團隊群體智慧提供的意見再次討論要採取的行動 Page 4
Nexus Nexus 的角色 活動 與工作物件的作用繼承了 Scrum 中對應的角色 活動 與工作物件, 如 Scrum 指南中所描述 (www.scrumguides.org). Nexus 角色 Nexus 由 Nexus 整合團隊與大約 3 到 9 個 Scrum 團隊所組成 Nexus 整合團隊 Nexus 整合團隊負責確保每個衝刺至少能產出一次 完成 的整合遞增成品 ( 整合工作由 Nexus 完成 ) 如 Scrum 所要求,Scrum 團隊負責交付 完成 的潛在可發佈產品遞增成品 Scrum 指南中指定了 Scrum 團隊所有成員的角色 Nexus 整合團隊由以下組成 : 產品負責人 Scrum Master 一或多個 Nexus 整合團隊組員 Nexus 整合團隊組員通常也是其中的 Scrum 團隊成員 在這個情況下, 他必須以 Nexus 整合團隊的工作優先 Nexus 整合團隊的組員身份優先於各別 Scrum 團隊的成員身份 這樣的優先順序有助於確保影響多個團隊的議題能被優先處理 隨著時間,Nexus 整合團隊組成可能依照當時的需求變更 Nexus 整合團隊的一般活動可能包括指導 諮詢 及指出依賴關係與跨團隊議題 他們也可能執行產品待辦需求上的工作 Scrum 團隊提出 Nexus 中的整合議題,Nexus 整合團隊則提供 Nexus 對整合的聚焦點 這裡的整合, 包括解決所有妨礙 Nexus 持續交付整合遞增成品的跨團隊技術或非技術約束 他們應利用 Nexus 中各團隊由下而上的群體智慧來解決這些問題 Page 5
Nexus 整合團隊的產品負責人一個 Nexus 只有一份產品待辦需求, 而依據 Scrum 框架, 一份產品待辦需求由一名產品負責人來最終決定其內容 產品負責人負責將產品的價值最大化, 工作的執行與整合則由 Nexus 中的 Scrum 團隊來進行 產品負責人是 Nexus 整合團隊的成員產品負責人負責管理產品待辦需求, 最大化 Nexus 產出的整合遞增成品價值 作法可能會視不同組織 不同 Nexus 不同 Scrum 團隊 或不同人而有很大的差異 Nexus 整合團隊的 Scrum Master Nexus 整合團隊的 Scrum Master 負責確保整個 Nexus 了解 Nexus 框架並依此執行 這個 Scrum Master 可以同時是這個 Nexus 中一或多個 Scrum 團隊的 Scrum Master Nexus 整合團隊組員 Nexus 整合團隊中應包括熟悉工具 開發實務 與系統工程的專家 Nexus 整合團隊組員確保 Nexus 中各 Scrum 團隊了解 實施這些開發實務 工具, 找出依賴性及頻繁地整合產出物件以滿足 完成 定義 Nexus 整合團隊組員負責指導 Nexus 中的 Scrum 團隊養成 實施 並學習這些開發實務與工具 此外,Nexus 整合團隊也指導各 Scrum 團隊符合組織的開發 基礎結構 與架構標準, 確保開發出品質好的整合遞增成品 如果他們滿足了主要責任,Nexus 整合團隊組員也可以作為各 Scrum 團隊中的開發團隊成員進行工作 Nexus 活動 Nexus 活動的時間長度與 Scrum 指南中的對應事件一樣, 除了對應的 Scrum 活動,Nexus 活動也是有限時活動 需求精煉在規模化中對產品待辦需求進行需求精煉有二個目的 幫助 Scrum 團隊預估哪個團隊將交付哪些產品待辦需求項目, 及指出跨團隊的依賴關係 透明度讓團隊可以監看依賴關係並將它降到最低 Page 6
Nexus 持續對產品待辦需求項目精煉, 直到項目夠獨立足以讓單一 Scrum 團隊工作而不發生過度的衝突 需求細部化會議的次數 頻率 時間長度 與出席者取決於產品待辦需求中的依賴關係與不確定性 龐大與模糊的產品待辦需求項目須經過多個層級的拆解, 讓一個 Scrum 團隊可以在一個衝刺內交付 如有需要並合適, 需求精煉可在衝刺當中不斷進行 為了讓產品待辦需求項目準備好在 Nexus 衝刺規劃活動中被選擇, 各別 Scrum 團隊會持續對產品待辦需求進行精煉 Nexus 衝刺規劃 Nexus 衝刺規劃的目的是協調 Nexus 中所有 Scrum 團隊在這個衝刺中的活動 產品負責人提供領域知識 指導選擇和優先順序決定 產品待辦需求應該在 Nexus 衝刺規劃之前被充分精煉, 找出依賴關係並消除或減至最低 Nexus 衝刺規劃中, 各別 Scrum 團隊的適當代表確認與調整在需求精煉產生的工作的順序 為了最小化溝通議題, 所有 Scrum 團隊的成員應該出席這個活動 產品負責人在 Nexus 衝刺規劃時說明 Nexus 衝刺目標 Nexus 衝刺目標描述了各 Scrum 團隊在這個衝刺應達成工作的目的 了解 Nexus 的整體工作後,Nexus 衝刺規劃的下一階段是讓各 Scrum 團隊進行各自的衝刺規劃 Scrum 團隊間應持續與 Nexus 中的其它 Scrum 團隊分享他們新發現的依賴關係 當各 Scrum 團隊結束各自的衝刺規劃後,Nexus 衝刺規劃也就隨著完成 在 Nexus 衝刺規劃時會增加新的依賴關係 這些依賴關係應該被透明化及最小化 團隊之間的工作順序也可能會隨著調整 充分精煉產品待辦需求會降低 Nexus 衝刺規劃時新增的依賴關係 所有在這個衝刺被選擇的產品待辦需求項目和它們的依賴關係要在 Nexus 衝刺待辦需求上被透明化 Nexus 衝刺目標 Nexus 衝刺目標是一組當前衝刺目的的集合 它是 Nexus 中各 Scrum 團隊的衝刺目標與工作的總合 Nexus 應在 Nexus 衝刺評審時展示開發 完成 的功能性能達成 Nexus 衝刺目標, 以便取得利害關係人的回饋 Nexus Daily Scrum Nexus Daily Scrum 是讓各別開發團隊適當的代表檢驗當前整合狀態, 並提出整合問題或新發現的跨團隊依賴或影響的活動 Page 7
在 Nexus Daily Scrum 時, 參加者應該專注各團隊整合遞增成品受到的影響並討論 : 昨天的工作是否有成功整合? 如果沒有, 為什麼? 找出了什麼新的依賴關係或影響? 有什麼資訊應該分享給 Nexus 中的其它團隊? 開發團隊利用 Nexus Daily Scrum 檢驗 Nexus 衝刺目標被達成的進度 至少每次 Nexus Daily Scrum 時, 應調整 Nexus 衝刺待辦需求以反映 Nexus 中各 Scrum 團隊對當下狀態的理解 各別 Scrum 團隊接著將在 Nexus Daily Scrum 中找出的問題與工作, 帶回各自的 Daily Scrum 中進行規劃 Nexus 衝刺評審 Nexus 衝刺評審在衝刺結束前舉行, 用來提供對 Nexus 在這個衝刺產出的整合遞增成品的回饋, 並在需要時調適產品待辦需求 Nexus 衝刺評審取代了各別 Scrum 團隊的衝刺評審, 因為要聚焦在取得利害關係人對整合遞增成品的回饋 在這個活動上可能無法展示所有完成工作的細節 需要一些技巧來最大化利害關係人的回饋 Nexus 衝刺評審的成果是修訂後的產品待辦需求 Nexus 衝刺回顧 Nexus 衝刺回顧是一個讓 Nexus 自我檢驗與調適, 並建立下個衝刺的改善行動計畫以確保能持續改善的正式機會 Nexus 衝刺回顧在 Nexus 衝刺評審與下次的 Nexus 衝刺規劃間舉行 Nexus 衝刺回顧由三部份組成 : 1. 第一部份由 Nexus 中各團隊的適當代表進行討論, 找出會影響超過一個團隊的議題 目的是讓共同議題對所有的 Scrum 團隊變得更透明 2. 第二部份是讓各別 Scrum 團隊各自進行 Scrum 框架中的衝刺回顧 他們可以把第一部份找出的議題投入這個活動中進行討論 各別 Scrum 團隊應在活動中提出用來應對這些議題的行動 3. 最後, 第三部份是讓 Nexus 中各團隊的適當代表再次進行討論, 如何讓這些應對行動可被視覺化與追蹤 這樣讓 Nexus 可以作為一個整體來進行調適 Page 8
每次回顧都該討論以下在規模化中常見的障礙 : 是否留下任何未完成的工作?Nexus 是否產生了技術債? 是否所有的產出物件, 特別是程式碼, 都頻繁的 ( 每天 ) 成功整合? 軟體成功建置 測試 與部屬的頻率是否足以防止累積太多未解析的依賴關係? 對於以上的問題, 在有需要時討論 : 為什麼會發生? 技術債如何消除? 如何防止再次發生? Nexus 工作物件 如 Scrum 指南中所描述, 工作物件代表用來提供透明度與檢驗 調適機會的工作或價值 產品待辦需求 整個 Nexus 與其中所有 Scrum 團隊只有一份產品待辦需求 產品負責人對這份產品待辦需求負 責, 包括內容 可用性 與排序 在規模化的情境下, 產品待辦需求須被理解到能夠找出 最小化依賴關係的程度 產品待辦需求 項目常被解析到被稱為功能 薄片 (thinly sliced) 的大小 當產品待辦需求項目沒有或已將對其 它 Scrum 團隊的依賴降到最低, 這個項目被視為 準備完成 (ready) 可在 Nexus 衝刺規劃上被 Scrum 團隊選擇 Nexus 衝刺待辦需求 Nexus 衝刺待辦需求是各 Scrum 團隊的衝刺待辦需求中產品待辦需求項目的組合 它被用來強 調衝刺中的依賴關係與工作順序 它必須至少每天更新, 常會在 Nexus Daily Scrum 執行 整合遞增成品 整合遞增成品代表當下 Nexus 所有已完成整合的工作的總合 整合遞增成品必須符合 完成 定 義, 可使用且具備可以釋出的條件 整合遞增成品會在 Nexus 衝刺評審中被檢驗. Page 9
工作物件透明度 如同組成 Nexus 的 Scrum 一樣,Nexus 的基礎建立在透明度上 在 Nexus 中 Nexus 整合團隊與 Scrum 團隊協同合作, 確保所有的工作物件足夠提供透明度給團隊, 讓團隊了解整合遞增成品的整合狀態 基於 Nexus 工作物件所作決策的效力受限於工作物件透明度 不完整的資訊會導致不正確或有缺陷的決策 以 Nexus 的規模, 這些決策的影響會被放大 軟體開發必須在技術債變得讓 Nexus 不可接受前找出並解析依賴關係 缺乏透明度時不可能有效指引 Nexus 有效地將風險最小化並將價值最大化 完成 定義 完成 定義由 Nexus 整合團隊負責, 適用於每個衝刺開發的整合遞增成品 Nexus 中的所有 Scrum 團隊遵守 完成 定義 只有在產品負責人認為遞增成品已整合 可使用 且潛在可發佈時, 遞增成品才算是 完成 各別 Scrum 團隊內部可以使用更嚴格的 完成 定義, 但不能使用較寬鬆的條件 結語 Nexus 由本指南免費提供 如同 Scrum 框架,Nexus 的角色 工作物件 活動 與規則是不可變 的 雖然只實施其中的部份是可能的, 但這樣的結果不是 Nexus 致謝 Nexus 與 Scaled Professional Scrum 是由 Ken Schwaber David Dame Richard Hundhausen Patricia Kong Rob Maher Steve Porter Christina Schwaber 與 Gunther Verheyen 共同合作所開發 翻譯 這份指南由上述開發者提供的原始英文版本翻譯為繁體中文版 鄭偉鵬 Adrian Cheng, PSM II, SPS, PSD, PMI-ACP, PMP adriancwp@gmail.com Page 10
Nexus 指南在 2015 版與 2018 版之間的變更 1. Nexus 指南描述由 規模化 Scrum 開發的外框架 更新為 以 Nexus 規模化 Scrum 的權威指南 : 遊戲規則 2. 將 Nexus 定義為 一種人或物之間的關係或連結 3. 在 Nexus 程序流程章節, 變更用詞以聚焦在團隊上而不是各別成員, 一個 Nexus 由多個協同工作並在每個衝刺結束前交付潛在可發佈整合遞增成品的跨功能 Scrum 團隊所組成 此外補充 各團隊可基於依賴關係進行自我組織並選擇最合適的成員來執行特定工作 4. 更明確 Nexus 整合團隊角色 a. Nexus 整合團隊通常也是 Nexus 中各別 Scrum 團隊成員 這種組合支援了 Nexus 中各別 Scrum 團隊由下而上群體智慧的必要性 b. Nexus 整合團隊並沒有真的在執行整合的工作 整合的工作由各別 Scrum 團隊執行 c. 移除 Nexus 整合團隊也是一個 Scrum 團隊的描述 避免混淆導致 Nexus 整合團隊永久地成為 Nexus 中的一個獨立團隊 5. 需求精煉章節搬移, 成為 Nexus 衝刺規劃前的 Nexus 活動 a. 不再規定需求精煉分二部份 調整用詞以聚焦在透明度而不是視覺化 b. 移除需求精煉 會議, 僅稱為 需求精煉 c. 強調在需要且合適時, 需求精煉可在衝刺中持續進行 6. 不再指定 Nexus 目標為 Nexus 衝刺規劃的輸入或是產出, 這將視清況而定 只稱為產品負責人在 Nexus 衝刺規劃時討論的目標 移除關於共用空間必要性的用語 a. Nexus 目標改為 Nexus 衝刺目標 為保持與 Scrum 框架的一致性, 不再列為一項新的工作物件 b. 由目錄中移除 7. Nexus Daily Scrum 除了檢視跨團隊依賴外, 也是檢視跨團隊影響的機會 a. Nexus Daily Scrum 不是調整 Nexus 衝刺待辦需求的唯一時機 只是各團隊至少應在這個時候一起調整 Nexus 衝刺待辦需求以反映出他們當下對工作與跨團隊依賴的理解 b. Nexus Daily Scrum 是讓 Nexus 中開發團隊檢驗 Nexus 衝刺目標被完成進度的場合 8. Nexus 衝刺評審不是展示與說明, 在 Scrum 中也不是 新增說明這是在需要時調適產品待辦需求的機會 此外, 在 Nexus 流程 章節提出關於 Nexus 衝刺評審需要回饋的描述 9. 新增說明 Nexus 衝刺回顧是一個讓 Nexus 自我檢驗與調適並建立下個衝刺的改善行動計畫的正式機會 a. 如同 Scrum 指南的更新,Nexus 衝刺回顧的存在是為了確保 Nexus 可以持續改善 10. 整合遞增成品代表當下已整合的工作狀態 11. 完成 定義明確說明整合遞增成品必須已完成整合 12. 在 工作物件透明度 章節, 移除 測試是否有不可接受的技術債, 看進行整合時是否仍有未被解析的依賴性, 以 軟體開發必須在技術債變得讓 Nexus 不可接受前找出並解析依賴關係 取代 13. 移除軟體實務章節 雖然這是相關的重要主題, 仍需要進一步的闡述以增加其價值 14. 增加共享許可 Page 11