Kent Beck談敏捷開發的應用和價值觀

    Kent Beck做了許多與敏捷軟體開發相關的幕後工作，其中包括JUnit測試框架和極限程式設計。Kent還是在物件導向程式設計中應用設計模式的先驅。InfoQ的Kurt Christensen最近採訪了Kent，並詢問了一些關於敏捷軟體開發現狀和未來定位的問題。

    InfoQ: 您目前的工作是什麼？

    Kent Beck (KB): 前不久我剛完成《Implementation Patterns》一書，該書介紹瞭如何通過程式碼進行溝通。它將在2007年第一季度上市。現在我正在開發JUnit的新版本。與此同時，在我現在參與的許多專案中，我將很多時間花在利用付費客戶端進行遠端結對程式設計上。

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

    KB: 我所見過的大多數反對意見來自於程式設計師個人而非機構或整個行業，這些程式設計師通常不願向機構中的其他成員負責。我想，這些針對行業的反對意見，反對的不過是敏捷開發這個詞的含糊使用，而不是任何特定的流程。

    客戶看起來並不在意更少的缺陷和更可預測的時間表，以及程式設計師們是否願意溝通和貫徹他們的承諾。當客戶開始期望這些，而程式設計師們卻不打算這麼做時，問題就產生了。用敏捷開發標榜自己，卻不去遵循敏捷開發的價值觀和原則，最終將導致程式設計師與客戶間糟糕的關係。

    InfoQ: 作為一個社群，我非常擔憂這種情況，當敏捷開發起作用時，我們誇耀自己，而敏捷開發行不通時，我們彼此踢著皮球並且說這樣做不“正確”。如果敏捷開發更像是價值觀而非規範或特定的習慣，那麼一個機構如何才能知道何時他們真的在進行敏捷開發呢？如何才算正確地進行敏捷開發呢？

    KB: 你描述了人們對結果不滿意時的反應，但你忽略了人們從中學習到經驗的機會。我想，因為我們怕難為情，我們已經錯過了許多分享和學習的機會。

    有時我們會想，“假如我是一個完美的程式設計師，這個專案應該就會非常成功了。如果專案不是輕鬆完成，那我就算失敗了。”這種心態或多或少地影響了我們的行為。

    而且確實，當你承認失敗時，敏捷開發社群中的人們會斥責你的失敗。在避免這種令人膽戰心驚的結果的同時，我們與那些有用的心得失之交臂。

    成功的專案需要許多因素以及彼此的同心協力，一個人無論多聰明或者多麼卓越，專案的成敗都不可能由他一個人的技術能力和意志力決定。無論如何，溝通、團隊建設、時間安排、與公司其它部門協作、甚至編碼竅門等，這些東西都是我們可以從失敗的專案中學到並應用於未來專案中的。如果我們願意分享心得（而不是我們的失敗感），那麼作為一個社群，我們還可以做得更多。

    敏捷開發一詞的含糊性會成為一個障礙。問“我們做得正確嗎？”（或更可能的情況——告訴別人“你做得不正確！”），這個問題並沒有什麼價值。“我們在學習所有我們能學到的嗎？”和“我們需要改變自己來最大限度地迎合公司的目標嗎？”這兩個問題更有意義。如果敏捷開發成為一種意識，那麼我們並不真的需要衡量正確與否的尺度了。你工作時有敏捷開發的意識嗎？你嘗試過從多個角度看問題嗎？你會突破桎梏去思考嗎？你會參與到團隊交流中，共同向一個有價值的目標去努力嗎？你會以坦蕩誠實的胸懷和負責任的態度向你們共同的目標努力嗎？你參與的流程如何在組織中起作用，其意義遠比一個敏捷開發專家對流程的思考要重要。

    InfoQ: 在您幫助機構向敏捷化方向成長的經驗中，這些問題有一些明顯的規律嗎？為什麼機構通常總是無法正確地開展敏捷開發呢？

    KB: 通常的情況包括我們缺少溝通，團隊和成員彼此孤立，辦公室裡沒有交流，某個人有團隊所需的特長卻沒人願意與之合作，或者無法表達清楚他們最近的工作對公司的價值等。

    機構層面的失敗往往是由在流程定製和融會貫通方面的無能為力導致的。嘗試直接將別人的模式照搬到你的組織並不會起到太好的作用。這樣做將遺漏上一個成功案例中的太多重要細節，同時也會忽略你公司的特殊情況。生搬硬套的敏捷開發流程並不敏捷。基於敏捷開發原理的流程其價值在於，你能夠將原理應用在針對你的情況的特定流程上，而且一個額外的好處就是你能夠以此心得來改變你的組織。這才是“定製”。

    從個人角度來看，我認為最大的問題是——程式設計師壓力太大。我曾經做過一次“放鬆工作(Ease at Work)”的討論，你可以在Google Video搜尋中找到視訊。除非程式設計師能夠保持一個清晰的自我認識，否則關於後續技術改進的探索將在很長的時間裡一無所獲。我確信這裡同樣存在一些屬於機構的大問題，但問題的根源在這裡。

    InfoQ: 在向機構介紹敏捷開發時，您會首先展示例項，然後藉此來說明它的價值，或者恰恰相反？又或者在一開始就同時舉例和說明價值？當您打算嘗試去改變一個機構的價值體系時，您會選擇哪種方式呢？

    KB: 我首先從人們已有的正面經驗切入（這種方式被稱為肯定式探詢），並瞭解這些經驗如何應用於現有情況。這將引發三個層面的討論——價值觀、原則和習慣。

    改變一個機構的價值體系需要強有力的支援，這種支援往往來源於機構中希望變革的高層。我傾向於嘗試去引導這些機構發生改變，但這一般不起作用。相反地，我先與他們共事並按照他們的方式做好工作，當我通過這種方式首先表達了我對他們的尊重之後，效果才是最好的。這樣做，我仍舊保留了我的價值觀，原則和習慣。隨著時間的推移，我們彼此取長補短。

    InfoQ: Scrum社群借其認證過程（譯者注：Scrum社群是澳大利亞的一個關於敏捷開發的技術社群，它要求使用者展示自己後，才向使用者提供帳號。）在創立一個品牌。您認為這種方式有助於使敏捷開發在大機構中如魚得水嗎？通過這種方式推行敏捷開發是好是壞呢？

    KB: 我認為這種方式使得專家們要對自己的技術和成果負責。傳統的認證過程不過是做個測試，提供一篇論文，我不認為這樣的認證過程能有什麼用。另一方面，其它的專業領域也存在有意義的認證過程。如果你是持證的內科醫生，這意味著你通過了相應的認證。儘管這個與計算機中的認證相差甚遠。認證的主考官都是專家，它的過程耗費很多時間和金錢，需要大量的研究和一次在實踐中的示範來展示對知識的精確掌握。

    尤其在大機構裡，認清名字能夠幫助你找對辦公室的門，但它仍舊有著照本宣科的問題。如果這被認為是可接受的方式，它就會開始被使用。而一旦辦公室發生了一些必需的重大調整，那麼這種方式將失去可信度，名字的價值也就不存在了。

    InfoQ: Martin Fowler前不久寫了一篇名為“語義傳播(Semantic Diffusion)”的文章，在文中他描述了“敏捷”這個術語的變化。當“敏捷”成為另一個口號時，敏捷開發會有什麼改變嗎？有沒有辦法來避免這種情況，從而保持理念和語言的生命力呢？

    KB: 當敏捷變成口號以後，人們會尋找最簡單的辦法來判斷何謂敏捷開發。這個語義傳播的隱喻的問題在於，意義會隨時間弱化的觀點忽略了那些明確並且成功的使用術語的情況，這些例子不斷出現並保持著術語的原有含義。我一直都在關注這樣一種情況，“敏捷”屬於一個吸引眼球的詞，那些一點都不理解它內涵的人也可能會使用它。誰不願意被認為是在做敏捷開發呢？敏捷開發這幾個字說起來輕鬆；有價值的思想往往附帶著諸多的責任。這就是我們探討“負責任開發”的原因。在英語中，責任有附帶著負擔、要求或者義務的含義。有價值的思想意味著許多東西，但同時它並不是那麼輕鬆自由的。

    當你將思想公之於眾時，別人如何利用它是你無法控制的。我能做的僅僅是盡全力去保留思想的火種，誠實地報導社群中發生的一切。

    InfoQ: 自您完成《Extreme Programming Explained》（中文版《解析極限程式設計：擁抱變化》）第二版至今，您有沒有發現可以被加入到第三版中的新的價值觀，原則或習慣呢？

    KB: 關於XP，我並沒有什麼新的體會。但我在工作中發現一些對做決策有幫助的原則。

    我已經開始參考一些並沒有列入第二版的原則了，這其中包括問責性和透明度。我探討了這兩大出自於測試驅動開發的原則，對它們加以明確並隨即驗證。最終，我發現這些能夠降低流程損耗的原則非常有用。

    隨著實踐的逐步深入，我不久前使用的最重要的東西就是追蹤和分析軟體的真實使用狀況。目前在我參與的一個專案中，我們實現了對用途的追蹤，這好比在黑暗的房間中點亮所有的燈光，那些使用者切實使用的功能將一目瞭然。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-567136/，如需轉載，請註明出處，否則將追究法律責任。