無論是在軟件或者管理行業敏捷開發已成為眾多高效開發團隊的制勝之道。敏捷開發可以說是在開發中面臨迅速變化需求中的一種快速開發能力。當然，敏捷不僅是簡單的快速，而是在開發過程中短周期的不斷改進、提高和調整；當然也不僅僅是一個版本只做幾個功能，而主要的是突出重點。

在國外軟件企業中，幾乎將近半的企業是已采用敏捷方法進行開發，隨著近年來受軟件外包和外企的帶動，敏捷開發在中國也出現了日漸普及的趨勢，如騰訊，IBM等等內部幾乎所有的開發團隊都在實施敏捷方法。敏捷開發的流行絕非偶然，因此，51CTO記者采訪了AdMaster（精碩科技）***布道師程顯峰，講解了敏捷開發在團隊中的實踐以及發展現狀。

[[66187]]

簡介：程顯峰，畢業于悉尼大學，《MongoDB權威指南》譯者，MongoDB中文社區創始人。Emacs使用者，Ruby寫手，Scheme愛好者。AdMaster***布道師，負責團隊建設，人員培訓，新技術普及，還有一些公司技術PR的工作。

以下是相關的采訪實錄：

敏捷在項目中的實踐

記者：有些人認為敏捷開發并不適用于水平一般的程序員或團隊，您是怎么認為的？

程顯峰：至于敏捷開發是不是用這種程序團隊，我認為特別適合訓練有素的團隊。反過來說，如果不是一個訓練有素的團隊，實施傳統軟件開發也會失敗，所以我覺得基本的要求是跟原來的一些要求基本一致的，溝通能力、協調能力，對于項目變動的控制能力都是一樣的。包括傳統軟件開發當中講的項目可控，整個項目可復制，同樣的資源配比后還可以復制這個項目，如果原來的這些做得比較好的話實施敏捷項目就相對容易一些。

記者：很多人為了編寫易變更的代碼，在采用敏捷時，拋棄許多習慣用法，由你的經驗出發，如何去看待這個問題？

程顯峰：從我在實施的過程中***點需要強調的就是大部分跟傳統的軟件工程還是一樣的，現在異化的部分過于被強調了，搞得大家以為是完全新的、不一樣的東西，傳統軟件包括需求管理、進入控制、質量管理、測試體系，這些東西在敏捷里也都要體現、都要實施，而且要求可能還會更高，并不是把一些傳統的東西拋棄掉了，既沒有進入管理又沒有版本控制，幾個人一商量就定了敏捷，這是完全的一種誤解，而且還是要好的工程基礎才能實施。

記者：所以傳統的方法對于程序員的要求還是比較高的吧？敏捷這樣的功能經過修改之后就可以推出一個小的版本？

程顯峰：并不是說推出小版本就降低難度，這是沒有因果關系的。比如說這小的版本即使推送上去，如何保證這個小的版本是對的？你也需要大版本的方法，比如軟件測試、進度控制、需求管理，這些東西都得有，你才能控制好。雖然你推得比較快，看上去可能是一個一個的，如果你要是推的沒有章法的話一樣也是亂套。不是你想要的東西，也會造成大量的浪費，我是這么覺得的。

記者：對于一個失敗的軟件項目來說，您認為敏捷方法是它的救星嗎？

程顯峰：對于一個失敗的項目就要說出失敗的原因，這才是解決失敗項目的辦法，敏捷的方法不是，這個邏輯就是有問題的，我覺得這個沒什么好說的。

其實我覺得敏捷的方法不是任何失敗項目的救星，這是肯定的。至于失敗這個事情，看上去可能是分工的原因，有可能深層次的來講是不交流、不溝通的原因。敏捷比較注重強調溝通互動這些方面，它是有強調這些東西，如果你的問題恰巧是由于不溝通導致的，可能采用了敏捷的方法可能會有極大的改善，但也非常取決于實施的人和分析的效果。好多人說敏捷就是一個框，什么東西都可以往里面扔，實際上也確實有點這個樣子。

我覺得敏捷的方法更多的是注重發現問題的框架，就是能讓你更快地發現問題、暴露問題。至于怎么解決問題，原來能解決的就能解決，要是原來解決不掉，敏捷也幫不了你。但是它能幫助你發現問題，比如說原來你有溝通問題，但是很長時間才能暴露出來，這個東西能讓你在短時間內暴露出來，那么就有助于解決這個問題。

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

