有人說，實踐敏捷的根本不在于敏捷本身，而在于理解敏捷背后擁抱變化的基因。確實，使用敏捷，那么你就應該知道為何敏捷。如今，國內很多敏捷團隊沒有真正的了解敏捷的精髓，也說明了為什么在使用敏捷的過程中并沒有真正的“敏捷”。所以，不但不能真正的解決傳統開發的一些問題，反而新增加了更多的問題。因此，51CTO記者采訪了具有17年軟件研發、管理咨詢經驗，擅長在實際環境中應用敏捷開發實踐的專家陳勇老師，為網友們解讀敏捷在開發實踐及管理中的一些問題。

[[70475]]

陳勇，17年軟件研發、管理及咨詢經驗，擅長在實際環境中應用敏捷開發實踐。具有豐富的工程技術與項目管理實踐經驗，從其程序員、項目經理、CMMI/FPA功能點估算/敏捷咨詢師、事業部總監、副總經理等各種技術與管理崗位獲得的一手經驗，令其可以站在企業管理者的角度，以更廣的視角來理解敏捷開發，并能配合和推動非研發部門協作推廣敏捷。

工作經歷：

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

以下是采訪內容：

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

陳勇：看看清楚敏捷開發對成本的控制，先要看之前的方法有何問題，比如瀑布模型。

對瀑布模型而言，有兩個地方控制不好成本：

一，瀑布模型中，如果項目簽的需求太多而價格太低，往往在中后期會通過工時統計等發現入不敷出，但由于普通模型這時候正處在編碼末期或測試前期，因此很難就此停下，或刪除某些次要功能繼續開發（因為在晚期刪除功能往往成本很高）。

對這個問題，敏捷開發解決得比較不錯，也很容易實施。漸進式交付使得“隨時”停止開發并進行發布變得可能。

但要注意如果優先級排序不當，也可能會面臨“重要的功能還沒有開發，次要功能卻開發了不少”的尷尬境地。

另一個問題是提前交付可以換回一些款項，但并不能徹底解決成本超支的問題。這時候應該配合類似功能點分析這類的方法來解決。也就是早期用功能點報價；中間如果通過計數發現由于需求蔓延、變更等原因導致需求的總量上升了，那么乙方有權要求追加款項，或刪除某些次要功能。這種聽起來不可思議的想法，在某些國家如芬蘭、澳大利亞都是很普遍的。可能我們會抱怨說甲方不贊同或不理解這種過于“偏技術”方法，但如果連乙方都不贊同不理解，就不能單方面責怪甲方了。2012年底中國剛剛推出了基于功能點的軟件成本估算相關的國標，試點領域是政府軟件開發。雖然現在還沒有對階段性付款提出方案，可以已經可以看出未來的大趨勢一定如此。

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

敏捷開發解決這個問題的方法很簡單：減少早期對需求、設計的投入，盡量早讓產品“可運行”以便讓客戶提出反饋意見。

不過這個方法極其容易被“用過頭”，比如有些團隊可能放棄了必要的需求和設計，導致由于蠻力編碼造成編碼混亂而不斷返工，整個產品則像一個沒有骨架的沙雕一樣難以

做大。

正確的方法是：在漸進式開發、漸進式交付的同時，做漸進式需求和設計。我們要避免的是需求和設計返工，而不是需求和設計活動本身。因此對大中型產品而言，應該保證每個階段的編碼之前都有簡單設計用以保證編碼的正確性；而被客戶確認后的功能至少要“后補”需求和設計，以備未來回溯。這樣既避免蠻力編碼返工，又能避免推翻設計的返工。

記者：做到敏捷開發，每個團隊都要經歷一個轉型期，那么在轉型期還需要每個團隊根據自身的不同，找出合理有效的解決方法。一般如何去處理這個問題？

陳勇：這是培訓和咨詢過程中最常見的一個問題，也是最難回答的。有幾個步驟可以幫助找出合理有效并適合團隊的方法。

一、對有效性進行定義和評價

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

二、階段性檢查和推進目標

前幾個迭代往往離目標很遠，很容易忙了半天才發現走偏了。這時候可以設置某些臨時目標來作為“路標”。比如，假設某團隊經常處于“很多活都在干，但沒有一個干完了，因此也不能交付”的狀態，而幾個月后希望做到“當月計劃功能的交付比例達到80%”，那么可能需要這樣幾個路標（實際工作不只如此）：

