有人說(shuō)，實(shí)踐敏捷的根本不在于敏捷本身，而在于理解敏捷背后擁抱變化的基因。確實(shí)，使用敏捷，那么你就應(yīng)該知道為何敏捷。如今，國(guó)內(nèi)很多敏捷團(tuán)隊(duì)沒(méi)有真正的了解敏捷的精髓，也說(shuō)明了為什么在使用敏捷的過(guò)程中并沒(méi)有真正的“敏捷”。所以，不但不能真正的解決傳統(tǒng)開發(fā)的一些問(wèn)題，反而新增加了更多的問(wèn)題。因此，51CTO記者采訪了具有17年軟件研發(fā)、管理咨詢經(jīng)驗(yàn)，擅長(zhǎng)在實(shí)際環(huán)境中應(yīng)用敏捷開發(fā)實(shí)踐的專家陳勇老師，為網(wǎng)友們解讀敏捷在開發(fā)實(shí)踐及管理中的一些問(wèn)題。

[[70475]]

陳勇，17年軟件研發(fā)、管理及咨詢經(jīng)驗(yàn)，擅長(zhǎng)在實(shí)際環(huán)境中應(yīng)用敏捷開發(fā)實(shí)踐。具有豐富的工程技術(shù)與項(xiàng)目管理實(shí)踐經(jīng)驗(yàn)，從其程序員、項(xiàng)目經(jīng)理、CMMI/FPA功能點(diǎn)估算/敏捷咨詢師、事業(yè)部總監(jiān)、副總經(jīng)理等各種技術(shù)與管理崗位獲得的一手經(jīng)驗(yàn)，令其可以站在企業(yè)管理者的角度，以更廣的視角來(lái)理解敏捷開發(fā)，并能配合和推動(dòng)非研發(fā)部門協(xié)作推廣敏捷。

工作經(jīng)歷：

• 曾以技術(shù)骨干和項(xiàng)目經(jīng)理等身份，組織和承擔(dān)開發(fā)了國(guó)慶50周年直升機(jī)編隊(duì)指揮系統(tǒng)、空軍一基地GPS數(shù)據(jù)源系統(tǒng)、清華同方CCTV數(shù)字電視條件接收系統(tǒng)、航空材料研究院無(wú)損檢測(cè)系統(tǒng)等項(xiàng)目，并在其中某些項(xiàng)目中實(shí)踐敏捷。
• 曾在清華同方、普天集團(tuán)、亞信科技等企業(yè)擔(dān)任EPG骨干、組長(zhǎng)；曾在斯福泰克、DNV ITGS等機(jī)構(gòu)擔(dān)任CMMI/敏捷咨詢師。
• 曾在中國(guó)系統(tǒng)與軟件改進(jìn)年會(huì) 、中國(guó)軟件技術(shù)大會(huì)、敏捷中國(guó)大會(huì)、MPD等國(guó)際國(guó)內(nèi)會(huì)議從事敏捷演講、翻譯或主持工作。
• 在任泰克賽爾軟件公司中國(guó)部門的咨詢總監(jiān)、ALM事業(yè)部總監(jiān)、副總經(jīng)理期間，主管敏捷研發(fā)管理工具的市場(chǎng)、銷售、支持與咨詢活動(dòng)，在盛大、金山、騰訊、漢王科技等知名企業(yè)深入推動(dòng)其工具應(yīng)用與實(shí)施活動(dòng)。
• 當(dāng)前正在作為產(chǎn)品經(jīng)理、架構(gòu)師帶領(lǐng)一個(gè)小型團(tuán)隊(duì)，從事“火星人敏捷開發(fā)在線服務(wù)”的研發(fā)工作。很多課程與咨詢中的最佳實(shí)踐，均來(lái)自于其之前及當(dāng)前參與的實(shí)際項(xiàng)目的一線實(shí)踐。

以下是采訪內(nèi)容：

記者： 在使用敏捷當(dāng)中，很多人都是看中了它的成本控制，能夠降低在項(xiàng)目開發(fā)中的浪費(fèi)，但是往往適得其反，不但沒(méi)有降低，反而增加了開發(fā)成本，那么在成本控制這塊您怎么去理解？

陳勇：看看清楚敏捷開發(fā)對(duì)成本的控制，先要看之前的方法有何問(wèn)題，比如瀑布模型。

對(duì)瀑布模型而言，有兩個(gè)地方控制不好成本：

一，瀑布模型中，如果項(xiàng)目簽的需求太多而價(jià)格太低，往往在中后期會(huì)通過(guò)工時(shí)統(tǒng)計(jì)等發(fā)現(xiàn)入不敷出，但由于普通模型這時(shí)候正處在編碼末期或測(cè)試前期，因此很難就此停下，或刪除某些次要功能繼續(xù)開發(fā)（因?yàn)樵谕砥趧h除功能往往成本很高）。

對(duì)這個(gè)問(wèn)題，敏捷開發(fā)解決得比較不錯(cuò)，也很容易實(shí)施。漸進(jìn)式交付使得“隨時(shí)”停止開發(fā)并進(jìn)行發(fā)布變得可能。

但要注意如果優(yōu)先級(jí)排序不當(dāng)，也可能會(huì)面臨“重要的功能還沒(méi)有開發(fā)，次要功能卻開發(fā)了不少”的尷尬境地。

另一個(gè)問(wèn)題是提前交付可以換回一些款項(xiàng)，但并不能徹底解決成本超支的問(wèn)題。這時(shí)候應(yīng)該配合類似功能點(diǎn)分析這類的方法來(lái)解決。也就是早期用功能點(diǎn)報(bào)價(jià)；中間如果通過(guò)計(jì)數(shù)發(fā)現(xiàn)由于需求蔓延、變更等原因?qū)е滦枨蟮目偭可仙耍敲匆曳接袡?quán)要求追加款項(xiàng)，或刪除某些次要功能。這種聽起來(lái)不可思議的想法，在某些國(guó)家如芬蘭、澳大利亞都是很普遍的。可能我們會(huì)抱怨說(shuō)甲方不贊同或不理解這種過(guò)于“偏技術(shù)”方法，但如果連乙方都不贊同不理解，就不能單方面責(zé)怪甲方了。2012年底中國(guó)剛剛推出了基于功能點(diǎn)的軟件成本估算相關(guān)的國(guó)標(biāo)，試點(diǎn)領(lǐng)域是政府軟件開發(fā)。雖然現(xiàn)在還沒(méi)有對(duì)階段性付款提出方案，可以已經(jīng)可以看出未來(lái)的大趨勢(shì)一定如此。

二，瀑布模型中，如果需求變更比較頻繁，初期付出眾多工作量的需求、設(shè)計(jì)常常被不斷返工，進(jìn)而又引發(fā)編碼返工，造成成本上升。

敏捷開發(fā)解決這個(gè)問(wèn)題的方法很簡(jiǎn)單：減少早期對(duì)需求、設(shè)計(jì)的投入，盡量早讓產(chǎn)品“可運(yùn)行”以便讓客戶提出反饋意見。

不過(guò)這個(gè)方法極其容易被“用過(guò)頭”，比如有些團(tuán)隊(duì)可能放棄了必要的需求和設(shè)計(jì)，導(dǎo)致由于蠻力編碼造成編碼混亂而不斷返工，整個(gè)產(chǎn)品則像一個(gè)沒(méi)有骨架的沙雕一樣難以

做大。

