揭開極端編程的神秘面紗：關注價值
——如何與客戶進行交流以交付他們真正想要的軟件
作者：Roy W. Miller 本文選自：IBM DW中國 2003年05月07日
如何與項目出資人（投資軟件開發的人）以他們的語言進行交流，但又不違背 XP 告訴我們的原則，對于你們的 XP 團隊而言，需要明白這個問題的重要性。這個月，Roy Miller 從他即將出版的書籍 Growing Software: Exploding the Myth of Prediction and Control（定于 2003 年由 Addison-Wesley 出版社出版）中摘錄了部分材料，并對其進行了改編，從而向您講述了如何以上述方式與客戶交流。請在相應的論壇中同作者及其他讀者一起分享您對本文的看法。
項目資金必須得到落實，而掌管預算的人極有可能對 XP 或靈活（agile）方法知之甚少。如果他熟悉這些編程概念，我懷疑他會認為這些想法十分愚蠢或者過于冒險。向持懷疑態度的資金來源尋求資金可能是件有風險的事情。管理人員要想十拿九穩，最好的方法之一就是要確保在與出資人交談時運用對方的語言。
關注價值
上次我略微談到過把注意力放在商業價值上來驅動項目的軟件開發項目�；ㄙM時間和金錢來開發軟件的原因僅僅是因為有人要您這么做，這種解釋并不是一個好的商業理由（雖然這可能是保住飯碗的好辦法）。最終，如果團隊所開發的軟件并不能為企業提供價值，那么其項目出資人就得不償失 — 這一點他最終是會發現的。
“價值”可以有兩種不同含義。要么是指節省開支 — 省錢，要么是改進運營，從而賺錢。如同我們前面討論過的那樣，計劃一個項目時，您應該鼓勵團隊成員盡其所能為所創建的每個功能部件（更可能的情況是每個功能部件集）增加含金量。這就是軟件的商業案例。對于每個功能部件，您都應該嘗試回答兩個問題：
·該功能部件解決何種價值需求（即，它能降低客戶的哪些成本，或者它能增加哪些收益）？
·達到這些目的又要付出多大代價？
當然，不見得總是能夠回答出這兩個問題來，但是也不要沒試過就認為這兩個問題沒法回答。有人為該軟件投入了資金，因而他應該知道他會從投入的資金中得到什么。事先知道這些信息將更容易獲取啟動 XP 項目所需的資金。
要錢
為軟件開發項目出資的人在掏錢之前會詢問三個問題：
·我將從該項目中得到哪些更新、更好的業務能力呢？
·什么時候？
·要花多少錢呢？
管理人員并不總是都能夠詳細回答這些問題的，但我相信，項目出資人也并不見得就一定想問個水落石出。而且，管理人員在回答這些問題時也必須綜合考慮兩種因素，即他們無法預測未來，而又需要對此進行充分的預測以獲取預算。對于出資人而言，雖然他們可能將大筆資金花在具有風險的項目上，但他們不可能一時頭腦發熱把錢花到自己不熟悉的方面。
更為重要的可能是，機構內的成員，包括軟件開發團隊的管理人員和程序員都需要有目標。必須在地上打上樁，告訴所有人：“這就是我們的目的地。一路上我們可能會改變方向，但就我們現在所知，它就是我們的最終目標�！�
大錯特錯
當提著錢袋子的人（出資人）要求尋求資金的人十分詳細地回答上面三個問題時，他們幾乎是在詢問一些無用的信息。每當管理人員試圖做一個“自底向上”估算時，這一點就變得尤為突出。他們試圖識別出所有的任務并估算對每個任務所做的努力。您可以想象他們這么做實際上是在構建一幅越來越詳細的甘特圖（Gantt chart）。這樣，全部項目時間就變成了所有任務時間的總和了。結果往往會違背我們的初衷，這就是為什么大量的軟件項目不能按時交付的原因。
問題出在詳細程度上。如果必須提前數月告訴某人某個軟件項目要花費多長時間，而且必須精確到天，那么我幾乎不可能做到這一點。這是因為我所做的自底向上的詳細估算可能會出錯。一個小小的早期估算錯誤可能會嚴重地影響我們后面的計劃。您知道哪些計劃不會造成小的估算錯誤 — 或者大的估算錯誤呢？估算只是預測，而不是承諾。設想一下對構建在線商店這一項目進行估算。（簡化了的）功能需求可能是：
·允許用戶瀏覽并購買書籍
·允許用戶瀏覽并購買音樂
·允許用戶瀏覽并購買電子制品
和大多數試圖對事物進行估算的人一樣，您可能先從一些核心需求開始，然后從內向外推進。您可能會假定編寫用于瀏覽并購買書籍的代碼將需要 5 個單位（小時、天、星期、人和任何其它單位）的努力，而滿足另兩項需求則只需要三個單位，因為它們都通過已經為支持售書部分編寫了代碼而得到了簡化。因此，您最終得到了一份看起來類似下面這樣的簡化計劃：
任務 單位
瀏覽／購買書籍 5
瀏覽／購買音樂 3
瀏覽／購買電子制品 3
典型的管理人員可能會說：“好了，11 個單位，完事了�！钡�，如果“瀏覽／購買書籍”這個環節花了六個而不是五個單位，那會怎樣呢？如果我對該環節（所花費的努力）低估了 20％，那么對其它環節，也可能會低估同樣的百分比。該誤差擴散開來，整個估算會因此瓦解。
計劃越詳細，也就越脆弱。任何人都可以就任何事做出預測。而所做預測的誤差容限是否足夠小，從而使得這個預測還算有用，這完全是另外一碼事。詳細的長期預測通常不能（做到這點）。當上級管理部門詢問項目需要多長時間時，簡單的回答就是：您無法給出準確的天數或周數。如果您試圖（給出確切的時間），那么極有可能出錯，因此（提供）這些信息可能不會有任何幫助。
但是，僅僅因為您無法進行精確、詳細和長期的預測，并不能作為逃避回答這三個問題的擋箭牌。您還是必須回答這些問題，但卻必須以另一種方式來回答。您需要向項目出資人提供的信息只要足以讓他做出十分明智的決定就夠了。
很好的答案
據說，J. P. Morgan 在被要求就股市進行預測時說：“股市將上下波動�！彪m然這可能并不完全是提問者想要的回答，但卻也是大實話。這同樣也是對于軟件開發我們所能做的。當我們開始一個項目時，只有兩個細節可以進行可靠地預測：
·我們最終所得的系統必須滿足這樣的商業需求，即某個擁有資金的人愿意為此出資。
·時間、金錢和耐心將用盡。
時間、金錢和耐心都會悄悄溜走。問題是，您的團隊如何在這些東西用完之前開發出能夠增值的優秀軟件呢？最好在那些東西用完的時候開發出一些能夠助我們前進的工作軟件，而不是一無所有，并對這樣的經歷感到后悔。堅持 XP 實踐能夠幫助您的團隊做到這一點。但是作為管理人員，您無法進行很好的預測或太多的控制，這使您受到一定的約束。對可能的項目出資人所提的問題最直接的回答類似于：
我們將開發某個軟件。我不知道這要花掉多少錢、花費多長時間以及這個軟件最終會是個什么樣子。但當我們成功時，就會發行它。我們知道我們應當試著盡早到達這一步，而這正是我們要做的。
這是實話，但實際卻行不通。擁有資金的人需要的信息不止于此（尤其是在后 .com（post-dot-com）時代）。所幸的是，潛在的出資人只需要有足夠的信息讓其在不能完全了解未來的基礎上做出明智的抉擇。因而，不必做出太多的預測就能回答這些問題。技巧在于要把精力放在目標而不是如何實現這一目標的詳細計劃上。要頂住這樣一種壓力，即要求您近乎愚蠢地窮究細節，從而拿出對項目所花時間和所耗資金的估算。這類估算很少是正確的，以致于得不償失。
相反，更明智的做法是將要參與（或可能參與）所提議項目的人員召集起來。對第一個發行版的功能需求進行討論。軟件第一次交付時，最少且絕對需要哪些功能？將這些信息記在某處�；趫F隊中已經有一部分人員，現在讓團隊中的技術人員就以下問題做出估算：每項功能的開發要進行多少重復工作。此時，進行高級別的估算是很好的。僅讓有經驗的人員就（實現）每項功能所要付出的努力相互交流看法，并記下這些看法。
在此，經驗十分重要，因為它將團隊所必須做出的猜測減到最小。每項估算至少部分屬于猜測，而經驗或高智商并不能消除全部猜測。經驗能夠有助于將猜測降低到某種程度，但是必須明白的是我們無法精確預測將來。
以下是來自我目前正在從事的項目的一個示例（略有修改）：
環節 估算的重復數 指派的發行版
先期準備工作 2 1
物理管理 2 1
邏輯管理 2 1
用戶管理 1 1
狀態維護 2 1
部署 3 1
外部工具集成 1 1
審計 1 1
監控 1 2
總的重復數 15
上面的估算假定團隊有四名開發人員。這種細節級別足以讓我們估算出實現上面所列的全部高級功能部件所需的工作。在那里，我們為每個重復工作標上價格，并用總的重復數（15）與它相乘。這項實踐花了不到兩周的時間來思考和研究各種技術問題。最終的結果就是潛在的客戶需要我們回答的所有三個問題的可接受答案：
1、項目將會提供哪些新的或改進的商業能力呢？您在這里看到的主要功能部件將隨著團隊在開發過程中所了解的情況的不同而略有不同。
2、項目要花多長時間？大約 15 個單周重復，即四個月不到一點。
3、項目要花多少錢？用單個重復的成本乘以 15。
我們還可以更進一步。我們的客戶聘請我們公司開發一個軟件產品。通過與營銷主管進行一個簡單的討論，團隊了解到營銷主管希望在頭四年里售出多少許可證，售價又是多少。這讓我們大致計算出了客戶什么時候會使其對我們所提供的服務的投資達到收支平衡。
全部三個問題我們都回答得簡潔明了，避免了可能的錯誤。我們沒有繪制甘特圖，因為我們并不需要它。僅僅一個多星期，我們就得到了所有所需的信息。
計劃
我認為前一節中的計劃就是管理人員（和團隊）開發軟件所需的全部，但對某些項目出資人而言可能太過基本。管理人員可能能夠回答出資人所提的三個問題，并且有可能因此而獲得某個項目，但有時卻不見得能夠談成這筆交易。管理人員可能至少需要一份看起來更加面熟的初始計劃。圖 1 只顯示了內容較清楚的甘特圖。
圖 1. 甘特圖
圖 2 中顯示的概括表示更加簡單。
圖 2. 甘特圖概括表示
我們的計劃需要進行匯總。一根粗線條，兩個日期。
大多數管理人員并不繪制這樣的甘特圖。有些管理人員認為甘特圖的變化越詳細就越好或者越精確，有些管理人員則有其它一些正面的看法。然而，我非常信任管理人員。我想大多數管理人員會繪制詳細程度令人難以置信的甘特圖，他們這樣做是被迫的，而不是因為他們笨或存心這么做（盡管有些管理人員確實是這樣）。他們的有些上司期望得到這些詳細的圖，沒有這些圖項目就無法繼續得到資金。這是因為有人認為這樣的詳細計劃是物有所值的。
然而，事實是所有計劃都只是虛構的。計劃只要一落筆就是錯的。我們需要開始那么做。我認為大多數管理人員都會對他們過于詳細的計劃產生一絲疑慮。下面這段話是我的一個朋友給我的電子郵件的開頭：
由于我剛剛為我的項目完成了電子表格，該表格根據對下一個發行版所提議的范圍的 A&D 估計（按照 6 個月的實現和 60 多個全職雇員（FTE），精確到 30 秒以內）對構建進行了估計，因此我想我會再給您一封電子郵件。
管理人員不會用一個月的薪水為賭注來賭特別詳細的計劃的正確度。計劃不必這么精確 — 多談些目標，少談些期望。在 The Innovator's Dilemma（參閱參考資料）中，Clayton Christensen 說，當我們在研究不太明確的技術和市場時，計劃應該用于學習而不是實現。這是在未知環境下進行有目的的活動的唯一方法。研究不確定的軟件需求以滿足不確定的業務需求也是如此：業務需求會隨著我們接近它們以及對它們的理解加深而變化。要想制定尊重這些事實的計劃，各級管理部門就必須在對失敗的看法上有一個大的改變。
Jim Highsmith 是 Adaptive Software Development: A Collaborative Approach to Managing Complex Systems（參閱參考資料）的作者，他說我們對質量的思考是不完整的。我們完全沒有考慮出錯、失敗和試驗：
當前的軟件質量管理實踐狀態通常由“一次成功（Do it right the first time）”這句話來指導。但在復雜的環境里，一次成功卻是一種會導致失敗的指導思想。它實質上是說，
·我們不能不確定
·我們不會從錯誤中吸取教訓（因為我們不會犯任何錯誤）
·我們不能偏離計劃
·我們所需的是，樂意剛開始就犯錯，以便最后不出錯。
我們需要徹底失敗，并從中吸取教訓。計劃應該支持這一點。記住，我們并不完全知道我們要前往何方。采取小的步驟，保持簡潔，然后出錯，再從中吸取教訓，這是探索未知事物的最好辦法。要經常地、徹底地并且以較小的代價制造失敗。Gary Hamel 在他的 Leading the Revolution（參閱參考資料）一書中寫道，要求每個人始終都不會出錯只是空想。除非制定計劃比計劃本身更重要，否則這就是我們的計劃要做的。
堅持到底
XP 要求管理人員以不同的方式開展項目，因為對軟件項目的傳統看法及規劃軟件項目的傳統方法往往不能產生大多數管理人員所希望的結果。一旦您有了資金，項目就啟動了，事情需要有些不同。這就是 XP 實踐的含義 — 一種不同的項目運作方法，使您的團隊在項目結束時更有可能交付出人們真正想要的軟件。
下個月
和上個月一樣，我將讓本專欄的讀者來決定下個月的主題。您希望我寫些什么呢？您對 XP 最大的疑問是什么呢？您認為什么是十分愚蠢、不明智、不專業或者不可能的呢？最令人混淆的實踐是什么呢？請參與本專欄的論壇。告訴我您希望我寫些什么。我將調查我收到的請求。如果有一定數量的讀者期待我論述某個特定主題，我就將討論這個問題。如果沒有，我將選擇寫一些我認為值得寫的東西。
參考資料
閱讀 Clayton M. Christensen 的 The Innovator's Dilemma （Harvard Business School Press，1997 年）以理解傳統的業務規劃為什么對于未開拓市場內的創新產品不適用。
對于 Jim Highsmith 對靈活方法的見解，尤其是他自己的自適應軟件開發（Adaptive Software Development），要獲取與之相關的更多信息，請查看他所著的 Adaptive Software Development: A Collaborative Approach to Managing Complex Systems （Dorset House，2000 年），該書曾榮獲 Jolt 獎（Jolt Award）。
要明白為什么大多數企業都需要一些這樣的另類人才：即在通往成功的路上愿意而且會犯錯的人，請閱讀 Gary Hamel 所著的 Leading the Revolution: How to Thrive in Turbulent Times by Making Innovation a Way of Life （Harvard Business School Press，2000 年）。
看完本文之后您會加入本專欄嗎？閱讀第一篇 XP 文章，由 Roy Miller 和 Chris Collins 合作撰寫的 “XP distilled”（developerWorks，2001 年 3 月），從而搞清楚本專欄的出發點，然后一定要查看本專欄的檔案文章 。
閱讀An excerpt from "Java Tools for Extreme Programming" （developerWorks，2002 年 7 月）中有關使用 Ant 構建和部署 Java 應用程序的內容。
在用 IBM VisualAge for Java 進行極端編程 中了解為何 VisualAge for Java 是 XP 團隊的優秀工具。
在 developerWorks Java 技術專區中可找到關于 Java 編程各方面內容的大量文章。
關于作者
Roy W. Miller 從事軟件開發和技術咨詢工作將近十年了，最初在 Andersen Consulting（現在的 Accenture）工作，目前則在位于北卡羅萊納州的 RoleModel Software, Inc. 工作。他使用過重量級方法和靈活方法，包括 XP。他與人合著了 Addison-Wesley XP 系列叢書中的一本（Extreme Programming Applied: Playing to Win），目前他正在撰寫一本關于復雜性、緊急情況和軟件開發的書（暫定標題為 Growing Software: Exploding the Myth of Prediction and Control）。請通過 rmiller@rolemodelsoft.com. 或 roy@roywmiller.com. 與 Roy 聯系。您也可以通過 www.roywmiller.com. 訪問他的個人網站。
文章來源于領測軟件測試網 http://www.kjueaiud.com/