程顯峰：我是傾向于比較溫和地對團隊進行改進，實施的東西盡量不要讓團隊有一個明顯的轉型期，比如版本控制，原來做的版本控制、提交力度、上線流程這些，我會給大家介紹一個新的系統，但是并不會太影響大家的工作，適應起來又很快，這樣的改進效果是比較立竿見影的，而且影響又非常小。這種改進不是偶爾一次才會用到，而是天天都能用到，比如說調試方法，每天能省一分鐘就行，我特別喜歡這樣的改進。

大家可能都覺得敏捷特別神奇，每天能省百分之二十的時間，現在我還沒發現這種現象，我特別不相信這種東西，就是不想省百分之二十的時間就不會讓大家經歷一個很長的轉型期。比如你告訴大家一個技巧，每天能省兩分鐘，這種東西大家天天用實際積累下來的效果才是比較明顯。你要是教給大家一個方法，比如能省二十分鐘，實際上這種方法看上去是非常漂亮，但它不是什么場景都能用得到，所以我就不太喜歡這樣的方法。現在大家吹噓的敏捷方法可能有一部分也不敏捷，我在這個團隊里也不太愿意教那部分，比如說每天早上例會的時候站在那里說一通。我也跟他們講過，他們有的話可以，沒有也OK，有些東西我的要求就比較死，比如上線的流程、可控性，我在這個方面的要求就比較死，開不開會對于我的項目沒有什么影響，但是上線的流程就不一樣，我要往回退的話就要花成本。

對于小的團隊來講真的是可有可無的，因為團隊的人都坐在一起工作，未必需要一個站到板子上的形式。現在有人把形式看得很重，本來例會是很簡單的，五分鐘就開完了，但是吵起來了，開不完，因為一般都是開早會，吵完以后心情就不好，所以效率就下來了，這也是很正常，但是你不要想著漂亮的東西，我對漂亮的東西感覺都不實用。

記者：會不會因為不吵這個架把錯誤帶到真正開發的過程中造成成本的耗費？

程顯峰：會，所以我們要在實際的工作當中發揮，其實例會也不是吵架的會，還有很多的會可以發現這個問題，比如通過Review，可以有各種各樣的方法去發現，不用拘泥于這種形式上的東西。其實最難改變的往往是那些小的習慣，比如他就愿意用這個手指頭去敲鍵盤，但是這可能會影響他的效率，他不愿意改。這種習慣的話改的阻力反而比較小，你讓他去開個例會他覺得耽誤時間，但是要讓他改這個的話他可能會改。你想他要敲多少？天天可能都要去敲，這種感覺可能是持續的。

記者：這種其實是屬于比較個性化的調整，每個人的使用習慣不一樣，有些人可能喜歡用這個手按著，有些人喜歡用那個手按著，你要主動發現各個人在工作當中需要調整的地方？

程顯峰：我一直認為團隊就是一個泯滅個性的過程，而且這一點我是非常講究的，包括編輯器的使用習慣和配色都有強烈要求，不像別的看上去那么自由，坐在哪里無所謂，但是你用電腦的方式必須是我規定好的。沒有一個共同基礎的團隊根本就不叫團隊，總有一些東西是有共同基礎的，而且一些高效的團隊很可能所有的東西都是共同基礎，就像特種兵出去打仗，一個手勢就得去殺人，你還能再問這個是什么意思？就像我們用別人的電腦，或者在團隊當中用其他人的電腦，那些配色習慣都是一樣的，我們溝通交流起來就會非常容易。

現在新人如果不配色，直接就卡掉，新人培訓就不合格，所以必須要有配色，包括快捷鍵的使用，不能人家給你一套代碼你還慢吞吞的，這會非常影響別人的心情。因為有些忽悠師天天都去忽悠各種敏捷方法，但又不注重工程實踐，不注重觀察細節，所以就做不到。他們不會注重這種實踐，比如咱倆是木匠，我天天使完的刀子隨手一扔，天天你給我收拾，雖然我是大牌，但是你也不愿意。你和我都收拾的很好，大家都用一個工具箱，這樣才能省下很多時間。我就覺得能省時間的話，就是在任何層面上都是節約和避免浪費的表現。

記者：如能得到準確的數據支持，敏捷實施能夠更好地開展下去，那么敏捷實踐下的程序員工作指標將如何衡量?

