聰明的讀者大概注意到了，前后兩個故事講的是同一回事，同樣的兩個項目�，F(xiàn)在我的問題來了：請問哪個項目是更成功的項目？

  這個問題并不容易回答——實際上它沒有標(biāo)準(zhǔn)答案。站在很多軟件企業(yè)的立場上，項目 A 是一個理想的成功項目：按時間、按成本完成預(yù)先約定的任務(wù)。請注意，我用了“理想的”這個詞，稍后我還會解釋這個有趣的詞，因為實際上的軟件項目往往沒有那么理想。

  而如果換一個角度，站在客戶的立場上呢？也許付錢購買軟件的客戶會有一些不同的想法。項目 B 從開始之后一個月便交付了第一個可工作的版本，從那時起客戶開始使用這個軟件的部分功能，并且不斷地把自己使用的感受反饋給開發(fā)團(tuán)隊。在真實的業(yè)務(wù)運(yùn)營過程中，客戶甚至發(fā)現(xiàn)了一種新的盈利模式，并進(jìn)行了一次大規(guī)模的業(yè)務(wù)調(diào)整，這次調(diào)整的結(jié)果也直觀地體現(xiàn)在軟件項目中。雖然項目B的整體交付速率低于項目 A，但它提供的所有功能都是客戶真正需要的，它們?yōu)榭蛻籼峁�實實在在的價值——更不用說，客戶提前好幾個月開始使用這個軟件。

  實際上，這是一篇關(guān)于軟件價值的文章。和“成功項目”一樣，對于“軟件的價值”，不同的人也會有不同的定義。不過作為付錢購買軟件的客戶，他對于軟件價值的定義是一目了然的：他能夠從使用軟件中創(chuàng)造多少價值，軟件能夠為他的業(yè)務(wù)提供多少價值，這是軟件的價值�；蛘哒f得更簡明一點(diǎn)：

  軟件價值源自使用
     這正是為什么很多客戶青睞“項目 B”的原因——我并不打算聲稱所有客戶都有同樣的觀點(diǎn)，稍后我也會舉出反例，但至少支持這一觀點(diǎn)的客戶不在少數(shù)。因為他們處在一個殘酷而快速變化的商業(yè)環(huán)境中：他們的供應(yīng)商在變化，他們的客戶在變化，他們所處的經(jīng)濟(jì)環(huán)境和政策環(huán)境也在變化。這一切的變化迫使他們的業(yè)務(wù)也要隨之變化。更要命的是，這個經(jīng)濟(jì)全球化的時代是一個“快魚吃慢魚”的時代，客戶迫切希望新的軟件系統(tǒng)為他們帶來競爭優(yōu)勢——哪怕這個軟件系統(tǒng)尚未完成，只要能夠投入使用。后，客戶對于新的軟件系統(tǒng)究竟應(yīng)該是什么樣子并沒有百分之百的把握，他們的想法往往要在真正使用軟件之后才會浮現(xiàn)成型。幾方面的因素加在一起，使得這些客戶更愿意盡快開始使用軟件、提出反饋、并不斷完善軟件，而不是提出一組需求、然后坐等幾個月之后原封不動地拿到這些功能。

   一個真實的案例

  在 ThoughtWorks 的一個項目中，開發(fā)者們在項目開始之后一個月內(nèi)發(fā)布了第一個版本——只有一些簡單的數(shù)據(jù)采集功能。在發(fā)布展示會上，發(fā)生了這樣的對話……

  開發(fā)者：這是我們的第一個功能。我們從文本文件、Excel 數(shù)據(jù)表和遺留數(shù)據(jù)庫采集數(shù)據(jù)，現(xiàn)在我們的數(shù)據(jù)庫中有這些數(shù)據(jù)……（展示數(shù)據(jù)庫結(jié)構(gòu)）
