一種高效的專案啟動方式——QuickStart,該方法用以確認在專案開始之前理解專案的關鍵驅動因素。來自ThoughtWorks英國分公司的Liv Wild為現場觀眾介紹QuickStart的理念與實踐。

主持人：有請Liv Wild做主題演講，演講的題目是“一種高效的專案啟動方式——Quickstart”。

Liv Wild：今天下午我要談的是需求的收集，特別會談到敏捷行。希望跟大家有個交流，希望大家下午玩兒的愉快，如果你們有問題的話也可以問我。首先做一簡單自我介紹，然後會談需求由誰收集我們的客戶是誰？誰來做需求分析？在敏捷的環境裡面怎麼結果需求的收集，接下來是ThoughtWorks如何幫助你們也效的在資訊通訊專案裡對資訊進行的收集。

　　我有八年諮詢工作的經驗，過去為一非常大的紐約軟體諮詢公司工作，我是一個軟體開發員，後來做業務諮詢，現在在投行、金融、零售等領域做諮詢服務。另外我也參與過很多專案，都是數百萬的這樣一些專案，另外還有一些ICT的管理和電子政務的實踐應用等等。

　　我們的工作都是非常有效的。來到ThoughtWorks之後我的這個團隊的這些人就是想有更好的資料收集的方法，我們今天早晨都談到了ThoughtWorks，我們是一個全球的業務服務企業。我們在全球有700名員工，下面是列出了財富500強的公司客戶。

　　過去30年ICT領域總結一下經驗：首先要知道使用者的需求，把所有東西寫下來找個人簽字，然後嚴格執行我們的計劃，所以程序一開始大家把需求進行評估。我們看到在美國、歐洲有一些非常有意思的ICT的專案，有個非常有趣的例子，比如美國的丹弗機場有一個行李自動吞吐的系統，這麼高階的只有一個機場利用它，很浪費。美國的一個這樣的系統是花了3680萬美元，拖延了三年才完成，英國也是一樣我們有一個國家航空交通服務系統，就是空氣航空交通的。是96年上馬，準備花3.5億英鎊，但是最後花了差不多6億英鎊。我們要想為什麼有這些問題呢？專案收集需求方式重要的是沒有幫助大家滿足這樣的要求，在這樣的專案中我們是過去瀑布式的開發方式，軟體要進行分析、設計、測試最後實施，最後發現撞車了。我們的需求是隻是在專案開始收集一次就完了。橫向是一個時間軸，時間非常長，根本無法反應客戶真正的需求。如果有一萬個需求，你怎麼理解這麼多呢呢？對於一個人來說很難理解真正的需求到底是什麼？

　　看一下敏捷如何處理需求的？這是一個時間軸、分析、然後設計、然後迭代1、迭代2。分析和設計在整個專案過程中都是貫穿的，貫穿於整個專案生命週期中。最後要想有一個“新車”的就真的能做出一輛“新車”。（演示）這個案例是幫助客戶首先了解需求，但是沒有很好的解釋我們的需求從何而來？首先客戶是誰，誰來確定這些需求？我們所稱的客戶是有共同意願的個體或者群體，他們告訴我們程式設計師軟體怎麼寫？他們可以確定一些功能，並且解釋為什麼這個功能是必要的。然後可以把這個功能進行量化，每一個需求都對它的業務有價值貢獻。並不是永遠都可以把功能能夠量化，當然你還是可以努力去量化，實在沒有量化也沒有辦法。我們的客戶應該在專案週期裡騰出一些時間和開發團隊進行交流。

　　當然不能非常清楚的解釋我們在一些業務流程中的一些問題，我們在業務開始的時候要考慮業務有多大，作為諮詢公司我們要問自己是不是有資格解決這樣的問題？或者說我們願不願意解決這種問題，很可能這種問題它不符合我們的理論，很可能我們也沒有什麼特別的能力去解決。另外，你如何找到解決的方法？是不是現在有想法，有了想法怎麼融入進開發中。我們剛才談的都是故事，我們要談客戶的故事從哪兒來、成本是多少、要花多長時間，解決方案交付結構式什麼樣？如何讓大家改變自己的思維方式？如何與客戶建立初期的關係？對我們ThoughtWorks來說我們要管理好與客戶之間的關係是非常重要的，這有利於我們諮詢工作的展開。當你聽到敏捷行的話，很可能都聽不到BA，我們是談客戶和開發者。我就是一個BA，我每天干什麼呢？我從來不與客戶交流，因為對中國客戶來說好像不願意花太多時間根據我們倡導的模式跟我們交流，他們每天都有自己的事情要做。我們希望他們能抽出時間跟我們交流。BA希望客戶時間能夠花的物有所值。我們要從客戶這邊知道為什麼開發這個軟體？我們要確保我們的客戶知道自己到底要什麼而且明確的表達。即是過程中根據我們的分析，他們改變願望，產品最終符合需求。敏捷行有各種各樣的方式幫助客戶參與到我們的開發過程中。它和傳統的方式相比有很多優勢，我們BA是幫助客戶瞭解有什麼樣的問題，然後幫助客戶解決這些問題。這就是為什麼我們ThoughtWorks把資訊收集的方法叫快速QuickStart。QuickStart是為了瞭解需求從何而來，它是用敏捷行提供一個專案產品，把專案規模處理好，要建立專案的需求關係，要確保這專案是有最大成功的可能性。

