[SCRUM] Scrum 是什麼（2）：Scrum 的內涵－Foxbrush

From: http://teddy-chen-tw.blogspot.tw/2011/12/scrum-2.html

===============================================

Scrum 是什麼第一集提到鄉民們可將 Scrum 視為一種敏捷專案管理框架，而 Scrum 與傳統專案管理最大的差異之一，就是 Scrum 擁有雙重回饋機制。這一集要談一下 Scrum 的內涵。

Scrum 的內涵可以透過兩張圖來說明：

靜態圖：說明 Scrum 三個主要元素角色（roles），活動（activities）與產出物（artifacts）的意義。
動態圖：說明上述三個元素之間彼此的互動關係。

Scrum 靜態圖

Scrum 動態圖

以上這兩張圖是老師傅手工打造 Teddy 精心繪製的，請慢慢享用。首先看到 Scrum 靜態圖：

Role：Scrum 的角色可以分成兩大類，第一類叫做主要角色（core role），包含 Product Owner，Scrum Master 與 Team（Developer）。第二類叫做輔助角色（ancillary role），包含 stakeholder 與 manager。廣義的來說，和軟體開發專案有關，但是卻沒有實際參與專案開發活動的人，都可以稱之為 stakeholder（利益相關者）。所以鄉民們可以把輔助角色都稱為 stakeholder。在這張圖中，把輔助角色區分為 stakeholder（customer, vendor）這些公司以外的人以及 manager（專案經理或是老闆等）公司內部的人，不過鄉民們可以不用理會（迷之音：那幹麼把圖畫成這樣？！）。主要角色的責任為：

Product Owner（PO）：定義產品需求，負責產品成敗。Product Owner 顧名思義就是『產品擁有者』，有些公司把 PO 稱之為『Product Manager』，是一樣的意思。PO 在 Scrum 專案中算是『客戶代表人』，要負責寫出產品的需求並決定需求的施工順序（以 story 的形式把產品需求寫出來），並且當 Developer 對於產品需求不清楚的時候，要負責回答問題與釐清需求。如果這個開發到最後不幸產品失敗了（可能因為客戶不喜歡），那麼 PO 要有種有擔當的負起全責，不可以把失敗的責任推給其他人。
Scrum Master（SM）：協助開發團隊依循 Scrum 的精神來開發軟體，確定 Scrum 所規範的幾個活動都有定時且正確的進行。協助團隊改善軟體開發流程，排除任何阻礙開發活動的事件（例如，不必要的會議與來自老闆突發的干擾）。
Developer：負責開發軟體。Scrum 強調團隊成員的組成應該是一個所謂的 cross-functional team，就是說團隊要包含所有能夠完成專案的人才，包含從 UI 設計，程式開發到資料庫操作等等。而且這些人才最好能夠擁有多種技能，例如設計 UI 的人也能夠寫點程式，寫程式的人也能夠操作資料庫或是做 UI 端的程式設計等等。

Activity：Scrum 的活動包含了：

Sprint planning meeting：在每個 sprint 開發活動的第一天，團隊要舉辦此會議，主要用意有兩點：（1）挑選這個 sprint 所要開發的需求（stories），（2）逐一將每一個 stories 細分為若干個 task（施工項目），並且估算完成每一個 task 所需的時間（以小時計算）。PO，SM 與 Developer 都需要參與這個會議，在此過程中，強調 PO 與 Developer 之間的對話，藉由對話讓需求變得越來越清楚，使得 Developer 開始施工之後比較清楚『到底要做什麼』。此會議結束會產生一份叫做『Spring Backlog』的東東，基本上 Spring Backlog 就是這個 sprint 所以施工的需求（以 story 的方式撰寫）。
Daily Scrum：每日站立會議，團隊每天（通常是早上）『站著』開一個約 15 分鐘左右的會議，團隊成員要報告三件事情（1）昨天做了那些事，（2）今天準備做了那些事，（3）有沒有遇到任何問題。
Sprint：為期 2-4 週的開發活動，Teddy 的經驗是採用 2 週長度的 sprint。當一個 Scrum 團隊選擇 sprint 長度（例如 2 週）且實施過一段時間穩定下來之後，最好不要任意改變 sprint 長度（例如改成 3 週或四週），以避免打亂開發的步調。
Sprint demo (reivew ) meeting：當 sprint 結束的那一天會舉辦此會議，參加對象至少包含 PO，SM，Developer 並可邀請輔助角色來參加。此會議主要是要展示團隊在此 sprint 中所完成的每一個 story，並且讓 PO 確認這些 story 有做到他心目中所想要的程度。PO 透過實際的軟體展示，可能會引發新的想法，那麼這些新的想法就可能變成新的需求，移到後續的 sprint 中實做（PO 要決定需求的施工順序）。
Sprint retrospective meeting：參加對象為 SM 與 Developer，如果 PO 有空也可參加。此會議主要目的為檢討與改善『軟體開發流程』，在會議中開發人員列舉出在此 sprint 中有那些開發流程是好的，要繼續維持，有那些是不好的或是沒做到的，應該要改善的項目。最後團隊討論出改善行動方案（action plan），在下一個 sprint （或是連續若干個 sprints）中實施此改善項目。改善項目不要太多，因為假設一個 sprint 才兩週，不太可能改善一大堆問題，以 Teddy 的經驗通常改善行動方案只列出一條，例如，30% 的 tasks 都要採用 pair programming 的方式施工，或是 build 一次軟體的時間要縮短為 10 分鐘等等。
Product backlog refinement meeting：這個活動 Teddy 在一般介紹 Scrum 的書籍中比較少看到（應該是書看的太少或是不專心看...XD），第一次聽到這個名詞是 Teddy 去上 Certified ScrumMaster 課程的時候。這個會議主要的目的是讓 PO 與開發團隊每個 sprint 抽出 5%-10% 的時間來檢視 product backlog 裡面的所有需求，然後挑選一些下一個 sprint 準備要施工的 stories。

