Nexus 規模化 Scrum 框架 (The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams)

庫爾特·比特納 (Kurt Bittner), 帕特麗夏·孔 (Patricia Kong), 等

Nexus 規模化 Scrum 框架 (The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams)

買這商品的人也買了...

商品描述

本書由Scrum.org企業解決方案副總裁攜Nexus框架的主要貢獻者及Scrum.org公司CEO共同撰寫，Scrum聯合創始人、敏捷大師Ken Schwaber作序推薦，循序漸進地描述瞭如何應用Nexus改進和加速大型、分佈式、複雜項目的軟件交付。
全書共8章。第1章介紹了在項目需要多個Scrum團隊參與的情況下，如何使用敏捷；第2章講解Nexus背後的基本原則和概念，包括何時需要Nexus，以及啟動Nexus 所需要的準備；第3章主要關註如何圍繞產品建立一個Nexus，在創建Nexus時如何增加團隊，如何在Nexus中組織Scrum團隊，以及如何識別（並最小化）產品待辦事項的依賴關係；第4章講解如何組織Nexus的工作；第5章介紹Sprint中的Nexus工作；第6章講解如何管理Nexus，包括報告進度、提升績效和吞吐量，以及消除瓶頸；第7章關註Nexus如何幫助組織剋服規模化過程中的典型挑戰；第8章展示了當團隊和組織擴展Scrum時所經歷的典型旅程，同時展望了團隊和組織可以做些什麼來持續提升交付複雜應用程序的能力。

本書非常有價值。書中從一個簡單的Nexus應用開始，描述了Nexus在日益複雜情況下的應用。作者闡述了環境的複雜性及其所導致的問題，以及如何應用Nexus來解決這些問題。 ——　Ken Schwaber，Scrum聯合創始人

Nexus框架是一種簡單、有效的方法，可以在橫跨多個團隊、地點和時區上規模化應用Scrum，它是由提供Scrum培訓和認證的先進組織Scrum.org所創建的，而該組織又是由Scrum的聯合創始人Ken Schwaber創立的。 Nexus框架可幫助大家利用幾十年的經驗來解決團隊聚集在一起、共享工作，以及管理和減少依賴關係所面臨的獨特挑戰。

本書簡明扼要地展示了Nexus如何幫助團隊在既不犧牲一致性和質量，也不增加不必要的複雜性，更不偏離Scrum核心原則的前提下，在短時間、頻繁的周期中交付複雜的、多平臺的、基於軟件的產品。本書作者通過使用一個擴展的案例研究，解釋了Nexus如何幫助團隊解決常見的規模化挑戰，比如減少跨團隊的依賴、保持團隊的自組織和透明性，以及確保履行相應的責任。

本書包括如下內容：
理解由多個團隊來交付工作、集成產品增量時所面臨的挑戰，以及利用Nexus如何解決這些挑戰
圍繞新產品或已有產品建立一個Nexus框架，並學習Nexus是如何設定目標和計劃工作的
在一個Nexus中運行Sprint，為進展提供透明性，進行有效的Nexus Sprint回顧，並利用Nexus Sprint回顧進行持續改進
剋服分佈式團隊協作所面臨的挑戰

作者簡介

Kurt Bittner是Scrum.org企業解決方案副總裁，擁有超過35年的從業經驗，曾作為程序員、產品經理/產品負責人、業務分析師，以及組織變革代理人，幫助許多團隊在短週期反饋驅動的條件下交付軟件。他曾出版過其他3本軟件工程方面的書籍，寫過許多博客和文章，並經常出席會議發表演講。

Patricia Kong是Nexus框架和基於事件管理框架的主要貢獻者，Scrum.org企業解決方案產品負責人（包括Nexus框架）。她曾在幾家初創公司領導過產品開發、產品管理和市場營銷團隊。

Dave West是Scrum.org公司的CEO和產品負責人，經常在主要的行業會議上發表主題演講，並是一個擁有廣泛讀者的書籍、博客、文章和研究報告的作者。他曾領導過跨國公司的產品開發和諮詢部門。

目錄大綱

