跳至主要内容

Project Management

參考資料

個人經驗心得​

  • 不要把「Story、Task、Bug」和 subtasks 混為一談。開發上如果需要拆成多個 Todo Items 應該用 subtasks。
  • 估點的層級可以是「Story、Task、Bug」，不同的 functions（例如 FE/BE/QA）估自己的部分。
  • Story/Task 不應該太大，盡可能要能在一個 Sprint 內做完，否則應該要再拆的更小

Scrum​

Product Backlog​

  • 由 PO 負責釐清優先順序

User Story​

  • 通常會用類似的描述：「As a user, I want to be able to ..., in order to... 」

Epic 和 User Story 的差別​

  • User Story 應該要能在一個 Sprint 內完成，如果會超過一個 Sprint 則應該要再拆
  • Epic 會是更大更完整的功能，沒有辦法在一個 Sprint 內完成，而是會需要多個 Sprint 的時間

Sprint Backlog​

  • 這個 Sprint 中要完成的項目清單
  • 一般來說 Sprint 開始後就不能變更

Role​

Product Owner (PO)​

  • 掌握 Product Backlog 的人
  • 在專案初期，他們需要釐清、確認和定義需求，建立 Epics 和 User Story
  • 定義在 Product Backlog 中各個 task 的優先順序
  • Sprint 開始後，他們應該要在 Demo 時檢查所有產出，並且驗證做出來的功能有符合需求
  • 同時，他們也是最終 approve 產品完成的人
  • PO 也是能夠在 Sprint 中修改 ticket 優先順序的人

Scrum Master​

  • 要為 Scrum 的成敗負責
  • 支持 PO 和 Developer Team 成功地完成任務
  • 確認大家做的事情和 Scrum 的目標是一致的
  • 帶領活動讓大家合作
  • 執行 Planning, Retro, Daily Standups
  • 管理 Backlog changes
  • 移除團隊當前面對到的障礙
  • Coach & Mentor

Scrum Master 和 Project manager 的差別​

  • PJM 負責整個專案，包含 business case, budget, risks, stakeholder management, vendor management；並且可以同時負責多個專案；帶領專案從開始到結束
  • Scrum Master 則是專注在帶特定的 scrum team 和 delivery；不能同時專注在多個 Scrum team

Ceremonies​

Daily Standup(DSUs)​

  • What did you do yesterday?
  • What will you do today?
  • Are there any roadblocks or issues that may prevent you from completing your tasks?

Sprint Planning​

  • PO 從 Backlog 中取出希望此次衝刺能完成的 Story，排序好後，逐一向團隊介紹他希望這次 Sprint 要完成哪些故事。
  • 團隊和 PO 確認驗收標準（AC），確保大家腦中的想像和預期結果是的一樣，重複以上動作，直到團隊無法承諾更多故事。
  • 在 Sprint 開始之後，不能再追加故事，除非團隊提早做完主動要求，或有其他特殊原因需要中斷。

Sprint Review​

  • 團隊向 PO 和其他 stake holders 展示這個 Sprint 完成的項目

Retrospective​

  • What went well during the last sprint?
  • What did not go well and not as per plan?
  • 不聚焦在 who，而是假設這件事是種必然：發現事件中反覆出現的模式 → 尋找因果關係 → 討論迫切性及影響程度（是否值得花時間及成本進行改進）

Story Point Estimation​

  • 能估點的人最好是會該實作技術的人（不同 function 不要互相估點）
  • Story Point 是一個相對的概念，請大家先校準 1 點可能是要實作什麼功能（例如，新增一個按鈕）

Terms​

Spikes and RFCs (Request for Comments)​

  • Spikes
    • Focused on research and exploration
    • When you're trying to figure out how to do something
  • RFCs
    • Focused on proposing and discussing changes to a system or protocol
    • When you know what to do but want to get consensus on your proposal before moving forward