什麼是敏捷開發 (Agile)？
首先，我們先回顧一下古代的軟體工程與開發模式，在沒有敏捷以前，系統的開發週期往往很長，風險超高。怎麼說呢？以最常聽到的瀑布法開發模式 (Waterfall Model) 來看，一個產品的開發週期可以由以下幾個階段組成：
系統分析 (SA) > 設計 (SD) > 開發 (Dev) > 測試 (Test) > 發佈 (Market Release)
為了讓專案可以如期完成，前期需要花上許多時間進行這個假議題的規劃與設計，花這麼多時間是想要把可能犯錯的地方都仔細想過，好降低開發中的風險。那為什麼說是假議題呢？因為產品還沒上線，沒有人可以拍胸脯確保開發完成後，市場與消費者會願意買單付帳。假設這個開發週期需要 18 個月，我們仍舊無法保證一開始的市場需求在 18 個月後是否一樣存在與強烈！我們都知道世界變地很快，這些需求隨著時間變化也隨時都在改變，先撇開莫非定律與專案時程延誤這樣的肥皂劇，說穿了，在這假裝會準時的 18 個月開發週期裡，我們無時無刻都在承受風險！軟體開發掌握了太多我們不確定的因素，就像小丑走鋼索，搖搖欲墜。
適應變化的能力，比專案如期完成更重要
時程、資源、功能、品質
一個好的系統，時程、資源、功能與品質一樣重要，我認為沒有一定的解答，隨著變化及時調整比重是很重要的。RD 最不擅長回答 PM「做這個功能估計要多久？」，除了可愛的 PM，其他都是假的 (誤~)。畢竟我們都在做一件我們未曾做過的事，未曾開發過的新產品，要花多久時間除非做了才知道？所以才叫做估計！既然是「估」，那不準是理所當然的。再想想前面提到的 18 個月開發週期，真的很可笑！以人月神話這本書的專案時程規劃建議來看，一個健康的專案設計、開發、測試的時間分配比例如下：
哇，上圖有 1/3 的時間都在進行規劃與設計，假設 18 個月的開發週期，那可要花上半年進行規劃與設計。幾年前，我在工作上曾經與日本富士通 (Fujitsu 日本最大軟體製造商) 一同開發產品，還就真的花上半年時間進行設計，在沒有寫一行 Code 以前，把整的系統都在紙上先設計好，包含畫面、流程、訊息、測試案例、DB Schema 與 SQL Query 都已經寫下文件並審核完成 (話說不能寫程式真的很痛苦)。近百人經過半年嚴密的設計，那產品最後有沒有如期完成呢？你猜對了，一樣 GG！即使經驗豐富的架構師設想再周到，以使用者為優先的考量前提下，需求變更是必須的，沒有什麼不能改的。只是當時的開發模式不適合快速迭代與修正，日本富士通是非常注重品質，「Peopleware： 腦力密集產業的人才管理之道」這本書提到的開發團隊甚至有權利基於品質，延後產品上市的時間，或拒絕交付未達品質水準的產品到客戶手上。這件事情是真的，當時真的在品質堪慮的情況下 PM 直接打槍 (太有 Guts 了)，社長補刀再開槍，品質至上！
經歷如此傳統的瀑布法開發模式，我深深體會到專案風險發生的可怕，其實很多風險在開發過程就已經被「識別」，但傳統的開發觀念跟不上，還是以時程功能目標優先，如此只會讓風險藏得越來越深，直到最後一刻引爆，你懂 der.......
我想，我們需要一種產品開發模式，可以快速迭代，最好可以讓這些準備會發生的風險提早發生，好讓我們改變作戰策略，決定下一步棋的位子。唯有將產品開發風險進行切割，快速反饋市場需求，才能夠在快速變化的世界中生存，物競天擇、適者生存。先別說這個了，你聽過敏捷開發嗎？
起初像個變形蟲，快速改變、快速適應，最後蛻變為高等生物！
敏捷是一種精神、一種態度
今天不談 Scrum, XP (極限編程), Kanban (看板開發) 等等方法論與實踐手段，我們先思考一下敏捷的目的。雖然我們知道的敏捷常用在產品開發上，但是敏捷其實是一種精神，是一種工作態度，一種信念，甚至也可以用在生活當中。比如媽媽到市場買菜煮飯給你吃，可以一開始已經想好要採購的項目，到了市場隨著接觸菜價與質量等等因素，本來想買的青蔥貴改買洋蔥，豬肉賣相不好改買魚，燒的飯一樣好吃。好菜上桌，這時候你怎麼沒大喊「媽！你這是需求變更！」，因為燒的飯好吃，符合市場 (你的胃) 需求，達到目的。
一樣地，對於工程師來說，把心力放在最有價值的開發項目，打造優雅的軟體架構，快速適應功能需求並實現，像是擅長接受「需求變更」的變形蟲，透過 Hack 精神達到目的，這些過程都是敏捷的實踐。對於產品設計師來說，找出最重要與最迫切的功能，獲得市場反饋後，快速修改，產品重新定位，透過反覆迭代達到 PMF (Product-Market Fit)。這些遠比準時花上 18 個月開發產品，最後不符合市場預期來的友善多了。產品定位、功能與需求有沒有變化一點也不重要，重要的是找到對的事，然後把它做好！
敏捷最大的目的是創造成功的產品，而不是實現 Feature！
敏捷的實踐
概念有了，再來是方法。仿間蠻多敏捷開發導入顧問，同樣與往年的 CMMI 要價不斐，我沒有接觸過，也不知道效果好不好。台灣目前比較常聽到開發團隊採用 Scrum 開發模式，如果你不了解敏捷的根本精神，少了信念，導入敏捷走到最終只剩下形式，下場跟幾年前的 CMMI 一樣 (話說 CMMI v1.3 以後也趕流行加入了 Agile 的元素)，不知道為何而做？最終淪落到為了敏捷而敏捷，如果你既有的產品開發模式，已經可以快速適應市場變化，那麼你根本不需要導入什麼 Scrum，因為你已經走在正確的路上了，你只需要不斷的檢討與改善，不是嗎？
以敏捷常做的「站立會議」來說，站立會議主要的目的是快速溝通，用最有效率的方式掌握開發節奏，幫助我們隨時檢視有沒有違背敏捷的精神。如果站立會議變成只是交辦事項、殭屍會議、或者一日復一日的口述報告，那其實已經走偏了。好比 Scrum 中的 Sprint Plan，兩週的 Sprint 只是個建議，盲目的追求兩週的 Sprint，而無法在兩週後讓產品交付到客戶手上，那這樣的兩週一個 Sprint 沒有太大的意義，先想辦法先做到持續交付 (Continuous Delivery) 會更重要！沒辦法交付，就沒有市場反饋，你的 Sprint 只是瀑布模式的縮影，還不如叫做小瀑布開發模式會比較適合，一點也不敏捷。
遵循敏捷根本的精神與信念，比盲目追求敏捷的實踐更加重要！
期盼各位在錢燒完以前，可以找到對的事，然後做到最好！掰了.......