我是覺得這個數據比較難以衡量的，因為衡量有意義的必須是在某種固定的場景下。比如對于我這里來講，我可能會要求程序員開發一個標準模塊的實踐，但是對于別人來講，這個他可能不太注意。從實施的角度來講，我對怎么度量這個事情想的不是很多，我是比較相信主觀看法的，因為我在實施的過程中是跟他們在一起工作，不需要用那些數據來告訴我他們已經進步了，他們做外部咨詢的就比較注意這個事情，因為他們需要給那些老板寫報告，我不太需要這個東西，我對其它的產品負責就可以了。

#p#

敏捷開發的解決方案

記者：剛才提到你特別關注的除了工作規范和開發規范上的細節，還有就是發布流程。

程顯峰：是這樣的，發布流程實際上就像互聯網團隊的一個核心，就是有一個標志，如果我拿到一個需求，***到發布有多長時間，這是看整個團隊效率的標志性衡量，現在很多人都講敏捷，其實軟件度量是一門學問，究竟度量什么大家非常有爭議，但是我感覺沒有太多爭議。所有的度量尺度都用時間，因為時間是比較公正的，沒有差別的。比如你用代碼行數，大家都說代碼行數不是一個標準尺度，你用C寫的五百行和用Java寫的五百行到底能不能衡量？但是你用時間的話，我這里一秒和在美國那里一秒是不是都一樣的？所以所有的東西都應該用時間來衡量，很多東西都可以轉化成時間。比如上線效率就可以轉化成時間，拿到一個需求到***推上線就是一個標準的時間，你能在多短的時間之內完成這個事情，這是你團隊效率的一個提升。

還有一個非常重要的提升，就是當你發現線上的東西有問題，多長時間能回退到上一個版本？我們可以在秒級之內回去，就是一分鐘之內退回去。這是整個團隊開發效率的一個顯著的管理，如果你做不到這一點的話，比如你已經發現Bug了，第二天才能把這個更正，其中的時間全部都浪費了，而且對于一個線上系統就是損失。我是講比較實在的東西，對于開發流暢要把控的特別嚴，怎么才能把控上線的這些東西呢？就是要把上線的過程和開發的過程、測試的過程全都緊密地聯系在一起，這是一個整體，而不是把它們割裂。包括很多傳統企業這個方面做得也非常好，并不是敏捷獨有的。所有的東西我堅信都不是敏捷獨有的，對于優秀的工程實踐來講都是通用的，整個過程都是非常好、非常快。

記者：在敏捷方法流程中具體 實踐的有極限編程（XP）和Scrum等等，Scrum目前團隊用的是比較多的，對于極限編程不知道您有沒有了解，據我了解很多團隊用過Scrum的都不喜歡極限編程的實踐方式，能說說您的觀點嗎？

程顯峰：Scum只是一個簡單的溝通框架，所以大家的接受程度會比較高，只是規定了你該在什么時候溝通，該在什么時候反思，早上起來應該怎么跟大家交流，抽張撲克牌估算一下這個東西，Scum只是一個實施框架。極限編程是大量工程實踐的集合，比如極限編程里講TDD，它是具體讓你操作的，比如咱倆就在一塊，它是一種具體的工程實踐，就是這么做。但具體工程實踐大家反感就比較大了，因為跟他以前的做法不一樣，而且問題的關鍵在于實施這種東西最重要的是有一個人帶一個人去實施，兩個人都不會你就在那兒極限編程，這個太扯了，根本一點用都沒有，這種東西就是師傅帶徒弟。

比如結對編程，兩個人都沒結對過，你如何在那兒結對？比如本來是一個大鋸，你在這邊我在那邊，大家都沒使過這個鋸，咱倆就商量這個鋸到底怎么拿，所以時間長了以后沒有效果，大家馬上就對這個不看好，然后就失敗了，他們不能帶來效果。一般在成熟的公司里面，他們是極限編程。就像結對這種最簡單了，總共有兩種，一種是師傅帶徒弟，就是一個mentor，一個是徒弟在這里學，mentor一開始會給你演示所有的編程，你就在后面看，mentor可能會給你提問，等過了一陣你來，mentor在后面觀察你、指導你，然后讓你干這些。這是帶新手非常有用的招，很快就能把新手培養出來。

