換一種思路 極端編程不再神秘
作者：Roy W. Miller
本文選自：IBM DW中國
2003年03月13日
在XP講師兼開發人員Roy Miller講解“熱門”的XP實踐之前，他將為您展示如何轉變您的思路，以便您可以開始使用XP。這并不是一項輕松的任務—XP需要一種與大多數程序員和業務人員完全不同的思維方式。如果您正面臨著這樣的問題，那么
Roy 會幫助您解決這一問題。
我沒有計算機科學學位，因此我無法從直接親身體驗的角度來討論大多數程序員所獲得的“傳統的”培訓。更確切地說，我曾經同許多程序員和業務人員在多個軟件開發項目中一起合作過。因此，我想我可以明智地說出當他們設法開發軟件時是如何想的，以及是如何做的。讓我首先談論一下程序員，因為我就是其中的一員。
了解編程
我的父親是位醫生。他曾多次告訴我（我都記不清次數了），“去讀醫科學校，畢業后去實習，在實習中學著做醫生�！蔽蚁�，大多數計算機科學專業的畢業生也都類似。他們帶著很多理論知識（其中一些是好的且有幫助的）離開了學校，但是對于如何編寫好的代碼卻所知不多。由于我沒有計算機科學學位，因此也就沒有大多數理論知識。有時候這會讓我很傷心，但大多數時候不會。
當我開始編程的時候，我22歲，剛剛走出學校。Andersen Consulting對我進行了培訓，老師們將我領進了門，而我好不容易才“蒙混”過關。大多數人都經歷過這個過程：他們在工作的過程中學習編程，并且大多數人通常都身處于公司環境。遺憾的是，他們的師傅和老師也是這樣過來的。習慣、術語和偏好（大多數都不是很好的）就這樣代代相傳下來。最后，大多程序員學會了如何盡可能快的完成工作。
程序員中似乎存在著四種行為模式：
· 程序員不知道如何同業務決策者很好地交流。
· 程序員期望出現教科書式的問題。
· 程序員喜歡獨自工作。
· 程序員認為測試是編碼后的活動。（有關測試的內容請訪問《細說軟件測試》）
業務培訓
業務人員有自己的培訓，但是它同程序員接受的培訓有著巨大的差別。但結果是類似的：業務人員習慣于用危及其軟件項目的方式工作。
進行業務的費用
負責預算的業務人員整天都在計算業務費用，但他們似乎不知道如何考慮為什么他們需要軟件。通常，他們對于特性的業務優先級，或者那些特性對其業務的貨幣價值（直接的或間接的）并沒有實際的概念。對于較低級別的項目管理人員和公司領導而言，這是可以理解的。
在許多公司環境（尤其是大公司）中，很容易看到底層下屬如何看待高層管理人員通過規章制度進行的管理。高層傳達一些命令，只要求底層下屬執行它。負責管理項目的人只知去做，而不知為何去做。通常公司并不鼓勵他們進行思考。因此，當下達了一項命令時，他們只需服從，而為什么他們應該或不應該做什么的詳情只能是那些企業高層人事考慮的事情。
但是，恐怕并不是高層的英明人士做出的決策總是正確的。許多業務決策都是根據什么“熱門”或者什么最能引起新聞界的關注而決定的�！叭绻衅渌径荚谧�，我們也應該做”。這稱為“隨大流效應”。問題在于企業領導對軟件的認識是錯誤的。他們認為它是費用開銷，而不是花費一些費用的資產。他們認為它是“無可避免之災禍”，或者是生產的手段，而不是策略優勢。
我不希望參與
據說業務人員有進一步“參與”軟件項目的趨勢。通常他們根本不太參與這些項目。軟件開發人員可能會偶爾詢問他們一些問題，但是該過程真的沒什么意義。項目通常是從分析設計開始，即使在開發團隊不使用瀑布模型變體的情況下也是這樣。這是最需要業務人員參與發言的階段。但是技術團隊通常都希望業務人員能回答所有問題�！艾F在就告訴我，這個軟件一年以內需要做什么。我們會告訴您，您可以在將來改變您的想法，但是這只是開玩笑。您現在做的任何決定都是一錘定音的�！�
難怪業務人員會很緊張。他們不得不就他們不知道的東西進行明確的陳述。這使他們幾乎不可避免地與 IT 團隊進行某種達爾文式的爭論，在這一過程中，業務人員把材料往墻上一扔，希望開發人員把問題解決。協調的創新活動沒有秘方，是嗎？
企業“拔河”
誰都有強烈的抵制約束的心理。作為項目管理人員，您的老板把上述一大堆難題都推給您處理，而他卻不管了。您必須取悅于每個人，包括您的系統必須同其打交道的其它部門的職員，不管他們是高級職員還是普通職員。您肯定會在什么地方得罪某些人，并且使某些人不滿意。
打破模式
隨著時間的推移，大多數公司都“陷入”了這種行為。得到的結果是軟件項目使人疲憊不堪，可是當項目完成時，通常都不會使任何人滿意。
那它不是無可救藥了嗎？您不是永遠都陷于困境了嗎？是的，如果您還不開始采取其它行動的話。我不是思維過程的專家；我只能提供一些經驗之談。有時候，我認為您應當先嘗試著換一種思路，然后影響您的行為。但是，大多數時候這對我不起作用。我必須先采取不同的行動。我的思路才能隨之而來。對我而言，最佳的途徑是在采取不同的行動時有意識地改變我思考問題的方法。這就是 XP 可以幫助您的所在。
XP需要有別于標準培訓的行為。要了解由其產生的最佳可能結果，以及判斷其是否適合于您和您的組織，唯一的方法就是在一段時間內使用盡可能多的（最好是全部）實踐。讓您和您的團隊全身心地投入其中以探究它們的有效性，并且使公司里從事開發軟件的人能養成更良好的習慣。
XP實踐可以幫助人們改變思維，但是只有當他們開始使用這些實踐時才會有幫助。這需要轉變信念，或者至少需要暫緩下結論。XP并不“普通”，因此剛開始時您會覺得很難使用。也許它永遠都不會適合于您。也許它永遠都不會適合于您的公司，但是，如果不嘗試一下，您就不會確切地知道這一點。進行實驗是比較妥當的。試著花幾個星期使用 XP，在此過程中要牢記兩點：
· 不要放棄，即使您感到孤單或不友好。
· 自覺地用不同的思路看待您正在做的工作。
第一項承諾是顯而易見的。第二項承諾需要進行一些說明。針對程序員的 XP 實踐（如結對編程，pair programming）和針對業務人員的 XP 實踐（如告知詳情）需要不同的思路，以便更好地工作。不可能剛開始就會用不同的思路思考問題，但是您可以假裝這樣做。
優秀的偽裝者
當您遇到一項不熟悉的實踐時，您需要以兩種方式假裝：
· 假裝您喜歡這個任務——假裝您真的喜歡它。
· 假裝您是用該實踐希望的不同思路進行思考。
當然，如果您確實已喜歡該實踐，則您無須假裝。但是如果您不喜歡它，那么必須坐下來研究一下，就好象您確實喜歡一樣。時時刻刻都要使用該實踐。假裝沒有它您簡直不能編碼了。如果您實在憎恨這個實踐（大多數程序員不是喜愛就是憎恨“有爭議的”實踐，如結對編程），如果必需的話，發泄一下，但是要克服它。暫且不去懷疑，無論如何都要去做。這是考驗意志的行為。如果只因為您的偏見或者是您的意向或經驗就讓您生氣或采取抵制行為，那么最好不要那樣做。
那么，現在為什么要假裝用不同的思路進行思考？所言極是。Ron Jeffries 在一篇文章中講述這一問題，而他對它甚至不了解。他談論了 YAGNI（“You Aren't Gonna Need It，您不會需要它”）實踐，來提醒我們需要換一種思路進行思考：
作為技術專家，我們中的大多數人都對處理復雜性的能力洋洋自得，并且都喜愛了解最新的東西。我們需要提醒的是，我們的工作是生成簡單、可維護的程序，很快就能得到，而不是構建巨大的企業軟件以支持少數 Web 頁面。
他還說，YAGNI 提醒我們，作為程序員，在沒有搞清楚是否需要某些特性前不要向軟件添加這些特性。為什么呢？因為這一行為實際上應當是由業務推動的，并且因為我們經常會對以后我們將“需要”什么作出錯誤的判斷，如果我們正在使用其它相當好的實踐，那么當將來我們需要某些功能時，就可以對其進行添加，而不需要額外的費用。YAGNI 讓我們一直專注于簡易性。這是 XP 所需的新思路的一部分。下面是適合于程序員的一些其它示例：
結對編程需要您知道“三個臭皮匠，頂得上一個諸葛亮”。私下里認為其他人是傻瓜是不公平的。他有知識差距嗎？如果有就彌補差距，別在私下里貶低他。您永遠都不會知道“傻瓜”也可能會看到一些您未察覺的東西，甚至還會有高見。
測試優先的開發需要您有遠見。在只有一個類時，您當然可以叫嚷著不需要測試。其代碼相當簡單。但是，當您有100個類，并且突然出現一個錯誤時，會發生什么呢？進行測試可以以極快的速度將錯誤分離出來。不進行測試則會讓您經受數小時的調試煎熬。首先編寫測試還需要您接受一個令您不快的事實：您并非全才或者是無所不知的。
告知詳情實踐需要您堅信，您的顧客將驅動這個軟件，我是指真正地驅動它。您不能粉飾某些東西，無論假想的特性可能有多酷。
下面是幾個針對業務人員的示例：
告知詳情需要您堅信，您可以并且也應該驅動軟件。您必須這樣想，“這是我的軟件。我最好告訴人家它應該做什么�！�
頻繁的發行版需要您認為“只有更好沒有最好”，來自實際用戶的反饋是“駕御”項目使之朝著您最終希望的軟件方向進行開發的最佳途徑。您必須這樣想，在軟件完成前將其發布給真正需要的人是很不錯的，盡管有些部分可能看上去仍然很不完善。
用戶測試需要您堅信，讓您花費明顯是額外的工作來編寫這些測試是值得的。是的，它將花費一些時間。您希望項目成功嗎？那么，當您的開發人員“完成”某個特性時，讓他們進行測試，以證明您對此很滿意。不要似是而非地推諉不知情。
下面是一個示例，展示了所有這些假裝可能看起來象什么。如果您是程序員，讓用戶驅動，即使您對其很反感。除非有用戶對您“告知詳情”，告訴您做什么，并且有了告訴您何時完成的驗收測試，否則不要編寫一丁點的代碼。如果您不同意用戶的明智要求，只需提一個問題，讓用戶去考慮他正在做什么。不要信口開河地評論他的需求是多么的愚蠢。要求團隊中的每位開發人員都做到這一點。如果您是客戶，不要匆忙地給出模糊的定義，并且希望程序員把他們解釋清楚。盡您所能編寫最好的需求，要知道，您可以要求獲得稍后改變想法的權利。因此故意就某件事改變想法 — 這沒什么大不了。如果您是程序員，當您的客戶改變了想法時，不要討價還價，而是對其做出良好的反應 — 假裝它正是您所希望的。
這種假裝將開始培養您的習慣。這些習慣將改變您的思維。因而您會開始覺得它們很自然。
專注于價值
最后要做的事情看起來簡直瘋狂至極。您團隊的業務人員要求您盡力量化（用美元計）您要求的每個特性（或更可能是每組特性）的商業價值。這是針對軟件的商業案例，可能值得在本專欄中再寫另一篇文章來介紹（我將讓讀者來決定寫還是不寫，因此請提供您的意見）。目前，我簡要地談論我說的是什么意思。對于您的團隊正在開發的軟件的每個特性，您應當試著回答以下兩個問題：
這個特性將提供哪些需要的價值（即，用戶的哪些成本將因此而降低，或者它會提高哪些收入）？
實現該特性需要多少花費？
并不是始終都能回答這些問題，我第一個同意這種觀點。不能回答這些問題時，別緊張，但是在您嘗試之前，千萬別假想不能回答這些問題。作為一名特性的請求者，對您而言，理解為什么需要它們是很重要的。有人會購買這個軟件。他們應該知道花錢后他們會獲得什么。
腦筋轉彎
利用 XP 開發軟件通常需要您改變思路，但是有幾點新的思維方式特別怪異。請密切注意以下幾點：
· 客戶需要時時刻刻驅動軟件開發，而不只是開發人員讓他這樣做的時候才做。開發人員需要將客戶看作其團隊的一部分�？蛻粜枰獙⑺麄冏约嚎醋魇菆F隊的一部分。
· 客戶應當由業務需求來驅動，而不是來自上司的武斷壓力。
· 客戶必須將業務需求轉換成非常具體的特性需求。否則，程序員將不知道如何編碼。
· 客戶（可能在其他人的幫助下）必須指定驗收測試，這些驗收測試告知開發人員何時完成每個需求。
· 如果客戶沒有詳細地告訴開發人員要添加特性，開發人員就不能這樣做。
· 開發人員必須時時刻刻都要編寫程序員測試。
這幾點完全不同。它們都需要紀律約束。大多數情況下，紀律所產生的回報將是不斷提高項目的成功率。堅持您的立場。在我將來的文章中，我將講述有關如何改變思維模式的具體建議。
改變必須影響高層
“客戶應當由業務需求來驅動，而不是來自上司的武斷壓力�！蔽乙呀浡牭侥诎l牢騷了，“算了吧，Roy。請別那么天真了。上司始終會給您壓力的。壓力是一級加給一級的�！辈诲e，但是必須改變對此的反應。
還記得程序員實踐嗎？如果客戶要求的內容是將進行的一次迭代開發內容的兩倍，而且他是昨天提出的，那么程序員能說什么呢？說不，或者是說好，然后進行修改。他們肯定不同意一個星期工作 100 小時。業務人員也需要開始進行同樣的工作。這肯定會一路波及到組織的高層。每個人都需要這樣采取行動。其它任何事情都是不切實際的。
我很樂意說要從高層開始改變，但是通常都不是這樣。有時候改變必須自下進行。之所以出現這種方式，是因為下屬不希望再向上司說謊，以便減輕短期壓力。否則，在您無法交付產品時，您就得把怒氣藏在自己肚子里。說實話：“不，我們不能那樣做。我認為，我們可以這樣做，那才是我們將做的�！边@樣可能會讓您惹上更大麻煩。我不希望那發生。但是正如 Martin Fowler 所說的，“如果您不能改變您的組織，那么就改變它�！闭页銎渌泻蠈嶋H的方法。事物沒有發生改變的唯一原因是我們拒絕對其進行改變。
參考資料
參與有關本文的論壇。（也可以單擊文章頂部或底部的討論以訪問論壇。）
在 Demystifying Extreme Programming 系列中閱讀所有文章。
請閱讀最早的“XP distilled”（developerWorks，2001 年 3 月）。
“Extreme Programming with IBM VisualAge for Java”（developerWorks，2001 年 4 月）描述了一些利用領先的 Java IDE 使用 XP 的最佳實踐。
請參閱由 Ron Jeffries 所著的“Misconceptions about XP”以獲得他對有關 XP 思想的一些想法。
這是另一篇同樣由 Ron 所著的有關假裝益處的好文章：“Pretend You're Not Afraid�！�
在 developerWorks Java 技術專區可找到數百篇其它 Java 相關技術的參考資料。
如果您學習更多有關 XP 的知識，請務必查閱以下書籍：
Extreme Programming Explored，William Wake 著（Addison-Wesley，2001 年）
Extreme Programming Applied: Playing to Win，Ken Auer 和 Roy Miller 著（Addison-Wesley，2001 年）
Planning Extreme Programming，Kent Beck 和 Martin Fowler 著（Addison-Wesley，2000 年）
Extreme Programming Explained: Embrace Change，Kent Beck 著（Addison-Wesley，1999 年）
關于作者
Roy W. Miller 作為一名軟件開發人員和技術顧問差不多 10 年了，最初為 Andersen Consulting（現在的 Accenture）效力，現在為 RoleModel Software，Inc.（位于北卡羅萊納州）效力。他使用過重量級的方法和敏捷方法，包括 XP。他是 Addison-Wesley XP 系列（Extreme Programming Applied：Playing to Win）書籍的合著者，目前正在編寫一本有關復雜性、突發性和軟件開發的書�？梢酝ㄟ^ rmiller@rolemodelsoft.com 或 roy@roywmiller.com 與 Roy 聯系。也可以訪問他的個人網站 www.roywmiller.com。
『引自 IBM DW中國』
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/