細讀《硝煙中的Scrum和XP》，再想想我們做Scrum的經(jīng)歷，心里不禁想著：要是早一點看到這本書就好了。
為什么這本書叫硝煙呢？我理解是因為這是一本實戰(zhàn)書，書中的內(nèi)容來自于實戰(zhàn)，從書中可以看出來一次次的實踐、檢查、調整，一次次的小戰(zhàn)爭。如果我們想要從這本書學到一些東西，可以應用到我們的工作中來，我們需要認同一個點：以目標為導向。
書中首先強調了目標。在Scrum里，目標是什么，怎么呈現(xiàn)呢？henrik認為目標是通過產(chǎn)品backlog來表現(xiàn)的，里面包含里故事和特性，按照重要程度進行排序，并且有估算。里面包含了客戶想要的東西，并用客戶語言來進行描述。對于每一個故事，henrik認為需要包含ID、名稱、重要性、估算、驗收測試、注釋。驗收測試很重要，故事是否滿足要求，以驗收測試作為標準。
目標確定之后，就開始做計劃。在書中，henrik花了很大的篇幅來描述他們是怎么做計劃的，在做計劃之前還有個準備階段，確保我們已經(jīng)準備好了，可以做計劃了。這個準備階段也是我們做Scrum的時候，容易忽視的地方。henrik用了一章來描述準備工作，也給我們展現(xiàn)了一個DoR標準。
在迭代計劃一章，henrik描述了PO和DT是怎么各司其職的：PO負責澄清用戶故事和調整優(yōu)先級，DT負責估算和決定接受多少用戶故事。而對于質量，henrik的態(tài)度非常堅定。他描述了內(nèi)部質量（用戶看不到的要素，它對系統(tǒng)的可維護性有深遠影響?？删S護性包括系統(tǒng)設計的一致性、測試覆蓋率、代碼可讀性和重構等）和外部質量（用戶可以感知的。運行緩慢、讓人迷糊的用戶界面就屬于外部質量低劣）。一般來說，系統(tǒng)內(nèi)部質量優(yōu)秀，外部質量仍有可能很差。而內(nèi)部質量差的系統(tǒng)，外部質量肯定也不怎么樣。松散的沙灘上怎么可能建起精美的樓閣？所以在任何時候，團隊都要保證內(nèi)部質量，這一點毋庸置疑，也沒有折扣可將?，F(xiàn)在如此、將來如此、一直如此、直到永遠。
好的計劃是成功的一半，迭代計劃很重要。可是當我們時間不夠了怎么辦？我們要一直開下去嗎？不是的。在敏捷開發(fā)里面，時間盒是一個非常重要的概念，如果時間到了，我們就要停止，然后可以決定是明天繼續(xù)開迭代計劃會，還是這個迭代先這么干著。這么干著會不舒服，可以讓我們?nèi)W習，怎么去做調整，為以后做好迭代計劃積累經(jīng)驗。
在迭代計劃會上做計劃？需要重申迭代目標。我們需要PO回答這樣的問題：我們?yōu)槭裁匆M行這個Sprint？為什么我們不直接放假算了？這可以讓我們的PO去思考，從“為什么”的角度去思考，而不是從“是什么”的角度去思考。“為什么”更能打動人，更能做出非凡的產(chǎn)品。讀到這里，我想起了“黃金圈法則”。
確定的“為什么”之后，我們來決定怎么做，怎么去達成Sprint目標。我們從產(chǎn)品待辦列表里選擇用戶故事，來達成Sprint目標。在這里，我們要考慮兩個問題：1、團隊怎么決定把哪些故事放到Sprint里？2、PO怎么影響他們的決定？
先回答第二個問題，PO可以通過拆小故事，或者調整故事優(yōu)先級來施加他們的影響；而團隊可以通過本能反應，或者生產(chǎn)率來計算，這個Sprint可以接受多少個用戶故事。我建議采用生產(chǎn)率來作為接受依據(jù)。生產(chǎn)率怎么得來呢？來自于我們的歷史經(jīng)驗，可以隨著項目的進展進行適度的調整。如果是第一個迭代怎么辦？拍腦袋選一個吧。在計算生產(chǎn)率的時候，還涉及到用戶故事的估算。henrik建議采用估算撲克的方式來進行。
在迭代計劃會上，我們還需要明確“完成”的定義，團隊需要就“完成”達成一致。最好的“完成”定義是：隨時可以上線。
在我們已經(jīng)決定了當前Sprint能夠接受的用戶故事之后，我們需要對用戶故事進行拆分，把故事拆分成任務，并且對任務的工作量進行估算。故事和任務有什么區(qū)別呢？故事是可以交付的，而任務不可以。任務拆分的粒度是什么呢？建議拆分為每個人一天內(nèi)可以完成。
然后對于技術需求和bug的處理，henrik也給出了建議。我們可以跟PO說清楚，但是技術需求是必須要做的，我們需要在每個迭代留出一些時間來做技術需求。而bug可以交給PO，由PO把bug和用戶故事進行統(tǒng)一排序。當PO對技術不理解，不接受技術需求的時候怎么辦呢？我們可以用事實來說服他，以過去幾個迭代由于受到技術需求的影響，而造成生產(chǎn)率下降的事實來說服他。如果這還不能說服，那可以把技術需求包含在功能需求里面去做。這里回應了前面提到關于質量的堅定：質量是不可妥協(xié)的。
