文章重點:
- 傳統專案執行,可能面臨的問題
- 解決方向
- 敏捷 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 工程師都在同一團隊中,
如此一來,在面對問題或需求時,團隊內部就可以自行解決,省去跨部門協調的麻煩,更能掌握專案進度。
Scrum 的價值毋庸置疑,但現實上在執行時卻常常以失敗收場,主要原因是它可能改變現有的運作方式,例如管理習慣、開會模式、人員組織 ... 為了降低失敗風險,建議可以分階段推動,先從比較容易執行的步驟開始。
- 練習拆解專案,短期交付
把週期長達一年、一季的專案,切割成 1~4 週,學習短期內交出成果,
這會促使成員思考工作的價值和優先順序。
- 進行每日站立會議
定時報告進度、同步資訊,能讓成員練習每天都有所進展,也能更有效的追蹤工作,提升團隊合作品質。
以下是使用 xms+ 「專案管理」功能執行敏捷專案 Scrum 的操作教學。