《硝煙中的 Scrum 和 XP》這本書并不厚，只有一百多頁。在Scrum的圈子里面這本書很有名氣，是很多人首推Scrum學(xué)習(xí)的入門資料。翻看了一半左右的內(nèi)容，這本書的內(nèi)容確實很接地氣，敏捷不是說出來的，是干出來的，需要注重實踐而非理論研究，而本書作者也正是一些真槍實彈的故事來介紹自己實踐敏捷的經(jīng)驗，這也很有可能是本書的名字的來源---硝煙來自于實戰(zhàn)。不過我覺得另外一個很受歡迎的原因也是書不算厚，入門閱讀起來相對容易一些。

Scrum是什么？

不像很多書開始就從基本概念講起，這本書只有短短幾句推薦了幾個網(wǎng)站自己學(xué)習(xí)Scrum的ABC知識。

對不起，你完全不了解Scrum或者XP？那你最好先去看一下這幾個鏈接：
? http://agilemanifesto.org/
? http://www.mountaingoatsoftware.com/scrum
? http://www.xprogramming.com/xpmag/whatisxp.htm
要是你真沒耐心去訪問這些網(wǎng)站，也沒關(guān)系。隨便翻翻看看吧。大多數(shù)Scrum的相關(guān)術(shù)語都會在書中慢慢講到，你會感興趣的。

好在Scrum本身的一些概念也并不是很復(fù)雜，Scrum不是開發(fā)產(chǎn)品的一種流程或一項技術(shù)，而是提供了一個框架，在這個框架里可以應(yīng)用各種流程和技術(shù)。另外有一個交流的說法是Scrum也是對一些PDCA這些基本管理方法的一個實例化的框架，所以有一定實戰(zhàn)經(jīng)驗的人開始用這個框架應(yīng)該也是可以找到共鳴的。

Scrum的基本概念和重要術(shù)語

為了便于后面的理解，還是需要有一個術(shù)語表，一圖勝千言，介紹前先上個圖：

Scrum的架構(gòu)圖

• Scrum的主要內(nèi)容可以用“1334”來表達

• 1 就是一個共同的價值觀
  

  敏捷價值觀

• 第一個3是三個關(guān)鍵角色：
  1．PO： Product Owner，產(chǎn)品負責人，描繪產(chǎn)品遠景，定義優(yōu)先級。互聯(lián)網(wǎng)公司的 PO一般由相關(guān)的產(chǎn)品經(jīng)理擔任；如果是為客戶項目， PO一般就是客產(chǎn)負責人。
  2．Scrum Master: Scrum的推動者，消除障礙，帶領(lǐng)過程運作。
  3 . Team一般由多個 developer組成，開發(fā)的主力,實現(xiàn)產(chǎn)品

• 第二個3是三件神器：Production Backlog、Sprint Backlog 和燃盡圖是三大神器。
  

  PB vs SB

• 最后一個4是四會：Sprint 計劃會、每日站會 Daily Scrum、Sprint 評審會（Sprint Review） 和Sprint回顧會（Sprint Retrospective）
  

  四會

戰(zhàn)斗開始

雖然說是一篇短文，實際上也有100多頁的樣子，有18個章節(jié)，詳細的方法還是建議把書仔細看一遍，下面只摘取一些有感覺的觀點，并盡量附上自己的理解。

1. 怎樣編寫產(chǎn)品 backlog

產(chǎn)品 backlog 是 Scrum 的核心，是一切的起源，在Scrum里面一般稱為故事 （ story ） ，有時候也叫做 backlog 條目，其實也就是我們常說的需求。backlog又跟我們常見的需求有什么差別呢？

• 產(chǎn)品 BACKLOG（示例）：

幾個特別需要關(guān)注的地方：

• 1） Imp：Importance（重要性）——產(chǎn)品負責人評出一個數(shù)值，指 示這個故事有多重要。例如 10 或 150。分數(shù)越高越重要。
• 2） Est：Initial estimate（初始估算）——團隊的初步估算，表示與 其他故事相比，完成該故事所需的工作量。小的單位是故事點（story point），一般大致相當于一個“理想的人天 （man-day）”。
• 3）How to demo（如何做演示）——它大略描述了這個故事應(yīng) 該如何在 sprint 演示上進行示范，本質(zhì)就是一個簡單的測 試規(guī)范?！跋冗@樣做，然后那樣做，就應(yīng)該得到……的結(jié) 果 ”。 如果你在使用 TDD（測試驅(qū)動開發(fā)），那么這段 描述就可以作為驗收測試的偽碼表示。

有時為了便于產(chǎn)品負責人判斷優(yōu)先級別，也可以在產(chǎn)品 backlog 中使用一些其它字段。需要讓產(chǎn)品 backlog 停留在業(yè)務(wù)層次上，如果產(chǎn)品負責人有技術(shù)相關(guān)的背景，那他可能添加這樣一個故事：“給 Events 表添加索引”。這就不是一個業(yè)務(wù)層次的故事，指出如何解決問題的應(yīng)該是開發(fā)團隊， 產(chǎn)品負責人只需要關(guān)注業(yè)務(wù)目標。

