敏捷軟件開發實踐-Sprint Setup Meeting

介紹：

對于一個迭代周期Sprint來說，最先開始的活動并且也是最重要的活動之一就是Sprint Setup Meeting. 在這個會議上，我們主要會去探討一些這個Sprint我們需要完成哪些story，并且這些story的具體需求是什么。其實，我們公司走的是離岸開發模式，這種模式下，我們由于和我們的客戶有個時差（9小時） ，所以很難大家坐在一起然后和標準的Sprint Setup Meeting一樣開始plan. 在這種模式下，我們有2種方式來實現。

實現方式：

一種實現方式是，我們offshore團隊每次外派一個人出差，然后這個人在美國負責和美國團隊一起開展正規的Sprint Setup Meeting,然后這個人負責記錄好所有的meeting minutes,然后把結果反饋給中國這邊的團隊，這是典型的“推”模型，也就是onshore吧Setup Meeting的結果推給offshore團隊，我去年有半年時間在美國，當時我們運行的模式就是這種，優點是我直接和客戶打交道，我可以拿到需求的第一手資料，從而更加精確的明白他們到底需要什么，但是缺點就是作為 onsite coordinator，特別累，因為他必須開2次會議，而且一次是要聽明白全部，第二次是要吧這些內容原封不動的“復制”給offshore團隊，所以需要coordinator本身有一定的技術水準，他能時刻抓住事物本質，還要有好的溝通和理解能力，還要有很好的精力。（附上右1 我去年出差的照片）

另外一種實現方式是：

我們每個Sprint開始的前一天，onshore會吧這個sprint的要完成的story預先定義在Jira上，如下圖：

然后我們團隊各模塊負責人會抽時間逐個review一下，并且提出一些困擾的問題，然后第二天，我們只用1小時的時間來和onshore美國團隊開展這個Sprint Setup Meeting, 我一般會主持offshore這邊的會議，然后我們快速的review 每個story,然后就著我們的問題和onshore直接討論并且figure out，如果不能就會記錄下來并且由專門的郵件保持跟進。

總結：

在這個Meeting開完之后，team里面每個成員應該對這個sprint我們要做的story有一個宏觀的big picture. 這對于了解項目組的進度，宏觀的把握，以及以后萬一team有人請假而去接管任務，都是有幫助的。