第一個月：實現任務的看板管理

第二個月：實現基于故事的看板管理

第三個月：當月計劃功能交付比例達到50%

第四個月：控制在制品數量在2N-1以下（N是團隊人數，此目標即“同時開工的工作量

不超過2N-1個”）

……

第N個月：當月計劃功能交付比例達到80%

在這個例子當中可以看到，如果一上來就直接設定“當月計劃功能交付比例達到50%”之類的度量數據，可能不但很難達到，甚至可能由于沒有看板管理而不能度量。

三、同時選擇超過一個團隊進行試點

敏捷開發的試點過程千變萬化，如果只找一個團隊試點會有問題。如果失敗了，大家會以為敏捷不行；如果成功了，大家會照搬經驗。

所以最好的方法是讓若干個團隊各自基于自己的目標進行試點，如果其中有多個取得成功，大家會意識到原來成功的方法有很多種，就能靈活應用在自己團隊中進行實驗和推廣了。

四、需要對“商業目標”與“一線實踐”有很深入的理解

做到這一點非常困難，然而偏偏這一點又是成敗的關鍵。

經常見到很多團隊或成員一擁而上開始試點某個局部實踐，有時候是Scrum中的撲克牌估算或每日立會，有時候是XP中的自動化測試或結對編程。但做了一段時間，由于沒有目標，尤其是沒有那些讓團隊聽了之后就不會放棄的目標，很快就堅持不下去了。

要培養商業目標意識很難，甚至很多從業之前沒有做過高級管理職位的敏捷培訓師或咨詢師都不具備，更不用說普通一線工作人員了。一種做法是讓高層比如部門經理來宏觀協調敏捷的實施，而不要完全自下而上。高層經理的職業特性保證了他們會潛移默化地關心最終實施的效果勝過實踐本身。說起來，“效果勝過實踐”本身就是敏捷宣言中“可工作軟件勝過繁雜文檔”的現實體現。

五、要注意敏捷開發的生態系統問題

剛才提到嘗試個別實踐經常失敗，一個原因是因為缺少目標只關注實踐，另外一個則是忽略了與此實踐相關的生態系統。

比如每日立會，看起來非常簡單，但實踐起來困難重重。比如為什么我要告訴別人我的進度？為什么我要告訴別人我遇到的困難？誰因為什么原因會提供幫助？……這些潛在的問題，都需要相應的團隊模型來解決。敏捷開發生態系統就是用來描述各種活動之間的關系的，這個在我的“敏捷開發生態系統”系列博客中有較為詳細的描述。

#p#

記者：敏捷過程中有一個我認為最重要的部分是需求拆分，您能談談如何進行合理的拆分嗎？

陳勇：需求拆分是個業界難題，在敏捷開發領域是如此。盡管每個敏捷流派對這個問題說起來都頭頭是道，但是要說誰有一個過目不忘的好方法，還真沒有。

真正解決需求拆分問題的關鍵有兩個：拆分后的顆粒度如何控制，拆分后的需求結構如何表達。前者可能問得比較多，因為多數程序員都要關心；后者只有產品經理會關心，所以顯得不太突出，但對大產品和持續開發的產品而言則是個關鍵問題。

一、顆粒度問題

這個問題在敏捷框架下基本無解。

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

下面舉一個例子來看功能點到底是什么。這里將略去功能點中對數據、操作的復雜細節分析過程，而只說大概。

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

“是的，我現在每天都在新建用戶，因為最近正在招人”而不會說“是的，我最近每天都在數據庫表中新建記錄，還會同步更新聯系人數據表，因為最近正在招人”，雖然后者也的確發生了，但卻不是客戶日常工作的內容。

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

這得益于大數定理及眾多統計數據的分析結果。本段內容的詳情可在Google查詢“nesma”（一個總部在荷蘭的世界第二大功能點組織），這個簡化體系稱為“Indicative Function Point”（指示性的功能點），在其網站上有荷蘭語和英語介紹。

