看不見的團隊進度需要圖像化

在衝刺期間，我們通常會建議在一大早就先開每日的15分鐘站立會議。假設，公司是早上9點整準時上班，可以把每日站立會議的時間訂在早上09:15～09:30、09:30～09:45或者是09:45～10:00之譜。關於每日站立會議，我也有一個「三三三」口訣，與你分享之：

三定（三件固定）：固定時段（早上15分鐘）、固定地點、固定問題。其中的「固定問題」，不是指只能問固定的問題，而是說下面的三個問題一定要記得固定問。

三問（三個問題）：簡單來說，就是問，昨天做了什麼？Q2、今天打算做什麼？Q3、昨天進度落後的原因？

三出（三項產出）任務板、任務卡、燃盡圖。其中，任務板和燃盡圖都會把最新的狀況標上去。如果，衝刺期間有新增的任務，都要寫在任務卡上面，並且貼到任務板上。

接下來用衝刺1中間的2個工作天為例，衝刺1第3天和第4天，來模擬每日站立會議中，如何依據任務變動情況，隨時更新任務板和燃盡圖。

模擬每日站立會議[衝刺1第3天]
之前，我們的Scrum團隊已經約定好，固定在早上09:30舉行15分鐘的每日站立會議。

圖1 任務板[衝刺1第3天早上]

一早到公司，喝完咖啡，到了固定開每日站立會議的地方，大夥圍著任務板瞧，一邊動手更新自己的進度，也一邊動眼看別人的進度，如圖1所示。

參與會議的人員，還是跟昨天一樣，Scrum教練、以及三位團隊成員。同時兼另一個專案的程式設計師：麥克今天還是不在辦公室，不過好消息是，明天早上麥克會到場參加每日站立會議。

目前來看，系統工程師彼得的狀況最佳，進度超前。在「安裝並配置硬體及網路線」的任務上頭，非常順利，所以並沒有花掉原先預估的那麼多時間。所以，昨天下午便提早開始執行「安裝並設定系統軟體」的任務了，今天還是預定會繼續做這件工作。

至於，系統分析師卡爾目前已經完成了，「增刪改查基金公司基本資料」的使用案例敘述和類別圖（含資料庫規格）。

不過，所花費的時間，比他預期的時間還多，有點擔心後面其他使用案例的估算時間也有誤差。

此外，由於基金系統有意要採用ASP.NET MVC2的實作技術，但是在BCE樣式上頭，還無法確定該如何對應實作。所以，系統分析師卡爾的循序圖遲遲無法定案，還在持續與程式設計師克萊兒協調當中，因此造成進度無法推進。

最後，卡爾和克萊兒兩人共同決議應該新增一項任務，安排幾個鐘頭來研究ASP.NET MVC2的實作技術，找出共識之後，才能確定循序圖能夠實作，如表1所示。

因此，燃盡圖上頭的工時會調高到143小時，由原先的136.5小時減少了9.5（8+1+0.5）小時，但是增加了24小時，如圖2所示。所以，燃盡圖的曲線沒有下降，反而是往上爬升了，正如圖3所示。

圖2 新增了一項任務

圖3 燃盡圖[衝刺1第3天]

而且，卡爾預定今天下午也會花一些時間來撰寫「更新基金基本資料」使用案例敘述。所以，他移動了任務板上的任務卡，退後了一張「繪製循序圖」的任務卡，前進了一張「撰寫使用案例敘述」的任務卡，而且還新增了一張「研究ASP.NET MVC2如何實作BCE樣式」的任務卡，如圖4所示。

圖4 任務板局部[衝刺1第3天早上]

待辦項目：更新基金基本資料
「更新基金基本資料」這個使用案例，不需要提供圖形介面，它僅是個基金系統對外提供給基金公司伺服器呼叫的Web Services，讓基金公司可以主動更新基金基本資料，提升整體效能。相關的使用案例圖和敘述，分別如圖5和表2所示。

圖5 更新基金基本資料[使用案例圖局部]

在繪製類別圖時，我們會在增加使用案例的同時，一點一點增加更多的類別圖的細節，如圖6所示。在類別圖中，可以在結合關係的兩個結合端旁，標示出個體數目，這就就可以很清楚得知：一家基金公司可以管理一到多檔基金，而任何一檔基金一定僅能由某一家基金公司所管理。

圖6 基金實體類別[類別圖局部]

