2010年敏捷大會訪談錄 敏捷需以人為本
原創【51CTO獨家特稿】51CTO對于實施敏捷過程中，***的障礙是什么？我們先咨詢了吳昊先生。
吳昊“其實這個時候我們可能碰到最多的，實際上是一種文化上的沖突。51CTO剛才提到的敏捷，可能敏捷是不一樣的。比如從時間角度上來看，敏捷可能是一種功能實踐和管理實踐，在它背后有12個原則。其實我們認為只要你是符合這些原則的實踐都是敏捷實踐，而不是說你僅僅有這些就夠了，它可能遵守也可能違背最開始的原則。舉例說，敏捷的編程，這個時候他可能在很多情況下符合敏捷的原則，但是在很多極端情況下，實際上你是違反了敏捷的原則的，所以這個時候并不是每次都要判斷他是不是符合后面敏捷的精神或者敏捷的基本原則，他在每個場景下都會有不同的例子。我基本上不能跟你說有任何實踐放在任何環境下都有這樣的實踐，你需要在一個環境下進行具體判斷。
敏捷不能套用生硬的條文
我們往往碰到的問題是，有些實施敏捷的人，他只要實施了全套的實踐，那么我就是一個敏捷了，那么在他們實施這套實踐的時候，反而是一種非敏捷的方法，或者更重視這樣的過程，所以和他們開始的意愿是違背的，這個時候從實踐來看做的都是對的，只是他們選擇采取這樣的時機和方式不是很好的時機和方式，使得他們看上去是敏捷的實踐，實際上并不是。那這樣的話造成這樣的情況，我們最常見的敏捷障礙就是文化上的沖突，當一些企業管理者，他有這些變革式的方法的時候，他希望來保持我原來的生產效果，他不希望受到我新鮮事物的影響，然后他又強調你這個團隊應該是以新的方式來工作，那么我們都知道當你掌握一個新東西的時候，你都有一個學習階段，在這個階段相比原來的時候，生產效率會有所降低，但是從他的決策人的角度來看，往往我們聽到一些使用敏捷的時候都會說，在不影響現在的進度下使用這個方式，在這個前提下，當你跟敏捷的原則產生沖突的時候，往往這個項目決策人，項目進行前提會遠遠高于你的新的實踐，就會造成很多團隊在實施過程中他們自己也會覺得我們的實踐是違敏捷的，是走樣的，他根本上仍然是你的最終的團隊決策人，他是不是真的接受了敏捷的思想和文化，我真的愿意擁抱這樣的思想和文化，從而通過文化上的轉變帶來生產效率的提高，還是僅僅把它當做一種工具和一種新的過程，比如瀑布式，敏捷式你也可以強制的定義成這樣的過程，那是不是還有它原來的效果，這些都是我們不清楚的，12原則之上的敏捷宣言，里面最重要的一句是人是重于交互和工具的，這一點來說敏捷是發揮人的主干創造力和能動性，我們充分信任每一個人的能力，激發他們的創造力從而提高這樣的生產效率，而不是我們通過定義你的過程，使用你的工具提高你的生產效率，實際上當你能不能真正地接受這樣的文化，消除這樣的沖突，我覺得這個可能是，我們看到遇到很多問題，最終都能夠歸結于這樣的沖突。”
對于宋金永先生，我們感興趣的是他們在日常的工作中，會用到哪些敏捷工具？
宋先生說“工具方面也是我們在敏捷之前，也是預估到的，是一塊比較大的工作，我們這一塊逐步地引入一些工具，在需求管理上我們逐步引入一些管理需求上的工具，比如EXCEL的表格，可能我們能夠定制一下一個規范，我們就形成了FutureList，這個是一個小工具，大家把它用起來了，也有一些產品線屬于自發性比較好，他開源也好，網上也好，他會下載一些軟件，他會管理，甚至形成狀態圖，都有這樣的應用，后來慢慢地我們就發現可能對工具的統一也是必要的，后來我們自己也在嘗試做需求管理這一塊的工具，這是一方面。”
“另外一方面可能工具的大頭還在工程方法，比如單測，原來我們這邊，因為很多產品線，他們也是有自己的選擇，比如我是用CB的，還有用其他的，后來我們發現在這一塊是有成本的，為什么？就是它的代碼風格，框架不統一的時候會帶來很多問題，這一塊我們再統一掉，就是我們有統一的測試工具，我們有開發組專門做開發的，另外今天上午馬汀大師也在講持續集成，半年多之前我們開始在準備這個事情，也在開發這個事情，應該說初步的東西我們已經看到自己的持續集成平臺了，但是后面的路還非常長，因為我們發現這種工具首先可能是解決***步問題，后面的工作絕對是重頭戲，需要用各種方法，包括實踐上的，包括一些前期的引導的，還有和產品線具體合作的，類似的規律都要去做及可能我想到的工具主要這幾大塊。”
51CTO記者表示，在與一些程序員進行交流的時候，他們有一種想法，敏捷這種東西還不如原來用的瀑布式，覺得那樣開發起來，熬兩個晚上就開發出來了，也很好，老板也很滿意。所以他覺得敏捷的東西很虛，甚至于特別在一些小規模公司，那么幾個人，他們認為敏捷的方法很不適合他們，您覺得他那種想法是對還是錯誤的想法？您對于這種規模比較小一點的公司，在運用敏捷上有哪些方面的建議？
徐昊：這個其實很有意思，其實我很難評判你剛才說的情況，到底敏捷更合適還是現在的方法，很難評判，但是我想強調一點，當敏捷在強調效率的時候，好像我剛才講的，會有工程實踐，管理方法等等等等這些東西，當你做出任何一個決定的時候，都是這些東西平衡之后的結果，對于任何一家公司都存在這樣一個風險，比如這個人他很快，他花一兩天把這個做了，花一天可以做好這個工程，但是當你有了代碼的時候并不代表你擁有修改這個代碼的能力，可能只有他自己一個人，別人誰都看不懂，但是他寫的代碼除了他自己，別人想理解要花很長時間，在這樣的情況下，實際上對于公司而言會存在一種人力風險，如果這個人明天他不干了，走人了，他說我代碼都放在這兒，不能是完全正確的，老板有沒有評估我需要花多少精力和時間，這個里面可能是非常高的成本，也可能非常低，我并不能說一定非常高，但通常而言他可能成本相對而言要高出我們的想象，因為其實很多人我們并沒有意識到這樣的成本，當我修改別人的代碼，我得讀懂它變成個人理解的時候都會變得很困難。所以這個時候你就會理解敏捷方法它看上去慢，但是它是宏觀考慮，我承認當你做探索性開發的時候，效率并不高，如果其中有一個人能力很強，應不如他自己開發的效率更高，這個我們是能觀察到的，這個并不是通常情況，很多情況下，往往是這樣的，它是一個探索性的，大家都不知道什么樣子，人與人之間的能力又差別很大。之所以要做決策編程，就是把你知識壁壘的風險降低，我有一個人放這里，你必須要讓我能夠理解你在做什么的情況下，實際上你在做的是知識傳遞，那么你在這種過程中，實際上每時每刻都在培養我一組人，而不是一個人了解你的代碼，而實際上你是在培養一組對你這個代碼有修改能力的人，這個效率是***的，從宏觀角度來講，它的效率是非常低的，甚至有過了一兩年之后，你自己再過來看，很可能你都不知道，所以讓一個人保有一份獨有的知識對于任何一個公司都是極大的風險。
很多企業在做這樣的事情的時候都會有這樣的困擾，比較初期的公司，他需要很長時間，那么在這樣的時候，我可能會做很多培訓，可能效果都很小，那么其實真正地讓一個人很有效地承擔方式就是把它放到一個能力的極限應用這種環境下面激發它，在這樣的情況下他自己做可能承擔很大的風險，找一個人跟他一塊兒做，對于有經驗的人他覺得沃德效率降低了，因為你自己做，我帶另外一個人可能效率會很高，那么這個里面有一個宏觀的問題，不僅僅是把工作做完，如果僅僅是這一個標準，我們有很多效率更高的方法，當你在做敏捷時間的時候，讓它變成囤積知識，讓成員整體能力提高，那當這四個放在一起的時候，哪個更高？綜合來看敏捷更高，因為它解決的問題不是單一的問題，我們解決任何單點問題都有更高的效率，但是你想同時解決一些問題的時候，我個人感覺敏捷方法是更高的效率。
左為吳昊先生，右為宋金永先生
【編輯推薦】