如果對用戶故事的定義（而非“業務操作”的定義，因為后者更完善、嚴格）略作約束，則可以迅速與功能點中的“業務操作”兼容。兼容的結果有兩個，首先是很容易把握顆粒度，其次是功能點與工作量的比例關系極佳，可以迅速推知工作量。

二、需求結構問題

在敏捷開發中有一個不完善的答案：Product Backlog 和 Sprint Backlog。前者是整個產品的待開發項，后者是當前迭代的待開發項，兩者內部都按優先級進行排序。

這個答案對項目經理（可以模糊理解為Scrum Master）和開發人員足夠用了，因為他們主要關心時間上的開發問題，也就是現在讓我做什么，什么時候要的問題。但對產品經理（可以模糊理解為Product Owner）而言，時間是一個維度，空間則是另外一個維度。

所謂空間維度，就是系統-子系統-模塊-大需求-小需求……之間的關系問題，這完全不是一個一維表格能解決的。由于敏捷開發主要是一線開發人員和項目經理發明并推動的，所以空間維度一直被忽略。但這是需求分解過程中一個繞不過去的問題，因為人們不可能面對一個一個一維表格回答這個問題：“我們所有的功能都包括在這里呢嗎？哪部分還略顯粗糙希望繼續分解？這些大需求包含哪些小需求？”

在UML中的答案比較完善，“用戶 - Use Case”（人-功能）很好地把一批相關的功能聯系起來。雖然只是非常簡單的表達，但比把幾個毫無關聯的故事按優先級排在一起，或把幾個密切相關的故事相隔十萬八千里放置還是進步不少。UML中的模塊則是一個更宏觀的需求“目錄”。

FPA雖然沒有需求關系表達，但如果把“業務數據 - 業務操作”作為一個樹形結構，很類似把UML中的“實體 – Use Case”作為一個樹，形成“數據-功能”的關系。不過，這個體系沒有提供更宏觀尺度上的需求結構問題。

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

很多時候我們會覺得引入較為嚴格的定義會“有限制太難做”，但其實更難做的是“無規則無限制”下自由發揮。

記者：敏捷開發中需求拆分之后，任務應該怎樣分工？

陳勇：即使都是使用敏捷開發，任務拆分和分工的方法也會因行業、產品的特點而有所不同。

在純軟件或技術相對單一的產品中，需求拆解到4天左右（也就是前面提到的“一個業務操作”的規模）就可以分下去或領取了，因為人們比較容易估算4天左右的工作量，也容易跟蹤。在這種情況下，如果一個人同時負責幾個“業務操作”，應該分解為多個任務來完成，而不是一個。因為這些業務操作可以獨立完成并交付，合在一起不但不能持續交付，也會使得進展不透明。但再進一步劃分沒有必要，因為再劃分就不能獨立交付了。“獨立性”是FPA中對業務操作的一個約束條件，如果按照FPA的概念來劃分任務，會自動滿足獨立性。

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

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

總之，對任務的分解應該本著“需要”與“必要”的原則。不能因為想“更敏捷”而采用“更小的任務”。

記者：Sprint會議是實踐scrum中最重要的事件。您認為Scrum會議在團隊中應如何進行的？

陳勇：要做好計劃會，應該先建好團隊模型。

計劃會是少有的團隊齊集一堂進行的活動，無論團隊模型是怎樣的，都應該有助于大家以集體的力量完成計劃，并完成計劃的任務。

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

第一，“所有隊員平等”的團隊互助的動力從哪里來？人們一定會說：都是在一起工作的同事，怎么會沒有互助動力？我們曾經在一個團隊實施代碼審查，而且是我之前多次提到的那個最好的139團隊，很快發生一次事故：一大段4000多行但包含4000多個常數的爛代碼逃過了檢查者的眼睛進入了代碼庫，并最后引發客戶現場的Bug。當詢問代碼審查者為何讓明顯存在問題的代碼通過檢查？代碼審查者很無奈地說：“我剛來不久，雖然我覺得這些代碼有問題，但我感覺大家都說他（編寫者）是個高手，我也就不想說什么了。其實我本人也覺得這些代碼有問題”。這件事情促使我們后來形成了139團隊，就是形成層次團隊，由師傅來審核徒弟的代碼，出問題師傅負責。這不是說所有團隊一定要如此，而是說不能簡單地把互助建立在“雷鋒精神”上面。

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