2. 怎樣準備 sprint 計劃

在 sprint 計劃會議之前，要確保產(chǎn)品 backlog 的井然有序。 它表示的意思是：

1. 產(chǎn)品 backlog 必須存在
2. 只能有一個產(chǎn)品 backlog 和一個產(chǎn)品負責人
3. 所有重要的 backlog 條目都已經(jīng)根據(jù)重要性被評過分，不同 的重要程度對應(yīng)不同的分數(shù)。
4. 產(chǎn)品負責人應(yīng)當理解每個故事的含義。他不需要知道每個故事具 體是如何實現(xiàn)的，但是他要知道為什么這個故事會在這里。

注意：產(chǎn)品負責人之外的人也可以向產(chǎn)品 backlog 中添加故事，但 是他們不能說這個故事有多重要，這是產(chǎn)品負責人獨有的權(quán)利。他 們也不能添加時間估算，這是開發(fā)團隊獨有的權(quán)利。

3. 怎樣制定 sprint 計劃

Sprint 計劃會議非常關(guān)鍵，應(yīng)該算是 Scrum 中重要的活動。要是它執(zhí)行的不好，整個sprint 甚至都會被毀掉。 Sprint 計劃會議會產(chǎn)生一些實實在在的成果：

• sprint 目標。
• 團隊成員名單（以及他們的投入程度，如果不是 100%的 話）。
• sprint backlog（即 sprint 中包括的故事列表）。
• 確定好 sprint 演示日期。
• 確定好時間地點，供舉行每日 scrum 會議。
  整個團隊和產(chǎn)品負責人都必須要參加sprint計劃會議，原因在于，每個故事都含有三個變量，它們兩兩之間都對彼此有著強烈 依賴。
  
  SEI三角形
  
  范圍（scope）和重要性（importance）由產(chǎn)品負責人設(shè)置。估算 （estimate）由團隊設(shè)置。在 sprint 計劃會議上，經(jīng)過團隊和產(chǎn)品負責人面對面的對話，這三個變量會逐步得到調(diào)整優(yōu)化。

3.1 不能在質(zhì)量上讓步

不管什么時候，團隊都要保證系統(tǒng)質(zhì)量，現(xiàn)在在質(zhì)量上節(jié)省下來一點時間，接下來的日子里你就要一直為它付出代價，這一點毋庸置疑，也沒有折扣可講?，F(xiàn)在如此、將來如此、 一直如此，直到永遠。
把外部質(zhì)量也看作范圍的一部分。有時出于業(yè)務(wù)考慮，可能會先 發(fā)布一個系統(tǒng)版本，其中用戶界面給人的感覺可能比較簡陋，而且 反應(yīng)也很慢；不過隨后會發(fā)布一個干凈的版本?？梢宰尞a(chǎn)品負責 人做權(quán)衡，因為他是負責定義項目范圍的人。 一旦產(chǎn)品負責人弄清楚內(nèi)部質(zhì)量是不可能讓步的，他一般都會處理 好其他變量。

3.2 決定 sprint 要包含的故事

因為有時間盒的概念，可能有一些用戶故事（例如故事D）不能被包括在當前Sprint里面，產(chǎn)品負責人很失望。雖然產(chǎn)品負責人在正常情況下不能控制團隊的估算生產(chǎn)率，他依然有很多種方式，對sprint 中放入哪些故事施加影響。
1.重新設(shè)置故事的優(yōu)先級
2.縮小某個故事的范圍，知道團隊隊相信故事D能在這個sprint 里完成為止
3.還可以拆分故事，把一些已有的故事拆小為幾個部分，這樣就可以放入故事D了

3.3 估算，團隊怎樣決定把哪些故事放到 sprint 里面？

書中提到了兩個技術(shù)：

1. 本能反應(yīng)（專家拍腦袋）
2. 生產(chǎn)率計算，這項技術(shù)包括兩步：
   1. 得出估算生產(chǎn)率
   2. 計算在不超出估算生產(chǎn)率的情況下可以加入多少故事。
      估算生產(chǎn)率其實也是一件很不容易的事情，又可以細化出不少方法，文中提了一個新名稱“昨日天氣（yesterday’s weather）”，其實也就是根據(jù)歷史經(jīng)驗去估算。另外還有經(jīng)典的PM中的人力資源計劃方法，還有一種“投入程度”的折算方法，在新團隊中默認放在了“70%”，這個數(shù)字挺有趣的。