　　所以我們個Quickstart方法優勢，是它完全反應業務真正的需求。有時候專案初期的需求和最終的需求是不一樣的，我們是可以解決這個問題的，作為業務本身來說我們要了解好問題和解決的方法。我們在不同的專案中可能大家都有自己的想法，對解決方案的想法也不一樣，所以他們應該共同分享對不同問題的看法，這種理解也是共享的。與實施專案的人是共享的，比如說IT部門。對需求來說就是要看需求如何符合業務的價值，敏捷是能夠很好的促進這種理解並最後加以實施。每一個需求是與某種業務目標能夠關聯的，也就是說不僅僅是IT做什麼就做什麼，而是每一個需求都是功能驅動的，都可以滿足某一個特定業務的目標。作為Quickstart還有一個快速接觸的功能，就是分析階段非常迅速大家都可以參與其中，都可以理解他們要做什麼我們有一個堅定的基礎最後把專案交付。各種改變我們都是擁抱改變的，這些改變都能夠整合到過程中，這種改變還是受到大家鼓勵的，這就是我們專案的開始。

　　有些業務專案常常有這樣的情況，我們的業務員工、IT員工和使用者他們很可能互相都不交流也不關注，大家也不是特別友好。他們之間是對抗的關係，而且他們的溝通也是有缺陷的，這樣最終對使用者來說是一個大麻煩，最後不能拿到自己想要的產品。Quickstart可以幫助改變這種關係，把瓶頸消除，最後都能更好的交流，來自業務，IT和終端使用者能夠協同合作。最後所有的相關方都有一個共識，互相都可以瞭解對方的需求是什麼。我們看一下Quickstart到底是什麼樣？它是包容性的，也是合作型的，我們有很多討論會，有來自於IT部門和終端使用者的代表，他們都能達成共識，同時也是能快速實現的。Quickstart一般來說花四個星期的時間，四個星期之後大家都有共識了我們這樣做速度是非常快的，我們不一定要有非常快的交換。如果大家有改變的想法必須要告訴我們，我們的模式是互動性的，也是非常視覺化的，不是通過文字來做的。另外我們也經常用圖片，這樣就更加有互動性。我們討論所有東西在成本上都有關注。也就是說來自業務的人們他就會告訴我們他們需要的是什麼，來自我們開發部門人會說，這麼做需要什麼樣的成本等等。我們做出的都應該是合理的決定，這些決定取決於我們的業務到底是什麼，這麼做的成本是什麼？這是前期的分析。前期的分析和過去的瀑布模型的開發方式是不一樣的。

　　我們是持續的進行貫穿專案週期的分析，這是Quickstart的特點。（圖）這是工作的場景，可以看到都是由故事卡片組成，（圖）這是我們的例行會議，客戶討論他們的需求到底是什麼，然後我們有四個禮拜，每個禮拜末都有最終展示，最後有一個終極展示。我們差不多每天都有一個展示，這樣能從客戶那邊獲得他們的反饋。

　　Quickstart它是可以量身定製的，你可能有自己的想法隨著你對問題理解的改善很可能把原來的需求改變，開始的想法和最後的初衷可能完全不一樣。我們是擁抱這種改變，也鼓勵這種改變，我們希望大家解放思想，不是簡單的重複已經有的系統，而是要進行創新。我們每天都要討論和研討，每天也只有在今天工作完成之後通過討論才能知道我們明天要做什麼。

