項目初始會議 – 如何在一次會議中達成共識

項目初始會議 – 如何在一次會議中達成共識

　　英文原文： 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 一書。