參考網站：http://hi.baidu.com/cly84920/item/c11fddc48e27c80c0ad93a03

前些天在微博上看到人郵出版社說即將出版《精益開發實戰》這本書，而書的作者就是《硝煙中的scrum和xp》的作者Henrik！立馬心動，幾天後在china-pub上看到書已經開賣了，馬上下單。今天上午書到了。

一口氣讀完。對比上一本講scrum的書，這本書中有很多地方值得注意：

1）團隊規模 和 scrum of scrums。

無論是scrum之父肯施瓦伯的書《應用scrum進行軟體專案管理》，還是《硝》，都重點講的是scrum本身，而scrum團隊的規模都不大，按Henrik在《硝》中的說法，團隊規模最好在5~9人之間，最好是7個人。如果人數特別多，就應該使用scrum of scrums——將團隊拆成幾個更小的團隊，每個小團隊各自使用scrum，然後各個團隊再派負責人蔘加團隊之間的scrum。兩本書關於scrum of scrums講的都並不多，《硝》講了一些，但它其實變化很大——多團隊之間並不是每日站立會議，而是每週一次，全員參與，15分鐘以內，溝通的方式不像是“交流”而更像是“彙報”。

《精》中講的案例則正好填補了這個空白，講的是一個由60人組成的團隊！這個大團隊就拆成了5支小團隊，共同配合。本書很細緻地講解了怎麼進行scrum of scrums——當然，它管這個叫精益，並不是典型的scrum。

5支團隊分別是：1支產品分析團隊，1支測試團隊和3支功能開發團隊。

其中產品分析團隊和測試團隊都會派人進入功能開發團隊，這些人是交叉團隊，即屬於垂直的功能開發團隊，又屬於橫向的支援團隊。他們是scrum of scrums的重要元素。

scrum中要求團隊是跨職能的，所以這樣的安排對於三支功能開發團隊來說，是非常好的。但產品分析團隊和測試團隊又該做何解釋呢？它們可不是scrum中所說的跨職能團隊呀。書上說之所以會有這兩支團隊的存在，是因為在產品分析和測試方面，不僅需要深入開發細節的人，也需要站在全域性把握進度和方向的人。

scrum of scrums的每日站立會議會開三輪，首先是3支垂直功能團隊們開自己的站立會議——包括屬於這支團隊的產品分析人員和測試人員。接著是2支橫向團隊分別開會，由交叉團隊的成員，分別彙報各個功能開發團隊的當前進度和瓶頸，橫向團隊據此瞭解了全域性的進度，進行相應的調整和計劃。最後是各個團隊的負責人和專案的總負責人碰頭。

這三輪會議的時間是序列的，每輪會議的時間都嚴格控制在15分鐘以內。也就是說，每天早上都會開45分鐘的會，分三次開完。有些人只會出席一個會議，有些人會出席兩到三個會議。其中第一輪和第兩輪會議，分別有三支和兩支團隊同時進行，這些團隊都會集中在看板前，相距不過幾米，如果有問題需要跨團隊溝通，走兩步即可。

《硝》中每週一次的全體站立會議，從管理上更加扁平，全員參與，但這個真的感覺不到“每日站立會議”的精神了。《精》中每天早上三次早立會議，不要求全員參加，從管理上來說，讓組織架構更深了，多少有點官僚的影子進來了，但至少更能感受到“每日站立會議”的精神。

我知道每日站立會議對於scrum的重要性，但從沒想過scrum of scrums時的壯觀景象，呵呵。

2）測試團隊如何融入scrum。

關注scrum的人都會問到這個問題，理論上如果一切都那麼理想的話，scrum團隊編寫出來的程式碼應該是質量非常高的，團隊成員是跨職能的，自己能做測試工作，每個輪次結束時程式碼都是可馬上釋出的。但——現實是，專業的QA這一環肯定是必不可少的，專業的測試人員具備一些工程師沒有的技能，工程師寫單元測試的確可以幫助提高一下程式碼質量，降低bug數，但專業的QA是不可替代的。

肯施瓦伯沒有講如何讓QA融入進來，《硝》倒是有比較詳細的講解。《硝》建議：

<1> 提高程式碼質量，儘量少產生點bug

<2> 每個輪次少接受一點任務，保證這個輪次完成的功能質量都很高，可釋出。不搶功能，重質量，不搶速度。