第三，剩下的“主動領取任務”、“互不干涉”等，也要進行相似的分析，不能因為“看上去很自由很敏捷”就采納。提出這些實踐的團隊可能與我們所處的情況差別很大，未必能拿來就用。我曾經用過“自由領取任務”，那是在10年前的一個假期里邊，我邀請自己關系很近的兩個老部下來幫忙做一個軟件；一些零散任務就被單獨拿出來，誰先做完手頭工作就自由領取，其中一個人領取了8個中的5個之多。但在之后的每一個項目中，我都會先想一想，團隊是否允許我再次采用這個實踐。

團隊模型理順了，計劃會所需的共同計劃、集思廣益、團隊協作才能做好。

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

陳勇：Scrum主要是關于需求和項目管理的，而XP則主要是技術管理。

Scrum中關于Product Backlog的全部及Sprint Backlog的形成過程、評審會大部分，可以理解為需求管理內容，包括需求開發，分解，描述，排序以及進展跟蹤的過程。而估算、每日立會、燃盡圖等內容則屬于項目管理。

XP則主要是技術管理問題，不過其結構不明確，不好分類。

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

Scrum在商業運作上也更成功。這應該歸功于Scrum的發明者是項目經理或更高級別的人員，而XP則主要是一線員工，甚至說是Geek們不為過。Scrum推出了認證的Scrum Master和Product Owner兩種認證，由于體系相對完整，認證課程目標聽眾的收入也相對較高，所以推廣起來比較容易；多數咨詢師更容易理解Scrum的理念而非XP的，也使之得以快速推廣。

不過長遠看來，團隊，過程，技術三者密不可分。Scrum覆蓋了前兩者中的一部分，但如果沒有持續集成、自動化測試等方法的支撐，迭代交付將很難完成。所以，未來應該會有并存的需要，即使不再以當前的兩個名字存在。

#p#

記者：拙劣的度量指標會產生嚴重的后果，敏捷度量指標也是一個很有爭議的問題，以您的經驗如何去解決這個問題？

陳勇：有多個層次的指標可供衡量，下面從基層到高層一層層剖析一下。

一、基層度量

對最基層活動而言，一般所有度量均不用于個體考核，而只是用于改進。比如個體的缺陷率、工作完成量、按時完成率等。

之所以這樣做，原因是不希望面向個體的考核破壞了團隊中原本用來提高生產率的團隊協作。團隊協作可以消除個體錯誤，通過共同估算讓高手的技能流向新手，等等。如果個體考核讓人心有掛念，會產生問題。

不過一個不可回避的問題是：不管你們敏捷開發怎么說，但財務終究要把績效獎金（假如有）發放到個體而非團隊的賬戶上，怎么知道誰應該發多少呢？在一個10個隊員且關系互相平行的團隊里邊，的確沒有辦法知道，因此也不得不面向個體考核，并最終不可避免地毀掉團隊協作。

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

因此它是一種兼容敏捷團隊精神的個體績效考核方法。

二、外部度量

正如前面所說，外部度量是為了讓團隊對外透明而做的度量。有這樣幾個原則：只做外部看得懂的度量；只做外部有人看的度量；盡量少做度量。

典型的外部度量是給PO也就是產品經理所作的用戶故事的完成情況的度量，比如白板上處于完成狀態的故事的數量。這里說故事而非任務，是因為對產品經理而言，任務完成沒有意義。

生產率也經常是一個被度量的內容，但現在尚無好的方法。有些團隊經常使用“故事點”來做度量，方法是：先挑選一些以往的故事作為典型故事；為每個典型故事分配一個點數（一般是當時完成此故事的天數）；每次估算新故事時查先看更像哪個典型故事，然后再根據難度差別為新故事設定一個點數；實際完成后，點數/天數=生產率，也就是實際完成點數的速度。這個方法看似有效，但因為大家對典型故事的熟悉程度差別很大，典型故事也很難選擇，導致實際使用的人很少。另外一個問題是不同項目的典型故事和點數是不通用的，因此無法做比較。好不容易做了一個想對外發布的生產率，卻無法橫向比較只能自娛自樂，顯然存在問題。未來，這個問題可能會被功能點生產率解決，但現在還沒有看到有人嘗試。我們自己做了一些宏觀嘗試，但沒有每個迭代都做。