　　而且在工作討論中我們將會對內容進行修剪，並且保證我們用的分析方法是最適合我們的需求的。這樣可以保證工作人員能夠使用這些工具。尤其是我們看到了如果用以前非常傳統的需求收集工作的方法，不太適宜不斷變化的情況。我們必須要把這種業務的價值體現出來。這就必須在每一次做總結的時候都有一個產品出來。大家可以看到我們有一個專案，而且我們有每一個計劃的出臺，希望每一次開始的時候都非常迅速，對所收集到的資訊進行分析和進行再一次的處理。最後我們將會進行回顧。然後再開始第二次反饋，對於上一次的結論進行評價，評價以後對有用的資訊留下來，為下一次交流做鋪墊。Quickstart它實際上並不是完全的替代分析和設計，我們所做的迭代式的分析沒有一個現成的發展規劃可以提供。分析過程中不斷有新的需求出現，所以每一次都是反覆實驗之後得出結果，在根據這個結果做下一次實驗。我們第一次迭代中出現了一些問題，新的問題可能會加入我們的故事卡中。Quickstart是以模式為基礎的，人是有不同的思維模式的。比如說這個人想的模式跟另一個人就不一樣，當一個人對某一件事情進行評述和描述的時候可能和其他人的描述方式不一樣。即使讀同一樣的東西表達方式也是不一樣的。我們要做的事情就是在圖表上或者在黑板上寫出來他們對此問題的看法。或許這些看法是不一樣的，但是在板子上所表達出來的內容是有一種更好的集中性，而且會經過反覆實驗將最終的共識能夠表現出來。

　　我們現在所使用的模式都是基於Quickstart，我們是基於一些優先專案目錄進行的，並且還有一些構架式的模式作為基礎。我們在這種投資的時候必須根據優先專案進行優先投資。而且我們這種原形也必須要反映這種優先。寫編碼的時候也要表現這種模式，因為每一個模式都在不斷的變化和更新。所以做更新的時候有不同的方法，每一個模式都會隨著要求的改變而不斷的改變。首先從業務角度來看，首先有一些目標，這些目標是什麼，比如說呼叫中心我們的目的就是每一個迭代週期之內要非常明確我們的目標是什麼，把這些目標優先的專案列出來。

　　還有我們也有一些業務個案，這些個案可能使用的是比較低容量的渠道，這是一種金融的模式。我們在這個過程中會區分出低層次和高層次的分析過程，這種分析的過程都包含了一種優先效能的體現。尤其是我們的目的在不同的層次上都會有體現。時間上也有不同的要求。這些都是在功能上的需求，而且對每一個案來說要求都是不一樣的，甚至時間的要求都不一樣，我們做的時候這些需求都要列出來。從開發者角度來看我們必須把所有的這些層次連線起來，而且要了解每一個要求和某一個業務目的都是息息相關的，不是孤立的。

　　Quickstart中通常是這樣做，要列出我們的要求，低層次故事的要求，同時開發者有沒有什麼特殊的需求，同時要找到專案本身如果要完成有個性化的需求。這種分析並不是傳統的分析，也不是我們經常做的方式，因為有不斷的變化，只有變化是不變的。如果我們一開始就做了大量的話也許最後是一種浪費，所以是在變化不斷過程中進行分析。尤其是高層的運作過程中我們必須有一個明確的目標，當目標不變的情況，也許情況發生變化我們也不會改變初衷。而且必須瞭解這個層次中有什麼樣的限制？我們同時在整個過程中也會出現迭代情況，我們所使用的舉證應該是體現一種價值。我們的能力是可以拓展到哪一步，應該從哪個角度拓展都應該要考慮到它是否能體現更多的價值。

