《Scrum 敏捷軟件開發》豆瓣鏈接

第一部分 啟航

第1章 為什么敏捷轉型難（但值得）

為什么轉型困難

成功的變革不是完全的自上而下或者自下而上

成功實施 Scrum 的關鍵是結合自上而下和自下而上的變革相關要素。

結束狀態是不可預知的

這是一個沒有終點的過程，需要持續的改進。

變化來的比以往更快

最佳實踐是危險的

大野耐一：有一些事情稱之為標準工作，但是標準是在不斷變化的。如果我們把一些事情作為最好的可能方法，那么對于精益（持續增量的改善）的動力就消失了。

為什么值得投入

更高的生產力及更低的成本

Scrum 團隊更有可能只開發用戶真正需要的功能。

員工的參與度和工作滿意度增強

敏捷過程提倡可持續的開發步調，日常工作具有更好的可控性，減少加班。

敏捷過程可以更快地看到工作成果，使團隊更緊密地協作，更可能滿足客戶的期望。

更快的產品上市時間

更高的質量

沒有遺留的缺陷拖累團隊，所以他們可以持續不斷地快速前進。

項目干系人的滿意度提升

敏捷能更友好地應對優先級別的變化。

敏捷可以使技術團隊和商業團隊更容易達成共識。

現在的做法已不再有效

第2章 ADAPT 模型

成功、持續實施 Scrum 必備的5個活動：

• 意識（Awareness），當前的過程已不能實現可接受的結果
• 渴望（Desire），把實施 Scrum 作為一種方法來解決當前的問題
• 能力（Ability），有能力成功實施 Scrum
• 推廣（Promotion），通過分享經驗來推廣 Scrum
• 傳遞（Transfer），把實施 Scrum 帶來的影響擴大到整個公司

意識開發工具

• 通過溝通，說明問題的存在
• 使用度量數據
• 接觸新的人與經驗

重視新員工的多樣性，刻意尋求不同背景的人。

• 運行一個試點項目
• 關注最重要的變革理由

渴望提升工具

• 告訴人們有更好的辦法
• 創造一種緊迫感
• 造勢（讓愿意做的人去做）
• 讓團隊“試駕 Scrum”
• 統一激勵機制（或至少消除不利因素）

以團隊為導向的準則：

1. 更好地完成份內工作
2. 為知識的分享做出貢獻
3. 愿意跨職位工作
4. 達到團隊交付目標和質量目標

• 聚焦恐懼的消除
• 幫助人們學會放手
• 不要詆毀過去
• 努力讓員工參與

能力開發工具

• 提供輔導和培訓
• 賦予個體責任
• 共享信息
• 設置合理的目標
• 立即行動

Greene and Fry：做實驗，保持耐心，并盼著犯錯誤。

Scrum 推廣工具

• 講述成功故事
• 開一個“敏捷野生動物園”
• 吸引注意力和興趣

第3章 Scrum 實施模式（暫無摘錄）

第4章 漸進敏捷（暫無摘錄）

第5章 試點項目

Scrum 團隊使用速率（Velocity）來衡量項目進展，它衡量某個 Sprint 中完成的工作。

第二部分 個體

第6章 克服抵觸

員工和管理人員抵觸變革的主要因素

第7章 新角色

ScrumMaster 對團隊成員沒有管轄權但對流程有控制權。

ScrumMaster 的職責是提供指導而非答案。

優秀 ScrumMaster 的品質

• 負責
• 謙遜
• 協作
• 投入
• 有影響力
• 知識淵博

產品負責人為團隊指出正確的目標，ScrumMaster 幫助團隊盡可能有效地達到目標。

產品負責人負責給團隊提供愿景和邊界。

優秀產品負責人的品質

• 始終都在
• 懂業務
• 善于溝通
• 果斷
• 得到授權的

第8章 角色轉換

分析員

在使用等級式產品負責人的大型項目中，一些分析員會轉變成產品負責人的角色。
首席產品負責人考慮用戶和市場，而分析員則可能擔任各團隊的產品負責人，協助首席產品負責人將愿景落實到團隊的產品 Backlog 中。

是否需要將分析員計劃未來的工作放到當前 Sprint 的 Backlog？

建議在 Sprint 的 Backlog 中包含 Sprint 計劃會議中可以明確的所有具體分析任務。例如，如果產品負責人和團隊都同意下個 Sprint 應包括A任務，那么與A任務相關的初步分析工作就應該被確認、估算并包括在當前 Sprint 的 Backlog。如果下個 Sprint 的工作尚不清楚，則當前 Sprint 的 Backlog 就不應包含與下個 Sprint 相關的具體工作任務。

