敏捷管理成功的關鍵及常見的迷思

敏捷管理常見的迷思

在尚未了解敏捷的精神和應用之前,有些人對敏捷會有一些迷思,其中最主要的一個迷思是,把敏捷跟專案畫上等號。雖然我們經常看到 ‘敏捷專案管理’ 這個名詞,但其實更嚴格地講,應該稱為敏捷式管理或敏捷式手法。敏捷管理不見得是只用來管專案,在之前孟華顧問的線上系統教學影片中,我們是以產品開發專案為例,為了做好這個產品交付,我們與其花一段較長的時間做出一個很龐大的產品交付,我們採用敏捷管理,用更頻繁多次(亦即多個迭代)做出更小的交付,同時,每次交付都是使用者可以看到、可以用的,所以我們更早推出產品讓使用者能使用、提供回饋,進而持續改善,經過多次迭代產出來做出更滿足使用者需求的產品。

講到這裡,對敏捷迭代式的交付,希望很多人都能了解到敏捷的效益。不過,從敏捷的宣言裡,或許也有很多人認為敏捷都不需要寫文件、敏捷也不需要計劃,甚至很多人說我們有用看板、我們有站立會議,我們就是敏捷,這些想法其實都是問號。正確的說法應該是,看板(Kanban)是敏捷的一個很好的工具,而站立會議是進行敏捷式溝通的很好的方式;但反過來說,並不是用看板來管理就一定是敏捷式管理,從我所觀察到,很多公司雖然有看板工具,但其實還是以瀑布式專案的管理思維和作法,這麼一來反而會有疊床架屋的情形。


敏捷管理的成功關鍵

如何推行敏捷式管理比較容易成功?大概可以分成幾個重點:

  • 第一點,產品負責人跟開發團隊要非常密切的互動。不論是在站立會議或是平日的溝通,產品負責人不能像一般瀑布式裡所謂的計劃主持人,等到查核點的時候才出現。敏捷式管理中這個密切的互動溝通是很重要的,這樣才能夠確保在每一個迭代能夠做一個快速的交付,或是迭代與迭代之間能做快速的決策和改善回饋。反過來說,如果在敏捷管理執行中,產品負責人還是等到查核點才出現,中間那些迭代的交付搞不好在最後又被全盤推翻,如此就完完全全失去了敏捷的精神。
  • 第二點,是攸關產品工作清單 (Product Backlog)的取捨與排序。常常大家都覺得,每個工作項目都很重要,但是當我們什麼都認為很重要、什麼都想做,最後就會變成什麼不知道要從何開始,甚至無法做出來。所以在這裡特別強調,Product Backlog的取捨及優先順序,對敏捷管理的成功交付是非常重要的。
  • 第三點,是關於每一個工作項目(Work Item)的大小。一般而言,每個迭代的執行期間是1~2週,多數人以兩週為單位,我們不希望一個Work Item的內容在一個迭代中做不完。因此,若是真的有這麼大的Work Item,請務必要把它切割成比較小的Work Item,否則就很難完成迭代的管理與交付。
  • 第四點,是不要怕做錯,而是要能快速回饋修正。剛開始應用敏捷管理時,多數人會想迭代這樣規劃,做得不好會怎麼樣。如前面所提,每一個迭代的期間是1~2週,所以如果這一個迭代的交付做錯或不如預期,能夠在下一個迭代快速把它修正過來,這才是敏捷的重點。

綜合以上所說的敏捷成功關鍵,第一點是Product Owner與開發團隊的密切互動;第二點是Product Backlog的取捨和優先順序,這是很困難的一件事,因為大家都覺得什麼都很重要、什麼都要做,最後很可能又會回到今天的一個惡性循環,什麼都要做、卻又甚麼都做不好,時間又一拖再拖,因此,取捨和排序非常重要。第三點是要切割work item為適當的大小;最後一點是在在迭代與迭代之間,能快速的回應與修正,快速回饋、持續改善是敏捷的精神,也是敏捷成功的關鍵之一。