　　Quickstart並不會做特別大量的分析工作，所以我們要不斷的進行討論。而且我們進行小組的討論和分析工作是非常具體的。我們也可以將現在所使用的分析功能或者分析手段用於下一步，但是分析的功能也是不斷變化的。我們也要進行最後的審查，比如說商業目標是否達成了？驗收專案成果，然後看一下這些優先目標是否得到了體現？我們的路線圖是否能夠更好的得到體現和遵循？當我們的產品出臺的時候我們所要做的並不是專案本身是否完成，而是專案它本身的要求和目的是否得到了體現和實現。還要非常清楚的看到目前的現狀和今後可能會發生的變化。尤其是有些專案是跨越一些領域的，在整個過程中也許每一個步驟和每一個分析功能是特定的，不可能做長遠的拓展。所以這種迭代的過程是非常複雜的。還要有一個非常好的架構模式，尤其是使用高效率原形體現的時候，可能在現實生活中我們程式設計人員面臨著非常具體的工作。但是，我們所使用的技術有些時候可能不適於消費者真正的需求，所以要做的就是先把技術放一邊，先看客戶需要什麼？尤其是我們還要分析一下主故事鏈或者故事目錄是哪些？然後才能找到最重要的需要花功夫的地方，最後運作出一個非常高層次的計劃。也許我們不可能在很短時間內把所有的專案和要求得到滿足。但是我們是在不斷的變化過程中的，而且這總比花很多力氣在一大堆檔案中分析更好，因為人們的判斷是非常短期的，尤其是短期的價值或者它的期待值和一開始所做的分析以及其所獲得的結果是不一樣的。我們能夠提供什麼樣的服務？比如說我們有很多檔案，我們就必須運作出一個業務模式。然後進行一個小結，就是我們最主要做的工作是哪些，如何保證目的能夠達成。如果沒有達到的話我們就必須做一個決定：是否這個計劃應該按原計劃進行下去？比如說一個業務的流程，在過程中我們必須確定有哪些會參與其中，他們的需求是哪些、限制是哪些，然後畫一些列表出來。這些需求目錄列出來以後可以看到了哪些是主要的，哪些是次要得？誰做這個工作呢？我們經常所做的就是由客戶和核心小組對分析進行收集和整理，比如我們有BA、QA和開發員，每個人都各司其職，每天都必須要做分析的工作和協調工作。還要在整個運作過程中必須要做一個協調，每個人對自己手上的工作都必須非常明確，BA、QA、和開發員要有很好的溝通。我們可以讓BA保證這些需求能很好的互通，每個人都瞭解自己的工作是什麼。當然我們還有一個領域專家，這個領域專家要知道自己說的是什麼，也要知道這個專案的走向。比如每天工作八個小時，八個小時之內每個人工作要達到目的是什麼，每天結束的時候工作目的是否達到？中午休息的時候也許他們還可以進行進一步的交流。我發現這種溝通的方式能夠讓組員不斷的知道什麼叫敏捷？過程中也許有一些技術性的問題，他們也可以在談話的過程中進行解決和磨合。

　　專案的工作人員他們有些時候對某些方面持有固有的想法，但是這種固有的想法可能比較偏激，如果要進行全面的溝通，做評估的話就可以知道具體磨合這種偏激要花多長時間，工作中的每個環節，每個星期要花4個小時進行溝通。Quickstart是什麼意思？這是一個時間表，表示了Quickstart的走向。它們進行定期的會議，每天早上從10點鐘開始，之後整個早上他們都會看自己要做什麼，而且在中午吃飯的時候何以選擇這個進行進一步的交流。每天下午的時候他們都要對當天的工作做一個回顧，保證工作流程非常速度和無障礙。來自業務的這些工作人員也可以參與其中，這樣在整個過程的最後可以得到令各方都滿意的結果，而且每一個展示過程中也可以表現出每一個工作小組的成果，這種小結是非常全面的。

　　接下來有一個核心小組分析工作，下午有一個小組分析。來自業務和技術的人員進行溝通，我們也有一個大家都站著回顧的過程，時間非常簡短。這意味著我們的工作不可能做到每一次都非常迅速，但是這是我們的目標。我們必須瞭解消費者的心理、客戶的需求，這是最重中之重的地方。謝謝，最後看一下大家有什麼樣的問題？

問：您剛才談到需求是不斷的更迭，我想請問在敏捷設計方法裡，需求是如何和設計進行相互跟蹤的？

Liv Wild：分析和需求是同時進行的我們有技術人員保證他們的設計。在分析中的設計是不斷的重複出現的，我們的反饋可能是來自客戶的、技術人員的，這些技術人員要非常迅速的零拖延的獲得這種需求，從而保證整個設計過程中需求和分析之間不會出現時間的落差。

問：一般傳統的設計方法開始肯定有一個需求規範書，客戶最終會根據這個需求規範書驗收整個專案。如果說整個需求不斷的更迭，什麼階段能形成一個需求的文件供可瞭解整個系統的狀況和驗收這個系統。因為對於一個企業級的專案，比如銀行專案一個人可能都不一定能搞清楚整個專案，可能每個人只是負責區域性，最後整個專案是根據什麼來驗收呢？什麼階段出需求最終形成和整個需求對應的實際文件？

Liv Wild：我們是確保需求和分析每一個迭代期都在做。沒有一個所謂的簽發期，每一個迭代期都是要做決定的。比如說在迭代4，很可能和迭代0的時候是不一樣的，是互相矛盾的，這樣一個週期都是永遠自己給自己有反饋。也就是說做決定的時候就應該是正確的決定。

熊節：我們一會兒安排ThoughtWorks中國同事跟大家交流。感謝Liv Wild的精彩演講！