每天用15分鐘掌握團隊進度

在衝刺期間，除了第一天不需要舉行「每日站立會議」（Daily Standup Meeting）外，其餘時候的早上，Scrum教練和開發團隊都要「站立」進行15分鐘的每日會議，主要用來了解團隊的工作執行狀況。

對了，每日站立會議又稱為「每日Scrum會議」（Daily Scrum Meeting），不過每日站立會議稱呼起來比較傳神，所以選用「每日站立會議」的稱呼。

在每日站立會議中，每個團隊成員都必須回答三個問題；在下列問題中的「我」，指的是回答問題的團隊成員本身。這三個重要的問題，如下列所述：

● 從上次的每日站立會議之後，一直到現在，我做了什麼？

● 在開完這次的每日站立會議之後，一直到下次的每日站立會議舉行之前，我打算做些什麼？

● 有沒有發生什麼事情，阻礙了我的工作效率？

其實，Scrum敏捷開發是個講求資訊透明的方法，非常符合現今民主潮流的思維。在傳統的專案管理方法中，專案的整體狀況掌握在專案經理手中，而團隊的工作狀態則掌握在團隊成員手中，並不鼓勵將資訊透明化。

然而，Scrum敏捷開發的四個會議，包括：我們之前談到的衝刺規畫會議，以及此處的每日站立會議；還有我們在後面會談到，在整個衝刺期間結尾時，必須舉行的衝刺審查會議和衝刺回顧會議。Scrum敏捷開發的這四個重要會議，在在都講求資訊透明化。

任務板
在每日站立會議中，團隊成員除了透過上述三個問題，向其他人分享自己的工作狀況外，還可以使用「任務板」（Task Board）具體呈現每項任務的執行狀態。

請你看到圖1，這是任務板的示意圖，由左至右主要分為四個欄位。除了第一欄標示待辦項目的名稱外，其餘右側的三欄分別標示出任務執行狀態，依序為：未開始（To Do）、進展中（In Progress）、已完成（Done）。

圖1 任務板[衝刺開始]

在衝刺期間第2天的早上，團隊在舉行每日站立會議時，任務板上的任務狀態可能如圖1的樣子，所有任務都還沒有開始執行。

但是，經過第2天一整天的工作之後，有些任務已經做完了，因此團隊成員修改了任務狀態。因此，到了第3天的每日站立會議時，可能所有團隊成員看到的是像圖2的樣子，整體的衝刺任務狀態已經有所改變了，表示團隊正在全力衝刺中。

圖2 任務板[衝刺期間]

至於，任務板要怎麼做？許多Scrum團隊喜歡將任務寫在大大小小、各種顏色的便利貼上頭，然後固定貼在要舉辦每日站立會議的牆上、鐵櫃背後、白板上、大張的白報紙上等等，都十分常見。總之，簡潔、便利就好，這樣比較符合Scrum敏捷開發標榜的輕量、敏捷的精神啦！

最後，要提醒你的是，Scrum敏捷開發並沒有規定一定要使用任務板。還記得以前我們曾經提過，Scrum敏捷開發只是一個簡單的框架（Framework），核心元素主要包含：三種角色、四個會議、三項產出。

● 三種角色：Scrum教練、產品負責人和團隊。

● 四個會議：衝刺規畫會議、每日站立會議、衝刺審查會議和衝刺回顧會議。

● 三項產出：產品待辦清單、衝刺待辦清單和燃盡表。任務卡
前面已經說過，實體任務板可以設在大白板、鐵櫃背後、或者直接在牆壁空白處貼一張大的白報紙。然後，就可以在任務板上頭張貼一張張的「任務卡了」。

很多Scrum團隊會去買許多不同顏色、大小的便利貼，當成實體的任務卡，然後用白板筆、彩色筆或粗筆把任務大大、粗粗地寫在上頭。另外，我也建議可以使用巴掌大、約莫80開的兩孔資料卡，當作任務卡，這會比便利貼容易收藏。

此處，我們把任務板上的「任務卡」放大來瞧一瞧，在巴掌大的任務卡上，主要寫上待辦項目序號、負責成員、任務內容、預估工時和實際工時，如圖3所示。

圖3 任務卡

