Keys to Agile Management Success and Common Myths
敏捷管理常見的迷思
在尚未了解敏捷的精神和應用之前，有些人對敏捷會有一些迷思，其中最主要的一個迷思是，把敏捷跟專案畫上等號。雖然我們經常看到 ‘敏捷專案管理’ 這個名詞，但其實更嚴格地講，應該稱為敏捷式管理或敏捷式手法。敏捷管理不見得是只用來管專案，在之前孟華顧問的線上系統教學影片中，我們是以產品開發專案為例，為了做好這個產品交付，我們與其花一段較長的時間做出一個很龐大的產品交付，我們採用敏捷管理，用更頻繁多次(亦即多個迭代)做出更小的交付，同時，每次交付都是使用者可以看到、可以用的，所以我們更早推出產品讓使用者能使用、提供回饋，進而持續改善，經過多次迭代產出來做出更滿足使用者需求的產品。
講到這裡，對敏捷迭代式的交付，希望很多人都能了解到敏捷的效益。不過，從敏捷的宣言裡，或許也有很多人認為敏捷都不需要寫文件、敏捷也不需要計劃，甚至很多人說我們有用看板、我們有站立會議，我們就是敏捷，這些想法其實都是問號。正確的說法應該是，看板(Kanban)是敏捷的一個很好的工具，而站立會議是進行敏捷式溝通的很好的方式；但反過來說，並不是用看板來管理就一定是敏捷式管理，從我所觀察到，很多公司雖然有看板工具，但其實還是以瀑布式專案的管理思維和作法，這麼一來反而會有疊床架屋的情形。
敏捷管理的成功關鍵
如何推行敏捷式管理比較容易成功？大概可以分成幾個重點：
- 第一點，產品負責人跟開發團隊要非常密切的互動。不論是在站立會議或是平日的溝通，產品負責人不能像一般瀑布式裡所謂的計劃主持人，等到查核點的時候才出現。敏捷式管理中這個密切的互動溝通是很重要的，這樣才能夠確保在每一個迭代能夠做一個快速的交付，或是迭代與迭代之間能做快速的決策和改善回饋。反過來說，如果在敏捷管理執行中，產品負責人還是等到查核點才出現，中間那些迭代的交付搞不好在最後又被全盤推翻，如此就完完全全失去了敏捷的精神。
- 第二點，是攸關產品工作清單 (Product Backlog)的取捨與排序。常常大家都覺得，每個工作項目都很重要，但是當我們什麼都認為很重要、什麼都想做，最後就會變成什麼不知道要從何開始，甚至無法做出來。所以在這裡特別強調，Product Backlog的取捨及優先順序，對敏捷管理的成功交付是非常重要的。
- 第三點，是關於每一個工作項目(Work Item)的大小。一般而言，每個迭代的執行期間是1~2週，多數人以兩週為單位，我們不希望一個Work Item的內容在一個迭代中做不完。因此，若是真的有這麼大的Work Item，請務必要把它切割成比較小的Work Item，否則就很難完成迭代的管理與交付。
- 第四點，是不要怕做錯，而是要能快速回饋修正。剛開始應用敏捷管理時，多數人會想迭代這樣規劃，做得不好會怎麼樣。如前面所提，每一個迭代的期間是1~2週，所以如果這一個迭代的交付做錯或不如預期，能夠在下一個迭代快速把它修正過來，這才是敏捷的重點。
綜合以上所說的敏捷成功關鍵，第一點是Product Owner與開發團隊的密切互動；第二點是Product Backlog的取捨和優先順序，這是很困難的一件事，因為大家都覺得什麼都很重要、什麼都要做，最後很可能又會回到今天的一個惡性循環，什麼都要做、卻又甚麼都做不好，時間又一拖再拖，因此，取捨和排序非常重要。第三點是要切割work item為適當的大小；最後一點是在在迭代與迭代之間，能快速的回應與修正，快速回饋、持續改善是敏捷的精神，也是敏捷成功的關鍵之一。
近期文章
