從根本上來說，所有的敏捷開發實踐，諸如TDD（譯註1）、結對編程（譯註2）、持續集成（譯註3）和重構（譯註4），都有一個統一的觀念--永遠不被阻攔。這就好像是一個優秀的撞球選手總要確保他的每一次擊球都能爲下一擊創造好機會，每個優秀的敏捷開發者每有一點進展也都要確保下一步。一個優秀的敏捷開發者決不會走出一步，然後就無法再有進展，或是讓別人沒辦法再有進展。
那你怎麼知道你的進度停下來了呢？如果你無法讓系統運行，進度就是停下來了。如果你不能通過測試，進度就是停下來了。在敏捷世界裏，進度只能由通過測試的可運行系統來衡量。如果系統無法運行或是測試失敗，那麼所有的進度都會停下來，因爲反饋循環能告訴我們代碼出了問題還是一切良好。當編寫的代碼無法執行的時候，就好像是駕駛着汽車卻看不到擋風玻璃的外面。車輪或許還在轉動，但你不知道正在駛往哪個方向，或許你正要駛落懸崖。保持系統隨時可運行就像是保持擋風玻璃的清潔。除非我們能看見東西，否則我們無法取得進展。
仔細想想，例如，兩個程序員正開發一個項目。Jack說他要寫J模塊，而Bob說他要寫B模塊。當Bob寫代碼寫到一個程度就必須要去找J。可是J還沒完成，Bob就不得不等。假如Bob那時是個優秀的敏捷開發者，他決不會讓事情發展到那一步。他會給J創建一個接口，然後用假代碼（stub code）實現它，這樣他就可以使得自己那部分的測試能持續運行，因而可以繼續開發下去。
設想一個四人團隊工作在一個三層架構的管理信息系統上。他們已經通過架構的抽象層次來分好了工。Gerry和George工作在GUI上，Marvin在中間層，而Debeay在數據庫。當增加新功能的時候，Debeay做的頭一件事情就是去改變開發庫的表結構。GUI要等中間層運行起來了才能運行。Debeay已將黑漆塗灑在了擋風玻璃上，整個團隊就像是瞎子開車。假如Debeay那時是個優秀的敏捷開發者，她會發現一種能夠循序漸進的修改數據結構的方法，增加新的列或是表而不用改變舊的。一直到迭代的最終完成，數據結構會達到成品的樣子，而系統在此過程中絕不會中止運行。
保持系統能夠持續運行是第一目標。你絕不會做出一些事情以至於會讓系統被破壞超過幾秒鐘。如果你要做一個巨大的設計改變，你會找到一種方式，讓每一步的改變都微小到可以確保系統能運行。如果你能找到一種方式能保持所有測試的可持續運行，就不會讓系統中止超過幾秒鐘。
這可不是一個容易掌握的觀念。開發者總是習慣於做出一些改變把整個系統搞亂，然後再試圖去一塊塊的拼湊起來。很多人很熱衷於這種體驗。其實，我曾於一個開發者交談，他說把系統撕得粉碎再把它拼湊起來是一個程序員所必需的本事。他爲他有能力做這種事而感到自豪。因爲這對他的自尊來說很重要，我不得不很禮貌的勸說他，他的這種自我成就感是建立在他所冒的風險和爲僱主創造利潤背道而馳的基礎上的。實際上，他對這種賴以生存的能力感到歡喜雀躍。他是一個嗜險成性的人，而且他在拿僱主的財產冒險，這可不是專業行爲。敏捷開發好像一場謹慎的象棋遊戲，不是一個不計後果的code-chicken遊戲（譯註5）。優秀的敏捷開發者爲他們的目標小心的策劃了一條路線，那就是每走一小步都能保持系統的可運行和測試的通過。
一些開發者認爲這樣做效率低而且緩慢。他們覺得先把系統弄亂然後再重組爲一個新的會來得更快些。也許有時候這樣做更快些，然而，這樣做就像是你想要開車去商店，於是就調整方向直指商店，把擋風玻璃漆成黑色，然後不管紅燈和路況就徑直的朝着商店開。如果碰巧能行，你就開得更快。但更多的時候這麼開在路上就會出岔子。
這個目標可以延伸到團隊和組織的各個層面。決不被阻攔意味着你設置好了你的開發環境以至於阻攔的事情不會發生。優秀的敏捷團隊使用不被阻攔的源代碼控制方法。如果Bill有個模塊已經簽出（check out），Bob也可以將其簽出，但第一個拆入（check in）的人是成功的。假設核心團隊正在爲我們打造一個可複用的框架，而我們需要的一些功能還沒就緒，我們會先自己寫好它，等他們好了的時候再使用核心團隊的功能。如果企業架構支持我們的這種迂迴婉轉的方式，那麼我們就只需花上幾天時間來學習它，然後就能忽略企業架構，而讓功能的開發以一種簡單的方式來進行。我們就不會被阻攔。
譯註：
1，TDD，測試驅動開發，詳情請參見“TDD的三條軍規”。
2，結對編程，pair programming，又譯作“配對編程”。代碼由結對的程序員使用一臺電腦共同完成。結對人員中的一位控制編碼，另一位觀察正輸入的代碼並尋找代碼中的錯誤和可改進地方。兩人頻繁互換角色，而且結對的關係每天至少改變一次，以便每個程序員在一天中可以在兩個不同的結對中工作。據Laurie Williams和Nosek的研究表明，結對非但不會降低開發團隊的效率，而且會大大減少缺陷。
3，持續集成，continuous integration。程序員每天會多次拆入（check in）他們的代碼並進行集成，規則很簡單，第一個拆入的只要完成拆入就可以了，所有其他的人負責代碼的合併（merge）工作。爲了避免合併時間過長，團隊的成員會非常頻繁的拆入他們的模塊。因此，XP團隊每天會進行多次系統構建，並重新創建整個系統。
4，重構，refactoring。隨着我們添加一個個特性或是處理一個個錯誤，代碼的結構會逐漸退化，最終會導致糾結不清，難於維護。XP團隊通過經常性的代碼重構來扭轉這種退化。重構就是在不改變代碼行爲的前提下，對其進行一系列小的改造，旨在改進系統結構的實踐活動。
5，code-chicken，密碼雞，一種在北美頗爲流行的益智類遊戲。
（原文鏈接網址：http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeDirectiveOfAgileDevelopment; Robert C. Martin的英文blog網址： http://www.butunclebob.com/ArticleS.UncleBob）
作者簡介：Robert C. Martin（暱稱Uncle Bob）是Object Mentor公司總裁，面向對象設計、模式、UML、敏捷方法學和極限編程領域內的資深顧問。他不僅是Jolt獲獎圖書《敏捷軟件開發：原則、模式與實踐》（中文版）（《敏捷軟件開發》（英文影印版））的作者，還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主編，並與James Newkirk合著了XP in Practice。他是國際程序員大會上著名的發言人，並在C++ Report雜誌擔任過4年的編輯。