今天很榮幸能夠在亞太軟件研發團隊管理年會上采訪到姜志輝先生，請姜先生先給我們介紹一下你自己？
我是一個喜歡寫軟件的人，喜歡軟件行業的這樣一個人，有些時候人很難找到自己和自己興趣愛好相關的這樣的一個行業，幸運的是我找到了自己，就是把我自己的興趣、我自己的愛好和我自己的工作能夠融合在一起的。所以如果要做一個自我介紹，我是一個快樂主義軟件的消費者。
那目前我們也知道國內采用敏捷方法來開發軟件的團隊越來越多，但是我們也了解到很多團隊只是注意到這個敏捷的一種形，而沒有注意到它的神，所以說我們想了解一下你對此有哪些自己的想法或者建議。
我個人建議是這樣的，要想能夠應用敏捷必須有個思想上的轉變，這個轉變對于很多領導層來說非常的難。因為什么呢？因為需要在他的字眼里去除這兩個字，“管理”這兩個字，我認為在敏捷里邊它有一個很重要的概念是領導，而不是管理。它更關注于人，更關注于人的本性，而且也關注于經濟學，所以我個人認為，如果要學習敏捷，我認為應該有兩點，第一點你要關注于人，關注于團隊，第二個部分是關注于它背后的軟件經濟學，就像我做一個事情，怎么樣做可能會更合理？
舉個例子說，有很多人會有這樣的一些誤解，我前一段時間就有人問過這樣的問題，說用了敏捷是不是不寫文檔了？這是一個誤解。敏捷本身不是不寫文檔，它只是說做文檔的目的是為了什么？是為了溝通。那么好了，就溝通這么一點來說，有什么樣的方式能夠更好的體現溝通呢？如果我們人很少，大家坐在一起，七八個人，三五人一個小團隊，這個時候我們會發現，如果文檔的目的是為了溝通，面對面的溝通、交流是最好的，所以這個時候應該取消文檔。
但是如果我面對的可能是上百人的一個大團隊，而且是分布式的，這個時候你會發現，如果面對面的溝通交流，效果不是那么好，其實不如文檔的效果會更好，所以這個時候你會發現能夠表達溝通意圖的那個文檔會比我們說的“溝通”，就是面對面的溝通交流會更好。所以敏捷關注的是背后的本質，它關注的是如何才能更好的達到實效，這是敏捷。
所以我說要想應用敏捷必須有兩點轉變，第一個點是對于軟件團隊基礎建筑材料的不同，很多人把軟件開發一直比喻成建筑，實際上不一樣，它們的材料不一樣。構建軟件的基本材料是人。是人就有缺點，就會有弱點，所以應用敏捷、學習敏捷首先第一個是對人的認識，關注于人，關注于團隊；第二點是可能要關注于敏捷背后的一些經濟學，這是我個人的一些建議。
很好的建議，目前采用敏捷的團隊很多也在用Scrum，很多人說，一提到敏捷，那就是Scrum，對于精益，對于XP，包括對于看板，對于Crystal卻不是非常的了解，那你能不能簡單給我們大家介紹一下它們各自的特點。
如果說介紹每一個各自特點，就像介紹每一個公司的每一個方法的招式一樣，因為它們是實踐。那么敏捷聯盟之所以能夠成為聯盟，是因為有很多方法融合在一起。包括我們介紹這個敏捷的宣言，敏捷的原則，是因為在宣言這個部分，它們的價值觀部分達到了統一。然后其次是在原則上達到了基本的一致，而在方法上它們各有各的不同，所以它們的關注點是不一樣的，比如說Scrum它本身是一種開發框架，關注點是迭代的框架，嚴格的說，它是一個迭代閉環的關注點。
而水晶方法論，它可能關注的是一個什么概念呢？它可能更多的是關注如何能構建一個好的團隊，一個團隊它應該具有什么樣的屬性。包括極限，像Kent
Beck。他們在把自己的一些成功的實踐拿出來和大家分享的這么一個方法集，尤其到了第二版，像極限編程的第二版，它提出它自己的價值觀、原則還有實踐。包括還有一些我們從日本的經濟方法里邊提練的一些方法，它們是方法不太一樣，但是本質是一樣的。
如果我個人應用的話，我的推薦是，如果要想使用敏捷，可以從Scrum開始，為什么？因為它是最簡單、最輕量的一個管理方法，而且它是從管理入手的，但是如果要想應用的話，我個人建議，可以從極限編程入手。我們的開發團隊，可以自己去應用，可以不通過管理層。比如說你使用測試驅動開發，你使用重構，你使用持續構建，我想管理團隊不會說阻止你應用這些實踐，所以一個團隊，它可以不通過管理層，而使用這些的敏捷實踐，最佳實踐。
如果通過管理層，Scrum是一個可以推廣的一個方法，而關注于團隊的建設我個人認為像水晶方法論可能會更合適一些。但是它們背后的本質，那個才是我們最需要關注的東西，實踐的手法是我們用來進行借鑒和學習并且需要加以改造的。
現在很多組織或者是企業都在，可以說在盲目的采用敏捷方法，以為它可以去解決傳統方法的所有的弊端，遇到的所有的問題，但是你也知道，結果往往并不是非常的如意。那么您個人覺得敏捷無法解決的問題主要有哪些？
敏捷首先無法解決的問題是思想的瓶頸。因為很多人在使用敏捷的時候，原本的出發點就錯了，比如說我作為一個管理者，我為什么要使用敏捷，我是為了提高生產效率，提高質量，說白了它就是期望以更低的成本，完成更高質量投資回報的這樣的一種方法。它希望是這樣一個東西，它本質的思想沒變，換句話說，它一開始就把敏捷當作一個工具，它在本質上，在思想上沒有發生改變。
比如說他們沒有關注于背后的人，沒有關注于以人作為基礎的團隊，也沒有關注于軟件經濟學，沒有關注這些最基本的價值觀和原則，而一上來就使用這樣的一些方法，所以我說這個是很多團隊最糟糕的部分，任何沒有達到團隊思想統一的流程，都會淪為一種形式。所以我說，最難的部分是這樣的：他們沒有關注于底層的這個真正的背后的思想，而關注于它的方法，或者形式。那么我們說這是敏捷，是很多人在敏捷失敗的最基本的原因，不關注于本質。
那么很多時候，我們的研發團隊自己可能也是用了敏捷的思維，敏捷的方法。但是管理層卻沒有完成轉變，所以說這種時候，常常會存在一些碰撞。那么在這個時候，敏捷團隊的成員，或者是管理層應該是各自怎樣，或者是去如何對待這種碰撞？
提到這個問題，我想起祖爾•索伯斯基在《祖爾說軟件》里邊，在博客里邊曾經提到過這個觀念，說如果作為一個計算，作為一個估算，程序員和管理者兩個之間發生了沖突，這個時候怎么辦呢？我記得祖爾•索伯斯基當時提出的概念是這樣的，你給出你自己真實的想法，然后讓時間去證明它。所以不管是一個開發者還是一個管理者，我認為爭吵是不必要的，最好的方法就是實踐。
舉個例子說，對一個東西它是否能產生這樣的效果，那我去實踐，我是一個開發者，我用實踐來說話，我用實踐來告訴你，這樣一個策略性開發，確實提高了我的代碼質量，給了我一個更容易理解、更容易溝通，而且變化更靈活的這樣一個代碼，而我以后適應變化也非常的好，這個用事實說話。而作為一個管理者來說，它更應該關注的是結果，就是我做這樣一件事情，它給我帶來什么樣的結果，而不是它所謂的形式，一定要放開。
因為作為一個管理者來講，作為一個程序員來說，它首先是需要尊重，而尊重是建立在什么基礎之上呢？是建立在事實的基礎上的，所以我個人建議無論是一個程序員還是一個項目經理，當他們有沖突的時候，最好的方法就是用實踐來證明你的觀點。
證明給你的管理層？
沒錯。
那另外一個問題就是關于在日本劍道里面有，所謂有守、破、離三個方法。那所謂守，但是怎么來講？就是在我們采用敏捷方法的過程中，其實大多數的組織和團隊，還都是只能達到一個守的階段？很少有能達到第二個階段，就是破，那更不用說達到第三個階段，達到離的階段，那你認為應該如何做才能去達到第二個階段，達到破這個階段？
達到這個階段有幾種方式，第一種方式，我覺得你必須經過成千上萬次的演練，就像我會投籃，我要有球感，我必須經過不斷的投籃練習，不斷的得到失敗，從里面得到一些經驗教訓，這個是不可以越過的。所以我說，你要想達到破的境界，必須經過守這個階段。但是如果老是經過守，我們的成本是不是太高了？所以有些時候我們可以請一些教練，就像宮本武藏在寫《五輪書》的時候，他自己本身是一個劍道高手，為了達到更高的境界，他找禪師來幫助他找到劍術最高境界的本質，所以劍道最主要目的是能夠戰勝對方，就是在這一點上能夠得到認識。因此我認為，通過教練，通過外部的一些環境，一些人員可以給我們提供幫助。
另外一個方式，就是能夠不斷的審視自己，反思、總結、改變，這很重要。比如說我今天用了這么一個招式達到這樣一個效果了，那么好了，經過一段時間，我自己總結，我為什么能夠做，我背后的目的是什么？不斷地問為什么，不斷地反思，不斷地改進，不斷地總結，所以我要說的概念是這樣的：如果要想達到破的境界就必須經過守的境界，但是要從守達到破，不是你不經過思考的，我認為這種思考，可以尋求一些幫助，而反思改進是最好的方式。
自己要主動，有時候也要借鑒一些外部的力量？
外界的力量，可以借助一些外界的力量，因為外界的力量它看的可能更清楚，在你偏離方向的時候，它能幫你回到正確的位置上去。
對，這就是教練的作用。那我們也了解到像80/20法則這個在軟件開發中是一個非常有趣的現象，也是一個有趣的經濟學的問題，那敏捷團隊如何才能真正交付客戶價值？
尊重，首先是尊重，軟件開發，我也一直在提到一個問題，軟件開發是一種博弈。博弈有很多種，那么軟件開發本身，它不是一種零和的博弈，什么是零和博弈？就是你犧牲某一個人的利益，以某一個人的付出作為代價來獲得利益，當兩個人加到一起的時候，它的結果為零。實際上有些時候，我們很多團隊是這樣的，有一段時間，我經常聽到很多人提出這個問題，包括會間吃飯的時候有人提到這個問題。什么是好的軟件？就是你做這么一個東西給用戶，那么用戶認為它很好，沒有發現里面的問題，這就是一個好的軟件。我們認為這個認識是錯誤的，這是一種零和博弈。一旦這種東西進入一種循環，一種惡性循環，往復的這樣一個博弈，馬上進入一種零和博弈，所以軟件開發不是零和博弈，就是它不是說誰占了誰的便宜，或者誰的收益是以另外一個人的付出作為一種代價的，軟件開發應該是一種非零和博弈，是雙贏的。大家共同來完成這樣一個事情，每個人在里邊獲得自己的價值，是這個樣子。
那么在這個基礎上，我們會發現，我們需要相互的不斷的溝通，交流，反饋這樣的一個過程。舉個例子來說，我們在很多開發團隊里邊，用戶會一直要求看我們的文檔，或者看我們的進度，對我們進度進行評審。但實際上我們很多客戶它真的會看你的文檔嗎？你的文檔交付給它，我們大家都知道，我交付那個文檔有些時候是沒有任何意義的，而客戶其實有些時候，拿著文檔不看，那它為什么要求文檔？實際上是對你沒有信心。
找到一種安全感？
對，所以只要你能夠通過一種方法，不斷的給他建立信心，你們兩個之間就會有尊重，那么有了尊重以后你們就會有了信任，有了信任就會有了溝通。那么你會發現，你們交互是雙贏的，你交付給用戶，通過反饋交付價值，而用戶通過和你溝通，來創造符合它自己的更高的投資回報，是這樣的一個過程。
那我們也了解到，快速反饋是敏捷的一個基本的要求，那為了做到快速反饋，當然最有效的溝通是最關鍵的，這個問題是怎樣才能進行最有效的溝通？
有些時候確實存在著很多問題，就像一個優秀的歌手和它的制片人一樣，一個電影的投資人和一個非常棒的電影演員(音樂人)，它們之間一定會有沖突，因為一個是追求藝術的，我是一個搖滾愛好者，我追求藝術，那些人根本不懂我的藝術。但是作為一個投資人來說，他要求的是商業回報，所以它們兩個之間一定會有這樣的一些問題。
同樣的方式，我們也會有這樣的一些問題。前兩天一個朋友給我又推薦了一個笑話，這個笑話概念是什么樣子呢？是這樣的，就是天很熱，夫妻倆，然后這個妻子在里邊去洗澡，洗完澡之后，這個丈夫也鉆進去洗澡了，妻子剛出來，門響得很急促，妻子就很著急，拿過一個圍巾把自己給圍上了，到了門口，有個男子，拿了800美金，看到妻子就說，如果你把那件衣服脫了，我把這個800美金給你，妻子猶豫了片刻之后把衣服脫了，拿了800美金。過了一會兒，丈夫出來了。丈夫說剛才是誰敲門啊？妻子說是誰誰來敲門了，他說那他有沒有提到他還欠我800美金的問題。那么看了這個笑話以后，說明一個什么問題呢？就是要和你的合伙人和你的伙伴分享你們之間的知識，這樣才能避免一些不必要的風險。
所以剛才我講了兩個東西，一個是什么呢？一個是音樂界里邊你的投資人和演員(音樂人)之間它們有的沖突。那么另外一個，一個小笑話是夫妻之間的東西。但是不管怎么說都是在一起合作的人，那么合作的人之間總會有一些分歧，這是不可避免的，夫妻之間也會吵架。但是最關鍵的問題在于你必須和你的合伙人一起來分享，否則你們會發現你們失去的東西會很多。
舉個例子說，如果我們兩個人在一塊開發，我加班加點，我自己閉關，通過一個月我終于解決了一個難度很高的問題，結果在我匯報的時候，其中有一個人對我說，那個問題在兩個月之前早已經解決了，這就是我剛才說的，如果不溝通，那么你會發現，你們浪費的時間、人員、這種精力、成本這樣的一些浪費。
那如何讓這種溝通，彼此之間的溝通更加有效果一點或者更加有效一些？
我覺得首先要學會把一個團隊建立成一個能夠相互尊重的團隊，某一個固定的方法可能很難。舉個例子說我的團隊采用的方法是什么，是以學習和游戲為主的這樣的一個方式，不一定適于你的團隊。舉個例子說，我的團隊每天下午的五點會在一起打游戲，但打的游戲一定不是單機版游戲，是團隊合作游戲，比如說魔獸世界，比如說CS，好多。比如說在玩兒魔獸世界時，也需要幾個人相互的合作。
那么這種合作，就是你的法師，你的戰士，你的盜賊，還有包括你的牧師，它們之間一定要相互合作的。中間任何一個人不到位，你是很難完成這個關口。好的，如果失敗的話，我們會發現最后我們這個游戲玩兒完了以后很多人就會總結為什么？誰沒有到位，建立起這樣一個相互溝通，團隊相互之間的交流的這樣一個氛圍。包括我們一塊去攀巖，一塊去騎馬，一塊去爬山，這些方式都是幫助我們團隊建立溝通，建立交流，建立團隊的這么一個非常好的方法，我的團隊是這樣用的。
但是到了你的團隊是怎么做得呢？我想應該有更好的方法或更好的實踐，但是我堅決反對以硬性的條文來規定我們團隊之間應該進行溝通的，否則就像我剛才說的就會變為形式了。
還是應該是一種自然的真誠的溝通？
對，自然的真誠的，最好的話就是團隊之間建立起一個相互尊重的、相互信任的這么一種關系。怎么建立？可以從其它的游戲規則里面去學習，打游戲也好，打籃球也好，只要是一種團隊活動就可以舉行，只要是這樣的一種以團隊為基礎的非零和的博弈，只要是這種博弈，都可以學習。比如說我們一起看籃球，比如說我們一起看橄欖球，我記得米盧在世界杯之前，給國家隊看那個橄欖球的電影，其實你會發現我們的軟件開發完全可以像那種以團隊作為藝術的，非零和游戲里邊的任何一款進行學習，找到相互溝通的方法和密鑰。
很多東西其實都是相同的。另外一個問題是關于測試驅動開發的，我們也知道測試驅動開發是極限編程中十分重要的一個實踐，從第一次系統提出TDD，到現在差不多也有十多年了，其中也是爭論不斷，但是很少有團隊能夠真正的去應用這個測試驅動開發，并通過測試驅動開發來去增強信心，你認為在這個整個的過程中，大家可能遇到的困惑，或者困境是什么，那開發的團隊應該如何開始實踐TDD？
沒錯，問題有幾個，我不能全列出來。舉個例子來說，有的人為什么使用測試驅動開發？因為測試驅動開發流行了，所以我使用測試驅動開發。為了測試驅動而測試驅動，這種東西一定會失敗，同樣的方式，為了敏捷而敏捷一定會失敗。
第二個部分，很多人認為測試驅動開發是浪費時間的，浪費我的成本的，很多人在心里上去排斥它，就是一個問題。思想上沒有達到認識，它不知道測試驅動開發給我們帶來了什么樣的好處，所以有一個問題，測試驅動開發到底給團隊帶來什么樣的好處，這個在思想上一定要達成共識。舉個例子說，我們說測試驅動開發本身它不是測試，它不是測試。我很多人說，測試驅動開發是白盒測試或者黑盒測試。測試驅動開發它不是測試，它是開發，它是設計。它有一個很好的一個閉環。
首先我來解釋第一個問題，說測試驅動開發浪費時間，實際上把我們軟件開發分成幾個流程，需求、分析、設計、實現、測試，這么幾個部分，如果再加上一個調試，什么部分最浪費時間？我想很多人會選擇調試，會選擇設計，會選擇分析，但是少有人會選擇開發，也就是編碼，少有人會選擇這個部分。因為編碼僅僅是當你的思想成熟的時候，然后進行開發的，所以作為測試驅動開發來說，你可能只是加上三行或者是五行就可以完成這個部分了，因為測試驅動開發代碼很少，所以你耽誤的時間只是幾分鐘而已，但是你獲得好處是什么，你會發現你好像幾乎不需要調試了。
當然這個可能有點絕對，但是這是從我個人的角度來看，幾乎不需要調試了。
第二個部分，它給了你一個立即進入狀態的這樣的一個規則，就像我們很多人說，比如說像我原來開發的時候，這個地方應該怎么進行設計？我會花很多時間去學習，我會去思考。在思考之前我會去學習，買一些書籍，或者查一些相關資料，看看哪一個方案更好，那么最后什么時候去決定這個設計呢，當時間到的時候，我沒有辦法了，然后我趕快倉促的給出一個設計來。但是你會發現測試驅動開發是一個什么概念呢，一開始以故事的方式，以用戶使用的方式來描述出你的，你是應該怎么去用的，那么很快通過代碼把它表述出來，通過這種代碼，說明這個代碼是應該這樣設計的，所以它給了你一個方式。
就像我爬山的時候，在我的前方定了一個大長釘，我的目標在那個地方，而且我能快速前進，那么好了，當我快速前進的時候，我完成了一個部分，緊接著下一步，所以它非常符合人性，人性是什么？人總是希望能大踏步前進，但是人能夠做的事情是小步前進，而且我們會發現如果我們不能飛翔，那就快速的移動我們的步伐，達到飛的狀態，所以我認為這是測試驅動開發的本質。
另外一塊，從面向對象的這個角度來說，它也非常好。比如說我們在軟件開發里面講過一個什么？叫做高內聚低耦合。高內聚怎么解決的？我記得Peter曾經講過一個概念，說什么呢？DIY原則，你把你自己想象成這個對象，然后你在那個世界里面，在那個領域里邊，你應該具有什么樣的職責或者行為。那么好的，我們會發現，用測試驅動開發，能夠封裝意圖，就是那個對象到底要干什么，它的意圖跟行為是一致的，好的，用測試驅動開發來封裝我的意圖，然后用一些手法，比如說重構，比如說設計模式，來解耦對這個意圖的實現，它是非常符合面向對象的原則的。
第三個部分，測試驅動開發本身又能夠與持續構建很好的形成一個反饋的閉環，所以我們說，如果使用測試驅動開發，能夠認識到背后的本質，它符合經濟學，因為它能夠形成一個測試閉環，能夠快速的找到問題所在，來節省我們的成本。它符合設計本身、高內聚低耦合的原則。我們會發現測試驅動開發本身是從能夠讓你符合人性的這個角度來出發的，如果能夠認識到，然后快速的去做一些實踐，實踐過程中不斷地反思，不斷地反思再去快速的使用。
那么我的建議是這樣的，就是每一次使用不要把它當作一種形式，認真地去體會測試驅動開發的好處。當然了，剛剛使用的時候會有很多問題，因為改變一個人的習慣會非常非常的難，這個時候需要一定的勇氣，就像我戒煙一樣，我已經戒了三次煙了，到現在為止還是沒有戒掉，所以改變自己的習慣，需要點勇氣，不過有一個好消息是應用測試驅動開發比戒煙容易的多。
非常好的類比，最后一個問題是關于總結回顧的。我們也知道總結回顧是自我改善的一個基本的方法，許多團隊都會定期，現在都已經習慣定期舉行一些回顧會議，但是遇到的問題是，問題還是層出不窮，而且很多問題也是，你根本沒有辦法去好像是根治它們，那么作為您，如果說去面對這樣的問題，您認為應該去如何去避免這種現象？
我覺得有一個很重要的問題是，很多團隊它不斷的回顧，不斷的總結，但是從來不改進。我們團隊有一個很重要的概念就是持續改進，反思改進，就是遇到了問題以后，我們找到問題，找到問題，找到它。然后去解決這個問題背后的一些原因。比如說我們現在很多團隊都是這樣的，一個項目完了，就去評審，評審完以后給出很多的意見，說我們什么地方不成功，然后我們會列出很多條例，列完就列完了，我們再也沒有去改進它，這個是很多團隊最可怕的問題，因為很多時候我們不是不總結，是總結了從來不改進。
所以這里我想用兩段話來回答這個問題。那么第一段話，是Kent
Beck的話：“保持專注、適應、改進”，就是那句話，“保持專注、適應、改進”
！所以最后這個改進是要有的，不能光反思總結而不改進。第二句話是祖爾說的一句話：“軟件開發是這樣一個過程，你瞄準一個目標，瞄準、臥倒、射擊、移動...”
，所以我們說在軟件開發過程中，千萬不要想大踏步前進，一步一步的前進，那么我們發現自己身上有一個問題，改正它，讓它變成我們的一個習慣，再發現一個問題，然后再改進它，再變成我們的一個習慣。
所以在此我也給想使用敏捷的人一個建議，就是我們在使用一個實踐的過程中，有些時候，不要一上來就把所有的實踐都堆過來，這個時候更改非常非常難，找到我們最關注的部分，然后在這個部分的思想價值觀達到了統一以后，去逐漸的去改變它，形成一個習慣，再加上一個習慣。什么是優秀的團隊？優秀的團隊只是有幾個優秀的習慣而已，但是這些習慣的養成非常非常難。
還有一個好消息是這樣的，在敏捷的實踐里邊很多的實踐是相互套接的，就像剛才我們討論了很多問題，它們都是離不開的，比如說溝通，反饋，交流，測試驅動開發，持續構建，它們都是連在一起的。那么迭代本身緊接著后面就是反思改進，反思改進完了下次迭代。迭代過程中我們需要測試驅動開發、持續集成，再后面圍繞著一個迭代的過程，它們之間是相互連接的，只要你有一個好的實踐，并且體會到了，你馬上會有第二個，第三個，第四個實踐。