今天來看 Retro Meeting，是敏捷專案管理中非常重要的一部分。Retro 通常在每個 Sprint 結束後舉行，目的是讓團隊反思 Sprint 的工作過程，發現並討論問題，從而持續改進團隊的工作效率和品質。 回顧會議的目的 反思和學習 團隊成員一起回顧過去的衝刺，反思什麼做得好、什麼地方需要改進，並學習如何在未來的衝刺中避免相同的問題。 以我們工程師來說，可以有很多內容可以提出，包含但不限於： 1. 對隕石與需求變動的改善方式 2.

今天來看敏捷專案管理中很重要（但混合式專案管理常被忽略或變種）的衝刺審查（Sprint Review）。 衝刺審查通常在每個 Sprint 結束時舉辦。主要目的是讓開發團隊展示這個Sprint 完成的工作成果，並收集來自 PO 和其他利害關係人的回饋，確保產品方向與需求一致。 衝刺審查的主要活動 展示進度或成果 開發團隊會展示在衝刺期間完成的產品增量，讓大家得知這個 Sprint 的產出。 獲得回饋 利害關係人和產品負責人會對展示的成果提供回饋，這些回饋可以讓 PO 決定是否需要調整產品待辦清單（

今天來看看敏捷專案管理中的產品待辦清單（Product Backlog）和衝刺清單（Sprint Backlog）差異： 產品待辦清單 Product Backlog 產品待辦清單是一個有(優先)序的需求列表，包含產品需要實現的新功能、修正的錯誤、技術問題和其他待改善的工作項目。 在敏捷專案中，這個清單由產品負責人 PO 管理，隨著新需求的出現或現有商業需求的優先級變化，產品待辦清單會不斷新增或調整內容。 相對於衝刺清單，產品待辦清單會是高層次的描述，不一定有具體細節，

Agile 敏捷專案管理在近年來越來越受到重視，特別是在軟體開發領域。它的靈活性和迭代式的開發方式，使得團隊能夠更快速地適應變化與交付。在現行 PMBOK7 中更是加入了不少敏捷的內容，所以今天就讓我們來看看「理論上」敏捷專案的三個核心角色：產品負責人 Product Owner、敏捷教練 Scrum Master，以及開發團隊Development Team 差異。 產品負責人 Product Owner 首先來看看產品負責人，PO

在 PMP/PMBOK 中，當專案面臨變動，需求被迫增加（已通過變更控制委員會）但 Deadline 無法改變甚至提早的情況下，有多種方式可以應對這些變化。通常應對方式是集中在時間管理、範疇管理和資源管理上，例如「快速跟進」和「縮程（趕工）法」，今天就來介紹有哪些策略可行： 快速跟進 Fast Tracking 快速跟進是指將相對於「當前」