另外一種就是兩個人的水平差不多，就是互相干活，一個人負責設計，另一個人負責實現，這是真正的工程模式。那個是教學模式，你就要求兩個人合作很長時間，比如我說的設計他不懂，這就玩完了，沒法在一起。關于你說的極限編程，兩個人沒在一起合作過，或者兩個人都沒搭檔過，你還在電腦上干自己的，后面的人就特別沒意思，沒有互動沒有交流，好多工程實踐都是這樣的，雖然跟你平時的編程方法不一樣導致的。Scrum跟大家多數的東西都不沖突，只是原來要開會，現在也要開會，現在規定好了什么時間開什么會，只是輕度地改變了你的東西，所以實施起來非常容易，大家的認可度也非常高，而且某種程度上見效又比較快。主要是因為它能發現一些具體的非技術上的問題，比如溝通的障礙、理解需求有問題，或者節拍上有問題，有的部門太快了有的部門太慢了，他們能發現這些問題。

記者：當一個敏捷團隊工作時，有時透明化的流程會暴露出機構中的問題，而這些問題又被稱為敏捷開發流程的過失。在整個行業中，您們開始遇到這種情況了嗎？敏捷開發會使行業的缺點逐步暴露，從而在各方面招致一些與敏捷開發對抗的反對意見嗎？

程顯峰：是這樣的，按照我的理解，我覺得暴露問題是個好事，暴露問題就說明這不是一套有效的方法。為什么豐田要做單件流的系統呢？因為任何一個環節出了問題，馬上就要停掉工作，他是可以以最快的速度發現問題、解決問題。為什么是一鍵而不是兩鍵呢？因為一鍵可以發現的更及時，要求生產線上的所有環節都要嚴格匹配，如果有稍微不匹配的地方馬上就會跳出來。如果它是一種發現問題的話，我覺得這種很好，不發現才是問題，發現問題不好嗎？我覺得非常好。當然，你肯定會遭到反對意見，這個我覺得是實施的人應該想清楚的事情，實施什么會遭到反對意見，或者不實施什么會遭到反對意見。

記者：在實施當中有沒有過這樣的情況？

程顯峰：肯定會有，這個可以來自于各個方面，但是你要實施的話就要想清楚，比如老板什么時候會反對？不出效益的時候會反對。所以剛開始實施的時候不會去做那些影響步驟的問題，你要先見效，有很多方法可以先見效，但是很多人都不知道，你要實施那些先見效的，這對樹立信心、樹立威望都是非常有幫助的。你不能一開始就挽起袖子說要怎么干，沒有獲得之前這些事情是做不了的。我們團隊剛開始還好，有些團隊你要實施敏捷，或者實施某些具體工程實踐的話會有挑刺，這就跟你實施人員的素質有關了，比如你能說服他就說服，要是說服不了他的話你也沒法實施。

有的人去實施版本控制，他就說要用分步式的傳統模式，有些人就說為什么要用分步的？那么你做一個版本宏觀動作，我用這個做一個，我們比一下。因為技術這個東西很好衡量，大家一看就都明白，它不比了，就實施吧。你要有手段和信心去實施這個東西，而且你要知道對手是什么，如果你控制不住這個局面的話，以后實施的時候會有各種各樣的東西。比如實施測試，測試的好處你有沒有給團隊看到？你自己都不會測試，也帶來不了什么好處，你就說服不了團隊去做這種事情。

比如這里是有框架層面的東西，我特別愿意實施工程實踐，因為我對工程實踐的把控力特別強，你要是反對我，我有很多理由去說服你，而且非常容易見效，你要很快地贏得工程技術人員的信任。反而在實施這個項目時大家會很嘀咕，覺得這個家伙到底寫沒寫過代碼？是不是只會這些？因為它不涉及到任何技術細節。工程實踐就不一樣了，你說代碼這么寫不合適，那你就得說出不合適的道理，你要那么設計的話就是一種技術的對抗。其實遭到反對意見不光是敏捷遇到，干什么事情沒有反對意見？沒有反對意見的事大家早就做了，也不需要其他人。

記者：其實我想了解你們開發的反對意見。

