QuickStart：專案快速啟動之模型與共識

QuickStart：專案快速啟動之模型與共識[@more@]來自：CSDN　

[ 上帝的子民妄想建造一座通天塔，但上帝不悅，他混淆了人類的語言，使得他們無法溝通。]


在一個不大的會議室裡，牆上貼滿了卡片和大白紙，你們幾個人和客戶坐在桌前，老劉是客戶方業務部門的負責人，他正在講述建立使用者的過程，你站起來，在白板上畫了起來：輸入使用者資訊，證明檔案存檔……

大家覺得這個過程沒有問題。

接下來，你向老劉詢問更詳細的資訊和過程細節，並順便把它們畫了出來：證明檔案存檔包括記錄文件編號，掃描並儲存電子文件，儲存紙質文件。

“等等，你是說，使用者建立過程中的文件需要掃描成電子文件嗎？”客戶IT部門的阿志回頭問。“我記得以前是隻登記文件編號，然後把紙質檔案存檔就可以了？”

“沒錯，以前是那樣的，現在我們的新使用者越來越多，業務擴充套件之後，各個地區的檔案要求也不盡相同，還經常需要查詢，只對紙質文件存檔已經不夠了，現在我們每個員工桌子旁邊都有幾大堆這些檔案，現在辦公室裡都沒有地方放了。”老劉解釋說。

“噢！原來是這樣！”阿志點點頭，表示明白了。其它幾個部門的客戶也都同意了這一過程。

接下來，在這次Workshop（討論會）結束之後，你把白板上的草圖整理到電腦上，加到下一次的Showcase（演示）的幻燈片中，在那個時候，會有更多的客戶相關人員參與。

這就是一次典型的QuickStart活動剪輯，開發團隊和客戶團隊在一起，討論專案的需求和範圍，建立模型，就模型進行討論並達成共識。

我們可以看到，很多時候，就算我們在同一個房間，說同一種語言，我們都說：“是這樣的”，我們達成了一致意見，但是，在後面的開發中，還是免不了“需求變更”乃至返工的問題，那麼，QuickStart會怎麼解決這個問題呢？



沒錯，我們建立模型，然後把它們拿出來，放在桌子上討論。接下來，讓視覺化的模型不斷迭代發展，達成真正的一致。



這回，大家所想的，都是同樣的概念了。

這樣透過模型，來消除專案範圍和需求溝通中的歧義，讓大家真正對專案有一致的認識，並且，專案的相關人員不再需要花時間去閱讀大部大部的文件，這一些方面對於專案的啟動和將來的正常執行意義重大。

QuickStart，快速啟動，這是ThoughtWorks公司用敏捷的方式快速啟動專案的過程。我們知道，一個專案的啟動就象一艘輪船啟航一樣，從人員準備，到下水，到全速執行，需要一個啟動的過程，QuickStart就是這樣一個應用多種技術和方法，快速啟動專案的過程。

QuickStart透過一段固定時間的工作，通常是兩到四周（依具體專案規模可延長），每週一個迭代，開發團隊和客戶團隊在一起緊張工作，把客戶的IT部門，業務部門，終端使用者組織到一起，透過協作而高度參與的方式組織Workshop（討論會），Showcase（成果演示）等等具有敏捷特色的實踐來消除溝通瓶頸，讓專案相關各方對專案範圍和高層次的需求達成一致意見。

我們會在QuickStart中把業務價值和實現成本考慮進來，為客戶方對需求進行優先順序排序提供有力的參考。我們也將把可用性和使用者體驗在專案的一開始就納入進來，建立直觀友好的使用者介面原型：

在QuickStart過程中產生的模型還包括財務模型（可選），業務過程模型，使用者模型（人物角色和目標），主使用者故事列表，架構模型等。這些模型並不會精確到開發級別，因為將來我們採用敏捷方法進行開發的時候，還會對它們進行細化和重構。

總的來說，QuickStart是一個採用敏捷方法快速啟動專案的過程，除了前面講到的透過模型讓專案參與各方達成真正的共識之外，它還能讓需求真實地反映實際的業務需要；建立直觀、友好的使用者介面原型；從業務價值和它們的實現成本兩個角度理解需求；需求將會明確地關聯到它們需要支援的業務目標；這是一個快速而高度參與的過程－－將為專案的成功交付打好堅實的基礎，因為我們期望變化，適應變化，而不是對變化進行抵制。

這項專業的快速啟動技術是由ThoughtWorks公司英國分公司幾位資深諮詢師在專案實踐中研究和發展起來的，目前已經在全球6個國家數十個專案得到了成功應用。