我們理解東西習慣從已知連線未知，首先我們來對比一下。我們最先了解到的是瀑布模型，那麼它就是不敏捷的。瀑布開發模式把開發分成一系列階段，如需求、設計、開發、測試，就像下圖它畫出來的，看起來很像瀑布，所以叫瀑布開發。
問題是需求的交付難道不都是要經歷這些階段嗎？
瀑布開發的本質問題並不是階段，而是批量。需求批量地在一起進行設計，然後是批量地開發，批量地測試、交付等等。批量有什麼問題? 首先，批量讓價值交付延遲，所有需求在最後的階段才能交付，價值交付比較晚。google執行董事長施密特提出過反摩爾定律，表述為：「如果18個月之後我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入。」價值的交付時間將直接影響收入。
敏捷開發有第乙個目標就是更快的交付價值，這裡的快指的不是絕對速度，而是更早的交付。
在專案結束的時候，一定是對產品和專案的知識理解最充分的時候。這顯而易見，我們在專案程序中積累了知識，特別是當向使用者交付產品後，使用者反饋：「我要的不是這個啊，我說的明明是……」，這時候你瞬間狂漲知識，並感嘆道「你怎麼不早說呢？」。這中間可能有溝通問題，但更多可能的是，使用者這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連使用者是誰也未必能準確地定義。產品和業務開發本來就是乙個探索的過程，開始時一定是最無知的時刻。
專案中的大部分決策也一定是在專案開始的時刻做出的，這將有乙個重大的悖論，在最無知的時刻，做出了最重要而且是絕大部分的決策，並把它作為隨後執行的依據。面對不確定的技術、市場環境，傳統開發模式已無法適應要求，悖論越發突出。
敏捷開發將通過迭代應對這一問題，只做初始決策，定大致的方向。通過市場反饋不斷修正對產品的認知，增量的決策和調整。
產品開發過程中，技術環境、市場環境、競品策略、團隊認知都會發生變化。面對變化的環境，我們必須承認自己的無知，在開發過程主動有效地學習，不斷地汲取反饋，靈活地調整。這也是敏捷的第二個業務目標，有效學習和靈活響應變化。
敏捷開發工具
敏捷開發是一種以人為核心，以迭代方式循序漸進開發的方法，其軟體開發的過程稱為「敏捷過程」。
在這一過程中，軟體專案的構建被切分成多個子專案，各個子專案的成功都經過測試，具備整合和可執行的特徵。
在2023年年初，一些業界專家成立了敏捷聯盟，起草了敏捷軟體開發宣言。該宣言針對一些企業的現狀，提出了讓軟體開發團隊具有快速工作、快速應變能力的若干價值觀和原則，其中包括4個簡單的價值觀以及敏捷開發方法應遵循的12條原則。
1.個人和互動勝過過程和工具。
2.可以執行的軟體勝過面面俱到的文件。
3.客戶合作勝過合同談判。
4.響應變化勝過遵循計畫。
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主管（流程主管）
開發團隊
負責管理產品backlog（代辦事項）的唯一負責人
代表客戶/專案如責任人
定義產品的所有特性
負責產品的投入產出
負責最大化產品和開發團隊工作的價值
起到教練的職責，領導團隊完成scrum的實踐以及體現其價值。
排除團隊遇到的困難，使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力。
確保團隊能勝任其工作，並保持高效的生產率。
保護團隊不受到外來無端影響
每日例會：每日5分鐘左右的乙個簡單例會，盡可能多的開發人員參與進來對緊要問題的討論。
評審會：需要在迭代週期的最後一天召開，1個小時左右就可以了，需要客戶出席，如果客戶不能出席，則需要產品經理出席
迭代回顧會：迭代回顧會是在每個迭代結束時進行，總結工作中的經驗和教訓，時間維持在30-60分鐘內，整個團隊都需要參加（scrum master、product owner、開發團隊以及客戶）。迭代回顧會包括兩部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含團隊是否完成了迭代目標，收集並評審迭代度量指標（包括速率、迭代燃盡圖、迭代計畫故事和實際完成故事、計畫發布日期與實際發布日期、客戶滿意度、團隊滿意度、生產環境bug數、生產bug解決時間、使用者故事等）。定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下乙個迭代實現）？
敏捷開發原則
原則一 我們最先要做的是通過盡早的持續的交付，有價值的軟體來時客戶滿意，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高，交付的越頻繁，最終產品的質量就越高。原則二即使到了開發的後期也歡迎改變需求敏捷過程，利用變化來為客戶創造競爭優勢。原則三經常性的交付，可以工作的軟體交付的間隔可以從幾...
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...
敏捷開發的原則
一 單一職責原則 the single responsibility principal srp 就是說盡量的單一化類的功能，不要使類具有多個功能。如果類具有多個功能時，任意乙個功能的修改都需要改寫這個類，也就會影響其他的類，而這些類根本沒有使用修改的這個功能。如果單一化功能，這種情況就可以避免。例...