程顯峰：在我看來大部分的意見其實是一種固有思維的反應，就是他們固有模式的一種反應，以及固有的工作習慣不愿意改變的反應。問題是他沒有見到你要實施這種東西好處的前提下會跳出來反對，你要做的事情是要證明這種東西會給他帶來利益。比如剛才說的那種，你用你的版本控制，我用我的版本控制，你自己本身有非常豐富的經驗，你看到別人那么做就能很清楚地知道這樣做肯定是簡單或者容易的時候就不會比了。要是知道自己一定會贏的話肯定會比，肯定是他實施的新東西對他來講是有好處的，但是他又不愿意付出改變的成本，又不愿意讓大家明確地見到這種好處，因為團隊的人要是都知道這種好處你就沒法演下去了。所以很多事情要把它透明化，就是不存在那種邊邊角角的東西。

當然，阻力是各種各樣的，***的方式就是把這些東西都透明化，這些程序員相對來說還是非常講道理的，因為跟機器打交道多了，有一說一，思維方式還是比較客觀公正的，不會說這些東西明明是效率高的卻跟你說不行，一般不會有這種情形。

記者：目前國內出現了很多敏捷教練的角色，敏捷的教練需要具備什么樣的素質？

程顯峰：我個人覺得不管你具備什么樣的素質，你要能和開發團隊打成一片，要能贏得開發團隊的尊重才能做得下去，否則你天天講，人家不信你，其實你什么事都做不了，你可以不懂技術，但是開發團隊都很信你，這也OK，但是開發團隊一般都有一種傾向，就是技術沙文主義，不懂技術的人是不能打交道的，你要是想真正在這個團隊里混下去的話就得跟他們打交道。不同的團隊當然不一樣了，比如華為有敏捷實施的紅頭文件。

記者：這種規范開發人員的工作習慣，優化他們的習慣，教他們一些工程方法，這跟CTO的職能有什么區別？技術部門的Leader職能跟它有什么區別？

程顯峰：比如丹峰就負責技術架構設計運營，我就負責培訓，發現團隊的問題并整合這些看上去非常瑣碎的事情，還有一些其它培訓方面的事情，他們是思變，是想著怎么去打這個仗，我是像個教官一樣想著怎么提高他們的戰斗力。他們只想怎么用這些人，然后打哪兒，這是他們要管的事情，我是教他們怎么使用武器，讓他們訓練有素，學會配合這些常規性的事情。

#p#

敏捷與管理的發展現狀

記者：對于未來幾年敏捷開發的發展，您希望看到哪些新方向?有何建議?

程顯峰：發展方面的問題我還真不知道，還是覺得有點落后，這個還需要積累吧。很長時間才會有一些改進，國內技術上落后的已經比較少了，反而是管理上落后的非常非常多。比如Facebook的崛起，大家都看到它用的是什么技術，很少有人看到Facebook在壯大的時候立馬就從e-Bay挖了一個人給他們做工程方面所有的事情，他們從很早期的時候就從e-Bay挖了一個高管去做所有工程化的東西，很早就做了，非常有遠見，這些事情很少有人知道。Facebook每年開了什么會，開發了什么框架他都知道，到了一定程度你就會發現它不是幾個毛頭小子一個Idea就可以發展起來的。e-Bay大概已經有二十多年，其實是經驗非常豐富的人去做這個事情，并不是一個Idea就能行，現在好像不太注重這個方面。

其實在美國都是由非常資深的人去做工程化，而且這個市場還是比較穩定，真正去做這些東西的人還有一個相對比較穩定的流動環境，不會是從哪里突然冒出一個人就能做這些事情，或者是憑一個Idea就可以做。

記者：微軟就有自己的工程研究院和微軟研究院，也是不一樣的。

程顯峰：其實從開發的各種東西來說，類似微軟、蘋果、谷歌這些大公司，他們在工程管理上都有很多非常有經驗的人，但是這些人在國內往往不講這些。比如原來谷歌測試的負責人段念就是講測試方面的稍微多一些，那個屬于工程化的一部分，你就可以看到一些，多半也是做類似的工作，實際上他是一個非常有經驗的做工程化的人。

記者：主要還是國內管理上的問題。

程顯峰：對，軟件研發的管理落后的不是一點半點，國內那種落后的方式跟美國六七十年代有一拼。其實現實就是這樣，尤其是互聯網公司還在覺得自己是什么高科技，其實工程管理的水平差得一塌糊涂，但是不是壟斷高額利潤，如果是從一個軟件公司的角度去衡量的話，那個研究體系簡直是一塌糊涂。

記者：其實從工程化的角度也會影響本身推出產品的效率或質量。

程顯峰：其實工程化是一種內功，為什么IBM誰打他都不太怕？內功非常深厚體現在幾個方面。

