敏捷方法論：意義、優點、缺點等

敏捷方法是一種軟件開發理念，旨在通過使用更短的開發週期同時包括不斷的修訂來為客戶提供更好的價值。

軟件開發是從數學和科學領域發展而來的。 因此，它最初融合了這些領域的科學方法。

這些方法在 1970 年代演變成瀑布方法，以滿足當時的需求。 那時的計算機及其軟件龐大而復雜，並且設計可以使用數十年。 因此，瀑布方法非常適合。

但是，到 1990 年代後期，互聯網正在極大地改變世界，因此需要一種新的方法。 敏捷方法就是這樣誕生的。

以下是對這一軟件開發運動的詳細介紹，以及它如何幫助您和您的團隊。

敏捷開發方法的歷史

敏捷軟件開發源於互聯網及其在 1990 年代和 2000 年代初期的繁榮時期對應用程序的永不滿足的需求。

這也是許多沒有計算機科學背景的開發人員轉向 Web 開發的時期，因為對迎合不同群體和行業的網站的大量需求。

當然，大多數初創公司都很小。 因此，大多數開發都發生在小團隊中，最終目標通常是快速上市。 因為遲到意味著失去市場份額。

為了應對瀑布模型對盡快將產品推向市場的限制，不同的開發人員在 1990 年代提出了不同的方法。 它們包括快速應用程序開發 (RAD)、Scrum、極限編程 (XP)、看板等。

然後，在 2001 年的某個時候，17 名從事早期敏捷開發的一種或另一種形式的開發人員聚集在美國猶他州。 然後他們通過發布“敏捷軟件開發宣言”結束了他們的會議。

該宣言基於 4 個價值觀和 12 條原則。

敏捷開發的 4 個價值觀和 12 條原則

從他們在會議期間聚集的經驗來看，這 17 位開發人員就一組價值觀達成了一致，以更有效地創建軟件。

這四個值如下：

1. 個人和交互超過流程和工具。 這意味著在遵循特定流程的同時使用工具開發軟件很重要。 但是讓有能力的人更有效地合作更為重要。
   
   
2. 工作軟件優於綜合文檔。 這攻擊了在實際軟件開發過程之前首先設計軟件並為其編寫文檔的瀑布方法。
   
   
3. 客戶合作超過合同談判。 只有與客戶或用戶密切合作，您才能準確了解和開發客戶的需求。 這創造了更多的價值。
   
   
4. 響應變化而不是遵循計劃。 遵循項目計劃很重要。 但計劃不能太死板。 它必須適應變化以滿足利益相關者的期望。

上述敏捷宣言價值觀基於 12 條原則，具體如下：

1. 通過早期和持續交付有價值的軟件來滿足客戶的需求。
2. 歡迎不斷變化的需求，即使是在後期開發中。
3. 經常交付工作軟件（幾周而不是幾個月）
4. 業務人員和開發人員之間密切的日常合作
5. 項目是圍繞有動力的個人建立的，他們應該被信任
6. 面對面交談是最好的溝通方式（同地辦公）
7. 工作軟件是進度的主要衡量標準
8. 可持續發展，能夠保持恆定的步伐
9. 持續關注卓越的技術和良好的設計
10. 簡單——最大化未完成工作量的藝術——是必不可少的
11. 最佳架構、需求和設計來自自組織團隊
12. 定期，團隊反思如何變得更有效率並做出相應的調整

迭代或衝刺

敏捷軟件開發中的迭代或衝刺通常是 1 到 4 週的短週期，開發工作被分解為其中。 這使得事情更容易管理，因為它需要更少的計劃。

每個團隊通常還由具有不同職能的成員組成，這些職能包括規劃、分析、設計、編碼和測試。

團隊在每次迭代或衝刺時一起開發軟件。 他們最終生產出工作產品。 根據敏捷宣言，這個工作軟件是衡量真正進步的標準。

根據產品和客戶的需求，迭代的產品可能會投放市場或不投放市場。 因此，單個版本通常需要多次迭代。

