為什麼需要敏捷開發
在傳統的瀑布式開發中，需要等上一階段的任務完全完成後才能開始進行下乙個階段。好比你點了10道菜，廚師要等到10道菜都做好了才給你一起上，那作為消費者肯定是不樂意的。而在軟體開發中，要等到產品完全完成後才上線勢必會延誤市場時機。因此，軟體開發的模型不再使用瀑布模型了，更多的企業傾向於使用敏捷開發。
敏捷開發並不追求前期完美的設計、完美編碼，而是力求在很短的週期內開發出產品的核心功能，盡早發布出可用的版本。然後在後續的生產週期內，按照新需求不斷迭代公升級，完善產品（也就是：先定乙個小目標）。
敏捷開發有很多種方法，包括了xp（極限程式設計），scrum（迭代式增量軟體開發過程），rup等。
xp客戶作為團隊成員：這裡的客戶是指定義產品特性並對其進行排列優先順序的人或者團體，即今天我們俗稱的產品、業務分析師、專案經理等一類人。極限程式設計所追求的是「客戶」和開發人員在同乙個環境中工作。面對面溝通，是最有效最簡潔的交流方式。
良性計畫：極限程式設計中，開發人員和客戶要先確定最重要的需求，以保證快速響應和進行工時預估。需求可以隨時進行調整。
簡單設計：採用能夠解決當前需求的最簡單設計。只有在確定真的需要引入某些基礎結構（比如資料庫、通訊服務框架）價效比更高時，再去引入它們。將重複或相似度較高的**變成函式，封裝成乙個統一的抽象集合，然後在使用時呼叫即可（這也將進一步減少**間的耦合）。
結對程式設計
持續整合：多次的check in和check out並進行merge，使用源**控制工具。
tdd（測試驅動開發）：先編寫測試**（單元測試），再編寫功能**。
uat（驗收測試）：用來驗證系統是否滿足它所聲稱的具有其功能的黑盒測試方法。驗收測試是關於系統特性的最終文件。單元測試作為可編譯可執行的系統內部結構的文件，驗收測試是有關系統特性的可編譯執行的文件。
重構：重構後的程式讀起來應比之前好很多，工作的也應該更好。程式應該變得更易理解和修改，且程式結構各部分之間互相隔離。
scrum
scrum則是一種開發流程框架，也可以說是一種套路。scrum框架中包含三個角色，三個工件，四個會議，聽起來很複雜，其目的是為了有效地完成每一次迭代週期的工作。
在專案啟動之前，會由團隊的產品負責人（product owner）按照需求優先順序來明確出乙份product backlog，為專案做出整體排期。
隨後在每乙個小的迭代週期裡，團隊會根據計畫（sprint plan meeting）確定本週期的sprint backlog，再細化成乙個個task，分配給團隊成員，進行具體開發工作。每一天，團隊成員都會進行daily meeting，根據情況更新自己的task狀態，整個團隊更新sprint burn down chart。
當這一週期的sprint backlog全部完成，團隊會進行spring review meeting，也就是評審會議。一切順利的話，會發布出這一版本的release，並且進行sprint回顧會議（sprint retrospective meeting）。
xp和scrum的區別
迭代長度的不同：xp的乙個sprint的迭代長度大致為1~2周, 而scrum的迭代長度一般為 2~ 4周。
在迭代中, 是否允許修改需求：xp在乙個迭代中，如果乙個user story(使用者素材, 也就是乙個需求)還沒有實現， 則可以考慮用另外的需求將其替換， 替換的原則是需求實現的時間量是相等的。而scrum是不允許這樣做的，一旦迭代開工會完畢, 任何需求都不允許新增進來，並有scrum master嚴格把關，不允許開發團隊受到干擾。
在迭代中，user story是否嚴格按照優先級別來實現：xp是務必要遵守優先順序別的。但scrum在這點做得很靈活，可以不按照優先級別來做，scrum這樣處理的理由是：如果優先問題的解決者，由於其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。另外乙個原因是，如果按優先順序排序的user story #6和#10，雖然#6優先順序高，但是如果#6的實現要依賴於#10，則不得不優先做#10。
軟體的實施過程中，是否採用嚴格的工程方法，保證進度或者質量：scrum沒有對軟體的整個實施過程開出工程實踐的處方，要求開發者自覺保證。但xp對整個流程方法定義非常嚴格，規定需要採用tdd、自動測試、結對程式設計、簡單設計、重構等約束團隊的行為。
devops
敏捷開發的重心是開發，devops的重心是開發和運維的協作。devops是development和operations的合成詞，其目標是要加強開發人員、測試人員、運維人員之間的溝通協調。如何實現這一目標呢？需要我們的專案做到持續整合、持續交付、持續部署。
有用的參考文章
趣文：三分鐘了解敏捷開發
敏捷開發：極限程式設計簡述
什麼是持續整合？該怎麼做？
一分鐘告訴你究竟devops是什麼鬼？
理論上最漂亮的企業門戶
企業門戶能漂亮到什麼程度已經是個核心競爭力了，門戶產品功能再強大，介面不美也是個失敗的門戶產品。原因很簡單，假設乙個企業裡面有5萬名員工，每個員工每天要看門戶頁面十次，每看一次就潛意識的不舒服一次，那麼一天就總共不舒服50萬次，一年下來全公司所有員工總共不舒服一億次，多麼驚人的危害。但問題是每個企業...
從理論上理解採用交叉熵作為損失函式的意義
簡要解釋為什麼要使用交叉熵作為損失函式。用簡短的話來解釋就是 我們需要得到最大似然估計，即模型得到的 分布應該與資料的實際分布情況盡可能相近。kl散度 相對熵 是用來衡量兩個概率分布之間的差異。模型需要得到最大似然估計，乘以負log以後就相當於求最小值，此時等價於求最小化kl散度 相對熵 所以得到k...
「理論上如何」其實是主觀上如何
理論上如何 其實是主觀上如何 紅朝儒生 2016 12 9 關鍵字 理論 主觀 簡介 所謂 理論上如何 其實是主觀上認為應該如何。人們都喜歡說 理論上如何 說了這一句，就會跟一句 現實中會不如何 吾常常想，既然是理論上如何，怎麼現實就不如何了？那說明理論錯了。既然理論錯了，完善補充就是了，為什麼還繼...