每個項目經(jīng)理都聽說過夢魘般的編程項目：項目歷時長達(dá)預(yù)期時間的兩倍、嚴(yán)重超出成本預(yù)算，又遠(yuǎn)遠(yuǎn)看不到結(jié)果。幸好，可以使用敏捷編程來解決這些問題。

    公司需要想辦法降低開發(fā)成本、提高軟件可靠性、縮短開發(fā)時間，并且確保應(yīng)用軟件真正有助于用戶，而不是有礙于用戶。這四個方面對任何人來說都是難以實現(xiàn)的，但敏捷編程技術(shù)能夠在許多應(yīng)用編程場景做到這一點。敏捷編程可通過減少開發(fā)人員在設(shè)計及開發(fā)應(yīng)用軟件中所犯的錯誤來降低開發(fā)成本。另外，它還能消除最高昂的一種開發(fā)成本：失敗的應(yīng)用軟件。

    不過，即便應(yīng)用軟件開發(fā)完成、安裝到服務(wù)器上后，提高可靠性所需的成本仍會抵消應(yīng)用軟件帶來的潛在好處。只有精心設(shè)計的應(yīng)用軟件，才有望獲得大多數(shù)公司力爭實現(xiàn)的99.999%可靠性。敏捷編程能夠完成這項任務(wù)，因為可以減少每個模塊可能出現(xiàn)的開發(fā)錯誤數(shù)量，還能通過不斷測試來迅速找出錯誤。

    許多公司期望任何開發(fā)項目都能迅速獲得投資回報。然而，如果公司等待開發(fā)人員完成整個應(yīng)用軟件，大多數(shù)項目就會被擱置多年。而敏捷編程技術(shù)不是等待整個應(yīng)用軟件完成，而是立即使用應(yīng)用軟件的至少一部分，這意味著用戶可以馬上從應(yīng)用軟件中受益。

    一、敏捷編程有何不同？

    敏捷編程把一個應(yīng)用軟件開發(fā)項目分成了諸多很小的模塊化部分。每個部分在很短時間內(nèi)逐個解決，然后添加到整個應(yīng)用軟件上，最后提供完整的功能。部署了不完全的應(yīng)用軟件后，人們可以用它來完成某種工作，即使軟件不具備從長遠(yuǎn)來看應(yīng)當(dāng)具備的各種功能。

    每個部分的迭代過程持續(xù)一到四周。因而，用戶可以立即知道應(yīng)用軟件的某個部分何時出了問題。這樣，就可以立即解決問題，而不是在一大堆錯誤百出或者“不是用戶所需”的代碼上實現(xiàn)了各種其他功能之后再解決問題。

    每個迭代過程本身就像一個小型項目。作為敏捷項目經(jīng)理，要像往常那樣監(jiān)管規(guī)劃、需求、設(shè)計、編碼、測試和文檔編制等各個階段，只不過這是針對應(yīng)用軟件的某項功能。譬如說，如果正在開發(fā)一種特殊的文字處理軟件，有個迭代過程可能是針對拼寫檢查程序的。拼寫檢查程序添加到文字處理軟件上，它影響的只是整個軟件的一個方面。開發(fā)人員開發(fā)處理拼寫的迭代過程之前，用戶就可以使用該文字處理軟件，沒有這項功能也沒關(guān)系。他們只是沒法檢查拼寫的內(nèi)容罷了。

    二、是否需要做大量額外工作？

    有些人誤認(rèn)為，敏捷編程技術(shù)需要做大量的額外工作。不過事實上，它減少了工作量，還大大加快了投資回報的實現(xiàn)，這是因為每個組件的周轉(zhuǎn)時間縮短了，可以更迅速地投入使用。

    事實上，由于開發(fā)人員能對這種軟件迅速做出反應(yīng)，項目經(jīng)理往往使用敏捷編程技術(shù)來挽救陷入困境的項目。譬如說，敏捷編程的創(chuàng)始人kent beck曾在1986年使用該技術(shù)挽救了克萊斯勒綜合薪資系統(tǒng)（3c）項目。

    三、除了迭代工作方式，敏捷編程還有何不同？

    敏捷編程方法的基礎(chǔ)是溝通。這種方法強調(diào)面對面的溝通，書面文檔作為討論要點。換句話說，不是許多人獨立負(fù)責(zé)開發(fā)項目的各個部分，而是大家聯(lián)合起來，作為一個團(tuán)隊來開發(fā)某個部分。

    不像其他編程方法，敏捷編程依靠的是大不相同的成員組成的團(tuán)隊，這些人分組工作。團(tuán)隊成員包括：項目經(jīng)理、設(shè)計人員、開發(fā)人員、測試人員、客戶、文檔編制人員以及需要使用這部分軟件的其他任何人。因為相關(guān)各方能夠協(xié)同工作，所以通常有可能在極短時間內(nèi)完成開發(fā)，幾乎不需要什么改寫。

    然而，敏捷編程方面要考慮的最重要因素就是，開發(fā)過程涉及每個人?？蛻簦ㄓ脩簦囊婚_始就參與項目，這意味著開發(fā)團(tuán)隊能比較準(zhǔn)確地了解用戶與應(yīng)用軟件之間如何互動以及執(zhí)行某項任務(wù)所需要的步驟。

    四、企業(yè)文化會不會發(fā)生變化？

    敏捷編程所需的環(huán)境確實有別于通常的那種企業(yè)環(huán)境。譬如說，團(tuán)隊的所有成員必須或多或少信任其他成員。任何人都不能拒絕向團(tuán)隊成員提供信息、資源或者數(shù)據(jù)。

    除了信任外，團(tuán)隊成員必須愿意妥協(xié)。應(yīng)用軟件的一個部分可能需要某些功能；而有些功能雖好，卻沒有必要。有時，為了在合理的時間內(nèi)開發(fā)完成某部分，團(tuán)隊必須確定棄用沒有必要的功能，留給將來的迭代過程去實現(xiàn)。

    團(tuán)隊做出的一些決策也許不受整個公司的歡迎，“你不可能討好每一個人”這句老話適用于此。因為團(tuán)隊中包括來自公司各部門的代表，公司必須信任團(tuán)隊這么做是出于好意，目的在于接受開發(fā)團(tuán)隊交付的那部分應(yīng)用軟件。不然，項目會很快陷入一片混亂。當(dāng)然，這不是說公司不得不接受錯誤百出或者無法完成任務(wù)的應(yīng)用軟件。之所以分成小部分來部署應(yīng)用軟件，就是為了更早發(fā)現(xiàn)及補救軟件錯誤及使用問題，從而減少補救成本。

    最后一點就是，提供促進(jìn)團(tuán)隊成員之間溝通的環(huán)境。實現(xiàn)這個目標(biāo)需要為團(tuán)隊成員提供特定的工作場所。成員們應(yīng)當(dāng)保持同樣長的工作時間，以便其他成員需要溝通時能找得到人。

    五、何時避免使用敏捷編程技術(shù)？

    應(yīng)用軟件開發(fā)根本就沒有什么靈丹妙藥可言。雖然敏捷編程技術(shù)可以很快開發(fā)出優(yōu)秀的應(yīng)用軟件，但不是說這項技術(shù)適合每個項目。

    譬如說，一家公司需要開發(fā)無法分成諸多小部分的大型應(yīng)用軟件，要20余名開發(fā)人員才能完成。例如，為一家大醫(yī)院開發(fā)心臟監(jiān)測應(yīng)用軟件，就不希望只開發(fā)出監(jiān)測心臟的那部分軟件，在還沒有開發(fā)出病人心臟有問題后發(fā)出警報的其他部分時就部署上去。這種情況下，必須開發(fā)出整個應(yīng)用軟件、整體測試后才可以部署，否則后果會很嚴(yán)重。這種場合下，敏捷編程技術(shù)算不上是良好的解決辦法，因為一旦涉及了許多人，系統(tǒng)馬上會崩潰。

    需要分布式開發(fā)的應(yīng)用軟件也不是非常適合使用敏捷編程技術(shù)。如果有些開發(fā)人員在英國、有些在美國，團(tuán)隊成員溝通起來不夠迅速。分布式團(tuán)隊很難得到敏捷方法帶來的所有好處。系統(tǒng)很快會陷入泥沼，你會發(fā)現(xiàn)大量時間用在了為團(tuán)隊的每個成員提供最新信息上。

    敏捷編程技術(shù)還很難應(yīng)用于每個部分一開始就要用的關(guān)鍵任務(wù)型應(yīng)用軟件。因為敏捷編程技術(shù)最適合小的迭代過程，那樣整個應(yīng)用軟件不必立即開發(fā)出來。這種方法要求公司部署不完全的應(yīng)用軟件，以便征求整個公司的意見。目的在于，迅速補救任何實際缺陷及使用問題，而不是開發(fā)出一個完整的應(yīng)用軟件，等項目結(jié)束后才能測試。

    有些公司本身也不適合使用敏捷編程技術(shù)，因為采用了集中的命令式管理方式，這遏制了敏捷編程發(fā)揮作用所需的有創(chuàng)意的方法。

    六、只有一種敏捷編程方法嗎？

    敏捷編程包括好多方法，都可以用來實現(xiàn)目標(biāo)。到底使用哪種方法，取決于想開發(fā)的應(yīng)用軟件類型、想要滿足的客戶以及公司內(nèi)部的環(huán)境。下面是幾種比較常見的敏捷編程方法：

    ◆極限編程（XP）

    這種方法強調(diào)的是適應(yīng)性，而不是可預(yù)測性。它最適合這種場合: 公司并不確切知道自己需要什么樣的最終產(chǎn)品。這種方法最先由Kent Beck采用。

    ◆Scrum

    這種方法強調(diào)的是重新開始迭代過程，而不是企圖補救問題。它最適合這種場合: 公司在使用新工具，以及應(yīng)用軟件在開發(fā)過程中幾乎肯定會變化。1993年，Jeff Sutherland在Easel Corporation最先使用了Scrum方法。

    ◆自適應(yīng)軟件開發(fā)（ASD）

    這種方法強調(diào)的是速度和靈活性。它最適合這種場合: 公司需要應(yīng)用軟件能夠迅速見效，還能隨客戶使用需求的增長而靈活變化。這種方法的發(fā)明者是Jim Highsmith。

    ◆動態(tài)系統(tǒng)開發(fā)方法（DSDM）

    這種方法最初來源于強調(diào)用戶參與的快速應(yīng)用軟件開發(fā)（RAD）技術(shù)。它最適合于在開發(fā)人員不是非常了解環(huán)境的情況。1990年，DSDM聯(lián)合會在英國發(fā)明了這種方法，旨在綜合編程最佳實踐方面的經(jīng)驗。

    ◆功能驅(qū)動開發(fā)（FDD）

    這種方法強調(diào)的是可預(yù)測性以及遵守開發(fā)最佳實踐。它最適合以下場合: 開發(fā)團(tuán)隊必須開發(fā)具有特定功能及可讀性高于正常水平的應(yīng)用軟件。1997年，Jeff De Luca最早發(fā)明了這種方法，旨在滿足當(dāng)時一家新加坡大銀行的需求。