項目經理

在 Scrum 中不需要該角色。傳統的項目經理可成為 ScrumMaster，產品負責人或其他團隊角色。

Scrum 團隊成員自己承擔選擇任務的責任。

架構師

架構師的主要職責是考慮變化和復雜性。

程序員

他們將不能再呆在自己的隔間里等待有人來告訴他們具體該寫什么程序。他們需要積極主動地理解產品需求。

在 Scrum 團隊中的程序員被期望能共享產品整體成功的責任。

不能說：給我完美需求，然后在我實現它時請走開。

測試員

測試員需要適應更頻繁且有意義地與其合作者交流，包括內部與外部。

不能說：給我完美需求文檔，我將確保系統做了它描述的所有內容。

每個人都需要思考產品，對每個特性提出問題并思考如何將它加入（或減少）到整個產品中。

第9章 技術實踐

追求技術進步

測試驅動開發

TDD, Test-Driven Development, 測試驅動開發

確保系統中的所有代碼都可以被測試。

重構

通過不斷地重構，并且在一些小問題變成大問題前不斷地修復它們，有助于防止代碼腐爛。

集體所有權

確保開發人員不會變得太專以至于只能在某一方面做出貢獻。

確保沒有一個地方變得太錯綜復雜以至于只有一個開發人員可以明白和完成其工作。

持續集成

采用持續集成的 Scrum 團隊中的任何一個程序員，要求他每天遞交幾次代碼，并且運行一個覆蓋整個應用程序的回歸測試套件。

Scrum 團隊需要一個合適的自動化測試環境。

對于復雜的系統，可以分割測試套件，但不能放棄持續集成。一個正式的每日構建對任何一個 Scrum 團隊都是必須的。

結對編程

設計：有意的而又是涌現式的

第三部分 團隊

第10章 團隊結構（暫無摘錄）

第11章 團隊協作（暫無摘錄）

第12章 領導自組織團隊（暫無摘錄）

第13章 產品 Backlog

使用順序式開發過程的時候，我們嘗試用一個很長的前期需求收集階段作為開始，在該階段中，產品的需求會被完全確定和細化。這個想法是，在項目前期，通過更長期的、更努力和更好的思考，項目的主體開發階段將不會遇到任何黑暗角落。

Scrum 團隊放棄漫長的前期需求階段。對需求的概要描述會在項目早期收集，但在那個時候它們只是最粗略的描述，然后在項目進行過程中逐步完善。它們被記錄在一個產品 Backlog 中。產品 Backlog 包括所有待添加功能的列表，它由產品負責人維護，并根據優先級按順序保存。與傳統的需求文檔不同，產品 Backlog 具有很高的動態性，其中的事項會被增加或減少，同時在每個 Sprint 中，這些事項會因為對產品、用戶和團隊等有更多的了解而重新排列優先級。

從文檔到討論的轉變

• 書面文檔會讓你暫停做出判斷。
• 有了書面文檔，我們就不能像談話時那樣反復聲明要表達的意思。
• 書面文檔不利于團隊責任制。

敏捷開發的目標是找到文檔和討論之間的合理的平衡。

你并不需要除去所有的文檔。只要盡量消除不需要的文檔并讓其他保留的文檔盡可能簡短，甚至考慮自動生成這些文檔。

《精益軟件開發》作者 Tom Poppendieck：當文檔主要用于用戶任務交接時，它們是罪惡的；而當它們用于捕捉交談記錄使其不被忘記時，則是有價值的。

在產品 Backlog 中使用用戶故事

用戶故事是將團隊焦點從編寫功能需求轉移到談論它們的最佳方式。

用戶故事是從需要該功能的用戶角度來講述的短小簡單的描述。

簡單的模板：作為一個<用戶類型>，我想<某個目標>，以便于<一些原因>。

與其將用戶故事寫在某個軟件中，作者更喜歡將用戶故事寫在 3# x 5# 的索引卡片上。

用戶故事并不意味著像是需求文檔那樣完整的功能描述，它只是一個開始。用戶卡片可作為開發團隊和產品負責人之間的承諾：開發團隊答應產品負責人，在他們開發該用戶故事前將與產品負責人討論，而產品負責人答應團隊，當團隊準備討論時他保證將有時間參與。

卡片不需要記錄所有的細節，細節在產品負責人和團隊討論后產生。

作者收集到的數據表明：6人團隊在為期2周的 Sprint 中平均能完成6到9個用戶故事。

持續地提煉需求

涌現的需求

不能提前確認的功能被稱作涌現的需求（特指沒有預期到的需求）。