此外還有一些度量，但取決于實際的需要。比如在線運行的網絡游戲，會度量迭代交付周期長度（直接影響響應時間，因此一般越短越好）。這些度量不全是明確量化的，但公司上下都能說出一個大致的數字來，因此也算是度量。

三、業務運營與收入度量

既然敏捷開發說是“交付客戶價值”而非文檔或代碼的，那么一定能改善營收或其他運營指標。

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

現在有些團隊如網絡游戲和搜索引擎公司，已經把這些數據引入了開發團隊的度量中。但一般不做績效考核，而是讓大家知道最近我們的研發在市場上的實際反饋如何。

四、內部創業

任何時候想度量的時候都要問：為什么要度量？答案是：度量的目的是為了改善目標。

那么如果說企業的終極目標是盈利，而卻有一種方法不需要度量就能提升盈利，那么應該怎樣？當然就不用度量了！目標永遠比方法要重要。

比如現在網絡游戲團隊普遍有一個政策：20%的營收歸項目作為獎金。一般這個數字從幾十萬到上億的規模，而團隊往往不到100人。他們不在通過繁雜的績效考核系統中的度量項發放獎金，而直接把收入變成開發人員的動力。這種方法跳過了所有繁瑣的度量過程，直擊問題實質，是一種不度量而改善目標的典范，可以理解為敏捷開發“可運行軟件超過繁瑣文檔”這種嘗試弱化中間過程的思想的產物。 

當然，即使不能“內部創業”，也一樣能做到類似的效果。比如降低程序員的基本工資，代之以把公司產品銷售的一部分錢拿來做獎金。程序員自然就開始關心客戶需求，嘗試理解客戶到底要什么不要要什么，嘗試自覺改善質量防止客戶流失，嘗試自己帶徒弟以便讓團隊成長進而增加產品競爭力……很多效果是通過度量都難以進行改善的。

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

記者：您是否能談談在項目中，敏捷測試人員的職責和技能要求？

陳勇：關于這個問題，有趣的是：“測試活動”比“測試人員”在敏捷開發中出現的頻率更高。原因就是敏捷開發中提倡跨職能，也就是所有人都對開發、測試負責，從測試活動的目標的轉變上就能看出來。

傳統認為，測試人員是幫開發人員找Bug的，這是個誤區。其實，開發人員才是負責找Bug的，尤其是自己找自己的Bug。打個比方，如果我們在自己家里忘了鑰匙放在哪里了，一定不會把家里翻個底朝天，而是會嘗試找自己以前習慣放鑰匙的地方；但如果讓一個客人來找，就不那么容易了，因為客人不熟悉家庭環境，也不熟悉我們放鑰匙的習慣。家庭環境就是軟件，而鑰匙就是Bug，測試人員則是一個不太熟悉家庭環境的客人，開發人員才是那個放鑰匙的人，盡管他暫時“忘了放在哪里了”。而且長期而言，只有開發人員才能改變自己的習慣，比如在墻上釘個釘子，習慣性地把鑰匙掛在上面。我們在一個項目中密集實踐過代碼審查活動，在短短27天時間里，通過每天花費半小時觀察、記錄、分析自己的缺陷，個體缺陷率降低了一半之多。而且好的習慣和規范一旦固化下來，以后無需花費額外時間也能在一定程度上保證代碼質量，可謂一勞永逸。

找bug的活被搶走了，傳統測試人員怎么辦？有兩種出路，或者說“職業生涯規劃”，都比原來傳統測試人員更有前景。

一、有開發經驗的測試人員應該轉向“開發測試”

“開發測試”是游戲領域的一種工種，對應的是完全不需要對開發有了解的“黑盒測試”，我們可以把它的定義擴展一下用在這里。開發測試在開發活動中主要負責自動化測試、持續集成、回歸測試等用于快速保證產品質量的活動。

為什么叫“快速保證產品質量”而不是“發現Bug”呢？因為開發測試程序的人其實不應該是這里的開發測試，而是開發某個功能的開發人員本身。正如之前所說，具體的功能開發者更清楚功能是什么，可能有哪些潛在的問題，如何驗證最好……所以開發并第一次執行（為發現缺陷而執行）的是開發人員；但如何讓眾多測試用例自動地全部或有選擇地再次運行，如何保證更高的運行效率、如何準備自動集成環境，則是開發測試人員的工作。

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