正確的方法是：在漸進(jìn)式開發(fā)、漸進(jìn)式交付的同時(shí)，做漸進(jìn)式需求和設(shè)計(jì)。我們要避免的是需求和設(shè)計(jì)返工，而不是需求和設(shè)計(jì)活動(dòng)本身。因此對(duì)大中型產(chǎn)品而言，應(yīng)該保證每個(gè)階段的編碼之前都有簡(jiǎn)單設(shè)計(jì)用以保證編碼的正確性；而被客戶確認(rèn)后的功能至少要“后補(bǔ)”需求和設(shè)計(jì)，以備未來(lái)回溯。這樣既避免蠻力編碼返工，又能避免推翻設(shè)計(jì)的返工。

記者：做到敏捷開發(fā)，每個(gè)團(tuán)隊(duì)都要經(jīng)歷一個(gè)轉(zhuǎn)型期，那么在轉(zhuǎn)型期還需要每個(gè)團(tuán)隊(duì)根據(jù)自身的不同，找出合理有效的解決方法。一般如何去處理這個(gè)問(wèn)題？

陳勇：這是培訓(xùn)和咨詢過(guò)程中最常見的一個(gè)問(wèn)題，也是最難回答的。有幾個(gè)步驟可以幫助找出合理有效并適合團(tuán)隊(duì)的方法。

一、對(duì)有效性進(jìn)行定義和評(píng)價(jià)

完全量化管理可能做不到，但“半年后，我們希望能每月發(fā)一個(gè)可交付版本”或“把總體測(cè)試時(shí)間降低一半”這類明確個(gè)別定義還是可以找到的。當(dāng)然不同團(tuán)隊(duì)首批目標(biāo)不同，首批要實(shí)踐的內(nèi)容也不同。但有了目標(biāo)，就可以防止團(tuán)隊(duì)借口“項(xiàng)目特色”，言敏捷之名行混沌之事。

二、階段性檢查和推進(jìn)目標(biāo)

前幾個(gè)迭代往往離目標(biāo)很遠(yuǎn)，很容易忙了半天才發(fā)現(xiàn)走偏了。這時(shí)候可以設(shè)置某些臨時(shí)目標(biāo)來(lái)作為“路標(biāo)”。比如，假設(shè)某團(tuán)隊(duì)經(jīng)常處于“很多活都在干，但沒(méi)有一個(gè)干完了，因此也不能交付”的狀態(tài)，而幾個(gè)月后希望做到“當(dāng)月計(jì)劃功能的交付比例達(dá)到80%”，那么可能需要這樣幾個(gè)路標(biāo)（實(shí)際工作不只如此）：

第一個(gè)月：實(shí)現(xiàn)任務(wù)的看板管理

第二個(gè)月：實(shí)現(xiàn)基于故事的看板管理

第三個(gè)月：當(dāng)月計(jì)劃功能交付比例達(dá)到50%

第四個(gè)月：控制在制品數(shù)量在2N-1以下（N是團(tuán)隊(duì)人數(shù)，此目標(biāo)即“同時(shí)開工的工作量

不超過(guò)2N-1個(gè)”）

……

第N個(gè)月：當(dāng)月計(jì)劃功能交付比例達(dá)到80%

在這個(gè)例子當(dāng)中可以看到，如果一上來(lái)就直接設(shè)定“當(dāng)月計(jì)劃功能交付比例達(dá)到50%”之類的度量數(shù)據(jù)，可能不但很難達(dá)到，甚至可能由于沒(méi)有看板管理而不能度量。

三、同時(shí)選擇超過(guò)一個(gè)團(tuán)隊(duì)進(jìn)行試點(diǎn)

敏捷開發(fā)的試點(diǎn)過(guò)程千變?nèi)f化，如果只找一個(gè)團(tuán)隊(duì)試點(diǎn)會(huì)有問(wèn)題。如果失敗了，大家會(huì)以為敏捷不行；如果成功了，大家會(huì)照搬經(jīng)驗(yàn)。

所以最好的方法是讓若干個(gè)團(tuán)隊(duì)各自基于自己的目標(biāo)進(jìn)行試點(diǎn)，如果其中有多個(gè)取得成功，大家會(huì)意識(shí)到原來(lái)成功的方法有很多種，就能靈活應(yīng)用在自己團(tuán)隊(duì)中進(jìn)行實(shí)驗(yàn)和推廣了。

四、需要對(duì)“商業(yè)目標(biāo)”與“一線實(shí)踐”有很深入的理解

做到這一點(diǎn)非常困難，然而偏偏這一點(diǎn)又是成敗的關(guān)鍵。

經(jīng)常見到很多團(tuán)隊(duì)或成員一擁而上開始試點(diǎn)某個(gè)局部實(shí)踐，有時(shí)候是Scrum中的撲克牌估算或每日立會(huì)，有時(shí)候是XP中的自動(dòng)化測(cè)試或結(jié)對(duì)編程。但做了一段時(shí)間，由于沒(méi)有目標(biāo)，尤其是沒(méi)有那些讓團(tuán)隊(duì)聽了之后就不會(huì)放棄的目標(biāo)，很快就堅(jiān)持不下去了。

要培養(yǎng)商業(yè)目標(biāo)意識(shí)很難，甚至很多從業(yè)之前沒(méi)有做過(guò)高級(jí)管理職位的敏捷培訓(xùn)師或咨詢師都不具備，更不用說(shuō)普通一線工作人員了。一種做法是讓高層比如部門經(jīng)理來(lái)宏觀協(xié)調(diào)敏捷的實(shí)施，而不要完全自下而上。高層經(jīng)理的職業(yè)特性保證了他們會(huì)潛移默化地關(guān)心最終實(shí)施的效果勝過(guò)實(shí)踐本身。說(shuō)起來(lái)，“效果勝過(guò)實(shí)踐”本身就是敏捷宣言中“可工作軟件勝過(guò)繁雜文檔”的現(xiàn)實(shí)體現(xiàn)。

五、要注意敏捷開發(fā)的生態(tài)系統(tǒng)問(wèn)題

剛才提到嘗試個(gè)別實(shí)踐經(jīng)常失敗，一個(gè)原因是因?yàn)槿鄙倌繕?biāo)只關(guān)注實(shí)踐，另外一個(gè)則是忽略了與此實(shí)踐相關(guān)的生態(tài)系統(tǒng)。

比如每日立會(huì)，看起來(lái)非常簡(jiǎn)單，但實(shí)踐起來(lái)困難重重。比如為什么我要告訴別人我的進(jìn)度？為什么我要告訴別人我遇到的困難？誰(shuí)因?yàn)槭裁丛驎?huì)提供幫助？……這些潛在的問(wèn)題，都需要相應(yīng)的團(tuán)隊(duì)模型來(lái)解決。敏捷開發(fā)生態(tài)系統(tǒng)就是用來(lái)描述各種活動(dòng)之間的關(guān)系的，這個(gè)在我的“敏捷開發(fā)生態(tài)系統(tǒng)”系列博客中有較為詳細(xì)的描述。

#p#

記者：敏捷過(guò)程中有一個(gè)我認(rèn)為最重要的部分是需求拆分，您能談?wù)勅绾芜M(jìn)行合理的拆分嗎？

陳勇：需求拆分是個(gè)業(yè)界難題，在敏捷開發(fā)領(lǐng)域是如此。盡管每個(gè)敏捷流派對(duì)這個(gè)問(wèn)題說(shuō)起來(lái)都頭頭是道，但是要說(shuō)誰(shuí)有一個(gè)過(guò)目不忘的好方法，還真沒(méi)有。