涌現的需求讓你不可能很完美地預測進度。前期的設計階段總是不完美，在涌現的需求還沒有出現前，設計人員不可能考慮到這些需求。

處理涌現需求的第一步是認識到我們不可能想到每一件事情。

產品 Backlog 冰山

在產品 Backlog 中，團隊很快要實現的那些條目必須擁有足夠的細節，以便每條都能在一個 Sprint 中編程實現、測試和集成。所以位置靠前的用戶故事會更小并更容易理解，而位置靠后的用戶故事則更大，理解上也更粗略一些。

梳理產品 Backlog

黃金法則是我們應花每個 Sprint 中10%的精力梳理 Backlog 列表，以便為將來的 Sprint 做準備。

對于產品 Backlog 的討論不局限于某個時間或會議，任何時候，任何團隊成員之間，都可能進行討論。

優秀的 Scrum 團隊不需要在它開始實現某功能前已經充分理解它。相反，在每個 Sprint 開始時，對該功能的理解只需要達到該團隊認為相當有可能在該 Sprint 中實現它即可。我們只需要一種準時和恰到好處的方法來理解產品 Backlog 中的功能需求，而不是在前期就竭盡所能地理解所有需求。

為什么要持續地提煉需求

• 事情會發生變化
  在項目的過程中，優先級會發生變化。
• 不需要
  開發條目要給予足夠的可見性，以便讓團隊能看到足夠遠，從而避免大部分問題。
• 時間有限
  同等對待所有的需求是一種浪費。

對用戶故事的持續提煉

團隊成員必須能夠創建大型的需求，這些需求位于產品 Backlog 冰山的底部；之后將它們分解為中等規模的條目；最后將它們拆分為足夠小的塊，從而讓每個小塊都能在單個 Sprint 中交付。

用戶故事示例：

作為一個用戶，我需要登錄系統，以便只有我才能訪問自己的信息。

該用戶故事可能被拆分為更小的用戶故事集合：

• 作為一名已注冊過的用戶，我能用我的用戶名和密碼登錄，讓我能信任該系統。
• 作為一名新用戶，我能通過創建用戶名和密碼注冊，讓該系統能記住我的個人信息。
• 作為一名已注冊過的用戶，我能改變我的密碼，讓我能保證它是安全的或容易記住的。

（略）

在一個大需求被拆分為小的故事后，建議在 Backlog 中去掉該需求。如果需要可以備份該需求以便可查。

加入滿意條件

當用戶故事被拆分到足夠小的粒度，進一步拆分已不再有幫助。此時通過向用戶故事中增加滿意條件，我們還可以持續地提煉需求。一個滿意條件是某個簡單的概要驗收測試。滿意條件可以防止團隊迷失方向。

示例：

作為負責市場的副總裁，我想在評估以往廣告促銷活動的效果時可以選擇節假日季節，以便我能確認那些有利潤的促銷活動。

滿意條件：

• 確保它可工作在大部分零售節假日：圣誕節、復活節、總統節、母親節、父親節、勞動節以及新年
• 支持跨2個日歷年的節日（不存在跨3個的）
• 節假日季節可以從某個節假日到另一個設定（比如感恩節到圣誕節）

學會在沒有詳細說明書的情況下開始

這并不是說要拋棄使用詳細說明書，實際上是要合理地使用它。

詳細說明書的一個不足是它們很少保持更新。

通過事例說明

改變寫詳細說明書的方式，考慮通過事例來說明一個產品。

用戶故事示例：

作為一個雇員，我希望對于我享有的假期請求可以自動批準，那樣我就無需等到某人手工批準。

該用戶故事的事例——申請比可用天數更多時間的請假不會被自動批準的例子

測試工具推薦：FitNesse, Cucumber

跨職能的團隊能降低對文檔的需求

Scrum 團隊是一個跨職能、多學科的團隊。

沒有采用敏捷時，測試人員常常抱怨程序員沒有持續更新文檔，而程序員抱怨他們不能從這些文檔中受益。

創建 DEEP 的產品 Backlog

• 詳略得當（Detailed Appropriately）
• 做過估算的（Estimated）
• 涌現的（Emergent）
• 排列優先級的（Prioritized）

不要忘記討論

與產品 Backlog 中所寫內容同等重要的是針對它的討論。這些討論發生在團隊和產品負責人頭腦風暴討論確定產品 Backlog 最初的事項的時候，也發生在 Sprint 中團隊和產品負責人持續提煉他們對某個功能的理解的時候。

第14章 Sprint