譯者序
序
前言
第1章　規模化敏捷概述1
1.1　為什麼使用敏捷2
1.2　為什麼要用Scrum3
1.2.1　什麼是產品3
1.2.2　什麼是Scrum4
1.3　為什麼要用Nexus6
1.4　簡單是進行規模化的關鍵7
第2章　Nexus概述9
2.1　什麼是Nexus9
2.2　Nexus擴展了Scrum11
2.3　Nexus集成團隊12
2.4　Nexus事件15
2.4.1　梳理16
2.4.2　Nexus Sprint計劃17
2.4.3　Nexus每日Scrum站會18
2.4.4　Nexus Sprint評審19
2.4.5　Nexus Sprint回顧20
2.4.6　Nexus Sprint回顧中要問的問題21
2.5　Nexus工件22
2.5.1　產品待辦事項列表22
2.5.2　Nexus目標22
2.5.3　Nexus Sprint待辦事項列表22
2.5.4　集成增量23
2.5.5　工件透明性23
2.5.6　Nexus中的“完成”定義24
2.6　要啟動Nexus需要做哪些準備24
2.7　結束語25
第3章　建立一個Nexus27
3.1　演進跨職能團隊30
3.1.1　實踐：開放代碼庫31
3.1.2　實踐：圍繞業務價值增量來建立團隊33
3.1.3　實踐：建立自組織團隊35
3.2　發展一個Nexus36
3.2.1　從小開始，不斷發展37
3.2.2　使用結對和“實習制”發展Scrum團隊38
3.2.3　為什麼Nexus中只有3～9個Scrum團隊38
3.3　建立Nexus集成團隊39
3.4　Nexus如何工作43
第4章　Nexus中的計劃45
4.1　鞏固和驗證產品待辦事項列表45
4.1.1　梳理產品待辦事項列表48
4.1.2　跨團隊產品待辦事項列表梳理50
4.1.3　產品待辦事項列表條目依賴關係54
4.1.4　可選實踐：使用故事地圖來瞭解功能和依賴關係56
4.1.5　可選實踐：使用跨團隊梳理板來瞭解依賴關係57
4.2　在Nexus中計劃一個Sprint61
4.2.1　建立Nexus目標62
4.2.2　估算和按規模大小排列產品待辦事項列表條目62
4.2.3　可選實踐：將產品待辦事項列表條目與價值交付互相關聯64
4.2.4　構建Nexus Sprint待辦事項列表和Scrum團隊待辦事項列表65
4.3　結束語69
第5章　在Nexus中運行Sprint71
5.1　Nexus每日Scrum站會71
5.2　在Nexus內部和外部提供透明性75
5.2.1　可選實踐：產品待辦事項列表樹形圖77
5.2.2　可選實踐：可視化產品待辦事項列表燃盡圖和速度78
5.3　Nexus Sprint評審80
5.3.1　可選實踐：使用“博覽會”形式進行Nexus Sprint評審81
5.3.2　可選實踐：使用離線評審技術進行Nexus Sprint評審82
5.4　Nexus Sprint回顧83
5.5　結束語89
第6章　演進Nexus91
6.1　可選實踐：圍繞特性組織Scrum團隊94
6.2　可選實踐：像開源項目一樣管理代碼96
6.3　可選實踐：圍繞用戶畫像組織團隊98
6.4　擴展Nexus集成團隊100
6.5　更新和梳理產品待辦事項列表101
6.6　再談Nexus Sprint計劃104
6.7　再談Nexus每日Scrum站會105
6.8　再談Nexus Sprint評審106
6.9　再談Nexus Sprint回顧107
6.9.1　工作太多，進展不足109
6.9.2　日益增加的技術債務110
6.9.3　不能及時出現的產品負責人111
6.9.4　不充分的構建和測試自動化112
6.9.5　制定改進計劃113
6.9.6　規模化Scrum的挑戰114
6.10　結束語116
第7章　應急模式下的Nexus119
7.1　三談產品待辦事項列表梳理121
7.2　三談Nexus Sprint計劃124
7.2.1　引導大規模分佈式Sprint計劃會125
7.2.2　軟硬件開發混合的Nexus127
7.2.3　按不同Sprint節奏工作的團隊128
7.2.4　在Nexus中混合Scrum和瀑布方法130
7.3　三談Nexus每日Scrum站會131
7.4　當Nexus開始掙扎時，應該做些什麼134
7.4.1　應急模式下的Nexus集成團隊136
7.4.2　減小規模136
7.4.3　使用健康檢查來瞭解團隊情緒139
7.4.4　Scrumble141
7.5　Nexus（偽）Sprint評審和回顧144
7.6　結束語145
第8章　Nexus旅程中的回顧147
8.1　哪些做得好148
8.1.1　Nexus每日Scrum站會148
8.1.2　Nexus集成團隊149
8.1.3　發布頻率150
8.1.4　生產力151
8.1.5　自組織152
8.2　需要改進的領域153
8.2.1　管理技術債務154
8.2.2　擴展產品負責人155
8.2.3　技能提升156
8.2.4　透明性和信任157
8.3　下一步是什麼160
8.4　結束語162
術語表164

類似商品