翻譯的不錯， 淺顯易懂， 非常具有實戰意義。完全是作者親身體會的總結。不過感覺scrummaster相關的東東介紹的太少了。

====================以下是讀書筆記的分割線===================

Scrum不是方法學，它是一個框架。也就是說Scrum不會告訴你到底該做些什么。

Scrum 的強大和令人痛苦之處就在于你不得不根據自己的具體情況來對它進行調整。

產品 backlog是 Scrum的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。它里面包含的是客戶想要的東西，并用客戶的術語加以描述。

一個backlog條目就是一個story, 包括：
id,
name,
優先級,
估算時間(多少人天),
如何演示(最終的結果是個什么樣子, 簡單的描述就是“先這樣做，然后那樣做，就應該得到……的結果  ”, 可以理解為測試的偽代碼),
備注(相關信息, 解釋說明, 相關資料引用, 一般都比較簡短)

如何解決問題的應該是開發團隊，產品負責人只需要關注業務目標。

不斷的問產品負責人“但是這樣做是為什么呢”這樣的問題，一直問下去，直到我們發現內在的目標為止。然后再用真正的目標來改寫這個故事, 最開始的技術描述只會作為一個注解存在。

在 sprint 計劃會議之前，要確保產品 backlog 的井然有序。

產品負責人應當理解每個故事的含義. 他不需要知道每個故事具體是如何實現的，但是他要知道為什么這個故事會在這里。

產品負責人有決定每一個故事優先級的權利

Sprint 計劃會議非常關鍵，應該算是 Scrum中最重要的活動

每個故事的三個重要變量:范圍, 估算, 重要性
范圍和重要性由產品負責人制訂, 估算由開發人員制訂

何為"范圍": 比如做某件事情, 是否還需要做另外一件事

產品質量分為內部質量和外部質量, 可以先發布一個很簡陋, 運行很慢的系統, 也就是外部質量很差的系統, 然后再進行調整, 但是內部質量(可維護性, 代碼可讀性, 測試覆蓋率和重構)決沒有討價還價的余地

Scrum中的一切事情都有時間盒。

當開了長時間的會議依然沒法確定一個sprint計劃, 可以規定一個最終的時間期限, 如果還是沒法做出, 就另外安排一個時間來開sprint計劃會議， 而不是一味延長時間

scrum的要求: 把事情完全做對, 達到完全可交付的狀態, 事情只做了一半, 它的價值就是0.

一旦時間估算值比較大, 其精確程度就很難把握

通過對故事的演示, 來揭示故事的范圍

故事和任務的區別:故事是可以交付的東西, 是產品負責人關心的, 任務是不可交付的, 產品負責人無須關心

無論你的 sprint backlog 是什么形式，都要盡力讓整個團隊參與到保持 sprint backlog 及時更新的工作中來。

ScrumMaster為團隊提供支持，消除他們的障礙

回顧是 Scrum中第二重要的事件（最重要的是 sprint 計劃會議），因為這是你做改進的最佳時機！

回顧會議中, 問"如果時間可以倒流，從第一天重新開始這個 sprint，那你覺得哪些事情會用其它方式來做？"

很多時候，只要能清楚地指出問題所在，到了下一個sprint，問題也許就自行解決了。

Scrum 注重的是管理和組織實踐，而XP 關注的是實際的編程實踐。

結對編程令人精疲力竭，不能全天都這樣做。

結對編程可以增進團隊間的知識傳播。速度快到令人難以想象。

多數情況下，開發人員掌握TDD的唯一方式就是跟一個熟悉 TDD的人一起結對編程，一旦掌握以后，他就會受到徹底的影響，從此再也不想使用其它方式工作。

HSQLDB 用作嵌入式的內存數據庫，在測試中使用。

Jetty用作嵌入式的內存 Web 容器，在測試中使用

剛開始應該想辦法提高手工測試的效率。

一開始就應該保持設計簡單化，然后不斷進行改進；而不是一開始努力保證它的正確性，然后就凍結它，不再改變。

你可以打破這里的任一規則，不過一定要有個好理由，并且記錄下來。

“測試人員”指的是“主要技能是測試的人”，而不是“只做測試的人”。

開發人員常常都是很差勁的測試人員。尤其是他們測試自己代碼的時候。

測試人員應該跟編寫測試代碼的開發人員一起結對編 程。如果測試人員根本不會編程，他也應該跟開發人員結對，即便 他只能坐在一邊看，讓開發人員敲鍵盤。相對于好的開發人員，好 的測試人員常常能想出多種不同類型的測試，所以他們可以互補。

即使所有的編程活動都已完成，距離產品發布還有很遙遠的距 離。至少復雜系統是這樣的。

在 Scrum 團隊中含有兼職成員一般都不是什么好主意。

“團隊凝聚力”是Scrum的核心要素之一，如果一個團隊合作工作達多個sprint之久，他們就會變得非常緊密。

Scrum master 檢查列表(職責)
創建sprint信息(目標, 團隊大小, 時間估算), 昭示天下
確保晨會正常開始和結束
增刪sprint中的故事
向團隊傳達項目進度(backlog, 燃盡圖)
排除開發過程中的障礙和干擾
sprint演示, 并昭示天下
組織召開sprint回顧會議
總結本次sprint經驗教訓和更新實際生產率估值


八卦
作者Henrik 在東京長大，目前與他的妻子 Sophia 和兩個孩子生活在斯德哥爾摩。他在空閑時間還是一個活躍的音樂家，跟本地樂隊一起創作樂曲，玩貝司和鍵盤。