整體上這個出路偏向開發人員多一些。

二、“沒有開發經驗”的測試人員應該轉向“產品經理”或“專業測試人員”產品經理不說了，因為出路很窄。這里說說專業測試人員。

有很多時候我們覺得原來的測試人員不就是“專業測試人員”嗎？其實不然。很多測試人員不過是看看說明書，點點鼠標，填填Bug而已，很難說上“專業“二字。

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

我曾經在松結對編程與139團隊系列博客中多次提到一個23個開發人員加2個測試人員的團隊，其中兩個測試人員就是專業測試人員。尤其是其中的測試經理，會定期基于業務的需要向我們提出測試要求，而我們則幫她編碼實現。這種搭配方式最終促成了產品的高質量，它現在正運行在國內60%以上的數字電視臺。

這里的“沒有開發經驗”被打上了引號，是因為我無數次聽到有人說“我沒有開發經驗，也不懂開發”，但這個人可能是與開發人員共事很多年的資深測試人員。其實，與相對論相比，開發更像是外語，就是外國乞丐學多了也能學會的東西。因此實在不能用技術壁壘作為借口，要做好可能很難，但要了解的確不難。要做好測試這個工作，不去側面了解和理解開發，是很不現實的。

記者： 在敏捷實踐的過程中是否一定要使用一些敏捷工具？能否推薦一些您認為比較好的工具？

陳勇：因為我自己也在開發一個敏捷工具“火星人”，所以就不直接推薦工具了，呵呵。不過下面可以介紹一下一些一般原則：

一、一定要選擇適合自己行業領域的產品

有些產品可能是為大型制造業、銀行、電信等開發設計的，那么盡管也叫“敏捷開發”產品，但里邊會帶有很多大型產品設計中所需的元素，比如UML，Portfolio Management（可以理解為大團隊或多團隊的管理）等內容。這并非像有人說的他們在“掛羊頭賣狗肉”，而是在特殊行業實施敏捷所必需的適應。反之，簡單的電子白板工具往往反而不適合在這些行業應用。

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

二、根據“數據持久性”選擇產品

所謂數據持久性，就是指數據要保存多久。如果是電子白板類產品，產品選型可以稍微“隨意”一些，因為電子白板上的東西多數零散、顆粒度較小，很少需要幾個月之后還要查看。所以可以大膽嘗試這些產品。其他比如計劃管理的工具也比較容易更換，畢竟完成了的項目的計劃被訪問的次數和必要性會迅速下降。

而對于需求管理、缺陷管理等產品，尤其是前者，則需要慎重選型。視行業的不同，這些產品可能需要考慮到未來3～5年乃至更長的數據保存問題，所以需要慎重一些。另外這些產品往往跨多個職能部門，選型時需要多方同時協調。

三、未必一個公司只用一個產品

All In One是每個公司的夢想，不過卻不現實。我培訓或咨詢過的一些大型電信企業，其涉獵的領域之廣往往令人驚訝。有家公司在做計費系統、BOSS系統（業務和運營系統）的同時，還在做移動互聯網軟件甚至游戲。前兩者對需求遵從性、成本控制的控制是核心，因為它們往往涉及甲乙方合同；而后者則對創新性要求更高，喜歡“擁抱變化”。

這種情況下管理層應該深刻理解不同領域的管理要點。比如甲乙方項目中，“誰在做什么”這類任務細節往往是重要的，因他它能保證所有人都有活干，防止空置資源的浪費；對完成功能的多少的掌握也是重要的（最好使用功能點），因為它能表征進度。但在移動互聯網軟件中，“現在我們在做什么”“什么時候這個功能能做出來”“這個功能做出來反饋如何”才是重點。

由此可見，領域要求不同，方法論就會不同，管理工具自然也可能不同。除了一些簡單的白板軟件“都能用”之外，復雜產品很少能適應如此巨大的差異，甚至說也不應該適應所有領域使用。

在這種復雜情況下進行選型的時候，領導層或領域專家應該給出自己對管理的核心需求，然后再放手讓團隊進行自由選擇，只要驗證核心需求被滿足就可以了。