增量開發主要是一塊接著一塊地構建一個系統。一部分功能先被開發出來，然后另一部分功能被加入前一部分功能，以此類推。

Alistair Cockburn：增量開發是一種分段和調度策略。

迭代開發是先開發一個初步的版本，得到用戶對它的反饋，然后開發包含反饋的后續版本，并根據需要不斷重復該過程。

Cockburn：迭代開發是一種重做調度策略。

迭代和增量開發指的是產生反饋，從中學習，之后調整我們正在構建的東西和我們的構建方式。

每個 Sprint 應遞交可工作的軟件

學會如何在每個 Sprint 中遞交可工作的軟件是一個新的 Scrum 團隊必須克服的最大挑戰之一，但是做到這點對于實現敏捷是非常關鍵的。

敏捷方法強調可工作的軟件，因為：

• 可工作軟件鼓勵反饋
• 可工作軟件幫助團隊衡量它們的進度
  項目中最大的風險之一就是不知道還剩余多少工作量需要完成。
• 可工作軟件允許產品在需要時盡早發布

“潛在可交付”的含義

任何一個新團隊需要做的一件事情是討論并同意“完成（done）”的定義，該定義的內容與應用于所有產品 “Backlog” 的用戶故事的滿足條件是一樣的。

在我們想為每個 Sprint 提交潛在可交付的產品的某個部分時，我們不需要在每個 Sprint 結束時就具備一個完整的產品。產品是可用的，對于這個正在開發的特性，其功能可能不全但是真的可以工作。

識別“潛在可交付”的指導方針

• 潛在可交付意味著測試過
• 潛在可交付并不意味著系統功能的完整
• 潛在可交付意味著集成已做好

每個 Sprint 提交一些有價值的東西

Scrum 團隊要在每個 Sprint 提交一些對用戶或客戶有價值的東西，完成那些可以讓用戶看到功能特性的任務。

在當前 Sprint 為下個 Sprint 做準備

只在一個 Sprint 中塞入能完成的東西

放入 Sprint 中的每個用戶故事必須理解透徹，并在這個 Sprint 中通過各種討論后確認能在這個 Sprint 中完成。

在 Sprint 中團隊有兩個目標：

1. 完成當前 Sprint 計劃的工作
2. 準備下一個 Sprint

每個 Sprint 始終保持協作

Scrum 項目的特點就是跨職能團隊一起工作，而不是將工作從一個組交接給另一個組。

Grossman：在蘋果公司，產品不會從一個團隊傳遞給另一個。不存在分離的、順序式的開發階段，相反，它是同時進行并且是一體的。產品通過所有部門并行的方式一起完成，包括設計、硬件和軟件，經過無窮輪的多學科的設計評審。

避免特定活動的 Sprint

缺點：

• 進度風險增加
• 花太長時間完成從想法到可運行、測試過的功能特性
• 并沒有真正解決交迭工作的問題

保持時間箱定期性和嚴格性

固定 Sprint 長度的好處：

• 團隊受益于定期的節奏。當 Sprint 長度可變，團隊成員會經常對進度有點不確定。
• Sprint 計劃變得更容易
• 發布計劃變得更容易

絕不要延長 Sprint

不要改變目標

在 Sprint 里不許改變任何任務，團隊在第一天承諾一系列工作，然后期望它們的優先級在整個 Sprint 保持不變。

Scrum 不允許變化進入 Sprint 而樂于異常終止并啟動一個新 Sprint。

第15章 做計劃

做計劃是 Scrum 的基礎。Scrum 團隊始終承諾開發最有價值的功能。要做到這一點，團隊和產品負責人必須要有交付某個功能會花費多少開發成本的估算，否則他們只能按照意愿來排列優先級。

逐步完善計劃

早期計劃要抓住將要交付內容的要素，但是把細節放到以后考慮。我們只在自己有足夠多的知識來支撐這些細節的時候才添加它們。

在早期的計劃中不考慮細節，并不是說我們不能承諾項目結束時將交付什么內容，只是我們需要為變更及其對應項目的不確定性預留一些空間。

逐步完善計劃的優勢：

• 它可以最大限度地減少時間上的投資
  項目開始前詳細的計劃基于非常多的假設，但隨著項目的進行，這些假設會與現實不符。
• 它允許在最佳時機做決策
  項目參與者在項目進行過程中會越來越了解他們的項目。
• 它允許我們改變路徑
• 它可以幫助我們避免落入相信計劃的陷阱
  一個徹底的、證據充分的計劃可以欺騙我們，讓我們相信一切都已經考慮周全。

區別對待估算和承諾

如果沒有一個好的估算作為開始，一個團隊的承諾將變得毫無意義。