<3> 把測試人員放到專案組中，讓他在日常的工作中就開始檢驗其他成員的程式碼，只有他檢驗通過的，才能放到“完成”一欄去，如果測試工程師沒有事情做了，就讓他做一些輔助的工作，比如組織文件，編寫釋出、打包之類的指令碼，拆分sprint backlog。

<4> 除了專案組中包含測試人員，在專案開發完成後，還是需要再由測試組進行一輪測試。

<5> 在每個輪次開始時做計劃會議時，都預留足夠的時間用於修復上個輪次結束時遺留的bug。理想情況下，scrum的情況是這樣的：

但實際情況，在sprint2的時候，會受到測試團隊反饋的關於sprint1的bug困擾。

在“開發新功能”還是“修復bug”這個問題上，採用“可以開始構建新東西，但是要給‘將舊功能產品化’分配高優先順序”的策略。

出於這個現實情況的考慮，scrum所推崇的“每個scrum週期結束後，程式碼都可直接釋出”，其實是很難做到的，應該說不可能做到。在這一點上，無需過多糾結。

《精》在講測試這一塊時，有類似的建議，希望測試團隊能定期進行測試，不要等到最後階段，等開發團隊程式碼全提測了再進行測試。從第一張圖上，三支功能開發團隊的隊伍中，都含有測試人員，就能看出這點。

這種方式會招來測試人員的反感，認為工作量太大，而且程式碼會反覆修改，並不穩定，測試工作不好做。

《精》比較了一下兩種測試方式的時間成本：

白色的部分表示的是測試用去的時間，黑色的部分表示的是修復bug用去的時間。

由這張圖可以看出，使用傳統的測試方法，測試的時間是比較短，但用於修復bug的時間卻會非常地長，因為bug越晚被發現，修復的成本就越高。而後者雖然測試時間變長了，但在修復bug上的用時卻會明顯變短。

這裡談一下我個人的看法：我雖然認同測試進入專案組，並儘早開始測試，但這事其實很難執行，因為在絕大多數公司裡，測試人員都是歸屬在一個橫向支援團隊中，而團隊和專案組之間是合作的關係，追求“資源池”的感覺，支援完成了某個專案，就直接回到池中等著下一個任務的到來。所以測試一直跟進某個專案，特別是還歸屬於專案組中去，很難！主要是行政方面會有很大的阻力。

3）迭代週期 VS 前十的任務。

在scrum中，有一個特別重要的概念就是sprint週期。整個scrum就是圍繞迭代週期來進行的，每個週期之始進行本輪次的計劃會議，週期結束時進行驗收會議和回顧會議，在週期之內，進行每日站立回憶。開發團隊會有非常強的節奏感，重視在一個很短的週期內完成一些功能，並且在週期結束時，程式碼可達到釋出狀態。

《精》在很大程度上和scrum有相似的地方，比如也會開會挑選優先順序高的使用者故事，壓入待開發佇列棧，但《精》並沒有sprint週期的概念，不要求開發團隊估算下個輪次（也就是未來幾周內）要開發完成哪幾個任務，不要求開發團隊估算故事點。《精》認為估算故事點非常耗時，但意義卻並不大。在計劃會議上，唯一要做的事，就是排出接下來要做的十個任務，而這些任務什麼時候完成，並沒有時間上的任何估算和承諾。

這一點和scrum有非常大的區別。而事實上，我更喜歡《精》的方式。scrum的計劃會議，雖然一再對工程師強調在未來的這個週期內，大家只用做一個“估算”，這個不是“承諾”，完不成也沒關係，希望藉此來讓工程師放鬆，更愉快地進行工作。但在實際執行的時候，“估算”很難不被“承諾”關聯上，工程師們總是會對“估算”有壓力。而且如果估算過於樂觀，在回顧會議上面對沒有完成的估算，沮喪感還是很強烈的。

《精》只重視優先順序，並不重視“一定週期內完成多少功能”。這可以讓工程師毫無壓力，其實更符合敏捷的“人性化”精神。

4）估算撲克牌。

《硝》和《精》中都提到了估算撲克牌。而且也都是在計劃會議中使用的，所以功能大致相同。但其實兩者又有區別。《硝》中講的是scrum實踐，scrum的計劃會議需要工程師們估算出sprint backlog的耗時，根據團隊生產力和各個sprint backlog的耗時，排出本輪次可完成的任務。《硝》中的估算撲克牌就是用於團隊估算每個sprint backlog需要的故事點的，它的單位是數字。