真正解決需求拆分問(wèn)題的關(guān)鍵有兩個(gè)：拆分后的顆粒度如何控制，拆分后的需求結(jié)構(gòu)如何表達(dá)。前者可能問(wèn)得比較多，因?yàn)槎鄶?shù)程序員都要關(guān)心；后者只有產(chǎn)品經(jīng)理會(huì)關(guān)心，所以顯得不太突出，但對(duì)大產(chǎn)品和持續(xù)開發(fā)的產(chǎn)品而言則是個(gè)關(guān)鍵問(wèn)題。

一、顆粒度問(wèn)題

這個(gè)問(wèn)題在敏捷框架下基本無(wú)解。

但在功能點(diǎn)分析（Function Point Analysis）中是一個(gè)基本概念。FPA通過(guò)對(duì)軟件中的“業(yè)務(wù)數(shù)據(jù)”以及對(duì)其進(jìn)行的“業(yè)務(wù)操作”為基本單元建立了顆粒度的概念，進(jìn)而建立了規(guī)模的概念。這些概念的應(yīng)用成熟度、推廣程度、數(shù)據(jù)積累量（公開的在10000個(gè)左右，在咨詢公司手中但非公開的在50000個(gè)左右，實(shí)際使用量不可估量）都遠(yuǎn)遠(yuǎn)超過(guò)敏捷開發(fā)或其他體系提出的方法，包括“故事點(diǎn)”。而且“業(yè)務(wù)操作”的概念非常接近用戶故事，也包括如減少依賴、完整交付客戶價(jià)值等描述。

下面舉一個(gè)例子來(lái)看功能點(diǎn)到底是什么。這里將略去功能點(diǎn)中對(duì)數(shù)據(jù)、操作的復(fù)雜細(xì)節(jié)分析過(guò)程，而只說(shuō)大概。

假設(shè)在一個(gè)OA系統(tǒng)中需要管理“用戶”“角色”“權(quán)限”這三種業(yè)務(wù)數(shù)據(jù)，那么他們就是業(yè)務(wù)數(shù)據(jù)；而對(duì)他們分別進(jìn)行的“增刪改查”就是業(yè)務(wù)操作。比如“新建用戶”“列出所有用戶”都是業(yè)務(wù)操作。“業(yè)務(wù)”這個(gè)詞在這里是相對(duì)于“技術(shù)”而言的，比如“新建用戶”對(duì)客戶而言是一個(gè)容易理解、認(rèn)可的操作，而且客戶管理員會(huì)告訴我們：

“是的，我現(xiàn)在每天都在新建用戶，因?yàn)樽罱谡腥?rdquo;而不會(huì)說(shuō)“是的，我最近每天都在數(shù)據(jù)庫(kù)表中新建記錄，還會(huì)同步更新聯(lián)系人數(shù)據(jù)表，因?yàn)樽罱谡腥?rdquo;，雖然后者也的確發(fā)生了，但卻不是客戶日常工作的內(nèi)容。

更神奇的是，“新建用戶”這個(gè)操作，在無(wú)法獲得更多細(xì)節(jié)的情況下，可以假設(shè)工作量為4人天（在OA系統(tǒng)中，其他系統(tǒng)有調(diào)整因子）；而統(tǒng)計(jì)還表明，“用戶”及所有與之相關(guān)的操作如剛才說(shuō)的“新建用戶”以及其他“刪除用戶”“列出所有用戶”“編輯用戶”……的總工作量（從需求到部署）大約是40人天，也就是2個(gè)人月，即使暫時(shí)不能確定到底有多少個(gè)操作。而“用戶”“角色”“權(quán)限”及其所有操作完成的工作量自然就是大約6人月。盡管每個(gè)數(shù)據(jù)或操作的時(shí)間可能會(huì)有出入，但總體規(guī)模則誤差不大。

這得益于大數(shù)定理及眾多統(tǒng)計(jì)數(shù)據(jù)的分析結(jié)果。本段內(nèi)容的詳情可在Google查詢“nesma”（一個(gè)總部在荷蘭的世界第二大功能點(diǎn)組織），這個(gè)簡(jiǎn)化體系稱為“Indicative Function Point”（指示性的功能點(diǎn)），在其網(wǎng)站上有荷蘭語(yǔ)和英語(yǔ)介紹。

如果對(duì)用戶故事的定義（而非“業(yè)務(wù)操作”的定義，因?yàn)楹笳吒晟啤?yán)格）略作約束，則可以迅速與功能點(diǎn)中的“業(yè)務(wù)操作”兼容。兼容的結(jié)果有兩個(gè)，首先是很容易把握顆粒度，其次是功能點(diǎn)與工作量的比例關(guān)系極佳，可以迅速推知工作量。

二、需求結(jié)構(gòu)問(wèn)題

在敏捷開發(fā)中有一個(gè)不完善的答案：Product Backlog 和 Sprint Backlog。前者是整個(gè)產(chǎn)品的待開發(fā)項(xiàng)，后者是當(dāng)前迭代的待開發(fā)項(xiàng)，兩者內(nèi)部都按優(yōu)先級(jí)進(jìn)行排序。

這個(gè)答案對(duì)項(xiàng)目經(jīng)理（可以模糊理解為Scrum Master）和開發(fā)人員足夠用了，因?yàn)樗麄冎饕P(guān)心時(shí)間上的開發(fā)問(wèn)題，也就是現(xiàn)在讓我做什么，什么時(shí)候要的問(wèn)題。但對(duì)產(chǎn)品經(jīng)理（可以模糊理解為Product Owner）而言，時(shí)間是一個(gè)維度，空間則是另外一個(gè)維度。

所謂空間維度，就是系統(tǒng)-子系統(tǒng)-模塊-大需求-小需求……之間的關(guān)系問(wèn)題，這完全不是一個(gè)一維表格能解決的。由于敏捷開發(fā)主要是一線開發(fā)人員和項(xiàng)目經(jīng)理發(fā)明并推動(dòng)的，所以空間維度一直被忽略。但這是需求分解過(guò)程中一個(gè)繞不過(guò)去的問(wèn)題，因?yàn)槿藗儾豢赡苊鎸?duì)一個(gè)一個(gè)一維表格回答這個(gè)問(wèn)題：“我們所有的功能都包括在這里呢嗎？哪部分還略顯粗糙希望繼續(xù)分解？這些大需求包含哪些小需求？”

在UML中的答案比較完善，“用戶 - Use Case”（人-功能）很好地把一批相關(guān)的功能聯(lián)系起來(lái)。雖然只是非常簡(jiǎn)單的表達(dá)，但比把幾個(gè)毫無(wú)關(guān)聯(lián)的故事按優(yōu)先級(jí)排在一起，或把幾個(gè)密切相關(guān)的故事相隔十萬(wàn)八千里放置還是進(jìn)步不少。UML中的模塊則是一個(gè)更宏觀的需求“目錄”。

FPA雖然沒(méi)有需求關(guān)系表達(dá)，但如果把“業(yè)務(wù)數(shù)據(jù) - 業(yè)務(wù)操作”作為一個(gè)樹形結(jié)構(gòu)，很類似把UML中的“實(shí)體 – Use Case”作為一個(gè)樹，形成“數(shù)據(jù)-功能”的關(guān)系。不過(guò)，這個(gè)體系沒(méi)有提供更宏觀尺度上的需求結(jié)構(gòu)問(wèn)題。

