從編寫邊改的無規劃程式設計，再到有一套繁瑣規則的重型方法，敏捷方法可以說是它們在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。 簡單的說，敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
一、核心思想：適應變化和以人為中心
專案最重要的一項就是需求，可客戶的需求總在變，根本不可能完全預見，這就需要迭代式開發，其要點是經常不斷地生產出最終系統的工作版本，這些版本逐部地實現系統所需的功能。它們雖然功能不全，但已實現的功能必須忠實於最終 系統的要求，它們必須是經過全面整合和測試的產品。這一點在我觀摩了同學跟著實驗室老師做的專案之後有很深的感觸。專案細節在開發初期並不重要，開發需分為幾個階段，前幾個階段需要把基本框架完成，並且基本功能經過完整的測試後沒有問題才能進入下個階段。這樣即使客戶臨時想要新增或修改什麼功能，也就在原有的正確的基礎上進行修改就可以了，節省了很多時間，同時也減少了許多專案的不可預見性。
客戶在這樣的適應性過程中，客戶實際上能夠對軟體開發過程進行很深入細微的控制。在每乙個迭代階段中，他們都能檢查開發進度，也能變更軟體開發方向。這導致了與軟體開發者更密切的關係，或曰真正的商業夥伴關係。同時實施乙個適應性過程特別要求一組高效的開發人員。所以說敏捷開發是面向人的開發過程。
二、「吾日三省吾身」
還有另一種適應性，即是過程本身隨著時間推移變化。隨著時間的推移，開發團隊會發現什麼方式對他們的工作最好，然後改變過程以適應之。自適應的第一步是經常對過程進行總結檢討。一般來說，在每一次迭代結束後， 你可以問自己如下問題：
這些問題會幫助你考慮在下一次迭代中如何對過程進行修正。這樣，如果 開始時使用的過程有問題的話，隨著專案的進行，該過程會得以逐步的完善， 以使其能更好地適合開發團隊。
三、即使無法預期，設計也很重要
不過不可能對開發階段即將遇到的所有問題進行預判，從而不可避免的在開發的時候就會發現一些對設計產生的質疑。這時候可以很好地利用重構的方法對於程式進行必要的修改以適應需求變化。
四、fowler關於設計與極限程式設計的忠告
乙個簡單系統的四個標準。排序如下（重要在前）：
fowler對於極限人（xpers）使用模式的忠告是：
一般來說圖是在開始編碼之前開展設計用的。當你這樣搞的時候注意：
五、持續整合
在我的概念中，一般合作的專案都是大家都做好之後再統一整合一下成為乙個完整的程式。但我現在意識到這是完全錯誤的。乙個程式的每乙個部分只有在理想化的基礎上，才是完全可分的。可事實上大部分的程式的各個部分還是有一定聯絡的。那麼如何讓所有人寫出來的程式能順利的成為乙個整體就成了乙個值得考慮的話題。
fowler在自己的文章中提到了持續整合的重要性。雖然過程很麻煩，不過麻煩也是有意義的。這樣做的結果是你總能得到乙個穩定的軟體，它可能有一些 bug，但可以正常工作。每個人都基於相同的穩定**進行開發，而且不會離得太遠，否則就會不得不花很長時間整合回去。bug被發現得越快，花在改正上的時間就越短。而且這樣也是團隊中各組員保持交流的一種方式。沒有交流的團隊程式設計是失敗的，所有人齊心協力共同完善**倉庫中的專案**，很大的提高了團隊合作效率。
個人部落格作業week5 敏捷開發方法讀後感
我對敏捷開發方法的理解 既然是寫讀後感，很多概念方面的東西我就不一一贅述了，在這篇文章我只談一談我對敏捷開發方法的個人體會。首先，敏捷開發是一種以人為核心 迭代 循序漸進的開發方法。在敏捷開發中，我認為用到了分治的思想，將乙個大問題，分割成若干個小問題，使得問題細化，能夠更好的解決，將乙個大專案分而...
作業記錄 WEEK5
triplet計算細節 訓練過程中的呼叫 import torch from torch.autograd import function from torch.nn.modules.distance import pairwisedistance class tripletloss functio...
week5 作業A 最大矩形
給乙個直方圖，求直方圖中的最大矩形的面積。例如，下面這個中直方圖的高度從左到右分別是2,1,4,5,1,3,3,他們的寬都是1，其中最大的矩形是陰影部分。input 輸入包含多組資料。每組資料用乙個整數n來表示直方圖中小矩形的個數，你可以假定1 n 100000.然後接下來n個整數h1,hn,滿足 ...