---

（一）

你叫Robert。日期是2001年3月。在假期中你和家人所度過的輕松時光使你恢復了精神，準備投入工作。你和你的開發團隊坐在會議室中。部門的管理者召集了這次會議。

“我們有一些關于一個新項目的想法”，部門管理者（稱為Russ）說，他是一個容易激動的英國人，他的精力比聚變反應堆還要旺盛。他雄心勃勃并具有緊迫感，但是他了解團隊的價值所在。

Russ描述了公司了解的新市場機遇的基本情況，并把你介紹給Jay，負責定義用來抓住這個機遇的產品的市場管理者。

和你打過招呼后，Jay說，“我們希望盡快開始定義我們首次要提供的產品，你和你的團隊什么時候能和我談談呢？”

你回答道，“本周五我們會完成我們項目的當前一次迭代。在這之間，我們可以抽出幾個小時和你談談。迭代完成后，我們會從團隊中抽出一些人專門投入到你的項目。我們會立即開始招聘一些人接替他們并為你的團隊招聘新人”

“好極了”Russ說，“但是我希望你明白，7月份我們要在產品展覽會上拿出一些東西展示，這很重要，如果我們到時不能拿出一些有意義的東西，我們就會錯失機會。”

“我明白”你回答道。“雖然我還不知道你打算做的是什么，但是到7月時肯定可以拿出一些東西來。我還不能馬上告訴你那個東西是什么。無論如何，你和Jay將完全控制著開發人員的開發方向，所以你可以放心，到7月要去展示時，你會拿到可以完成的最重要的東西。”

Russ滿意地點點頭。他知道這種工作方式。你的團隊總是能讓他了解并把握開發情況。對于你的團隊會首先著手最重要的工作并產生出高質量的產品這一點，他極有信心。

（二）

“那么 Robert, ”Jay在第一次會面時說，“你的團隊被分開是怎么看的？”

我們會還念在一起工作的日子，“你回答道”，“但是，我們中一些人對于最近的一個項目相當厭倦了，并且期望有一些變化，你那邊在做些什么呢？”

Jay微笑著說，“你知道我們的客戶當前遇到了極大的麻煩......” 接著他用大約半個小時的時間描述了問題以及可能的解決方案。

“好，稍等一會兒”你說到，“我需要把這搞清楚。”因此，你和Jay討論了系統可能的工作方式。Jay的一些想法并沒有完全形成。你提出了一些可能的方案。他對其中一些表示贊同。你們繼續討論。

在討論期間，對于所提出的每個新主題，Jay都編寫了相應的用戶素材卡，每張卡片都描述考慮系統必須要做的事情。卡片堆積在桌子上，展開在你們前面，當你們討論這些素材時，你和Jay都會指著它們，把他們拿起來，并在上面作一些記錄。這些卡片是有效的助記工具，你們使用它們來描述一些剛剛形成的復雜想法。

在會談結束時，你說，“好，我對你想要什么已經有了一個大體的認識。我和我的團隊會對他進行討論。我想我們會對各種不同的數據庫結構以及表示格式進行一些試驗。下次我們會面時，就會有一個團隊，并且我們會開始確定系統最重要的特征”

一周后，你新建的團隊和Jay會面。他們把現有的用戶素材卡在桌子上鋪開并開始研究系統的某些細節。

會議氣氛非常有活躍。Jay把素材按照它們的重要性排好。對于每一個素材都進行了大量的討論。開發人員關心的是要保持素材足夠的小，這樣便于估算和測試。所以他們不斷要求Jay把一個素材分成幾個小的一些素材。Jay關心的是每個素材都要有一個清晰地商業價值和優先級，倘若他對素材進行了分割，他就會保證這一點。

素材堆積在桌子上。Jay在編寫它們，不過，在需要時開發人員在上面寫注釋。沒有人試圖去捕獲所談論的每一件事情。素材卡不必捕獲所有的東西；它們不過在會談中起到提示性作用而已。

當開發人員對素材比較滿意時，它們就開始編寫對它們的估算，這些估算很粗糙并且只是一種預算，但是它們卻使Jay對素材的代價有了一個概念。

會談結束時，明顯還有許多素材可以討論。同樣，也清楚地知道已經明確了最重要的素材，實現這些素材需要幾個月。Jay結束了會議，他帶走了素材卡并承諾明天上午會拿出一份關于第一次發布的方案。

（三）

第二天早上，你又召集了會議，Jay挑選了5個素材卡，把他們擺放在桌子上。

“根據你們的估算，這些素材卡代表著大約50個點的工作量。上一個項目的最后一次迭代在3周內完成了50個點。如果我們可以在3周內完成這5個素材，我們就能夠把它演示給Russ看。這樣，他就會對我們的進度感到特別滿意。”

Jay在催促著。你從他臉上靦腆的表情可以看出他也知道這一點。你回答道，“Jay，這是一個新團隊，從事的是一個新項目。期望我們和前一個團隊具有同樣的開發速度有點專橫了。不過昨天中午我和團隊談過，事實上，我們都同意把最初的速度設定為每3周50個點。所以在這個事情上你非常幸運。”

“還請記住，現在有關素材的估算以及設定的速度都是推測出來的，在做計劃時我們了解得會多一些，在實現時了解得還要再多一些。”

Jay透過他的眼睛看著你，好像要說，“在這里到底誰是上司？”接著他笑著說，“好的，不必擔心，現在我已經知道了規則”