由于功能點(diǎn)、UML中的模塊用例等概念都是有嚴(yán)格、確定化的定義的，所以分解的過(guò)程井然有序，很少出現(xiàn)“這個(gè)還要繼續(xù)分嗎？”“這樣分是不是顆粒度太粗糙”之類的問(wèn)題。我們自己正在做的項(xiàng)目需求就是借用FPA的業(yè)務(wù)數(shù)據(jù)-業(yè)務(wù)操作作為主要分解關(guān)系，上面再加上我們自己定義的子系統(tǒng)-模塊兩個(gè)級(jí)別形成了一個(gè)“故事樹”。這個(gè)故事樹比我之前所做過(guò)及所見過(guò)的任何其他方法表達(dá)的需求結(jié)構(gòu)更為清晰。因此敏捷開發(fā)應(yīng)該吸取或者配合這些方法，至少是其中的一部分思想來(lái)完成需求分解。

很多時(shí)候我們會(huì)覺得引入較為嚴(yán)格的定義會(huì)“有限制太難做”，但其實(shí)更難做的是“無(wú)規(guī)則無(wú)限制”下自由發(fā)揮。

記者：敏捷開發(fā)中需求拆分之后，任務(wù)應(yīng)該怎樣分工？

陳勇：即使都是使用敏捷開發(fā)，任務(wù)拆分和分工的方法也會(huì)因行業(yè)、產(chǎn)品的特點(diǎn)而有所不同。

在純軟件或技術(shù)相對(duì)單一的產(chǎn)品中，需求拆解到4天左右（也就是前面提到的“一個(gè)業(yè)務(wù)操作”的規(guī)模）就可以分下去或領(lǐng)取了，因?yàn)槿藗儽容^容易估算4天左右的工作量，也容易跟蹤。在這種情況下，如果一個(gè)人同時(shí)負(fù)責(zé)幾個(gè)“業(yè)務(wù)操作”，應(yīng)該分解為多個(gè)任務(wù)來(lái)完成，而不是一個(gè)。因?yàn)檫@些業(yè)務(wù)操作可以獨(dú)立完成并交付，合在一起不但不能持續(xù)交付，也會(huì)使得進(jìn)展不透明。但再進(jìn)一步劃分沒(méi)有必要，因?yàn)樵賱澐志筒荒塥?dú)立交付了。“獨(dú)立性”是FPA中對(duì)業(yè)務(wù)操作的一個(gè)約束條件，如果按照FPA的概念來(lái)劃分任務(wù)，會(huì)自動(dòng)滿足獨(dú)立性。

在復(fù)雜環(huán)境比如嵌入式研發(fā)（涉及軟件、硬件、工業(yè)設(shè)計(jì)團(tuán)隊(duì)）或游戲（涉及軟件、美術(shù)、腳本、策劃團(tuán)隊(duì)），需求不能直接當(dāng)作任務(wù)分下去，需要做進(jìn)一步的分解。這里的分解目的是把不同工種的活分配下去，對(duì)其跟蹤的過(guò)程則可增進(jìn)各部門配合時(shí)所需的透明度。

也有一些團(tuán)隊(duì)喜歡把任務(wù)分解到短至1～2小時(shí)的時(shí)間。本人沒(méi)有與這樣的團(tuán)隊(duì)進(jìn)行深入探討以了解其這樣做的動(dòng)機(jī)及收益是什么，但要注意“更小的任務(wù)”不等于更敏捷。我們經(jīng)常說(shuō)敏捷開發(fā)有利于項(xiàng)目透明，但要知道透明的主體是“項(xiàng)目外部的人”，比如產(chǎn)品經(jīng)理、高層領(lǐng)導(dǎo)；而開發(fā)人員本人，或者小團(tuán)隊(duì)的若干個(gè)人之間，任務(wù)和進(jìn)度本來(lái)就是透明或半透明的。因此把詳細(xì)技術(shù)細(xì)節(jié)翻個(gè)底朝天并貼在白板上很可能不但于事無(wú)補(bǔ)反而添亂，不如把有限的管理時(shí)間用在“對(duì)外表達(dá)需求的完成情況”或“各部門的進(jìn)展及需要什么相互配合”上，也就是我們之前說(shuō)的兩種情況。

總之，對(duì)任務(wù)的分解應(yīng)該本著“需要”與“必要”的原則。不能因?yàn)橄?ldquo;更敏捷”而采用“更小的任務(wù)”。

記者：Sprint會(huì)議是實(shí)踐scrum中最重要的事件。您認(rèn)為Scrum會(huì)議在團(tuán)隊(duì)中應(yīng)如何進(jìn)行的？

陳勇：要做好計(jì)劃會(huì)，應(yīng)該先建好團(tuán)隊(duì)模型。

計(jì)劃會(huì)是少有的團(tuán)隊(duì)齊集一堂進(jìn)行的活動(dòng)，無(wú)論團(tuán)隊(duì)模型是怎樣的，都應(yīng)該有助于大家以集體的力量完成計(jì)劃，并完成計(jì)劃的任務(wù)。

因此，一些看上去很敏捷的團(tuán)隊(duì)模型或做事方法，很可能是很難鼓勵(lì)大家做到這一點(diǎn)的。比如：所有隊(duì)員都是平等的；大家在會(huì)上投票取平均值作為估算結(jié)果（還有一種做法：會(huì)上不需要估算，會(huì)后領(lǐng)取的人自己說(shuō)了算）；會(huì)后大家主動(dòng)領(lǐng)取任務(wù)；領(lǐng)取的任務(wù)大家互相不干涉，自己愿意怎么做就怎么做……這里邊存在什么問(wèn)題呢？

第一，“所有隊(duì)員平等”的團(tuán)隊(duì)互助的動(dòng)力從哪里來(lái)？人們一定會(huì)說(shuō)：都是在一起工作的同事，怎么會(huì)沒(méi)有互助動(dòng)力？我們?cè)?jīng)在一個(gè)團(tuán)隊(duì)實(shí)施代碼審查，而且是我之前多次提到的那個(gè)最好的139團(tuán)隊(duì)，很快發(fā)生一次事故：一大段4000多行但包含4000多個(gè)常數(shù)的爛代碼逃過(guò)了檢查者的眼睛進(jìn)入了代碼庫(kù)，并最后引發(fā)客戶現(xiàn)場(chǎng)的Bug。當(dāng)詢問(wèn)代碼審查者為何讓明顯存在問(wèn)題的代碼通過(guò)檢查？代碼審查者很無(wú)奈地說(shuō)：“我剛來(lái)不久，雖然我覺得這些代碼有問(wèn)題，但我感覺大家都說(shuō)他（編寫者）是個(gè)高手，我也就不想說(shuō)什么了。其實(shí)我本人也覺得這些代碼有問(wèn)題”。這件事情促使我們后來(lái)形成了139團(tuán)隊(duì)，就是形成層次團(tuán)隊(duì)，由師傅來(lái)審核徒弟的代碼，出問(wèn)題師傅負(fù)責(zé)。這不是說(shuō)所有團(tuán)隊(duì)一定要如此，而是說(shuō)不能簡(jiǎn)單地把互助建立在“雷鋒精神”上面。

