Nexus TM 指南 Nexus 終極指南 : 規模化 Scrum 開發的外框架 由 Ken Schwaber 與 Scrum.org 所開發與持續支援
目錄 Nexus 概述 2 Nexus 指南的目的 2 Nexus 的定義 2 Nexus 的背景 2 Nexus 框架 2 Nexus 的流程 3 軟體開發實務方法 4 Nexus 4 Nexus 的角色 4 Nexus 整合團隊 (Nexus Integration Team) 4 Nexus 的活動 5 Nexus Sprint 規劃 (Nexus Sprint Planning) 6 Nexus 每日檢視 (Nexus Daily Scrum) 6 Nexus Sprint 展示回饋 (Nexus Sprint Review) 6 Nexus Sprint 回顧 ( Nexus Sprint Retrospective) 6 需求細部化 (Refinement) 7 Nexus 的產出物件 (Nexus Artifacts) 7 產品待辦需求 (Product Backlog) 7 Nexus 目標 (Nexus Goal) 8 Nexus Sprint 待辦需求 (Nexus Sprint Backlog) 8 整合遞增成品 (Integrated Increment) 8 產出物件透明化 8 完成 的定義 (Definition of Done ) 8 附註 9 致謝 9 翻譯 9 版權所有 Scrum.org,2015 第 1 頁 ( 1.1 版本 )
Nexus 概述 Nexus 指南的目的 Nexus 是一個開發與維持規模化產品與軟體的框架 它由 Scrum 所建構而成 本指南包含了 Nexus 的定義 這個定義包括 Nexus 角色 活動 產出物件 與整合這些內容的規則 Ken Schwaber 與 Scrum.org 發展了 Nexus 框架, 並且編寫及提供 Nexus 指南 Nexus 的定義 Nexus ( 名詞 ): 開發單位 ( 在規模化專業 Scrum 中 ) Nexus 是一個包含了角色 活動 產出物件 及技巧的框架 用於將約三到九個開發同一個產品的 Scrum 團隊的工作結合起來, 建造整合遞增成品以滿足一個跨團隊的共同目標 Nexus 的背景 軟體開發是複雜的, 一個 完成 的成果須要整合協調許多的 產出物件 與活動 這些工作需要被組織 安排順序 消除依賴 並依階段產出成果 軟體本身沒有實體, 使軟體開發工作更加困難 許多軟體開發者使用 Scrum 作為團隊工作框架來進行遞增成品開發 然而, 當兩個以上 Scrum 團隊使用同一份產品待辦需求與產品程式碼, 共同開發一個產品時, 將會面對一些新的困難 如果這些開發者分別處在不同位置的團隊, 他們要如何溝通工作中對彼此的影響? 如果他們在不同的團隊中工作, 他們要如何整合產出 測試整合遞增成品? 兩個團隊協作時開始會遇到這些挑戰, 在三個或更多團隊協作時明顯地更加困難 為了在每個 Sprint 協作產出 " 完成 " 的遞增成品, 團隊間工作會產生許多依賴 這些依賴涉及 : 1. 需求 : 需求之間可能有重疊的範圍, 而實作方式可能彼此影響 在排序產品待辦需求與挑選需求時應該考量這些重疊與影響 2. 領域知識 : 團隊成員擁有不同的商業與電腦系統知識 這些知識應該被適當的分配至各團隊, 將衝刺進行中團隊間的干擾降至最低 3. 軟體與測試 產出物件 : 需求最終會以軟體程式碼與一系列的測試來實現 在需求範圍內, 分配團隊成員的知識 程式碼與測試 產出物件 組成多個相似的團隊, 可以降低團隊之間的依賴 當運用 Scrum 進行規模化軟體開發時, 團隊的組成應該優先考量需求 領域知識 軟體及測試產出物件 等依賴性, 這樣的團隊組成能夠將生產力最佳化 Nexus 框架 Nexus 是以開發同一產品的多個 Scrum 團隊為基礎的外框架 Nexus 與 Scrum 是一致的, 有 Scrum 專案工作經驗的人會對它的內容非常熟悉 差別在於,Nexus 更加關注的是 Scrum 團隊間的依賴與互動, 確保每個 Sprint 都能交付 " 完成 " 的整合遞增成品 如下圖所示,Nexus 的組成包括 : 版權所有 Scrum.org,2015 第 2 頁 ( 1.1 版本 )
角色 :Nexus 中有一個新的角色 - Nexus 整合團隊 (Nexus Integration Team), 負責協調 指導 與監督 Nexus 的實施以及 Scrum 的運作以利交付最好的產出結果 Nexus 整合團隊由一名產品負責人 (Product Owner) Scrum Master 及 Nexus 整合團隊組員所組成 產出物件 (Artifacts): 各 Scrum 團隊使用同一份產品待辦需求 產品待辦需求項目經過精 鍊 並準備完成後, Sprint 中團隊執行工作的指標變得視覺化 Nexus 用一個新的產出物件來提高 Sprint 中的透明度 - Nexus Sprint 待辦需求 (Nexus Sprint Backlog) 各 Scrum 團隊則維護自己的 Sprint Backlog 活動 :Nexus 活動新增 擴充 或取代標準 Scrum 中的活動 這些調整是為了兼顧各別 Scrum 團隊以及所有團隊的總成果 Nexus Framework, 規模化 Scrum 的外框架 Nexus 的流程 Scrum 團隊本身作為 Nexus 中的跨功能成員,Nexus 中的所有工作都可由其成員來完成 各團隊可基於依賴關係選擇最合適的成員來執行特定工作 精鍊產品待辦需求 (Refine the Product Backlog): 產品待辦需求須要經過分解來辨識其中的依賴性, 並且把它消除或最小化 產品待辦需求項目透過精鍊讓功能變得單純, 並且應該盡早識別出適合執行這項需求的團隊 Nexus Sprint 規劃 (Nexus Sprint Planning): 各 Scrum 團隊的適當代表進行討論與檢視精鍊過的產品待辦需求 這些代表選擇各自團隊預計執行的產品待辦需求項目 各 Scrum 團隊依此規劃各自的 Sprint, 並適當地與其它團隊互動 這個程序的產出結果是支撐起 Nexus 目標的各別 Scrum 目標 每個 Scrum 團隊的 Sprint 待辦需求 以及一份 Nexus Sprint 待辦需求 Nexus Sprint 待辦需求可以讓每個 Scrum 團隊選擇的產品 版權所有 Scrum.org,2015 第 3 頁 ( 1.1 版本 )
待辦需求項目與依賴關係透明化 開發工作 : 所有團隊執行軟體開發並頻繁地將它們的工作整合至一個可以進行整合測試的共用環境 Nexus 每日檢視 : 各 Scrum 開發團隊的適當代表每天討論確認是否有整合上的議題 如果有發現整合議題, 將這個資訊帶回各別 Scrum 團隊的每日檢視 確保在各別 Scrum 團隊的每日檢視時有提出這些整合議題 Nexus Sprint 展示回饋 (Nexus Sprint Review): 所有團隊與產品負責人一起檢視這個 Sprint 開發的整合遞增成品 可能會因此調整產品待辦需求 Nexus Sprint 回顧 (Nexus Sprint Retrospective): 各 Scrum 團隊的適當代表進行討論以辨別出共同面臨的困難 各 Scrum 團隊接著舉行各自的 Sprint 回顧 然後各 Scrum 團隊的適當代表基於各團隊群體智慧提供的意見再次討論要採取的行動 軟體開發實務方法 結合各 Scrum 團隊協同建造整合遞增成品需要各種軟體開發實務方法 大部份的軟體開發實務方法須要配合自動化 自動化有助於管理大量及複雜的工作與 產出物件, 特別是在規模化的開發環境中 Nexus Nexus 的角色 活動 與 產出物件 的作用繼承了 Scrum 指南中對應的角色 活動 與 產出物件 Nexus 的角色 一個 Nexus 由一個 Nexus 整合團隊與大約 3 到 9 個 Scrum 團隊所組成 Nexus 整合團隊 (Nexus Integration Team) Nexus 整合團隊負責確保每個 Sprint 能產出整合遞增成品 ( 整合工作由 Nexus 完成 ) 如 Scrum 中的要求,Scrum 團隊負責開發出可發行的軟體 Scrum 指南中指定了 Scrum 團隊的所有成員角色 Nexus 整合團隊是一個由以下人員組成的 Scrum 團隊 : 產品負責人 (Product Owner) Scrum Master 一或多個 Nexus 整合團隊組員 如果合適且有需要,Nexus 整合團隊中的組員也可以在其中的 Scrum 團隊工作 在這個情況下, 他必須以 Nexus 整合團隊的工作優先 Nexus 整合團隊的組員身份優先於各別 Scrum 團隊的成員身份 這樣的優先順序有助於確保影響多個團隊的議題能優先處理 隨著時間推進,Nexus 整合團隊組成可能依照當時的需求變更 Nexus 整合團隊的一般活動可能包括指導 諮詢 及指出依賴關係與跨團隊議題 它也可以執行產品待辦需求上的工作 版權所有 Scrum.org,2015 第 4 頁 ( 1.1 版本 )
任何整合上的議題都是 Nexus 整合團隊的責任 這個團隊對成功整合 Nexus 中所有 Scrum 團隊的所有工作負責 這裡的整合, 包括解決所有妨礙 Nexus 持續交付整合遞增成品的跨團隊技術或非技術的約束 他們應利用 Nexus 中各團隊的群體智慧來解決這些問題 Nexus 整合團隊的產品負責人一個 Nexus 只有一份產品待辦需求, 而依據 Scrum 框架, 一份產品待辦需求由一名產品負責人來最終決定其內容 產品負責人負責將產品的價值最大化, 工作的執行與整合則由 Scrum 團隊來進行 產品負責人應處於 Nexus 整合團隊 產品負責人的責任是透過排序與精 鍊 產品待辦需求, 來最大化 Nexus 開發出的整合遞增成品價值 這件事的作法可能會視不同組織 不同 Nexus 不同 Scrum 團隊 或不同人而有很大的差異 Nexus 整合團隊的 Scrum Master Nexus 整合團隊的 Scrum Master 負責確保整個 Nexus 了解 Nexus 框架並依此執行 這個 Scrum Master 可是同時是這個 Nexus 中一或多個 Scrum 團隊中的 Scrum Master Nexus 整合團隊組員 規模化開發工作中會用到一些各別 Scrum 團隊不常使用的工具或開發實務 Nexus 整合團隊中應包括熟悉這些工具 開發實務 與系統的軟體專家 Nexus 整合團隊組員確保這些開發實務 工具有被實施 了解, 並被用來找出依賴性及頻繁地整合 產出物件 以滿足 " 完成 " 定義 Nexus 整合團隊組員負責指導 Nexus 中的 Scrum 團隊養成 實施 並學習這些開發實務與工具 此外, 他們也訓練 Scrum 團隊符合組織的開發 基礎結構 與架構標準, 確保開發出品質好的整合遞增成品 如果他們滿足了主要責任,Nexus 整合團隊組員也可以作為各 Scrum 團隊中的開發團隊成員進行工作 Nexus 的活動 Nexus 活動的時間長度與 Scrum 指南中的對應事件一樣, 除了對應的 Scrum 活動,Nexus 活動也是有限時的活動 Nexus Sprint 規劃 (Nexus Sprint Planning) Nexus Sprint 規劃的目的是協調 Nexus 中所有 Scrum 團隊在這個 Sprint 中的活動 產品負責人提供領域知識 指導選擇和依優先順序決策 開始 Nexus Sprint 規劃時, 各別 Scrum 團隊的適當代表確認與調整在精 鍊 需求時建立工作的順序 為了最小化溝通議題, 所有 Scrum 團隊的成員應該出席這個活動 在 Nexus Sprint 規劃時會定出 Nexus Sprint 目標 它描述了各 Scrum 團隊在這個 Sprint 工 版權所有 Scrum.org,2015 第 5 頁 ( 1.1 版本 )
作的目的 了解 Nexus 的總工作後, 各 Scrum 團隊進行它們各自 Sprint 規劃 如果這個活動是在共用的空間進行, 團隊間可以持續分享他們新發現的依賴關係 當各 Scrum 團隊結束各自的 Sprint 規劃後,Nexus Sprint 規劃也隨著完成 在 Nexus Sprint 規劃時會增加新的依賴關係 這些依賴關係應該被視覺化及最小化 團隊之間的工作順序也可能會隨著調整 充分精鍊產品待辦需求會降低 Nexus Sprint 規劃時新增的依賴關係 所有在這個 Sprint 被選擇的產品待辦需求項目和它們的依賴關係要在 Nexus Sprint 待辦需求上被看到 產品待辦需求應該在 Nexus Sprint 規劃之前被充分精鍊, 找出依賴關係並消除或減至最低 Nexus 每日檢視 (Nexus Daily Scrum) Nexus 每日檢視是一個讓各別 Scrum 開發團隊適當的代表檢驗當前整合狀態, 並提出整合問題或新發現的跨團隊依賴的活動 在 Nexus 每日檢視時, 參加者應該專注各團隊整合遞增成品受到的影響並討論 : 昨天的工作是否有成功整合? 如果沒有, 為什麼? 找出了什麼新的依賴關係? 有什麼資訊應該分享給 Nexus 中的其它團隊? 在 Nexus 每日檢視時,Nexus Sprint 待辦需求被用來視覺化與管理當前的依賴關係 Nexus 每日檢視期間找出的工作會被代表帶回各自的 Scrum 團隊, 用於各自內部的每日檢視活動 Nexus Sprint 展示回饋 (Nexus Sprint Review) Nexus Sprint 展示回饋在 Sprint 結束前舉行, 用來提供對於 Nexus 在這個 Sprint 產出的整合遞增成品的回饋 Nexus Sprint 展示回饋取代了各別 Scrum 團隊的 Sprint 展示回饋, 因為要聚焦在取得關係人對整合遞增成品的回饋 可能無法在這個活動上展示所有完成工作的細節 需要一些技巧來最大化關係人的回饋 Nexus Sprint 回顧 (Nexus Sprint Retrospective) Nexus Sprint 回顧是一個 Nexus 內部檢驗與調適的正式機會 由三個部份組成 : 1. 第一部份由 Nexus 中各團隊的適當代表進行討論, 找出會影響超過一個團隊的議題 目的是讓共同議題對所有的 Scrum 團隊變得更透明 版權所有 Scrum.org,2015 第 6 頁 ( 1.1 版本 )
2. 第二部份是讓各別 Scrum 團隊進行它們各自 Scrum 框架中的 Sprint 回顧 他們可以把第一部份找出的議題投入這個活動中進行討論 各別 Scrum 團隊應在活動中提出用來應對這些議題的行動 3. 最後, 第三部份是讓 Nexus 中各團隊的適當代表再次進行討論, 如何讓這些應對行動可被視覺化與追蹤 這樣讓 Nexus 可以作為一個整體來進行調整 每次回顧都該討論以下在具規模開發中常見的功能障礙 : 是否留下任何未完成的工作?Nexus 是否產生了技術債? 是否所有的 產出物件, 特別是程式碼, 都能頻繁的 ( 每天 ) 成功整合? 軟體成功建置 測試 與部屬的頻率是否足以防止累積太多未解析的依賴關係? 以上的問題在有需要時, 討論以下內容 : 為什麼會發生? 技術債如何消除? 如何防止再次發生? 需求細部化 (Refinement) 以 Nexus 的規模來看會有許多不同層級的細部化工作 只有在產品待辦需求項目足夠獨立時, 這些項目才能被選擇並在沒有 Scrum 團隊之間過度衝突的情況下工作 需求細部化會議的次數 頻率 時間長度 與出席者取決於產品待辦需求中的依賴關係 依賴關係與複雜度愈高, 產品待辦需求項目需要愈多的細部化 龐大與模糊的產品待辦需求項目須經過多個層級的拆解, 讓一個 Scrum 團隊可以在一個 Sprint 內交付 在具規模開發中, 產品待辦需求細部化工作有二個目的 預估哪個團隊將交付哪些產品待辦需求項目, 及指出跨團隊的依賴關係 視覺化讓團隊可以監看依賴關係並將它降到最低 跨團隊需求細部化的第一部份被用來拆解產品待辦需求項目, 直到了解哪個團隊可能可以交付, 以及被執行的順序 需求細部化的第二部份關注依賴關係 要找出團隊間與 Sprint 間的依賴關係, 並且把它視覺化 團隊需要這個資訊, 以便透過重新排序與配置工作來將跨團隊的依賴關係降到最低 如果需求細部化執行夠充份, 在 Sprint 規劃時產品待辦需求項目會是準備完成 可被選擇 且有最少的依賴關係 Nexus 的產出物件 (Nexus Artifacts) 如 Scrum 指南中所描述, 產出物件 代表用來增加透明度 檢驗與調整的工作或價值 產品待辦需求 (Product Backlog) 版權所有 Scrum.org,2015 第 7 頁 ( 1.1 版本 )
整個 Nexus 與其中的 Scrum 團隊只有一份產品待辦 產品負責人對這份產品待辦負責, 包括內容 可用性 與排序 在規模化的情境下, 產品待辦需求須被了解到能夠找出與最小化依賴關係的程度 產品待辦項目常被解析到被稱為功能 " 薄片 "(thinly sliced) 的大小 當產品待辦項目可在 Nexus Sprint 規劃上被選擇, 沒有跨團隊依賴性或已降到最低讓 Scrum 團隊能夠順利執行時, 這個項目被視為 " 準備完成 "(ready) Nexus 目標 (Nexus Goal) Nexus Sprint Planning 時會制訂整個 Sprint 的目標 這個目標被稱為 Nexus 目標 這是 Nexus 中各個 Scrum 團隊工作與 Sprint 目標的總合 Nexus 應在 Nexus Sprint 檢驗上證明他們開發的功能達成 Nexus 目標 Nexus Sprint 待辦需求 (Nexus Sprint Backlog) Nexus Sprint 待辦需求是所有 Scrum 團隊的 Sprint 待辦需求上的產品待辦需求項目的組合 它被用來強調 Sprint 中的依賴關係與工作順序 它必須至少每天更新, 常會在 Nexus 每日檢視上執行 整合遞增成品 (Integrated Increment) 整合遞增成品代表 Nexus 完成的所有已整合的工作的總合 整合遞增成品必須符合 " 完成 " 定義, 可使用且具備可以釋出的條件 整合遞增成品會在 Nexus Sprint 展示回饋活動中被檢驗 產出物件透明化 如同組成 Nexus 的 Scrum 一樣,Nexus 的基礎建立在透明化上 在 Nexus 中,Nexus 團合團隊與 Scrum 團隊協同工作, 確保所有的 產出物件 足夠提供透明度給團隊, 讓團隊了解遞增成品的整合狀態 基於 Nexus 產出物件 所作決策的效力受限於 產出物件 透明化的程度 不完整的資訊會導致不正確或有缺陷的決策 以 Nexus 的規模, 這些決策的影響會被放大 缺乏透明度時不可能有效指導讓 Nexus 將風險最小化, 並將價值最大化 軟體開發必須在技術債變得不可接受前找出並解析依賴關係 測試是否有不可接受的技術債, 看當進行整合時是否仍有未被解析的依賴性 如果有, 這些依賴性持續隱藏在程式碼與測試中, 降低軟體的整體價值 " 完成 " 的定義 (Definition of Done ) " 完成 " 定義由 Nexus 整合團隊團隊負責, 應用於每個 Sprint 開發的整合遞增成品 Nexus 中的所有 Scrum 團隊遵守 " 完成 " 定義 只有在產品負責人認為遞增成品可使用且滿足可釋出條件時, 遞增成品才算是 " 完成 " 版權所有 Scrum.org,2015 第 8 頁 ( 1.1 版本 )
當產品待辦需求項目的功能成功地被新增並整合至產品中時, 可被視為 " 完成 " 所有 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 共同合作所開發 翻譯 本繁體中文指南 (1.1 版 ) 是由 Ken Schwaber 與 Scrum.org 的英文原版翻譯而來 繁體中文翻譯團隊包括 : Weipeng Cheng, PSM, SPS, PMI-ACP, PMP ( adriancwp@gmail.com ) Andrew Lin, PMP, PMI-ACP, CSP, SPC4, Agile Coach ( andrewlin@01uni.com ) 版權所有 Scrum.org,2015 第 9 頁 ( 1.1 版本 )