敏捷一詞對於我們來講已經不再陌生，在業界已經成爲一種軟件開發活動的推薦模式。那爲什麼要敏捷？這個答案很多，每個開發者心中都有一個自己答案，其實答案本身並不重要，重要是思考的過程。這個問題也沒有一個標準答案，就像每個軟件開發男都有一個自己心中的女神，女神可能是不一樣的，女神是否相同並不重要。
言歸正傳，個人觀點如下。回答敏捷是什麼？爲什麼要敏捷？回答“爲什麼要敏捷”的前提是回答“敏捷是什麼”，因此首要任務是要先回答第一個問題，從敏捷技術的觀點看，核心是敏捷價值觀、敏捷價值觀外層爲敏捷管理，比如XP或者Scrum；最外層爲敏捷技術實踐，比如CI、TDD和結對編程等技術，從這個結構看最裏層是一種敏捷文化、中間層爲軟件開發過程管理方法，最外層爲具體技術實踐，因此敏捷運行核心要素是通過軟件開發過程管理方法連接內層敏捷價值觀和外層敏捷開發技術實踐，對外呈現出一種開發模式和方法。
其次回答第二個問題，首先要解決敏捷不可替換價值在哪裏？如果說敏捷是交付有價值的軟件產品，那麼非敏捷方式難道就不能交付有價值的軟件產品？這個推論站不住腳，我們同樣也可以使用非敏捷方法交付有價值的軟件產品，現在仍然有大量的軟件產品按照非敏捷的方式進行開發，同樣也在交付價值。在我看來，一個字可以回答“爲什麼要敏捷”，這個字在於“變”，我們需求的變化。在我看來，需求的變化有以下三種場景：
場景一，需求從用戶環節到開發環節，這個漫長的需求鏈條在傳遞過程中出現了關鍵信息丟失，導致軟件開發產品交付後，與用戶需求嚴重不一致，導致軟件重大改動、甚至重新設計；
場景二，用戶對於需求的描述定義不準確，導致軟件開發產品開發出現偏差，軟件產品交付後，需要軟件進行重大改動、甚至重新設計；
場景三，需求本身已經有了變化和位移，移動互聯網發展非常快，需求本身可能每天都在變化，即使你搞清楚了之前的需求，等你軟件產品交付後，該需求已經不成立或者有了重大變化和位移，也會導致軟件重大改動、甚至重新設計；
需求變化這麼快，需求有可能存在偏差，怎麼辦？解決方法，可以看看電影功夫中的片段，快，足夠的快，快得很抓住子彈，本着“天下功夫，無堅不破，唯快不破”的原則，提升我們軟件開發的速度，適應這種變化。怎麼能夠提升我們軟件開發的速度，
敏捷方法提供了2個解決途徑:
第一 提升人件，通過敏捷團隊運作，激發出每一隊員的最大潛能，以最大合力完成軟件產品開發。就拿敏捷中Scrum來說，Scrum的原始含義，就是橄欖球比賽對抗，要讓團隊最大力量集中起來，集中一點，取得突破。如何能夠激發出每個人的最大潛能，讓自己當老闆，讓自己成爲軟件產品的老闆，軟件產品就是我自己，通過自組織團隊，讓開發人員真正的當家作主，成爲軟件開發的主人，以此激發隊員的最大潛能；同時敏捷文化鼓勵隊員之間的技術交流和分享，在這種技術交流和分享過程中提升開發人員的自身水平和能力，達到個體戰鬥力的最大化。
第二 軟件開發過程提升，軟件開發過程包括需求分析、系統設計、編碼、測試、交付、部署、上線這些環節，要做到快速，就必須從多方面入手。
首先，需要把大需求拆分爲小需求、從一次完成大而全軟件系統交付轉換爲每次提供一個核心和關鍵功能最小軟件系統快速交付，及時獲取用戶反饋，這樣即使在需求環節出現偏差，也可以減低對於軟件產品開發影響，減小需求偏離度，提升軟件產品準確命中用戶需求要點的能力；
其次，需要提升整個軟件開發彈性，引入代碼走查、鼓勵重構、結對編碼和編碼風格調整這些舉措，讓軟件編碼具有彈性，可以讓軟件對於後續變化和需求快速響應；
再者，由於需求經常變化，隨時都會對於軟件進行改動，爲了保證軟件產品具備快速交付能力，必須通過持續構建來解決系統經常代碼改動對於軟件產品交付能力的影響，分散產品發佈帶來的風險；通過自動測試來進行迴歸測試、集成測試以及系統測試，通過機器測試來換取測試壓縮，解決人力測試無法滿足測試路徑快速覆蓋的場景，隨時具備軟件產品交付能力。
綜上所述，敏捷的核心要素在於快，通過人件和軟件開發融合發力，實現軟件開發過程“快”，以快來取得“準”，以“準”來破“變”，實現軟件產品價值成功交付