整理 Product backlog
- 新增工作
把專案中所有要做的事，都建立成工作，就能列出待辦工作清單。
- 為工作分類
如果工作數量有非常多，不容易逐項安排時程，可以先不設定期限，
改成利用「標籤」來分類 (例如重要、非重要、緊急、非緊急)。
備註:
也可以依照重要、緊急程度，粗略規劃工作執行的先後次序。
例如，假設專案期間是 8/1~10/31，比較重要、緊急的工作，期限就可以先設定在 8/31，讓工作列在清單的前面。
-
00:00
1.
封面
-
00:11
2.
傳統專案常見問題
-
01:42
3.
提問
-
01:55
4.
Scrum 重要活動
-
03:02
5.
整理 Product backlog
-
03:26
6.
Sprint 短衝 ~ 規劃會議
-
05:18
7.
每日站立會議
-
06:07
8.
檢視會議
-
06:41
9.
回顧會議
-
07:03
10.
Scrum 團隊編制
-
07:30
11.
Scrum 無痛起手式
-
08:34
12.
善用 xms+ 系統
-
09:08
13.
重點整理
播放影片: https://learning.xms.tw/media/1350
傳統認為成功的專案，
就要「如期 (On time)、如質 (On quality)、如預算 (On budget)」。
強調規劃好一切後，照著固定階段，按表操課、做出完整成果才交付，這在過去需求明確、且環境變化慢的製造業時代，有很多好處。
但現在資訊流通快速，市場競爭激烈，
造成客戶、老闆的需求非常多變，未來更有許多不確定性，
傳統的「瀑布式」管理，經常遇到以下問題：
- 難以安排工作時程
專案週期長、待辦工作很多，而且需求常常在變，未來不好預估，就很難安排「所有工作」的時程。
- 難以如期執行、掌控進度
週期長，過程就可能有更多變數，讓工作難以如期進行。
加上「瀑布式」強調完成前一個階段後，才能進行下一階段，所以一旦 delay，就容易影響整體進度。
- 難以回應變化、即時改善
需求多變、不確定性高，計劃就常常趕不上變化，
所以傳統專案「遵循計劃，最後才交付」的特性，
就容易導致投入很多時間、資源，終於做出成果，但最後才發現不是市場 or 客戶想要的，只能重新來過 ...
這些問題，透過「敏捷管理」，就能有效得到解決，
而如果想要實踐敏捷管理，「Scrum」就是你絕對要學會的一套方法！
而如果想要實踐敏捷管理，「Scrum」就是你絕對要學會的一套方法！
敏捷 Scrum
分階段執行專案，全力衝刺短期目標
並逐步交付成果，取得回饋、持續改善
- 整理 Product backlog
負責人會先評估客戶、市場的各種需求，整理出 Product backlog (待辦項目清單)，並依照待辦事項的重要性、急迫性進行分類或粗略規劃，讓專案有一個大致的目標。
- 進入 Sprint，找出短衝目標 (待辦清單)
舉辦規劃會議 (Sprint Planning)，整個團隊都一起參與，共同討論並達成共識，挑出階段性要衝刺的目標 (工作清單)，這是 Scrum 的核心關鍵！
因為 Product backlog 中的待辦項目可能非常多，很難為「所有項目」安排明確的時程，所以 Scrum 會把專案週期分割成多個 Sprint (短衝)，通常為期 1~2 週，不超過一個月，讓團隊聚焦在重要項目上，集中火力達成短衝目標，解決「難以安排工作時程」的問題。
- 每日站立會議 (Daily Scrum)
每天站著開會 5~10 分鐘，讓成員簡單回答：完成哪些工作、今天預計要做什麼、有遇到障礙嗎？
這是解決「難以如期執行、掌控進度」的關鍵，更深入的說明可以參考：
「每日站立會議 ~ 解決追蹤、溝通等問題最有效方式！」。 - 檢視會議 (Sprint Review)
這是取得回饋、交流意見與持續改善的好機會！
每次 Sprint 都會交付「有價值的成果」，可能是新產品、新功能，或功能的優化。
並且，團隊會邀請客戶、老闆 ... 等利害關係人 (Stakeholders)，一起檢視 Sprint 的成果，再次確認需求，討論可以怎麼改善，將可以解決傳統專案「難以回應變化、即時改善」的困擾。
- 回顧會議 (Sprint Retrospective)
Sprint 結束後，團隊會花時間討論過程中有哪些做的好、要繼續維持，哪些則效果較差，下次應該修正。透過反思「過程」，不斷改進，這樣一來，就能讓一次次的短衝，進行的越來越順利。
另外，Scrum 也強調「跨功能」的團隊編制，例如：PM、RD、UX 工程師都在同一團隊中，
如此一來，在面對問題或需求時，團隊內部就可以自行解決，省去跨部門協調的麻煩，更能掌握專案進度。
如此一來，在面對問題或需求時，團隊內部就可以自行解決，省去跨部門協調的麻煩，更能掌握專案進度。
Scrum 的價值毋庸置疑，但現實上在執行時卻常常以失敗收場，主要原因是它可能改變現有的運作方式，例如管理習慣、開會模式、人員組織 ... 為了降低失敗風險，建議可以分階段推動，先從比較容易執行的步驟開始。
- 練習拆解專案，短期交付
把週期長達一年、一季的專案，切割成 1~4 週，學習短期內交出成果，
這會促使成員思考工作的價值和優先順序。
- 進行每日站立會議
定時報告進度、同步資訊，能讓成員練習每天都有所進展，也能更有效的追蹤工作，提升團隊合作品質。
重點
- 1.
- 2.確定 Sprint backlog
- 從 Product backlog 選擇工作
使用「篩選」功能，就能快速找到重要 or 緊急的工作，優先放入 Sprint backlog。
- 設定期限
為短衝內預計完成的工作，設定明確的「期限」，就能讓工作依照期限的順序，列在清單的前面。
- 從 Product backlog 選擇工作
- 3.每日站立會議 ~ 追蹤工作想要提升開會效率，可以在成員輪流報告時，配合使用「工作與記錄總覽」，
透過切換負責人和狀態，就能顯示工作的處理狀況，例如- 已完成 (昨天完成了什麼？)
- 進行中 (今天預計要做什麼？)
- TBD (遇到什麼困難，需要協助？)
更詳細的做法，可以參考課程「每日站立會議」。
- 4.檢視會議 ~ 檢視 Sprint 成果以「微課程 ~ 會議管理」的工作為例，
執行時，在處理記錄附上錄好的課程影片連結，以及講稿、PPT 的檔案，
檢視會議時，就可以進入工作、查看記錄，並逐項檢視成果。
- 5.回顧會議 ~ 反思 Sprint 過程除了看成果之外，我們也可以透過「報表 (工作執行)」的具體數據，幫助我們回顧短衝過程中，有什麼需要改善的地方。
例如，分析「已過期」的工作，是因為規劃時太樂觀，還是因為被插件而逾期，並針對根本原因，思考改善方法；或是從「驗證不通過」的工作，反思執行時是否遺漏哪些細節，下次又該如何避免。
特別提醒:預設檢視的期間是一個月，可以自行變更為符合短衝長度的期間。
評語
請登入後才可以評分
-
00:00
1.
封面
-
00:11
2.
傳統專案常見問題
-
01:42
3.
提問
-
01:55
4.
Scrum 重要活動
-
03:02
5.
整理 Product backlog
-
03:26
6.
Sprint 短衝 ~ 規劃會議
-
05:18
7.
每日站立會議
-
06:07
8.
檢視會議
-
06:41
9.
回顧會議
-
07:03
10.
Scrum 團隊編制
-
07:30
11.
Scrum 無痛起手式
-
08:34
12.
善用 xms+ 系統
-
09:08
13.
重點整理