而《精》的計劃會議是用於確定接下來最重要的十個開發任務。有scrum中，產品backlog拆分成sprint backlog時，sprint backlog的粒度有要求，不能太大，如果大了，就需要進一步拆分。有《精》中也一樣，產品負責人列出的開發任務，需要被開發團隊估算是不是太大了——不用像scrum那樣，進行過於細緻的拆分和時間估算，《精》並不提倡時間估算。《精》認為開發任務的大小和開發實際使用的時間沒有直接關係，有可能一個小功能因為各種原因，前後花了非常多的時間，而一個大功能卻可能很快就開發完成了。《精》只是需要在排開發任務時，保證這十個開發任務的粒度不要太大就行。

《精》提供的估算撲克牌，只有這麼幾張：

其中問號和咖啡的意思和scrum中一樣，但沒有了代表故事點的牌，只有表示“小”“中”“大”的三張牌。產品負責人問開發團隊某個開發任務的大小時，開發團隊抽出自己的牌壓在桌上，當大家一起亮牌時，如果意見不一致，那麼進一步討論，如果結論是開發任務粒度太大的話，那麼產品負責人進一步將開發任務拆小。

撲克牌玩法還是一樣，但意義已經完全不同了。

5）任務牆 VS 看板。

無論是任務牆還是看板，都不鼓勵使用電子系統，而是使用實體牆，這一點上兩者是一樣的。事實上，兩者非常相似——開發團隊的每日站立會議都是在這面牆面前進行的，而且牆上也都會劃分“待開發”“開發中”“待測試”“測試中”“完成”等欄目，也都會配上表示進度的圖表。

只是看板比任務牆更進一步：

<1>上面會陳列更多的任務，比如總體產品backlog居然也在這面牆上（根據專案需要，可以按自己意願自由擴充套件這面牆的欄目），所以看板會比scrum的任務牆更長，更大;

先看個任務牆：

這是我以前在某個專案中佈置的一個任務牆：

再看個看板：

怎麼說呢？任務牆是看板的一個子集。看板將任務牆這種形式帶到了一個更高的高度，一種極致。

<2> 看板將待開發功能進一步做了個整理，清晰地劃分出“下十個新功能”“下五個技術故事”“下五個bug”。“新功能”是可以看到的新的功能，“技術故事”是遷移資料庫，編寫自動構建指令碼，重構程式碼等使用者看不到，但技術上確定佔開發量的工作，“bug”是遺留的待解決bug。

6）燃盡圖 VS 開發速率圖

scrum用一條左上至右下的斜線來表示開發進度，用每輪次多少個故事點來表示團隊的開發速度。

而《精》用一條左上至右上的斜線來表示開發進度，用每週或每月多少個開發任務來表示團隊的開發速度。

7） 釋出計劃。

《精》和scrum一樣，只保證當前正在最重要的功能，開發的程式碼質量高，可持續將功能整合起來，產品可持續迭代，小步快跑地釋出新功能。只保證當前在做最正確的事，但不保證整體的開發時間。所以《精》也需要在一開始就搞定領導，如果領導堅持“x月x日前，xxx功能要全部開發完成”，那就沒法玩了。這應該是敏捷所有方法論都會遇到的問題。

8）sprint週期 VS 限額。

scrum的核心是sprint，確定一個較短的sprint週期，然後通過計劃會議將優先順序最高的需求壓到最近的sprint週期中，然後每日站立會議，最後驗收和回顧會議。借sprint週期來做專案的照明彈，保持團隊的成就感和活力，同時保證新增的功能可持續整合至生產環境。

《精》沒有sprint週期的概念，不是通過時間，而是通過限額來“降低開發團隊在可視範圍內的待開發任務量”的，比如看板上只能壓入“最新十個新功能”“最新五個技術問題”“最新五個bug”。這些“最新”都是優先順序最高的，超過這個限額的，就不往看板上放。這樣，可以保證開發團隊不會承受過大壓力。

因為scrum是有周期的，而且每個週期內都有設計、開發、測試、驗收，所以某種意義上來說，scrum的每個sprint輪次都是一次小型的瀑布，很完整。而精益沒有這種感覺，它更像一種源源不斷的“流”，沒有起點，也沒有終點，任何時候看板上都填滿了接下來需要開發的限額任務，但高質量的產出卻源源不斷。

《精》第17章的一組圖很好地反映了看板的精髓。圖不好找，建議大家自己買來看看。很棒的一本書。