關於網路那些事...

網路行銷,SEO,網路趨勢,教學文章,網頁設計,生活時事

敏捷開發 - Scrum 介紹

Scrum

Scrum 是一個敏捷專案管理架構:

Core Role 核心角色
  • Production owner ,產品負責人
    • 產品方向及願景,定義產品細節,優先級別,交付時間
  • Scrum Master,團隊負責人
    • 負責團隊 scrum 能合理運作,理解需求及安排產品技術製作時程,確保工程品質
  • Team (Developer),開發團隊
    • 5-9人團隊,團隊成員具備交付軟體所需要的各種技能
Activity,執行 scrum 活動的流程
  • Sprint planning meeting

    • 每個 sprint 開始的第一天,先進行 4-8 小時 plan to sprint 會議
    • Core Role 成員都需要參與,溝通
    • 逐一將所有 stories point分割成 task 項目(要做什麼,該怎麼做)
    • 估算每一個 task 所需要的時間(單位:小時)
    • 會議結束會產生 Sprint baccklog story (以及 task list)
  • Daily Scrum 每天15分鐘

    • 每日成員會議,團隊成員輪流報告
    • 昨天目標執行狀況
    • 今天預計完成目標
    • 有沒有遇到什麼問題
  • Sprint

    • 以 2-4 週為一個衝刺區間
    • 在期間內逐一完成 story 中的 task 項目
  • sprint demo (review) meeting

    • 在正式 Demo 之前,進行 2-4 小時的預前會議
    • Core Role 成員都需要參與
    • Production owner 會確認 story 有做到他期望的結果
    • Production owner 會再根據 story 提出新的想法,形成新的 sprint 則作為第二階段需求
    • 需預留會發生不符期待所需要的修正時間
  • Sprint repospective metting (1.5-3小時)

    • 回顧會議(改善優化)
    • 由 Scrum Master 與 Team Developer 參與
    • 提出的項目要掌握好,以2週時間能處理的為主,若項目過多,可另開 story
    • 哪些方法適合繼續執行

    例如: CI/ CD 執行狀況探討及回應

    • 哪些流程需要被改善

    例如,目前測試不夠完善,測試設備不足

    • 提出改善計畫 - action plan
  • Product backlog refinement metting (4-8小時)

    • 又稱 Product Backlog Grooming ,在執行 sprint 階段,規劃下一階段要做的項目
    • 由 Production owner 檢視 story 裡面的項目
    • 提出下一階段準備要實施的 story
Artifact,Scrum 文件管理
  • Vision

    • 軟體的遠景、願景
  • Story

    • 將 Vision 具體成可被執行的項目
    • 以使用者角度思考,軟體能帶來什麼功能,使用者能獲得什麼好處
    • 列出這些功能,形成一個個的 story (亦稱為 User story)
  • Product backlog

    • 待辦清單
    • 待辦清單中的項目,即稱為 PBI (Product backlog item)
    • 從重要性來做優先順序排序
    • 計算 story point
Importance Story topic Notes How to test Estimate
重要性 目標主題 註解 如何測試,如何Demo 完成此所需的 Story point

story point:

*使用相對數字 *

估算 story point 流行使用的是改良版費氏數列 (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100)

避免陷入連續數容易產生的糾結 (例如 在13, 14之間拿捏不定 )

延遲決定決策

Story point 是一種延遲決定的策略,需要到實際在 Sprint backlog 列出 task 時,才會推估出實際的時間

估算 story point

以建構後台為例,假設有五個單元要製作,功能都是CRUD

首先先推算出製作一個單元所需要的時間,就能以此類推的擬定出其他四個,就能取得總和

在估計story point 時,story point 單位為相對數值(非時間),

假設每個單元功能複雜度不一樣,以一個最基本的 CRUD story point 定義為 3,可以這樣估:

單元功能描述 story point
第一單元為 CRUD 3
第二單元為 CRUD + 圖片上傳 5
第三單元為 CR 1
第四單元為 CRUD + 圖片上傳 + 編輯器功能 8
Sprint backlog

  • 將 Story 轉化成可被執行的 Sprint 清單

首先,先確認清楚團隊可投入的有效工作時數

計算可投入有效工作時數

假設開發團隊有 2 名成員

以 sprint 為期 2 週情況,每天有效工作時間為 5小時,可預估有效工時為

2 人 x 10 天 x 5 小時 = 100 小時

Task
  • Sprint 可以被分成多個 task 任務

  • task 包括實際執行的每一個流程,包括設計, Code & Tests, CI/CD, QA+Fixes, Code Review + Fixes, Regresion + Fixes, 手冊及文件撰寫等

接著,根據 Task 來估計時間,可以沿用 story point 的方式來估

例如

  • 寫測試 : 5 小時 ( 1 story point)
  • 寫 code: 8 小時 (1.6 story point)
  • 測試:13 小時 (2.6 story point)

就可以得到 Task 所需要的總時間為 26 小時 (5.2 story point)

Burndown chart (task, story, release)


(示意)

  • 燃盡圖,將 task, story, release 實際完成狀態圖像化
  • task 是以 (實際完成工時/預期總施時) 來製作
Running software
  • 隨時可被用來發布上線的項目
  • 在 Sprint 執行過程,要能建構一套 running software
  • 這套 running software 可以隨時隨地切換到正式環境營運
Sprint info page
  • 在 Sprint planning meeting 會後,由 Scrum Master 製作文件
  • 文件說明本次 Sprint gold,Story, Sprint backlog 開始即結束時間,並且讓 Team developer 知道新的 sprint 開始
Sprint demo agenda
  • Sprint 結束前一天,由 Scrum Master 完成 Sprint demo 議程
  • 議程包括,需要 demo 的項目及時間,每一個 demo 負責解說者及輔助角色
Sprint summary report
  • 開完 Sprint repospective metting 回顧會議,由 Scrum Master 將會議結果整理成文件
  • 文件內容,對本次 sprint summary 完成狀況,sprint period 開始到結束的時間,sprint gold 目標中的 story points 完成度,Retrospectives 列出良好(Good)以及可優化項目(Improvements)列出來
  • 讓團隊成員知道這次 sprint 結束
Ancillary Role
  • Stakeholder

    • Customer

    客戶

    • Vendor

    老闆

  • Manager

    • PM

圖片來源:src


如果這篇文章對你有幫助,請在這裡點個讚



最新文章推薦