第二，集體估算的目的何在？很多人認(rèn)為是領(lǐng)導(dǎo)放權(quán)發(fā)揚(yáng)民主，所以投票+平均值就體現(xiàn)了這一點(diǎn)。但如果一個(gè)人估10人天，另一個(gè)人估計(jì)1人天，結(jié)果到底是多少呢？總不能真的是5.5人天吧？所以估算的目的其實(shí)是想知道有沒(méi)有更快的方法，有沒(méi)有人在走彎路……如果為期一天的計(jì)劃會(huì)耗費(fèi)整個(gè)團(tuán)隊(duì)10多個(gè)人天，但卻避免了上百人天的彎路損失，就算真正物有所值。我遇到的單個(gè)任務(wù)的最大差異是20人天比0.5人天，很可惜他們不做敏捷開發(fā)也不做估算，是任務(wù)接近尾聲的時(shí)候被偶然發(fā)現(xiàn)的，只用了0.5人天就重寫了。在一個(gè)139團(tuán)隊(duì)中，一般師傅要和徒弟用敏捷估算撲克估計(jì)每個(gè)任務(wù)的工作量；如果剛才這個(gè)任務(wù)出現(xiàn)在139團(tuán)隊(duì)中，師傅不會(huì)取值（20+0.5）/2，而是通過(guò)與徒弟討論，讓徒弟學(xué)會(huì)如何用0.5人天來(lái)完成這個(gè)任務(wù)，因?yàn)橥降芾速M(fèi)的時(shí)間最后要算在整個(gè)師徒小組身上。如果不是139團(tuán)隊(duì)，也要找到類似的人們參與爭(zhēng)論和堅(jiān)持自己正確見解的動(dòng)力。

第三，剩下的“主動(dòng)領(lǐng)取任務(wù)”、“互不干涉”等，也要進(jìn)行相似的分析，不能因?yàn)?ldquo;看上去很自由很敏捷”就采納。提出這些實(shí)踐的團(tuán)隊(duì)可能與我們所處的情況差別很大，未必能拿來(lái)就用。我曾經(jīng)用過(guò)“自由領(lǐng)取任務(wù)”，那是在10年前的一個(gè)假期里邊，我邀請(qǐng)自己關(guān)系很近的兩個(gè)老部下來(lái)幫忙做一個(gè)軟件；一些零散任務(wù)就被單獨(dú)拿出來(lái)，誰(shuí)先做完手頭工作就自由領(lǐng)取，其中一個(gè)人領(lǐng)取了8個(gè)中的5個(gè)之多。但在之后的每一個(gè)項(xiàng)目中，我都會(huì)先想一想，團(tuán)隊(duì)是否允許我再次采用這個(gè)實(shí)踐。

團(tuán)隊(duì)模型理順了，計(jì)劃會(huì)所需的共同計(jì)劃、集思廣益、團(tuán)隊(duì)協(xié)作才能做好。

記者：在敏捷開發(fā)方法中，Scrum和XP我個(gè)人認(rèn)為比較常見，您能介紹下Scrum與XP的最大區(qū)別在哪里？在實(shí)踐中Scrum與XP只取其一，還是兩者都取，或者全都拋棄？

陳勇：Scrum主要是關(guān)于需求和項(xiàng)目管理的，而XP則主要是技術(shù)管理。

Scrum中關(guān)于Product Backlog的全部及Sprint Backlog的形成過(guò)程、評(píng)審會(huì)大部分，可以理解為需求管理內(nèi)容，包括需求開發(fā)，分解，描述，排序以及進(jìn)展跟蹤的過(guò)程。而估算、每日立會(huì)、燃盡圖等內(nèi)容則屬于項(xiàng)目管理。

XP則主要是技術(shù)管理問(wèn)題，不過(guò)其結(jié)構(gòu)不明確，不好分類。

這個(gè)差別也可以解釋Scrum為何易于推廣：因?yàn)槠湔麄€(gè)體系很清晰。比如在我的培訓(xùn)課程中有一個(gè)貫穿始終的練習(xí)，用三個(gè)需求的描述、分解和估算過(guò)程來(lái)演練Scrum。這個(gè)練習(xí)能從第一天上午10：00左右開始，斷斷續(xù)續(xù)穿插于培訓(xùn)中，一直持續(xù)到第二天中午；要用一個(gè)練習(xí)把所有或者只是大部分的XP實(shí)踐串聯(lián)起來(lái)則幾乎是不可能的。另外Scrum宣貫起來(lái)也不需要大的技術(shù)革命，主要是人員職責(zé)的重新描述，部分管理活動(dòng)如計(jì)劃、跟蹤的引進(jìn)，因此門檻很低。不過(guò)反過(guò)來(lái)，由于缺少實(shí)際的技術(shù)改進(jìn)，若只得其皮毛而沒(méi)有利用團(tuán)隊(duì)、過(guò)程的變化來(lái)真正促進(jìn)開發(fā)，那么Scrum失敗的概率也很高。

Scrum在商業(yè)運(yùn)作上也更成功。這應(yīng)該歸功于Scrum的發(fā)明者是項(xiàng)目經(jīng)理或更高級(jí)別的人員，而XP則主要是一線員工，甚至說(shuō)是Geek們不為過(guò)。Scrum推出了認(rèn)證的Scrum Master和Product Owner兩種認(rèn)證，由于體系相對(duì)完整，認(rèn)證課程目標(biāo)聽眾的收入也相對(duì)較高，所以推廣起來(lái)比較容易；多數(shù)咨詢師更容易理解Scrum的理念而非XP的，也使之得以快速推廣。

不過(guò)長(zhǎng)遠(yuǎn)看來(lái)，團(tuán)隊(duì)，過(guò)程，技術(shù)三者密不可分。Scrum覆蓋了前兩者中的一部分，但如果沒(méi)有持續(xù)集成、自動(dòng)化測(cè)試等方法的支撐，迭代交付將很難完成。所以，未來(lái)應(yīng)該會(huì)有并存的需要，即使不再以當(dāng)前的兩個(gè)名字存在。

#p#

記者：拙劣的度量指標(biāo)會(huì)產(chǎn)生嚴(yán)重的后果，敏捷度量指標(biāo)也是一個(gè)很有爭(zhēng)議的問(wèn)題，以您的經(jīng)驗(yàn)如何去解決這個(gè)問(wèn)題？

陳勇：有多個(gè)層次的指標(biāo)可供衡量，下面從基層到高層一層層剖析一下。

一、基層度量

對(duì)最基層活動(dòng)而言，一般所有度量均不用于個(gè)體考核，而只是用于改進(jìn)。比如個(gè)體的缺陷率、工作完成量、按時(shí)完成率等。

之所以這樣做，原因是不希望面向個(gè)體的考核破壞了團(tuán)隊(duì)中原本用來(lái)提高生產(chǎn)率的團(tuán)隊(duì)協(xié)作。團(tuán)隊(duì)協(xié)作可以消除個(gè)體錯(cuò)誤，通過(guò)共同估算讓高手的技能流向新手，等等。如果個(gè)體考核讓人心有掛念，會(huì)產(chǎn)生問(wèn)題。

不過(guò)一個(gè)不可回避的問(wèn)題是：不管你們敏捷開發(fā)怎么說(shuō)，但財(cái)務(wù)終究要把績(jī)效獎(jiǎng)金（假如有）發(fā)放到個(gè)體而非團(tuán)隊(duì)的賬戶上，怎么知道誰(shuí)應(yīng)該發(fā)多少呢？在一個(gè)10個(gè)隊(duì)員且關(guān)系互相平行的團(tuán)隊(duì)里邊，的確沒(méi)有辦法知道，因此也不得不面向個(gè)體考核，并最終不可避免地毀掉團(tuán)隊(duì)協(xié)作。