至於，在關聯式資料庫的資料表設計上，我們也增添了另一個「Fund」（基金）資料表，如表3所示。特別看到基金資料表的「CompanyID」（公司編號）這個欄位，它是個「外鍵」（Foreign Key），對應到前面我們看到過的基金公司資料表的主鍵。

待辦項目：安裝軟硬體環境
由於，系統工程師彼得的工作即將完成，所以我們來看一下基金系統需要用到什麼樣的環境。基於銀行服務不能中斷的需求之下，Scrum團隊主要會為基金系統架設兩個環境，分別為：正式環境和測試環境。

在實際營運的正式環境中，會有兩臺網頁伺服器（Web Server），以及兩臺資料庫伺服器（Database Server）。

其中，兩臺網頁伺服器之間，我們會將它們設置成「負載平衡」（Network Load Balancing, NLB），並設定成網路流量平均分攤於兩臺伺服器上。此外，在負載平衡的架構下，當其中一臺網頁伺服器當掉時，所有的流量會自動導向到正常運作的另一臺網頁伺服器，這樣可以避免服務中斷。

至於，兩臺資料庫伺服器之間，則會設置成「叢集」（Cluster）。雖然，同一時間只有一臺資料庫伺服器會提供服務，另一臺資料庫伺服器處於待命狀態（standby）。但是，一旦提供服務的那一臺資料庫伺服器發生問題時，服務會立即切換到處於待命狀態的另一臺資料庫伺服器，以便繼續提供服務。

再者，資料庫中的資料都會被儲存在「磁碟陣列」（Disk Array）中。所以，無論是兩臺之中的任何一臺資料庫伺服器提供服務，都保證不會出現資料不一致的現象。

另外，我們還會準備一個測試環境，供系統維護人員做為測試程式之用。在程式上線到正式環境之前，我們會需要先在測試環境中進行測試，確定沒有問題之後才會正式上線。

不過，在節省經費的考量下，測試環境中只會準備一臺伺服器，在這臺機器上頭將同時安裝微軟的IIS，以及SQL Server 2008。

模擬每日站立會議[衝刺1第4天]
這一天參與會議的人員，還是只有四個人：Scrum教練、以及三位團隊成員。原本程式設計師麥克，有說今天要來參加每日站立會議，不過因為客戶那邊臨時出了些狀況，所以今天還是沒辦法回辦公室。

系統工程師彼得的狀況依舊良好，進度超前，已經將「安裝軟硬體環境」的相關任務全數執行完畢，所以明天彼得就暫時不用參與每日站立會議了。

圖7 任務板局部[衝刺1第4天早上]

之前一直都還在猛啃IBM紅皮書的程式設計師克萊兒，終於有了不錯的進展，今天已經可以開始動手寫測試程式了。至於，系統分析師卡爾都還是維持早上研究ASP.NET MVC2，下午則動手撰寫使用案例敘述、繪製類別圖以及開資料庫規格，更新以後的任務板如圖7所示。

最後，請你看到燃盡圖圖8。昨天早上還有151小時的剩餘工時，經過昨天一整天的工作後，完成了任務板上標示笑臉的任務，共計34（16+1+16+0.5+0.5）小時，所以剩下117（151-34）小時，如圖8所示。

圖8 燃盡圖[衝刺1第4天]

透過上述衝刺1的第3和第4天兩天的每日站立會議模擬，你可以看到開發工作會隨每個人的進度而隨時異動，在每日站立會議中回報的各項變化，若能即時反應到任務板和燃盡圖上，就可以將看不見的團隊進度圖像化，方便團隊成員一眼就了解目前最新的狀態。

不過，就如同先前提醒過的，Scrum敏捷開發並沒有規定一定要使用任務板，這只是一種方便具體呈現每項任務執行狀態的作法，也是不少Scrum團隊喜歡的作法。
實體任務板可設在大白板、鐵櫃背後、或者直接在牆壁空白處貼一張大的白報紙，就可以在任務板上張貼一張張的任務卡了。

很多Scrum團隊會買許多不同顏色、大小的便利貼，當成實體的任務卡，然後用白板筆、彩色筆或粗筆把任務大大、粗粗地寫在上頭。另外，我也建議可以使用巴掌大、約莫80開的兩孔資料卡，當作任務卡，這會比便利貼容易收藏。總之，簡潔、便利就好，這樣比較符合Scrum敏捷開發標榜的輕量、敏捷的精神啦！