Agile是一種軟件開發的理念，是對Software Development的價值觀。不是所有Project都應該使用Agile。Agile只是對現在商業模式急速變化，商機稍縱即逝，軟件開發相對應用於降低風險，快速體現價值的方法。
敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。
它不是一門技術，它是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發。敏捷開發之所以採用迭代的方式，實際上是利用蠶食方式逐步完成開發任務。將一個宏偉的目標切割為一個個小目標，會給予團隊成員更大的信心，並且能夠更加清晰地明確目標。而每次迭代後的回顧，則使得團隊成員可以更加清晰地明確我們在這個征途中，已經走到了哪裡，未來還有多遠的路程。
Agile就像一把大傘，Scrum、XP等都是其中的一員，Scrum是一種框架，更注重於一些過程，XP更注重於實踐。
敏捷方法論有一個共同的特點，那就是都將矛頭指向了“文檔”，它們認為傳統的軟件工程方法文檔量太“重”了，稱為“重量級”方法，而相應的敏捷方法則是“輕量級”方法。
XP：極限編程（eXtreme Programming）
XP是一種輕量（敏捷）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟件開發方式。
與其他方法論相比，其特點有：
1.在更短的周期內，更早地提供具體、持續的反饋信息。
2.在迭代的進行計劃編制，首先在最開始迅速生成一個總體計劃，然後在整個3.項目開發過程中不斷的發展它。
3.依賴於自動測試程序來監控開發進度，並及早地捕獲缺陷。
4.依賴於口頭交流、測試和源程序進行溝通。
5.倡導持續的演化式設計。
6.依賴於開發團隊內部的緊密協作。
7.盡可能達到程序員短期利益和項目長期利益的平衡。
Scrum (英式橄欖球爭球隊):軟件開發模型是敏捷開發的一種；
Sprints（衝刺/迭代）
（1）Scrum的項目過程由一系列的Sprint組成。
（2）Sprint就是一個迭代開發週期
（3）通常每個Sprint長度為1~4週
（4）通過固定的周期保持良好的節奏。
（5）產品的設計、開發、測試都在Sprint期間完成。
（6）Sprint結束時交付可以工作的軟件。
（7）在Sprint過程中Product Backlog及Sprint結束時間不允許發生變更；Sprint計劃前，Product Backlog可以調整。
3.2.1 Scrum的基本假設：
3.2.2 有關Scrum的幾個名詞
backlog :可以預知的所有任務，包括功能性和非功能性的所有任務。
Sprint：“衝刺”的意思，把一次迭代的開發內容以最快的速度完成它，這個過程我們稱它為Sprint。
sprint backlog :一個sprint週期內所需要完成的任務。
scrum Master :負責整個Scrum進程，修訂計劃的一個團隊成員。
time-box :一個用於開會時間段。比如每個daily scrum meeting的time-box為15分鐘。
sprint planning meeting :在啟動每個sprint前召開的會議。
Daily Scrum meeting：每日站會。每個成員簡短匯報，通過該會議，團隊成員可以相互了解項目進度。
Sprint review meeting：每個Sprint結束後的評審會議，演示成果。
Sprint retrospective meeting：對剛結束的Sprint進行總結。
3.2.3 實施Scrum的過程簡單介紹
1、首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；
2、Scrum Team根據Product Backlog列表，做工作量預估和安排；
3、有了Product Backlog列表，需要通過Sprint Planning Meeting（Sprint計劃會議） 從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；
5、在Scrum Team完成Sprint Backlog過程中，需要進行Daily Scrum Meeting（每日站會），每次會議控制在15分鐘左右，每個人都必鬚髮言，並且要向所有成員當面匯報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，更新自己的kanban；
6、做到每日集成，也就是每天都要有一個可以成功編譯、並且可以演示的版本；；
7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；
8、最後就是Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；
9、這樣周而復始，按照同樣的步驟進行下一次Sprint。
3個工件： Product Backlog, Sprint Backlog, increment（可交付軟件增量）
3個角色： Product Owner, Scrum Master, Scrum Team
5個會議：Product Backlog Refinement(產品任務細化)
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review Meeting
Sprint Retrospective Meeting
**5個價值觀：**公開，專注，勇氣，承諾，尊重
（1）、Scrum儀式之Sprint計劃
在啟動一個正式Sprint之前，需要組織一些項目要做事宜（例如需求收集，成本評估，架構審核，發布計劃等）
在Scrum框架下，沒有“個人”的概念，Scrum依靠的是團隊的力量。儘管Scrum Master在這個框架下的作用很重要，但這個人不是獨裁者。做Sprint計劃時，一定要讓整個團隊參加。
（2）、Scrum儀式之Scrum站會
站立會議是敏捷軟件開發方法論Scrum的相關技術之一，亦可稱之為Scrum的最佳實踐。
具體形式為：每天同一時間，一個敏捷開發團隊的所有成員面對面站在一起，進行一個為期15~20分鐘的短會。
站立會議的意義和作用是：
站立會議不僅能要讓所有人了解其他人在做什麼，當前項目計劃進展如何，還可以幫助大家解決那些阻礙做事情的問題，以及共享承諾。
（3）、Scrum儀式之Sprint評審
Sprint評審會用來演示在這個Sprint中開發的產品功能給Product Owner, Produc Owner會組織這階段的會議並且邀請相關的干係人參加。
Sprint演示：在一個Sprint結束以後，進行Sprint評審，團隊在此期間展示他們所完成的工作、可運行的軟件。出席此會議的有Product Owner、開發團隊、ScrumMaster、客戶、等任何對此感興趣的人。
（4）、Scrum儀式之Sprint回顧
Sprint回顧會議與項目總結會議不同：它不是要對項目進行蓋棺定論，而是通過及時回顧，總結上一次Sprint中的得與失，找到改善與提高的辦法，從而讓下一個Sprint走得更好。
4. Agile的12原則
1、我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
Scrum：產品需求列表中的優先級及每次迭代後持續提交工作軟件
2、欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
Scrum：產品需求列表可以隨時更新
3、經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向於採取較短的周期。
Scrum：1-4週的的迭代周期
4、業務人員和開發人員必須相互合作，項目中的每一天都不例外。
Scrum：跨職能團隊及每日15分鐘的站立會議
5、激發個體的鬥志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
Scrum：團隊自我管理原則
6、不論團隊內外，傳遞信息效果最好和效率最高的方式是面對面的交談。
Scrum：5~9人的小團隊，kanban的使用以及開放環境的面對面溝通
7、可工作的軟件是進度的首要度量標準。
Scrum：對工作的軟件的關注，演示會要求提供可以被驗收和演示的內容
8、敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
Scrum：時間盒概念，迭代速率的使用
9、堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
Scrum：要求對產品需求列表中每個用戶故事都定義一個完成標準；
10、以簡潔為本，它是極力減少不必要工作量的藝術。
Scrum：盡量製作正好夠的東西已經在恰當時間做決策
11、最好的架構、需求和設計出自組織團隊。
Scrum：如何做完全放在團隊手中；
12、團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
Scrum：回顧會的作用
測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論，TDD首先考慮使用需求（對象、功能、過程、接口等）
主要是編寫測試用例框架對功能的過程和接口進行設計，而測試框架可以持續進行驗證。
實際上BDD可以看作是對TDD的一種補充，讓開發、測試、BA以及客戶都能在這個基礎上達成一致，JBehave之類的BDD框架
通過單元測試用例來驅動功能代碼的實現，團隊需要定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試腳本開發。面向開發人員，強調如何實現系統以及如何檢驗
DDD指的是Domain Drive Design，也就是領域驅動開發,DDD實際上也是建立在這個基礎之上，因為它關注的是Service層的設計，著重於業務的實現,將分析和設計結合起來，不再使他們處於分裂的狀態，這對於我們正確完整的實現客戶的需求，以及建立一個具有業務伸縮性的模型
warren2lynch
iThome鐵人賽
看影片追技術