英文原文：http://www.infoq.com/articles/project-inception-meeting

　　在啟動一個項目之前預先達成團隊共識，這一點在效能和效率上是非常必要的。項目對發起人的重要性體現在哪里？項目如何適用于整個組織的藍圖？項目的最高優先級條目有哪些？以及項目發起人愿意在哪些方面進行妥協？如果團隊成員在這些方面沒有和發起人達成一致，就有可能導致項目進展脫離進度，或者項目成果無法滿足項目發起人的預期。同樣地，如果項目發起人與團隊無法達成一致，項目發起人就可能會對團隊的能力，項目發布的質量與時間抱有不現實的預期。那么，你該如何讓這個廣義上的團隊達成一致呢？

　　通常情況下，團隊成員個人很少會在日常工作中與項目發起人產生大量的互動。通過與整個團隊高忠誠度的交流來達到團隊共識，遠比大量的郵件、文檔和電話會議更為有效。通常情況下，由于地理位置，干系人的時間安排和項目安排的原因，保持整個廣義上的團隊每天都能夠保持高忠誠度的交流是不可能的，但整個廣義上的團隊肯定可以保證在某一個指定的日子里聚在一起。

　　在Pivotal公司，特別是在我們Cloud Foundry團隊，我們保證團隊達成共識的一個有效方法就是開一整天的獨立的會議，我們稱之為初始會議。通過本文，你將會學到與這個方法有關的“為什么”，“什么”和“如何”的有關答案，并且回顧一些從這個方法受益的具體例子，這些案例都來自于真實的Cloud Foundry項目和團隊。

　　什么是初始會議（Inception）？

　　典型的初始會議就是，團隊用一個工作日的大部分時間，專注于為啟動一個新的項目做準備。在需要對進行中的項目進行重新討論的時候，初始會議一樣也可以用于進行了幾個月的項目上。理想情況下，在初始會議之后的第二天，研發團隊就可以開始那些高優先級的、具體的和可操作的用戶故事了。

　　有的時候，啟動會議可以使我們團隊在開工之前，更早的發現干系人或者是項目的目標不清晰，需要做一些額外工作，從而對共同的目標進行提煉和達成一致。在團隊開始工作之前對問題進行澄清和達成一致，遠遠好于團隊已經工作了數周，甚至更長時間之后再重新研究，這些做過的工作遲早也會被丟棄。

　　初始會議與其他流程和方法有關嗎？

　　極限編程（Extreme Programming）有一個概念叫規劃策略（Planning Game）。初始會議的很多元素都是受這個方法啟發。不過在Pivotal公司，我們啟動項目通常都是用非常統一的會議議程，它非常有效。這與和松散定義的規劃策略的議程不同，后者往往貫穿于項目的整個階段，而不僅僅是一天。

　　一些人也許會將“初始”這個單詞與統一軟件開發過程（Rational Unified Process（RUP））中的初始階段（Inception Phase）聯系起來。初始會議和 RUP中的初始階段在語言或目的上都比較相近，但是初始會議是更為輕量級的方法，它能夠在一天內達到類似的目標。

　　為什么要像這樣開一整天的會？

　　會議的主要目的是達到團隊共識和更好的啟動項目。Graham Siener說：初始會議就是讓團隊關注于“知道項目要創建什么并且從哪里開始”。我的經驗是，初始會議可以讓團隊達成一致，從而更好的開始一個項目，快速交付價值，并且不會在錯誤的事情上浪費時間。

　　誰應該參加這個初始會議?

　　初始會議的參會者應該包括做這個工作的核心團隊、發起項目的干系人或者他們的代表。特別地，還要包括業務、產品、開發，也許還有像運維與支持等其它團隊。也有可能包括上下游團隊的代表，他們是這個團隊開發產品的制造商或者是客戶。實踐表示，當會議人數超過10人，會議的效率就會開始下降，那是因為這會產生許多小組討論，而且讓20個人有效地參與是很困難的。如果被邀請者列表變得太長，初始會議的引導者或者項目發起人就可以要求團隊參與度不高的受邀者，讓可以代表他觀點的其他參與者參加這個會議。有時候，大規模的初始會議是不可避免的，其代價就是降低每個參會者的參與度并有可能降低共識度。

　　項目發起人或干系人應該參加，或者應該派代表參加，代表是可以代表他們的觀點并且是給予授權的。如果發起人沒有時間參加這個重要的會議，但又想對項目的決定施加重要的影響或控制，那么這就發出一個信號，這個團隊并沒有獲得對現在和將來所需要的和應有的支持與關注。

　　獲得一位有經驗的團體引導師是重要的，他可以公平地主持會議。對引導師而言，擁有高效的主持能力是至關重要的。他們負責高效地按照議程主持會議，保證團隊進行有效的溝通，理解團隊應該在哪些地方深入討論片刻，并且知道哪些討論占用了太長的時間，應該暫停，并在之后用小組討論的方式得出結論。