客戶：唔……有意思。要是你能做這樣一個查詢（寫出查詢要求），得到的結(jié)果可能會有用。
開發(fā)者：可是我們的界面上沒有地方做這樣的查詢操作。
客戶：啊，我不需要操作界面，只要每天深夜做一次查詢，把報表發(fā)到我的信箱可以了。
開發(fā)者：這樣嗎……另一個問題是，這需要花我們幾天時間。
客戶：不要緊，把別的任務(wù)往后放幾天好了，我很想看到這份報表。
開發(fā)者：那好吧，下周我們會開始提供這個報表。
猜猜結(jié)果怎么樣？一周之后客戶開始每天接收這份報表，并根據(jù)報表內(nèi)容做一些分析和決策。僅僅幾個月之后，這份報表給客戶帶來的收益已經(jīng)超過了整個項目的投資——這時項目其他部分的開發(fā)甚至還沒有完成。

  想想這個客戶會怎么定義一個“成功的軟件項目”？好吧，也許這個項目超過了預(yù)期的時間，也許投入了更多的人力，但這些并不意味著“項目失敗”——只是付出更高的成本。關(guān)鍵在于，他投入的這些成本能夠帶來多大的收益，他的投資回報率是否劃算。對于這個客戶而言，如果項目能夠隨時給他提供可用的、能夠創(chuàng)造大價值的軟件，能夠隨時讓——像故事中提到的——這種有價值的想法得以實現(xiàn)，這是一個成功的項目。

  所以，親愛的讀者，請你忘記本文標(biāo)題上出現(xiàn)的“敏捷”二字，我們在這里所說的不是別的，是一種為客戶創(chuàng)造大化價值的軟件開發(fā)方法。這樣的方法有很多種，但它們有一個共同的特點(diǎn)：盡快、盡可能頻繁地交付可以工作的軟件，讓客戶盡快開始使用軟件，從使用中創(chuàng)造價值、厘清思路、提出反饋。仍然以 ThoughtWorks 的項目為例，這些項目通常在啟動開發(fā)階段之后一個月內(nèi)會發(fā)布第一個版本，隨后每一周或每兩周發(fā)布一個新版本——每個版本都是一個可以工作的軟件，每個版本都比前一個版本具有更豐富的功能，并且每個版本都包含客戶認(rèn)為迄今為止有價值的那些功能。用軟件開發(fā)的“黑話”，“開發(fā)下一個版本”的過程叫做“迭代”，這些開發(fā)方法大的共同點(diǎn)是“迭代式開發(fā)”——不是一股腦地交付全部功能，而是每次增加一點(diǎn)、漸進(jìn)地交付有價值的功能。

  軟件開發(fā)的夢想與真實

  回到文章開始處的兩個故事。我曾經(jīng)說過，對于很多軟件企業(yè)而言，項目 A 是一個“理想的”成功項目。那么，是什么讓情況變得不那么理想？

  答案是一個所有軟件開發(fā)者耳熟能詳?shù)脑~：需求變更。在真實的項目中，客戶通常不會等到后再照單全收整個項目，因為他知道自己的業(yè)務(wù)正在發(fā)生變化。這時需求變更出現(xiàn)了，伴隨著來回的扯皮和討價還價。更糟的是，大量的需求變更發(fā)生在項目晚期——因為直到這時客戶才真正看到、使用到這個軟件，他的很多想法才真正浮現(xiàn)成型。隨著這種“后一分鐘的需求變更”，項目超期、超出預(yù)算也成了家常便飯。能夠像項目A這樣完工交付的，實在是鳳毛麟角的幸運(yùn)兒。

  為了對付需求變更這個噩夢，軟件開發(fā)者們還發(fā)明了另一個詞：變更控制。這個有趣的詞暗示著：需求變更是一種“不好”的東西，是需要“控制”的東西。然而站在客戶的角度上想想，他在親身使用了軟件之后提出的要求，難道不是有價值的東西嗎？把這種真正創(chuàng)造業(yè)務(wù)價值的要求“控制”起來，難道是合理的嗎？

  在前面我也暗示過，并非所有的客戶都一定青睞迭代式開發(fā)。那么，哪些軟件項目不一定需要迭代式開發(fā)呢？從整篇文章的內(nèi)容不難看出，如果客戶的業(yè)務(wù)不會變化，如果客戶的需求巨細(xì)靡遺非常明確，如果客戶不需要盡快開始使用軟件以便收回成本，那么迭代式開發(fā)對他的幫助會小得多。不過，如果讀者認(rèn)真思考的話，這樣的例子也許并不多——也許比你初認(rèn)為的要少得多。一個很好的例子是“神州六號”火箭使用的計算機(jī)控制系統(tǒng)。還有多少這樣的例子？讀者不妨試著自己想想。

  如果我足夠幸運(yùn)的話，也許一些讀者已經(jīng)被這篇文章吊起了胃口：既然有這么好的軟件開發(fā)方法，既然它能夠為我們創(chuàng)造更大的價值，那還等什么呢，我們馬上動手吧。事情不會那么簡單。為了讓迭代式開發(fā)能夠成為現(xiàn)實，為了確保盡快、盡可能頻繁地交付，為了確保每次交付的都是有價值的功能，我們——包括軟件開發(fā)者、軟件企業(yè)和客戶——需要很多的改變。這里既有職責(zé)與權(quán)利的劃分，也有開發(fā)過程和團(tuán)隊的重組，還有技術(shù)層面的實踐指導(dǎo)。這些正是敏捷方法學(xué)所涵蓋的內(nèi)容。缺少了這些東西，“為客戶創(chuàng)造大價值”只能成為一句空話。在后續(xù)的文章里，我們將結(jié)合 ThoughtWorks 的實踐經(jīng)驗，逐步介紹敏捷方法的方方面面。