聰明的讀者大概注意到了，前后兩個故事講的是同一回事，同樣的兩個項目。現在我的問題來了：請問哪個項目是更成功的項目？
這個問題并不容易回答——實際上它沒有標準答案。站在很多軟件企業的立場上，項目 A 是一個理想的成功項目：按時間、按成本完成預先約定的任務。請注意，我用了“理想的”這個詞，稍后我還會解釋這個有趣的詞，因為實際上的軟件項目往往沒有那么理想。
而如果換一個角度，站在客戶的立場上呢？也許付錢購買軟件的客戶會有一些不同的想法。項目 B 從開始之后一個月便交付了第一個可工作的版本，從那時起客戶開始使用這個軟件的部分功能，并且不斷地把自己使用的感受反饋給開發團隊。在真實的業務運營過程中，客戶甚至發現了一種新的盈利模式，并進行了一次大規模的業務調整，這次調整的結果也直觀地體現在軟件項目中。雖然項目B的整體交付速率低于項目 A，但它提供的所有功能都是客戶真正需要的，它們為客戶提供實實在在的價值——更不用說，客戶提前好幾個月開始使用這個軟件。
實際上，這是一篇關于軟件價值的文章。和“成功項目”一樣，對于“軟件的價值”，不同的人也會有不同的定義。不過作為付錢購買軟件的客戶，他對于軟件價值的定義是一目了然的：他能夠從使用軟件中創造多少價值，軟件能夠為他的業務提供多少價值，這是軟件的價值。或者說得更簡明一點：
軟件價值源自使用
這正是為什么很多客戶青睞“項目 B”的原因——我并不打算聲稱所有客戶都有同樣的觀點，稍后我也會舉出反例，但至少支持這一觀點的客戶不在少數。因為他們處在一個殘酷而快速變化的商業環境中：他們的供應商在變化，他們的客戶在變化，他們所處的經濟環境和政策環境也在變化。這一切的變化迫使他們的業務也要隨之變化。更要命的是，這個經濟全球化的時代是一個“快魚吃慢魚”的時代，客戶迫切希望新的軟件系統為他們帶來競爭優勢——哪怕這個軟件系統尚未完成，只要能夠投入使用。后，客戶對于新的軟件系統究竟應該是什么樣子并沒有百分之百的把握，他們的想法往往要在真正使用軟件之后才會浮現成型。幾方面的因素加在一起，使得這些客戶更愿意盡快開始使用軟件、提出反饋、并不斷完善軟件，而不是提出一組需求、然后坐等幾個月之后原封不動地拿到這些功能。
一個真實的案例
在 ThoughtWorks 的一個項目中，開發者們在項目開始之后一個月內發布了第一個版本——只有一些簡單的數據采集功能。在發布展示會上，發生了這樣的對話……
開發者：這是我們的第一個功能。我們從文本文件、Excel 數據表和遺留數據庫采集數據，現在我們的數據庫中有這些數據……（展示數據庫結構）
客戶：唔……有意思。要是你能做這樣一個查詢（寫出查詢要求），得到的結果可能會有用。
開發者：可是我們的界面上沒有地方做這樣的查詢操作。
客戶：啊，我不需要操作界面，只要每天深夜做一次查詢，把報表發到我的信箱可以了。
開發者：這樣嗎……另一個問題是，這需要花我們幾天時間。
客戶：不要緊，把別的任務往后放幾天好了，我很想看到這份報表。
開發者：那好吧，下周我們會開始提供這個報表。
猜猜結果怎么樣？一周之后客戶開始每天接收這份報表，并根據報表內容做一些分析和決策。僅僅幾個月之后，這份報表給客戶帶來的收益已經超過了整個項目的投資——這時項目其他部分的開發甚至還沒有完成。
想想這個客戶會怎么定義一個“成功的軟件項目”？好吧，也許這個項目超過了預期的時間，也許投入了更多的人力，但這些并不意味著“項目失敗”——只是付出更高的成本。關鍵在于，他投入的這些成本能夠帶來多大的收益，他的投資回報率是否劃算。對于這個客戶而言，如果項目能夠隨時給他提供可用的、能夠創造大價值的軟件，能夠隨時讓——像故事中提到的——這種有價值的想法得以實現，這是一個成功的項目。
所以，親愛的讀者，請你忘記本文標題上出現的“敏捷”二字，我們在這里所說的不是別的，是一種為客戶創造大化價值的軟件開發方法。這樣的方法有很多種，但它們有一個共同的特點：盡快、盡可能頻繁地交付可以工作的軟件，讓客戶盡快開始使用軟件，從使用中創造價值、厘清思路、提出反饋。仍然以 ThoughtWorks 的項目為例，這些項目通常在啟動開發階段之后一個月內會發布第一個版本，隨后每一周或每兩周發布一個新版本——每個版本都是一個可以工作的軟件，每個版本都比前一個版本具有更豐富的功能，并且每個版本都包含客戶認為迄今為止有價值的那些功能。用軟件開發的“黑話”，“開發下一個版本”的過程叫做“迭代”，這些開發方法大的共同點是“迭代式開發”——不是一股腦地交付全部功能，而是每次增加一點、漸進地交付有價值的功能。
軟件開發的夢想與真實
回到文章開始處的兩個故事。我曾經說過，對于很多軟件企業而言，項目 A 是一個“理想的”成功項目。那么，是什么讓情況變得不那么理想？
答案是一個所有軟件開發者耳熟能詳的詞：需求變更。在真實的項目中，客戶通常不會等到后再照單全收整個項目，因為他知道自己的業務正在發生變化。這時需求變更出現了，伴隨著來回的扯皮和討價還價。更糟的是，大量的需求變更發生在項目晚期——因為直到這時客戶才真正看到、使用到這個軟件，他的很多想法才真正浮現成型。隨著這種“后一分鐘的需求變更”，項目超期、超出預算也成了家常便飯。能夠像項目A這樣完工交付的，實在是鳳毛麟角的幸運兒。
為了對付需求變更這個噩夢，軟件開發者們還發明了另一個詞：變更控制。這個有趣的詞暗示著：需求變更是一種“不好”的東西，是需要“控制”的東西。然而站在客戶的角度上想想，他在親身使用了軟件之后提出的要求，難道不是有價值的東西嗎？把這種真正創造業務價值的要求“控制”起來，難道是合理的嗎？
在前面我也暗示過，并非所有的客戶都一定青睞迭代式開發。那么，哪些軟件項目不一定需要迭代式開發呢？從整篇文章的內容不難看出，如果客戶的業務不會變化，如果客戶的需求巨細靡遺非常明確，如果客戶不需要盡快開始使用軟件以便收回成本，那么迭代式開發對他的幫助會小得多。不過，如果讀者認真思考的話，這樣的例子也許并不多——也許比你初認為的要少得多。一個很好的例子是“神州六號”火箭使用的計算機控制系統。還有多少這樣的例子？讀者不妨試著自己想想。
如果我足夠幸運的話，也許一些讀者已經被這篇文章吊起了胃口：既然有這么好的軟件開發方法，既然它能夠為我們創造更大的價值，那還等什么呢，我們馬上動手吧。事情不會那么簡單。為了讓迭代式開發能夠成為現實，為了確保盡快、盡可能頻繁地交付，為了確保每次交付的都是有價值的功能，我們——包括軟件開發者、軟件企業和客戶——需要很多的改變。這里既有職責與權利的劃分，也有開發過程和團隊的重組，還有技術層面的實踐指導。這些正是敏捷方法學所涵蓋的內容。缺少了這些東西，“為客戶創造大價值”只能成為一句空話。在后續的文章里，我們將結合 ThoughtWorks 的實踐經驗，逐步介紹敏捷方法的方方面面。
