換一種思路 極端程式設計不再神祕

在XP講師兼開發人員Roy Miller講解“熱門”的XP實踐之前，他將為您展示如何轉變您的思路，以便您可以開始使用XP。這並不是一項輕鬆的任務—XP需要一種與大多數程式設計師和業務人員完全不同的思維方式。如果您正面臨著這樣的問題，那麼 Roy 會幫助您解決這一問題。

程式設計師培訓

我沒有電腦科學學位，因此我無法從直接親身體驗的角度來討論大多數程式設計師所獲得的“傳統的”培訓。更確切地說，我曾經同許多程式設計師和業務人員在多個軟體開發專案中一起合作過。因此，我想我可以明智地說出當他們設法開發軟體時是如何想的，以及是如何做的。讓我首先談論一下程式設計師，因為我就是其中的一員。

瞭解程式設計

我的父親是位醫生。他曾多次告訴我（我都記不清次數了），“去讀醫科學校，畢業後去實習，在實習中學著做醫生。”我想，大多數電腦科學專業的畢業生也都類似。他們帶著很多理論知識（其中一些是好的且有幫助的）離開了學校，但是對於如何編寫好的程式碼卻所知不多。由於我沒有電腦科學學位，因此也就沒有大多數理論知識。有時候這會讓我很傷心，但大多數時候不會。

當我開始程式設計的時候，我22歲，剛剛走出學校。Andersen Consulting對我進行了培訓，老師們將我領進了門，而我好不容易才“矇混”過關。大多數人都經歷過這個過程：他們在工作的過程中學習程式設計，並且大多數人通常都身處於公司環境。遺憾的是，他們的師傅和老師也是這樣過來的。習慣、術語和偏好（大多數都不是很好的）就這樣代代相傳下來。最後，大多程式設計師學會了如何儘可能快的完成工作。

程式設計師中似乎存在著四種行為模式：

· 程式設計師不知道如何同業務決策者很好地交流。

· 程式設計師期望出現教科書式的問題。

· 程式設計師喜歡獨自工作。

· 程式設計師認為測試是編碼後的活動。（有關測試的內容請訪問《細說軟體測試》）

業務培訓

業務人員有自己的培訓，但是它同程式設計師接受的培訓有著巨大的差別。但結果是類似的：業務人員習慣於用危及其軟體專案的方式工作。

進行業務的費用

負責預算的業務人員整天都在計算業務費用，但他們似乎不知道如何考慮為什麼他們需要軟體。通常，他們對於特性的業務優先順序，或者那些特性對其業務的貨幣價值（直接的或間接的）並沒有實際的概念。對於較低階別的專案管理人員和公司領導而言，這是可以理解的。

在許多公司環境（尤其是大公司）中，很容易看到底層下屬如何看待高層管理人員通過規章制度進行的管理。高層傳達一些命令，只要求底層下屬執行它。負責管理專案的人只知去做，而不知為何去做。通常公司並不鼓勵他們進行思考。因此，當下達了一項命令時，他們只需服從，而為什麼他們應該或不應該做什麼的詳情只能是那些企業高層人事考慮的事情。

但是，恐怕並不是高層的英明人士做出的決策總是正確的。許多業務決策都是根據什麼“熱門”或者什麼最能引起新聞界的關注而決定的。“如果所有其它公司都在做，我們也應該做”。這稱為“隨大流效應”。問題在於企業領導對軟體的認識是錯誤的。他們認為它是費用開銷，而不是花費一些費用的資產。他們認為它是“無可避免之災禍”，或者是生產的手段，而不是策略優勢。

我不希望參與

據說業務人員有進一步“參與”軟體專案的趨勢。通常他們根本不太參與這些專案。軟體開發人員可能會偶爾詢問他們一些問題，但是該過程真的沒什麼意義。專案通常是從分析設計開始，即使在開發團隊不使用瀑布模型變體的情況下也是這樣。這是最需要業務人員參與發言的階段。但是技術團隊通常都希望業務人員能回答所有問題。“現在就告訴我，這個軟體一年以內需要做什麼。我們會告訴您，您可以在將來改變您的想法，但是這只是開玩笑。您現在做的任何決定都是一錘定音的。”

難怪業務人員會很緊張。他們不得不就他們不知道的東西進行明確的陳述。這使他們幾乎不可避免地與 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 開發軟體通常需要您改變思路，但是有幾點新的思維方式特別怪異。請密切注意以下幾點：

· 客戶需要時時刻刻驅動軟體開發，而不只是開發人員讓他這樣做的時候才做。開發人員需要將客戶看作其團隊的一部分。客戶需要將他們自己看作是團隊的一部分。

· 客戶應當由業務需求來驅動，而不是來自上司的武斷壓力。

· 客戶必須將業務需求轉換成非常具體的特性需求。否則，程式設計師將不知道如何編碼。

· 客戶（可能在其他人的幫助下）必須指定驗收測試，這些驗收測試告知開發人員何時完成每個需求。

· 如果客戶沒有詳細地告訴開發人員要新增特性，開發人員就不能這樣做。

· 開發人員必須時時刻刻都要編寫程式設計師測試。

這幾點完全不同。它們都需要紀律約束。大多數情況下，紀律所產生的回報將是不斷提高專案的成功率。堅持您的立場。在我將來的文章中，我將講述有關如何改變思維模式的具體建議。

改變必須影響高層

“客戶應當由業務需求來驅動，而不是來自上司的武斷壓力。”我已經聽到您在發牢騷了，“算了吧，Roy。請別那麼天真了。上司始終會給您壓力的。壓力是一級加給一級的。”不錯，但是必須改變對此的反應。

還記得程式設計師實踐嗎？如果客戶要求的內容是將進行的一次迭代開發內容的兩倍，而且他是昨天提出的，那麼程式設計師能說什麼呢？說不，或者是說好，然後進行修改。他們肯定不同意一個星期工作 100 小時。業務人員也需要開始進行同樣的工作。這肯定會一路波及到組織的高層。每個人都需要這樣採取行動。其它任何事情都是不切實際的。

我很樂意說要從高層開始改變，但是通常都不是這樣。有時候改變必須自下進行。之所以出現這種方式，是因為下屬不希望再向上司說謊，以便減輕短期壓力。否則，在您無法交付產品時，您就得把怒氣藏在自己肚子裡。說實話：“不，我們不能那樣做。我認為，我們可以這樣做，那才是我們將做的。”這樣可能會讓您惹上更大麻煩。我不希望那發生。但是正如 Martin Fowler 所說的，“如果您不能改變您的組織，那麼就改變它。”找出其它切合實際的方法。事物沒有發生改變的唯一原因是我們拒絕對其進行改變。

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