[議題探討]導入Scrum專案管理方法以提升專案成功率

Scrum

傳統專案管理的方法,著重在專案啟始的規劃階段,希望能藉由完整詳盡的需求訪談和系統分析設計,透過各式的流程圖和需求確認文件來同步彼此的認知,降低開發期的規格變更風險。但在軟體開發專案時,經常是不斷變更規格,需求一變再變,以雲端貿易系統的軟體開發專案為例,使用者往往無法清楚地表達自己的需求,因為貿易系統功能牽涉到領域Know-how,使用者又不具備軟體設計的專業知識,所以往往會在需求訪談時產生「口是心非」、「雞同鴨講」的情形,導致系統功能開發完成後才發現功能不符需要打掉重做,如此的耗時費力常造成專案範疇、時程和資源暴增的失敗。

因應以上的情境,可以導入 Scrum 專案管理方法以提升專案成功率,由於大部分的軟體開發專案都會有交付時間的限制,而且專案啟始期總是難以明確界定需求,所以 Scrum 的管理重點就放在專案時程內的需求確認及變更管理上,頻繁地以部分雛型向客戶確認需求,每次展示時讓客戶提供一些反饋,就能知道開發方向是否需要修正,藉此逐步完成專案的目標。

在 Scrum 專案管理的團隊中,可分為一種輔助角色和三種主要角色:

先介紹輔助角色,也就是利害關係人,通常是客戶,負責說明產品需求,或是提供團隊工作的環境和資源。而第一種主要角色是 Scrum 團隊的負責人(Product Owner),負責釐清客戶對於產品的需求,將需求拆解成工作項目並以重要性排序,也負責確認整個專案的開發進度。第二種主要角色是 Scrum 團隊的促進者(Scrum Master),幫助團隊移除工作週期中所遇到的障礙,使團隊可以依循著 Scrum 的精神進行開發,類似 Scrum 團隊的秘書,負責流程改善、解決問題、整合團隊。第三種主要角色是 Scrum 團隊的開發人員(Team Member),建議成員具有各式技能,如資料庫設計、UI設計、美術設計等,負責專案的實際開發工作。

在 Scrum 的專案管理工作中,會有三種紀錄及三種會議:

首先是「故事」(Story),也就是客戶提供的需求紀錄,包含需求的情境,從專案開始到結束需要執行的所有工作,都會以故事描述的方式說明呈現;其次是「產品需求」(Product Backlog),將故事中的需求進行拆解後,可以分成很多個工作項目,並註記其重要性和必須完工的時間,以作為整個專案的產品需求紀錄;最後一種紀錄是「工作清單」(Sprint Backlog),呈現每個工作週期所需要完成的工作項目。

「工作規劃會議」(Sprint Planning Meeting),類似Kick-off Meeting,在每個工作週期啟動之前召開,讓所有團隊成員一起進行討論工作分派,安排這個工作週期所要完成的工作項目。「工作日報」(Daily Scrum Meeting),每天都簡短地召開,報告當日完成的工作項目、明日預計的工作項目、是否出現需要協助排除的障礙,由促進者進行協調處理。「展示會議」(Sprint Review Meeting),在每個工作週期完成之後召開,展示這個工作週期所完成的工作項目,讓負責人和客戶可以驗收階段成果是否符合期望,先確認最核心的關鍵工作項目,再考慮調整其他工作項目的重要性,或是直接決定捨棄部份產品需求。

綜上所述,在 Scrum 的工作週期中提供團隊成員更多自主性,也仰賴團隊間更大量的溝通與合作。對客戶而言,透過每次的展示回饋可以更即時地驗證功能是否符合需求,以導正系統開發方向,避免到系統測試期才能看到系統問題,卻已經錯失修正開發方向的時機。簡而言之,導入 Scrum 專案管理方法是為了在時間有限的情況下,將資源投入在最重要的產品需求項目,採用更敏捷的方式進行需求變動管理以提升專案成功率。

相關文章:[議題探討]何謂專案及專案管理?


發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料