引言：scrum不是方法學，它是乙個框架。
（一）scrum流程：
1.產品backlog：
2.sprint計畫
3.sprint backlog（每日scrum例會、更新任務牆和燃盡圖）
4.sprint演示會議
5.sprint回顧會議
6.sprint休整時刻
（二）scrum實施及注意事項
1.產品backlog：
1）產品backlog是scrum的核心，也是一切的起源；
2）產品backlog列表，一般包括的字段：id、故事描述、重要性、初始估算、如何做演示（本質就是乙個簡單的測試規範。如：「先這樣做，然後那樣做，就應該得到……的結果」）、備註。額外的故事字段（如：需求提出者、相關bug的id等）
3）讓產品backlog停留在業務層上。（面對技術的故事，可以問產品負責人「但是為什麼呢」的問題）
2.sprint計畫
1）前置條件：已有產品backlog列表，且只有乙個產品backlog乙個產品經理。
2）產品負責人應當理解每個故事的含義。
3）判定故事的重要性，是產品經理獨有的權利；判定估算時間，是團隊獨有的權利。
4）sprint計畫會議的產出：sprint目標、團隊成員名單、sprint backlog、確定演示日期、確定好每日scrum會議的時間地點。
5）每個故事有三個變數：其中範圍和重要性是由產品經理決定的，估算是由團隊決定的。
6）絕不能在質量上讓步，質量包括外部質量和內部質量，其中內部質量指使用者看不到的要素，它們對系統的可維護性有深遠影響。
7）scrum中的一切事情都有時間盒。
8）sprint計畫會議日程：圖：p15
9）試下回答「我們為什麼要進行這個sprint？為什麼我們不直接放假算了？」以找出sprint目標。
10）產品經理可通過以下方式影響sprint放哪些故事：a.重新設定優先順序；b.調整故事範圍；c.拆分故事。
11）團隊通過如下兩個技術決定sprint放哪些故事：a.本能反應；b.生產率計算（昨日天氣、投入程度）。
12）在牆上使用索引卡進行故事排序。圖：29
13）定義「完成」：一般指：隨時可以上線。
14）使用「計畫紙牌」做時間估算---通常團隊每個成員都要參與所有故事的估算。
15）明確故事內容。（方法：描述如何手工執行最典型的測試場景。）
16）技術故事：指需完成但不屬於可交付物的東西，跟任何故事都沒有直接關聯，不會給產品負責人帶來直接的價值。
注意：1）剛開始要試驗sprint的長度。不要浪費太多時間進行分析。選乙個可以接受的長度先開始再說，等做完一兩個sprint再進行調整。
2）確定了自己最合適的長度後，就要在長時間內堅持住，這樣慢慢地就變成了大家共同的心跳節奏。
3）scrum的要求：要把事情完全做完，達到可交付的狀態，事情只做了一半，它的價值就是0（也許還會是負數）。
4）作者經驗值：新團隊使用的預設投入程式通常是70%。
5）不要讓任務拆分出現在產品backlog。
6）估算時應對該故事的全部工作時間進行估算。
7）故事是可以交付的東西；任務是不可交付的東西。
8）sprint計畫的優先順序：
a.優先順序1：sprint目標和演示日期。
b.優先順序2：sprint中的故事列表。
c.優先順序3：sprint中每個故事的估算值。
d.優先順序4：srpint中每個故事「如何演示」。
e.優先順序5：生產率和資源的計算。
f.優先順序6：明確每日例會固定舉行的時間地點。
g.優先順序7：把故事拆分成任務。
9）當sprint backlog含有技術故事時，應採取如下做法：
a.試著避免技術故事。努力把技術故事變成可衡量業務價值的普通故事。
b.如果無法把技術故事變為普通故事，那就看看這項工作能不能當作另乙個故事中的任務。
c.如果以上二者都不管用，那就把它定義為乙個技術故事，用另外乙個單獨的列表來存放。產品經理負責人能看到它，但不能編輯它。
3.sprint backlog
1）使用「sprint資訊頁」，讓整個公司了解我們在做什麼。圖：42
2）sprint計畫會議一結束，scrum master建立sprint資訊頁，並給整個公司**sprint啟動的郵件。
3）發布管理sprint backlog最有效的形式---掛在牆上的任務板。（包括內容：計畫做的；正在做的；已完成；非計畫內的故事；下乙個sprint故事；燃盡圖）圖：46
4）用人/天作為時間估算的基礎（也稱為故事點），它的最小值為0.5。
5）每日scrum例會、更新任務牆和燃盡圖
6）「讓團隊坐在一起」的含義：互相聽到、互相看到、隔離（即，如果你們整個團隊突然站起來激烈的討論，團隊外的任何人都不會被打擾到。反之亦然。）
7）如何更新任務板：一般我們都是在每日例會的時候更新任務板。
a.每個人都會一邊描述昨天已經做的事情和今天要做的事情，一邊移動任務板上對應的即時貼。
b.如果他講的是乙個未經計畫的條目，那他就新寫一張即時貼，貼到板上。
c.如果他更新了時間估算，那就在即時貼上寫上新的時間並把舊的劃掉。
8）每日例會一結束，就要有人算出剩餘時間估算之和，更新燃盡圖。
注意：1）產品經理應離團隊很近，但他不應跟團隊坐在一起。
2）scrum教練，應該盡可能貼近團隊，但不久以後，就離開他們，讓他們凝聚在一起，自我管理。然後每隔一段時間（不能太頻繁），就去參加一次他們的sprint演示，看看任務板，聽聽晨會。
3）每日例會，防止持續時間超過15分鐘。
4）盡量讓整個團隊參與到保持sprint backlog及時更新工作中來。
《硝煙中的scrum和xp》讀書筆記
align center img 翻譯的不錯，淺顯易懂，非常具有實戰意義。完全是作者親身體會的總結。不過感覺scrummaster相關的東東介紹的太少了。以下是讀書筆記的分割線 scrum不是方法學，它是乙個框架。也就是說scrum不會告訴你到底該做些什麼。scrum 的強大和令人痛苦之處就在於你不...
讀《硝煙中的Scrum和XP》
用了兩天讀完了這本書，對scrum的概念了有了大致的了解，藉此根據個人理解做乙個筆記 scrum是實現agile development的一種方法，它是乙個框架。如果說agile是一種理念的話，那麼scrum就是一種實踐。我們通過運用scrum來達到agile manifesto提到的4個價值觀和1...
書評 硝煙中的Scrum和XP
且看下面兩段話 孫子兵法有云，兵無常勢，水無常形，能因敵之變化而取得勝利者謂之神，很多人都嚮往用兵如神的境界，想必也知道讀萬卷書不如行萬里路，紙上談兵的故事更是耳熟能詳 但偏偏不能舉一反三。且看風清揚的一段話 你將這華山派的三四十招融合貫通，設想如何一氣呵成，然後全部將它忘乾淨了，忘的乾乾淨淨，一招...