建站
咨詢
售后
建站咨詢
新聞中心
有人說，實(shí)踐敏捷的根本不在于敏捷本身，而在于理解敏捷背后擁抱變化的基因。確實(shí)，使用敏捷，那么你就應(yīng)該知道為何敏捷。如今，國內(nèi)很多敏捷團(tuán)隊(duì)沒有真正的了解敏捷的精髓，也說明了為什么在使用敏捷的過程中并沒有真正的“敏捷”。所以，不但不能真正的解決傳統(tǒng)開發(fā)的一些問題，反而新增加了更多的問題。因此，記者采訪了具有17年軟件研發(fā)、管理咨詢經(jīng)驗(yàn)，擅長在實(shí)際環(huán)境中應(yīng)用敏捷開發(fā)實(shí)踐的專家陳勇老師，為網(wǎng)友們解讀敏捷在開發(fā)實(shí)踐及管理中的一些問題。
成都創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站建設(shè)、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的西區(qū)網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
陳勇，17年軟件研發(fā)、管理及咨詢經(jīng)驗(yàn)，擅長在實(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è)管理者的角度，以更廣的視角來理解敏捷開發(fā)，并能配合和推動(dòng)非研發(fā)部門協(xié)作推廣敏捷。
工作經(jīng)歷：
- 曾以技術(shù)骨干和項(xiàng)目經(jīng)理等身份，組織和承擔(dān)開發(fā)了國慶50周年直升機(jī)編隊(duì)指揮系統(tǒng)、空軍一基地GPS數(shù)據(jù)源系統(tǒng)、清華同方CCTV數(shù)字電視條件接收系統(tǒng)、航空材料研究院無損檢測系統(tǒng)等項(xiàng)目，并在其中某些項(xiàng)目中實(shí)踐敏捷。
- 曾在清華同方、普天集團(tuán)、亞信科技等企業(yè)擔(dān)任EPG骨干、組長；曾在斯福泰克、DNV ITGS等機(jī)構(gòu)擔(dān)任CMMI/敏捷咨詢師。
- 曾在中國系統(tǒng)與軟件改進(jìn)年會 、中國軟件技術(shù)大會、敏捷中國大會、MPD等國際國內(nèi)會議從事敏捷演講、翻譯或主持工作。
- 在任泰克賽爾軟件公司中國部門的咨詢總監(jiān)、ALM事業(yè)部總監(jiān)、副總經(jīng)理期間，主管敏捷研發(fā)管理工具的市場、銷售、支持與咨詢活動(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í)踐，均來自于其之前及當(dāng)前參與的實(shí)際項(xiàng)目的一線實(shí)踐。
以下是采訪內(nèi)容：
記者： 在使用敏捷當(dāng)中，很多人都是看中了它的成本控制，能夠降低在項(xiàng)目開發(fā)中的浪費(fèi)，但是往往適得其反，不但沒有降低，反而增加了開發(fā)成本，那么在成本控制這塊您怎么去理解？
陳勇：看看清楚敏捷開發(fā)對成本的控制，先要看之前的方法有何問題，比如瀑布模型。
對瀑布模型而言，有兩個(gè)地方控制不好成本：
一，瀑布模型中，如果項(xiàng)目簽的需求太多而價(jià)格太低，往往在中后期會通過工時(shí)統(tǒng)計(jì)等發(fā)現(xiàn)入不敷出，但由于普通模型這時(shí)候正處在編碼末期或測試前期，因此很難就此停下，或刪除某些次要功能繼續(xù)開發(fā)（因?yàn)樵谕砥趧h除功能往往成本很高）。
對這個(gè)問題，敏捷開發(fā)解決得比較不錯(cuò)，也很容易實(shí)施。漸進(jìn)式交付使得“隨時(shí)”停止開發(fā)并進(jìn)行發(fā)布變得可能。
但要注意如果優(yōu)先級排序不當(dāng)，也可能會面臨“重要的功能還沒有開發(fā)，次要功能卻開發(fā)了不少”的尷尬境地。
另一個(gè)問題是提前交付可以換回一些款項(xiàng)，但并不能徹底解決成本超支的問題。這時(shí)候應(yīng)該配合類似功能點(diǎn)分析這類的方法來解決。也就是早期用功能點(diǎn)報(bào)價(jià)；中間如果通過計(jì)數(shù)發(fā)現(xiàn)由于需求蔓延、變更等原因?qū)е滦枨蟮目偭可仙耍敲匆曳接袡?quán)要求追加款項(xiàng)，或刪除某些次要功能。這種聽起來不可思議的想法，在某些國家如芬蘭、澳大利亞都是很普遍的?？赡芪覀儠г拐f甲方不贊同或不理解這種過于“偏技術(shù)”方法，但如果連乙方都不贊同不理解，就不能單方面責(zé)怪甲方了。2012年底中國剛剛推出了基于功能點(diǎn)的軟件成本估算相關(guān)的國標(biāo)，試點(diǎn)領(lǐng)域是政府軟件開發(fā)。雖然現(xiàn)在還沒有對階段性付款提出方案，可以已經(jīng)可以看出未來的大趨勢一定如此。
二，瀑布模型中，如果需求變更比較頻繁，初期付出眾多工作量的需求、設(shè)計(jì)常常被不斷返工，進(jìn)而又引發(fā)編碼返工，造成成本上升。
敏捷開發(fā)解決這個(gè)問題的方法很簡單：減少早期對需求、設(shè)計(jì)的投入，盡量早讓產(chǎn)品“可運(yùn)行”以便讓客戶提出反饋意見。
不過這個(gè)方法極其容易被“用過頭”，比如有些團(tuán)隊(duì)可能放棄了必要的需求和設(shè)計(jì)，導(dǎo)致由于蠻力編碼造成編碼混亂而不斷返工，整個(gè)產(chǎn)品則像一個(gè)沒有骨架的沙雕一樣難以
做大。
正確的方法是：在漸進(jìn)式開發(fā)、漸進(jìn)式交付的同時(shí)，做漸進(jìn)式需求和設(shè)計(jì)。我們要避免的是需求和設(shè)計(jì)返工，而不是需求和設(shè)計(jì)活動(dòng)本身。因此對大中型產(chǎn)品而言，應(yīng)該保證每個(gè)階段的編碼之前都有簡單設(shè)計(jì)用以保證編碼的正確性；而被客戶確認(rèn)后的功能至少要“后補(bǔ)”需求和設(shè)計(jì)，以備未來回溯。這樣既避免蠻力編碼返工，又能避免推翻設(shè)計(jì)的返工。
記者：做到敏捷開發(fā)，每個(gè)團(tuán)隊(duì)都要經(jīng)歷一個(gè)轉(zhuǎn)型期，那么在轉(zhuǎn)型期還需要每個(gè)團(tuán)隊(duì)根據(jù)自身的不同，找出合理有效的解決方法。一般如何去處理這個(gè)問題？
陳勇：這是培訓(xùn)和咨詢過程中最常見的一個(gè)問題，也是最難回答的。有幾個(gè)步驟可以幫助找出合理有效并適合團(tuán)隊(duì)的方法。
一、對有效性進(jìn)行定義和評價(jià)
完全量化管理可能做不到，但“半年后，我們希望能每月發(fā)一個(gè)可交付版本”或“把總體測試時(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)來作為“路標(biāo)”。比如，假設(shè)某團(tuán)隊(duì)經(jīng)常處于“很多活都在干，但沒有一個(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í)開工的工作量
不超過2N-1個(gè)”）
……
第N個(gè)月：當(dāng)月計(jì)劃功能交付比例達(dá)到80%
在這個(gè)例子當(dāng)中可以看到，如果一上來就直接設(shè)定“當(dāng)月計(jì)劃功能交付比例達(dá)到50%”之類的度量數(shù)據(jù)，可能不但很難達(dá)到，甚至可能由于沒有看板管理而不能度量。
三、同時(shí)選擇超過一個(gè)團(tuán)隊(duì)進(jìn)行試點(diǎn)
敏捷開發(fā)的試點(diǎn)過程千變?nèi)f化，如果只找一個(gè)團(tuán)隊(duì)試點(diǎn)會有問題。如果失敗了，大家會以為敏捷不行；如果成功了，大家會照搬經(jīng)驗(yàn)。
所以最好的方法是讓若干個(gè)團(tuán)隊(duì)各自基于自己的目標(biāo)進(jìn)行試點(diǎn)，如果其中有多個(gè)取得成功，大家會意識到原來成功的方法有很多種，就能靈活應(yīng)用在自己團(tuán)隊(duì)中進(jìn)行實(shí)驗(yàn)和推廣了。
四、需要對“商業(yè)目標(biāo)”與“一線實(shí)踐”有很深入的理解
做到這一點(diǎn)非常困難，然而偏偏這一點(diǎn)又是成敗的關(guān)鍵。
經(jīng)常見到很多團(tuán)隊(duì)或成員一擁而上開始試點(diǎn)某個(gè)局部實(shí)踐，有時(shí)候是Scrum中的撲克牌估算或每日立會，有時(shí)候是XP中的自動(dòng)化測試或結(jié)對編程。但做了一段時(shí)間，由于沒有目標(biāo)，尤其是沒有那些讓團(tuán)隊(duì)聽了之后就不會放棄的目標(biāo)，很快就堅(jiān)持不下去了。
要培養(yǎng)商業(yè)目標(biāo)意識很難，甚至很多從業(yè)之前沒有做過高級管理職位的敏捷培訓(xùn)師或咨詢師都不具備，更不用說普通一線工作人員了。一種做法是讓高層比如部門經(jīng)理來宏觀協(xié)調(diào)敏捷的實(shí)施，而不要完全自下而上。高層經(jīng)理的職業(yè)特性保證了他們會潛移默化地關(guān)心最終實(shí)施的效果勝過實(shí)踐本身。說起來，“效果勝過實(shí)踐”本身就是敏捷宣言中“可工作軟件勝過繁雜文檔”的現(xiàn)實(shí)體現(xiàn)。
五、要注意敏捷開發(fā)的生態(tài)系統(tǒng)問題
剛才提到嘗試個(gè)別實(shí)踐經(jīng)常失敗，一個(gè)原因是因?yàn)槿鄙倌繕?biāo)只關(guān)注實(shí)踐，另外一個(gè)則是忽略了與此實(shí)踐相關(guān)的生態(tài)系統(tǒng)。
比如每日立會，看起來非常簡單，但實(shí)踐起來困難重重。比如為什么我要告訴別人我的進(jìn)度？為什么我要告訴別人我遇到的困難？誰因?yàn)槭裁丛驎峁椭?？……這些潛在的問題，都需要相應(yīng)的團(tuán)隊(duì)模型來解決。敏捷開發(fā)生態(tài)系統(tǒng)就是用來描述各種活動(dòng)之間的關(guān)系的，這個(gè)在我的“敏捷開發(fā)生態(tài)系統(tǒng)”系列博客中有較為詳細(xì)的描述。
#p#
記者：敏捷過程中有一個(gè)我認(rèn)為最重要的部分是需求拆分，您能談?wù)勅绾芜M(jìn)行合理的拆分嗎？
陳勇：需求拆分是個(gè)業(yè)界難題，在敏捷開發(fā)領(lǐng)域是如此。盡管每個(gè)敏捷流派對這個(gè)問題說起來都頭頭是道，但是要說誰有一個(gè)過目不忘的好方法，還真沒有。
真正解決需求拆分問題的關(guān)鍵有兩個(gè)：拆分后的顆粒度如何控制，拆分后的需求結(jié)構(gòu)如何表達(dá)。前者可能問得比較多，因?yàn)槎鄶?shù)程序員都要關(guān)心；后者只有產(chǎn)品經(jīng)理會關(guān)心，所以顯得不太突出，但對大產(chǎn)品和持續(xù)開發(fā)的產(chǎn)品而言則是個(gè)關(guān)鍵問題。
一、顆粒度問題
這個(gè)問題在敏捷框架下基本無解。
但在功能點(diǎn)分析（Function Point Analysis）中是一個(gè)基本概念。FPA通過對軟件中的“業(yè)務(wù)數(shù)據(jù)”以及對其進(jìn)行的“業(yè)務(wù)操作”為基本單元建立了顆粒度的概念，進(jìn)而建立了規(guī)模的概念。這些概念的應(yīng)用成熟度、推廣程度、數(shù)據(jù)積累量（公開的在10000個(gè)左右，在咨詢公司手中但非公開的在50000個(gè)左右，實(shí)際使用量不可估量）都遠(yuǎn)遠(yuǎn)超過敏捷開發(fā)或其他體系提出的方法，包括“故事點(diǎn)”。而且“業(yè)務(wù)操作”的概念非常接近用戶故事，也包括如減少依賴、完整交付客戶價(jià)值等描述。
下面舉一個(gè)例子來看功能點(diǎn)到底是什么。這里將略去功能點(diǎn)中對數(shù)據(jù)、操作的復(fù)雜細(xì)節(jié)分析過程，而只說大概。
假設(shè)在一個(gè)OA系統(tǒng)中需要管理“用戶”“角色”“權(quán)限”這三種業(yè)務(wù)數(shù)據(jù)，那么他們就是業(yè)務(wù)數(shù)據(jù)；而對他們分別進(jìn)行的“增刪改查”就是業(yè)務(wù)操作。比如“新建用戶”“列出所有用戶”都是業(yè)務(wù)操作。“業(yè)務(wù)”這個(gè)詞在這里是相對于“技術(shù)”而言的，比如“新建用戶”對客戶而言是一個(gè)容易理解、認(rèn)可的操作，而且客戶管理員會告訴我們：
“是的，我現(xiàn)在每天都在新建用戶，因?yàn)樽罱谡腥恕倍粫f“是的，我最近每天都在數(shù)據(jù)庫表中新建記錄，還會同步更新聯(lián)系人數(shù)據(jù)表，因?yàn)樽罱谡腥恕?，雖然后者也的確發(fā)生了，但卻不是客戶日常工作的內(nèi)容。
更神奇的是，“新建用戶”這個(gè)操作，在無法獲得更多細(xì)節(jié)的情況下，可以假設(shè)工作量為4人天（在OA系統(tǒng)中，其他系統(tǒng)有調(diào)整因子）；而統(tǒng)計(jì)還表明，“用戶”及所有與之相關(guān)的操作如剛才說的“新建用戶”以及其他“刪除用戶”“列出所有用戶”“編輯用戶”……的總工作量（從需求到部署）大約是40人天，也就是2個(gè)人月，即使暫時(shí)不能確定到底有多少個(gè)操作。而“用戶”“角色”“權(quán)限”及其所有操作完成的工作量自然就是大約6人月。盡管每個(gè)數(shù)據(jù)或操作的時(shí)間可能會有出入，但總體規(guī)模則誤差不大。
這得益于大數(shù)定理及眾多統(tǒng)計(jì)數(shù)據(jù)的分析結(jié)果。本段內(nèi)容的詳情可在Google查詢“nesma”（一個(gè)總部在荷蘭的世界第二大功能點(diǎn)組織），這個(gè)簡化體系稱為“Indicative Function Point”（指示性的功能點(diǎn)），在其網(wǎng)站上有荷蘭語和英語介紹。
如果對用戶故事的定義（而非“業(yè)務(wù)操作”的定義，因?yàn)楹笳吒晟?、?yán)格）略作約束，則可以迅速與功能點(diǎn)中的“業(yè)務(wù)操作”兼容。兼容的結(jié)果有兩個(gè)，首先是很容易把握顆粒度，其次是功能點(diǎn)與工作量的比例關(guān)系極佳，可以迅速推知工作量。
二、需求結(jié)構(gòu)問題
在敏捷開發(fā)中有一個(gè)不完善的答案：Product Backlog 和 Sprint Backlog。前者是整個(gè)產(chǎn)品的待開發(fā)項(xiàng)，后者是當(dāng)前迭代的待開發(fā)項(xiàng)，兩者內(nèi)部都按優(yōu)先級進(jìn)行排序。
這個(gè)答案對項(xiàng)目經(jīng)理（可以模糊理解為Scrum Master）和開發(fā)人員足夠用了，因?yàn)樗麄冎饕P(guān)心時(shí)間上的開發(fā)問題，也就是現(xiàn)在讓我做什么，什么時(shí)候要的問題。但對產(chǎn)品經(jīng)理（可以模糊理解為Product Owner）而言，時(shí)間是一個(gè)維度，空間則是另外一個(gè)維度。
所謂空間維度，就是系統(tǒng)-子系統(tǒng)-模塊-大需求-小需求……之間的關(guān)系問題，這完全不是一個(gè)一維表格能解決的。由于敏捷開發(fā)主要是一線開發(fā)人員和項(xiàng)目經(jīng)理發(fā)明并推動(dòng)的，所以空間維度一直被忽略。但這是需求分解過程中一個(gè)繞不過去的問題，因?yàn)槿藗儾豢赡苊鎸σ粋€(gè)一個(gè)一維表格回答這個(gè)問題：“我們所有的功能都包括在這里呢嗎？哪部分還略顯粗糙希望繼續(xù)分解？這些大需求包含哪些小需求？”
在UML中的答案比較完善，“用戶 - Use Case”（人-功能）很好地把一批相關(guān)的功能聯(lián)系起來。雖然只是非常簡單的表達(dá)，但比把幾個(gè)毫無關(guān)聯(lián)的故事按優(yōu)先級排在一起，或把幾個(gè)密切相關(guān)的故事相隔十萬八千里放置還是進(jìn)步不少。UML中的模塊則是一個(gè)更宏觀的需求“目錄”。
FPA雖然沒有需求關(guān)系表達(dá)，但如果把“業(yè)務(wù)數(shù)據(jù) - 業(yè)務(wù)操作”作為一個(gè)樹形結(jié)構(gòu)，很類似把UML中的“實(shí)體 – Use Case”作為一個(gè)樹，形成“數(shù)據(jù)-功能”的關(guān)系。不過，這個(gè)體系沒有提供更宏觀尺度上的需求結(jié)構(gòu)問題。
由于功能點(diǎn)、UML中的模塊用例等概念都是有嚴(yán)格、確定化的定義的，所以分解的過程井然有序，很少出現(xiàn)“這個(gè)還要繼續(xù)分嗎？”“這樣分是不是顆粒度太粗糙”之類的問題。我們自己正在做的項(xiàng)目需求就是借用FPA的業(yè)務(wù)數(shù)據(jù)-業(yè)務(wù)操作作為主要分解關(guān)系，上面再加上我們自己定義的子系統(tǒng)-模塊兩個(gè)級別形成了一個(gè)“故事樹”。這個(gè)故事樹比我之前所做過及所見過的任何其他方法表達(dá)的需求結(jié)構(gòu)更為清晰。因此敏捷開發(fā)應(yīng)該吸取或者配合這些方法，至少是其中的一部分思想來完成需求分解。
很多時(shí)候我們會覺得引入較為嚴(yán)格的定義會“有限制太難做”，但其實(shí)更難做的是“無規(guī)則無限制”下自由發(fā)揮。
記者：敏捷開發(fā)中需求拆分之后，任務(wù)應(yīng)該怎樣分工？
陳勇：即使都是使用敏捷開發(fā)，任務(wù)拆分和分工的方法也會因行業(yè)、產(chǎn)品的特點(diǎn)而有所不同。
在純軟件或技術(shù)相對單一的產(chǎn)品中，需求拆解到4天左右（也就是前面提到的“一個(gè)業(yè)務(wù)操作”的規(guī)模）就可以分下去或領(lǐng)取了，因?yàn)槿藗儽容^容易估算4天左右的工作量，也容易跟蹤。在這種情況下，如果一個(gè)人同時(shí)負(fù)責(zé)幾個(gè)“業(yè)務(wù)操作”，應(yīng)該分解為多個(gè)任務(wù)來完成，而不是一個(gè)。因?yàn)檫@些業(yè)務(wù)操作可以獨(dú)立完成并交付，合在一起不但不能持續(xù)交付，也會使得進(jìn)展不透明。但再進(jìn)一步劃分沒有必要，因?yàn)樵賱澐志筒荒塥?dú)立交付了?！蔼?dú)立性”是FPA中對業(yè)務(wù)操作的一個(gè)約束條件，如果按照FPA的概念來劃分任務(wù)，會自動(dòng)滿足獨(dú)立性。
在復(fù)雜環(huán)境比如嵌入式研發(fā)（涉及軟件、硬件、工業(yè)設(shè)計(jì)團(tuán)隊(duì)）或游戲（涉及軟件、美術(shù)、腳本、策劃團(tuán)隊(duì)），需求不能直接當(dāng)作任務(wù)分下去，需要做進(jìn)一步的分解。這里的分解目的是把不同工種的活分配下去，對其跟蹤的過程則可增進(jìn)各部門配合時(shí)所需的透明度。
也有一些團(tuán)隊(duì)喜歡把任務(wù)分解到短至1～2小時(shí)的時(shí)間。本人沒有與這樣的團(tuán)隊(duì)進(jìn)行深入探討以了解其這樣做的動(dòng)機(jī)及收益是什么，但要注意“更小的任務(wù)”不等于更敏捷。我們經(jīng)常說敏捷開發(fā)有利于項(xiàng)目透明，但要知道透明的主體是“項(xiàng)目外部的人”，比如產(chǎn)品經(jīng)理、高層領(lǐng)導(dǎo)；而開發(fā)人員本人，或者小團(tuán)隊(duì)的若干個(gè)人之間，任務(wù)和進(jìn)度本來就是透明或半透明的。因此把詳細(xì)技術(shù)細(xì)節(jié)翻個(gè)底朝天并貼在白板上很可能不但于事無補(bǔ)反而添亂，不如把有限的管理時(shí)間用在“對外表達(dá)需求的完成情況”或“各部門的進(jìn)展及需要什么相互配合”上，也就是我們之前說的兩種情況。
總之，對任務(wù)的分解應(yīng)該本著“需要”與“必要”的原則。不能因?yàn)橄搿案艚荨倍捎谩案〉娜蝿?wù)”。
記者：Sprint會議是實(shí)踐scrum中最重要的事件。您認(rèn)為Scrum會議在團(tuán)隊(duì)中應(yīng)如何進(jìn)行的？
陳勇：要做好計(jì)劃會，應(yīng)該先建好團(tuán)隊(duì)模型。
計(jì)劃會是少有的團(tuán)隊(duì)齊集一堂進(jìn)行的活動(dòng)，無論團(tuán)隊(duì)模型是怎樣的，都應(yīng)該有助于大家以集體的力量完成計(jì)劃，并完成計(jì)劃的任務(wù)。
因此，一些看上去很敏捷的團(tuán)隊(duì)模型或做事方法，很可能是很難鼓勵(lì)大家做到這一點(diǎn)的。比如：所有隊(duì)員都是平等的；大家在會上投票取平均值作為估算結(jié)果（還有一種做法：會上不需要估算，會后領(lǐng)取的人自己說了算）；會后大家主動(dòng)領(lǐng)取任務(wù)；領(lǐng)取的任務(wù)大家互相不干涉，自己愿意怎么做就怎么做……這里邊存在什么問題呢？
第一，“所有隊(duì)員平等”的團(tuán)隊(duì)互助的動(dòng)力從哪里來？人們一定會說：都是在一起工作的同事，怎么會沒有互助動(dòng)力？我們曾經(jīng)在一個(gè)團(tuán)隊(duì)實(shí)施代碼審查，而且是我之前多次提到的那個(gè)最好的139團(tuán)隊(duì)，很快發(fā)生一次事故：一大段4000多行但包含4000多個(gè)常數(shù)的爛代碼逃過了檢查者的眼睛進(jìn)入了代碼庫，并最后引發(fā)客戶現(xiàn)場的Bug。當(dāng)詢問代碼審查者為何讓明顯存在問題的代碼通過檢查？代碼審查者很無奈地說：“我剛來不久，雖然我覺得這些代碼有問題，但我感覺大家都說他（編寫者）是個(gè)高手，我也就不想說什么了。其實(shí)我本人也覺得這些代碼有問題”。這件事情促使我們后來形成了139團(tuán)隊(duì)，就是形成層次團(tuán)隊(duì)，由師傅來審核徒弟的代碼，出問題師傅負(fù)責(zé)。這不是說所有團(tuán)隊(duì)一定要如此，而是說不能簡單地把互助建立在“雷鋒精神”上面。
第二，集體估算的目的何在？很多人認(rèn)為是領(lǐng)導(dǎo)放權(quán)發(fā)揚(yáng)民主，所以投票+平均值就體現(xiàn)了這一點(diǎn)。但如果一個(gè)人估10人天，另一個(gè)人估計(jì)1人天，結(jié)果到底是多少呢？總不能真的是5.5人天吧？所以估算的目的其實(shí)是想知道有沒有更快的方法，有沒有人在走彎路……如果為期一天的計(jì)劃會耗費(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ì)中，師傅不會取值（20+0.5）/2，而是通過與徒弟討論，讓徒弟學(xué)會如何用0.5人天來完成這個(gè)任務(wù)，因?yàn)橥降芾速M(fèi)的時(shí)間最后要算在整個(gè)師徒小組身上。如果不是139團(tuán)隊(duì)，也要找到類似的人們參與爭論和堅(jiān)持自己正確見解的動(dòng)力。
第三，剩下的“主動(dòng)領(lǐng)取任務(wù)”、“互不干涉”等，也要進(jìn)行相似的分析，不能因?yàn)椤翱瓷先ズ茏杂珊苊艚荨本筒杉{。提出這些實(shí)踐的團(tuán)隊(duì)可能與我們所處的情況差別很大，未必能拿來就用。我曾經(jīng)用過“自由領(lǐng)取任務(wù)”，那是在10年前的一個(gè)假期里邊，我邀請自己關(guān)系很近的兩個(gè)老部下來幫忙做一個(gè)軟件；一些零散任務(wù)就被單獨(dú)拿出來，誰先做完手頭工作就自由領(lǐng)取，其中一個(gè)人領(lǐng)取了8個(gè)中的5個(gè)之多。但在之后的每一個(gè)項(xiàng)目中，我都會先想一想，團(tuán)隊(duì)是否允許我再次采用這個(gè)實(shí)踐。
團(tuán)隊(duì)模型理順了，計(jì)劃會所需的共同計(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的形成過程、評審會大部分，可以理解為需求管理內(nèi)容，包括需求開發(fā)，分解，描述，排序以及進(jìn)展跟蹤的過程。而估算、每日立會、燃盡圖等內(nèi)容則屬于項(xiàng)目管理。
XP則主要是技術(shù)管理問題，不過其結(jié)構(gòu)不明確，不好分類。
這個(gè)差別也可以解釋Scrum為何易于推廣：因?yàn)槠湔麄€(gè)體系很清晰。比如在我的培訓(xùn)課程中有一個(gè)貫穿始終的練習(xí)，用三個(gè)需求的描述、分解和估算過程來演練Scrum。這個(gè)練習(xí)能從第一天上午10：00左右開始，斷斷續(xù)續(xù)穿插于培訓(xùn)中，一直持續(xù)到第二天中午；要用一個(gè)練習(xí)把所有或者只是大部分的XP實(shí)踐串聯(lián)起來則幾乎是不可能的。另外Scrum宣貫起來也不需要大的技術(shù)革命，主要是人員職責(zé)的重新描述，部分管理活動(dòng)如計(jì)劃、跟蹤的引進(jìn)，因此門檻很低。不過反過來，由于缺少實(shí)際的技術(shù)改進(jìn)，若只得其皮毛而沒有利用團(tuán)隊(duì)、過程的變化來真正促進(jìn)開發(fā)，那么Scrum失敗的概率也很高。
Scrum在商業(yè)運(yùn)作上也更成功。這應(yīng)該歸功于Scrum的發(fā)明者是項(xiàng)目經(jīng)理或更高級別的人員，而XP則主要是一線員工，甚至說是Geek們不為過。Scrum推出了認(rèn)證的Scrum Master和Product Owner兩種認(rèn)證，由于體系相對完整，認(rèn)證課程目標(biāo)聽眾的收入也相對較高，所以推廣起來比較容易；多數(shù)咨詢師更容易理解Scrum的理念而非XP的，也使之得以快速推廣。
不過長遠(yuǎn)看來，團(tuán)隊(duì)，過程，技術(shù)三者密不可分。Scrum覆蓋了前兩者中的一部分，但如果沒有持續(xù)集成、自動(dòng)化測試等方法的支撐，迭代交付將很難完成。所以，未來應(yīng)該會有并存的需要，即使不再以當(dāng)前的兩個(gè)名字存在。
#p#
記者：拙劣的度量指標(biāo)會產(chǎn)生嚴(yán)重的后果，敏捷度量指標(biāo)也是一個(gè)很有爭議的問題，以您的經(jīng)驗(yàn)如何去解決這個(gè)問題？
陳勇：有多個(gè)層次的指標(biāo)可供衡量，下面從基層到高層一層層剖析一下。
一、基層度量
對最基層活動(dòng)而言，一般所有度量均不用于個(gè)體考核，而只是用于改進(jìn)。比如個(gè)體的缺陷率、工作完成量、按時(shí)完成率等。
之所以這樣做，原因是不希望面向個(gè)體的考核破壞了團(tuán)隊(duì)中原本用來提高生產(chǎn)率的團(tuán)隊(duì)協(xié)作。團(tuán)隊(duì)協(xié)作可以消除個(gè)體錯(cuò)誤，通過共同估算讓高手的技能流向新手，等等。如果個(gè)體考核讓人心有掛念，會產(chǎn)生問題。
不過一個(gè)不可回避的問題是：不管你們敏捷開發(fā)怎么說，但財(cái)務(wù)終究要把績效獎(jiǎng)金（假如有）發(fā)放到個(gè)體而非團(tuán)隊(duì)的賬戶上，怎么知道誰應(yīng)該發(fā)多少呢？在一個(gè)10個(gè)隊(duì)員且關(guān)系互相平行的團(tuán)隊(duì)里邊，的確沒有辦法知道，因此也不得不面向個(gè)體考核，并最終不可避免地毀掉團(tuán)隊(duì)協(xié)作。
但在一個(gè)139團(tuán)隊(duì)里邊，答案比較簡單。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ì)量；師傅會選擇關(guān)鍵時(shí)間點(diǎn)與徒弟碰頭，以便用最少時(shí)間解決最大的問題（這種活動(dòng)稱之為“松結(jié)對編程”，在我的“敏捷開發(fā)松結(jié)對編程系列”中有詳細(xì)描述）；師傅對徒弟的代碼進(jìn)行代碼審查；平時(shí)徒弟有問題會師傅。在這樣一個(gè)團(tuán)隊(duì)中，項(xiàng)目經(jīng)理收入最高，師傅次之，徒弟最低。薪水相對固定，如果位置沒有變化，無論自己一個(gè)人多編碼了還是幫別人太多導(dǎo)致少編碼了，都差不多。因此要想拿到高薪，不是在短期內(nèi)多編寫幾行代碼或關(guān)閉幾個(gè)Bug，而是看長期：新人先要達(dá)到獨(dú)立工作能力，然后幫助團(tuán)隊(duì)擴(kuò)張也就是自己帶徒弟成為師傅，最后成為可以獨(dú)自擔(dān)當(dāng)一種業(yè)務(wù)的人也就是項(xiàng)目經(jīng)理。在這種團(tuán)隊(duì)中，人的收入增長不是通過內(nèi)部競爭，而是通過內(nèi)部協(xié)作做到的。
因此它是一種兼容敏捷團(tuán)隊(duì)精神的個(gè)體績效考核方法。
二、外部度量
正如前面所說，外部度量是為了讓團(tuán)隊(duì)對外透明而做的度量。有這樣幾個(gè)原則：只做外部看得懂的度量；只做外部有人看的度量；盡量少做度量。
典型的外部度量是給PO也就是產(chǎn)品經(jīng)理所作的用戶故事的完成情況的度量，比如白板上處于完成狀態(tài)的故事的數(shù)量。這里說故事而非任務(wù)，是因?yàn)閷Ξa(chǎn)品經(jīng)理而言，任務(wù)完成沒有意義。
生產(chǎn)率也經(jīng)常是一個(gè)被度量的內(nèi)容，但現(xiàn)在尚無好的方法。有些團(tuán)隊(duì)經(jīng)常使用“故事點(diǎn)”來做度量，方法是：先挑選一些以往的故事作為典型故事；為每個(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)榇蠹覍Φ湫凸适碌氖煜こ潭炔顒e很大，典型故事也很難選擇，導(dǎo)致實(shí)際使用的人很少。另外一個(gè)問題是不同項(xiàng)目的典型故事和點(diǎn)數(shù)是不通用的，因此無法做比較。好不容易做了一個(gè)想對外發(fā)布的生產(chǎn)率，卻無法橫向比較只能自娛自樂，顯然存在問題。未來，這個(gè)問題可能會被功能點(diǎn)生產(chǎn)率解決，但現(xiàn)在還沒有看到有人嘗試。我們自己做了一些宏觀嘗試，但沒有每個(gè)迭代都做。
此外還有一些度量，但取決于實(shí)際的需要。比如在線運(yùn)行的網(wǎng)絡(luò)游戲，會度量迭代交付周期長度（直接影響響應(yīng)時(shí)間，因此一般越短越好）。這些度量不全是明確量化的，但公司上下都能說出一個(gè)大致的數(shù)字來，因此也算是度量。
三、業(yè)務(wù)運(yùn)營與收入度量
既然敏捷開發(fā)說是“交付客戶價(jià)值”而非文檔或代碼的，那么一定能改善營收或其他運(yùn)營指標(biāo)。
比如市場占有率，每日點(diǎn)擊數(shù)，平均在線人數(shù)，每活躍用戶收入……等等，這些營收應(yīng)該都是做敏捷度量的人所需要關(guān)注的。Scrum設(shè)置了PO來收集、描述、排序最重要的需求，又安排團(tuán)隊(duì)在自組織下高速生產(chǎn)出來，通過評審會后交付給客戶。因此如果這一切都是真的，沒有理由在實(shí)現(xiàn)敏捷開發(fā)后業(yè)務(wù)營收不變或下滑。當(dāng)然可能很多因素制約了企業(yè)的營收情況，但如果既不度量也不關(guān)心，直接來一句“由于情況很復(fù)雜，因此企業(yè)營收與研發(fā)沒有直接關(guān)系”，顯然只能被作為自我否定和消極逃避的借口。
現(xiàn)在有些團(tuán)隊(duì)如網(wǎng)絡(luò)游戲和搜索引擎公司，已經(jīng)把這些數(shù)據(jù)引入了開發(fā)團(tuán)隊(duì)的度量中。但一般不做績效考核，而是讓大家知道最近我們的研發(fā)在市場上的實(shí)際反饋如何。
四、內(nèi)部創(chuàng)業(yè)
任何時(shí)候想度量的時(shí)候都要問：為什么要度量？答案是：度量的目的是為了改善目標(biāo)。
那么如果說企業(yè)的終極目標(biāo)是盈利，而卻有一種方法不需要度量就能提升盈利，那么應(yīng)該怎樣？當(dāng)然就不用度量了！目標(biāo)永遠(yuǎn)比方法要重要。
比如現(xiàn)在網(wǎng)絡(luò)游戲團(tuán)隊(duì)普遍有一個(gè)政策：20%的營收歸項(xiàng)目作為獎(jiǎng)金。一般這個(gè)數(shù)字從幾十萬到上億的規(guī)模，而團(tuán)隊(duì)往往不到100人。他們不在通過繁雜的績效考核系統(tǒng)中的度量項(xiàng)發(fā)放獎(jiǎng)金，而直接把收入變成開發(fā)人員的動(dòng)力。這種方法跳過了所有繁瑣的度量過程，直擊問題實(shí)質(zhì)，是一種不度量而改善目標(biāo)的典范，可以理解為敏捷開發(fā)“可運(yùn)行軟件超過繁瑣文檔”這種嘗試弱化中間過程的思想的產(chǎn)物。
當(dāng)然，即使不能“內(nèi)部創(chuàng)業(yè)”，也一樣能做到類似的效果。比如降低程序員的基本工資，代之以把公司產(chǎn)品銷售的一部分錢拿來做獎(jiǎng)金。程序員自然就開始關(guān)心客戶需求，嘗試?yán)斫饪蛻舻降滓裁床灰裁?，嘗試自覺改善質(zhì)量防止客戶流失，嘗試自己帶徒弟以便讓團(tuán)隊(duì)成長進(jìn)而增加產(chǎn)品競爭力……很多效果是通過度量都難以進(jìn)行改善的。
最后這個(gè)問題的答案，其實(shí)回到了問題的本質(zhì)：敏捷開發(fā)提出的目的，其實(shí)還不是敏捷宣言中的那四句話左側(cè)的部分（個(gè)體與交互，可運(yùn)行軟件，客戶協(xié)作，響應(yīng)變化），而是通過這四點(diǎn)來幫助企業(yè)提高營收。因此，敏捷開發(fā)的度量，換言之敏捷開發(fā)要改善的地方，不能只是一線工程實(shí)踐，而應(yīng)該是“客戶價(jià)值”的改善，也就是營收的增加。否則敏捷開發(fā)就可能長期處于基層游擊隊(duì)活動(dòng)，在敏捷熱潮過去之后，被證明又是一個(gè)重過程不重結(jié)果的空架子而已。
記者：您是否能談?wù)勗陧?xiàng)目中，敏捷測試人員的職責(zé)和技能要求？
陳勇：關(guān)于這個(gè)問題，有趣的是：“測試活動(dòng)”比“測試人員”在敏捷開發(fā)中出現(xiàn)的頻率更高。原因就是敏捷開發(fā)中提倡跨職能，也就是所有人都對開發(fā)、測試負(fù)責(zé)，從測試活動(dòng)的目標(biāo)的轉(zhuǎn)變上就能看出來。
傳統(tǒng)認(rèn)為，測試人員是幫開發(fā)人員找Bug的，這是個(gè)誤區(qū)。其實(shí)，開發(fā)人員才是負(fù)責(zé)找Bug的，尤其是自己找自己的Bug。打個(gè)比方，如果我們在自己家里忘了鑰匙放在哪里了，一定不會把家里翻個(gè)底朝天，而是會嘗試找自己以前習(xí)慣放鑰匙的地方；但如果讓一個(gè)客人來找，就不那么容易了，因?yàn)榭腿瞬皇煜ぜ彝キh(huán)境，也不熟悉我們放鑰匙的習(xí)慣。家庭環(huán)境就是軟件，而鑰匙就是Bug，測試人員則是一個(gè)不太熟悉家庭環(huán)境的客人，開發(fā)人員才是那個(gè)放鑰匙的人，盡管他暫時(shí)“忘了放在哪里了”。而且長期而言，只有開發(fā)人員才能改變自己的習(xí)慣，比如在墻上釘個(gè)釘子，習(xí)慣性地把鑰匙掛在上面。我們在一個(gè)項(xiàng)目中密集實(shí)踐過代碼審查活動(dòng)，在短短27天時(shí)間里，通過每天花費(fèi)半小時(shí)觀察、記錄、分析自己的缺陷，個(gè)體缺陷率降低了一半之多。而且好的習(xí)慣和規(guī)范一旦固化下來，以后無需花費(fèi)額外時(shí)間也能在一定程度上保證代碼質(zhì)量，可謂一勞永逸。
找bug的活被搶走了，傳統(tǒng)測試人員怎么辦？有兩種出路，或者說“職業(yè)生涯規(guī)劃”，都比原來傳統(tǒng)測試人員更有前景。
一、有開發(fā)經(jīng)驗(yàn)的測試人員應(yīng)該轉(zhuǎn)向“開發(fā)測試”
“開發(fā)測試”是游戲領(lǐng)域的一種工種，對應(yīng)的是完全不需要對開發(fā)有了解的“黑盒測試”，我們可以把它的定義擴(kuò)展一下用在這里。開發(fā)測試在開發(fā)活動(dòng)中主要負(fù)責(zé)自動(dòng)化測試、持續(xù)集成、回歸測試等用于快速保證產(chǎn)品質(zhì)量的活動(dòng)。
為什么叫“快速保證產(chǎn)品質(zhì)量”而不是“發(fā)現(xiàn)Bug”呢？因?yàn)殚_發(fā)測試程序的人其實(shí)不應(yīng)該是這里的開發(fā)測試，而是開發(fā)某個(gè)功能的開發(fā)人員本身。正如之前所說，具體的功能開發(fā)者更清楚功能是什么，可能有哪些潛在的問題，如何驗(yàn)證最好……所以開發(fā)并第一次執(zhí)行（為發(fā)現(xiàn)缺陷而執(zhí)行）的是開發(fā)人員；但如何讓眾多測試用例自動(dòng)地全部或有選擇地再次運(yùn)行，如何保證更高的運(yùn)行效率、如何準(zhǔn)備自動(dòng)集成環(huán)境，則是開發(fā)測試人員的工作。
如果有可能，個(gè)人感覺最好不要設(shè)置全職的開發(fā)測試，而是視實(shí)際情況由不同的開發(fā)人員兼任。這樣更容易平衡工作量、保證開發(fā)與測試的銜接有效性。
整體上這個(gè)出路偏向開發(fā)人員多一些。
二、“沒有開發(fā)經(jīng)驗(yàn)”的測試人員應(yīng)該轉(zhuǎn)向“產(chǎn)品經(jīng)理”或“專業(yè)測試人員”產(chǎn)品經(jīng)理不說了，因?yàn)槌雎泛苷?。這里說說專業(yè)測試人員。
有很多時(shí)候我們覺得原來的測試人員不就是“專業(yè)測試人員”嗎？其實(shí)不然。很多測試人員不過是看看說明書，點(diǎn)點(diǎn)鼠標(biāo)，填填Bug而已，很難說上“專業(yè)“二字。
個(gè)人感覺對測試人員而言，“專業(yè)”有兩重含義。第一，對所在領(lǐng)域的質(zhì)量問題和解決方法有深入理解。比如特定的軟件，可用率是首位的（比如網(wǎng)站，允許癱瘓但不能總癱瘓）還是故障率是首位的（比如飛機(jī)，不允許故障）。Windows經(jīng)常死機(jī)，但是恢復(fù)速度很快，用起來也很簡單，這在家用軟件中就是可接受的“高質(zhì)量”標(biāo)準(zhǔn)；但用作服務(wù)器，可能就有點(diǎn)問題。如果不理解這些就開始測試，結(jié)果肯定是事倍功半。第二，對測試方法論應(yīng)該有深入理解。軟件仿真，持續(xù)集成，灰度發(fā)布……這些都可以稱為測試方法論或質(zhì)量方法論?！皩I(yè)測試人員”用這些方法論指導(dǎo)前面說的“開發(fā)測試人員”進(jìn)行測試，是一種很好的工作方式。
我曾經(jīng)在松結(jié)對編程與139團(tuán)隊(duì)系列博客中多次提到一個(gè)23個(gè)開發(fā)人員加2個(gè)測試人員的團(tuán)隊(duì)，其中兩個(gè)測試人員就是專業(yè)測試人員。尤其是其中的測試經(jīng)理，會定期基于業(yè)務(wù)的需要向我們提出測試要求，而我們則幫她編碼實(shí)現(xiàn)。這種搭配方式最終促成了產(chǎn)品的高質(zhì)量，它現(xiàn)在正運(yùn)行在國內(nèi)60%以上的數(shù)字電視臺。
這里的“沒有開發(fā)經(jīng)驗(yàn)”被打上了引號，是因?yàn)槲覠o數(shù)次聽到有人說“我沒有開發(fā)經(jīng)驗(yàn)，也不懂開發(fā)”，但這個(gè)人可能是與開發(fā)人員共事很多年的資深測試人員。其實(shí)，與相對論相比，開發(fā)更像是外語，就是外國乞丐學(xué)多了也能學(xué)會的東西。因此實(shí)在不能用技術(shù)壁壘作為借口，要做好可能很難，但要了解的確不難。要做好測試這個(gè)工作，不去側(cè)面了解和理解開發(fā)，是很不現(xiàn)實(shí)的。
記者： 在敏捷實(shí)踐的過程中是否一定要使用一些敏捷工具？能否推薦一些您認(rèn)為比較好的工具？
陳勇：因?yàn)槲易约阂苍陂_發(fā)一個(gè)敏捷工具“火星人”，所以就不直接推薦工具了，呵呵。不過下面可以介紹一下一些一般原則：
一、一定要選擇適合自己行業(yè)領(lǐng)域的產(chǎn)品
有些產(chǎn)品可能是為大型制造業(yè)、銀行、電信等開發(fā)設(shè)計(jì)的，那么盡管也叫“敏捷開發(fā)”產(chǎn)品，但里邊會帶有很多大型產(chǎn)品設(shè)計(jì)中所需的元素，比如UML，Portfolio Management（可以理解為大團(tuán)隊(duì)或多團(tuán)隊(duì)的管理）等內(nèi)容。這并非像有人說的他們在“掛羊頭賣狗肉”，而是在特殊行業(yè)實(shí)施敏捷所必需的適應(yīng)。反之，簡單的電子白板工具往往反而不適合在這些行業(yè)應(yīng)用。
通過翻閱供應(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ì)劃被訪問的次數(shù)和必要性會迅速下降。
而對于需求管理、缺陷管理等產(chǎn)品，尤其是前者，則需要慎重選型。視行業(yè)的不同，這些產(chǎn)品可能需要考慮到未來3～5年乃至更長的數(shù)據(jù)保存問題，所以需要慎重一些。另外這些產(chǎn)品往往跨多個(gè)職能部門，選型時(shí)需要多方同時(shí)協(xié)調(diào)。
三、未必一個(gè)公司只用一個(gè)產(chǎn)品
All In One是每個(gè)公司的夢想，不過卻不現(xiàn)實(shí)。我培訓(xùn)或咨詢過的一些大型電信企業(yè)，其涉獵的領(lǐng)域之廣往往令人驚訝。有家公司在做計(jì)費(fèi)系統(tǒng)、BOSS系統(tǒng)（業(yè)務(wù)和運(yùn)營系統(tǒng)）的同時(shí)，還在做移動(dòng)互聯(lián)網(wǎng)軟件甚至游戲。前兩者對需求遵從性、成本控制的控制是核心，因?yàn)樗鼈兺婕凹滓曳胶贤?；而后者則對創(chuàng)新性要求更高，喜歡“擁抱變化”。
這種情況下管理層應(yīng)該深刻理解不同領(lǐng)域的管理要點(diǎn)。比如甲乙方項(xiàng)目中，“誰在做什么”這類任務(wù)細(xì)節(jié)往往是重要的，因他它能保證所有人都有活干，防止空置資源的浪費(fèi)；對完成功能的多少的掌握也是重要的（最好使用功能點(diǎn)），因?yàn)樗鼙碚鬟M(jìn)度。但在移動(dòng)互聯(lián)網(wǎng)軟件中，“現(xiàn)在我們在做什么”“什么時(shí)候這個(gè)功能能做出來”“這個(gè)功能做出來反饋如何”才是重點(diǎn)。
由此可見，領(lǐng)域要求不同，方法論就會不同，管理工具自然也可能不同。除了一些簡單的白板軟件“都能用”之外，復(fù)雜產(chǎn)品很少能適應(yīng)如此巨大的差異，甚至說也不應(yīng)該適應(yīng)所有領(lǐng)域使用。
在這種復(fù)雜情況下進(jìn)行選型的時(shí)候，領(lǐng)導(dǎo)層或領(lǐng)域?qū)＜覒?yīng)該給出自己對管理的核心需求，然后再放手讓團(tuán)隊(duì)進(jìn)行自由選擇，只要驗(yàn)證核心需求被滿足就可以了。
分享題目：專訪陳勇：深入解讀敏捷在團(tuán)隊(duì)中的實(shí)踐
網(wǎng)址分享：http://m.fisionsoft.com.cn/article/cdehjgi.html