但在一個(gè)139團(tuán)隊(duì)里邊，答案比較簡(jiǎn)單。139團(tuán)隊(duì)，就是1個(gè)項(xiàng)目經(jīng)理，帶3個(gè)高手（師傅），每個(gè)高手再帶3個(gè)新手（徒弟）；師傅全權(quán)負(fù)責(zé)自己及3個(gè)徒弟的工作，從進(jìn)度，設(shè)計(jì)到質(zhì)量；師傅會(huì)選擇關(guān)鍵時(shí)間點(diǎn)與徒弟碰頭，以便用最少時(shí)間解決最大的問(wèn)題（這種活動(dòng)稱之為“松結(jié)對(duì)編程”，在我的“敏捷開發(fā)松結(jié)對(duì)編程系列”中有詳細(xì)描述）；師傅對(duì)徒弟的代碼進(jìn)行代碼審查；平時(shí)徒弟有問(wèn)題會(huì)師傅。在這樣一個(gè)團(tuán)隊(duì)中，項(xiàng)目經(jīng)理收入最高，師傅次之，徒弟最低。薪水相對(duì)固定，如果位置沒(méi)有變化，無(wú)論自己一個(gè)人多編碼了還是幫別人太多導(dǎo)致少編碼了，都差不多。因此要想拿到高薪，不是在短期內(nèi)多編寫幾行代碼或關(guān)閉幾個(gè)Bug，而是看長(zhǎng)期：新人先要達(dá)到獨(dú)立工作能力，然后幫助團(tuán)隊(duì)擴(kuò)張也就是自己帶徒弟成為師傅，最后成為可以獨(dú)自擔(dān)當(dāng)一種業(yè)務(wù)的人也就是項(xiàng)目經(jīng)理。在這種團(tuán)隊(duì)中，人的收入增長(zhǎng)不是通過(guò)內(nèi)部競(jìng)爭(zhēng)，而是通過(guò)內(nèi)部協(xié)作做到的。

因此它是一種兼容敏捷團(tuán)隊(duì)精神的個(gè)體績(jī)效考核方法。

二、外部度量

正如前面所說(shuō)，外部度量是為了讓團(tuán)隊(duì)對(duì)外透明而做的度量。有這樣幾個(gè)原則：只做外部看得懂的度量；只做外部有人看的度量；盡量少做度量。

典型的外部度量是給PO也就是產(chǎn)品經(jīng)理所作的用戶故事的完成情況的度量，比如白板上處于完成狀態(tài)的故事的數(shù)量。這里說(shuō)故事而非任務(wù)，是因?yàn)閷?duì)產(chǎn)品經(jīng)理而言，任務(wù)完成沒(méi)有意義。

生產(chǎn)率也經(jīng)常是一個(gè)被度量的內(nèi)容，但現(xiàn)在尚無(wú)好的方法。有些團(tuán)隊(duì)經(jīng)常使用“故事點(diǎn)”來(lái)做度量，方法是：先挑選一些以往的故事作為典型故事；為每個(gè)典型故事分配一個(gè)點(diǎn)數(shù)（一般是當(dāng)時(shí)完成此故事的天數(shù)）；每次估算新故事時(shí)查先看更像哪個(gè)典型故事，然后再根據(jù)難度差別為新故事設(shè)定一個(gè)點(diǎn)數(shù)；實(shí)際完成后，點(diǎn)數(shù)/天數(shù)=生產(chǎn)率，也就是實(shí)際完成點(diǎn)數(shù)的速度。這個(gè)方法看似有效，但因?yàn)榇蠹覍?duì)典型故事的熟悉程度差別很大，典型故事也很難選擇，導(dǎo)致實(shí)際使用的人很少。另外一個(gè)問(wèn)題是不同項(xiàng)目的典型故事和點(diǎn)數(shù)是不通用的，因此無(wú)法做比較。好不容易做了一個(gè)想對(duì)外發(fā)布的生產(chǎn)率，卻無(wú)法橫向比較只能自?shī)首詷?lè)，顯然存在問(wèn)題。未來(lái)，這個(gè)問(wèn)題可能會(huì)被功能點(diǎn)生產(chǎn)率解決，但現(xiàn)在還沒(méi)有看到有人嘗試。我們自己做了一些宏觀嘗試，但沒(méi)有每個(gè)迭代都做。

此外還有一些度量，但取決于實(shí)際的需要。比如在線運(yùn)行的網(wǎng)絡(luò)游戲，會(huì)度量迭代交付周期長(zhǎng)度（直接影響響應(yīng)時(shí)間，因此一般越短越好）。這些度量不全是明確量化的，但公司上下都能說(shuō)出一個(gè)大致的數(shù)字來(lái)，因此也算是度量。

三、業(yè)務(wù)運(yùn)營(yíng)與收入度量

既然敏捷開發(fā)說(shuō)是“交付客戶價(jià)值”而非文檔或代碼的，那么一定能改善營(yíng)收或其他運(yùn)營(yíng)指標(biāo)。

比如市場(chǎng)占有率，每日點(diǎn)擊數(shù)，平均在線人數(shù)，每活躍用戶收入……等等，這些營(yíng)收應(yīng)該都是做敏捷度量的人所需要關(guān)注的。Scrum設(shè)置了PO來(lái)收集、描述、排序最重要的需求，又安排團(tuán)隊(duì)在自組織下高速生產(chǎn)出來(lái)，通過(guò)評(píng)審會(huì)后交付給客戶。因此如果這一切都是真的，沒(méi)有理由在實(shí)現(xiàn)敏捷開發(fā)后業(yè)務(wù)營(yíng)收不變或下滑。當(dāng)然可能很多因素制約了企業(yè)的營(yíng)收情況，但如果既不度量也不關(guān)心，直接來(lái)一句“由于情況很復(fù)雜，因此企業(yè)營(yíng)收與研發(fā)沒(méi)有直接關(guān)系”，顯然只能被作為自我否定和消極逃避的借口。

現(xiàn)在有些團(tuán)隊(duì)如網(wǎng)絡(luò)游戲和搜索引擎公司，已經(jīng)把這些數(shù)據(jù)引入了開發(fā)團(tuán)隊(duì)的度量中。但一般不做績(jī)效考核，而是讓大家知道最近我們的研發(fā)在市場(chǎng)上的實(shí)際反饋如何。

四、內(nèi)部創(chuàng)業(yè)

任何時(shí)候想度量的時(shí)候都要問(wèn)：為什么要度量？答案是：度量的目的是為了改善目標(biāo)。

那么如果說(shuō)企業(yè)的終極目標(biāo)是盈利，而卻有一種方法不需要度量就能提升盈利，那么應(yīng)該怎樣？當(dāng)然就不用度量了！目標(biāo)永遠(yuǎn)比方法要重要。

