Scrum 是什麼（2）：Scrum 的內涵

December 29 08:52~11:49

泰迪軟體【Scrum敏捷方法實作班】招生中。

***

〈Scrum 是什麼（1）：雙重回饋機制〉提到鄉民們可先簡單將 Scrum 視為一種敏捷專案管理框架（以官方說法，Scrum是一種流程框架），而 Scrum 與傳統專案管理最大的差異之一，就是 Scrum 擁有雙重回饋機制。這一集要談一下 Scrum 的內涵。

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

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

▲Scrum 靜態圖

▲Scrum 動態圖

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

• Role：Scrum 的角色可以分成兩大類，第一類叫做主要角色（core role），包含 Product Owner，ScrumMaster 與 Team（Developer），此三者合稱為Scrum Team。第二類叫做輔助角色（ancillary role），包含 stakeholder（利益相關者） 與 manager。廣義的來說，和軟體開發專案有關，但是卻沒有實際參與專案開發活動的人，都可以稱之為 stakeholder。所以鄉民們可以把輔助角色都稱為 stakeholder。在這張圖中，把輔助角色區分為 stakeholder（customer, vendor）這些公司以外的人以及 manager（專案經理或是老闆等）公司內部的人，不過鄉民們可以不用理會（迷之音：那幹麼把圖畫成這樣？！）。主要角色的責任為：
  • Product Owner（PO，產品負責人）：與開發團隊合作一起定義產品需求，負責產品成敗。Product Owner 顧名思義就是「產品擁有者」，在傳統公司中「Product Manager」算是比較接近PO的角色（但不完全相同）。PO 在 Scrum 專案扮演客戶代表，負責管理產品需求並決定需求的施工順序（產品需求大多以user story 的形式呈現），並且當 Developer 對於產品需求不清楚的時候，要負責回答問題與釐清需求。如果這個開發到最後不幸產品失敗了（可能因為客戶不喜歡），那麼 PO 要 有種 有擔當的負起全責，不可以把失敗的責任推給其他人。 （2017/04/26 revised）
  • Scrum Master（SM，Scrum大師）：協助團隊依循敏捷開發與Scrum 精神來開發軟體，確定 Scrum 所規範的幾個活動都有定時且正確的進行。協助團隊持續改善開發流程，協助排除任何阻礙開發活動的事件（例如，不必要的會議與來自老闆突發的干擾）。
  • Developer（開發人員）：負責開發軟體。Scrum 強調團隊成員的組成應該是一個 跨職能團隊（cross-functional team），團隊中要有能夠完成專案的所有人才，包含 UI/UX 設計、程式開發、資料庫操作以及測試人員等等。而且這些人才最好能夠擁有多技能（multi-skills），例如設計 UI 的人也能夠寫點程式或幫忙測試，寫程式的人也能夠操作資料庫或是做 UI 端的程式設計等等。
• Activity：Scrum 的活動包含了：
  • Sprint planning meeting：在每個 sprint 開發活動的第一天，團隊要舉辦此會議，主要用意有兩點：（1）挑選這個 sprint 所要開發的需求（stories），（2）逐一將每一個 stories 細分為若干個 task（施工項目），並且估算完成每一個 task 所需的時間（以小時計算）。PO，SM 與 Developer 都需要參與這個會議，在此過程中，強調團隊成員之間的對話，藉由對話讓需求變得越來越清楚，使得 Developer 開始施工之後比較清楚「到底要做什麼」以及「該怎麼作」。此會議結束會產生一份叫做「Spring Backlog」的東東，基本上 Spring Backlog 就是這個 sprint 所以施工的需求（以 story 的方式撰寫）。

▲Sprint planning meeting

• Daily Scrum：每日Scrum，是一個重新規畫（replan）會議，讓團隊修正達成sprint目標的方法。會議通常以站立方式進行，在15分鐘之內舉辦完畢。在會議中團隊成員報告三件事情（1）昨天做了什麼以協助團隊達成sprint目標，（2）今天準備做什麼以協助團隊達成sprint目標，（3）有沒有遇到任何阻礙團隊達成sprint目標的事情（2018/07/04修訂）。