　　初始會議應該安排在什么時間？

　　理想情況下，在新的項目開始即將之前，或者對于已存在的長期項目，即將開始一個新的主要工作之前，應該啟動初始會議。如果一個團隊有相當數量的人加入或者離開、或者在方向上有很大的變化，那么重新主持一個初始會議可以幫助團隊達成共識。

　　初始會議應該怎樣主持？

　　會議引導師應該要求參與者全身心的投入，除了休息時間，不允許打開電腦或者接電話從而分心。引入以下規則：“如果你待在這里，你就全心全意的待著。”可以極大地提高會議的有效性。

　　理想情況下，初始會議應該在一個大的會議室進行，有白板和大的白板紙。推薦使用多種顏色的馬克筆、各種顏色的索引卡，膠帶和一些像零食或糖果形狀的可以用來投票的東西。會議中間應該經常休息，每小時休息五到十分鐘。

　　現場與遠程參與者

　　相比遠程參與者，現場參與者的好處如何強調都不為過。遠程參與者更容易受到干擾，從而影響溝通的忠誠度。我以前曾看到過初始會議有幾個遠程參與者的情況，相對于現場初始會議來說，我覺得遠程的初始會議參與度不夠，團隊從我的參與中所獲得的好處則更少。有時候，由于受到現實情況的限制，遠程參與的方式確實無法避免。在這種情況下，請嘗試用最好的遠程在線技術，例如高品質的麥克風和獨立的攝像機。用筆記本自帶的低音質的麥克風和攝像頭容易讓參與者受到郵件和瀏覽網頁的干擾。

　　典型的初始會議議程

　　介紹-保持介紹簡短，因為你要花幾乎一天的時間和團隊在一起，并且你們會通過一天的會議彼此很好地認識。讓引導師提醒每位參與者簡單的介紹幾個關鍵信息會非常有幫助，例如他是誰、為什么在這里等等。

　　愿景和目標 – 項目發起人和Product Owner應該闡明簡潔的項目長期愿景和接下來幾個月的近期目標。對于愿景和目標的討論需要給團隊安排一定的時間。

　　非目標 – 和目標一樣重要，明確的說明什么不是我們的短期目標非常重要。清晰的說明非目標，是我們限定當前工作范圍的一種方式，這樣給了團隊快速發布價值的許可，暫時不考慮那些今后想要、但不是現在必須要有的東西。要確保為小組討論非目標預留時間。

　　風險 –房間里的每一個人都要用索引卡片識別項目的主要風險。讓每個人針對每一個風險寫一張索引卡片，需要多少張風險卡片都沒問題。引導師應該對風險分類，把相關的風險卡片放到一個類別里疊成一堆。隨后把風險讀出來，并且給參與者機會，讓他們解釋在卡片中寫下的風險。這還不是對每一個風險進行小組討論的時機，只是試圖理解可能有哪些風險存在。然后，引導師指示每一個人用糖果或其他投票道具對風險投票，每個人三票，找出你認為對于達成項目目標風險最高的類別。你可以對某一個風險類別投出所有的三票，也可以給三個風險類別分別投票。投票結束之后，我們應該從投票數最多的風險分類開始討論。將每個分類的風險的投票得分記在白板上，或者是一張圖片上。團隊在當天結束之前應該對其重新投票，看看有沒有什么變化。通常情況下是有變化的。

　　角色/情景人物 – 引導師應該進行一個小組練習，用來識別與項目有關的角色 或情景人物。我曾見到過多種不同的識別方式，既可以通過Product Owner簡單的陳述來選出角色與人物，也可以讓大家一起進行頭腦風暴討論以得出各種不同的角色和情景人物。關鍵的目標就是讓團隊的每一個人理解用戶都是誰。

　　活動/工作流程–針對項目短期目標范圍內的每一個用戶角色或情景人物，引導師應該與討論組一起定義每個角色或情景人物的活動與工作流程。引導師應該針對討論組的不同情況選擇一種合適的方法。可以使用簡單的方式，例如讓Product Owner定義關鍵的活動，然后允許組內討論，也可以是像游戲一樣更有創意的方法。用戶與系統如何交互的高層次的描述形成了項目功能的基礎，通常在之后可以直接分解為用戶故事。例如“學生Bobby在書店的目錄里面查找一本書，把找到的條目放到他的購物車中，并且完成支付。”就是一個高層次的工作流程的例子。

　　用戶故事 – 如果有時間，可以把活動和工作流程分解到更小的、具體可操作的用戶故事。不要擔心寫的太過具體化，Product Owner可以在事后提煉這些語言和細節。有時候在初始會議中并沒有時間做這個活動，所以估算和排序必須在高層次的活動與工作流程的粒度上進行。這樣也是可以的，因為這是Product Owner的工作，和開發團隊一起工作，引導他們遵循初始會議的流程，確保盡快地寫出用戶故事。

