Leon's Blogging

Coding blogging for hackers.

Scrum 簡單介紹

| Comments

最近想在團隊中試著導入 scrum，因此先來瞭解一下 scrum 的概念

Waterfall vs Agile

Iron Triangle

The iron triangle of planning

  • Scope is the work to be done – such as features and functionalities – to deliver a working product.
  • Resources include budget and team members working to deliver and execute.
  • Time is when teams will deliver to the market such as releases and milestones.

The iron triangle of planning

Scrum

Manifesto for Agile Software Development 敏捷宣言

  • 個人與互動 重於 流程與工具
  • 可用的軟體 重於 詳盡的文件
  • 與客戶合作 重於 合約協商 
  • 回應變化 重於 遵循計畫

Scrum Role

  1. Product Owner(PO，產品負責人)
    • 為產品的成敗負責
    • 負責管理產品需求並決定需求的施工順序
    • 負責回答問題與釐清需求
  2. Scrum Master(SM，無中文名稱)
    • 監督流程
    • 協助團隊持續改善開發流程
    • 排除任何阻礙開發活動的事件
  3. Development Team(Dev Team，開發團隊)
    • 負責開發軟體
    • 決定細節，執行任務
  4. stakeholder (利益相關者)
    • 和軟體開發專案有關，但是卻沒有實際參與專案開發活動的人

Scrum Object

  1. Item(物件) or Story(故事)：
    • 由 PO 來定義產出，Story 的 Scope 必須是可以讓團隊在一般的速率下完成 3 - 5 個為佳，太多會太雜，太少會讓團隊感覺到這次的 Sprint 產出沒感覺，對團隊信心是個打擊
  2. Task(工作)：
    • 由 Dev Team 列出 Story 所需完成的工作項目，並由 Dev Team 自行分配
  3. Product Backlog(產品待辦清單)：
    • 由 PO 負責整理的產品願景圖，以 Story 為單位，開始順序由上而下
    • As a user, I can do something so that I can achieve xxx
    • ProductBacklog.xls
  4. Sprint Backlog(衝刺待辦清單)：
    • Dev Team 向 PO 承諾這個 Sprint 會盡力完成的 Story List，以 Task 為單位
  5. Potentially Shippable Product Increment(潛在可交付產品增量)：
    • Dev Team 的產出，就是這個 Spring 所完成的項目，並且客戶需要就可以立即上線的
  6. Burndown Chart(燃盡圖)：
    • 剩餘的 Sprint Backlog，看看還剩多少才能清空，以 Task 大小為單位
    • 把所有 stories 的 tasks 施工的小時數加總起來，每次 daily Scrum 報告已經完成哪些 tasks，並將總時數減掉完成時數，畫成一個表，團隊就可以知道進度是否正常
    • Burndown Chart

Scrum Ｍeeting

Scrum 活動每一個都是有它的目的和時間限制(Time Boxed) Spring n 個禮拜，所有活動抓 n 小時

  1. Sprint(衝刺)：
    • 團隊決定哪些 Item 後，就開始去衝刺
    • 長度定義上是 1 - 4 個禮拜，但實務上不要多過2個禮拜
    • 長度應該要保持穩定，盡可能不變，這樣才容易讓團隊掌握節奏，也容易預估和比較 Sprint 內的工作量
    • 大原則是 Sprint 內的 Sprint Backlog 不改變(有原則就有例外)
  2. Daily Scrum(每日站立會議)：
    • 每天 10 - 15 分鐘不能超時
    • 目的是讓團隊資訊同步
    • 一定要站著為了讓大家長話短說
    • 主要報告三件事
      • 昨天做什麼以協助團隊達成sprint目標
      • 今天準備做什麼以協助團隊達成sprint目標
      • 有沒有遇到任何阻礙團隊達成sprint目標的事情
  3. Sprint Planning Meeting(衝刺規劃會議)：
    • 討論這次 sprint 所要開發的需求（stories）
    • 將 story 細分為若干個 task，並估算每個 task 所需的時間（以小時計算
    • Story 優先順序 PO 決定
    • 選多少 Item 由 Dev Team 決定
    • 會議後會產生 Spring Backlog，上面完整寫出這次 Spring 所需要的所有資訊
  4. Product Backlog Refinement / PBR(產品待辦清單精煉會議)：
    • PO 跟 Dev Team 一起討論近期內會開始的 Story
    • 從商業和使用者角度切入，儘可能不觸及技術細節
  5. Sprint Review(衝刺檢視會議)：
    • Sprint 結束時針對這次 Sprint 產出的會議
    • PO 邀請利害關係人對產出給予意見，必須是可用的功能才算產出
    • 不需準備 Powerpoint 或其他簡報，單純就軟體操作取得回饋
  6. Sprint Retrospective / Sprint Retro (衝刺回顧會議，也有人稱『自省』會議)：
    • Scrum Team 成員(Dev Team 或包含 PO)
    • Sprint Review 後，針對這個 Sprint 團隊的工作模式討論改善，並定出下個 Sprint 改善事項
    • 原則上只有團隊成員才能參加，避免主管級參與，而變成檢討會議

後面為非正規 Scrum - Scrum 是什麼（3）：三種補充文件

  1. Sprint Info Page (One Page, Kick off)
    • sprint planning meeting 開完之後，SM 會寫一份 sprint info page 文件，這份文件包含了 sprint goal(一句簡短的句子，用以表明該 sprint 所要完成的主要功能)，stories，sprint，startTime，endTime，以及團隊成員。
    • SM 將這份文件寄給 Scrum Team 與其他有興趣的輔助角色人員，讓他們知道一個新的 sprint 已經開始了。
  2. Sprint Demo Agenda
    • Sprint 結束前一天，SM 要寫出 sprint demo 的議程表，並將此文件寄給 Scrum Team 與其他有興趣的輔助角色人員。
    • 議程表包含所有要 demo 的項目，以及每一個 demo 項目要花多少時間，由誰負責 demo。
    • 當 Developer 收到該議程表時，就可以準備明天要 demo 的資料。
  3. Sprint Summary Report (會議記錄)
    • 當開完 sprint retrospective meeting 之後，SM 會準備此文件
    • 內容包含
      • sprint 所完成功能的簡述
      • 完成多少個 story points
      • 好的以及有待改善的項目（最多只各列三點）
      • 改善行動計畫
    • 將此文件寄給Scrum Team 以及其他有興趣的輔助角色人員，讓他們知道這個 sprint 已經正式結束了。

Technical

  • 單元測試(Unit Test)
  • 系統測試(System Test)
  • CI 持續整合(Continuous Integration)
  • CD 持續交付(Continuous Delivery)

Benefit

  • 快速驗證使用者反應
  • 學習目標導向解決問題
  • 學習團隊協作
  • 快速失敗，快速學習
  • 快速且頻繁的同步資訊
  • 自組織團隊(Self Organizing Team)
  • 自省會議(Retrospective)
  • 引導(Facilitation)

參考文件

Comments