Jay接著把另外15張素材卡放到桌子上。他說，“如果我們到3月底能夠完成所有這些素材卡，我么就可以把系統移交給我們的betab版測試用戶。那么會從他們那里得到很好的反饋。”

你回答說，“好，我們已經定義了首次迭代，并且具有了此后3次迭代的素材。這4次迭代可以完成我們的首次發布。”

“那么，你們真的能夠在接下來的3周內完成這5個素材嗎？”Jay說。

“我確實不知道，Jay，”你回答道，“我們來把它們分解成任務，看看能得到些什么。”

于是，在接下來的幾個小時中，Jay，你和你的團隊把Jay為首次迭代挑選的5個素材中的每一個都分解成小任務。開發人員很快就認識到某些任務可以在素材間共享，并且其他一些任務具有一些可以加以利用的公共點。很明顯，開發人員的頭腦中已經出現了一些可能的設計。他們不時地結成討論小組并在一些卡片上勾勒出UML圖。

很快，白板就被任務充滿了，一旦實現了這些任務，就完成了本次迭代中的5個素材。你開始了簽訂過程，說道，“好，我們來簽訂這些任務吧。”

“我做初始數據庫生成，”Pete說，“在最近的一個項目我做的就是這個，這個看起來并不困難。我估計它需要兩天時間。”

“好，那么我做登錄屏幕。”Joe說。

“奧，該死，” Elmo，團隊的一個新成員，說道，“我從來沒有做過GUI,我有點想做這個。”

“哦，年輕人真急躁。”Joe賢明地說，并朝你使了個眼色，“你可以來協助我，年輕人”，他對Joe說，“我認為我需要大約3天完成它。”

開發人員一個接一個的簽訂了任務并估算了它們。你和Joe都讓開發人員自愿選擇任務要比把任務分配給他們好。你也充分地知道你不敢質疑任何一個開發人員的估算。你了解這些人，并且信任他們，你知道他們會盡最大努力的。

開發人員知道，他們簽訂的任務不能超過在他們參與的最近一次迭代中所完成的任務。一旦開發人員關于本次迭代時間表安排滿了，他就不再簽訂任務。

最后，所有的開發人員都停止簽訂任務。但是，當然，白板上還剩有任務。

“我擔心這些會發生，”你說，“好，現在只有一件事情要做，Jay。我們在這次迭代中做的過多了。我們可以去掉哪個素材或任務呢？”

Jay嘆了口氣。他知道這是唯一的選擇。在項目一開始就加班工作是非常愚蠢的，并且出現這種情況的項目也不會成功。

于是，Jay開始去掉最不重要的功能。“嗯，此時，我們還不是真正需要登錄界面。我們完全可以在登陸后的狀態中啟動系統。”

“胡說，”Elmo叫到，“我實在是想做這個。”

“耐心點，急性子”Joe說道，“只有等蜜蜂離開蜂箱后，享受蜂蜜時才不會蟄腫嘴唇（欲速則不達）”

Elmo顯得很困惑。

每個人都顯得很困惑。

“那么......”Jay繼續說道，“我覺得我們也可以去掉......”

于是，任務任務列表逐漸變少。失去任務的開發人員在剩余的任務中又簽訂了一個。

商談的過程不是沒有痛苦的。其中有幾次，Jay顯示出了沮喪和急躁。有一次，當局勢特別緊張時，Elmo自愿要求“超時工作來彌補時間的不足。”當你正打算糾正他時，還好，這時Joe看著他說，“一旦你走上了錯誤的道路，它就會永遠控制你的命運。”

最后，終于確定下來一個Joe可接受的迭代。這不是Joe想要的。事實上，它比Joe想要的要少的多。但是這是團隊覺得他們可以在接下來的3周中能完成的東西。并且，畢竟仍然在迭代中完成了Joe想要的最重要的事情。

“那么，Jay”當會談接近尾聲事你說，“你何時能夠提供驗收測試呢？”

Jay嘆了口氣。這是事情的另一方面。對于開發團隊實現的每個素材，Jay必須提供一組驗收測試來證明它們可以使用。并且團隊遠在迭代結束前就需要這些驗收測試，因為他們會明確得指出Jay和開發人員對系統行為認識上的差異。

“今天我會提供給你一些測試腳本的例子，”Jay許諾道，“此后的每一天，我都會增加一些。到迭代的中期，你就會擁有完整的測試集”

（四）

迭代在周一早晨開始了，我們開了一個急速的類—職責—協作者（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公司和你們進行了聯系。他們曾經為了他們的內部業務開發過一個類似的系統。經歷過一個死亡的項目后，他們取消了這個系統的開發，并和你們商談有關在他們的環境中使用你們的技術的授權許可事宜。

情況確實在不斷變好！

（全劇終）

【思考】讀完你是否會心一笑，如果是這樣，我想你曾經必定經歷過糟糕的項目，對小品中流程處理和節奏以及結果甚是向往和一種莫名的沖動，無論是瀑布還是迭代敏捷，項目成功唯一不變的標準就是在范圍，進度，質量，成本等相關約束盡可能滿足約束下交付。所以，成功的項目過程首先一個相互協作透明的過程，另外大家形成共識：商業價值，優先級，評估和演進，始終關注核心主流程（功能）。

注： 故事抄摘《敏捷軟件開發-原則，模式與實踐》【美】Robert C.Martin

總結

以上是生活随笔為你收集整理的【项目管理】敏捷小品：Rupert 工业公司 项目：~Alpha~的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。