記者：IBM也比較開源。

程顯峰：它的內功深厚也是有各種方面，首先就是知識產權方面保護得特別好，專利大戶向來都是***，第二就是在基礎研究各個方面，工程化的思想，好多軟件工程的思想，軟件工程的方法，他們也很注重敏捷的一些東西。這就衍生了一個問題，為什么抄IBM的人都很慘、都死掉了呢？因為內功不夠。IBM的管理方法非常重型，輕型的公司想抄都死掉了，為什么？因為你根本無法調動那么多的資源駕馭那么重型的方法，你的內功不行，就是這樣。IBM原來那個case版本控制系統使用起來多負責啊，***用的大部分都是電信系統，就是跟它有相同內功級別的人。他的客戶都是金融、能源方面的，要是小公司用IBM做咨詢，即便是你付得起錢也實施不下來。

記者：實施下來也達不到那種業務規模。

程顯峰：我是覺得軟件業的發展還是應該從基礎做起，實實在在地把軟件做好，不要過分地強調那些概念，好多人都是想解決別人的問題，每年實施的過程當中尤其要注意，作為一個團隊的leader，你最清楚的是團隊自身的問題，你也最容易解決團隊自身的問題，要是每天都解決自身的問題的話一定是個特別好的教練，根本不需要去搭理別人，但可以借鑒別人的方法，看別人是怎么借鑒類似的問題。一定要著眼解決自身的問題，因為他們解決的都是別人的問題，比如看到別人的溝通方法就覺得自己的團隊溝通有問題，實際上你就是三個人，你有什么溝通問題？根本就不存在。

記者：聽你這樣說，敏捷并不是一個特別有別于傳統開發流程、軟件開發工程的方法，只是在里面加入了一些管理的理念，能夠把工程化和管理結合起來，可能就是一種敏捷。

程顯峰：軟件行業的管理方法主要來自于兩個途徑，六七十年代的時候大體上是借鑒建筑行業的系統化管理方法，主要是需求管理、建筑管理方面的內容，另一次改進就是在九十年代后期，由于豐田在制造業上的改進，就是精益方法，主要的改造就是發現問題及時生產及時交付，所有迭代周期這方面的東西。軟件行業主要的來源就是制造業，實際上他們也不能太超越這兩種。我就覺得現在老是想標榜自己跟別人不同，反而是把自己給害了，那些方法實際上會在那些產業里實施得更好。

你看《精益軟件開發藝術》那本書，寫得特別好，那是波音的一個家伙寫的，因為波音在制造業生產的時候用了這種方法，他在波音的軟件部門，借鑒了波音的生產，然后再去用精益的思想改造，實際上都是借鑒其它傳統行業的。傳統軟件的方法主要是建筑業的，建筑業和制造業都是比較成熟的，他們也會互相借鑒，借鑒***的結果其實是發現方法和方法之間的差別沒有想像的那么大，可能只是流派之分而已。比如大家都注重的版本控制、質量管理，整個周期管理這些東西，哪個沒有呢？而且具體的操作方法大家都可以借鑒，你敏捷比較推薦的版本控制，實施到傳統軟件當中可不可以？也可以的。實際上并沒有那么不同。我覺得這是一種商業策略，給劃分了非黑即白，不是那樣子的。其實大家真正在玩的時候就會覺得他們是可以有很多互通的，大家也可以互相借鑒，而且兩種方法都在成長，這就跟武俠小說里的江湖差不多，大家都是為了各自的勢力劃分出來，他們就是邪教，我們就是明門正派。

其實那兩個人討論的就是一個風花雪月的問題，完全沒有必要分什么派別，大家討論的就是一個質量控制的問題，敏捷也可以用，傳統也可以用，根本沒有必要說這個方法就是屬于誰的，但是這種實踐的東西多起來之后就會發現越來越多的共同之處。

記者：***就會發現自己在實踐的過程中總結一套結合了傳統和敏捷的方法。

程顯峰：肯定的，我覺得比較負責、比較講究實際的人都會結合自己這塊東西去實施的，敏捷方面有個非常重要的東西，要是按照書本上實施的話肯定不是敏捷，最重要的就是裁減，你要按照自己的東西去裁減，包括傳統的軟件研發人員那一套也有裁減，只是很多人都不知道。傳統的軟件研發雖然很重，但是會按照自己的需求去裁減，要是完全按照那種東西就會死得很慘，所以你要實施一套流程的時候***件事情就是裁減，要把它裁成合適自己那塊，包括電信企業里面實施的東西都是經過裁減的。

