文章目錄
以我了解的敏捷式開發是不會有 PM 這種角色，比較接近的可能是 PO(Product Owner) 或是Scrum Master，但是這種外國人的東西一到了台灣，不免俗的就會開始本土化！我知道許多 PM 同行在這敏捷開發的風氣下，有時像是PO，有時又像是UI/UX，因為要做Scrum Master 又太像TPM…這左右為難的狀況下，太容易變成被工程師撻伐的對象，而自己也會不知如何是好。
過去我合作的工程師們，有些是交辦給在在左岸的團隊，而更多時候台灣本土工程師大部分會因為對自己的工作範圍有不同的了解，願意做的事情也就相當不同。當然公司文化風氣也會不同，而造就不同的開發環境。
專案開發 V.S 敏捷開發，工程師心態大不同
傳統的瀑布或迷你瀑布式開發，會有SA(系統分析)與SD(系統設計)。
SA是負責與使用者溝通，將使用者的需求設計成一篇一篇的設計文件，而通常SD會是團隊中的資深工程師來擔任。SD會需要定義專案使用的技術並且分析設計除了基本的 CRUD（新增、檢視、更新、刪除這類的基本功能）以外，其他比較需要集中火力弄清楚的東西，例如資料庫平衡載、搜尋效率、資安保護甚至是資料移轉的步驟等等。
而當以上的方向都定了以後，才是工程師進場按圖施工。
而敏捷開發的則是另一回事了，經典的敏捷會要求所有的工程師、使用者齊聚一堂，讓工程師自行理解使用者需求，並且自己跟使用者提案，自行進行系統設計後，自己實作出來！
這個狀況就好像是：
你打算裝潢你家，傳統的方式是找設計師，並且告訴室內設計師你想要的風格、要注意的地方以及預算，室內設計師依照你的需求進行設計、材料選擇，並用精美的3D渲染圖跟你確認完需求，然後幫你找好水電、泥作、木工，並且明確告知你工期，還幫你監工。
上面的狀況就像是傳統的專案開發，這聽起來不錯，但是室內設計師也有雷的，就算是好的室內設計事務所，你也可以了解他的報價肯定會比你找統包或是自己找工班來得貴！
敏捷式開發就像是你自己就是PO (Product Owner), 你大致上清楚你的需求，每一天找來水電、泥作、木工，甚至是布料廠商、地板廠商、傢俱廠商來跟你一起開StandUp Meeting, 你跟他們講解完需求後，『希望』他們可以自己推派出Scrum Master負責協調並排出 Sprint！
這你用想的就知道不可能！最少要有一個統包當Scrum Master吧！更不用說，如果這些裝潢師傅是你要固定付他們月薪，也許可以保證他把這個專案當作第一優先，每次會議都會出席，但這樣成本很高。因為身為使用者的甲方，你並不具有設計師專業，要怎麼知道應該何時找誰加入這個專案才是最佳時機？如果你是依照實際施工小時計費，那麼他們為何要花時間跟彼此溝通，每天跟你彙報進度呢？
這就是在台灣進行敏捷式開發最困難的部分！
並不是每一個工程師都有意願並且有能力了解平行單位的專業，或是依照各單位可以的時程來進行施作項目的調配，最可怕的不是專案延期，而是已經習慣有統包或是設計師發案的各家裝潢師傅，他們並不認為他的工作內容包含了跟其他平行單位的溝通，所以會不停的抱怨你找他們參加不必要的會議、無法互相溝通取得施工的共識。甩鍋不做還是小事，最怕的是他們為結案硬做，把你家弄得亂七八糟無法收拾。
把敏捷當迷你瀑布做
敏捷還是有許多好處的，像是強迫上版、依照開發進度靈活調整Sptint等等，可以杜絕傳統瀑布式開發最後一秒才開獎，或對於一直遲滯不前的功能沒有有效管理追蹤的方法等等。所以我的方式就是結合傳統做法再加上敏捷的好處，並且一樣可以用Jira（或任何你喜歡的方式）使用看板來實作。
Sprint 0 計劃階段
在計劃階段，我會依照功能的獨立性規劃，例如在一個產品的開發案中，會員註冊肯定是獨立又是產品操作的第一步驟。UI方面也不會太複雜。 所以我會在Sprint0規劃出至少前三個Sprint要做的功能項目。
並且針對Sprint 1 的功能進行UI/UX 設計，設定好GA等等的相關基礎設定，並且要求資深工程師完成開發環境建立（如Git與Jira的串連、CI/CD、資料庫配置等等）同時在這個階段，需要參與的人員僅有主要的SA角色（通常是我）、主要的使用者以及SD人員。
Sprint0不一定需要是兩週，端看整個專案的大小。但他的結束時必定是要有基本的技術架構、準備好開發環境，並且製作好開發準則準備要發給參與開發的人員。若有視覺設計人員加入時，有時Sprint0會需要加長，因為設計人員通常無法於兩週內搞定整體視覺＋完成Sprint1功能的設計與切版。
Sprint 1 進入開發
Sprint 1 就是正式開始進入開發，此時會將Sprint0 規劃要開發的功能，將其前後端的票(Ticket)開好，我會在Sprint day1 對團隊進行資料庫架構說明、UI說明、以及整個開發流程的預期進行說明。Sprint1不宜排得太滿，因為大家對於開發流程與環境可能尚不熟悉。
接著在 Sprint1 的開發期，SA就應要著手設計Sprint2的功能並且盡快交付給視覺設計人員，為一樣，在Sprint1 結束前，視覺設計人員應完成設計與切版。並且SD在這時刻除了要回覆開發人員與環境、開發準則的相關問題，還需要進行Sprint2關鍵技術的研究與安排。
我通常一個Sprint會排兩週，並且在第二週開始時進行任務調整。真的做不完的就拉到下一個Sprint，以確保Sprint結束前所有的任務都是可以上版的。
此時的參與人員才會真正的包含開發工程師，而QA可以不需要這時候全程參與，只需要了解測試的流程以及Jira 單上的流程即可。
Sprint2 循環開始
同樣的，Sprint2 就是要開發 Sprint1 中 SA 規劃的新功能，理論上來說，如果上一個Sprint原始規劃的任務有30%以上必須拖到這個Sprint才能做，就代表PM需要重新調整分配的量跟理解。而 Sprint2 就要開始請 QA 測試 Sprint1 完成的功能，如果有需要修改的地方，票就開在Sprint2， PM 再依照嚴重程度決定要這個Sprint修還是下一個。
如上所說，Sprint2 時 SA 也應該要進行 Sprint3 的功能設計，並交付給視覺設計。通常我都會在Sprint0–1盡量多規劃完功能，避免視覺人員太趕。有時如果太趕，也可以切版交給前端。
接下來的循環就是依照這個循環進行，每一個Sprint都要測試前一個Sprint上版的內容，因為有CI/CD的關係，QA若做完上一個衝刺的測試，也能即時測試當前的衝刺的內容，以確保每個人的工作都是滿檔的，不會有浪費。
要注意這邊的SA&SD的工作內容，與傳統的開發方法類似，只是切成小塊，並且保留彈性可以時時修正。這樣的方式我已經測試過很多不同的公司/對外產品或內部管理系統開發都適用。同時不會對無法適應的工程師造成太多困擾，也能彈性的適應很想高度參與的工程師。
我建議(經由合作過的工程師說:一定要保留!!!)還是要保留敏捷中的StandUp Meeting, 並且邀請使用者或老闆一同參與，開發成員每天都參加，而老闆或使用者一週參加一次也行。有時我甚至會利用週會的時間，報告專案進度以外，也進行功能設計確認，這樣會增加工程師的安全感，讓他們知道他們做的的確就是老闆要的！
敏捷愉快！
