衝刺期最後1天不排工作的3項好處

在Scrum敏捷開發專案中，每個衝刺（Sprint）的最後一天是不排定工作的，這一天主要會用來開兩個重要的會議，分別為：衝刺審查會議（Sprint Review Meeting）以及衝刺回顧會議（Spring Retrospective Meeting）。

不過，因為這一天也是專案衝刺中的一天，在正式進入會議之前，通常還是會按照慣例，先開15分鐘的站立會議，把最新的工作狀況更新上去。以先前我們的基金系統開發專案為例，請你看到圖1和圖2，這是到了衝刺最後一天時，最新的任務板和燃盡圖。

圖1 任務板局部[衝刺1最後1天早上]

圖2 燃盡圖[衝刺1最後1天早上]


從任務板上可以非常清楚看到，前一天的工作進度非常不理想，系統分析師：卡爾（Karl）和程式設計師：克萊兒（Clair）並未完成原先預定該完成的工作任務。Scrum教練詢問之下才知道，前一天卡爾（Karl）和克萊兒（Clair）兩人被臨時派去支援一項緊急任務。所以，卡爾（Karl）根本沒進度，而克萊兒（Clair）則只完成了一小部分的任務。最後，我們額外列出了任務板中，尚未開始的任務、以及進展一半還未完全完成的任務，如圖3。

圖3 任務板局部[未開始與進展中]
衝刺審查會議和衝刺回顧會議
每個衝刺的最後一天會先執行衝刺審查會議（Sprint Review Meeting），隨後執行衝刺回顧會議（Spring Retrospective Meeting）。衝刺審查會議主要用來展示並了解該衝刺的待辦項目達成狀況。

表面上，衝刺審查會議的主要內容，在展示系統目前的運作狀況。但是，我個人則認為，這樣的實機展示底下，其實會帶來下列三項更為重要的益處：

● 宣洩壓力：其實，Scrum的衝刺會給開發團隊帶來很大的壓力，需要定期宣洩壓力。我個人覺得，這種定期展示，可以有效宣洩壓力。正好比，醜媳婦早晚得見公婆，越想越擔心，倒不如定期給公婆見一見，這樣壓力就宣洩掉了。

● 凝聚共識：可以凝聚兩方面的共識：其一是對產品的共識，透過具體展示，Scrum團隊每一個人都可以看到產品的現況是好還是壞。另外，還可以建立起Scrum團隊生死與共的革命共識，因為無論產品目前的現況如何，都是Scrum團隊這一個衝刺期間的努力成果。產品如果好，Scrum團隊可以共享榮譽；產品如果糟糕，Scrum團隊也要共同承擔慘狀。

● 具體回饋：這好比網路上的鄉民喜歡說「沒圖沒證據」一樣，沒有看到具體展示的產品，其實真的很難激發出具體的回饋。因此，透過衝刺回顧會議中的產品展示，可以讓非開發團隊（Team）以外的人士，諸如：產品負責人（product owner）以及其他對產品有興趣的與會人士，有具體的產品可以觀看、使用、感受，才能夠激發出具體的回饋。

相較之下，前述的衝刺審查會議，其討論的主題鎖定在「產品」上頭。而此處的衝刺回顧會議，其討論的主題則聚焦在團隊的「開發程序」上頭，主要用來討論並調整下一期衝刺的開發程序。

這一系列討論並沒有打算要模擬整個專案的進行，所以也就沒有繼續進行下一個衝刺了。更何況，我最主要的目的是想要透過一個小小的專案，讓你看到其中一種的Scrum專案的簡易作法，試圖引發出你也想來建一個Scrum專案的念頭。

重新複習一下，這系列文章一開始提到的三四三口訣，這是我自己慣用來描述Scrum敏捷開發的核心元素，包括了三種角色，四個會議，以及三項產出。這三種角色包括了：

● 產品負責人（product owner）：其實，產品負責人這個角色有點像是客戶代表。他會站在比較接近客戶的立場，去設定產品待辦項目的優先順序，以及為團隊說明客戶的需求。

● Scrum教練（Scrum master）：顧名思義，Scrum教練必須熟知整個
Scrum敏捷開發，以便能夠協助產品負責人和團隊的運作。

● 團隊（Team）：就是一般的開發團隊，通常是跨職能的組成，也就是團
隊成員混合著架構師、分析師、設計師、程序員、測試員等等。

而四個會議分別是：

● 衝刺計畫會議（Sprint Planning Meeting）：每個衝刺期間的一開始必須先舉行衝刺計畫會議，主要用來決定該衝刺期間的待辦項目，以及團隊的衝刺任務。

● 每日站立會議（Daily Standup Meeting）：衝刺期間的每一天早上，都要執行15分鐘的站立會議，主要用來了解團隊的工作執行狀況。

● 衝刺審查會議（Sprint Review Meeting）：每個衝刺的最後一天會先執行衝刺審查會議，隨後執行衝刺回顧會議。在衝刺審查會議中，主要用來展示並了解該衝刺的待辦項目達成狀況。
而最後產出的三項成果是：

● 產品待辦清單（product backlog）：其實，產品待辦清單的概念很簡單，它主要包含了一般常見的功能性需求和非功能性需求；不過，比較特別的是，它還包含了技術團隊提出的需求，而不只是照顧到客戶的需求而已。也因此，Scrum敏捷開發特別採用了「產品待辦清單」（product backlog）的字眼，用來跟傳統只照顧客戶的系統需求，做字面上的分野。

● 衝刺待辦清單（sprint backlog）：衝刺待辦清單中的待辦項目，其實是產品待辦清單的子集。在每一次的衝刺規劃會議中，才會開會決定要處理哪些待辦項目。

● 燃盡圖（burndown chart）：簡單來說，我們可以繪製燃盡圖，來呈現一個時間區段中，剩餘的工作量。所以，有些文章或書籍中，也將「Burndown Chart」中譯為「剩餘工作圖」或者是「剩餘時間圖」，原因正是如此。

當然，關於Scrum敏捷開發，除了我提到的三種角色、四個會議、三項產出外，實務上當然還發展出許許多多小巧實用的技術。不過，還是建議你，別想著要學完整了，才動手去做。趕緊建一個屬於你自己的Scrum專案，邊做邊學、邊進行邊審查與回顧，這才是Scrum敏捷開發的核心精神呢！