“投入程度”表示“團隊有多少時間可以放在當前所承諾的故事上”。它永遠不可能是100%，因為團隊會把時間用于完成未經(jīng)計劃的條目、切換環(huán)境、幫助其他團隊、檢查郵件、修復(fù)自己出問題的電腦、在廚房中討論政治等等。

估算只是工具和手段，只要得出哪些故事要放到 sprint 里面，就算完成了目標。投入程度、資源可用性和估算生產(chǎn)率只是用來達成這個目標的手段。

3.4 DoD，定義“完成”

DoD在很多敏捷團隊中都有很高的關(guān)注度，我看到很多敏捷團隊宣傳海報也都會突出顯示DoD。這個確實是很多研發(fā)工作的痛點，而且敏捷很注重的質(zhì)量內(nèi)建活動對傳統(tǒng)開發(fā)的認知是有一定沖擊的，通過DoD可以協(xié)助開發(fā)人員進行自查，不僅僅開發(fā)完代碼，而是要把測試，文檔等一些交付必須的工作都完成。另外有一點很重要：產(chǎn)品負責人和團隊需要對“完成”有一致的定義。

3.5 這不是我要的

在 sprint 演示會議上，團隊演示了一個新特性，但產(chǎn)品負責人卻皺起眉頭，“呃，看上去不錯，但這不是我要的！”這樣的故事確實很常見。
書中提出了幾個方法：

1. 確保每個故事的所有字段都被填滿
2. 把故事拆分成更小的故事
3. 把故事拆分成任務(wù)
   • “任務(wù)”和“故事”的區(qū)別是什么呢？區(qū)別很簡單。故事是可以交付的東西，是產(chǎn)品負責人所關(guān)心的。任務(wù)是不可交付的東西，產(chǎn)品負責人對它也不關(guān)心。

3.6 技術(shù)故事

技術(shù)故事，或者叫做非功能性條目，是指的是需要完成但又不屬于可交付物的東西，跟任何故事都沒有直接關(guān)聯(lián)，不會給產(chǎn)品負責人帶來直接的價值。
例如：

• 安裝持續(xù)構(gòu)建服務(wù)器
• 編寫系統(tǒng)設(shè)計
• 重構(gòu) DAO 層

出于顯 而易見的原因，技術(shù)故事常常會因為某種原因給設(shè)置一個低優(yōu)先級，有時候產(chǎn)品負責人的做法是對的，但這只是少數(shù)情況。書中得出的結(jié)論是，產(chǎn)品負責人往往不能對此做出正確的權(quán)衡，需要跟PO去溝通協(xié)調(diào)，書中也提出了一些方法。

3.7 Bug 跟蹤系統(tǒng) vs. 產(chǎn)品 backlog

每個Sprint都可能會產(chǎn)生Bug，Bug不是故事，如何在Sprint中管理Bug就成為了一個問題。用 Excel 來管理產(chǎn)品 backlog 很不錯，用Excel管理Bug比較麻煩，書中作者用的是Jira。書中也給出了4條意見，也比較容易理解。

4. 怎樣讓別人了解我們的 sprint

就是要宣傳，透明有時候確實是最好溝通工具。要讓整個公司了解我們在做些什么，這件事情至關(guān)重要。否則 其他人就會發(fā)出抱怨，甚或?qū)ξ覀兊墓ぷ髯龀鲆軘唷?br> Scrum master 要把 sprint 信息頁打印出來，貼到團隊房間外面的墻上。路過的每個人都可以閱讀這張紙，了解這個團隊所做的事情。因為其中還包括了每日例會的時間地點，所以他也能知道 到哪里去了解更多信息。
Sprint 接近尾聲時，Scrum master 會把即將來臨的演示告知每個人。

5. 怎樣編寫 sprint backlog

有了計劃和宣傳后，下一步就是執(zhí)行計劃了。Sprint Backlog就是任務(wù)列表，如果映射到傳統(tǒng)的項目管理理論中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任務(wù)分解方法得到的WBS。
Scrum master 現(xiàn)在應(yīng)該創(chuàng)建 sprint backlog 了。 它應(yīng)該在 sprint 計劃會議之后，第一次每日例會之前完成。 作者試了很多方法，得出的結(jié)論是：我們發(fā)現(xiàn)管理 sprint backlog 有效的形式 ——掛在墻上的任務(wù)板！
注意——如果你用貼紙來記錄任務(wù)，別忘了用真正的膠帶把它們粘好，否則有一天你會發(fā)現(xiàn)所有的貼紙都在地上堆成一堆（深有感觸）。
可以通過燃盡圖來直觀的展示進度，通過觀察看板發(fā)現(xiàn)問題并及時干預(yù)。
作者還提到了兩個經(jīng)驗（我理解Scrum推崇的是人人平等的民主制，是自管理和為目標的團隊，過細的跟蹤式的管理是沒有太大必要的）：

1. 不需要特別針對某個任務(wù)的進展進行跟蹤
2. 用人天而不是人小時

--To be continued