要有一個好的估算，團隊和產品負責人需要知道兩個關鍵問題：

• 需要完成的工作的規模
• 對團隊完成這個工作的進度的預期

計算初始速率只是第一步，一旦有了歷史數據并創建置信區間后，需要把它變成一個范圍。

團隊最好有歷史數據或者運行一個或兩個 Sprint 后再做出承諾。

第16章 質量

質量保證是整個團隊的責任。

把測試集成到流程中

測試完全不是事后的糾正活動，而是為了驗證在之前的開發過程中沒有引入錯誤。

愛德華·戴明：我們應該停止依靠大量檢驗來保證質量，而是要改進工藝流程，從一開始就生產出優質的產品。

為什么最后才測試沒有效果：

• 很難改進現有產品的質量
• 錯誤一直未被發現
• 項目狀態難以測量
• 錯失反饋時機
• 測試很可能被削減

不同層次的自動化

很難寫出自動化測試的一個原因是在錯誤的層次上進行自動化。

自動化測試金字塔，從下到上分別為：單元，服務，UI

用戶界面的負面屬性：

• 脆弱。一個小變動可以破壞很多測試。
• 成本高
• 耗時

保留用戶界面測試的角色

在服務層執行主要的測試。在用戶界面層的測試只需要確認服務被正確的按鈕調用，并且數值正確顯示在結果字段中。

很多自動化測試投入上的錯誤是因為一直忽視了整個中間服務層的測試。

第四部分 組織

第17章 擴展 Scrum

Scrum of Scrums 會議

每個參與者要回答三個問題：

1. 從上次會議后，我的團隊做了哪些會影響其他團隊的東西？
2. 在下次會議前，我的團隊計劃做哪些會影響其他團隊的東西？
3. 我的團隊遇到哪些問題可以尋求其他團隊的幫助？

第18章 分布式團隊

沒有共同愿景，幾乎不可能形成一個強有力的團隊文化。

團隊文化部分起源于團隊成員彼此間達成的共識。

Scrum 只是一種項目管理框架，它的大量實現細節留給每個團隊來完成。

創建一個有凝聚力的團隊，關鍵在于團隊成員間建立信任感。

不幸的是，許多項目過早地安排太多時間用于團隊建設的練習和討論，這是一個普遍和危險的錯誤。在團隊早期的運行過程中，越多的人和另外的人進行交互，越有可能做出匆忙的判斷并強調他們的差異。作者建議推遲關系建設，直到團隊成員彼此了解更重要的東西，如特定技能、優勢、工作方式等。可以通過在早期關注進展而非關系建設來做到這一點。

各個團隊是由技能、態度和工作方式等方面志趣相投的成員組成的團隊，比各團隊是圍繞著表面屬性（國籍，工種等）組成的團隊更穩固。

作者強調：

1. 項目啟動時焦點要放在早期進展的演示上
2. 社交的整個預算不應該花在前面兩個 Sprint
3. 早期的社交活動應該依賴于項目的工作，諸如為制定版本發布計劃而把團隊召集到一起。

第19章 與其他方法論共存

敏捷不是目標，敏捷意味著持續的改進。

第20章 人力資源、后勤和PMO

在工作空間里應該可見的東西

• 大的、可見的圖表。如燃盡圖。
• 額外的反饋設備。如熔巖燈。
• 團隊里的每個人
• Sprint Backlog
• 產品 Backlog
• 至少一個大白板
• 一些安靜和私有的空間
• 食物和飲料
• 一個窗戶

第五部分 下一站

第21章 看看進展如何

測量的目的

測量的真正目的是為了減少不確定性。

在軟件度量的討論中，我們常常陷入追求完美的沼澤。我們其實不需要完美的測量，我們只需要測量來幫助我們回答問題。

一般性的敏捷評估

一個生意并不需要完美，它只是需要比競爭者做得好（并且一直保持領先）就行了。

Scrum 團隊平衡記分卡

Kaplan 和 Norton 建議企業應該從四個角度：財務、客戶、業務流程及學習與成長來衡量業務的狀態。

作者覺得更適合的另外的四個角度：

• 卓越運作
  團隊努力提供以高生產率生產高品質的產品，同時滿足成本和進度目標。
• 面向用戶
  團隊專注提供客戶所需要的功能。
• 商業價值
  節約了成本，增加收入等。
• 未來的方向
  在遞交今天的產品和功能的同時，團隊建設未來所需的技能和能力。

第22章 沒有終點

Scrum 團隊圍繞著可遞交的功能點來組織，而不是圍繞著技術或架構分層。