衝刺計畫會議上半場，先找出交付項目

在正式進入第一個衝刺期前，要先決定了一個衝刺期的長度（Sprint Length），以這系列文章的銀行基金系統範例而言，我決定衝刺期是2周。而且，打算先執行第一個衝刺之後，才在衝刺期最後一天的「衝刺回顧會議」（Sprint Retrospective Meeting）中，來討論是否要調整衝刺期的長度。

在物件導向技術中，建議採用反覆式的開發方式，而不是過去的瀑布式開發方式。簡單來說，所謂的反覆式的開發方式是指，在一小段的反覆期中，執行了分析、設計、實作、測試等等的開發步驟，以便迅速地修訂錯誤。

而在Scrum敏捷開發中，同樣採用反覆式的開發方式。不過，在物件導向技術中，稱為這樣的一小段時期為一個「反覆」（Iteration, 也有另一個常見的譯詞為「循環」）。到了Scrum敏捷開發中，則稱為一個「衝刺」（Sprint, Sprint Iteration）。至於，一個衝刺期間要設定多長時間，並沒有一定，常見是2～6周。

衝刺1
在每一個衝刺期間，除了團隊需要實際執行分內的任務外，Scrum還定義了四個重要的會議，分別簡述如下：

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

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

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

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

至於，在開始進入衝刺1之際，必備的重要文件就是在衝刺0時所產出的產品待辦清單表1和表2，由於，我們同時採用了UML技術，所以此處也建議你搭配基金系統的使用案例圖，將產品待辦清單視覺化，如圖1所示。

衝刺1第1天上午
每個衝刺期間的一開始必須先舉行衝刺計畫會議，可以細分為上半場和下半場。在上半場大約4小時的會議中，主要從產品待辦清單挑選出該衝刺期間必須交付的待辦項目。在下半場也是約莫4小時的會議中，將會針對每一個衝刺待辦項目，分解出相關的「任務」（Task）。

接下來的次小節中，我們會先聚焦在上半場的衝刺計畫會議中，一邊學習相關的概念，一邊進行衝刺計畫會議。

Scrum敏捷開發的三重限制
你可能學過，傳統的專案管理概念中，有一個很重要的概念稱為「三重限制」（Triple Constraints），也稱為「專案管理三角」（Project Management Triangle），如圖2所示。

簡單來說，在傳統的專案管理概念中，專案的範圍（scope）通常是固定的，因此決定了專案的成本（cost）和時間（time）。不過，在Scrum敏捷開發的專案中，我們不採用傳統的專案管理三角，而是將專案管理三角倒過來，由專案的成本和時間來決定專案範圍，如圖3所示。

你可能會跟我一樣覺得匪夷所思，怎麼能夠固定成本和時間，而決定出專案的範圍呢？如果這樣的話，系統的功能將大幅減少，因為團隊在固定的時間下，通常只能交付比較重要的功能。這樣真的沒有問題嗎？

有趣的是，知名的Standish Group在2002年的混沌報告（Chaos Report）調查中指出，在軟體專案中，大約只有20%的功能有經常被使用到，完全符合著名的80/20法則，如圖4所示。

也就是說，經由時間的限制條件下，我們可以設定待辦項目的優先順序，讓常用的、重要的使用案例可以優先擠進衝刺期間中。因此，在衝刺計畫會議中，可能會出現兩個比較特別的現象，如下：

● 產品負責人可能會調高某些待辦項目的優先順序，讓這些待辦項目可以早點進入衝刺期間，讓團隊可以優先開發和交付。

● 有些墊底的待辦項目可能永不見天日，因為在時間固定的情況下，恐怕沒有時間可以開發這些待辦項目。找出前20%的待辦項目
還記得在一開始時，我們已經先設定了每一個衝刺期間為2周，因此在時間固定的情況下，團隊必須挑選重要的待辦項目，優先處理。請你看到表3，我們依照優先順序排列了待辦項目，並且先行挑出前20%（大約4個使用案例）的待辦項目往下討論，如表4。

由於，產品負責人必須負責維護產品待辦清單，所以在衝刺計畫會議的上半場，產品負責人最好可以全程參與。產品負責人到場，主要負責下列事項：

● 向團隊解釋產品待辦項目：如果團隊對於某些待辦項目不清楚的話，產品負責人要負責解釋。

● 調整待辦項目的優先順序：在2周的衝刺期間內，團隊只能承諾交付選進衝刺待辦清單內的待辦項目，所以產品負責人如果認為某些待辦項目需要提早交付的話，那就必須調高待辦項目的優先順序，而不是要求團隊增加工作時間，或者延長衝刺期間。

增加產品待辦項目
特別注意的是，我們並不是說只交付20%的待辦項目，只是透過挑選前20%的待辦項目，來聚焦我們要討論的主題。再者，由於團隊還未分解出衝刺任務，以及更細膩地估算工時，所以我們根本也還無法確定衝刺1可以交付多少待辦項目。

此外，在進行衝刺計畫會議的上半場時，團隊也可能需要增加一些待辦項目，還記得我們曾經提到常見的待辦項目來源有四種，如圖5所示。

所以，在我們的基金系統案例中，團隊認為需要增添跟技術需求有關的兩個待辦項目，依序編號為18和19，如表5所示。

再者，由於在衝刺計畫會議的下半場，就要開始分解衝刺任務，以及仔細估算工時，所以此處我們就省略初始估算，僅簡單說明如何展示這兩項新增的待辦項目，如表6所示。

由於，新增的這兩項待辦項目優先順序比較高，所以會把原先挑選出來的四個待辦項目壓到後頭，如表7所示。

如果，繼續套用前述的80/20法則的話，可能得刪掉表7中的最後兩項優先順序比較低的待辦項目。不過，因為目前團隊還沒有仔細估算工時，實在也無法確定2周的衝刺期間可以完成多少個待辦項目。所以，我們還是先保留這六個待辦項目，等接續進行衝刺計畫會議下半場，再來確定衝刺待辦清單吧！