原來我的一個同事他們在項目實施的時候首先就是要看標準的研發流程，弄下來一份之后再裁減，就說這個我們不要了，那個我們不要了，要是按照標準化他們也受不了，肯定不行，包括傳統的實施。比如你就在一個豬圈，非得按照摩天大樓的質空標準去做，肯定不行，雖然都是建筑，但是不符合實際，所以最重要的就是符合實際產生效果，拿給老板也好說好看。

記者：那種大型的軟件，比較像傳統的，他們之間也有軟件開發的部分嗎？

程顯峰：肯定會的，工程實踐現在已經借鑒了很多，包括版本控制一般都是集中式的，現在大家對分布式的都會比較傾向，甚至是說發布流程。這些東西無所謂誰都可以用，比如傳統上的需求管理軟件、Bug跟蹤系統，敏捷也在用。敏捷也有這些東西，你也需要跟蹤Bug，你也需要有針對性地上線打包。

記者：所以只要技術能力強，跟敏捷沒有多大關系，都是在創業團隊里用敏捷的比較多。

程顯峰：是這樣的，大家為什么要用敏捷？很多都是創業小團隊偷懶的行為，因為他實施不了那種重型的，也沒有實施的經驗。其實在國內實施規范化的還是相對較少，他們覺得這個東西能夠玩轉才這么做的。而不是真正考察過，做了一個比較公正的技術選型，比如傳統上我們會得93分，用了敏捷會得94分，根本沒有數據，就是自己想，那種我們能不能玩？玩不了，這種我們能不能玩？差不多，實際上差得挺多的。因為敏捷強調的是不同，不同的東西又很少，所以大家就會覺得很容易。其實國內真正好的測試團隊簡直鳳毛麟角，能玩得起測試的鳳毛麟角，能把發布上線流程做好的也很少，這兩個都做好了，我覺得你是敏捷還是傳統都已經不重要了，這些對你才是實實在在的東西，對于質量、對于產品都是非常有益處的東西，至于長什么樣子已經不重要了，關鍵是對你是否有好處。

大家現在都是有點炒概念，不講實惠，我是比較講實惠的，這些東西好不好我很快就能知道，所以我要的是實惠。我向老板匯報的時候也是這樣，老板不看這些概念，他也不懂，創業的人好多是Idea出身，炒個概念會很好看，也會很好賣，但是大家現在都知道了，也不見得好賣。

記者：你們現在關注團隊的開發，是從哪個方面去看這個問題？

程顯峰：我個人比較關注的就是發現問題的方法，比如傳統的東西，包括制造業的那些管理方法我也都會看一些，比如《約束法》、《關鍵目標》的那套東西，主要是強調管理的，各種各樣的管理思想都能啟發你，實際上并不需要看特別針對軟件行業的東西，要看軟件行業里的東西我一般比較愿意看失敗的案例，就是類似《***軟件》那種常見的錯誤，比如程序員不善于溝通，然后說不是自己錯誤。人家在七十年代的時候已經把這些總結得特別好了，你會發現過了四十年還是那些問題，你就看那些老的書就會發現這些問題已經存在相當長的時間了，完全沒有什么新鮮感。里面刻畫的東西都是一樣的，具體的問題還是很一樣的，可能百分之九十的問題都是書上寫過的，不會有太大的差異，只是人不一樣、環境也不一樣，問題還是差不多的。比如注重質量、需求發散，這些問題都是非常常見的。

記者：看來還是比較大塊的問題，而且也不是軟件行業專有的，各個行業其實都有這樣的問題。

程顯峰：但是你看軟件行業的大師以前寫過這些話就會覺得挺有意思的，當然，你還可以借鑒一些制造業的，我覺得都會幫助很大。

記者：還有管理方面的，只要是這個行業的都適用。

程顯峰：其實這個點應該也差不多，我看騰訊的榮昊也做軟件管理，他也是什么管理方面的書都看了。如果光看這個方面的話，因為都是需要互相借鑒的，要是想做得比較好的話還是需要看很多東西。確實有些東西大家都太強調了，軟件行業的人都特別喜歡強調個性，其實管理的方法通用性還是比較高的。你看德魯克寫的那些書，每一條都是挺實在的，尤其是項目場景非常好。