|
在將什么是極限編程之前，咱們先來(lái)討論一下，當(dāng)今信息技術(shù)中最迫切的兩個(gè)問(wèn)題是: How do we deliver functionality to business clients quickly? 如何能快速地向商業(yè)用戶交付功能？ How do we keep up with near-continuous change? 如何才能跟上近乎連續(xù)的變化? 變化本身也在不斷地變化中。不僅僅是變化的速度在不斷地提高 ，已經(jīng)成為電子商務(wù)支柱的Internet, 就已使大范圍的行業(yè)產(chǎn)生劇變--更多的是打斷的平衡而不僅僅是一次劇變。當(dāng)整個(gè)商業(yè)模式正在發(fā)生變化，當(dāng)"時(shí)間意味著市場(chǎng)"正成為公司的咒語(yǔ)，當(dāng)適應(yīng)性與互連性正在成為甚至是最呆板的組織的需要的時(shí)候，我們將有必要檢查以下的每一個(gè)方面: 1.商業(yè)是如何管理的， 2.客戶為什么而感到高興， 3.以及產(chǎn)品是如何開發(fā)的。 終極編程(Extreme Programming )運(yùn)動(dòng)成為面向?qū)ο缶幊踢@個(gè)團(tuán)體的一部分已經(jīng)有數(shù)年了， 但是直到最近才引起了越來(lái)越多的注意，特別是最近Kent Beck的《終極編程 釋義:擁抱變化》(Extreme Programming Explained: Embrace Change)一書的出版。 有一種趨勢(shì)，特別在那些嚴(yán)格的方法論者中，希望剔除那些與"能力 成熟度模型"(Capability Maturity Model CMM)或者是國(guó)際標(biāo)準(zhǔn)化組織的標(biāo)準(zhǔn)相比不那么笨重的方法，比如象hacking.注釋: hacking推崇行動(dòng)而不是思考從而導(dǎo)致了較低的質(zhì)量。 剔除與某人關(guān)于這個(gè)世界的假設(shè)相沖突的實(shí)踐，這倒不失為一種簡(jiǎn)單的方法。 從另一個(gè)角度來(lái)看XP，它倒可能是一個(gè)難題的某個(gè)潛在的部分，這個(gè)一個(gè)我在過(guò)去18個(gè)月中一直都在寫的內(nèi)容。混亂 的時(shí)期產(chǎn)生新的問(wèn)題，而后者又導(dǎo)致了新的實(shí)踐--新的實(shí)踐公然違抗 傳統(tǒng)的知識(shí)，但卻得以幸存下來(lái)是因?yàn)樗鼈兡芨玫剡m應(yīng)這個(gè)新的現(xiàn)實(shí)世界。至少有四種實(shí)踐方式我覺得是屬于這個(gè)范疇的: XP 輕量級(jí)的開發(fā)(Lean development) 輕量級(jí)的Crystal方法(Crystal Light methods 自適應(yīng)軟件開發(fā)(Adaptive software development) 我必須承認(rèn)一件事情，就是我喜歡XP的原因應(yīng)該是它沒(méi)有其他的那些花哨的東西。支持XP的人們總是會(huì)向你指出XP適合的地方以及他的某些局限性。而XP的實(shí)踐者Beck以及Ron Jeffties卻相信XP會(huì)有更廣泛的應(yīng)用前景。他們通常對(duì)于自己的要求都是很謹(jǐn)慎的。例如：小的（小于10人），公司局部（他們有直接的經(jīng)驗(yàn)）兩者對(duì)于XP的適應(yīng)性都是很明顯的；他們并沒(méi)有試圖讓人們相信XP可以適用于一個(gè)200人的團(tuán)隊(duì)。 xp基礎(chǔ)---工程 最為著名的XP項(xiàng)目是克萊斯勒綜合補(bǔ)償系統(tǒng)（Chrysler Comprehensive Compensation system稱為C3工程）。 最初，C3是一個(gè)基于OO（面向?qū)ο蠹夹g(shù)）的開發(fā)項(xiàng)目，尤其是它采用Smaltalk語(yǔ)言進(jìn)行開發(fā)。作為著名的Smalltalk專家，Beck被邀請(qǐng)來(lái)討論有關(guān)SmalTalk性能優(yōu)化的問(wèn)題，并且在原項(xiàng)目被認(rèn)為不可救要的時(shí)候?qū)⑵渥優(yōu)橐粋€(gè)采用面向?qū)ο驩O（XP）方法的試驗(yàn)性項(xiàng)目。Beck并且?guī)?lái)了Jeffries用于幫助那些基本的東西，Jeffries在C3組一直干到1999年的春天。最開始的需求是要做一個(gè)對(duì)約10，000個(gè)雇員每月薪水發(fā)放進(jìn)行管理的系統(tǒng)。這個(gè)系統(tǒng)由大約2，000個(gè)類以及30，000個(gè)方法構(gòu)成，并且在計(jì)劃方面提供有合理的容忍度 。當(dāng)有人問(wèn)Jeffries他怎樣成功的將C3變?yōu)閄P并應(yīng)用到其他的克萊斯勒IT項(xiàng)目。他笑著告訴了我。多年來(lái)我為許多大型IT組織開發(fā)了不少RAD系統(tǒng)（快速原型開發(fā)），因此我知道為什么我們無(wú)法將成功的經(jīng)驗(yàn)運(yùn)用于其它項(xiàng)目中. 對(duì)于RAD, XP, 輕量級(jí)的開發(fā)以及其它一些未得到廣泛應(yīng)用的方法, 它們成功的原因至少有一百條. xp基礎(chǔ)---實(shí)踐 應(yīng)記住的一件事情就是我們應(yīng)傾向于在小型的, 局部的團(tuán)隊(duì)中運(yùn)用XP。除了代碼與測(cè)試用例外, 盡量減少有些的影響。XP的實(shí)踐既有正面的表現(xiàn),也有負(fù)面的。在某些方面看來(lái)，他們聽起來(lái)就像一堆規(guī)則，要做這個(gè)，不要做那個(gè)。對(duì)此Beck解釋道, 與規(guī)則相比, XP更像是指導(dǎo)方針，一個(gè)靈活的依賴于具體環(huán)境的開發(fā)方針。但是諸如“每周工作40小時(shí)”等看起來(lái)可能會(huì)感覺絮絮叨叨。Jeffries使得實(shí)踐也會(huì)互相作用的，平衡，互相加強(qiáng)。以至于挑選使用的同丟棄的都是棘手的事情。 計(jì)劃的制定：XP中關(guān)于制定計(jì)劃的實(shí)現(xiàn)方法中可以反映出大多數(shù)迭代式RAD項(xiàng)目的特點(diǎn)。短期的，每三周為一個(gè)循環(huán)，頻繁地更新，按優(yōu)先級(jí)劃分任務(wù)與技術(shù)， 分配stories（一個(gè)story定義了一個(gè)特殊的功能需求并以一種簡(jiǎn)單的方式記錄在卡片上），所有的這些就是構(gòu)成了XP中的計(jì)劃。 小版本：“每個(gè)版本應(yīng)該盡可能的小，而且包含最有商業(yè)價(jià)值的需求”，Beck如是說(shuō)。這也反映了Tom Gilb在他的<軟件工程管理原則>書中提到的關(guān)于漸進(jìn)式發(fā)布的兩點(diǎn)：“所有的大的項(xiàng)目都可以被分為局部的, 有用的小的步驟”以及“進(jìn)化的步驟會(huì)傳遞到下一級(jí)。”小型版本的發(fā)布意味著具有在大型項(xiàng)目中經(jīng)常缺少的頻繁的反饋的實(shí)現(xiàn).。 然而，一個(gè)開發(fā)小組當(dāng)然需要考慮到“發(fā)布”同“可發(fā)布”的不同。無(wú)論是否是最終的版本發(fā)布還是一個(gè)簡(jiǎn)單的可發(fā)行版本的發(fā)布, 都需要付出安裝，培訓(xùn)，轉(zhuǎn)化等代價(jià)。 隱喻：在XP中“隱喻”以及“story”的使用可能會(huì)讓人有一點(diǎn)不舒服。但是，這些術(shù)語(yǔ)的使用可以幫助我們以一種更人性化的方式加以理解，尤其是對(duì)客戶而言。從某種程度上來(lái)說(shuō)，隱喻同體系結(jié)構(gòu)是同意語(yǔ)――他們都著重于從全局描述一個(gè)項(xiàng)目。但是體系結(jié)構(gòu)經(jīng)常會(huì)陷于符號(hào)與連接的泥潭。而XP使用“隱喻”定義一個(gè)從開發(fā)者到商業(yè)客戶都可聯(lián)系的全面一致的主題。隱喻用于描述項(xiàng)目全面的面貌，而Story用于描述個(gè)別具體的特征。 簡(jiǎn)單的設(shè)計(jì)：簡(jiǎn)單的設(shè)計(jì)包含兩個(gè)部分。一，為已定義的功能進(jìn)行設(shè)計(jì)，而不是為潛在地未來(lái)可能的功能進(jìn)行設(shè)計(jì)。二，創(chuàng)建最佳的可以實(shí)現(xiàn)功能的設(shè)計(jì)。換句話說(shuō)，不用管未來(lái)會(huì)是怎樣，只創(chuàng)建一個(gè)目前為止可以實(shí)現(xiàn)的最好的設(shè)計(jì)。“如果你相信未來(lái)是不確定的，并且你相信你可以很方便的改變你的主意的話，那么對(duì)未來(lái)功能的考慮是危險(xiǎn)的。”Beck寫到。“只有在你真正需要的時(shí)候才去做“。 數(shù)據(jù)的質(zhì)量是使用功能，不是捕捉與存儲(chǔ)。此外，我說(shuō)數(shù)據(jù)如果不是很系統(tǒng)的使用便會(huì)變壞。數(shù)據(jù)質(zhì)量是系統(tǒng)使用的功能，不是可預(yù)料的設(shè)計(jì)。無(wú)論預(yù)期的對(duì)還是錯(cuò)，試著設(shè)計(jì)一個(gè)我們從來(lái)都不會(huì)用到的數(shù)據(jù)，最終結(jié)果很可能我們一次也不會(huì)用到它們。XP的簡(jiǎn)單設(shè)計(jì)方法反映了相同的觀點(diǎn)。如在本文后來(lái)所描述的那樣，這并不意味著不需要預(yù)測(cè)，而是說(shuō)為預(yù)測(cè)的內(nèi)容所做的設(shè)計(jì)一旦發(fā)生變化，其導(dǎo)致的代價(jià)是十分巨大的。 重構(gòu)：如果我不得不找出一個(gè)能夠?qū)P和其他方法區(qū)別開來(lái)的東西那就是重構(gòu)――不斷的軟件再設(shè)計(jì)以改進(jìn)它對(duì)于變化的反應(yīng)。RAD方法常常很少甚至根本不與設(shè)計(jì)相關(guān)；XP應(yīng)當(dāng)被看作持續(xù)設(shè)計(jì)。當(dāng)變化既快而且頻繁的時(shí)候，應(yīng)投入更多的精力于重構(gòu)之上。參見下面的“重構(gòu)”和“數(shù)據(jù)重構(gòu)”部分。 測(cè)試：XP充滿發(fā)人深思的有趣的難題。例如：什么是“先測(cè)試后編碼”？在一些軟件公司是通過(guò)代碼的行數(shù)來(lái)對(duì)程序員的績(jī)效加以考核，而測(cè)試的績(jī)效則是通過(guò)發(fā)現(xiàn)的缺陷的數(shù)量來(lái)考核的。這兩種方法都不能鼓勵(lì)減少測(cè)試前產(chǎn)生的缺陷的數(shù)量。XP使用兩種測(cè)試：?jiǎn)卧獪y(cè)試和功能測(cè)試。單元測(cè)試要求在寫代碼之前就開發(fā)出相應(yīng)功能的測(cè)試方法，并且測(cè)試應(yīng)當(dāng)是自動(dòng)化的。代碼一完成，它就被立即用有關(guān)測(cè)試集加以測(cè)試，從而能立即得到反饋。 配對(duì)編程：代碼檢查（還是直接用Inspection為好？）（也稱審查或走查）也是被廣為接受（至少在理論上）和有效度量的少數(shù)軟件工程實(shí)踐之一。在最好情況下，Inspection這種協(xié)同交互的檢查能夠加速學(xué)習(xí)，同時(shí)發(fā)現(xiàn)缺陷。一個(gè)較少被知道的關(guān)于Inspection的統(tǒng)計(jì)數(shù)據(jù)是盡管它在發(fā)現(xiàn)缺陷方面非常有效，但通過(guò)團(tuán)隊(duì)對(duì)于好的開發(fā)實(shí)踐持續(xù)的學(xué)習(xí)和協(xié)作，可以更好的在第一時(shí)間預(yù)防缺陷。 一家軟件公司客戶引用一個(gè)內(nèi)部研究結(jié)果，表明在測(cè)試階段發(fā)現(xiàn)一個(gè)缺陷需15小時(shí)，在Inspection階段發(fā)現(xiàn)一個(gè)缺陷則需2－3小時(shí)，而在Inspection之前發(fā)現(xiàn)缺陷只需15分鐘。后面的數(shù)據(jù)來(lái)自于產(chǎn)生于常規(guī)審查的持續(xù)的團(tuán)隊(duì)學(xué)習(xí)。配對(duì)編程將這個(gè)帶入下一步――與其用Inspection來(lái)遞增式學(xué)習(xí)，為什么不用配對(duì)編程來(lái)學(xué)習(xí)呢？ “配對(duì)編程是兩個(gè)人試圖同時(shí)編程和理解如何更好編程的一種對(duì)話”，Beck寫道。讓兩個(gè)人同時(shí)坐在一臺(tái)終端前面（一個(gè)人敲代碼或測(cè)試用例，一個(gè)人審查和思考）產(chǎn)生一種持續(xù)的、動(dòng)態(tài)的交流。Williams在猶他大學(xué)進(jìn)行的博士論文研究證明了配對(duì)編程不僅僅是一種美好的想法而且確有實(shí)效。 代碼共享：項(xiàng)目組中的每個(gè)人都可以在任何時(shí)候修改其他項(xiàng)目成員的代碼，這就是XP中所定義的代碼共享。。對(duì)許多程序員以及經(jīng)理而言，，共有代碼的想法會(huì)引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現(xiàn)問(wèn)題我應(yīng)該怪誰(shuí)？"等等。共享代碼從另一個(gè)層面提供了對(duì)配對(duì)編程中協(xié)作的支持。 經(jīng)常集成：每日構(gòu)造（build）在許多公司已經(jīng)成為規(guī)范，許多公司將每日編鏈作為最小要求，XP實(shí)踐者將每日集成作為最大要求，選擇每?jī)蓚€(gè)小時(shí)一次的頻繁編鏈。XP的反饋周期迅速：開發(fā)測(cè)試集、編碼、集成（編鏈）和測(cè)試。 對(duì)于集成缺陷危險(xiǎn)的認(rèn)識(shí)已有多年了，但我們并不是總能擁有相應(yīng)工具和時(shí)間將這些知識(shí)好好用起來(lái)。XP不僅提醒我們有可能有嚴(yán)重的集成錯(cuò)誤，而且從實(shí)踐與工具的角度提供了一種新的認(rèn)識(shí)。 每周只干40小時(shí)：XP有12條實(shí)踐的基本原則，但是有時(shí)候，比如象每周只干40小時(shí)的原則，聽起來(lái)更象規(guī)則。我同意XP中的觀點(diǎn)。只是不認(rèn)為有必要硬性規(guī)定工作小時(shí)數(shù)。相比起來(lái)，我更喜歡一句類似于“不要把部隊(duì)燒光”的話。在一些情況下，工作40小時(shí)太勞累，而在另外一些組里，甚至需要一周60個(gè)工作時(shí)。 Jeffries提供了關(guān)于加班的更多思索："我們說(shuō)的是加班被定義為我們不想在辦公室的時(shí)候呆在辦公室。而且你不應(yīng)當(dāng)加班超過(guò)一周。如果你超過(guò)了，就有什么東西出了問(wèn)題――你過(guò)于勞累，有可能比你按時(shí)下班干的還差。我同意你關(guān)于60工作時(shí)一周的感受。在我們年輕和滿身干勁的時(shí)候，這也許沒(méi)問(wèn)題。值得注意的是拖沓的一周又一周。" 我不認(rèn)為一周的工作時(shí)間會(huì)造成大的差別。決定區(qū)別的是自愿的貢獻(xiàn)。人們?cè)敢鈦?lái)工作嗎？他們對(duì)每一天都充滿干勁嗎？人們必須來(lái)工作，但是他們通過(guò)投入項(xiàng)目來(lái)創(chuàng)造巨大成就，而投入僅僅產(chǎn)生于目標(biāo)感。 現(xiàn)場(chǎng)客戶：這就對(duì)應(yīng)到了最初軟件開發(fā)時(shí)所提出的問(wèn)題――用戶參與。XP，同其他的快速開發(fā)一樣，要求客戶在現(xiàn)場(chǎng)持續(xù)地參與到項(xiàng)目組中。 編碼標(biāo)準(zhǔn)：XP實(shí)踐相互支持。例如，如果你進(jìn)行配對(duì)編程并讓他人修改共有代碼，那么編碼標(biāo)準(zhǔn)看起來(lái)就是必須的。 價(jià)值和規(guī)則 在2000年一月一日周六時(shí)候，華爾街日?qǐng)?bào)（周一到周五出版的）用一個(gè)58頁(yè)的版面發(fā)布了一個(gè)千僖年紀(jì)念版。在篇首的有關(guān)工業(yè)及金融的介紹里標(biāo)著Tom Petzinger.寫的：“長(zhǎng)久的需求與召喚：經(jīng)濟(jì)新的增長(zhǎng)點(diǎn)――顯得同以往不同”。底下的一行 Petzinger 寫著：“創(chuàng)造性正代替‘萬(wàn)金藥’的資本在成為首要的因素”。 Petzinger并沒(méi)有談?wù)撋贁?shù)天才的創(chuàng)造性，而是談了以下群體的創(chuàng)造性――從組到部門。一旦我們撇下天才們的個(gè)體創(chuàng)造，創(chuàng)造性就是環(huán)境的功能，而人們運(yùn)用并互相協(xié)助而達(dá)到我們的結(jié)果的能力。如果你的公司認(rèn)為軟件開發(fā)只是一個(gè)統(tǒng)計(jì)上的重復(fù)試驗(yàn)，刻板的，技術(shù)性的過(guò)程，那么XP對(duì)于您也許并不合適。雖然XP中也有技術(shù)實(shí)踐里的嚴(yán)格，但是XP本身是追求"創(chuàng)造"與"溝通"。 環(huán)境是靠?jī)r(jià)值同規(guī)則共同驅(qū)動(dòng)的系統(tǒng)。XP（或者其他類似的）可能、也可能不適合您的單位，可是，應(yīng)該澄清的是成功并不是只靠每周40小時(shí)的瘋狂工作或者配對(duì)編程，也不是依靠XP之中應(yīng)用在您單位中的價(jià)值或者是規(guī)則。 Beck指出了四個(gè)價(jià)值，五個(gè)基本規(guī)則，以及十個(gè)輔助規(guī)則--不過(guò)我要提到是這五個(gè)規(guī)則。 溝通：是的，溝通，可是，這里似乎沒(méi)有新的東西在里面？溝通主要是看人們自己的看法，XP構(gòu)建的基本是人與人，通過(guò)最簡(jiǎn)潔的文檔，最直接的面對(duì)面溝通獲得對(duì)任務(wù)環(huán)境的理解。 簡(jiǎn)潔：XP問(wèn)每個(gè)開發(fā)組成員：“可能實(shí)現(xiàn)的最簡(jiǎn)潔的方法是什么？”。今天所保持的簡(jiǎn)潔，可以降低明天由于變更所帶來(lái)的費(fèi)用 反饋：Beck說(shuō)："對(duì)于編程而言，樂(lè)觀主義是一種冒險(xiǎn)。"，"而反饋則是相應(yīng)的解決良藥。"無(wú)論是用反復(fù)的構(gòu)建或者頻繁的用戶功能測(cè)試，XP都能不斷地接收到反饋。雖然每次對(duì)軟件開發(fā)策略進(jìn)行研討時(shí)，我們都會(huì)說(shuō)及反饋--即使是非常有害的瀑布模型--不同的是XP的實(shí)踐者認(rèn)為反饋比起前饋(feedforward)來(lái)更為重要。無(wú)論是對(duì)測(cè)試失敗的代碼進(jìn)行修改或者是對(duì)用戶拒收的軟件從新返工，開發(fā)環(huán)境的快速變化要求開發(fā)人員對(duì)反饋有更好的認(rèn)識(shí)。 勇氣：無(wú)論您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇氣的。許多地方將勇氣定義為做某件事情的權(quán)利，即使被迫去做其他的事情。開發(fā)人員經(jīng)常借口壓力而發(fā)出帶有許多缺陷的產(chǎn)品，并對(duì)此加以堅(jiān)持。然而，更進(jìn)一步的應(yīng)該包括其他的正確的不同的東西進(jìn)來(lái)。通常，人們并不是缺少勇氣，而是缺少一種讓正確實(shí)踐獲得承認(rèn)的理由，而且，也不堅(jiān)信這點(diǎn)，勇氣不像看起來(lái)那么重要。而如果你對(duì)之沒(méi)有信心，那么是很難盡力工作的。 "勇氣并不只是方法"，Jeffries說(shuō)道，它是一種最終的價(jià)值。如果你在一種基于"溝通"，"簡(jiǎn)潔"，"反饋"的模式下工作，你將獲得勇氣，越往前信賴就越不重要。 優(yōu)質(zhì)的工作：好，如果你們中有贊成劣質(zhì)工作的話，那么請(qǐng)舉手離開這兒吧。不論你是一個(gè)Rational Unified Process，CMM，或是XP的贊成者，其本質(zhì)的觀點(diǎn)"你怎樣定義質(zhì)量"與"什么樣的活動(dòng)會(huì)贏得高質(zhì)量"，定義"無(wú)缺點(diǎn)"質(zhì)量是這個(gè)問(wèn)題的一個(gè)方向。Jerry Weinberg的定義是"質(zhì)量是對(duì)多數(shù)人有益" |
|
|
