錯！你認識的敏捷開發根本不敏捷！

敏捷開發Scrum專案管理

本篇的內容標題雖然很聳動，根據一個假期的學習後，我只能說完全顛覆我過往對敏捷開發的一些想像。

大多數的人把敏捷開發當作成一種規範，按照著前人的敏捷開發方式一定就能夠成功對吧？我想新手 PM 在一開始就踏入了條不歸路。大多數的開發團隊甚至都還不清楚敏捷開發的原則跟意義就套用了，你說要怎麼成功以及進行？

本篇文章將是我個人的一個學習紀錄，會盡可能將內容整理的有條理。

現在想要 Hire 一隻敏捷蟲來當我們的 Scrum Master lol

在進入正題之前，我想推薦幾個不錯的內容頻道的 Ref：

  1. 產品三眼怪實驗室 — 聚集了超多 PM 的經驗以及分享
  2. 10 分鐘學敏捷 — 言簡意賅的教學影片讓任何不懂專案管理的人都能理解敏捷
  3. 不是工程師也能懂的 Scrum 入門介紹 — 透過簡單的內容分享 Scrum 工作術

敏捷（Agile）開發

敏捷開發是一種應對快速變化需求的一種軟體開發模式，並且敏捷開發的宗旨主要是「擁抱變化」。

敏捷開發由敏捷宣言以及 12 項原則所組成，旨在遵守其宣言及原則。

敏捷宣言

  • 人員與互動 高於 流程與工具
  • 可運作的程式 高於 繁複的文件
  • 客戶合作 高於 合約談判
  • 回應變更 高於 遵循計畫

「宣言」 不是建議用左邊的物品替換右邊的物品，而是強調優先考慮左邊的物品。

敏捷 12 項原則

  1. 我們最優先的任務，是透過早期並持續地交付有價值的軟體來滿足客戶需求。
  2. 歡迎不斷變化的要求，甚至是開發後期。敏捷流程利用變化來實現客戶的競爭優勢。
  3. 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
  4. 業務人員和開發人員必須在整個專案中每天一起工作。
  5. 圍繞有動力的個人建立專案。為他們提供所需的環境和支持，並相信他們能夠完成工作。
  6. 開發團隊內部和內部傳達訊息的最有效的方法是面對面交談。
  7. 可以透過軟體來衡量是否進步。
  8. 敏捷過程促進可持續發展。贊助商、開發者和用戶應該能夠無限期地保持穩定的步伐。
  9. 持續關注技術卓越和良好的設計可提高靈活性。
  10. 精簡──或最大化未完成工作量之技藝──是不可或缺的。
  11. 最佳的架構、需求與設計皆來自於能自我組織的團隊
  12. 團隊定期反思如何變得更有效，然後相應地調整和調整其行為。

總結一下，我自己看上去認為比較重要的幾條：

  • 可以不斷地變化要求，以實現客戶的需求
  • 精簡工作量
  • 最佳的架構、需求與設計皆來自於能自我組織的團隊
  • 團隊定期反思如何變得更有效，然後相應地調整和調整其行為

Scrum 總架構

分為 3 Roles、3 Commitments、3 Artifacts、5 Values、4 Events

Roles

  • Product Owner（PO）：定義專案做什麼，負責最大化產品以及開發團隊工作的價值。
  • Scrum Master（SM）：從過程保證了如何實現專案，是團隊的導師和組織者，與 Product Owner 緊密合作，及時為團隊成員提供幫助。
  • Developer（Dev）：從技術保證如何實現專案。

Commitments

  • Product Goal：產品目標，產品的最終目標
  • Sprint Goal：短衝目標，在每個短衝期間所要完成的目標
  • Definition of done（DOD）：完成定義，每次的交付都需要認定什麼叫完成

Artifacts

  • Product backlog：產品待辦清單
  • Sprint backlog：短衝待辦清單
  • Increments：功能成品

Values

  • Commitment：願意對目標做出承諾
  • Courage：有勇氣做出承諾並履行承諾
  • Focus：將心思用在承諾的工作上
  • Openness：把專案中的一切開放給每個人看
  • Respect：每個人都有它獨特的背景和經驗，並尊重每個人

