《Scrum 敏捷軟件開發(fā)》豆瓣鏈接

第一部分 啟航

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

為什么轉型困難

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

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

結束狀態(tài)是不可預知的

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

變化來的比以往更快

最佳實踐是危險的

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

為什么值得投入

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

Scrum 團隊更有可能只開發(fā)用戶真正需要的功能而线。

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

敏捷過程提倡可持續(xù)的開發(fā)步調锋华，日常工作具有更好的可控性嗡官，減少加班。

敏捷過程可以更快地看到工作成果毯焕，使團隊更緊密地協(xié)作衍腥，更可能滿足客戶的期望。

更快的產品上市時間

更高的質量

沒有遺留的缺陷拖累團隊芥丧，所以他們可以持續(xù)不斷地快速前進紧阔。

項目干系人的滿意度提升

敏捷能更友好地應對優(yōu)先級別的變化。

敏捷可以使技術團隊和商業(yè)團隊更容易達成共識续担。

現(xiàn)在的做法已不再有效

第2章 ADAPT 模型

成功擅耽、持續(xù)實施 Scrum 必備的5個活動：

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

意識開發(fā)工具

• 通過溝通乃沙，說明問題的存在
• 使用度量數(shù)據(jù)
• 接觸新的人與經驗

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

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

渴望提升工具

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

以團隊為導向的準則：

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

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

能力開發(fā)工具

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

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

Scrum 推廣工具

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

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

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

第5章 試點項目

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

第二部分 個體

第6章 克服抵觸

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

第7章 新角色

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

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

優(yōu)秀 ScrumMaster 的品質

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

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

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

優(yōu)秀產品負責人的品質

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

第8章 角色轉換

分析員

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

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

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

項目經理

在 Scrum 中不需要該角色领舰。傳統(tǒng)的項目經理可成為 ScrumMaster，產品負責人或其他團隊角色迟螺。

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

架構師

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

程序員

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

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

不能說：給我完美需求窍株，然后在我實現(xiàn)它時請走開民轴。

測試員

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

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

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

第9章 技術實踐

追求技術進步

測試驅動開發(fā)

TDD, Test-Driven Development, 測試驅動開發(fā)

確保系統(tǒng)中的所有代碼都可以被測試。

重構

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

集體所有權

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

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

持續(xù)集成

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

Scrum 團隊需要一個合適的自動化測試環(huán)境官卡。

對于復雜的系統(tǒng)，可以分割測試套件醋虏，但不能放棄持續(xù)集成寻咒。一個正式的每日構建對任何一個 Scrum 團隊都是必須的。

結對編程

設計：有意的而又是涌現(xiàn)式的

第三部分 團隊

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

第11章 團隊協(xié)作（暫無摘錄）

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

第13章 產品 Backlog

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

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

從文檔到討論的轉變

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

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

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

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

在產品 Backlog 中使用用戶故事

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

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

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

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

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

卡片不需要記錄所有的細節(jié)咖摹，細節(jié)在產品負責人和團隊討論后產生评姨。

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

持續(xù)地提煉需求

涌現(xiàn)的需求

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

涌現(xiàn)的需求讓你不可能很完美地預測進度吐句。前期的設計階段總是不完美胁后，在涌現(xiàn)的需求還沒有出現(xiàn)前，設計人員不可能考慮到這些需求嗦枢。

處理涌現(xiàn)需求的第一步是認識到我們不可能想到每一件事情攀芯。

產品 Backlog 冰山

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

梳理產品 Backlog

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

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

優(yōu)秀的 Scrum 團隊不需要在它開始實現(xiàn)某功能前已經充分理解它弛作。相反涕蜂，在每個 Sprint 開始時，對該功能的理解只需要達到該團隊認為相當有可能在該 Sprint 中實現(xiàn)它即可映琳。我們只需要一種準時和恰到好處的方法來理解產品 Backlog 中的功能需求机隙，而不是在前期就竭盡所能地理解所有需求瘦真。

為什么要持續(xù)地提煉需求

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

對用戶故事的持續(xù)提煉

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

用戶故事示例：

作為一個用戶仲闽，我需要登錄系統(tǒng)，以便只有我才能訪問自己的信息僵朗。

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

