- 論壇徽章:
- 0
|
[這個貼子最后由cinc在 2002/10/21 05:06pm 編輯]
澄清 XP 的誤解
級別：入門
Roy W. Miller（rmiller@rolemodelsoft.com）
軟件開發(fā)人員，RoleModel Software, Inc.
2002 年 10 月
使用 Java 語言所進(jìn)行的面向?qū)ο缶幊套兊每涨捌占�。它使軟件開發(fā)發(fā)生了某種程度的變革。但最近的研究表明，有半數(shù)軟件開發(fā)項目滯后，而三分之一的項目超出了預(yù)算。問題不在于技術(shù)；而是開發(fā)軟件所使用的方法。所謂的“靈活”方法，與諸如 Java 之類的面向?qū)ο笳Z言的能力和靈活性結(jié)合在一起，或許剛好就是答案。最流行的靈活方法稱作極端編程（Extreme Programming），或簡稱 XP，但許多人并不真正了解它。對軟件開發(fā)項目使用 XP 可以大大提高成功的機(jī)會。由 Roy Miller 撰寫的這個新專欄從重訪他受歡迎的文章“XP 精華”開始，將消除謠言和誤解，幫助您理解 XP，并解釋為什么它這么重要。Roy 很快還會在相關(guān)論壇中討論 XP。
自從我和 Chris Collins 共同編寫“XP distilled”以來已有一年了，那以后發(fā)生了很大的變化。極端編程（XP）有些成熟了，而且與以前相比，更多人在他們的組織中實現(xiàn)它。盡管 XP 得到了發(fā)展并由此產(chǎn)生了各種議論，但對于 XP 是什么和不是什么還是有許多混淆和爭論。不必驚訝，甚至微軟也把其最新的操作系統(tǒng)貼上“Windows XP”的標(biāo)簽，這更增加了人們的疑惑。
在此后的幾個月中，我將在本專欄中澄清圍繞 XP 的誤解、誤傳和真正的疑惑。我希望向您提供解答有關(guān) XP 問題的實用資源以及如何在組織中實現(xiàn)它的思想。本專欄前幾篇文章將是“XP 精華”的擴(kuò)展版本，它們將涉及與 XP 相關(guān)的當(dāng)前實踐和思想。我的目標(biāo)是向您提供支持進(jìn)一步探索 XP 的扎實基礎(chǔ)以及解釋它如何給您的公司和職業(yè)生涯帶來變化。
我從事軟件行業(yè)中的某些工作已有大約十年了。在此期間，我從未看到或使用過象 XP 那樣令我興奮的軟件開發(fā)方法。我相信這是一種自然的編程方法 — 當(dāng)人們開始使用時，可能并不是每個人都能感覺到自然。但如果有機(jī)會使用它，您就會驚訝于您以前怎么會使用任何其它方法進(jìn)行工作的。
當(dāng)然，XP 并不是開發(fā)優(yōu)秀軟件的唯一方法，但我深信兩點：
XP 運用到實踐中的原則是正確的原則。
我從未使用過象 XP 那樣將軟件開發(fā)的所有部分結(jié)合起來的軟件開發(fā)方法。
所以，如果您還不了解它，那么我將懷著極大的熱情介紹 XP。最后，我希望您也會被它所吸引 — 但并不是因為高明的市場營銷。我認(rèn)為讓其他人信服 XP 的最佳方法是據(jù)實演示 XP，然后讓他們自己決定 XP 方法是否比他們正使用的方法更好。
業(yè)務(wù)問題
在發(fā)表“XP 精華”的那一年，企業(yè)管理面臨的最大問題（IT 業(yè)內(nèi)和業(yè)外）一直未改變過：企業(yè)領(lǐng)導(dǎo)人如何利用他們的 IT 資產(chǎn)和能力獲得競爭優(yōu)勢？在許多情況下，我們討論的這些“資產(chǎn)和能力”與軟件和開發(fā)軟件有關(guān)。那是問題的癥結(jié)所在。
50 多年來程序員一直在艱苦地編寫代碼。這期間，寫出的代碼“堆積如山” — 有些很好，但大多數(shù)很糟糕。平均起來很糟糕的原因很簡單：傳統(tǒng)的軟件開發(fā)方法會導(dǎo)致項目的失敗。最糟糕的是擁有滿腔熱情、努力工作的優(yōu)秀人員看到他們大量的項目都失敗了。在“XP 精華”中，我們給出了有關(guān)項目成功的一些數(shù)字。圖 1 顯示了 2000 Group CHAOS Report 中更新的一些數(shù)字。（順便提一下，我的編輯問我是否介意定義一下“CHAOS”。我回答說，我不會介意，但 Standish Group 拒絕透露縮寫詞的含義。正如我告訴編輯的那樣 — 不，我沒騙您。您可以在參考資料的 Keeping CHAOS quiet 中讀到有關(guān)的介紹。）
圖 1. 軟件項目過去和現(xiàn)在的成功和失敗
![]()
我在一本軟件雜志的文章中第一次看到與此類似的圖。作者將該圖稱作“項目顯示穩(wěn)步的提高（Projects Show Steady Improvement）”，而且他們說明，1994 年只有 16% 的項目成功了，而在 2000 年有 28% 的項目成功了。盡管 28% 當(dāng)然要比 16% 好，但是結(jié)果還是非常糟糕的。正如我以前說過的，如果您使用標(biāo)準(zhǔn)軟件開發(fā)方法，那么即使開發(fā) Java 應(yīng)用程序，也要做好失望的準(zhǔn)備。盡管自 1994 第一次發(fā)布 CHAOS Report 以來，已有了一些提高，但幾乎四分之三的項目還是失敗了。難怪公司領(lǐng)導(dǎo)人不愿在軟件項目上進(jìn)行投資。
為什么這些數(shù)字這么糟糕？有多少人問此問題，可能就有多少種觀點，但我認(rèn)為有幾個主要原因：
人們不相信他們有問題。
人們知道有問題，但是擔(dān)心采用其它方法來解決此問題可能會帶來風(fēng)險。
人們知道有問題，也愿意設(shè)法解決它，但誤解了設(shè)法解決的問題。
人們知道有問題，愿意設(shè)法解決它，也理解該問題，但受現(xiàn)狀約束。
讓我們簡要討論這三個原因。
不相信他們有問題
人們總是喜歡自欺欺人。公司和項目的領(lǐng)導(dǎo)人也不例外。軟件開發(fā)項目正逐漸消耗著企業(yè)資產(chǎn)，而每個人還確信一切進(jìn)展順利 — 或至少它們看上去如此，這是非�？赡艿�。我在前面提到的數(shù)字已很明顯地指出組織中的軟件開發(fā)不順利。當(dāng)然也有例外，但許多組織對他們自己存在的問題一片茫然。
在您的組織中，IT 團(tuán)隊和“業(yè)務(wù)人員”之間的關(guān)系是否很僵？組織中的企業(yè)領(lǐng)導(dǎo)人是否說過這樣的話：“如果技術(shù)真的是這樣好的話，為什么我從 IT 團(tuán)隊聽到的只是‘不’呢？”如果是這樣，那么您就有問題要解決了。如果您不解決，那么“慣性”或許會使您可以暫時繼續(xù)工作，但失敗已隱約可見了。
知道存在問題，但擔(dān)心解決它會帶來風(fēng)險
更為常見的是，組織中有才能和觀察敏銳的人意識到他們目前的軟件開發(fā)方法不起作用。他們只是擔(dān)心嘗試采用使情況好轉(zhuǎn)的其它方法可能會帶來風(fēng)險。這可以理解。嘗試新事物需要勇氣，而且通常要冒一些風(fēng)險。而在我們急功近利的文化中，對您的職業(yè)生涯來說，失敗會產(chǎn)生不利影響，或者甚至是致命的。
由于成功的機(jī)會渺茫，大多數(shù)人就采用阻力最小的捷徑。這種方法在短期內(nèi)可能會保護(hù)所從事的工作，但它僅僅推遲了問題的出現(xiàn)，并使之更復(fù)雜。如果等待時間太長，小的問題也會變得難以克服。最終將沒有方法激勵人們變得勇敢，去冒更多風(fēng)險，但本專欄及相關(guān)論壇中的思想可能幫助您使組織中的人（包括您自己）戰(zhàn)勝對失敗的恐懼。
知道存在問題，也愿意設(shè)法解決它，但誤解了要解決的問題
有時人們知道他們有問題，而且愿意設(shè)法解決它，即使那意味要嘗試新事物。但他們嘗試解決錯誤的問題。例如，他們設(shè)法解決生產(chǎn)問題，假設(shè)（或許是無意的）開發(fā)軟件就象在裝配線上生產(chǎn)產(chǎn)品。讓裝配線上的工人不按照裝配的有效次序和方法進(jìn)行操作，這樣做毫無意義。軟件之所以不同是因為它是新生事物。Jim Highsmith 在 XP2002 的演講 Agile Methodologies: Problems, Principles, and Practices（請參閱參考資料）中，描述了軟件中優(yōu)化和探索之間的區(qū)別。軟件中，我們通常探索新領(lǐng)域，并做一些以前未做過的事情。這使軟件開發(fā)成為需要不同解決方案的完全不同的一類問題。
如果您設(shè)法使軟件開發(fā)過程過度“機(jī)械化”或過多控制此過程，那么您將對此失去控制。我希望本專欄即將發(fā)表的文章會有助于清晰地闡明您正試圖解決的軟件開發(fā)問題。
知道存在問題，也愿意設(shè)法解決它，但受現(xiàn)狀約束
最后，人們可能知道存在問題，愿意去解決它，也理解了正設(shè)法解決的問題，但在組織中卻無法執(zhí)行。這個問題很令人沮喪，而且解決起來也很困難，但未必不可能。遺憾的是，解決它需要的勇氣卻不是大多數(shù)人所能擁有的。有時為了進(jìn)行變革，您不得不去冒犯某些人。我知道說比做容易，但如果您是一個組織中的成員，該組織的領(lǐng)導(dǎo)層拒絕解決危害組織健康發(fā)展的問題，那么您可以做如下選擇：要么全力以赴設(shè)法進(jìn)行變革，要么在該組織不堪自身重負(fù)而關(guān)門大吉之前離開。本專欄中的這篇文章及以后的文章會向您提供一些好的意見，以幫助您克服通常阻礙組織內(nèi)新事物（特別是 XP）發(fā)展的阻力。
一個解決方案：靈活方法
在某種程度上，“極端編程”這個名稱就不太適宜。大多數(shù)人聽到 XP 時，可能會想到極限運動，或 Microsoft 的操作系統(tǒng)。這個名稱背后的思想是軟件開發(fā)的最佳實踐，例如編寫單元測試和代碼復(fù)查。為什么不能一直執(zhí)行這些實踐呢？當(dāng)您這樣做時，它們就變成類似測試驅(qū)動的開發(fā)（Test-Driven Development）和結(jié)對編程（Pair Programming）之類的概念，大多數(shù)人認(rèn)為相當(dāng)極端。那就是這個名字的由來。它與蘇打、蹦極或比爾·蓋茨無關(guān)。
可能是為了防止對該名稱不合適和目光短淺的批評，那些認(rèn)為象 XP 之類的方法很好的人，已開始將這樣的方法稱作靈活（agile）方法。您會聽到將 Crystal Method、適應(yīng)性軟件開發(fā)（Adaptive Software Development）和（目前最流行的）XP 稱為靈活方法。所有這些過程都有這樣一個事實，即需要人們共同合作來開發(fā)軟件。成功的軟件過程必須充分發(fā)揮人們的長處，而盡量避免他們的缺點。依我看來，XP 做得最好的地方在于它解決了如何互補(bǔ)影響涉及到的人員的所有力量，而且當(dāng)團(tuán)隊中的程序員編寫代碼時，幫助他們完成正確的事情。它還讓他們在大部分時間內(nèi)編寫代碼，而這正是他們喜歡做的。
不管您把您的方法稱作靈活的還是其它，這都不重要 — 結(jié)果最重要。目的是均衡所有的力量以有效地開發(fā)軟件。依我看來，這個方法始終需要真誠。它要求人們遵守基本的承諾，這樣您就不會在持續(xù)的壓力下屈服、退出，去采用舊方法完成任務(wù)。這還要用到技巧。
與大多數(shù)人所說的相反，我認(rèn)為不是每個程序員都會在 XP 團(tuán)隊中受益。XP 方法需要太多始終如一的真誠和謙虛。程序員在學(xué)校中往往不可能學(xué)到這些，而且大多數(shù)的企業(yè)環(huán)境也不鼓勵這樣做。軟件是由人類開發(fā)的。我們都有弱點，并且我們都有許多相同的弱點。我們需要使人類還原本色的方法，一種使人們難以出差錯的方法。我認(rèn)為 XP 是我見到過的任何方法中這一點做得最好的方法。
XP 的價值
正如我在“XP 精華”中所說的，XP 規(guī)定了一組核心價值和實踐，可以讓軟件開發(fā)人員發(fā)揮他們的專長：編寫代碼。XP 消除了大多數(shù)重量級過程中不必要的東西，它們減慢開發(fā)速度、耗費開發(fā)人員的精力（例如甘特圖、狀態(tài)報告，以及大量的需求文檔等），從而偏離目標(biāo)。Kent Beck 在他的書 Extreme Programming Explained: Embrace Change（請參閱參考資料）中概述了 XP 的核心價值。這些價值在去年沒有發(fā)生實際的更改。我仍用這種方法概述了這些價值：
交流：項目的問題往往可以追溯到某人在某一時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流幾乎不可能。
簡單性：XP 建議：在對于過程和編寫代碼起作用的方面，總是做最簡單的事情。按照 Kent 的說法，“XP 就是打賭。它打賭今天最好做些簡單的事，而不是做些較復(fù)雜但可能永遠(yuǎn)也不會用到的事。”
反饋：及早和經(jīng)常從客戶、團(tuán)隊和實際最終用戶獲得具體反饋意見，這提供了更多為您工作方向“掌舵”的機(jī)會。反饋可以讓您把握住正確的方向，少走彎路。
勇氣：勇氣存在于其它三個價值的環(huán)境中。它們相互支持。相信開發(fā)過程中的具體反饋比預(yù)先知道每件事更有價值，需要一定的勇氣。當(dāng)需要與團(tuán)隊中的其他人交流，而此時可能會暴露您的無知時，需要有勇氣。使系統(tǒng)保持簡單，把明天的決定留到明天做，也需要勇氣。而如果沒有簡單的系統(tǒng)、沒有不斷的交流來擴(kuò)展知識以及沒有掌握方向所依賴的反饋，勇敢也就失去了依靠。
在我與其他人為在意大利撒丁島召開的 XP2001 會議而合著的論文中，我建議在上面的列表中加上“自省”。但當(dāng)在那兒演講此論文時，我意識到自省實際上不僅僅是實踐。堅持學(xué)習(xí)作為另一個價值被包含進(jìn)來，這個強(qiáng)大的候選選項是以 Joshua Kerievsky 的一篇論文（請參閱參考資料）為基礎(chǔ)的。在該論文中，他談到對于一個健康的 XP 團(tuán)隊來說，持續(xù)學(xué)習(xí)（Continuous Learning）是如何成為必要條件的。我同意。我不知道添加另一種價值需要 XP 從業(yè)者提供什么樣的支持，但我認(rèn)為它很有意義。
修訂版的需要
當(dāng)我第一次讀到 Extreme Programming Explained 時，我很興奮，幾乎愛不釋手。我所見過的大多數(shù)企業(yè)環(huán)境中的軟件開發(fā)方法和 Kent 描述的使人耳目一新的方法之間竟存在如此巨大差異，我為此震驚。但我在內(nèi)心還是有點懷疑，書中留下了對項目業(yè)務(wù)方面有些過多的想像，這在接受時會產(chǎn)生問題。我被一種無法抗拒的思想給震住了，即 XP 不僅僅是關(guān)于編程的。
幸運的是，在有關(guān) XP“12 個實踐”的 XP 社區(qū)、因特網(wǎng)新聞組以及其它論壇中都有重點討論。人們正意識到 XP 的第一個發(fā)行版似乎過分強(qiáng)調(diào)了軟件開發(fā)的編程方面，而影響了其它方面，并且業(yè)務(wù)方面不是象它應(yīng)有的那樣十分完善�；驹瓌t是好的，但是完成軟件開發(fā)還要包含一些更多的實踐。在已修改的實踐列表（包含 19 個實踐，而不是 12 個）中隱含了這樣的認(rèn)識：即 XP 實際上不僅是關(guān)于編程的。它是關(guān)于為了生產(chǎn)優(yōu)秀軟件所需創(chuàng)建的某種組織性變革。這個方法當(dāng)然需要嚴(yán)明的編碼紀(jì)律和高超的編碼技能，但它還需要團(tuán)隊中每個人在思考創(chuàng)建軟件的方法上有重大轉(zhuǎn)變。這是指團(tuán)隊中的每個人，包括用戶、業(yè)務(wù)分析員以及決策者。新的實踐在這一點上絕對清楚，并主要集中在建立可一直生產(chǎn)優(yōu)秀軟件的團(tuán)隊上。事實上，它強(qiáng)調(diào)了團(tuán)隊是 XP 世界發(fā)生變革背后的主要驅(qū)動力。Kent Beck 在以 One Team 為主題的論文草稿中說道：
Extreme Programming Explained 中最嚴(yán)重的錯誤是隱含的假設(shè)，即您的技術(shù)團(tuán)隊只為一個客戶提供服務(wù)。
在同一篇論文的后面，他說道：
就象“客戶以同一種聲音告知團(tuán)隊”中的那樣，使用“團(tuán)隊”一詞時，就會提到程序員，這使得在 XP Explained（以及隨后的論文和交談）中，這個問題變得復(fù)雜了。這個用法總是困擾我，但我不知道對此該做什么。
新的實踐和集中于一個團(tuán)隊的方針設(shè)法解決那個問題。以對軟件開發(fā)帶來組織性變革為目標(biāo)的任何方法都必須彌合 IT 團(tuán)隊和業(yè)務(wù)團(tuán)隊之間的裂縫。存在裂縫的最主要原因之一首先是因為創(chuàng)建軟件涉及的人員不屬于一個團(tuán)隊。那么這樣一個團(tuán)隊看上去會象什么呢？在同一篇論文中，Kent 使用了一個三條腿的凳子作為比喻。開發(fā)團(tuán)隊是程序員，而業(yè)務(wù)（或客戶）團(tuán)隊是分析員、用戶、測試員等等。第三條腿是管理團(tuán)隊，它由回答如下問題的人員組成：
項目如何開始？
如何增加、減少或終止投資？
如何解決業(yè)務(wù)和開發(fā)團(tuán)隊不能解決的爭論？
在這個團(tuán)隊和需要完成的所有其它項目之間如何設(shè)置相對優(yōu)先級？
所以現(xiàn)在我們將一個團(tuán)隊定義為三個子團(tuán)隊：程序員、客戶和管理。
盡管管理團(tuán)隊對某些重大業(yè)務(wù)作決策，但管理開發(fā)工作并不是由一個團(tuán)隊負(fù)責(zé)的。每個人都屬于一個團(tuán)隊，不同的人擔(dān)任不同的角色。當(dāng)然，說要比做容易。需要有許多人愿意完成不同的工作。有失�。ú⒖赡芙K止）的風(fēng)險，但回報也可能是可觀的。
非常好。我們有了一個團(tuán)隊。每個人做什么呢？就象一年前那樣，所有 XP 實踐將四個價值轉(zhuǎn)換成了作為一個軟件開發(fā)團(tuán)隊成員每天應(yīng)該做的工作，不管是不是技術(shù)方面的工作。對成員而言，不管是否從事技術(shù)工作都沒有什么十分新的東西。XP 編程實踐被業(yè)界公認(rèn)為最佳實踐已經(jīng)有好幾年了，而且更關(guān)注于業(yè)務(wù)的實踐被認(rèn)為很有效（請參閱參考資料的 Standish Group CHAOS Report 以獲取證據(jù)）。極端編程中的“極端”一詞來自兩方面，這一點仍然正確：
XP 采取經(jīng)過證明的業(yè)界最佳實踐并將其發(fā)揮到極致。
XP 將這些實踐以某種方式進(jìn)行組合，使它們產(chǎn)生的結(jié)果大于各部分的總和。
如果每個人都在同一個團(tuán)隊中，那么第二點會令人驚奇。但只要您砍掉凳子的一條腿，那就準(zhǔn)備掉在地上吧。XP 從未保證 — 以后也不會保證 — 人們始終會做得正確，但它給予他們嘗試的機(jī)會。這適用于團(tuán)隊中所有成員，不管是不是技術(shù)人員。團(tuán)隊中使用所有實踐的成員一起工作會在速度和效率上得到明顯的提高。這些實踐可以營造使組織產(chǎn)生出優(yōu)秀軟件的環(huán)境。是否還有任何其它種類的實踐呢？
修訂的實踐
XP 的 19 個實踐（請參閱表 1）定義了團(tuán)隊各種成員應(yīng)有的習(xí)慣。這個月，我們將較深入地研究聯(lián)合（joint）實踐，因為它將一個團(tuán)隊中的所有成員都聚集在一起。下個月，我們將討論開發(fā)（development）實踐，它形成了最初的 12 個 XP 實踐的主體。再下個月，我們將討論客戶（customer）和管理（management）實踐。這將使您更好地理解用 XP 開發(fā)軟件意味著什么。
表 1. XP 的 19 個實踐
聯(lián)合實踐 迭代
公共詞匯表
開放式工作區(qū)
回顧
開發(fā)實踐 測試驅(qū)動的開發(fā)
結(jié)對編程
重構(gòu)
集體所有權(quán)
持續(xù)集成
YAGNI
管理實踐 接受的職責(zé)
空中掩護(hù)
季度評審
鏡像
可持續(xù)步調(diào)
客戶實踐 告知來龍去脈
發(fā)行規(guī)劃
接受測試
頻繁的發(fā)行版
在我們討論聯(lián)合實踐之前，讓我先澄清什么是實踐，以及什么不是實踐。實踐不是 XP。XP 不只是實踐。事實上，XP 的價值也不是 XP。Ken Auer、Erik Meade 和 Gareth Reeves 共同寫了一篇稱為“The Rules of XP”的文章（請參閱參考資料），其中對此描述得非常好。他們簡明扼要地說：
XP 的價值使 XP 靈活。XP 的實踐沒有定義 XP . . . XP 是由它的規(guī)則定義的。
他們使用 Alistair Cockburn 的游戲作類比，接著描述了“交戰(zhàn)規(guī)則”，該規(guī)則說明了進(jìn)行有效的軟件開發(fā)所需的環(huán)境。然后他們討論了“游戲規(guī)則”，它定義“交戰(zhàn)規(guī)則”框架內(nèi)每一分鐘的活動和規(guī)則。他們建議：
“游戲規(guī)則”確保 XP 的唯一性。
遵守“游戲規(guī)則”就是極端編程。
遵守“游戲規(guī)則”和“交戰(zhàn)規(guī)則”就是極端軟件開發(fā)。
XP 實踐很重要，因為它們強(qiáng)制了一些行為，這些行為增加了團(tuán)隊生產(chǎn)出與團(tuán)隊成員期望值相符的優(yōu)秀軟件的可能性。但 XP 不只是如此。它不僅是編程，還擴(kuò)展至包括整個軟件開發(fā)過程。修訂的 XP 實踐考慮到了這一點，它們要求所涉及的每個人都有不同的行為。
XP 實踐的四個類別正逐漸變得清晰。一個團(tuán)隊中的每個子團(tuán)隊有一個集合，而且還有將三個子團(tuán)隊聚集起來的集合。最初 12 個實踐中的大多數(shù)都在開發(fā)團(tuán)隊集合中，但有些可能會去掉。有些名稱已改變，主要因為最初的名稱要么不太合適，要么沒有反映它們應(yīng)有的意義。有些實踐沒有列在最初 12 個實踐的列表中。在下一節(jié)（以及以后的文章）中，在每個名稱后，我將附加說明該實踐是新的、未更改的還是到最初名稱的映射。請注意這些名稱還會有更改，但原則或許不變。
在描述實踐之前，闡述我如何看待“‘部分’觀點”，這一點很重要：團(tuán)隊必須使用所有實踐，還是只需挑選它所喜歡的呢？作為規(guī)則，XP 假設(shè)團(tuán)隊一直使用所有實踐，但團(tuán)隊可以挑選幾個實踐，并成功使用它們（諸如重構(gòu)或結(jié)對編程）。您可以在您的團(tuán)隊中隨意這樣做。對于我的團(tuán)隊，我不選擇這樣做，因為我認(rèn)為實踐會相互補(bǔ)充，一起使用效果好，所以如果我不選一個或多個實踐，那么就會放棄一些令人驚奇的東西。但應(yīng)由您自己來作出決定。如果您想嘗試 XP，我建議您暫且一直使用所有實踐，來確定您要放棄哪些實踐。我敢打賭您要放棄的那些實踐所組成的列表會很小。
好了，讓我們來描述實踐吧。本月我將討論聯(lián)合實踐來為所有其它實踐打基礎(chǔ)。首先我們需要確保我們有一個使用所有實踐的團(tuán)隊。這是先決條件。
聯(lián)合實踐：建立一個團(tuán)隊
這組實踐適用于每個人。團(tuán)隊中的每個人（程序員、客戶和管理）需要一直進(jìn)行這些實踐。這些實踐使子團(tuán)隊聚集在一起以建立我們需要的一個團(tuán)隊。
公共詞匯表（映射到比喻）
最初的比喻（metaphor）實踐失敗了。但其思想并非很糟糕：這是一幅控制圖，其中的系統(tǒng)是用每個人都能理解的術(shù)語描述的，而且賦予該系統(tǒng)一個統(tǒng)一的主題，該主題使團(tuán)隊知道新事物適合哪方面。問題是，該實踐確實偏離了主要目的：對系統(tǒng)的共同理解。團(tuán)隊中的每個人都需要理解它。有時不能獲得一個非常好的比喻，或要想出這樣的比喻非常費時。請不要僅僅因為不能對您正設(shè)法構(gòu)建的系統(tǒng)找到一個恰當(dāng)?shù)谋扔髅枋龆R時間了。應(yīng)將重點集中于每個人都能使用的共享詞匯表（Ward Cunningham 稱之為“名稱系統(tǒng)”）。如果比喻有幫助的話，那么就使用一個。如果您不能找到一個很好的比喻，那就用共享詞匯表（它列出了類、方法等的名稱）吧。
在 Extreme Programming Explored（請參閱參考資料）中，Bill Wake 也談到了比喻。他說：
當(dāng)項目已經(jīng)開始并有所成果時，在研究階段確定比喻。隨著進(jìn)展來修改它。讓比喻來指導(dǎo)您的解決方案。將其名稱用于最高級的類。理解那些類是如何交互的。
他建議當(dāng)您不能想出一個更好的名稱時，就使用“自然的比喻”（即，讓對象成為其自身）。真是好建議。
開放式工作區(qū)（新）
大部分時候非正式的交流比正式交流更有效。辦公室小房間使非正式交流比較困難。最佳解決方案是采用開放式工作區(qū)，其中人們可以在旁邊聽到討論，當(dāng)交流的內(nèi)容有意義時，可以一起討論，提出自己的想法，而且還可以對任何重要的事情進(jìn)行即時討論。這種群體交互可以產(chǎn)生令人驚奇的意外結(jié)果。我已經(jīng)在工作中看到了成效�！巴频箟Ρ凇薄Ｄ膱F(tuán)隊將因此而合作得更好。如果您的組織不同意搬動家具，那么您就有更大的問題了。
對開放式工作區(qū)實踐的典型反應(yīng)是懷疑一群人在同一個區(qū)域討論會相互分散注意力。從經(jīng)驗來說，這確實會發(fā)生。當(dāng)團(tuán)隊中的成員相互足夠尊重，以致可以在開放式工作區(qū)一起工作，而不是濫竽充數(shù)時，開放式工作區(qū)就會發(fā)揮作用。如果有人想偷懶，就讓他到可以偷懶的區(qū)域，那當(dāng)然是另外一個地方。這并不意味著工作區(qū)不能有樂趣。它應(yīng)該有樂趣，但它也應(yīng)該是可以完成工作的地方。如果團(tuán)隊成員相互關(guān)心并關(guān)注他們正從事的工作，那么他們就能使開放式工作區(qū)起作用。您應(yīng)該設(shè)想它不會有問題，并且只在真有問題時才處理它。
我聽說有人提出開放式工作區(qū)實踐意味著 XP 不適用于大型的團(tuán)隊。他們認(rèn)為一大群人在一個大空間（或一些其它開放式工作區(qū)）的地方會很混亂�？赡芩麄兪菍Φ�。坦率地說，我認(rèn)為這個側(cè)重點是錯誤的。他們似乎假設(shè)了兩點：您需要大型的團(tuán)隊，以及沒有支持團(tuán)隊的協(xié)作式環(huán)境。
可能您需要大型團(tuán)隊。但是您真的這么認(rèn)為，還是剛有這個想法？可能在一個有助于順利完成工作的環(huán)境中共事的一小組優(yōu)秀的開發(fā)人員 — 擁有他們需要的支持 — 可以比一個大型團(tuán)隊做得更多、更好和更快。也可能不是這樣，但它值得考慮。
假設(shè)您真的需要一個大型團(tuán)隊。為此您如何為它建立一個合作的環(huán)境，而完全沒有產(chǎn)生混亂呢？如果您有多個相鄰的開放式工作區(qū)，彼此處于半隔離狀態(tài)（敞開的大門、半堵墻、在大空間之間有通道等），那么怎么樣呢？有些人指出不能創(chuàng)造支持大型團(tuán)隊的合作環(huán)境，我認(rèn)為他們中的大多數(shù)通常不太喜歡這個想法 — 不管是對于小型團(tuán)隊還是大型的。假設(shè)開放式工作區(qū)不適合大型團(tuán)隊是個錯誤。
迭代（新）
使用 XP 的人經(jīng)常談?wù)擁椖康摹肮?jié)奏”。這個節(jié)奏有不同的級別，但迭代的節(jié)奏級別簡直就象心臟跳動那樣快。每隔一到三個星期，團(tuán)隊就交付具有客戶要求的新功能的工作系統(tǒng)。那是基本思想。但人們不習(xí)慣以這種方式創(chuàng)建軟件。大多數(shù)方法注重在編寫代碼之前先進(jìn)行大量的工作。XP 要求您編寫代碼、讓人們使用它，并讓他們的反饋把握項目的方向（我們將在以后的文章中更詳細(xì)地討論這個概念）。
每次迭代從制定一些規(guī)劃開始。我（以及許多其他人）稱之為迭代規(guī)劃，我們在迭代規(guī)劃會議上完成它。在這個會議上制定的規(guī)劃看上去非常象發(fā)行規(guī)劃（我們也將在以后的文章中更詳細(xì)討論這個概念），只不過是更詳細(xì)的級別。我們只關(guān)心下一次迭代。我們詢問客戶，“如果項目在下一次迭代之后將結(jié)束，您想要項目具有什么功能？”然后我們估計構(gòu)建那些功能所需的工作。我們在這次迭代中加入可以加入的東西，而推遲完成其它東西�？蛻舸_定優(yōu)先級；程序員確定成本。那意味著有些事情必須推遲進(jìn)行，讓位給當(dāng)前的迭代。您不能對此采取折衷辦法。您不可能獲得更多的時間。
時間定量（timeboxing）一詞在這里非常重要。時間定量是對某些工作設(shè)置完成期限的做法，在未到期限之前，一直從事這些工作，期限到時，就停止，然后評估您完成了多少。它是一種技術(shù)，防止團(tuán)隊在某些任務(wù)上花的時間太長，而影響其它需要完成的工作。迭代實踐不僅僅是關(guān)于時間定量的。實際上迭代實踐是關(guān)于要求人們作出艱難決定的，而這些人最有資格作出相應(yīng)的決定�？蛻魶Q定下一步要構(gòu)建哪些最重要的功能。程序員對關(guān)于如何構(gòu)建功能以及需要多少工作作出技術(shù)決定。管理層就有關(guān)項目的戰(zhàn)略方向以及該項目如何才能適合于組織的其它部分而作出決定。這涉及項目團(tuán)隊中的每個人，但他們堅持遵循他們知道的。他們當(dāng)然經(jīng)過深思熟慮，但還要相信別人也同樣如此。
對于將這個實踐稱作什么有些爭論。我們應(yīng)該稱它短迭代以強(qiáng)調(diào)迭代的節(jié)奏快，還是該稱作迭代規(guī)劃以強(qiáng)調(diào)集合每個人進(jìn)行規(guī)劃的合作方面？我喜歡短迭代，因為它強(qiáng)調(diào)使用戶獲取真正的、有效的軟件以返回具體反饋的需要。
回顧（新）
這是我職業(yè)生涯中很罕見的項目，團(tuán)隊中每人都花少量時間進(jìn)行回顧，并公開指出什么地方確實沒有做好。我必須自己來完成。當(dāng)我這樣做（如果我有時間的話）時，我通常發(fā)現(xiàn)如果團(tuán)隊花一點時間來解決項目中的問題，那么通常這些問題在它們成為“問題”之前就被解決了。那就是回顧（Norm Kerth 創(chuàng)造的術(shù)語）所要做的。
不反思您正做的工作就繼續(xù)做下去會使您陷入重復(fù)失敗的境地。團(tuán)隊中每人都最好反思他自己的工作以及他吸取的經(jīng)驗和教訓(xùn)，然后與團(tuán)隊中其他成員分享反思的結(jié)果。正如我和 Chris Collins 在我們的 XP2001 論文 Adaptation: XP Style（請參閱參考資料）中所概述的那樣，我正討論的個人行為是自省。回顧時，您公開您的自省。
思考您在項目中吸取的經(jīng)驗和教訓(xùn)。思考哪些做得好，哪些搞砸了。思考團(tuán)隊是如何運行的。思考團(tuán)隊整體產(chǎn)生了什么�？煞駥⒐ぷ魍瓿傻酶�？為什么？更重要的是，怎么做？什么是您做得好的，是您確信要繼續(xù)保持的？該怎么做？這種共同評審應(yīng)該以有組織的方式至少在每次發(fā)布后進(jìn)行一次，最好在每次迭代之后進(jìn)行。不會花很長時間。在迭代規(guī)劃會議時留出頭一到兩小時用于回顧上一次迭代�？赡艿脑捔舫鲆惶欤ɑ驇滋欤┯糜诎l(fā)布后的回顧。不要有任何松懈。在這里您正設(shè)法使團(tuán)隊更優(yōu)秀，設(shè)法提高您可以對組織增加的價值，設(shè)法通過在工作中添加一點樂趣使自己的生活更美好。這是至關(guān)重要的。
我和大部分同事都覺得團(tuán)隊中的每兩個成員結(jié)成對在每天結(jié)束時進(jìn)行“迷你回顧”很有幫助。反思只需幾分鐘。如果我們學(xué)到了值得共享的東西，那么我們可以在第二天的團(tuán)隊會議中提出。通過這種方法我們學(xué)到了很多。
回顧當(dāng)然要使一些薄弱環(huán)節(jié)得到有效解決。彌補(bǔ)了團(tuán)隊的不足后，團(tuán)隊就變成了一個更完整的團(tuán)隊。每個人都要參與回顧，包括技術(shù)和非技術(shù)成員。如果這需要太多的人，以致在一個場所容納不下（而且是可能的）時，則子團(tuán)隊（例如管理）可以進(jìn)行他們自己的回顧，然后派一名代表參加一個較小型的會議。關(guān)鍵是吸取經(jīng)驗和教訓(xùn)，這樣我們就減少了重復(fù)犯相同錯誤的機(jī)會。這就需要一個團(tuán)隊和每個人都全身心地投入其中。
組織性變革
最后，XP 是關(guān)于組織性變革的 — 它只是從軟件開始。使每個人參與同一個團(tuán)隊，但分配不同的工作，這是我所能想像到的發(fā)生有效變革的最佳途徑。這個月我們討論了 XP 的聯(lián)合實踐，它有助于創(chuàng)建為產(chǎn)生那種真正的、持久的組織性變革所需的一個團(tuán)隊。
正如我在下幾個月中每次結(jié)束時都要談到的，我重申：這里描述的已修改的實踐未必就是“新”XP 將來的模樣，這一點很重要。我想我們所有人都必須等待 Kent Beck 的 Extreme Programming Explained: Embrace Change 第二版的發(fā)布以看看下一發(fā)行版是什么樣。
消除業(yè)務(wù)／IT 團(tuán)隊的隔閡
將企業(yè)需求轉(zhuǎn)變成它實際使用的軟件是 IT 世界中最難的問題之一。讓技術(shù)人員和業(yè)務(wù)人員進(jìn)行持續(xù)且坦誠的交流是一個令人畏縮的挑戰(zhàn)。盡管大多數(shù)公司在口頭上夸夸其談，但他們的行為表明他們實際不重視交流。他們到處設(shè)置障礙。信息就無法流通。拉幫結(jié)派的斗爭使他們偏離了需要完成的工作。人們對于其他組所做的工作一無所知。項目的啟動遙遙無期，而為了似乎永遠(yuǎn)也不可能達(dá)到的目標(biāo)，這些項目艱難地前進(jìn)著，而且它們會多次中途夭折。
從人們可以記起的那一刻起，情況可能就是這樣了。行為形成了習(xí)慣。業(yè)務(wù)人員已經(jīng)習(xí)慣技術(shù)人員以種種方法向他們說“不”，所以他們開始新項目時，拋出每個可能的功能要求，并要求每件事都要擁有高優(yōu)先級，甚至是不需要的時候。技術(shù)人員以前也經(jīng)歷過這樣的“游戲”。他們知道業(yè)務(wù)人員實際上并不需要所有那些功能。背地里，他們認(rèn)為大多數(shù)業(yè)務(wù)人員都很愚蠢和優(yōu)柔寡斷。他們知道業(yè)務(wù)人員會設(shè)法改變需求（可能在“游戲”的后期），而且他們知道這個“范圍蔓延”將削弱按接近于業(yè)務(wù)人員期望的準(zhǔn)時和預(yù)算內(nèi)交付任何項目的能力。所以他們開始新項目時，就試圖限制范圍，而且通過限制“范圍蔓延”來執(zhí)行項目。這種情況意味著：
業(yè)務(wù)人員認(rèn)為 IT 團(tuán)隊只知道說“不”，而且他們沒有得到他們想要的軟件。
技術(shù)人員感到受侮辱了，而且他們沒有生產(chǎn)出他們希望能夠生產(chǎn)出的軟件。
這個游戲是個問題，但它也是個病癥。根本原因是人的本性。技術(shù)人員不愿與業(yè)務(wù)人員交流的真正原因是因為他們通常不想解決業(yè)務(wù)問題。他們寧愿玩冷冰冰的玩具，而且就技術(shù)管理而言，要贏取權(quán)利很難。當(dāng)然并非到處都如此，但很普遍。
業(yè)務(wù)人員不愿交流的根本原因是因為他們不愿花額外的精力幫助技術(shù)人員把事情做好，而且他們不想對項目結(jié)果負(fù)責(zé)。如果業(yè)務(wù)人員想要技術(shù)人員理解他們真正需要什么以及為什么，那么他們首先需要自己理解它。他們通常沒有這樣做。如果業(yè)務(wù)人員想讓技術(shù)人員生產(chǎn)“正確的”軟件，那么他們需要花些時間與技術(shù)人員共同探討，以達(dá)到共同目的。通常他們不愿意（或被不允許）這樣做。大多數(shù)業(yè)務(wù)人員沒把這看作他們工作的一部分。
這種內(nèi)耗使大多數(shù)軟件項目產(chǎn)生令人不滿意的結(jié)果就不足為奇了。事實上，我很驚奇的是，在以這種方法進(jìn)行工作的環(huán)境中，有些項目實際上還是成功了。那么我們要如何修正呢？除了組織性變革以外不需要進(jìn)行任何更改。逐步變革不會起作用，雖然我愿意幫助組織設(shè)法以這種方式進(jìn)行變革。這種變革的主要催化劑是一種根本不同的軟件開發(fā)方法，它要求并使軟件開發(fā)團(tuán)隊的業(yè)務(wù)成員和技術(shù)成員合作。我想那就是 XP 的真正意義所在。
回顧我在前面討論的一個團(tuán)隊的概念。如果您是技術(shù)人員，那么您是否通常會把業(yè)務(wù)人員視為團(tuán)隊中的一員呢？如果您是業(yè)務(wù)人員，您是否把自己視為軟件開發(fā)團(tuán)隊中的一員呢？要讓生產(chǎn)軟件的方法產(chǎn)生根本變化，我們必須改變?nèi)藗冎g的關(guān)系。XP 要求這樣做，本專欄以后的一篇文章中將描述的客戶實踐會使這一點完全清晰�？蛻粢允贾两K推動過程。作為程序員，那些客戶是我團(tuán)隊中的成員。我們應(yīng)同心協(xié)力。業(yè)務(wù)人員同樣要愿意推動開發(fā)過程。他們要對有關(guān)功能的取舍做出艱難的決定。他們需要能及早并經(jīng)常進(jìn)行發(fā)布，即使當(dāng)系統(tǒng)未“完成”時，這樣團(tuán)隊才能從真正的用戶那里得到具體反饋。他們需要以客戶測試的形式，確定何時“完成”某一特定事情。那才是最根本的。
XP 不僅僅是關(guān)于編程的。它是關(guān)于根本的、改變生活的組織性變革。我相信這是治愈滋生在全體 IT 團(tuán)隊中疾病的唯一良藥。
下個月
本月的專欄文章概述了 XP 的聯(lián)合實踐，它可以幫助您建立一個團(tuán)隊，而不是一些爭論不休的小組。下個月我們將涉及程序員的實踐。那些實踐告訴程序員要創(chuàng)建一個團(tuán)隊想要的系統(tǒng)，每天要完成的工作。結(jié)對編程是不是聽起來很奇怪，或甚至很可笑？持續(xù)集成是不是聽起來不可能？下個月您會了解到它們的含義，以及了解它們并不是您想象的那樣瘋狂的想法。
參考資料
單擊本文頂部或底部的討論，參與有關(guān)本文的論壇。
請閱讀最初的“XP distilled”（developerWorks，2001 年 3 月）。
Jim Highsmith 在撒丁島的 XP2002 會議上所作的演講 Agile Methodologies: Problems, Principles, and Practices（PDF）描述了軟件中優(yōu)化和探索之間的區(qū)別。
Joshua Kerievsky 的 XP2001 論文 Continuous Learning （PDF）非常優(yōu)秀。堅持學(xué)習(xí)可以成為第五個 XP 價值。
請參閱 Ken Auer、Erik Meade 和 Gareth Reeves 合著的 The Rules of XP。它還未發(fā)表，請留意。
Chris Collins 和 Roy Miller 合著了 Adaptation: XP Style（PDF）。
Standish Group 的這篇報道詳細(xì)描述了有關(guān)軟件項目成功率的殘酷事實。（另外，請閱讀 Keeping CHAOS quiet (PDF) 中有關(guān) CHAOS 的秘密。）
JUnit.org 是由 Erich Gamma 和 Kent Beck 開發(fā)的流行測試框架的豐富資源。
請訪問 Xprogramming.com 以優(yōu)先獲取有關(guān)極端編程的信息。
如果您想要了解有關(guān) XP 的詳細(xì)信息，請務(wù)必挑選一本本文所參考的書籍：
William C. Wake 編著的 Extreme Programming Explored
Ken Auer 和 Roy Miller 編著的 Extreme Programming Applied: Playing to Win
Kent Beck 和 Martin Fowler 編著的 Planning Extreme Programming
Kent Beck 編著的 Extreme Programming Explained: Embrace Change
在 developerWorks Java 技術(shù)專區(qū)可以找到幾百篇 Java 技術(shù)的相關(guān)參考資料。
關(guān)于作者
Roy W. Miller 作為軟件開發(fā)人員和技術(shù)顧問已有差不多十年了，一開始他在 Andersen Consulting（現(xiàn)在是 Accenture）工作，目前在位于北卡羅來那州的 RoleModel Software, Inc. 工作。他曾經(jīng)使用過重量級方法和靈活方法（包括 XP）。他是 Addison-Wesley 出版的 XP 系列書籍 Extreme Programming Applied: Playing to Win 的合著者，而且目前正在編寫有關(guān)復(fù)雜性、新興技術(shù)和軟件開發(fā)的書籍。可以通過 rmiller@rolemodelsoft.com 或 roy@roywmiller.com 與 Roy 聯(lián)系。可以訪問他的個人網(wǎng)站 www.roywmiller.com。
|
|
免費注冊
發(fā)表于 2002-10-21 17:05