敏捷開發的優勢

可以想像，敏捷方法帶來了許多優勢。 它們如下：

1. 更快地實施想法
2. 比瀑布方法更靈活
3. 通過託管迭代提高生產力
4. 通過用戶交互更好的產品
5. 快速識別和消除錯誤

敏捷方法的缺點

使用敏捷開發方法也有一些缺點。 它們可以包括：

1. 一開始可能很難評估全部成本
2. 它需要大量的客戶輸入
3. 涉及大量計劃外工作
4. 沒有明確定義的項目結束

何時使用敏捷方法

1. 當您無法估計軟件需要什麼時
2. 您有足夠的客戶訪問權限
3. 您正在開發 Web 應用程序或易於更新的系統
4. 您需要通過早期版本快速佔領市場份額

流行的敏捷開發框架

有許多流行的敏捷開發框架。 有些人在 2001 年敏捷宣言之前就開始了，而其他人則較晚。

框架的目標只是定義方法的規則。 因此，雖然下面列出了最流行的框架供您參考，但還有更多。 您還可以自由創建或修改現有框架以適應您的團隊。

1. Scrum ：這個框架是為 10 人或更少成員的團隊設計的。 工作分為 2-4 週的衝刺，每天 15 分鐘的會議。
   
   
2. 看板：源自豐田，看板是一個日語單詞，意思是廣告牌，對於欣賞視覺輔助的團隊非常有幫助。 使用便箋或應用程序等視覺表示將任務從一個階段移動到另一個階段。
   
   
3. 快速應用程序開發 RAD ：這個短語既可以指一般的敏捷軟件開發，也可以指 James Martin 方法。 RAD 專注於用戶界面需求，並在很大程度上依賴於原型設計。
   
   
4. 精益創業：這個框架適用於那些需要開發產品或服務的人，但首先必須確定其市場可行性。 它涉及使用實驗來查看哪些有效，哪些無效。

其他值得注意的框架包括極限編程 (XP)、自適應軟件開發、敏捷建模、動態系統開發方法和規模化敏捷框架。

敏捷與瀑布方法

以下是用於開發軟件的敏捷方法和瀑布方法的並列視圖。 它可以幫助了解每種方法如何相互疊加。 因此，您可以輕鬆選擇最適合您工作的工具。

適應性與預測性發展

敏捷軟件開發的目標是適應現實世界的變化。 這些通常是客戶或用戶需求的結果。 適應與瀑布模型的預測性質形成鮮明對比。

因此，在開發您不太確定事情會如何發展的系統時，使用敏捷方法是有意義的。 或者當一個行業不斷變化和發展時。 互聯網就是一個很好的例子。

否則，如果您正在開發一個您對一切都瞭如指掌的系統或市場，並且幾乎不會改變或對改變免疫。 那麼，瀑布哲學的預測性質可能會有所幫助。

軟件工藝

Software Craftsmanship 是另一種建立在敏捷開發原則之上的哲學，它側重於強調參與項目的軟件開發人員的技能。

軟件工藝運動也有一個宣言，它指出：

 作為有抱負的軟件工匠，我們通過實踐和幫助他人學習技能來提高專業軟件開發的標準。 通過這項工作，我們開始重視：
 
 · 不僅是工作軟件，還有精心製作的軟件
 · 不僅響應變化，而且穩步增加價值
 · 不僅是個人和互動，還有專業人士的社區
 · 不僅是客戶協作，還有富有成效的合作夥伴關係
 
 也就是說，在追求左邊的項目時，我們發現右邊的項目是不可或缺的。
 
  2009 年，簽署人。
 本聲明可以任何形式自由複制，但只能通過本通知全文複製

結論

在我們對敏捷方法和軟件開發的了解結束時，您會看到那裡有很多選擇。

每個團隊都是不同的。 正如不同的團隊開發了不同的方法來適應不斷變化的時代一樣。 您也必須通過使用已經建立的框架或對其進行調整以適應您的團隊來適應。