喜歡敏捷的很多想法，喜歡它務(wù)實(shí)的態(tài)度。我說“敏捷不能當(dāng)飯吃”，當(dāng)然不是說敏捷無用，相反，我倒是挺推崇敏捷的。之前有兩篇文字都涉及到一些對(duì)敏捷的看法。一篇是 與神對(duì)話，另一篇是 對(duì)敏捷的一些想法。只是看到很多人好像敏捷是他爺爺寫的一樣，龜孫子似地迷信和追捧敏捷，把工作一條一條跟書上描述的對(duì)照，一旦工作中實(shí)際操作跟書上有不一致，口誅筆伐，吐沫拳頭無影腿就一齊上來了，那就太過了。敏捷跟太極拳一樣，是一種思想精髓，它的一招一式體現(xiàn)在實(shí)際工作中靈活運(yùn)用敏捷原則，敏捷并無特定套路。Scrum等流程是敏捷的一種成功案例，這個(gè)案例在特定環(huán)境下工作得非常好，但那只是特定環(huán)境而已。敏捷大師們自己也總提醒，很多項(xiàng)目采用敏捷開發(fā)，仍然一塌糊涂，是因?yàn)閼?yīng)用敏捷并不簡(jiǎn)單。
Kent Beck是敏捷的發(fā)起者之一，很多敏捷的發(fā)起者后來都寫了關(guān)于敏捷的書，但Kent Beck的書是最有影響力的，它的Extreme programming explained – embrace change可以在這篇博客中找到。這本書主要闡述敏捷的一系列理念，對(duì)實(shí)踐描述的并不具體。scrum之類講敏捷流程的書，對(duì)實(shí)踐操作的環(huán)節(jié)就會(huì)講的很具體。先了解并接受敏捷的理念，再去看敏捷流程的話，比較容易理解流程背后的用意是什么，只有深刻理解了敏捷精神，才能比較好的實(shí)踐敏捷。而現(xiàn)實(shí)情況很多時(shí)候不是這樣，直接學(xué)習(xí)流程總是比較省事兒，于是scrum就被當(dāng)成圣經(jīng)直接拿來就用了，人家mc hotdog早就說過，“照單全收的盲從，就像在吃屎”。我相信通常情況下，scrum的實(shí)踐在一個(gè)項(xiàng)目組，只有一小部分能用得上，當(dāng)然，這已經(jīng)是件很偉大的事情了。在一些常見的工作環(huán)境中，有些scrum的想法并不適用。
一個(gè)方面是，scrum強(qiáng)調(diào)“全功能團(tuán)隊(duì)”，每個(gè)人了解產(chǎn)品的每一個(gè)feature；團(tuán)隊(duì)人數(shù)在敏捷中是有限制的。但如果一個(gè)負(fù)責(zé)某個(gè)產(chǎn)品的團(tuán)隊(duì)就是有12，3個(gè)人，那么怎么辦？ 再拆成兩個(gè)敏捷團(tuán)隊(duì)以適應(yīng)敏捷對(duì)人數(shù)的要求？垂直劃分feature提供了細(xì)化團(tuán)隊(duì)的機(jī)會(huì)，但產(chǎn)品不總能清晰地一刀切成兩半，尤其還要考慮各個(gè)程序員有不同的專長(zhǎng)，甚至根本用的不是同一種編程語言，如果團(tuán)隊(duì)只有一個(gè)c程序員，一個(gè)js程序員，一個(gè)pl/sql程序員，其他做java，那么切分項(xiàng)目組的方式是跟c有關(guān)的一組，跟js有關(guān)的另一組？底層架構(gòu)和公共模塊都不容易豎切。如果產(chǎn)品比較大并且不易細(xì)分，大家都了解每個(gè)feature是很難做到的。如果產(chǎn)品使用的技術(shù)比較繁雜，pl/sql, js, java, c樣樣都用，全功能團(tuán)隊(duì)怎么實(shí)現(xiàn)？js的程序員跟c程序員也講不到一塊兒去啊。我可以理解scrum的想法，也認(rèn)同它的道理，但是在實(shí)際工作中，如果確實(shí)人數(shù)對(duì)不上敏捷的要求，或者程序員的技術(shù)特長(zhǎng)分散在不同層面，這很難照搬scrum的實(shí)踐。人多開會(huì)費(fèi)時(shí)間，效果又不好，雞同鴨講，各說各的。寫c的人才不關(guān)心js有什么技術(shù)瓶頸呢。
還有，scrum想了個(gè)招兒，用打撲克的方式溝通需求和幫助定schedule。這是建立在全功能團(tuán)隊(duì)的基礎(chǔ)上的，上面已經(jīng)論述過了，如果產(chǎn)品比較大，程序員沒法兼顧所有story，那成本太大了，打撲克也只能流于形式，尤其術(shù)業(yè)有專攻，唯一的c程序員的工作只有他自己估計(jì)才有意義。更實(shí)際的問題是，當(dāng)你知道story具體需求的時(shí)候，還不足以估計(jì)出時(shí)間，程序員必須知道“怎么做”才能估出來比較靠譜的時(shí)間。很多時(shí)候需要做一些research的工作以及一點(diǎn)兒prototype才好估時(shí)間，在這樣的情況下，你非逼我出張牌，我只能出“問號(hào)”。 有時(shí)候，雖然我不需要做prototype, 但我確實(shí)也不能在5分鐘之內(nèi)理清思路, 知道用什么approach更合理，那么我怎么辦，告訴大家容我想想，等我一會(huì)兒？技術(shù)問題本來也不應(yīng)該規(guī)定在5分鐘之內(nèi)出個(gè)計(jì)劃，非逼我出計(jì)劃倒也沒問題，但是隨后我就得重做計(jì)劃。還有一個(gè)問題，大家一起打牌，A知道這工作十有八九落在B頭上，A可能出于好心多估時(shí)間，B可能為了面子少估時(shí)間，這些人為因素如何排除掉？
敏捷強(qiáng)調(diào)單元測(cè)試，這肯定是沒錯(cuò)的。問題是，各個(gè)團(tuán)隊(duì)之間容易開始攀比覆蓋率，其實(shí)程序員心里都明白，覆蓋率的欺騙性很強(qiáng)，單元測(cè)試的有效性更重要。如果單元測(cè)試又沒貢獻(xiàn)于驅(qū)動(dòng)開發(fā)，也沒貢獻(xiàn)于質(zhì)量保證（簡(jiǎn)單的api，諸如getter/setter之類的api就是這樣，不用測(cè)試驅(qū)動(dòng)直接就知道怎么寫了，寫了手動(dòng)測(cè)試一遍就知道寫的沒錯(cuò)，code以后也不可能改），那么就沒必要寫這種單元測(cè)試，寫這種單元測(cè)試的唯一好處是，成本低，比較容易貢獻(xiàn)覆蓋率。麻煩在于，太多弱智這么說，咱們敏捷了，單元測(cè)試覆蓋率應(yīng)該向某某弱智team看齊，于是人在江湖，身不由己，開始對(duì)付覆蓋率。好吧，scrum其實(shí)也沒說具體百分比，這不是scrum的錯(cuò)。
我絕對(duì)不想抨擊敏捷或者scrum，我覺得這都是很出色的想法。只是聽了太多“這不是敏捷”這種話，是不是敏捷根本不重要，能優(yōu)化流程，讓工作更有效才重要。我喜歡敏捷的地方在于，敏捷強(qiáng)調(diào)以人為本，尊重程序員的各種訴求。正視design不能一蹴而就的現(xiàn)實(shí)。承認(rèn)長(zhǎng)期計(jì)劃不靠譜。強(qiáng)調(diào)優(yōu)先級(jí)，決定優(yōu)先級(jí)的時(shí)候從性價(jià)比的角度考慮。scrum的很多實(shí)踐也很實(shí)用，比如backlog應(yīng)該包含的內(nèi)容等等不一一羅列。敏捷不是一門玄奧難懂的技術(shù)，不需要花錢找培訓(xùn)機(jī)構(gòu)受教育。敏捷的出發(fā)點(diǎn)就是務(wù)實(shí)，用務(wù)實(shí)的態(tài)度擁抱敏捷就足夠好。套用二八原則，scrum的實(shí)踐在實(shí)際中也許只需要吸收20%，卻能取得80%的效果，剩下那20%要靠基于敏捷精神的創(chuàng)造力。