基礎
文章重點：
- 傳統專案執行，可能面臨的問題
- 解決方向
- 敏捷 Scrum 方法
- 從哪裡開始推動，可以簡單又很快有效果？
敏捷 ~ 顧名思義，就是可以更快因應環境的變化，及早調整，避免埋頭苦幹、做了好久之後才發現問題 ...
傳統認為成功的專案，
就要「如期 (On time)、如質 (On quality)、如預算 (On budget)」。
強調規劃好一切後，
照著固定階段，按表操課、做出完整成果才交付，這在過去需求明確、且環境變化慢的製造業時代，有很多好處。
但現在資訊流通快速、 產品生命週期短、市場競爭激烈，
造成客戶、老闆的需求非常多變，未來更有許多不確定性，
傳統專案的「瀑布式」管理，經常遇到一些挑戰：
- 工作時程，不好安排
專案週期長、待辦工作很多，除了很難安排「所有工作」的時程外，也不容易隨著環境 or 需求變化調整。
- 進度，不好掌控與如期完成
週期長，過程就可能有更多變數，讓工作難以如期進行。
加上「瀑布式」強調完成前一個階段後，才能進行下一階段，所以一旦 delay，就容易影響整體進度。
- 變化、
難以即時回應與改善
需求多變、不確定性高，計劃就常常趕不上變化，
所以傳統專案「遵循計劃，最後才交付」的特性，
就容易導致投入很多時間、資源，終於做出成果，但最後才發現不是市場 or 客戶想要的，只能重新來過 ...
解法
針對這些問題，「敏捷」管理會是一個好的作法 ~
用最少的時間做出成果、 並因應環境變化做出 「即時反應」 、疊代不斷改善。
也就是想辦法
- 將開發週期變短
- 聚集所有相關的人一起確認需求
- 盡全力用最短的時間完成
- 依據需求變動盡可能「即時」調整
在這種作法下，上述問題自然就可以迎刃而解。
- 工作時程，不好安排？
因為沒有要一次安排所有的工作，小範圍當然就容易許多。 - 進度，不好掌控與如期完成？
開發週期短，每天確認，就更容易即時發現問題、調整改善。 - 變化、 難以即時回應與改善？
每個階段完成後，都可以依據當下的情況 or 需求進行調整，不用等到整個專案執行完畢才發現問題。
敏捷 Scrum
分階段執行專案，全力衝刺短期目標
並逐步交付成果，取得回饋、持續改善
- 整理待辦事項清單 (Product backlog)
把所有想得到的需求、要做的事，都先紀錄下來！
並依照重要性、急迫性進行初步的分類或規劃，讓專案要執行的事情有一個大致的輪廓 or 目標。
小提醒：
即使計畫執行中也是，可以即時因應需求的變化。
- 找出短衝目標 (Sprint 工作清單)
這是 Scrum 的核心關鍵 ~ 拆解，找出要接下來 1~2 週要衝刺的目標。
讓專案執行更有目標、專注、有節奏，解決「難以安排工作時程」的問題。
做法就是舉辦規劃會議 (Sprint Planning)，
整個團隊一起參與，挑出「階段性」要衝刺的目標 (工作清單)！
- 每日站立會議 (Daily Scrum)
每天站著開會 5~10 分鐘，
讓成員簡單回答：完成哪些工作、今天預計要做什麼、有遇到障礙嗎？
這是解決「難以如期執行、掌控進度」的關鍵，更深入的說明可以參考：
「每日站立會議 ~ 解決追蹤、溝通等問題最有效方式！」。 - 檢視會議 (Sprint Review)
檢視階段性的成果，這是取得回饋、交流意見與持續改善的好機會！
每次 Sprint 都會交付「有價值的成果」，可能是新產品、新功能，或功能的優化。
並且，團隊會邀請客戶、老闆 ... 等利害關係人 (Stakeholders)，一起檢視 Sprint 的成果，再次確認需求，討論可以怎麼改善，將可以解決傳統專案「難以回應變化、即時改善」的困擾。
- 回顧會議 (Sprint Retrospective)
Sprint 結束後，團隊會花時間討論過程中有哪些做的好、要繼續維持，哪些則效果較差，下次應該修正。透過反思「過程」，不斷改進，這樣一來，就能讓一次次的短衝，進行的越來越順利。
另外，Scrum 也強調「跨功能」的團隊編制，例如：PM、RD、UX 工程師都在同一團隊中，
如此一來，在面對問題或需求時，團隊內部就可以自行解決，省去跨部門協調的麻煩，更能掌握專案進度。
如此一來，在面對問題或需求時，團隊內部就可以自行解決，省去跨部門協調的麻煩，更能掌握專案進度。
如何開始？
- 練習拆解專案，短期交付
把週期長達一年、一季的專案，切割成 1~4 週，學習短期內交出成果，
這會促使成員思考工作的價值和優先順序。
- 進行每日站立會議
定時報告進度、同步資訊，能讓成員練習每天都有所進展，也能更有效的追蹤工作，提升團隊合作品質。
以下是使用 xms+ 「專案管理」功能執行敏捷專案 Scrum 的操作教學。
未登入或權限不足!