在任務執行結束後，負責成員要把實際的工作時數寫上去，這樣可以協助修正後面衝刺、或者其他專案對於相似任務的估算。工時的估算一直是件不容易的事情，所以我們可以透過一次又一次的估算工時、記錄實際工時、調整估算工時、記錄實際工時…，來學習並修正估算。

模擬每日站立會議
接著，我們來模擬一下衝刺1第二天每日站立會議的進行。

首先，先看到參與人員，這天的每日站立會議只有Scrum教練和其他三位團隊成員參與。因為，兼職的程式設計師：麥克（Michael）這兩天得到客戶公司，去支援另一個專案，所以這天沒進辦公室，也就辦法參與今天的每日站立會議了。

還記得，我們前面有提到，每日站立會議必須回答三個問題。由於，這是衝刺1第一次開每日站立會議，所以團隊成員就省略了兩個問題，只有回答了一個問題：

「在開完這次的每日站立會議之後，一直到下次的每日站立會議舉行之前，我打算做些什麼？」

在團隊成員一個接一個地回答完問題之後，他們動手移動了任務板上頭的任務卡，標示出等一下開會結束之後，他們即將動手做的任務，如圖4所示。

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

在寫這段文章的同時，我的老客戶即時通訊問我關於採用Scrum敏捷開發所需要的軟體工具。

其實，你要是看到前面我們講到使用白報紙、便利貼、彩色筆，或許可以感受到，Scrum敏捷開發並不是一個重度依賴軟體工具的開發方法。

當然，我們不是說軟體工具不重要。而是說，Scrum敏捷開發其實更重視人與人之間實際的溝通和互動，同時還強調使用簡單且隨處可見的實物，來替代複雜且昂貴的軟體工具。執行任務的產出
接著，我們來看團隊成員執行任務的產出情況。請你看到圖5，這是基金系統的使用案例圖局部，僅展示出「增刪改查基金公司基本資料」這個使用案例的情況。從這個局部的使用案例圖，我們可以立即得知銀行行員將啟動「增刪改查基金公司基本資料」使用案例，來協助執行日常的工作業務。

圖5 增刪改查基金基本資料[使用案例圖局部]

至於，增刪改查基金公司基本資料的使用案例敘述，我們則拆成新增、刪除、修改、查詢四個部份，並且分別放置於表1、表2、表3、表4內。此外，在執行「增刪改查基金公司基本資料」使用案例期間，會涉及到兩個參考畫面，如圖6、圖7所示。

圖6 增刪改查基金公司基本資料畫面

圖7 刪除時彈跳出來的確認對話框

由於，實體類別對應真實世界中的領域概念，所以我們很容易就可以定義出基金公司實體類別的屬性，如圖8所示。眼尖的你可能已經發現，基金公司實體類別中的屬性幾乎都是對應前頭的使用案例敘述與參考畫面。

圖8 基金公司實體類別[類別圖局部]

最後，請你看到表5的基金公司資料表規格，比較特別的是，資料表的最後多了兩個欄位用來記錄資料的異動人員和時間。

BCE樣式
在基金系統中，我們直接採用Ivar Jacobson大師的BCE樣式（Boundary-Control-Entity Patterns）的概念，將系統內部的所有類別，分為：邊界類別（boundary class）、控制類別（control class）和實體類別（entity class）這三種。

此外，BCE類別有獨特的圓形系列圖示，當然也可以使用傳統的矩形圖示，再配上雙角箭號標示出BCE類別。在遵守BCE樣式的規約下，BCE物件之間的互動情況可以有3種：

● 邊界物件：畫面或網頁是最常見的邊界物件，系統外部的參與者物件僅能夠跟邊界物件互動。

● 控制物件：我們特別用UCO字樣，標示出掌控整個使用案例流程的控制物件。另外，需要跟關聯式資料庫互動時，也會透過另一種常見的DAO控制物件，來存取資料庫當中的資料表。

● 實體物件：對應「領域概念」，要盡量保持單純。

再者，我們還把BCE類別，分別放置在對應的套件中，並且繪製了基金系統的套件圖。

由於，我們希望可以限制實體類別僅能夠被匯入到控制套件中，而不會被一路往外匯入到邊界套件中，所以在控制套件與實體套件之間的關係上，特別採用「套件存取」（Package Access）關係，而非一般常見的「套件匯入」（Package Import）關係。