比如現(xiàn)在網(wǎng)絡(luò)游戲團(tuán)隊(duì)普遍有一個(gè)政策：20%的營(yíng)收歸項(xiàng)目作為獎(jiǎng)金。一般這個(gè)數(shù)字從幾十萬(wàn)到上億的規(guī)模，而團(tuán)隊(duì)往往不到100人。他們不在通過(guò)繁雜的績(jī)效考核系統(tǒng)中的度量項(xiàng)發(fā)放獎(jiǎng)金，而直接把收入變成開發(fā)人員的動(dòng)力。這種方法跳過(guò)了所有繁瑣的度量過(guò)程，直擊問(wèn)題實(shí)質(zhì)，是一種不度量而改善目標(biāo)的典范，可以理解為敏捷開發(fā)“可運(yùn)行軟件超過(guò)繁瑣文檔”這種嘗試弱化中間過(guò)程的思想的產(chǎn)物。 

當(dāng)然，即使不能“內(nèi)部創(chuàng)業(yè)”，也一樣能做到類似的效果。比如降低程序員的基本工資，代之以把公司產(chǎn)品銷售的一部分錢拿來(lái)做獎(jiǎng)金。程序員自然就開始關(guān)心客戶需求，嘗試?yán)斫饪蛻舻降滓裁床灰裁矗瑖L試自覺改善質(zhì)量防止客戶流失，嘗試自己帶徒弟以便讓團(tuán)隊(duì)成長(zhǎng)進(jìn)而增加產(chǎn)品競(jìng)爭(zhēng)力……很多效果是通過(guò)度量都難以進(jìn)行改善的。

最后這個(gè)問(wèn)題的答案，其實(shí)回到了問(wèn)題的本質(zhì)：敏捷開發(fā)提出的目的，其實(shí)還不是敏捷宣言中的那四句話左側(cè)的部分（個(gè)體與交互，可運(yùn)行軟件，客戶協(xié)作，響應(yīng)變化），而是通過(guò)這四點(diǎn)來(lái)幫助企業(yè)提高營(yíng)收。因此，敏捷開發(fā)的度量，換言之敏捷開發(fā)要改善的地方，不能只是一線工程實(shí)踐，而應(yīng)該是“客戶價(jià)值”的改善，也就是營(yíng)收的增加。否則敏捷開發(fā)就可能長(zhǎng)期處于基層游擊隊(duì)活動(dòng)，在敏捷熱潮過(guò)去之后，被證明又是一個(gè)重過(guò)程不重結(jié)果的空架子而已。

記者：您是否能談?wù)勗陧?xiàng)目中，敏捷測(cè)試人員的職責(zé)和技能要求？

陳勇：關(guān)于這個(gè)問(wèn)題，有趣的是：“測(cè)試活動(dòng)”比“測(cè)試人員”在敏捷開發(fā)中出現(xiàn)的頻率更高。原因就是敏捷開發(fā)中提倡跨職能，也就是所有人都對(duì)開發(fā)、測(cè)試負(fù)責(zé)，從測(cè)試活動(dòng)的目標(biāo)的轉(zhuǎn)變上就能看出來(lái)。

傳統(tǒng)認(rèn)為，測(cè)試人員是幫開發(fā)人員找Bug的，這是個(gè)誤區(qū)。其實(shí)，開發(fā)人員才是負(fù)責(zé)找Bug的，尤其是自己找自己的Bug。打個(gè)比方，如果我們?cè)谧约杭依锿髓€匙放在哪里了，一定不會(huì)把家里翻個(gè)底朝天，而是會(huì)嘗試找自己以前習(xí)慣放鑰匙的地方；但如果讓一個(gè)客人來(lái)找，就不那么容易了，因?yàn)榭腿瞬皇煜ぜ彝キh(huán)境，也不熟悉我們放鑰匙的習(xí)慣。家庭環(huán)境就是軟件，而鑰匙就是Bug，測(cè)試人員則是一個(gè)不太熟悉家庭環(huán)境的客人，開發(fā)人員才是那個(gè)放鑰匙的人，盡管他暫時(shí)“忘了放在哪里了”。而且長(zhǎng)期而言，只有開發(fā)人員才能改變自己的習(xí)慣，比如在墻上釘個(gè)釘子，習(xí)慣性地把鑰匙掛在上面。我們?cè)谝粋€(gè)項(xiàng)目中密集實(shí)踐過(guò)代碼審查活動(dòng)，在短短27天時(shí)間里，通過(guò)每天花費(fèi)半小時(shí)觀察、記錄、分析自己的缺陷，個(gè)體缺陷率降低了一半之多。而且好的習(xí)慣和規(guī)范一旦固化下來(lái)，以后無(wú)需花費(fèi)額外時(shí)間也能在一定程度上保證代碼質(zhì)量，可謂一勞永逸。

找bug的活被搶走了，傳統(tǒng)測(cè)試人員怎么辦？有兩種出路，或者說(shuō)“職業(yè)生涯規(guī)劃”，都比原來(lái)傳統(tǒng)測(cè)試人員更有前景。

一、有開發(fā)經(jīng)驗(yàn)的測(cè)試人員應(yīng)該轉(zhuǎn)向“開發(fā)測(cè)試”

“開發(fā)測(cè)試”是游戲領(lǐng)域的一種工種，對(duì)應(yīng)的是完全不需要對(duì)開發(fā)有了解的“黑盒測(cè)試”，我們可以把它的定義擴(kuò)展一下用在這里。開發(fā)測(cè)試在開發(fā)活動(dòng)中主要負(fù)責(zé)自動(dòng)化測(cè)試、持續(xù)集成、回歸測(cè)試等用于快速保證產(chǎn)品質(zhì)量的活動(dòng)。

為什么叫“快速保證產(chǎn)品質(zhì)量”而不是“發(fā)現(xiàn)Bug”呢？因?yàn)殚_發(fā)測(cè)試程序的人其實(shí)不應(yīng)該是這里的開發(fā)測(cè)試，而是開發(fā)某個(gè)功能的開發(fā)人員本身。正如之前所說(shuō)，具體的功能開發(fā)者更清楚功能是什么，可能有哪些潛在的問(wèn)題，如何驗(yàn)證最好……所以開發(fā)并第一次執(zhí)行（為發(fā)現(xiàn)缺陷而執(zhí)行）的是開發(fā)人員；但如何讓眾多測(cè)試用例自動(dòng)地全部或有選擇地再次運(yùn)行，如何保證更高的運(yùn)行效率、如何準(zhǔn)備自動(dòng)集成環(huán)境，則是開發(fā)測(cè)試人員的工作。

如果有可能，個(gè)人感覺最好不要設(shè)置全職的開發(fā)測(cè)試，而是視實(shí)際情況由不同的開發(fā)人員兼任。這樣更容易平衡工作量、保證開發(fā)與測(cè)試的銜接有效性。

整體上這個(gè)出路偏向開發(fā)人員多一些。

二、“沒(méi)有開發(fā)經(jīng)驗(yàn)”的測(cè)試人員應(yīng)該轉(zhuǎn)向“產(chǎn)品經(jīng)理”或“專業(yè)測(cè)試人員”產(chǎn)品經(jīng)理不說(shuō)了，因?yàn)槌雎泛苷＿@里說(shuō)說(shuō)專業(yè)測(cè)試人員。

有很多時(shí)候我們覺得原來(lái)的測(cè)試人員不就是“專業(yè)測(cè)試人員”嗎？其實(shí)不然。很多測(cè)試人員不過(guò)是看看說(shuō)明書，點(diǎn)點(diǎn)鼠標(biāo)，填填Bug而已，很難說(shuō)上“專業(yè)“二字。