• 作為一名已注冊過的用戶赖欣，我能用我的用戶名和密碼登錄，讓我能信任該系統(tǒng)验庙。
• 作為一名新用戶顶吮，我能通過創(chuàng)建用戶名和密碼注冊，讓該系統(tǒng)能記住我的個人信息粪薛。
• 作為一名已注冊過的用戶悴了，我能改變我的密碼，讓我能保證它是安全的或容易記住的违寿。

（略）

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

加入滿意條件

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

示例：

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

滿意條件：

• 確保它可工作在大部分零售節(jié)假日：圣誕節(jié)捌木、復活節(jié)、總統(tǒng)節(jié)嫉戚、母親節(jié)刨裆、父親節(jié)澈圈、勞動節(jié)以及新年
• 支持跨2個日歷年的節(jié)日（不存在跨3個的）
• 節(jié)假日季節(jié)可以從某個節(jié)假日到另一個設定（比如感恩節(jié)到圣誕節(jié)）

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

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

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

通過事例說明

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

用戶故事示例：

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

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

測試工具推薦：FitNesse, Cucumber

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

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

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

創(chuàng)建 DEEP 的產品 Backlog

• 詳略得當（Detailed Appropriately）
• 做過估算的（Estimated）
• 涌現(xiàn)的（Emergent）
• 排列優(yōu)先級的（Prioritized）

不要忘記討論

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

第14章 Sprint

增量開發(fā)主要是一塊接著一塊地構建一個系統(tǒng)突梦。一部分功能先被開發(fā)出來诫舅，然后另一部分功能被加入前一部分功能，以此類推宫患。

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

迭代開發(fā)是先開發(fā)一個初步的版本这弧，得到用戶對它的反饋娃闲，然后開發(fā)包含反饋的后續(xù)版本，并根據(jù)需要不斷重復該過程匾浪。

Cockburn：迭代開發(fā)是一種重做調度策略皇帮。

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

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

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

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

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

“潛在可交付”的含義

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

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

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

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

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

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

在當前 Sprint 為下個 Sprint 做準備

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

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

在 Sprint 中團隊有兩個目標：

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

每個 Sprint 始終保持協(xié)作

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

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

避免特定活動的 Sprint

缺點：

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

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

固定 Sprint 長度的好處：

• 團隊受益于定期的節(jié)奏。當 Sprint 長度可變兄渺，團隊成員會經常對進度有點不確定缝龄。
• Sprint 計劃變得更容易
• 發(fā)布計劃變得更容易

絕不要延長 Sprint

不要改變目標

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

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

第15章 做計劃

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

逐步完善計劃

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

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

逐步完善計劃的優(yōu)勢：

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

區(qū)別對待估算和承諾

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

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

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

計算初始速率只是第一步，一旦有了歷史數(shù)據(jù)并創(chuàng)建置信區(qū)間后愉镰，需要把它變成一個范圍米罚。

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

第16章 質量

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

把測試集成到流程中

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

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

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

• 很難改進現(xiàn)有產品的質量
• 錯誤一直未被發(fā)現(xiàn)
• 項目狀態(tài)難以測量
• 錯失反饋時機
• 測試很可能被削減

不同層次的自動化

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

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

用戶界面的負面屬性：

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

保留用戶界面測試的角色

在服務層執(zhí)行主要的測試笔咽。在用戶界面層的測試只需要確認服務被正確的按鈕調用搔预，并且數(shù)值正確顯示在結果字段中。

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

第四部分 組織

第17章 擴展 Scrum

Scrum of Scrums 會議

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

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

第18章 分布式團隊

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

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

Scrum 只是一種項目管理框架橄霉，它的大量實現(xiàn)細節(jié)留給每個團隊來完成。

創(chuàng)建一個有凝聚力的團隊邑蒋，關鍵在于團隊成員間建立信任感姓蜂。

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

各個團隊是由技能、態(tài)度和工作方式等方面志趣相投的成員組成的團隊诀蓉，比各團隊是圍繞著表面屬性（國籍栗竖，工種等）組成的團隊更穩(wěn)固。

作者強調：

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

第19章 與其他方法論共存

敏捷不是目標，敏捷意味著持續(xù)的改進沥曹。

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

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

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

第五部分 下一站

第21章 看看進展如何

測量的目的

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

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

一般性的敏捷評估

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

Scrum 團隊平衡記分卡

Kaplan 和 Norton 建議企業(yè)應該從四個角度：財務、客戶桑滩、業(yè)務流程及學習與成長來衡量業(yè)務的狀態(tài)梧疲。

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

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

第22章 沒有終點

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