《可伸縮敏捷開發：企業級最佳實踐》是2009年電子工業出版社出版的中譯圖書。
基本介紹
內容簡介,作者簡介,目錄,
內容簡介
敏捷開發實踐雖然在一些圈子內仍然存在著爭議，但是它卻給我們帶來了不可否認的益處，例如：更加快速地向市場交付、更好地回響變化的客戶需求以及提供更高的軟體質量。然而，敏捷方法一直定義或者推薦在小型團隊中套用。在《可伸縮敏捷開發（Scaling Software Agility ）》這本書中，Dean Leffingwell 介紹了如何將敏捷方法套用於企業級的開發上。第1部分介紹了最通用且最有效的敏捷方法。第2部分介紹了擴展到企業級規模的7個敏捷最佳實踐。 第3部分介紹了公司所能掌握的獲得企業範圍內軟體敏捷性全部好處的另外一套實踐，即7個組織能力。
該書對於軟體開發人員、測試人員及 QA 人員、經理和團隊領導，以及軟體組織的執行人員是非常有價值的，這些組織的目標是提高軟體開發過程的質量和生產率，但是這些組織面臨著在企業範圍內開發軟體的所有挑戰。
作者簡介
蘭芬維奧 (Dean Leffingwell) ，是一位知名的軟體開發方法論者和作者，也是一個軟體團隊指導。他是8equisite公司的創始人和前CEO，也是Rational軟體公司的前副總裁。在過去的五年里.他的工作角色是獨立顧問，並擔任Rally軟體公司的顧問兼方法論者。Leffingwell致力於將敏捷方法套用於跨國公司分散式大型開發團隊。Leffingwell也是《Managing Software Requirements》（Addison—Wesley公司，2003年出版）的第一作者。
目錄
第1部分 軟體敏捷概述
第1章 敏捷方法介紹
1.1 在軟體經濟中獲得競爭優勢軟體開發方法與行業一起發展
1.2 走進敏捷方法
1.3 敏捷的規模
1.4 了解敏捷方法敏捷宣言
1.5 採用敏捷方法的趨勢
1.6 軟體敏捷的企業效益
1.6.1 提高生產力
1.6.2 提高質量
1.6.3 提升團隊士氣和工作滿意度
1.6.4 更快地面市
1.7 XP、Scrum及RUP的簡介
1.7.1 極限編程（XP）
1.7.2 Scrum
1.7.3 Rational統一過程
1.8 小結
第2章 為什麼瀑布模型不適用
2.1 瀑布模型的問題
2.2 瀑布模型的假設
2.2.1 假設1：如果我們花時間來理解的話，存在著一套定義相當明確的需求
2.2.2 假設2：改變是小型且便於管理的
2.2.3 假設3：系統集成會順利進行
2.2.4 假設4：我們完全可以按計畫交付
2.3 利用敏捷方法來糾正行為
第3章 XP的本質
3.1 什麼是XP
3.2 有關XP的爭議
3.3 有關XP的極限
3.4 XP的基本原則
3.5 XP的價值、原則及實踐方法
3.5.1 XP的5個核心價值
3.5.2 基本原則
3.5.3 XP的13個關鍵實踐技巧
3.5.4 對結對編程的注釋
3.6 XP的過程模型
3.7 XP方法的套用
閱讀參考
第4章 Scrum的本質
4.1 Scrum是什麼
4.2 Scrum的角色
4.3 Scrum的哲學根基
4.4 Scrum的價值觀、原則及實踐方法
4.5 Scrum的關鍵實踐方法
4.6 Scrum的基本原則：經驗過程控制
4.7 Scrum的過程模型
4.8 對Scrum和組織的變更
4.9 方法的套用
閱讀參考
第5章 RUP的本質
5.1 什麼是RUP
5.2 RUP的關鍵特徵
5.3 RUP的根源
5.3.1 RUP的原理與實踐
5.3.2 疊代：RUP的基本原則
5.3.3 架構驅動和用例中心化
5.3.4 RUP開發過程模型
5.3.5 時間軸
5.3.6 規程軸
5.3.7 RUP生命周期疊代類型
5.4 敏捷RUP變體
5.4.1 開放統一過程（OpenUP）
5.4.2 敏捷統一過程
5.5 方法的適用性
閱讀參考
第6章 精益軟體開發、DSDM和FDD
6.1 精益軟體開發關於精益軟體開發的閱讀參考
6.2 動態系統開發方法
6.2.1 背景
6.2.2 DSDM的基本原則
6.2.3 DSDM的核心實踐
6.2.4 訪問DSDM
6.3 特徵驅動開發FDD的最佳實踐
第7章 敏捷的本質
7.1 敏捷正在改變什麼
7.1.1 成功的新措施
7.1.2 不同的管理文化
7.1.3 需求、架構和設計的不同方法
7.1.4 修正編碼和實現實踐
7.1.5 測試和質量保證實踐的轉變
7.1.6 規劃和進度安排的新方法
7.1.7 最大的變化：範疇VS日期，優先考慮日期
7.2 敏捷的重要動力：短時間盒內的工作代碼
7.3 總結
第8章 可伸縮敏捷的挑戰
8.1 方法的明顯障礙
8.1.1 小團隊規模
8.1.2 客戶是團隊的一部分
8.1.3 配置
8.1.4 架構形成
8.1.5 缺乏需求分析和規範文檔
8.1.6 文化和物理環境
8.2 企業的障礙
8.2.1 過程和項目管理組織
8.2.2 現有正式的策略和流程
8.2.3 企業文化
8.2.4 固定日程、固定功能授權
8.2.5 開發部門和用戶/客戶代理團隊之間的摩擦
8.2.6 通過紀律組織人力而不是生產線
8.2.7 高度分布
8.3 總結
1.1 在軟體經濟中獲得競爭優勢軟體開發方法與行業一起發展
1.2 走進敏捷方法
1.3 敏捷的規模
1.4 了解敏捷方法敏捷宣言
1.5 採用敏捷方法的趨勢
1.6 軟體敏捷的企業效益
1.6.1 提高生產力
1.6.2 提高質量
1.6.3 提升團隊士氣和工作滿意度
1.6.4 更快地面市
1.7 XP、Scrum及RUP的簡介
1.7.1 極限編程（XP）
1.7.2 Scrum
1.7.3 Rational統一過程
1.8 小結
第2章 為什麼瀑布模型不適用
2.1 瀑布模型的問題
2.2 瀑布模型的假設
2.2.1 假設1：如果我們花時間來理解的話，存在著一套定義相當明確的需求
2.2.2 假設2：改變是小型且便於管理的
2.2.3 假設3：系統集成會順利進行
2.2.4 假設4：我們完全可以按計畫交付
2.3 利用敏捷方法來糾正行為
第3章 XP的本質
3.1 什麼是XP
3.2 有關XP的爭議
3.3 有關XP的極限
3.4 XP的基本原則
3.5 XP的價值、原則及實踐方法
3.5.1 XP的5個核心價值
3.5.2 基本原則
3.5.3 XP的13個關鍵實踐技巧
3.5.4 對結對編程的注釋
3.6 XP的過程模型
3.7 XP方法的套用
閱讀參考
第4章 Scrum的本質
4.1 Scrum是什麼
4.2 Scrum的角色
4.3 Scrum的哲學根基
4.4 Scrum的價值觀、原則及實踐方法
4.5 Scrum的關鍵實踐方法
4.6 Scrum的基本原則：經驗過程控制
4.7 Scrum的過程模型
4.8 對Scrum和組織的變更
4.9 方法的套用
閱讀參考
第5章 RUP的本質
5.1 什麼是RUP
5.2 RUP的關鍵特徵
5.3 RUP的根源
5.3.1 RUP的原理與實踐
5.3.2 疊代：RUP的基本原則
5.3.3 架構驅動和用例中心化
5.3.4 RUP開發過程模型
5.3.5 時間軸
5.3.6 規程軸
5.3.7 RUP生命周期疊代類型
5.4 敏捷RUP變體
5.4.1 開放統一過程（OpenUP）
5.4.2 敏捷統一過程
5.5 方法的適用性
閱讀參考
第6章 精益軟體開發、DSDM和FDD
6.1 精益軟體開發關於精益軟體開發的閱讀參考
6.2 動態系統開發方法
6.2.1 背景
6.2.2 DSDM的基本原則
6.2.3 DSDM的核心實踐
6.2.4 訪問DSDM
6.3 特徵驅動開發FDD的最佳實踐
第7章 敏捷的本質
7.1 敏捷正在改變什麼
7.1.1 成功的新措施
7.1.2 不同的管理文化
7.1.3 需求、架構和設計的不同方法
7.1.4 修正編碼和實現實踐
7.1.5 測試和質量保證實踐的轉變
7.1.6 規劃和進度安排的新方法
7.1.7 最大的變化：範疇VS日期，優先考慮日期
7.2 敏捷的重要動力：短時間盒內的工作代碼
7.3 總結
第8章 可伸縮敏捷的挑戰
8.1 方法的明顯障礙
8.1.1 小團隊規模
8.1.2 客戶是團隊的一部分
8.1.3 配置
8.1.4 架構形成
8.1.5 缺乏需求分析和規範文檔
8.1.6 文化和物理環境
8.2 企業的障礙
8.2.1 過程和項目管理組織
8.2.2 現有正式的策略和流程
8.2.3 企業文化
8.2.4 固定日程、固定功能授權
8.2.5 開發部門和用戶/客戶代理團隊之間的摩擦
8.2.6 通過紀律組織人力而不是生產線
8.2.7 高度分布
8.3 總結
第2部分 7種可伸縮的敏捷團隊實踐
第9章 定義/構建/測試模組團隊
9.1 什麼是定義/構建/測試模組團隊
簡單故事的生命周期
9.2 解除功能單元
9.3 敏捷模組團隊的角色和職責
9.4 創建自組織、自管理的定義/構建/測試團隊
9.4.1 團隊中有合適的人
9.4.2 團隊是被領導而不是被管理
9.4.3 團隊了解任務
9.4.4 團隊不斷交流與合作
9.4.5 團隊為結果負責
9.5 分散式的團隊
第10章 計畫和追蹤兩個級別
10.1 通用敏捷框架
10.1.1 定義疊代
10.1.2 剖析疊代
10.1.3 定義發布
10.1.4 剖析發布
10.1.5 計畫發布
10.1.6 為發布分配需求
10.1.7 發布計畫
10.2 小結：兩個級別的計畫
第11章 掌握疊代
11.1 疊代：敏捷的推動力
11.2 標準的兩周疊代
11.3 計畫和執行疊代
11.4 疊代計畫
11.4.1 為疊代計畫會做準備
11.4.2 參與者
11.4.3 疊代計畫會議
11.4.4 結果：疊代計畫
11.4.5 附加的疊代計畫指導原則
11.4.6 分散式團隊的疊代計畫
11.5 疊代執行
11.5.1 承擔職責
11.5.2 開發
11.5.3 交付故事
11.5.4 宣布故事完成
11.5.5 接收疊代
11.6 疊代追蹤和調整
11.6.1 追蹤每日站立例會
11.6.2 每日站立例會指導原則
11.6.3 追蹤疊代狀態
11.6.4 追蹤剩餘時間表
11.7 疊代節奏日曆
第12章 更小、更頻繁的發布
12.1 小型發布的好處
12.2 定義發布和制定發布的日程
12.2.1 日程驅動發布
12.2.2 最簡單的模型：固定周期發布日期
12.2.3 估算特徵集
12.3 計畫發布
12.3.1 參與者
12.3.2 準備
12.3.3 發布計畫過程
12.3.4 結果：發布計畫
12.3.5 附加的發布計畫指導原則
12.4 發布追蹤
12.4.1 為發布狀態審查做準備
12.4.2 發布狀態審查會
12.4.3 成果/文檔
12.5 發布路線圖
12.6 大規模敏捷的預覽：全面的發布計畫和追蹤
12.6.1 組織大規模的敏捷
12.6.2 多團隊發布計畫
12.6.3 發布追蹤
第13章 並發測試
13.1 敏捷測試介紹構建本質上可測試的系統
13.2 敏捷測試原則
13.3 單元測試
13.3.1 疊代過程中的單元測試
13.3.2 單元測試和測試驅動開發
13.4 接收測試自動接收測試實例：FIT方法
13.5 組件測試
13.6 系統和性能測試
13.7 小結：簡述敏捷測試策略疊代和發布測試模式
第14章 持續集成
14.1 什麼是持續集成非持續集成：微觀世界的問題
14.2 持續集成
14.3 實現持續集成的3個步驟
14.3.1 原始碼集成
14.3.2 自動化構建管理
14.3.3 自動構建驗證測試
14.4 什麼是持續集成成功
第15章 定期反省和調整
15.1 疊代回顧
15.1.1 疊代回顧的形式
15.1.2 定量評估
15.1.3 定性評估
15.1.4 要求行動
15.2 發布回顧
15.2.1 定量評估
15.2.2 定性評估
15.2.3 利用疊代回顧消除組織的障礙
9.1 什麼是定義/構建/測試模組團隊
簡單故事的生命周期
9.2 解除功能單元
9.3 敏捷模組團隊的角色和職責
9.4 創建自組織、自管理的定義/構建/測試團隊
9.4.1 團隊中有合適的人
9.4.2 團隊是被領導而不是被管理
9.4.3 團隊了解任務
9.4.4 團隊不斷交流與合作
9.4.5 團隊為結果負責
9.5 分散式的團隊
第10章 計畫和追蹤兩個級別
10.1 通用敏捷框架
10.1.1 定義疊代
10.1.2 剖析疊代
10.1.3 定義發布
10.1.4 剖析發布
10.1.5 計畫發布
10.1.6 為發布分配需求
10.1.7 發布計畫
10.2 小結：兩個級別的計畫
第11章 掌握疊代
11.1 疊代：敏捷的推動力
11.2 標準的兩周疊代
11.3 計畫和執行疊代
11.4 疊代計畫
11.4.1 為疊代計畫會做準備
11.4.2 參與者
11.4.3 疊代計畫會議
11.4.4 結果：疊代計畫
11.4.5 附加的疊代計畫指導原則
11.4.6 分散式團隊的疊代計畫
11.5 疊代執行
11.5.1 承擔職責
11.5.2 開發
11.5.3 交付故事
11.5.4 宣布故事完成
11.5.5 接收疊代
11.6 疊代追蹤和調整
11.6.1 追蹤每日站立例會
11.6.2 每日站立例會指導原則
11.6.3 追蹤疊代狀態
11.6.4 追蹤剩餘時間表
11.7 疊代節奏日曆
第12章 更小、更頻繁的發布
12.1 小型發布的好處
12.2 定義發布和制定發布的日程
12.2.1 日程驅動發布
12.2.2 最簡單的模型：固定周期發布日期
12.2.3 估算特徵集
12.3 計畫發布
12.3.1 參與者
12.3.2 準備
12.3.3 發布計畫過程
12.3.4 結果：發布計畫
12.3.5 附加的發布計畫指導原則
12.4 發布追蹤
12.4.1 為發布狀態審查做準備
12.4.2 發布狀態審查會
12.4.3 成果/文檔
12.5 發布路線圖
12.6 大規模敏捷的預覽：全面的發布計畫和追蹤
12.6.1 組織大規模的敏捷
12.6.2 多團隊發布計畫
12.6.3 發布追蹤
第13章 並發測試
13.1 敏捷測試介紹構建本質上可測試的系統
13.2 敏捷測試原則
13.3 單元測試
13.3.1 疊代過程中的單元測試
13.3.2 單元測試和測試驅動開發
13.4 接收測試自動接收測試實例：FIT方法
13.5 組件測試
13.6 系統和性能測試
13.7 小結：簡述敏捷測試策略疊代和發布測試模式
第14章 持續集成
14.1 什麼是持續集成非持續集成：微觀世界的問題
14.2 持續集成
14.3 實現持續集成的3個步驟
14.3.1 原始碼集成
14.3.2 自動化構建管理
14.3.3 自動構建驗證測試
14.4 什麼是持續集成成功
第15章 定期反省和調整
15.1 疊代回顧
15.1.1 疊代回顧的形式
15.1.2 定量評估
15.1.3 定性評估
15.1.4 要求行動
15.2 發布回顧
15.2.1 定量評估
15.2.2 定性評估
15.2.3 利用疊代回顧消除組織的障礙
第3部分 創建敏捷企業
第16章 有意識的架構
16.1 什麼是軟體架構
16.2 敏捷和架構
16.2.1 極限編程：架構形成
16.2.2 Scrum
16.2.3 在FDD中的架構
16.2.4 RUP：以架構為中心
16.3 關於重構和可伸縮系統
16.4 你在創建什麼
16.5 用於企業級系統的敏捷架構方法基於組件的系統：組織遵從架構
16.6 創建架構跑道
16.6.1 架構的脆弱性和臨時性本質
16.6.2 擴展架構跑道
16.6.3 通過產品記錄重構
16.6.4 擴展架構跑道：與疊代同步
16.6.5 擴展架構跑道：一種精益的、基於拉的方法
第17章 伸縮時的精益需求：願景、路線圖、適時的細化
17.1 概述：需求金字塔
17.1.1 利益相關者的需要
17.1.2 解決方案的“特性”
17.1.3 軟體需求
17.1.4 傳統的需求方法
17.2 敏捷方法中需求的不同
17.2.1 在XP中的需求
17.2.2 Scrum、產品擁有者和產品記錄
17.2.3 在RUP中的需求
17.3 一種可測量的、敏捷的需求方法：概要、路線圖以及適時的細化
17.3.1 細化用戶故事
17.3.2 細化用例
17.3.3 細化接收測試用例
17.4 小結
第18章 系統的系統及敏捷發布序列
18.1 敏捷組件發布日程
18.1.1 驅動敏捷序列的經驗教訓
18.1.2 敏捷發布序列的原則
18.2 敏捷發布序列
18.2.1 序列是同步的
18.2.2 序列是由願景、主題和端到端用例驅動的
18.2.3 保持序列被跟蹤並符合日程
18.2.4 測量過程和速度
18.2.5 觀察系統級模式
18.2.6 管理相互依賴關係
18.3 發布序列審查
第19章 管理高度分散式開發
19.1 在規模上，所有的開發都是分散式開發
19.2 案例研究1PINGIDENTITY公司：
分散式定義/構建/測試組件團隊
19.2.1 PingIdentity案例研究背景
19.2.2 學到的其他經驗教訓
19.3 案例研究2BMC軟體公司：高度分散式的、大規模企業中的敏捷改革
19.3.1 背景
19.3.2 IMD套用敏捷
19.3.3 結果
19.3.4 從編碼到編程：大範圍採用敏捷
19.3.5 吸取的經驗：貫穿大型組織的可伸縮敏捷實踐
19.3.6 下一步驟：敏捷成功的第一年後
19.4 重視溝通
19.4.1 穿梭訪問
19.4.2 通信基礎設施
19.5 企業級敏捷的基礎設施建設
19.5.1 原始碼管理
19.5.2 網路基礎設施
19.5.3 在早期疊代中提供基礎設施
19.6 小結
第20章 對客戶和操作的影響
20.1 敏捷方法對銷售和市場的好處
20.2 對產品市場/產品管理的影響
20.3 更小、更頻繁的發布更小、更頻繁發布的挑戰
20.4 最佳化敏捷發布過程
20.4.1 發布選擇1：忽略敏捷
20.4.2 發布選擇2：追求敏捷
20.4.3 發布選擇3：通過從外部發布中分離出開發發布，進行最佳化
20.5 來自真正的銷售和市場執行人員關於敏捷的真實挑戰和錯覺
第21章 組織變更
21.1 概述
21.2 為何敏捷需要改變組織
21.3 為Scrum和敏捷做準備
21.3.1 讓軟體過程和組織都“Scrumming”
21.3.2 讓執行主管成為組織變更的Scrum主管
21.3.3 當心：變更是很困難的
21.4 消除軟體生產率的障礙
21.5 給執行管理層的敏捷模型
21.5.1 支持採用敏捷
21.5.2 實踐你宣揚的理論：把敏捷作為執行管理層實踐
21.6 在大型組織中全面開展Scrum/敏捷
21.6.1 概觀、評估和先導準備
21.6.2 先導項目
21.6.3 組織擴張
21.6.4 獲得影響
21.6.5 度量、評估和調整
21.6.6 擴展和勝利
21.7 小結
第22章 度量業績
22.1 敏捷測量：主要區別
22.2 測量團隊業績
22.2.1 敏捷項目度量
22.2.2 敏捷過程度量
22.2.3 評估成果
22.3 關於度量、“過程策略”和團隊自評估
22.4 擴展至組織業績：綜合評價卡方法
22.4.1 效率
22.4.2 質量
22.4.3 價值交付
22.4.4 敏捷性
22.5 可伸縮的敏捷度量:為企業實現一個靈活的、自動化的和有意義的BSC
22.5.1 第1步：量化BSC矩陣元素
22.5.2 第2步：轉為字母等級
22.5.3 第3步：聚合成產品線、業務單元和企業
結論：敏捷是可伸縮的
16.1 什麼是軟體架構
16.2 敏捷和架構
16.2.1 極限編程：架構形成
16.2.2 Scrum
16.2.3 在FDD中的架構
16.2.4 RUP：以架構為中心
16.3 關於重構和可伸縮系統
16.4 你在創建什麼
16.5 用於企業級系統的敏捷架構方法基於組件的系統：組織遵從架構
16.6 創建架構跑道
16.6.1 架構的脆弱性和臨時性本質
16.6.2 擴展架構跑道
16.6.3 通過產品記錄重構
16.6.4 擴展架構跑道：與疊代同步
16.6.5 擴展架構跑道：一種精益的、基於拉的方法
第17章 伸縮時的精益需求：願景、路線圖、適時的細化
17.1 概述：需求金字塔
17.1.1 利益相關者的需要
17.1.2 解決方案的“特性”
17.1.3 軟體需求
17.1.4 傳統的需求方法
17.2 敏捷方法中需求的不同
17.2.1 在XP中的需求
17.2.2 Scrum、產品擁有者和產品記錄
17.2.3 在RUP中的需求
17.3 一種可測量的、敏捷的需求方法：概要、路線圖以及適時的細化
17.3.1 細化用戶故事
17.3.2 細化用例
17.3.3 細化接收測試用例
17.4 小結
第18章 系統的系統及敏捷發布序列
18.1 敏捷組件發布日程
18.1.1 驅動敏捷序列的經驗教訓
18.1.2 敏捷發布序列的原則
18.2 敏捷發布序列
18.2.1 序列是同步的
18.2.2 序列是由願景、主題和端到端用例驅動的
18.2.3 保持序列被跟蹤並符合日程
18.2.4 測量過程和速度
18.2.5 觀察系統級模式
18.2.6 管理相互依賴關係
18.3 發布序列審查
第19章 管理高度分散式開發
19.1 在規模上，所有的開發都是分散式開發
19.2 案例研究1PINGIDENTITY公司：
分散式定義/構建/測試組件團隊
19.2.1 PingIdentity案例研究背景
19.2.2 學到的其他經驗教訓
19.3 案例研究2BMC軟體公司：高度分散式的、大規模企業中的敏捷改革
19.3.1 背景
19.3.2 IMD套用敏捷
19.3.3 結果
19.3.4 從編碼到編程：大範圍採用敏捷
19.3.5 吸取的經驗：貫穿大型組織的可伸縮敏捷實踐
19.3.6 下一步驟：敏捷成功的第一年後
19.4 重視溝通
19.4.1 穿梭訪問
19.4.2 通信基礎設施
19.5 企業級敏捷的基礎設施建設
19.5.1 原始碼管理
19.5.2 網路基礎設施
19.5.3 在早期疊代中提供基礎設施
19.6 小結
第20章 對客戶和操作的影響
20.1 敏捷方法對銷售和市場的好處
20.2 對產品市場/產品管理的影響
20.3 更小、更頻繁的發布更小、更頻繁發布的挑戰
20.4 最佳化敏捷發布過程
20.4.1 發布選擇1：忽略敏捷
20.4.2 發布選擇2：追求敏捷
20.4.3 發布選擇3：通過從外部發布中分離出開發發布，進行最佳化
20.5 來自真正的銷售和市場執行人員關於敏捷的真實挑戰和錯覺
第21章 組織變更
21.1 概述
21.2 為何敏捷需要改變組織
21.3 為Scrum和敏捷做準備
21.3.1 讓軟體過程和組織都“Scrumming”
21.3.2 讓執行主管成為組織變更的Scrum主管
21.3.3 當心：變更是很困難的
21.4 消除軟體生產率的障礙
21.5 給執行管理層的敏捷模型
21.5.1 支持採用敏捷
21.5.2 實踐你宣揚的理論：把敏捷作為執行管理層實踐
21.6 在大型組織中全面開展Scrum/敏捷
21.6.1 概觀、評估和先導準備
21.6.2 先導項目
21.6.3 組織擴張
21.6.4 獲得影響
21.6.5 度量、評估和調整
21.6.6 擴展和勝利
21.7 小結
第22章 度量業績
22.1 敏捷測量：主要區別
22.2 測量團隊業績
22.2.1 敏捷項目度量
22.2.2 敏捷過程度量
22.2.3 評估成果
22.3 關於度量、“過程策略”和團隊自評估
22.4 擴展至組織業績：綜合評價卡方法
22.4.1 效率
22.4.2 質量
22.4.3 價值交付
22.4.4 敏捷性
22.5 可伸縮的敏捷度量:為企業實現一個靈活的、自動化的和有意義的BSC
22.5.1 第1步：量化BSC矩陣元素
22.5.2 第2步：轉為字母等級
22.5.3 第3步：聚合成產品線、業務單元和企業
結論：敏捷是可伸縮的