　　估算 – 對于非常重要的用戶故事，需要與會的開發人員快速地給出粗略的估算。如果你的估算是在用戶故事的層面，可以試圖使用團隊在開發階段使用的故事點系統。如果你的估算是處于史詩、活動或工作流程級別的，可以嘗試使用幾個開發人員周的粗略估算方式。Martin Fowler的 Thrown Estimate 技巧非常有效，可以快速地得到粗略估算。如果你有大量的條目需要估算，我的同事Evan Willey建議使用Affinity Estimating方法。重要的是，客戶端發起人和Product Owner可以從負責實現的團隊那里直接得到估算。

　　優先級 – 讓Product Owner把用戶故事按照優先順序排列，并且允許小組討論和驗證。Product Owner應該能夠根據業務價值來判斷團隊工作的優先級。這些功能在當前階段是“必須的”，還只是“可有可無”？可以根據團隊的大小，看看這個基于故事點的估算是否可以轉換成項目周數。在我參加的幾乎所有的初始會議中，估算和優先級幾乎都預示著團隊必須減少在幾個月內發布的內容。現在就是一個很好的時機，與項目發起人和Product Owner討論一些取舍，因為他們很可能是首次從負責交付項目的團隊那里得到半精確的估算。

　　風險 – 重復之前的風險討論環節，看看風險是否發生了變化。

　　下一步 –對接下來幾天或幾周應該做些什么進行小組討論。這是為了讓團隊的每個成員達成一致或者告訴每一個人，接下來團隊要使用的開發與簽入的流程。通常情況下，引導師和Product Owner會把白板的內容拍下來、收集活動中使用的索引卡片、捕獲行動項，并對誰應該發出一篇總結達成統一意見。我偶爾看到團隊把初始會議產生的那些白板紙、索引卡片和白板的圖片放到團隊的工作區域。隨著時間的流逝，這些內容就變得過時，價值也開始降低。

　　回顧 – 用敏捷回顧會議對初始會議進行討論，哪些做得好，哪些東西人們有問題或者有困惑，哪些做得不好，以及對下次會議有什么好的主意等等。

　　放松 –大家在房間里已經待了一整天，每個人都已經非常疲憊。當天的工作結束時間或許已經快到了，最好讓團隊在辦公室以外，例如選擇有利于社交的某個集合地，做一些放松娛樂的活動。通常情況下，那些不能參加初始會議的那些人想知道會議的結論并希望與團隊溝通，所以邀請那不能參加初始會議的人也是個不錯的主意。讓這個活動保持隨意是比較重要的，因為某些團隊成員需要時間放松減壓。

　　持續的達成一致

　　初始會議在某一點上及時地達成一致是非常好的，但為了確保持續的達成一致，在項目中也應該使用其他類型的循環反饋回路。有效的反饋回路方式包括每日站立會議，每周的迭代計劃會議，每周與項目發起人的會議，每周或每兩周的回顧會議，以及項目功能的持續發布。在幾個月或者重要的里程碑之后，我建議啟動另一個初始會議。因為達成一致的團隊才是一個有效的團隊。

　　Cloud Foundry項目的初始會議

　　我曾在 Pivotal公司的Cloud Foundry 團隊中工作過2年，我相信我們工作的方式給我們帶來了高效的生產力，擁有優秀的功能團隊，成員們也在工作中獲得了樂趣。每一個Cloud Foundry的子項目在啟動時都會進行初始會議，包括一些最有創意的功能項目，例如 Loggregator。Loggregator是從所有的應用中直接添加一些聚合的日志給用戶，并且從遠程終結點的系統日志中排出。在初始會議中，我們明確地從團隊中得到半精確的估算，我們確保功能范圍只限于流日志，并不擴展到日志的持久化和搜索功能。用Golang重寫Cloud Foundry 命令行接口是我們得益于初始會議的另一個項目。在Inception會議中，團隊達成一致，我們將從Ruby版本的命令行接口（CLI）開始再考慮改進用戶體驗，從而幫助我們減少了重寫的范圍，并有了更好的用戶體驗。

　　在我以前很多的軟件開發經驗中，都是使用更傳統的瀑布式流程，有大規模的提前設計和文檔編寫，大規模的團隊，以及持續一年或更久的長期項目。我再也不想回到那樣的工作方式上了。自從Pivotal 實驗室創建以來，我們就用務實的現實項目和持續的改進， Pivotal公司現在使用的方法是基于有25年歷史的 極限編程 和敏捷原則。這個流程保證我們達成共識，讓核心團隊與外部發起人及干系人對項目有共同的理解。在你下一次開始新的項目和方案的時候，不妨試著啟動一個初始會議或類似的¹會議吧。

　　¹ 對于這個方法更多更全面的討論，我的同事Andrew Clay Shafter推薦閱讀Diana Larsen和Ainsley Nies寫的Liftoff: Launching Agile Teams & Projects 一書。