敏捷開發（Agile Development）是一種軟體開發方法，旨在使團隊能夠快速、靈活地進行軟體開發，並以客戶為中心。它是基於敏捷軟體開發宣言的一組原則和指南，該宣言旨在使軟件開發能夠更快速、更可靠地滿足客戶需求。
敏捷開發的基本概念包括迭代、演示、專業團隊、自我管理和自我組織。它強調了透過不斷的小步驟來進行軟件開發，並通過專業團隊的自我管理和自我組織來實現這一目標。
敏捷開發的目的是提高軟件開發的效率和品質，並使團隊能夠快速應對業務需求的變化。它通過減少溝通成本、提高團隊協作效率、加快軟件上市時間等方式實現這一目的。
點我免費領取全端開發學習地圖！
敏捷模型
敏捷模型則假設使用者並不清楚他們想要什麼，強調的是如何挖掘「使用者的需求與體驗」。因此，敏捷模型講究不斷收取客戶回饋、分析結果，並進行優化。許多新創公司都會採用這一種模式來開發產品。
「敏捷模型」之所以能夠盛行，有一個重要原因，就是佈署軟體產品（尤其是網路應用程式）所需要的成本與時間大量降低了。所以一個產品可以不斷被優化，短時間內就能把數個不同的版本推進市場。
產品如何不斷的更新、優化？來看看一個我們熟悉的的例子：Facebook。
2004 年，這是 Facebook 剛推出時的個人專頁。
2005 年，除了介面的改良，Facebook 將「The」拿掉了，簡化並加深了品牌的形象。有興趣的人可以去看「The Social Network」這部電影了解 Facebook 品牌的故事。
2008 年，Facebook 在個人專頁上推出塗鴉牆 ( Wall ) 功能，推動社交圈子的互動。
2009 年，Facebook 了解到使用者並不想將塗鴉牆上的訊息分享給所有人知道，於是推出容易操作與使用的「隱私和安全設定」。
2011 年，Facebook 了解到圖片的重要性，注重提升圖片在個人專頁的展示。
2012 Facebook 推出時間線 ( Timeline ) 功能，讓你回顧過往的節慶與紀念日。
資料與圖片來源：Time.com
當然，Facebook 演進至今，還添加了許多重要功能如：按讚、分享、通知。但從一個簡單的個人頁面演進至今，有一個不變的定律：功能之所以有進步空間，正是因為客戶的需求也會演進，所以開發者需要不斷「優化」與「調適」。
敏捷模型如何調適？
敏捷模型之所以叫敏捷，就是「縮短」系統開發生命週期和「縮小」開發內容，使得在「較短時間」內能夠推出讓使用者「使用」的軟體產品；因此，敏捷模型會把軟體產品區分成不同功能，逐一推出測試，並根據測試後得到的數據「調適」軟體產品，修正舊的功能之餘也追加新的功能。
敏捷模型的演進與全端開發團隊
如上所述，敏捷模型可以將軟體產品切割成不同的功能區塊，依序交由團隊開發進行開發。然而隨著開發工具的進步和專案管理技巧的日漸成熟，敏捷模型如今已演進成能將功能區塊分配給不同團隊「同時」進行開發、設計、測試。
能夠有此突破，是因為參與的團隊變成了「全端團隊 (full stack team)」——也就是說，專案團隊有從規劃、設計、到開發的能力。這不是代表公司要同時建立好多個完整的團隊，而是指一個具備多項能力的團隊能夠同時參與產品的多個開發階段。這樣，資源的利用才更充份、也更有彈性。
講到這裡，你可能會好奇是哪個聰明又有勇氣的人提出「敏捷開發」這個新流程？我們想提出一個重要的概念，就是敏捷開發不只是一個流程，更不是一些工具或是特定的工作模式。「敏捷 (agile)」在一開始其實是一群工程師針對產品開發所希望建立並宣揚的一個精神。
2001 年，一群軟體開發者在美國猶他州雪鳥的滑雪聖地聚集一塊，討論軟體開發上面臨的問題。他們認為，過往的管理方式流於缺乏彈性的制式流程，讓開發者常因無法滿足僵化的時間要求而受挫，開發出的產品也不易符合變動的市場需求。
因此，這群人組成「敏捷聯盟 (The Agile Alliance)」，發布敏捷軟體開發宣言 (Manifesto for Agile Software Development)，希望在互相信任與尊重的基礎下，建立並協作一個讓大家能發揮工作價值、將產品潛力發揮到最大的開發模型。
敏捷的四大理念
敏捷宣言包含四大理念：
- 個人與互動 重於 流程與工具
- 可用的軟體 重於 詳盡的文件
- 與客戶合作 重於 合約協商
- 回應變化 重於 遵循計劃
這裡我們來深入看看這四大理念背後的意義：
個人與互動 重於 流程與工具
傳統產品開發模式傳承自工業時代的生產模式：透過機器（工具）與流程的安排，大量製造產品，而每個人只要像螺絲釘一樣負責特定崗位上的工作。流程與工具固然重要，但是敏捷精神更強調個人能力的發揮，以及如何有效地與他人合作。
可用的軟體 重於 詳盡的文件
良好的文件可以幫助人們瞭解如何開發與使用產品，但是敏捷精神強調團隊是否能開發出更有價值的產品。所以相較於花時間撰寫一字不漏的文件，敏捷精神引導團隊多花時間來優化產品。
與客戶合作 重於 合約協商
在客戶與開發團隊之間的合作裡，詳細的合約可以讓開發團隊明確收到客戶列出的需求，避免責任與期待不清楚。但敏捷精神強調與使用者或客戶共同合作，以挖掘出客戶更深層的需求，而不是糾結於合約的細節。
回應變化 重於 遵循計劃
有完善的計劃很好，但是敏捷精神認為，能因應變化進而調整的計劃才更有價值。
十二項原則
在四大理念之下，敏捷宣言同時也定義了以下 12 項原則來實踐敏捷精神：
- 我們最重要的目標，是透過儘早及持續不斷發布有價值的軟體，以滿足客戶的需求。
- 即便在開發晚期，也歡迎需求變化。敏捷流程可因應產品需求改變去即時調整，如此才能增進客戶的競爭優勢。
- 發布可用軟體的頻率可從數月縮短到數週，週期是越短越好。
- 業務人員必須與開發者一起工作，才能確保團隊成員對產品需求有共識。
- 以積極的成員為核心建立起開發團隊，並給予每個成員充分的資源去發揮潛力，相信你的隊友能支持彼此完成專案。
- 面對面談永遠是團隊內最有成效且最有效率的溝通方式。
- 「可運作的產品」是衡量專案進度的最佳依據。
- 敏捷強調迭代開發，產品負責人、開發者與使用者應當能維持穩定的產品開發週期。
- 持續追求卓越的技術與良好的設計是提升敏捷的不二法門。
- 簡潔是必須的，團隊需掌握精簡工作量的藝術。
- 一個自我管理的團隊才能做出最接近市場需求的產品架構與設計。
- 團隊應定期反思如何提高成效，並以此為據去調整團隊合作模式。
但該如何實踐？
敏捷宣言所提供的只是一種精神，並沒有定義明確的執行方法。雖然敏捷宣言於 2001 年才問世，但其實在此之前，敏捷的概念早已存在。
而在過去的十多年裡，有許多標榜符合「敏捷精神」的產品開發的管理方法也已一一面世。我們之後會介紹的 Kanban 與 Scrum 就是其中的典範。
不同敏捷開發方法並沒有高下優劣之分，某個方法適不適合你的團隊，端看團隊成員之間的合作模式以及專案性質。關於不同方法之間的差異，我們在 Kanban 與 Scrum 章節會更詳細說明。
要成為夠「敏捷」的開發團隊，除了運用敏捷精神進行決策外，更重要的是這個團隊要能持續自我調適，找到適合自己獨特的團隊合作與管理方法。
敏捷的迷思
迷思1：敏捷是一種特定的開發方法
敏捷只是一種精神，有許多方法可以實踐敏捷精神，但更重要的是一個團隊是否能夠不斷調適，找到最適合自己的方法。
迷思 2：敏捷的最重要的點只在於「快」
「快」只是實踐敏捷精神的結果，重點在於團隊是否能具備面對變化以及提升產品品質的調適能力。同樣重要的，就是要客戶與開發團隊都以使用者需求為首要目標，開發有價值的產品。
迷思 3：敏捷開發代表自由發揮臨場應變，沒有管理計劃
敏捷精神注重執行計劃的「彈性」，而非否定管理或計劃的重要性。
迷思 4：敏捷開發不用寫文件紀錄
有助於闡述產品價值、開發原則、重要抉擇的紀錄文件仍是必須的。
軟體企業面臨的挑戰
過去，產品的生命週期非常長，從規劃、分析、研發設計到產品開發，可能就要花上數年的時間，而一款產品可能可以在市場上存活 10 年甚至更久。但慢慢地，人們開始發現，不到 5 年的年輕產品的獲利，在企業中占的比重越來越高。
軟體開發商要能在這個戰國時代脫穎而出，就必須能夠：
- 打造使用者真正需要的產品
- 快速搜集使用者的回饋，然後設計出更好的版本並發布
- 提高開發效率、降低成本
這迫使企業去思考：除了提高產品品質、降低成本、差異化之外，要如何創造產品開發的「速度」與「彈性」，以獲得在市場上的競爭優勢。
這個背景環境，就是造成「敏捷開發」之所以流行的原因。
新競爭環境帶來新的生存模式
有別於傳統的「線性生產」與「專業分工」產品開發方式，許多大企業像是佳能（Canon）、本田汽車（Honda）、富士全錄（Fuji Xeror）開始嘗試用不同的管理方式開發新產品。
他們挑選出一支負責新產品開發的團隊，其團隊成員來自不同的專業背景。企業給予這支團隊極為困難的目標與挑戰，譬如生產「高品質、低油耗、低成本」的全新房車，但同時也給予足夠的空間（極少的管理限制）讓他們可以盡情發揮創新能力。
這樣的管理方式有以下幾個特性：
1. 與生俱來的不確定性
在專案啟動的時候，企業只會給予策略方向與遠大的目標，至於要如何達成目標、產品細節為何等問題，都要靠開發團隊自己去摸索。
2. 自我組織的開發團隊
甚至，開發團隊內部的分工方式，也要靠團隊自己去摸索，因為分工的方式可能會因為產品性質、開發方式而有所變動。
3. 重疊的開發週期
為了在有限的時間之內達到目標，在團隊初步規劃的時候，就必須嘗試投入下一步的分析、研發設計與製造，才能驗證產品的可行性。同時也不會就此停止規劃，團隊將持續探索新的可能、收集回饋，進一步改善產品規劃。
4. 更深入、更多元的學習機會
為了解決困難問題，團隊成員會更願意分享自己的知識，同時，也學習來自不同專業領域的知識。如此一來，更可能激盪出不一樣的想法。
5. 採用調適性的管理
為了讓開發團隊能發揮最大潛力，企業也採取不同的管理方式，像是
- 創造開放的工作環境
- 鼓勵工程師走出辦公室與客戶交流
- 建立以團隊為基礎的獎勵方式
- 容忍錯誤的發生
6. 知識的轉移
除了開發團隊內有不同層級、不同專業間知識交流外，開發團隊所累積起來的知識，也會轉移並影響到企業內部的其他團隊，帶動企業的成長。
不斷優化才是王道
在瞬息萬變的今天，已經沒有所謂完美的產品，只有不斷追求完美的產品。唯有以使用者為中心，隨時自我調適的敏捷開發團隊才能成就卓越。
