敏捷開發的精髓：如何透過本質實現靈活的開發流程

最近，社群對於敏捷開發的討論又掀起了一波熱潮。自從 2001 年敏捷宣言誕生以來，敏捷開發模式一直都是個擁戴與反對聲浪都不小的開發模式。幾乎每隔一段時間，社群就會展開一輪有關敏捷開發的討論。這些討論通常從抱怨敏捷的現狀開始，隨後會有支持者強調：「你討論的並不是敏捷的真正本質」。最終，這些討論常常得出一個結論：「問題不在敏捷，而在於錯誤的實踐方式。」

雖然說我們不是敏捷專家，但因為待過的團隊不算少，有號稱用敏捷但非常瀑布流的團隊，也有沒特別提敏捷但運作非常敏捷的團隊，因此從這些經驗中，也有一些對於敏捷的心得。

敏捷開發的核心原則：回歸敏捷宣言

談到敏捷開發，就不能不提 2001 年被提出的敏捷宣言。這個宣言是當初多位資深軟體工程師 (例如 Robert C. Martin) 共同提出的，該宣言的內容如下：

從該宣言又延伸出了 12 項「敏捷宣言背後的原則」，以及後續業界出現了各種實務方法 (例如 Scrum) 來實踐敏捷的開發精神。不過不幸的是，許多團隊在套用這些方法時，不知不覺就走偏了。

避免敏捷開發中的常見誤區

許多實踐敏捷開發的團隊經常落入「形式化」的陷阱。舉例來說，很多使用各類敏捷方法的團隊，經常有很多大大小小的會議。然而，敏捷背後的原則是要「經常交付可用的軟體」，如果長時間花在開會上，壓縮了能經常交付可用軟體的時間，就會變得與敏捷背後的原則牴觸。

又或者許多公司在導入流程與工具時，會很死地要求團隊必須要照著做，即使某些流程在落地後幾乎變得沒有意義，但仍是為了做而做。但敏捷宣言提到「個人與互動重於流程與工具」。

如果真的要做到敏捷，針對每個會議、流程與工具，應該要回到第一性原理思考，檢視其是否真的有意義，而不是死硬著要開某個浪費時間的會議，或者死硬著要求照做某個冗餘的流程。若你對第一性原理思考不熟悉，請參考這篇介紹：第一性原理思考。

正確的敏捷實踐：避免由上而下的控制

在許多會抱怨敏捷的文章中，經常會看到抱怨老闆由上而下的隕石。然而這種隕石或流星雨式的徵兆，似乎與「以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作」這個原則相抵處。

理論上，一個敏捷的團隊，要可以自己決定怎麼樣的方式運作 (ownership)。當發現問題，也應該自行間起責任來解決。舉例來說，假如團隊因為沒有寫測試，導致某個功能出問題上線後才發現。

比起是由上而下要求加上流程 (例如把寫測試這件事塞入流程中)，把如何解決交還給團隊決定，由團隊負責，會是更符合敏捷的做法。否則，當越來越多問題發生，就會越加越多東西，導致最後流程變得超級冗長，進而變得毫不敏捷。

敏捷開發與瀑布開發的對比

談到敏捷，就不能不談在敏捷之前業界主流的瀑布式開發 (waterfall)。所謂的瀑布式開發，是從需求，到設計，到實作，到測試，最後到部署與為運，一個階段往下一個階段，就像瀑布一樣開發。

過往業界對瀑布式開發有許多批評，包含瀑布式開發這種分階段的方式，極度缺乏彈性。又或者瀑布式開發到測試階段已經很後面，所以當測到問題後前面整段重來的成本很高。

然而，眾多批評當中，最嚴重的問題會是瀑布式開發到上線後已經很晚，要實際收到使用者回饋也會很晚。這將導致一個嚴重的問題，那就是經歷各個階段後、花很多時間後，才發現做出對使用者沒價值的成果，導致前面的大量投入全部白費。

但敏捷的核心是追求「滿足客戶需求」，是追求更頻繁的回饋迴圈 (feedback loop)，這能避免做出對使用無價值的成果。

使用者很多時候，其實沒辦法說清楚自己真正想要什麼。所以單純的前期使用者訪談，雖然能做為方向的指引，但很多時候不會是馬上就能精準抓對方向。因此更有效的方法，是根據需求做出原型，接著給使用者用用看，同時蒐集回饋來迭代。

很常見的狀況，是使用者訪談後，根據最開始蒐集到的需求後做出的原型，拿回去給使用者測試後，使用者說這不是自己要的。雖然覺得很無言，但在敏捷的做法下，驗證到真正的需求成本會遠小於瀑布的做法。

然而，如果沒有不斷驗證、不斷迭代、不斷精練對使用者需求的理解，就代表跟敏捷的精髓有所偏離。

從本質出發自然就敏捷

最後，如開頭提到的，過去我們曾經待過，在開發模式上完全沒提敏捷，但是實際運作起來高度敏捷的團隊。之所以能做到這樣，是因為在團隊運作的本質上，與敏捷的原則不謀而合。

因此，推薦比起導入各種方法或流程，不如回到原則面來看敏捷的本質。拋開那些方法與工具，直指核心地問自己所在的團隊：

是否做到「及早並持續地交付有價值的軟體」？
是否做到「滿足客戶需求」？
是否做到「招募積極的成員到團隊，並給予所需的環境與支援」？
是否做到「用高效的方式溝通」？
是否做到「持續追求優越的技術與優良的設計」？
是否做到「給予團隊自主」？
是否做到「定期自省如何更有效率，並據之適當地調整與修正自己的行為」？

當團隊對於上面這些問題的回答都是肯定的，那即使不導入 Scrum 或 Kanban 等方法，也能夠跑得很敏捷。

最後，在我們過去的經驗中，能良好體現敏捷本質的團隊成員，多半對組織脈絡有一定的掌握，知道組織的架構、知道不同產品之間的定義與上下游關係，並能透過系統性的思考，把這些資訊整合起來。當能夠做到這樣，將能夠更容易地實踐敏捷。