我們理解東西習慣從已知連線未知，首先我們來對比一下。我們最先了解到的是瀑布模型，那麼它就是不敏捷的。瀑布開發模式把開發分成一系列階段，如需求、設計、開發、測試，就像下圖它畫出來的，看起來很像瀑布，所以叫瀑布開發。
問題是需求的交付難道不都是要經歷這些階段嗎？
瀑布開發的本質問題並不是階段，而是批次。需求批次地在一起進行設計，然後是批次地開發，批次地測試、交付等等。批次有什麼問題? 首先，批次讓價值交付延遲，所有需求在最後的階段才能交付，價值交付比較晚。Google執行董事長施密特提出過反摩爾定律，表述為：“如果18個月之後我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入。”價值的交付時間將直接影響收入。
敏捷的目標1：
敏捷開發有第一個目標就是更快的交付價值，這裡的快指的不是絕對速度，而是更早的交付。
在專案結束的時候，一定是對產品和專案的知識理解最充分的時候。這顯而易見，我們在專案程式中積累了知識，特別是當向使用者交付產品後，使用者反饋：“我要的不是這個啊，我說的明明是……”，這時候你瞬間狂漲知識，並感嘆道“你怎麼不早說呢？”。這中間可能有溝通問題，但更多可能的是，使用者這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連使用者是誰也未必能準確地定義。產品和業務開發本來就是一個探索的過程，開始時一定是最無知的時刻。
專案中的大部分決策也一定是在專案開始的時刻做出的，這將有一個重大的悖論，在最無知的時刻，做出了最重要而且是絕大部分的決策，並把它作為隨後執行的依據。面對不確定的技術、市場環境，傳統開發模式已無法適應要求，悖論越發突出。
敏捷開發將透過迭代應對這一問題，只做初始決策，定大致的方向。透過市場反饋不斷修正對產品的認知，增量的決策和調整。
敏捷的目標2：
產品開發過程中，技術環境、市場環境、競品策略、團隊認知都會發生變化。面對變化的環境，我們必須承認自己的無知，在開發過程主動有效地學習，不斷地汲取反饋，靈活地調整。這也是敏捷的第二個業務目標，有效學習和靈活響應變化。
敏捷過程
敏捷開發是一種以人為核心，以迭代方式循序漸進開發的方法，其軟體開發的過程稱為“敏捷過程”。
在這一過程中，軟體專案的構建被切分成多個子專案，各個子專案的成功都經過測試，具備整合和可執行的特徵。
在2001年年初，一些業界專家成立了敏捷聯盟，起草了敏捷軟體開發宣言。該宣言針對一些企業的現狀，提出了讓軟體開發團隊具有快速工作、快速應變能力的若干價值觀和原則，其中包括4個簡單的價值觀以及敏捷開發方法應遵循的12條原則。
敏捷開發的價值觀
1.個人和互動勝過過程和工具。
2.可以執行的軟體勝過面面俱到的文件。
3.客戶合作勝過合同談判。
4.響應變化勝過遵循計劃。
敏捷開發應遵循的12條原則
1.透過儘早的、不斷地提交有價值的軟體來使客戶滿意。
2.即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
3.以從幾個星期到幾個月為週期，儘快、不斷地提交可執行的軟體。
4.在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
5.以積極向上的員工為中心，建立專案組，給他們提供所需的環境和支援，並對他們的工作予以充分的信任。
6.在團隊內部，最有效、效率最高的傳遞資訊的方法，就是面對面的交流。
7.測量專案進展的首要依據是可執行軟體。
8.敏捷過程提倡可持續的開發，責任人、開發者和使用者應該為能夠保持一個長期的、恆定的開發速度而努力。
9.時刻關注技術上的精益求精和好的設計，以增強敏捷能力。
10.簡單是最根本的。
11.最好的構架、需求和設計出於自組織的團隊。
12.每隔一定時間，團隊要反省如何才能更有效地工作，然後相應地調整自己的行為。
敏捷組織提出的敏捷開發模型的整體框架主要有三個：
Scrum、XP（eXtreme Programming）、OpenUP 這3個敏捷實踐。
敏捷開發的原則
1.凝聚人的力量，緊密協（合）作。包括業務負責人、開發團隊、客戶、管理者之間的關係，所有這些關係在以前都是造成專案危機的原因之一，那麼，在敏捷時代，我們需要這些角色 緊密合作，最大限度的發揮各個角色的力量.
2.聚焦客戶價值，消除浪費（如何聚焦使用者價值，即頻繁的交付使用者可工作的軟體，快速收到使用者反饋）
敏捷團隊運作機制
1.一個團隊有自己的
待辦事項，對
待辦事項進行拆小。
2.按客戶價值進行優先順序排序，產品經理負責價值排序。
3.小而穩定，跨職能團隊。
4.多個團隊松耦合（依賴性比較低），對齊迭代時間和戰略目標。
關鍵的團隊角色
產品負責人
Scrum主管（流程主管）
開發團隊
產品負責人（Product Owner）
負責管理產品backlog（
待辦事項）的唯一負責人
代表客戶/專案如責任人
定義產品的所有特性
負責產品的投入產出
負責最大化產品和開發團隊工作的價值
Scrum Master（流程主管）
起到教練的職責，領導團隊完成Scrum的實踐以及體現其價值。
排除團隊遇到的困難，使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力。
確保團隊能勝任其工作，並保持高效的生產率。
保護團隊不受到外來無端影響
關鍵的團隊活動
每日例會：每日5分鐘左右的一個簡單例會，儘可能多的開發人員參與進來對緊要問題的討論。
評審會：需要在迭代週期的最後一天召開，1個小時左右就可以了，需要客戶出席，如果客戶不能出席，則需要產品經理出席
迭代回顧會：迭代回顧會是在每個迭代結束時進行，總結工作中的經驗和教訓，時間維持在30-60分鐘內，整個團隊都需要參加（Scrum
Master、Product
Owner、開發團隊以及客戶）。迭代回顧會包括兩部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含團隊是否完成了迭代目標，收集並評審迭代度量指標（包括速率、迭代燃盡圖、迭代計劃故事和實際完成故事、計劃釋出日期與實際釋出日期、客戶滿意度、團隊滿意度、生產環境Bug數、生產Bug解決時間、使用者故事等）。定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下一個迭代實現）？