個(gè)人感覺對(duì)測(cè)試人員而言，“專業(yè)”有兩重含義。第一，對(duì)所在領(lǐng)域的質(zhì)量問(wèn)題和解決方法有深入理解。比如特定的軟件，可用率是首位的（比如網(wǎng)站，允許癱瘓但不能總癱瘓）還是故障率是首位的（比如飛機(jī)，不允許故障）。Windows經(jīng)常死機(jī)，但是恢復(fù)速度很快，用起來(lái)也很簡(jiǎn)單，這在家用軟件中就是可接受的“高質(zhì)量”標(biāo)準(zhǔn)；但用作服務(wù)器，可能就有點(diǎn)問(wèn)題。如果不理解這些就開始測(cè)試，結(jié)果肯定是事倍功半。第二，對(duì)測(cè)試方法論應(yīng)該有深入理解。軟件仿真，持續(xù)集成，灰度發(fā)布……這些都可以稱為測(cè)試方法論或質(zhì)量方法論。“專業(yè)測(cè)試人員”用這些方法論指導(dǎo)前面說(shuō)的“開發(fā)測(cè)試人員”進(jìn)行測(cè)試，是一種很好的工作方式。

我曾經(jīng)在松結(jié)對(duì)編程與139團(tuán)隊(duì)系列博客中多次提到一個(gè)23個(gè)開發(fā)人員加2個(gè)測(cè)試人員的團(tuán)隊(duì)，其中兩個(gè)測(cè)試人員就是專業(yè)測(cè)試人員。尤其是其中的測(cè)試經(jīng)理，會(huì)定期基于業(yè)務(wù)的需要向我們提出測(cè)試要求，而我們則幫她編碼實(shí)現(xiàn)。這種搭配方式最終促成了產(chǎn)品的高質(zhì)量，它現(xiàn)在正運(yùn)行在國(guó)內(nèi)60%以上的數(shù)字電視臺(tái)。

這里的“沒(méi)有開發(fā)經(jīng)驗(yàn)”被打上了引號(hào)，是因?yàn)槲覠o(wú)數(shù)次聽到有人說(shuō)“我沒(méi)有開發(fā)經(jīng)驗(yàn)，也不懂開發(fā)”，但這個(gè)人可能是與開發(fā)人員共事很多年的資深測(cè)試人員。其實(shí)，與相對(duì)論相比，開發(fā)更像是外語(yǔ)，就是外國(guó)乞丐學(xué)多了也能學(xué)會(huì)的東西。因此實(shí)在不能用技術(shù)壁壘作為借口，要做好可能很難，但要了解的確不難。要做好測(cè)試這個(gè)工作，不去側(cè)面了解和理解開發(fā)，是很不現(xiàn)實(shí)的。

記者： 在敏捷實(shí)踐的過(guò)程中是否一定要使用一些敏捷工具？能否推薦一些您認(rèn)為比較好的工具？

陳勇：因?yàn)槲易约阂苍陂_發(fā)一個(gè)敏捷工具“火星人”，所以就不直接推薦工具了，呵呵。不過(guò)下面可以介紹一下一些一般原則：

一、一定要選擇適合自己行業(yè)領(lǐng)域的產(chǎn)品

有些產(chǎn)品可能是為大型制造業(yè)、銀行、電信等開發(fā)設(shè)計(jì)的，那么盡管也叫“敏捷開發(fā)”產(chǎn)品，但里邊會(huì)帶有很多大型產(chǎn)品設(shè)計(jì)中所需的元素，比如UML，Portfolio Management（可以理解為大團(tuán)隊(duì)或多團(tuán)隊(duì)的管理）等內(nèi)容。這并非像有人說(shuō)的他們?cè)?ldquo;掛羊頭賣狗肉”，而是在特殊行業(yè)實(shí)施敏捷所必需的適應(yīng)。反之，簡(jiǎn)單的電子白板工具往往反而不適合在這些行業(yè)應(yīng)用。

通過(guò)翻閱供應(yīng)商提供的客戶清單可以有所了解，而產(chǎn)品的主要功能和主張的方法論也能提供一些線索。這些資料往往印刷在宣傳資料或發(fā)布在網(wǎng)站上，公開且不易被輕易修改。

二、根據(jù)“數(shù)據(jù)持久性”選擇產(chǎn)品

所謂數(shù)據(jù)持久性，就是指數(shù)據(jù)要保存多久。如果是電子白板類產(chǎn)品，產(chǎn)品選型可以稍微“隨意”一些，因?yàn)殡娮影装迳系臇|西多數(shù)零散、顆粒度較小，很少需要幾個(gè)月之后還要查看。所以可以大膽嘗試這些產(chǎn)品。其他比如計(jì)劃管理的工具也比較容易更換，畢竟完成了的項(xiàng)目的計(jì)劃被訪問(wèn)的次數(shù)和必要性會(huì)迅速下降。

而對(duì)于需求管理、缺陷管理等產(chǎn)品，尤其是前者，則需要慎重選型。視行業(yè)的不同，這些產(chǎn)品可能需要考慮到未來(lái)3～5年乃至更長(zhǎng)的數(shù)據(jù)保存問(wèn)題，所以需要慎重一些。另外這些產(chǎn)品往往跨多個(gè)職能部門，選型時(shí)需要多方同時(shí)協(xié)調(diào)。

三、未必一個(gè)公司只用一個(gè)產(chǎn)品

All In One是每個(gè)公司的夢(mèng)想，不過(guò)卻不現(xiàn)實(shí)。我培訓(xùn)或咨詢過(guò)的一些大型電信企業(yè)，其涉獵的領(lǐng)域之廣往往令人驚訝。有家公司在做計(jì)費(fèi)系統(tǒng)、BOSS系統(tǒng)（業(yè)務(wù)和運(yùn)營(yíng)系統(tǒng)）的同時(shí)，還在做移動(dòng)互聯(lián)網(wǎng)軟件甚至游戲。前兩者對(duì)需求遵從性、成本控制的控制是核心，因?yàn)樗鼈兺婕凹滓曳胶贤欢笳邉t對(duì)創(chuàng)新性要求更高，喜歡“擁抱變化”。

這種情況下管理層應(yīng)該深刻理解不同領(lǐng)域的管理要點(diǎn)。比如甲乙方項(xiàng)目中，“誰(shuí)在做什么”這類任務(wù)細(xì)節(jié)往往是重要的，因他它能保證所有人都有活干，防止空置資源的浪費(fèi)；對(duì)完成功能的多少的掌握也是重要的（最好使用功能點(diǎn)），因?yàn)樗鼙碚鬟M(jìn)度。但在移動(dòng)互聯(lián)網(wǎng)軟件中，“現(xiàn)在我們?cè)谧鍪裁?rdquo;“什么時(shí)候這個(gè)功能能做出來(lái)”“這個(gè)功能做出來(lái)反饋如何”才是重點(diǎn)。

由此可見，領(lǐng)域要求不同，方法論就會(huì)不同，管理工具自然也可能不同。除了一些簡(jiǎn)單的白板軟件“都能用”之外，復(fù)雜產(chǎn)品很少能適應(yīng)如此巨大的差異，甚至說(shuō)也不應(yīng)該適應(yīng)所有領(lǐng)域使用。

在這種復(fù)雜情況下進(jìn)行選型的時(shí)候，領(lǐng)導(dǎo)層或領(lǐng)域?qū)＜覒?yīng)該給出自己對(duì)管理的核心需求，然后再放手讓團(tuán)隊(duì)進(jìn)行自由選擇，只要驗(yàn)證核心需求被滿足就可以了。