談敏捷式管理手法
敏捷式(Agile)這個概念，其實源自於軟體工程。因為一個軟體在實做出來之前總是有很大的想像空間。如果軟體開發的結果不符合客戶或市場需求，那麼從前面的系統分析、系統設計，到程式撰寫、測試等等所花費的時間，最後可能又會重工，所以才會發展出敏捷式開發的做法。
了解敏捷式開發之前，我們先很快的來回憶一下常見的專案管理方法，也就是所謂的瀑布式(Waterfall)專案是怎麼管的。如果各位對孟華的專案管理協作平台ezteamwork很熟悉的話，首先會聯想到系統呈現的甘特圖。整個瀑布式專案的概念，就是希望盡可能、盡早地把專案計畫時程(Scheduling)排出來，而且希望專案計畫越精準越好，因為我們要依此時程計畫做成專案的Baseline基準，將來在執行這個專案的時候，我們要根據這個基準時程，來衡量專案的執行是否符合基準? 是超前或是落後? 也就是說在一個瀑布式專案裡面，它的源起都來自一個理想的計畫時程，而且計畫愈詳細越好，而我們最常使用的工具，就是大家非常熟悉的WBS (工作分解結構) 及甘特圖，所以WBS還有甘特圖是瀑布式專案裡面最常用的工具。
敏捷式管理
回到敏捷式管理這個主題，在討論其作法前，首先必須先談一下敏捷的宣言，敏捷的宣言其實有四個重點 :
- 互動大於流程
- Working software，也是就是可以正常運作的軟體，比寫一大堆文件來得更重要
- 跟客戶的協同合作會重於合約跟協商
- 我們要能夠回應變化，而不是一成不變的照計畫來做
上面第二個重點，是指開發出能正常運作的軟體，比花時間製作詳盡的文件來得更重要。如前面所提到，敏捷的概念源自於軟體工程，早期常常花了很多時間進行系統分析、設計，做了Prototype，而等到整個軟體開發出來之後才發現並不是符合客戶的要求。因此，第二個重點是強調，與其一開始花很多時間寫文件，最後把文件改掉重寫，還不如盡快把這個軟體雛形先做出來和客戶溝通討論來得更重要，因為我們知道在開發的過程，需求會不斷的修改、變化，所以才會有第四個宣言，也就是我們要回應變化，而不是像在一般傳統專案管理裡面，要透過繁雜的計畫變更程序才能回應變化，因為這樣的流程反而是沒有效率的。
敏捷式專案
一個敏捷式專案要怎麼管？敏捷式的管理方法有很多種，最常被多數人採用的方法，就是建立一個產品的待辦清單，也就是我們常聽到的 Product Backlog。Product Backlog通常會用User Story的方式來呈現。那接下來，我們會把專案裡的Product Backlog透過建立一個或多個迭代去執行，當然這個Product Backlog裡面的待辦清單是需要經過排序的，通常我們會把最優先、最必要的待辦清單放到第一個迭代裡面去，從每一個迭代裡面去做一個增量式的進展，而每一個迭代就會有其待辦的產出交付。正如前面的敏捷宣言中提到，可用的產品比文件更重要，因此每一個迭代的交付就要透過產品使用者來做驗證，也就是為何我們需要透過跟客戶或使用者的密切互動，來驗證產品、得到回饋，把得到的產品回饋投入下一個迭代進行持續改善。一個敏捷式的專案是以這樣的概念來進行，而不是花很長一段時間規劃設計、經過很幾個階段後才做出一個大的交付。
正如前面的敏捷宣言中提到，可用的產品比文件更重要，因此每一個迭代的交付就要透過產品使用者來做驗證，也就是為何我們需要透過跟客戶或使用者的密切互動，來驗證產品、得到回饋，把得到的產品回饋投入下一個迭代進行持續改善
敏捷和迭代
以手機APP的開發為例子，大家是否有注意到APP經常在改版，或許有人會想：為什麼APP開發者不一次做好，而是隔一段時間就會發布一些新功能，或是一些新修正呢? 其實現在市面上多數的APP開發都是使用敏捷式的概念來發展，我們認為的為什麼不一次做好、做完整的這個概念，是一個永遠不存在的理想，所以還不如趕快做出讓使用者可以看得到、可以使用的功能，然後以蒐集使用者的回饋來持續改善，這樣的作法比傳統的作法來得更實際有效。
更進一步探討，敏捷式專案管理的方法是透過一個一個迭代去滾動執行。在迭代與迭代之間，以及每一個迭代的裡面，團隊人員之間、以及和客戶之間都需要做很密切的互動，因此敏捷式專案團隊需要一個可視化的工具，看板(Kanban 或 Board)是敏捷式管理中最常用來進行人員溝通互動的工具。
敏捷團隊
敏捷團隊到底包含哪些角色? 根據敏捷的精神，敏捷團隊是一個扁平化的組織，和一般傳統瀑布式專案團隊組成有所不同。首先，敏捷團隊會有一個產品負責人(Product Owner)，產品負責人是最了解這個專案或產品需求的人，其次是開發團隊(Developer)，最後是促進者 (Facilitator)，這個角色在不同的敏捷方法裡也可以叫做Scrum Master，接著來看這些不同角色做什麼事情。
前面所提到的產品待辦清單Product Backlog，主要是由Product Owner和Developer共同自訂，重點是共同自訂，而不僅是由Product Owner自己訂定。
這些Product Backlog裡面會包含不同的工作項目，而且也需要依其重要性、必要性做排序，優先排序的待辦清單Work Items則會先指派給開發團隊來執行。同時，每一個迭代的Work Items和產出，同樣要由產品負責人來做確認驗收。因此，產品負責人和開發團隊，是整個敏捷團隊裡面非常重要的兩個角色。
至於團隊的促進者或是Scrum Master，在孟華專案管理協作平台ezteamwork裡叫做迭代管理者(Iteration Master)。這個角色顧名思義，就是促進整個團隊運作的一個角色，這個角色的任務，可以說是為了確保在整個執行過程、及團隊溝通是非常有效率地向前推進，這和一般瀑布式專案管理中的專案經理角色有所不同。
迭代管理
其次，迭代的執行過程中會有一個Daily Standup Meeting，也就是每天的站立會議。這裡用Standup是強調團隊成員是站立著開會，因為希望每一個會議是小而精簡，大家站著希望比較能夠聚焦、專注，所以Daily Standup Meeting 通常是個十五分鐘左右的小會議，最長不會超過三十分鐘。
最後，我們來談一談在一個迭代裡面要怎麼樣來進行管理。首先，在每個迭代的開始會有一個迭代的規劃，又叫做Iteration Planning，主要是根據Product Backlog裡面的所有待辦清單 (或工作項目)去做排序，排序優先的就會進入該迭代要執行的工作項目。
在這個會議之中，團隊成員建立微承諾 (Micro Commitment)，也就是說，每一天會議中，團隊成員接收新的指派工作項目或既有項目執行上的回饋時，代表是一個短時間內可以承諾或完成執行的。
接著，當一個迭代結束時，會做這個迭代的Demo，也就是展示迭代的成果。最後，會做一個迭代的檢討(Review)和回顧(Retro)，檢討和回顧中所產生的工作項目，會再回饋到新的迭代，如此滾動需求、持續回饋改善。
至於團隊的促進者或是Scrum Master，在孟華ezteamwork平台裡叫做迭代管理者(Iteration Master)。這個角色顧名思義，就是促進整個團隊運作的一個角色，這個角色的任務，可以說是為了確保在整個執行過程及團隊溝通是非常有效率地向前推進，這和一般瀑布式專案管理中的專案經理角色有所不同。