Artifact：Scrum 的產出物（文件）包含了：

Vision：遠景，老闆或是專案資助人有一個夢，然後團隊要把這個夢變成需求並且把實際的東西（軟體）給生出來。
Story：Scrum 把需求以 story 的形式寫出來，如果有學過 use case （使用案例）的人，可以把一個 story 想像成一個 use case 中的一條執行路徑或是一個劇情（scenario）。一個典型的 story 長成這樣：As a user, I can do XXX so that yyy. 例如，As a user, I can install the software so that I can use it later.
Product backlog：所有關於此專案或是產品的 stories 就稱為 product backlog，放在 product backlog 裡面的 stories 要經過『排序』一下，比較重要，比較優先要施工的 stories 放在前面。鄉民們可以直接用 excel 來紀錄 product backlog，當然也可以用支援 Scrum 的軟體系統（例如免費的 ezScrum）甚至是一般的文字檔來管理 product backlog。
Sprint backlog：Sprint backlog 就是某一個 sprint 準備施工的 stories（可以想成是 product backlog 的子集合），同樣的 sprint backlog 裡面的 stories 也是要排序過的，比較重要的先開工。
Task：Task 是完成 Story 的施工項目，在 sprint planning meeting 時，團隊會將每一個 story 再細分若干個 task。典型的 task 有設計使用者介面，coding，寫自動化單元測試程式，設計資料庫表格格式，寫 DAO（data access object），寫自動化功能測試，寫使用手冊等等。
Burndown chart：嚴格講起來 brundown chart 可以分成三種，從大到小分別是 release burndown chart, story burndown chart 以及 task burndown chart，在這邊先解釋 task burndown chart 。在 sprint planning meeting 結束之後，先把所有 stories 的 tasks 施工的小時數加總起來，假設有 250 小時。然後第每一天 daily Scrum 會議之後，Developer 會報告說有一些 tasks 已經被做完了，假設第二天有 15 小時的工作已經完成了，那麼Scrum 團隊就可以畫一張圖，把 250 小時減掉每天完成的工作時數，剩下來的就是尚未完成的工作。所以只要每天看這張 burndown chart，團隊就可以知道進度是否正常（理論上在 sprint 最後一天剩下未完成的工作時間應該是 0）。以下是一張 burndown chart 的例子：

Running software：在 sprint 結束時，團隊要能夠產出一份 potentially shippable product increment，也就是說這個 sprint 所增加的軟體功能如果客戶馬上就要的話，要可以交付給客戶。所以要確定團隊隨時間可以產生一份 running software（自己開發的軟體要隨時都處於可執行的健康狀態）。
Sprint info page：後面這三項文件不算是 Scrum 正式規範的文件，是 Teddy 從 Scrum and XP from the Trenches 這本書學來的，不過因為 Teddy 自己實際用了三年多覺的還滿有用的，所以一併介紹給鄉民們。當 sprint planning meeting 開完之後，Scrum Master 會寫一份 sprint info page 文件，這份文件包含了 sprint goal（這個 sprint 的目標）還有列出這個 sprint 所要施工的 stories，sprint 開始與結束時間，以及團隊成員。然後 Scrum Master 將這份文件寄給 Scrum Team 以及其他有興趣的輔助角色人員，讓他們知道一個新的 sprint 已經開始了。
Sprint demo agenda：Sprint 結束前一天（sprint demo meeting 前一天中午 12:00 之前）Scrum master 要寫出 sprint demo 的議程表，並將此文件寄給 Scrum Team 與其他有興趣的輔助角色人員。此議程表包含所有要 demo 的項目，以及每一個 demo 項目要花多少時間，由誰負責 demo。所以當 Developer 收到該議程表時，就可以準備明天要 demo 的資料。
Sprint summary report：當開完 sprint retrospective meeting 之後，Scrum Master 會準備此文件，文件內容包含對於本次 sprint 所完成功能的簡述，完成多少個 story points，團隊成員在 sprint retrospective meeting 中所列出好的以及有待改善的項目（Teddy 最多只各列三點），以及改善行動計畫。同樣的，將此文件寄給Scrum Team 以及其他有興趣的輔助角色人員，讓他們知道這個 sprint 已經正式結束了。

***

參照上面對於 Scrum 每個元素的解釋， Scrum 動態圖就應該很容易了解了。其他需要補充的地方就等下一集吧。