什麼是敏捷
敏捷是一套關於軟體開發過程的思想、方法和工具體系，透過遵循一系列價值觀和核心原則，並藉助由此演化出的若干實踐方法和工具，實現儘早和持續地交付有價值的軟體，從而幫助客戶獲得競爭優勢。
可見，敏捷的
終極目標是幫助客戶在競爭中獲取優勢，贏得先機
，其
根本途徑是提升響應力
，即
儘早和持續地交付有價值的軟體
。
敏捷的體系架構
為了確保實施過程不走樣，
敏捷推出了12項關鍵原則，框定了一些關鍵要求
，如對最高目標的強調，對響應需求變化態度的強調，和對業務人員和開發人員必須在一起的要求等。
敏捷同時透過6句宣言宣告了其價值觀，便於實施人員在決策時做出正確判斷
。
基於敏捷的原則和價值觀，在實踐中形成了Scrum、Kanban等很多卓有成效的方法，還湧現了很多工具來幫助我們正確有效地利用這些方法。
從道、法、術的角度來看，有人將敏捷6句宣言認為是敏捷的道，將敏捷的12項原則認為是敏捷的法，將Scrum、Kanban等敏捷方法認為是敏捷的術。
敏捷的道、法、術體系
個人認為，敏捷的6句宣言，還不夠級別稱之為敏捷的“道”，更像是敏捷這棵體系大樹的“剪刀”，可以用來“修修剪剪”，讓敏捷之樹健康成長，不至於“長歪”。
敏捷思想的橫空出世，是為了應對軟體領域的複雜和市場的瞬息萬變形成的“勢”，敏捷透過響應力來提出破解之道，一切形成響應力的背後的那些樸素的思想才是敏捷的“道”。這些思想似乎就在那裡，但又不好言說，隱約之中似乎有“快速、有效且持續地行動-反饋-調整”這麼一條，但甚是不便概括。
敏捷的勢、道、法、術、器和衡體系
一般來說，敏捷的公式如下：
敏捷
=
價值觀
+
原則
+
一系列符合價值觀和原則的方法
本文再給進一步擴充套件一下：
敏捷
=
原理
+
價值觀
+
原則
+
一系列符合價值觀和原則的方法
敏捷宣言
前面說了半天敏捷宣言和價值觀，這裡再把其內容補充一下。
敏捷軟體開發宣言
雖然宣言的內容比較“虛”，沒有太多具體的方法，但是也難得地看到束縛軟體研發的幾道枷鎖被明確指出，並提出了鬆綁之道，很有幾分“解放思想，實事求是”的意思。
敏捷原則
敏捷的價值觀很“虛”，為了更好地指導大家實踐，敏捷宣言還提出了12條原則。
敏捷12條開發原則
有了敏捷的12條原則，就可以為我們編出一個虛擬的“框”，為我們定義了一些行事規範，不至於走偏。
敏捷的原理
現在，我們把包含目標、價值觀和原則的整個敏捷思想體系繪製在一張圖上，嘗試解構一下敏捷思想背後的原理，以更好地理解其脈絡。
敏捷的原理
敏捷的原理
通俗地說，
敏捷還是為了實現又對、又快、又好這三個目標
，為了同時實現這些目標，我們甚至可以自行腦補出一些做法，比如把需求打散，賦予優先順序，分批交付，加強反饋，減少浪費等，再可以擴展出更多的具體些的實施要點，而把這些東西系統地梳理出來，不就是敏捷嗎？我們也可以從這個角度更好地理解和實施敏捷。
所以，我們試著找一下敏捷行事規則裡的那些關鍵詞，適當地彙總和抽象一下，就可以發現這麼一些詞彙，有
拆分
、
反饋
、
儘早
、
並行
、
有用
等，這些似乎都與試錯和提升效能有關，這是不是就是敏捷背後的原理呢？
敏捷的侷限性
敏捷並不是軟體開發專案的銀彈，敏捷至少具有如下侷限性：
專案範圍、所需資源、交付日期均難以嚴格確定
對團隊成員的技能要求較高
需要業務、產品、開發、測試等相關資源持續全情地投入
迭代交付的方式對產品和架構的一致性帶來挑戰
過程中還可能帶來額外的架構重構和迴歸測試工作量
敏捷的選型
敏捷的兩種主流方法是Scrum和Kanban。
Scrum使用固定時長的迭代，專注於更快地完成更多的工作，應用門檻相對較低。
Kanban專注於過程改進，並不要求固定迭代時長，而是利用Little‘s Law原理，透過最佳化過程瓶頸和嚴格限制在製品數量（WIP），實現提升吞吐量（TP）和縮短交付週期（CT）。
瓶頸和太多的在製品導致週期時間延長
Cynefin框架是處理任何情況的通用模型，根據該框架，我們在面對問題時一般處於以下五個狀態：
簡單（Simple）：容易瞭解，並知道如何應對
棘手（Complicated）：容易瞭解，但是需要專業知識來應對
費解（Complex）：未知領域或情況，需要開發新的知識和專業知識來應對
混亂（Chaotic）：不可知，超出我們的學習能力，需要創新實踐
錯亂（Disordered）：我們不知道我們在做什麼
Cynefin框架3D增強版
通常用改編的Stacey Matrix來進行專案過程選型：
需求清楚、方案明確的
簡單專案推薦使用瀑布式（Waterful）管理
需求明確、方案不太確定的
棘手專案推薦採用敏捷（Agile）管理
需求不太清晰、實現難度不高的
燒腦專案儘量採用瀑布式（Waterful）管理
需求不清楚、方案不明確的
複雜專案推薦採用Scrum管理
需求和方案均高度未知的
混沌專案推薦採用Kanban管理
利用Stacey Matrix進行軟體過程選型
敏捷的實施
除了選型之外，敏捷最難的就是實施落地了。和微服務、中臺、DDD、DevOps等很多行業概念一樣，在具體實施過程中，很容易就“把經念歪”了。
現實中，受制於環境、組織等因素影響，尤其是人員思想認識和技能水平，很多敏捷做得徒有其形，甚至只剩每日站會這個“皮毛”了，而就連站會也常常開不好。
究其原因，可能很大一部分原因要歸結到“人”上來，和人的思想和能力有很大關係，不知道您是否同意這個觀點呢？
人常說，英雄所見略同，一幫牛逼的人在一起，思想認識基本可以達到“心有靈犀一點通”，根本不需要過多的資訊同步過程。而敏捷最重要的就是對團隊和人員的要求，所以，推行敏捷，首先要解決的就是人的問題，要轉變團隊人員的思想，提升團隊成員的技能水平和敏捷框架應用能力。
尤其重要的是做好持續改進，做好定期反省和調整行為這一項，提升團隊成員的積極性和參與度，讓大家進入那種一心做事的狀態，才能做到形神兼備，真正發揮出敏捷的威力。
