《精益開(kāi)發(fā)實(shí)戰(zhàn)》這本書(shū)的作者就是《硝煙中的Scrum和XP》的作者Henrik！scrum、xp、精益看板，這下齊活了。對(duì)比上一本講Scrum的書(shū)，這本書(shū)中有很多地方值得注意：
1）團(tuán)隊(duì)規(guī)模 和 Scrum of Scrums
無(wú)論是Scrum之父肯施瓦伯的書(shū)《應(yīng)用Scrum進(jìn)行軟件項(xiàng)目管理》，還是《硝》，都重點(diǎn)講的是Scrum本身，而Scrum團(tuán)隊(duì)的規(guī)模都不大，按Henrik在《硝》中的說(shuō)法，團(tuán)隊(duì)規(guī)模應(yīng)該在5~9人之間，最好是7個(gè)人。如果人數(shù)特別多，就應(yīng)該使用Scrum of Scrums——將團(tuán)隊(duì)拆成幾個(gè)更小的團(tuán)隊(duì)，每個(gè)小團(tuán)隊(duì)各自使用Scrum，然后各個(gè)團(tuán)隊(duì)再派負(fù)責(zé)人參加團(tuán)隊(duì)之間的Scrum。兩本書(shū)關(guān)于Scrum of Scrums講的都并不多，《硝》講了一些，但它其實(shí)變化很大——多團(tuán)隊(duì)之間并不是每日站立會(huì)議，而是每周一次，全員參與，15分鐘以內(nèi)，溝通的方式不像是“交流”而更像是“匯報(bào)”。
《精》中講的案例則正好填補(bǔ)了這個(gè)空白，講的是一個(gè)由60人組成的團(tuán)隊(duì)，這個(gè)大團(tuán)隊(duì)拆成了5支小團(tuán)隊(duì)，共同配合。本書(shū)很細(xì)致地講解了怎么進(jìn)行Scrum of Scrums——當(dāng)然，它管這個(gè)叫精益，并不是典型的Scrum。
5支團(tuán)隊(duì)分別是：1支產(chǎn)品分析團(tuán)隊(duì)，1支測(cè)試團(tuán)隊(duì)和3支功能開(kāi)發(fā)團(tuán)隊(duì)。
其中產(chǎn)品分析團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)都會(huì)派人進(jìn)入功能開(kāi)發(fā)團(tuán)隊(duì)，這些人是交叉團(tuán)隊(duì)，即屬于垂直的功能開(kāi)發(fā)團(tuán)隊(duì)，又屬于橫向的支持團(tuán)隊(duì)。他們是Scrum of Scrums的重要元素。
Scrum中要求團(tuán)隊(duì)是跨職能的，所以這樣的安排對(duì)于三支功能開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)，是非常好的。但產(chǎn)品分析團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)又該做何解釋呢？它們可不是Scrum中所說(shuō)的跨職能團(tuán)隊(duì)呀。書(shū)上說(shuō)之所以會(huì)有這兩支團(tuán)隊(duì)的存在，是因?yàn)樵诋a(chǎn)品分析和測(cè)試方面，不僅需要深入開(kāi)發(fā)細(xì)節(jié)的人，也需要站在全局把握進(jìn)度和方向的人。
Scrum of Scrums的每日站立會(huì)議會(huì)開(kāi)三輪，首先是3支垂直功能團(tuán)隊(duì)們開(kāi)自己的站立會(huì)議——包括屬于這支團(tuán)隊(duì)的產(chǎn)品分析人員和測(cè)試人員。接著是2支橫向團(tuán)隊(duì)分別開(kāi)會(huì)，由交叉團(tuán)隊(duì)的成員，分別匯報(bào)各個(gè)功能開(kāi)發(fā)團(tuán)隊(duì)的當(dāng)前進(jìn)度和瓶頸，橫向團(tuán)隊(duì)據(jù)此了解了全局的進(jìn)度，進(jìn)行相應(yīng)的調(diào)整和計(jì)劃。最后是各個(gè)團(tuán)隊(duì)的負(fù)責(zé)人和項(xiàng)目的總負(fù)責(zé)人碰頭。
這三輪會(huì)議的時(shí)間是串行的，每輪會(huì)議的時(shí)間都嚴(yán)格控制在15分鐘以內(nèi)。也就是說(shuō)，每天早上都會(huì)開(kāi)45分鐘的會(huì)，分三次開(kāi)完。有些人只會(huì)出席一個(gè)會(huì)議，有些人會(huì)出席兩到三個(gè)會(huì)議。其中第一輪和第兩輪會(huì)議，分別有三支和兩支團(tuán)隊(duì)同時(shí)進(jìn)行，這些團(tuán)隊(duì)都會(huì)集中在看板前，相距不過(guò)幾米，如果有問(wèn)題需要跨團(tuán)隊(duì)溝通，走兩步即可。
《硝》中每周一次的全體站立會(huì)議，從管理上更加扁平，全員參與，但這個(gè)真的感覺(jué)不到“每日站立會(huì)議”的精神了?！毒分忻刻煸缟先卧缌?huì)議，不要求全員參加，從管理上來(lái)說(shuō)，讓組織架構(gòu)更深了，多少有點(diǎn)官僚的影子進(jìn)來(lái)了，但至少更能感受到“每日站立會(huì)議”的精神。
我知道每日站立會(huì)議對(duì)于Scrum的重要性，但從沒(méi)想過(guò)Scrum of Scrums時(shí)的壯觀景象，呵呵。
2）測(cè)試團(tuán)隊(duì)如何融入Scrum
關(guān)注Scrum的人都會(huì)問(wèn)到這個(gè)問(wèn)題，理論上如果一切都那么理想的話，Scrum團(tuán)隊(duì)編寫(xiě)出來(lái)的代碼應(yīng)該是質(zhì)量非常高的，團(tuán)隊(duì)成員是跨職能的，自己能做測(cè)試工作，每個(gè)輪次結(jié)束時(shí)代碼都是可馬上發(fā)布的。但——現(xiàn)實(shí)是，專業(yè)的QA這一環(huán)肯定是必不可少的，專業(yè)的測(cè)試人員具備一些工程師沒(méi)有的技能，工程師寫(xiě)單元測(cè)試的確可以幫助提高一下代碼質(zhì)量，降低bug數(shù)量，但專業(yè)的QA是不可替代的。
肯施瓦伯沒(méi)有講如何讓QA融入進(jìn)來(lái)，《硝》倒是有比較詳細(xì)的講解。《硝》中的建議如下。
提高代碼質(zhì)量，盡量少產(chǎn)生點(diǎn)bug。
每個(gè)輪次少接受一點(diǎn)任務(wù)，保證這個(gè)輪次完成的功能質(zhì)量都很高，可發(fā)布，不搶功能，重質(zhì)量，不搶速度。
把測(cè)試人員放到項(xiàng)目組中，讓他在日常的工作中就開(kāi)始檢驗(yàn)其他成員的代碼，只有他檢驗(yàn)通過(guò)的，才能放到“完成”一欄去，如果測(cè)試工程師沒(méi)有事情做了，就讓他做一些輔助的工作，比如組織文檔，編寫(xiě)發(fā)布、打包之類的腳本，拆分sprint backlog。
除了項(xiàng)目組中包含測(cè)試人員，在項(xiàng)目開(kāi)發(fā)完成后，還是需要再由測(cè)試組進(jìn)行一輪測(cè)試。
在每個(gè)輪次開(kāi)始時(shí)做計(jì)劃會(huì)議時(shí)，都預(yù)留足夠的時(shí)間用于修復(fù)上個(gè)輪次結(jié)束時(shí)遺留的bug，理想情況下，Scrum的情況是這樣的：
但實(shí)際情況，在sprint2的時(shí)候，會(huì)受到測(cè)試團(tuán)隊(duì)反饋的關(guān)于sprint1的bug困擾。
在“開(kāi)發(fā)新功能”還是“修復(fù)bug”這個(gè)問(wèn)題上，采用“可以開(kāi)始構(gòu)建新東西，但是要給‘將舊功能產(chǎn)品化’分配高優(yōu)先級(jí)”的策略。
出于這個(gè)現(xiàn)實(shí)情況的考慮，Scrum所推崇的“每個(gè)Scrum周期結(jié)束后，代碼都可直接發(fā)布”，其實(shí)是很難做到的，應(yīng)該說(shuō)不可能做到。在這一點(diǎn)上，無(wú)需過(guò)多糾結(jié)。
《精》在講測(cè)試這一塊時(shí)，有類似的建議，希望測(cè)試團(tuán)隊(duì)能定期進(jìn)行測(cè)試，不要等到最后階段，等開(kāi)發(fā)團(tuán)隊(duì)代碼全提測(cè)了再進(jìn)行測(cè)試。從第一張圖上，三支功能開(kāi)發(fā)團(tuán)隊(duì)的隊(duì)伍中，都含有測(cè)試人員，就能看出這點(diǎn)。
這種方式會(huì)招來(lái)測(cè)試人員的反感，認(rèn)為工作量太大，而且代碼會(huì)反復(fù)修改，并不穩(wěn)定，測(cè)試工作不好做。
《精》比較了一下兩種測(cè)試方式的時(shí)間成本：
白色的部分表示的是測(cè)試用去的時(shí)間，黑色的部分表示的是修復(fù)bug用去的時(shí)間。
由這張圖可以看出，使用傳統(tǒng)的測(cè)試方法，測(cè)試的時(shí)間是比較短，但用于修復(fù)bug的時(shí)間卻會(huì)非常地長(zhǎng)，因?yàn)閎ug越晚被發(fā)現(xiàn)，修復(fù)的成本就越高。而后者雖然測(cè)試時(shí)間變長(zhǎng)了，但在修復(fù)bug上的用時(shí)卻會(huì)明顯變短。
這里談一下我個(gè)人的看法：我雖然認(rèn)同測(cè)試進(jìn)入項(xiàng)目組，并盡早開(kāi)始測(cè)試，但這事其實(shí)很難執(zhí)行，因?yàn)樵诮^大多數(shù)公司里，測(cè)試人員都是歸屬在一個(gè)橫向支持團(tuán)隊(duì)中，而團(tuán)隊(duì)和項(xiàng)目組之間是合作的關(guān)系，追求“資源池”的感覺(jué)，支持完成了某個(gè)項(xiàng)目，就直接回到池中等著下一個(gè)任務(wù)的到來(lái)。所以測(cè)試一直跟進(jìn)某個(gè)項(xiàng)目，特別是還歸屬于項(xiàng)目組中去，很難！主要是行政方面會(huì)有很大的阻力。
3）迭代周期 VS 前十的任務(wù)
在Scrum中，有一個(gè)特別重要的概念就是Sprint周期。整個(gè)Scrum就是圍繞迭代周期來(lái)進(jìn)行的，每個(gè)周期之始進(jìn)行本輪次的計(jì)劃會(huì)議，周期結(jié)束時(shí)進(jìn)行驗(yàn)收會(huì)議和回顧會(huì)議，在周期之內(nèi)，進(jìn)行每日站立會(huì)議。開(kāi)發(fā)團(tuán)隊(duì)會(huì)有非常強(qiáng)的節(jié)奏感，重視在一個(gè)很短的周期內(nèi)完成一些功能，并且在周期結(jié)束時(shí)，代碼可達(dá)到發(fā)布狀態(tài)。
《精》在很大程度上和Scrum有相似的地方，比如也會(huì)開(kāi)會(huì)挑選優(yōu)先級(jí)高的用戶故事，壓入待開(kāi)發(fā)隊(duì)列棧，但《精》并沒(méi)有Sprint周期的概念，不要求開(kāi)發(fā)團(tuán)隊(duì)估算下個(gè)輪次（也就是未來(lái)幾周內(nèi)）要開(kāi)發(fā)完成哪幾個(gè)任務(wù)，不要求開(kāi)發(fā)團(tuán)隊(duì)估算故事點(diǎn)?！毒氛J(rèn)為估算故事點(diǎn)非常耗時(shí)，但意義卻并不大。在計(jì)劃會(huì)議上，唯一要做的事，就是排出接下來(lái)要做的十個(gè)任務(wù)，而這些任務(wù)什么時(shí)候完成，并沒(méi)有時(shí)間上的任何估算和承諾。
這一點(diǎn)和Scrum有非常大的區(qū)別。而事實(shí)上，我更喜歡《精》的方式。Scrum的計(jì)劃會(huì)議，雖然一再對(duì)工程師強(qiáng)調(diào)在未來(lái)的這個(gè)周期內(nèi)，大家只用做一個(gè)“估算”，這個(gè)不是“承諾”，完不成也沒(méi)關(guān)系，希望借此來(lái)讓工程師放松，更愉快地進(jìn)行工作。但在實(shí)際執(zhí)行的時(shí)候，“估算”很難不被“承諾”關(guān)聯(lián)上，工程師們總是會(huì)對(duì)“估算”有壓力。而且如果估算過(guò)于樂(lè)觀，在回顧會(huì)議上面對(duì)沒(méi)有完成的估算，沮喪感還是很強(qiáng)烈的。
《精》只重視優(yōu)先級(jí)，并不重視“一定周期內(nèi)完成多少功能”。這可以讓工程師毫無(wú)壓力，其實(shí)更符合敏捷的“人性化”精神。
4）估算撲克牌
《硝》和《精》中都提到了估算撲克牌。而且也都是在計(jì)劃會(huì)議中使用的，所以功能大致相同。但其實(shí)兩者又有區(qū)別?！断酢分兄v的是Scrum實(shí)踐，Scrum的計(jì)劃會(huì)議需要工程師們估算出Sprint backlog的耗時(shí)，根據(jù)團(tuán)隊(duì)生產(chǎn)力和各個(gè)Sprint backlog的耗時(shí)，排出本輪次可完成的任務(wù)?！断酢分械墓浪銚淇伺凭褪怯糜趫F(tuán)隊(duì)估算每個(gè)Sprint backlog需要的故事點(diǎn)的，它的單位是數(shù)字。
而《精》的計(jì)劃會(huì)議是用于確定接下來(lái)最重要的十個(gè)開(kāi)發(fā)任務(wù)。有Scrum中，產(chǎn)品backlog拆分成Sprint backlog時(shí)，Sprint backlog的粒度有要求，不能太大，如果大了，就需要進(jìn)一步拆分。有《精》中也一樣，產(chǎn)品負(fù)責(zé)人列出的開(kāi)發(fā)任務(wù)，需要被開(kāi)發(fā)團(tuán)隊(duì)估算是不是太大了——不用像scrum那樣，進(jìn)行過(guò)于細(xì)致地拆分和時(shí)間估算，《精》并不提倡時(shí)間估算。《精》認(rèn)為開(kāi)發(fā)任務(wù)的大小和開(kāi)發(fā)實(shí)際使用的時(shí)間沒(méi)有直接關(guān)系，有可能一個(gè)小功能因?yàn)楦鞣N原因，前后花了非常多的時(shí)間，而一個(gè)大功能卻可能很快就開(kāi)發(fā)完成了。《精》只是需要在排開(kāi)發(fā)任務(wù)時(shí)，保證這十個(gè)開(kāi)發(fā)任務(wù)的粒度不要太大就行。
《精》提供的估算撲克牌，只有這么幾張。
其中問(wèn)號(hào)和咖啡的意思和Scrum中一樣，但沒(méi)有了代表故事點(diǎn)的牌，只有表示“小”“中”“大”的三張牌。產(chǎn)品負(fù)責(zé)人問(wèn)開(kāi)發(fā)團(tuán)隊(duì)某個(gè)開(kāi)發(fā)任務(wù)的大小時(shí)，開(kāi)發(fā)團(tuán)隊(duì)抽出自己的牌壓在桌上，當(dāng)大家一起亮牌時(shí)，如果意見(jiàn)不一致，那么進(jìn)一步討論，如果結(jié)論是開(kāi)發(fā)任務(wù)粒度太大的話，那么產(chǎn)品負(fù)責(zé)人進(jìn)一步將開(kāi)發(fā)任務(wù)拆小。
撲克牌玩法還是一樣，但意義已經(jīng)完全不同了。
5）任務(wù)墻 VS 看板
無(wú)論是任務(wù)墻還是看板，都不鼓勵(lì)使用電子系統(tǒng)，而是使用實(shí)體墻，這一點(diǎn)上兩者是一樣的。事實(shí)上，兩者非常相似——開(kāi)發(fā)團(tuán)隊(duì)的每日站立會(huì)議都是在這面墻面前進(jìn)行的，而且墻上也都會(huì)劃分“待開(kāi)發(fā)”、“開(kāi)發(fā)中”、“待測(cè)試”、“測(cè)試中”、“完成”等欄目，也都會(huì)配上表示進(jìn)度的圖表。
只是看板比任務(wù)墻更進(jìn)一步。
上面會(huì)陳列更多的任務(wù)，比如總體產(chǎn)品backlog居然也在這面墻上（根據(jù)項(xiàng)目需要，可以按自己意愿自由擴(kuò)展這面墻的欄目），所以看板會(huì)比scrum的任務(wù)墻更長(zhǎng)，更大。先看個(gè)任務(wù)墻：
這是我以前在某個(gè)項(xiàng)目中布置的一個(gè)任務(wù)墻：
再看個(gè)看板：
怎么說(shuō)呢？任務(wù)墻是看板的一個(gè)子集?？窗鍖⑷蝿?wù)墻這種形式帶到了一個(gè)更高的高度，一種極致。
看板將待開(kāi)發(fā)功能進(jìn)一步做了個(gè)整理，清晰地劃分出“下十個(gè)新功能”、“下五個(gè)技術(shù)故事”、“下五個(gè)bug”?！靶鹿δ堋笔强梢钥吹降男碌墓δ?，“技術(shù)故事”是遷移數(shù)據(jù)庫(kù)，編寫(xiě)自動(dòng)構(gòu)建腳本，重構(gòu)代碼等用戶看不到，但技術(shù)上確定占開(kāi)發(fā)量的工作，“bug”是遺留的待解決bug。
6）燃盡圖 VS 開(kāi)發(fā)速率圖
Scrum用一條左上至右下的斜線來(lái)表示開(kāi)發(fā)進(jìn)度，用每輪次多少個(gè)故事點(diǎn)來(lái)表示團(tuán)隊(duì)的開(kāi)發(fā)速度。
而《精》用一條左上至右上的斜線來(lái)表示開(kāi)發(fā)進(jìn)度，用每周或每月多少個(gè)開(kāi)發(fā)任務(wù)來(lái)表示團(tuán)隊(duì)的開(kāi)發(fā)速度。
7） 發(fā)布計(jì)劃
《精》和Scrum一樣，只保證當(dāng)前正在進(jìn)行最重要的功能，開(kāi)發(fā)的代碼質(zhì)量高，可持續(xù)將功能集成起來(lái)，產(chǎn)品可持續(xù)迭代，小步快跑地發(fā)布新功能。只保證當(dāng)前在做最正確的事，但不保證整體的開(kāi)發(fā)時(shí)間。所以《精》也需要在一開(kāi)始就搞定領(lǐng)導(dǎo)，如果領(lǐng)導(dǎo)堅(jiān)持“x月x日前，xxx功能要全部開(kāi)發(fā)完成”，那就沒(méi)法玩了。這應(yīng)該是敏捷所有方法論都會(huì)遇到的問(wèn)題。
8）Sprint周期 VS 限額
Scrum的核心是Sprint，確定一個(gè)較短的Sprint周期，然后通過(guò)計(jì)劃會(huì)議將優(yōu)先級(jí)最高的需求壓到最近的Sprint周期中，然后每日站立會(huì)議，最后驗(yàn)收和回顧會(huì)議。借Sprint周期來(lái)做項(xiàng)目的照明彈，保持團(tuán)隊(duì)的成就感和活力，同時(shí)保證新增的功能可持續(xù)集成至生產(chǎn)環(huán)境。
《精》沒(méi)有sprint周期的概念，不是通過(guò)時(shí)間，而是通過(guò)限額來(lái)“降低開(kāi)發(fā)團(tuán)隊(duì)在可視范圍內(nèi)的待開(kāi)發(fā)任務(wù)量”的，比如看板上只能壓入“最新十個(gè)新功能”、“最新五個(gè)技術(shù)問(wèn)題”、“最新五個(gè)bug”。這些“最新”都是優(yōu)先級(jí)最高的，超過(guò)這個(gè)限額的，就不往看板上放。這樣，可以保證開(kāi)發(fā)團(tuán)隊(duì)不會(huì)承受過(guò)大壓力。
因?yàn)镾crum是有周期的，而且每個(gè)周期內(nèi)都有設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、驗(yàn)收，所以某種意義上來(lái)說(shuō)，Scrum的每個(gè)Sprint輪次都是一次小型的瀑布，很完整。而精益沒(méi)有這種感覺(jué)，它更像一種源源不斷的“流”，沒(méi)有起點(diǎn)，也沒(méi)有終點(diǎn)，任何時(shí)候看板上都填滿了接下來(lái)需要開(kāi)發(fā)的限額任務(wù)，但高質(zhì)量的產(chǎn)出卻源源不斷。
《精》第17章的一組圖很好地反映了看板的精髓。圖不好找，建議大家自己買(mǎi)來(lái)看看。很棒的一本書(shū)。