▲Daily Scrum

• Sprint：為期 2-4 週的開發活動，Teddy 的經驗是採用 2 週長度的 sprint。當一個 Scrum 團隊選擇 sprint 長度（例如 2 週）且實施過一段時間穩定下來之後，最好不要任意改變 sprint 長度（例如改成 3 週或四週），以避免打亂開發的步調。
• Sprint review meeting：Sprint檢視會議，當 sprint 結束的那一天會舉辦此會議，參加對象至少包含 PO，SM，Developer 並可邀請輔助角色來參加。此會議主要是要展示團隊在此 sprint 中所完成的每一個 story，並且讓 PO 確認這些 story 有做到他心目中所想要的程度。PO 透過實際的軟體展示，可能會引發新的想法，那麼這些新的想法就可能變成新的需求，移到後續的 sprint 中實做（PO 要決定需求的施工順序）。

▲Sprint Review

• Sprint retrospective meeting：Sprint回顧會議，參加對象主要為 SM 與 Developer，如果 PO 有需要也可參加。此會議主要目的為檢討與改善『軟體開發流程』，在會議中開發人員列舉出在此 sprint 中有那些開發流程是好的，要繼續維持，有那些是不好的或是沒做到的，應該要改善的項目。最後團隊討論出改善行動方案（action plan），在下一個 sprint （或是連續若干個 sprints）中實施此改善項目。改善項目不要太多，因為假設一個 sprint 才兩週，不太可能改善一大堆問題，以 Teddy 的經驗通常改善行動方案只列出一條，例如，30% 的 tasks 都要採用 pair programming 的方式施工，或是 build 一次軟體的時間要縮短為 10 分鐘等等。

▲Retrospective

• Product backlog refinement meeting：又稱為Product Backlog Grooming，這個活動主要目的是讓 PO 與開發團隊每個 sprint 抽出 5%-10% 的時間來檢視 product backlog 裡面的項目，然後挑選一些下一個 sprint 準備要施工的 stories。
• Artifact：Scrum 的產出物（文件）包含了：
  • Vision：遠景，老闆或是專案資助人有一個夢，然後團隊要把這個夢變成需求並且把實際的東西（軟體）給生出來。
  • User story：Scrum沒有規定需求要用何種方式撰寫，但許多Scrum團隊會將需求以user story（用戶故事） 表達，如果有學過 use case （使用案例）的人，可以把一個 user story 想像成一個 use case 中的一條執行路徑或是一個劇情（scenario）。一個典型的 user story 長成這樣：As a user, I can do [什麼功能] so that [獲得什麼好處]. 例如，As a user, I can install the software so that I can use it later.
  • Product backlog：所有關於此專案或是產品的代辦事項就稱為 product backlog，放在 product backlog 裡面的東西稱為product backlog item（PBI），需要依據優先順樹經過排序，比較重要，比較優先要施工的 PBI放在前面。鄉民們可以直接用 excel 來紀錄 product backlog，當然也可以用支援 Scrum 的軟體系統（例如免費的 ezScrum）甚至是一般的文字檔來管理 product backlog。
  • Sprint backlog：Sprint backlog 就是某一個 sprint 準備施工的 user story（可以想成是 product backlog 的子集合），同樣的 sprint backlog 裡面的 story也是要排序過的，比較重要的先開工。
  • 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）。

▲Taskboard與 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 動態圖就應該很容易了解了。

下一集：〈Scrum 是什麼（3）：三種補充文件〉

泰迪軟體【Scrum敏捷方法實作班】招生中。

***

友藏內心獨白：寫這一篇又是破紀錄的久，突然有一種這一系列寫完又要去醫院做復健的不祥預感...Orz。