Events

  • Sprint Planning：短衝規劃會議
  • Daily Scrum：每日站立會議
  • Sprint Review：短衝檢視會議，需要符合 DOD
  • Retrospective：內部自省會議，以確保下次的短衝可以保持更好

一、短衝規劃會議可分為 Part 1、Part 2

Part 1：討論需求內容（what to do）

  • 由 PO 解釋此 Sprint 所預計要完成的 User Story 有哪些
  • 目的是為了與成員們溝通，拉近彼此對於需求的共識

Part 2：討論實作方法（how to do）

  • 將 User Story 分成若干個 Task（eg 設計 UI、設計資料庫表格 ..）
  • 估算每個 Task 所需要的工時

二、站立會議

會議目的

利用每日站立會議，快速溝通專案進度，目標 15 分鐘結束

分別是檢視專案進度，並根據需求調整 Sprint Backlog 的清單

會議內容

  • 昨日做了什麼
  • 今日要做什麼
  • 需要什麼幫助

三、Sprint Review 短衝檢視會議（與客戶召開）

會議內容

  • 向利害關係人展示功能以及產品特性，讓客戶驗收並收集用戶回饋
  • 檢視 Sprint 成果和決定未來的調整方向

注意事項

  • 交付給客戶的功能，須先經過內部驗收標準

四、Retrospective 短衝回顧會議（內部召開）

會議目的

  • 將經驗總結累積，並於下個 Sprint 進行改善
  • 探索如何才能提高效率和品質

會議內容

  • 回顧本 Sprint 有關人員、互動、流程、工具以及交付的功能情況
  • 總結哪些做得好、哪些不好、遇到哪些問題，以及如何解決這些問題

用戶故事

用戶故事是敏捷中用戶功能的最小單位，可以在一個敏捷衝刺中交付。

通常我們會透過一個公式來列用戶故事，分別是 Who + What + Why

範例：作為一個部落客，我想要撰寫文章，以便讓所有人可以知道我。

也需要符合以下特性

  • 獨立性：實現當前功能的時候不會依賴於其他功能
  • 可協商性：不應該包含過多的細節
  • 有價值性：如果沒有價值根本不需要被產生
  • 可以估算的：對故事進行評估
  • 小的：盡量將用戶故事切得越小越好
  • 可以進行測試的：確認是否能完成的，符合 DOD

常見問題

一、Product Backlog vs Epic vs User Story

在敏捷開發中，Product Backlog（產品待辦清單）、Epic（史詩）和 User Story（用戶故事）是三個不同層次的需求描述。

在實踐中，Epic 是 Product Backlog 中的一個項目，代表一個較大的需求單位，而 User Story 則是 Epic 的一部分，更具體地描述了用戶的需求。Epic 可以進一步拆解為多個 User Story，以便更容易地規劃和執行。Product Backlog 則包含了所有的 Epics 和 User Stories，提供了全面的需求視圖。

二、我的團隊適合 Scrum 嗎

最重要的三點：

  1. 永遠彈性調整，並優先做最重要的事情
  2. 團隊的所有人都要能「隨時掌握情況，幫助彼此解決問題」
  3. 要專注在「如何於固定時間內，產生更多價值」

筆者認為問團隊是否適合前，可以好好先跟團隊溝通並且傳達正確的 Scrum 原則，以讓大家都能符合原則跟規範在進行！若不行採用別種管理方式也可以的！

三、如何評估工作量？

談到評估工作量時，在敏捷中有兩種評點方式，第一種是用戶故事點數、第二種是工作時數預估

基本上需要先評估用戶故事點數，可以透過費氏數列：

1..2..3..5..8..13..21

Story Point 評分的簡易流程

  1. 先理解 User Story
  2. 設立度量衡
  3. 各自填寫自己認為的點數

若有認知差異需要點名以繼續

  1. 倘若點數會穿越多個數字，需要特別出來討論是否認知不一
  2. 若 User Story 出現 21，需要確定是否切得不乾淨