--摘抄自敏捷軟件開發。
--來自：http://blog.csdn.net/kook_tian/archive/2009/12/27/5087100.aspx
看了以後覺得很有感觸，寫出來希望更多沒有注意過這篇文章的管理者或是想成爲管理者的人看到。
（匆匆抄寫沒有校對，湊合看吧。）
Rufus公司：“日落”項目
你叫Bob。日期是2001年1月3日。剛剛度過了新千年的狂歡，你的頭還疼着。你和幾個管理人員以及一些同事坐在會議室中。你是一個項目團隊的領導。你的上司也在其中，他叫來了歸他管理的所有團隊領導。他的老闆召集了這次會議。
“我們有一個新項目要開發”你上司的老闆（我們叫他BB）說。他的發尖是那麼的高，都擦到天花板了。你的上司的發尖纔剛開始長出，他急切地等着有一天他也可以把Brylcream護髮香波的痕跡沾染在吸音瓦上。BB描述了他們調查過的新市場的基本情況，以及他們想開發的用來開拓市場的產品。
“到第四季度，10月1日時，我們必須完成這個新產品，並使之可用”，BB要求到，“任何事情都沒有它的優先級別高；因此我們要取消你們當前的項目”。
大家的反應出奇地安靜。數月的工作就這樣將被完全丟棄了。慢慢地，低沉的反對聲開始在會議室中傳播。
當BB和房間中每個人的目光相遇時，他的發尖發出邪惡的綠光。和每個人相視時的陰險目光使每個在場者不寒而慄。顯然，他不容許在這個事情上進行討論。
大家一恢復安靜，BB就說：“我們要馬上開始。你們需要多長時間來進行分析？”
你舉起了手。你的上司視圖阻止你，但是他投擲的小東西沒能擊中你，你沒有察覺到他的舉動。
“先生，在得到一些需求前，我們無法告訴你分析會花費多長時間。”
“需求文檔要在3周或者4周後才能準備好，”BB說，他的發尖由於沮喪而震動着。“那麼，假如現在需求文檔就在你面前。你需要多長時間進行分析？”
大家都屏住呼吸。每一個人都環顧着其他的每個人，看看他們是否有一些主意。
“如果分析需要的時間超過4月1日，那麼就會出現問題。到那時，你們能夠完成分析嗎？”
你的上司明顯地鼓足勇氣，突然說到，“先生，我們會找到辦法的！”他的發尖增長了3mm，而你的頭痛也增加了，需要服兩片去痛片才行。
“好！”BB露出微笑，“現在，設計要花費多長時間？”
“先生，”你說。你的上司明顯臉色蒼白。顯然，他也在擔心他那3mm會有危險。“沒有分析，是不可能告訴你設計會花費多長時間的。”
BB的表情難以置信的嚴厲。“假如你已經做過了分析！”他說，同時還用他那透露着無知的小圓眼注視着你。“那麼，設計會花費你多長時間？”
兩片去痛片都不能減少疼痛。你的上司，不顧一切地想保住他新增長的發尖，插嘴說道，“嗯，先生，只剩下6個月的時間來完成項目了，設計最好不能超過3個月。”
“你能同意，我很高興，Smithers！”BB面帶喜色地說。你的上司放鬆了一些。他知道他的發尖保住了。過了一會兒，他開始輕輕地哼起Brylcream的廣告語。
BB繼續說道，“好，4月1日完成分析，7月1日完成設計，那麼你們有3個月的時間實現項目。這次會議是一個榜樣，他表明了我們新的協商和授權程序工作得有多麼好。現在大家可以離開，開始工作了。我期望在下週前，可以在我的辦公桌上看到TQM（全面質量管理）設計以及QIT（質量改進團隊）任命情況。哦，別忘了在下個月質量審計中，你們交叉功能團隊要召開會議進行報告。”
“忘掉去痛片，”當你返回小臥室時，心裏想道，“我需要波旁（Bourbon）威士忌酒。”
你的上司過來找你，明顯帶着興奮，說道：“天哪，多麼美妙的一個會議呀！我認爲關於這個項目，我們真的會做出一些震驚世界的事情。”你憤怒得只能點頭同意。
“哦，”你的上司繼續說道，“我幾乎忘了。”他交給你一份30頁的文檔。“記住，SEI下週要過來做一次評估。這是評估指南。你要把它讀一遍，記住它，然後把它撕碎。他告訴你如何回答SEI審計師問你的任何問題。它還告訴你在構建過程中可以使用那些部分內容以及避免使用那些部分內容。到6月份時，我們會被確定爲CMM3級機構。”
***
你和你的同事開始對新項目進行分析。這很困難，因爲你們沒有需求。但是，從BB在那個決定命運的早上所得到的10分鐘介紹中，你們對於產品應該做什麼有了一些認識。
公司的過程要求，開始時要編寫一份用例文檔。你和你的團隊開始列舉用例繪製橢圓圖以及參與者標識圖。
團隊中爆發了爭論。對於某些用例之間是用《entends》還是《includes》關係鏈接起來，大家有不同的意見。雖然不同的模型都被創建出來，但是沒有人知道如何去評論它們。爭論在繼續着，明顯拖延了進度。
一週後，有人找到了一個網站：iceberg.com，上週推薦完全不要使用《extends》和《includes》，應該使用《precedes》和《uses》來代替它們。改網站上由Don Sengroiux所寫的文檔描述了一個叫做Stalwart分析的方法，該方法聲明可以逐步地把用例轉換成設計圖。
使用這個新方案，更多不同的用例模型被創建出來；但是，同樣，大家對如何評價它們仍無法達成一致。爭論仍在繼續。
用例會議越來越多的是被情緒而不是理性所驅動。要不是因爲沒有需求，你早就會因爲沒有任何進展而心煩意亂了。
在2月15日拿到了需求文檔。接着，在20日，25日以及以後的每週都有需求文檔到來，每次新版本的需求都和前面的有衝突。雖然編寫需求文檔的市場人員負責此事，但是顯然他們沒有一致的意見。
同時，許多團隊成員又提出了一些新的不同的用例版本。每個人都以自己特有的方式來延續進度。爭論愈發激烈了。
3月1日，過程監控人員Prudence Putrigence成功地把所有不同的用例形式和模板和爲一個單一的包含一切的形式。僅僅空白表格就有15頁之多。她把在所有不同模板中出現的每一個不同的地方都包含進去。同時，她還提供了一份159頁的文檔，描述如何填寫用例表格。所有當前的用例都要按照新的標準改寫。
令你大爲驚奇的是，現在要回答“當用戶敲擊回車鍵時，系統應該做什麼？”這個問題，需要填寫15頁的表格和問答題。
公司的過程（由L.E.Ott制定，他是“全盤分析：軟件工程師進步辯證法”的知名作者）堅決要求你們必須找出所有的首要用例，87%的次要用例以及36.274%的第三級用例之後，纔可以算是完成分析並進入設計階段。你們根本就不知道什麼是第三級用例。所以，爲了滿足這個需求，你們就讓市場部檢查你們的用例文檔。也許，你們知道什麼是第三級用例。
糟糕的是，市場人員正忙於銷售支持而無法和你討論。事實上，自從項目開始，你們就沒能召開過任何有關市場的會議。他們所能做到的最好的就是提供一份不停變化並且矛盾的需求文檔。
當一個團隊糾纏於無窮無盡的用例文檔時，另外一個團隊在開發領域模型。不停變化的UML文檔淹沒了這個團隊。每週，模型都要重新做。團隊的成員無法決定在模型中是使用《interfaces》還是使用《types》。關於OCL的適合語法以及應用方面，出現了很大的不同意見。團隊中的有些人完全違背了5天課程中關於“分解”的內容，他們創建的圖是不可思議的詳細和晦澀，所有其他人都無法理解。
3月27日，距離分析完成還有一週時間，你們已經產生了大量的文檔和圖示，但是你們對問題的分析卻和1月3日對此的分析一樣的淺薄。
***
接着，奇蹟發生了。
***
4月1日，星期日，你在家中檢查你的電子郵件，看到一封你的上司發給BB的便函。上面明確地寫道你已經完成了分析！
你給上司打電話並抱怨道，“你怎麼能告訴BB我們已經完成了分析呢？”
“喂，你看過日曆嗎？”他回答，“今天是4月1日！”
你沒有忘記這個日期的諷刺意義，“可是，我們還有很多問題要考慮，很多東西要分析！我們甚至還沒有決定是用《extends》還是用《precedes》！”
“你憑什麼說你們還沒有完成？”你的上司不耐煩地問道。
“我……”
但是他打斷了你，“分析永遠也做不完，必須要停在某個點上。因爲今天就是計劃要結束的日棋，所以它就停在今天。星期一，我希望你把現有的所有分析資料收集起來放在一個公共的文件夾中。把該文件發給Prudence，這樣他就可以在星期一中午前把它等人CM系統。接下來就開始設計工作吧。”
當掛斷電話時，你開始思考在寫字檯底部的抽屜中保存一瓶波旁威士忌酒的好處。
***
他們舉行了一個宴會來慶祝分析階段按時完成。BB發表了一通有關授權的激動人心的講話。你的上司，其發尖又另外增長了3mm，也祝賀他的團隊所表現出的不可思議的團隊和團隊協作精神。最後，CIO登臺並告訴大家SEI的審計工作進行得非常順利，並且告訴大家學習並撕碎了所發的評估指南。看來，在6月肯定可以被授權CMM3級。
（有傳言說，一旦被SEI授予了CMM3級，與BB同層以及更高層的管理者就可以得到豐厚的獎金。）
幾周過去了，你和你的團隊一直在進行系統的設計。當然，你發現設計基於的假設分析是有缺陷的……不，毫無用處……不，比無用還糟。但是，當你告訴你的上司需要返回去再多一些分析工作以及加固分析中的薄弱部分時，他只是說道，“分析階段已經結束了。唯一允許做的事情是設計。現在回去設計吧。”
於是，你和你的團隊盡最大努力去拼湊設計，不知道是否正確地分析了需求。當然，實際上，這也沒有什麼大問題，以爲需求文檔仍然每週都在劇烈地變化着，並且市場部仍然拒絕和你們見面。
設計是一場噩夢。很不幸，你的上司最近讀了一本書The Finish Line（完成期限），其中，作者Mark DeThomaso輕率地建議設計文檔的詳細程度應該達到代碼級。
“如果我們要達到這個詳細程度，”你問道，“那麼爲什麼我們不直接去編寫代碼呢？”
“因爲那樣的話，你當然就不是在設計了。而設計階段唯一允許做的事情就是設計。”
“此外，”他繼續說，“我們剛剛購買了一個Dandelion的公司範圍內使用的許可證！這個工具支持‘超級轉換工程’！你只要把所有的設計圖傳遞給它，它就會爲我們自動生成代碼！同時，它還會保持設計圖和代碼的同步。”
你的上司把一個色彩明亮、用塑料薄膜包裝的盒子交給你，裏面裝着銷售版的Dandelion。你麻木地接過它，步履蹣跚地回到你的小臥室。12小時後，你終於把該工具安裝到你的服務器上，安裝的過程經歷了8次崩潰、一次磁盤重新格式化並玩了8輪射擊遊戲。你想了一下你的團隊參加Dandelion培訓要浪費的那一週。接着，你露出微笑並想到，“不過在這裏度過的任何一週都會是愉快的一週。”
一個接一個的設計圖被你的團隊創建出來。Dandelion使這些圖的繪製變得非常困難。其中會遇到大量的深層嵌套的對話框，並且必須正確填寫這些對話框上的一些滑稽可笑的文本域以及檢查框。接着，就會碰到在包之間移動類的問題……
起初，這些圖都是來自用例的。但是由於需求的頻繁變動，用例很快都變得毫無意義。
關於是應該使用Vistor模式還是Decorator模式的爭論爆發出來，一個開發人員拒絕使用任何形式的Vistor模式，聲稱它不是真正的面向對象概念。另外一個拒絕使用多重繼承，因爲它會帶來麻煩。
評審會議很快就變成有關面向對象的意義、分析和設計的定義以及如何使用聚集和關聯的爭論。
在設計週期的中期，市場人員宣稱你們重新考慮了系統的中心內容。他們徹底重新組織了一份新的需求文檔，去掉了一些主要的特性範圍，取而代之的是一些他們從客戶調查中預見的更合適的特性範圍。
你告訴你的上司，這些變更意味着需要對系統的大部分內容進行重新分析和重新設計。但是他卻說，“分析階段已經結束。唯一允許做的事情是設計。現在回去設計吧。”
你建議創建一個簡單的原型展示給市場人員，甚至一些潛在的客戶，這樣可能會好一些。但你的上司卻說：“分析階段已經結束。唯一允許做的事情是設計。現在回去設計吧。”
拼湊、拼湊、拼湊、拼湊。你設計創建了某種也許會真實反映新需求文檔的設計文檔。但是，需求的徹底更改並沒有導致它們停止變動。事實上，如果說有的話，就是需求文檔的瘋狂變動只是頻度和幅度方面有所增加。你在它們的包圍中艱難地前進着。
6月15日，Dandelion的數據庫遭到了破壞。顯然，破壞是逐步形成的。數據庫中的小錯誤在幾個月內累計成越來越大的錯誤。最後，CASE工具完全停止工作了。當然，逐步形成的破壞在所有的備份中都有出現。
給Dandelion的技術支持人員打了幾天的電話，都沒有得到任何答覆。最後，你收到了一封來自Dandelion的簡短的電子郵件，通知你這是一個已知的問題，解決辦法就是購買新的版本（他們承諾新版本在下季度的某個時候可以使用），然後手工重新輸入所有的圖。
***
接着，7月1日另外一個奇蹟發生了！你完成了設計！
這次，你沒有去見你的上司並抱怨什麼，相反你在寫字檯中間的抽屜中放入了一些伏特加酒。
***
他們舉行了一個宴會來慶祝設計階段的按時完成，以及通過了CMM3級認證。這次，你發現BB的講話非常地煽情，因此你只好在開始前就躲在休息室中。
在你工作的地方遍佈着一些新的標語和牌匾。上面顯示着鷹和登山者的圖案，並且寫着關於團隊協作以及授權方面的內容。上面增加了一些方格線後，辨認起來好多了。這讓你想起你需要在你的文件櫃中騰出點地方來放白蘭地。
你和你的團隊開始編碼。但是你很快就發現設計在一些重要的地方存在不足。實際上，它在所有重要的方面都有缺乏。你在一個會議室中召集了設計會議，試圖解決一些嚴重的問題。但是你的上司在會議室中抓住你並解散了會議，說：“設計階段已經結束。唯一允許做的事情是編碼。現在回去編碼吧。”
Dandelion發生的代碼實在是醜陋。你和你的團隊終究還是誤用了關聯和聚集。爲了改正這些錯誤，必須編輯所有生成的代碼編輯這種代碼異常的困難，因爲它上面添加了一些具有特殊語法的醜陋註釋塊，Dandelion要使用這些註釋來保持圖和代碼之間的同步。如果你不小心更改了某個註釋，那麼重新生成的圖就會不正確。結果表明，“超級轉換工程”還需要非常多的工作要做。
你越是想保持代碼和Dandelion兼容，Dandelion產生的錯誤就越多。最後，你放棄了這種做法，並決定手工地使圖保持最新。一秒鐘後，你發現使圖保持最新根本沒有意義。此外，以誰的時間爲準呢？
你的上司僱傭了一個顧問來構建一個計算所編寫的代碼行數的工具。他把一張很大的座標紙貼在牆上，在頂部標出了數字1000000。每天他都會延長紅線來顯示增加了多少行代碼。
貼出座標紙3天后，你的上司在大廳裏攔住你。“那張圖增長得不夠快。我們要在10月1日完成100萬行代碼。”
“我們還不確信該產品會需要100萬行代碼。”你急着說。
“我們必須在10月1日完成100萬行代碼。”你的上司重複着。他的發尖再一次增長了，並且他在它們上面使用的希臘式配方營造出一種權威和能力的氛圍。“你確信你們的註釋塊足夠大嗎？”
接着，他立刻閃現出了管理方面的洞察力，說：“我知道了！任何一行代碼都不能超過20個字符。任何超過20個字符的代碼行必須分成兩行或者更多的行—越多越好。現有的所有代碼都必須按這個標準改寫。這會使我們的代碼行增加！”
你決定不告訴他這需要2個計劃外的工作月。你決定根本不告訴他任何事情。你覺得靜脈注射酒精是唯一的辦法。你做了適當的安排。
拼湊、拼湊、拼湊還是拼湊。到9月1日，座標圖顯示代碼行120萬行，你的上司讓你寫一個報告描述一下你們爲何超出代碼預算20%。他制定了強制性的週六加班，並要求項目代碼減少到100萬行代碼。你們開始着手對代碼進行重新合併。
拼湊、拼湊、拼湊還是拼湊。脾氣變得暴躁；人員一個一個辭職；QA把大量的故障報告發給你。客戶在要求安裝產品以及用戶手冊；銷售人員要求給特殊的客戶進行一些預先的演示；要求文檔仍然在變動；市場人員在抱怨產品根本不是他們所要的，賣酒的店鋪也不再賣給你酒了。必需要交出一些東西了。9月15日，BB召開了一次會議。
當他走進會議室時，他的發尖散發着朦朧的霧氣。當他說話時，他精心修飾過的低音致使你的胸口要翻轉過來。“QA的管理人員告訴我，這個項目只實現了不到50%的必需的特性。他還告訴我係統總是會崩潰，產生錯誤的結果，並且非常慢。他還抱怨他無法跟上連續的每日發佈，每次發佈都比不上一次出現更多的錯誤！”
他停頓了幾秒鐘，明顯想鎮定一下。“QA的管理人員估計，像這樣開發下去，要到12月份，我們才能夠發售產品!”
事實上，你認爲更可能在明年3月份，但是你什麼也沒有說。
“12月！”BB吼叫着，面帶着嘲笑，每個人都低下頭，就好象他正用一隻突擊步槍對準自己一樣。“12月是絕對不行的。團隊領導們，我希望明天上午在我的辦公室桌上見到新的估算。因此，我要求每週工作65小時，直到這個項目完成。最好能在11月1日完成。”
當他離開會議室時，就聽他他嘀咕到，“授權----呸！”
你的上司禿頂了；他的發尖被安放在BB的牆上。熒光燈照在他的頭頂所反射的光很快使你眼花。
“你這兒有喝的東西嗎？”他問道。剛剛喝完你最後一瓶Boone’s Farm,你又從書架上取下一瓶Thunderbird並倒入他的咖啡杯中。“怎樣做才能完成這個項目?”他問道。
“我們要求凍結需求，分析他們，設計他們，然後實現他們。”你麻木的回答。
“到11月1日？”你的上司懷疑的大叫到，“不！趕快回去編寫這該死的東西。”他抓着他那光禿禿的腦袋氣沖沖地走了。
幾天後，你發現你的上司被調到公司研究部門。銷售量大幅地增長。客戶一知道他們的訂單無法按時完成，就立即要取消他們的訂單。根據市場情況，又對該產品是否符合公司的總體目標進行了評估，等等，等等。信函亂飛，人員被免職，政策改變，總的來說，事態變得相當嚴峻。
最後，到3月份。經過了大量的65小時工作周後。一個非常不可靠的版本完成了。實地使用時，錯誤的出現率非常高，技術支持人員對於發怒的客戶的抱怨和要求束手無策。所有人都不高興。
4月，BB決定通過購買的方式來解決問題，他購買了由Rupert工業公司開發的產品的使用授權並重新銷售。客戶的怒火被平息了，市場人員沾沾自喜，而你被解僱了。
Rupert工業公司:“朝暉”項目
你叫Robert，日期是2001年1月3日。在假期中，你和家人所度過的輕鬆時光使你恢復了精神，準備投入工作。你和你的開發團隊坐在會議室中。部門的管理者召集了這次會議。
“我們有一些關於一個新項目的想法。”部門管理者（稱他爲Russ）說。他是一個容易激動的英國人，他的精力比聚變反應器還要旺盛。他雄心勃勃並具有緊迫感，但是他了解團隊的價值所在。
Russ描述了公司瞭解的新市場機遇的基本情況，並把你介紹給Jane，負責定義用來抓住這個機遇的產品的市場管理者。
和你打過招呼後，Jane說，“我們希望儘快開始定義我們首要提供的產品。你和你的團隊什麼時候能和我談談？”
你回答到：“本週五我們會完成項目的當前一次迭代，在這之間，我們可以抽出幾個小時和你談談。迭代完成後，我們會從團隊中抽出一些人專門投入到你的項目。我們會立即開始招聘一些人來接替他們併爲你的團隊招聘新人。”
“好極了！”Russ說，“但是我希望你明白，7月份我們要在產品展覽會上拿出一些東西展示，這很重要。如果我們到時不能拿出一些有意義的東西，我們就會失去機會。”
“我明白，”你回答道，“雖然我還不知道你打算做的是什麼，但是到7月時肯定可以拿出一些東西來。我還不能馬上告訴你那些東西是什麼。無論如何，你和Jane將完全控制着開發人員的開發方向，所以你可以放心，到7月要去展示時，你會拿到可以完成的最重要的東西。”
Russ很滿意地點點頭。他知道這種工作方式。你的團隊總是能讓他了解並把握開發情況。對於你的團隊會首先着手於最重要的工作並產生出高質量的產品這一點，他極有信心。
***
“那麼Robert，”Jane在第一次會面時說到，“你的團隊對被分開是怎麼看的？”
“我們會懷念在一起工作的日子，”你回答道，“但是，我們中的一些人對於最近的一個項目相當厭倦了，並且期望有一些變化。你那邊在做些什麼呢？”
Jane微笑着說：“你知道我們的客戶當前遇到了很大的麻煩……”接着她用了大約半個小時來描述問題以及可能的解決方案。
“好，請稍等一會兒。”你說道，“我需要把這搞清楚。”因此，你和Jane談論了系統可能的工作方式。Jane的一些想法並沒有完全成形。你提出了一些可能的方案。她對其中的一些表示贊同。你們繼續討論。
在討論期間，對於所提出的每個新主題，Jane都編寫了相應的用戶故事卡。每張卡片都描述了新系統必須要做的事情。卡片堆積在桌子上，展開在你們的面前。當你們討論這些故事時，你和Jane都會指着它們，把它們拿起來，並在上面做一些記錄。這些卡片是有效的助記工具，你們使用它來描述一些剛剛成形的複雜想法。
在會談結束時，你說：“好，我對你想要什麼已經有了一個大體的認識。我和我的團隊會對它進行討論。我想他們會對各種不同的數據庫結構以及表示格式進行一些實驗。下次我們會面時，就會有一個團隊，並且我們會開始確定系統最重要的特性。”
一週後，你新建的團隊和Jane會面。他們把現在的用戶故事卡鋪開在桌子上並開始研究系統的某些細節。
會議非常有生氣。Jane把故事卡按照它們的重要性排好。對於每一個故事都進行了大量的討論。開發人員關心的是要保持故事足夠地小，這樣便於估計和測算。所以他們不斷地要求Jane把一個故事分成幾個小一些的故事。Jane關心的是每個故事都要有一個清晰的商業價值和優先級，倘若她對故事進行了分割，她就會保證這一點。
故事堆積在桌子上。Jane在編寫它們，不過，在需要時開發人員會在上面寫上註釋。沒有人試圖去捕獲所談論的每一件事情。故事卡不必捕獲所有的東西；它們只不過在會議中起到提示作用。
當開發人員對故事較滿意時，他們就開始編寫對它們的估算。這些估算很粗糙並且只是一種預算，但是它們卻使Jane對故事的代價有一個概念。
會談結束時，明顯還有許多故事可以討論。同樣，你們也清楚地知道已經明確了最重要的故事，實現這些故事需要幾個月。Jane結束了會議，她帶走了故事卡並承諾明天上午會拿來一份關於第一次發佈的方案。
***
第二天早上，你又召集了會議。Jane挑選了5個故事卡，把它們擺放在桌子上。
“根據你們的估算，這些故事卡代表着理想情況下一週的工作量。上一個項目的最後一次迭代在3周內完成了這些工作。如果可以在3周內完成這5個故事，我們就能夠把它們演示給Russ看。這樣，他就會對我嗯的進度感到非常滿意。”
Jane在催促着。你從她臉上靦腆的表情可以看出她也知道這一點。你回答道：“Jane，這是一個新團隊，從事的是一個新項目。期望我們和前一個團隊具有同樣的開發速度有點專橫了。不過昨天中午我和團隊談過，事實上，我們都同意把最初的速度設定爲每3周完成這麼多工作。所以在這個事情上你非常幸運。”
“還請記住，”你繼續說，“現在，有關故事的估算以及設定的速度都是推測出來的。在做計劃時我們瞭解得會多一些，在實現時瞭解得還要再多一些。”
Jane透過她的眼鏡看着你，好像要說，“在這裏到底誰是上司？”接着她笑着說，“好的，不必擔心，現在我已經知道了規則。”
Jane接着把另外15張故事卡放在桌子上。她說，“如果我們到3月底能夠完成所有的這些故事卡，我們就可以把系統移交給我們的beta版測試客戶。那麼我們會從他們那裏得到很好的反饋。”
你回答說：“好，我們已經定義了首次迭代，並且具有了以後3次迭代的故事。這4次迭代可以完成我們的首次發佈。”
“那麼，”Jane說，“你們真的能夠在接下來的3周內完成這5個故事嗎？”
“我確實不知道，Jane。”你回答道，“我們來把它們分解成任務，看看能得到些什麼。”
於是，在接下來的幾個小時中，Jane、你和你的團隊把Jane爲首次迭代挑選的5個故事中的每一個都分解成小任務。開發人員很快就認識到某些任務可以在故事間共享，並且其他一些任務具有一些可以加以利用的公共點。很明顯，開發人員的頭腦中已經出現了一些可能的設計。他們不時地結成討論小組並在一些卡片上勾勒出UML圖。
很快，白板就被任務充滿了，一旦實現了這些任務，就完成了本次迭代中的5個故事。你開始了簽訂過程，說道：“好，我們來簽訂這些任務吧。”
“我做初始的數據庫生成，”Pete說，“在最近的一個項目我做的就是這個，這看起來並不困難。我估計它需要兩天時間。”
“好，那麼我做登錄屏幕。”Joe說。
“噢，該死！”Elaine，團隊的一個新成員，說道，“我從來沒有做過GUI，我有點想做這一個。”
“哦，年輕人真急躁。”Joe賢明地說，並朝你使了個眼色，“你可以來協助我，年輕人”，她對Jane說，“我認爲我需要大約3天完成它。”
開發人員一個接一個地簽訂了任務並對它們進行了估算。你和Joe都知道讓開發人員自願選擇任務要比任務分配給他們好。你也充分地瞭解你不敢質疑任何一個開發人員的估算。你瞭解這些人，並且信任他們。你知道他們會盡最大努力的。
開發人員知道，他們簽訂的任務不能超過在他們參與的最近的一次迭代中所完成的任務。一旦開發人員關於本次迭代的時間表安排滿了，他就不再簽訂任務。
最後，所有的開發人員都停止簽訂任務。但是，當然，白板上仍剩有任務。
“我就擔心這會發生，”你說：“好，現在只有一件事情要做，Jane。我們在這次迭代中做的過多了。我們可以去掉哪個故事或者任務呢？”
Jane嘆了口氣。她知道這是唯一的選擇。在項目一開始就加班工作是非常愚蠢的，並且出現這種情況的項目也不會成功。
於是，Jane開始去掉最不重要的功能。“嗯，此時，我們還不是真正的需求要登錄界面。我們完全可以在登錄後的狀態中啓動系統。”
“胡說！”Elaine叫道，“我實在是想做這個。”
“耐心點，急性子，”Joe說道，“只有等密封離開蜂箱後，享受蜂蜜時纔不會蟄腫嘴脣（欲速則不達）。”
Elaine顯得很困惑。
每個人都顯得很困惑。
“那麼……”Jane繼續說道，“我覺得我們也可以去掉……”
於是，任務列表漸漸地變少。失去任務的開發人員在剩餘的任務中又簽訂了一個。
商談的過程不是沒有痛苦的。其中有幾次，Jane顯示出了沮喪和急躁。有一次，當局勢特別緊張時，Elaine自願要求“超時工作來彌補時間的不足。”當你正打算糾正她時，還好，這時Joe看着她說：“一旦你走上了錯誤的道路，它就會永遠控制你的命運。”
最後，終於確定下來了一個Jane可接受的迭代。這不是Jane想要的。事實上，它比Jane想要的要少得多。但是這是團隊覺得他們可以在接下來的3週中可以完成的東西。並且，畢竟仍然在迭代中完成了Jane想要的最重要的事情。
“那麼，Jane，”你在會談接近尾聲時說，“你何時能夠提供驗收測試呢？”
Jane嘆了口氣。這是事情的另一個方面。對於開發團隊實現每個故事，Jane必須提供一組驗收測試來證明它們可以使用。並且團隊遠在迭代結束前就需要這些驗收測試，因爲它們會明確地指出Jane和開發人員對系統行爲認識上的差異。
“今天我會提供給你一些測試腳本的例子，”Jane許諾道，“此後的每一天，我都會增加一些。到迭代的中期，你就會擁有完整的測試集。”
***
迭代在週一早晨開始了，我們開了一個急速的類—職責—協作者（CRC）會議。到上午10點左右時，所有的開發人員都已經組合成對，並在快速地編碼。
“現在，年輕的學徒，”Joe對Elaine說，“你該學習一下測試優先設計的技術！”
“哇，這聽起來相當不錯。”Elaine回答道，“你是如何做到的？”
Joe微笑了一下。顯然，他已經預見到了這一刻。“年輕人，現在代碼做了些什麼呢？”
“嘿？”Elaine回答道，“它根本什麼都沒有做，還沒有代碼呢。”
“好，考慮一下我們的任務。你能想起一些代碼應該做的事情嗎？”
“當然可以。”Elaine帶着年輕人的自信說道，“首先，它應該鏈接到數據庫。”
“那麼，要鏈接數據庫，必須的東西是什麼呢？”
“你說話真是古怪，”Elaine笑着說，“我認爲我們必須要從某個註冊表（registry）得到數據庫對象，並調用其Connect（）方法。”
“哈！敏銳的年輕奇才。你正確地察覺到了我們需要一個對象，在該對象中我們可以緩存（cacheth）數據庫對象。”
“‘cacheth’是一個真實的單詞嗎？”
“在我說出它時，它是的！那麼，我們可以編寫哪些我們認爲數據庫註冊表應該通過的測試呢？”
Elaine嘆了口氣。她知道她必須合作下去。“我們應該創建一個數據庫對象並用Store（）方法把它傳遞給註冊表。然後，我們應該能夠使用Get（）方法把它從註冊表中取出來並證實它就是上一個對象。”
“哦，說得對，我的年輕搗蛋鬼！”
“嗨！”
“那麼，現在，我們來編寫一個測試函數來檢測你所說的情形。”
“但是，我們不應該先編寫數據庫對象和註冊表對象嗎？”
“啊，你還有許多東西需要學習，沒有耐心的年輕人，先編寫測試。”
“但是這甚至無法編譯！”
“你肯定？如果可以編譯怎麼辦呢？”
“嗯……”
“先編寫測試，Elaine。相信我。”
於是，Joe，Elaine以及所有其他開發人員都開始編寫他們的任務，每次一個測試用例。他們工作的房間中充滿了結對人員之間交談的嗡嗡聲。嗡嗡聲不時被告呼聲中打斷，這些高呼聲就是某一對人員完成了一個任務或者通過了一個困難的測試用例時所發出來的。
在開發的過程中，開發人員每1～2天就更換結對夥伴。每個開發人員都會了解所有其他人做的東西，因此關於代碼的知識就廣泛地在整個團隊中傳播。
每當一對人員完成某個重要的東西，不管是一個完整的任務或者僅僅是任務的一個重要部分，他們都會把完成的東西和系統的其餘部分集成起來。這樣，代碼基每天都在增長，並且集成的難度被減少至最小。
開發人員每天都和Jane進行交流。每當他們對系統的功能或者驗收測試用例的解釋有疑問時，都會找Jane。
Jane很好履行了她的諾言，平穩持續地給團隊提供驗收測試腳本。團隊用心地理解這些腳本，從而對Jane期望系統做的東西有了更好的理解。
到第二週初時，所完成的功能已經足以演示給Jane。Jane熱切地觀看着，演示通過了一個接一個的測試用例。
“這真是太棒了，”當演示最後結束時，Jane說道，“但是這看起來好像不到1/3的任務。你們的速度比預期的慢嗎？”
你皺起眉頭。你本來想等待一個合適的時機把這告訴Jane，但是現在她卻提前提出了一個問題。
“是的，很遺憾，我們比期望的要慢一些。我們使用的新應用服務器配置起來很費勁。並且，還得常常重新啓動它。每次即使我們對它的配置做了最微小的更改，都必須重新啓動它。”
Jane用懷疑的眼光看着你。上週一商談中的緊張狀態還沒有完全消散。她說：“那麼，這對我們的進度意味着什麼呢？我們不能再落後進度了，絕對不能。Russ會很生氣的！他會懲罰我們所有人，併爲我們增加一些新人手。”
你一直看着Jane。這樣的消息是沒有辦法以令人愉快的方法說出來的。於是你完全不假思索的說道：“看，如果事情還像這樣進行下去，那麼到下週五時，我們將不能完成所有東西！現在我們是有可能找出一條可以快一些的方法的。但是，坦白地說，我不會依賴於它的。你應該考慮一下從迭代中去掉1個或者2個任務，而又不破壞給Russ的演示。無論如何，我們都會在週五進行演示的，並且我認爲你不會想讓我們來挑選去掉哪些任務。”
“啊，看在上帝的面上！”當Jane搖着頭大步離開時，幾乎無法抑制住喊出最後一句話。
不止一次，你對自己說，“從來沒有人敢向我保證項目管理會是容易的。”你非常肯定這也不會是最後一次。
***
實際的情況要比你期望的稍好一些。事實上，團隊確實從迭代中去掉了一個任務，但是Jane做了明智地選擇，所以給Russ的演示很順利。
Russ對進度沒有太深的印象，但是他也沒有感到沮喪，他只是說：“相當好。但是記住，我們必須能夠在7月的展覽會上進行演示，如果以這樣的速度的話，看起來你們不能完成所有的要展示的東西。”
Jane的態度在迭代完成後有了很大的改善，她回答Russ說：“Russ，這個團隊工作得很努力，也很好。到7月時，我確信我們會演示一些最重要的東西。它不是所有的東西，並且其中的一些可能沒有真正的實現，但是我們會有一些東西的。”
雖然剛剛結束的迭代很費勁，但是它卻校準了你們的開發進度。接下來的迭代好了許多。這並不是因爲你的團隊完成了比上一次更多的任務，而只是因爲不必在迭代的中期去掉任何的任務或者故事。
到第四次迭代開始時，一個自然的開發節奏建立起來哦。Jane、你以及開發團隊都可以準確地知道彼此期望的是什麼。雖然團隊工作得很艱苦，但是開發速度卻是可持續的。你確信團隊能夠在一年或者更長的時間內保持這個速度。
在進度方面幾乎沒有出現什麼問題；但是在需求方面卻非如此。Jane和Russ常常檢查逐漸增長的系統並對現有的功能提出一些建議和更改。但是任何一方都知道這些更改是花費時間的並且必須要列入計劃。因此，更改沒有導致對任何人期望的違背。
在3月，你們給董事會做出了一個該系統的較大型的演示。系統功能非常有限，還不足以拿到展覽會上去演示，但是進展卻非常穩定，給董事會留下了相當深刻的印象。
第二次發佈甚至比第一次還要順利。現在，團隊已經找到了一個可以自己執行Jane的驗收測試腳本的方法。他們同樣也對系統進行重構，直到確實可以容易地向某個增加新特性以及更改原有的特性。
6月底完成了第二次發佈，並拿到展覽會行。系統的功能要比Jane和Russ原本想要的少一些，但是它確實演示了系統最重要的特性。雖然展示會上的客戶注意到了某些功能還沒有實現，但是在總體上卻給他們留下了深刻的印象。你、Russ以及Jane在從展示會上返回時都面帶笑容。你們都彷彿覺得這個項目是一個勝利者。
事實上，許多月以後，Rufus公司和你們進行了聯繫。他們曾經爲了他們的內部業務開發過一個類似的系統。經歷過一個死亡的項目後，他們取消了這個系統的開發，並和你們商談有關在他們的環境中使用你們的技術的授權許可事宜。
情況確實在不斷變好！