敏捷開發學習筆記

敏捷軟體開發是為了防止專案開發中的過程膨脹而提出的。為此，成立了敏捷軟體聯盟，並建立了《敏捷軟體開發宣言》。

我對敏捷開發的感覺有以下幾點：

一、在開發過程中強調人以及人與人之間關係的作用。不但要求開發團隊要有乙個積極向上的氛圍，同時還強調成員與成員之間的合作和交流。例如：每兩名成員組成一對，共同開發乙個功能，並且這種結對要至少每天更換一次。這就保證了資訊在專案組內部的流通，同時知識也更容易傳播。

二、降低了工具的作用。在開發的過程中，應當優先使用簡單的工具，直到證明這些簡單的工具不再適用。

三、在每次迭代中，要優先實現已確定的素材，其次再為下一次迭代的素材作打算。在每次迭代中，要以實現當前的素材為準則。「團隊最開始的工作是以盡可能最簡單的方式實現第一批使用者素材。只有當出現乙個使用者素材迫切需要改變基礎結構時，他們才會引入該基礎結構」。

四、推薦在編寫**之前，要先編寫單元測試和驗收測試。然後以通過測試為目的來編寫**。這樣「有目的的編寫**」，可以有效地降低**的冗餘。同時，單元測試可以降低**之間的耦合。

五、重構和隱喻很重要。我想這並不僅僅適用於敏捷開發。

敏捷開發的最重要的意義之一在於：防止軟體的腐化。

需求是多變的。需求的一次簡單變更就可以輕易破壞**的優雅和原有的結構。

**的腐化可以從以下幾個角度來定義：僵化性、脆弱性、牢固性、粘滯性、不必要的複雜性、不必要的重複、晦澀性。

如果真的有一點我們寫出了這樣腐化的**，我們不應當抱怨需求的變更。

我們能做的是改變我們寫**的方式，嘗試以下原則：

1．遵循敏捷實踐去發現問題

2．應用設計原則去診斷問題

3．應用適當的設計模式去解決問題

在開發的時候我們應該做到:

分析一點

設計一點

編寫一點

測試你所有你能測試的部分

敏捷開發的精髓在於快速響應。

響應什麼？相應變化。

誰的變化？需求的變化。

如果我們能夠每隔一秒鐘就從使用者那裡重新獲得需求，然後進行分析、設計、編碼、測試，那麼我們就不會抱怨使用者的需求總是變化了。因為在這一秒鐘的時間段裡，使用者的需求沒有任何變化。但是顯然，這不可能。

不可能的地方有兩個，一是我們不能每一秒鐘就重新獲得一次需求。二是我們不可能每次都對使用者的需求重新分析、設計。

但是我們可以找到乙個相對平衡的時間段和需求塊，儘管不是完美的平衡。時間段有多長？取決於使用者需求變化的速率。需求變化得越快，那麼獲取的頻率應該越高。每次對多少需求進行分析和設計？這取決於我們擁有多少時間以及我們的工作效率.

為什麼需要重構？因為它會使**更靈活，擁有更好的反應能力。

為什麼要拒絕腐化的**？因為死人是永遠不會做出響應的。