什麼是敏捷開發？ - IT 觀察者隨筆

需要比瀑布更快的方式來創建軟件嗎？敏捷可能適合你…

Table of Contents hide

有一種軟件開發方法正在迅速普及，被稱為“敏捷” – 本身不是一種東西，而是更多的抽象概念。

敏捷是一種軟件開發方法，它嚴重依賴團隊內部以及開發人員和客戶之間的協作，通常會產生快速的結果。增量交付，頻繁規劃和持續學習都是該方法成功的關鍵驅動因素，這使其成為組織進行數字轉換，軟件升級和開發的主要方式之一。

2001年，敏捷創立於敏捷宣言之初，該敏捷宣言由17位軟件開發人員撰寫，他們在猶他州的滑雪勝地旅館組裝了兩天。該宣言的目的是創建原則，以試用更好的軟件開發方法。

在宣言中提出的十二項原則中，建立了方法論背後的哲學，其中四項是我們感興趣的。敏捷重視個人和流程與工具之間的互動，通過綜合文檔工作軟件，通過合同談判進行客戶協作，以及響應遵循計劃的變更。

敏捷囊括了一種驅動其特定品牌軟件開發的思維模式。該方法理解每個客戶的需求是不同的，並且包含這些差異以創建更好的方法。一種方法並不適合所有情況，因此“敏捷”一詞更能代表一系列方法和實踐，這些方法和實踐與宣言的12條原則所支持的核心價值觀相結合。

這些敏捷方法通常稱為框架。它們代表了軟件開發生命週期階段的廣泛方法，例如規劃，執行和交付。他們詳細介紹了完成工作的方法，並提供了明確的指導和原則。

每個元素必須在下一個元素開始之前完成。當發現問題時，項目必須從第一階段重新開始。通過敏捷，可以即時進行更改，因此只要出現問題，就可以轉移資源來解決問題，而無需佔用項目的其餘部分。

這種對緊縮周轉時間的關注以及在短時間內改變項目要求或規範的能力使得敏捷在科技公司和初創公司中非常受歡迎，他們經常需要進行小型迭代更新，以便跟上瞬息萬變的市場。

敏捷與其他IT趨勢緊密相關 – 許多雲開發團隊都讚同敏捷原則，並且還與DevOps共享其許多核心原則- 特別是它專注於快速迭代和團隊成員之間的密切協作。

自稱為“敏捷戰士”的Jonathan Rasmusson稱該方法)是一種“時間框架，迭代的軟件交付方法，從項目開始就逐步構建軟件，而不是試圖在接近結束時立即交付所有軟件”。

“敏捷宣言”於2001年出版，概述了支撐這一概念的關鍵原則：

也就是說，雖然右邊的項目有價值，但敏捷值更左側的項目。

簡而言之，敏捷有利於交付，測試和持續反饋的速度。其核心原則支持這一點。他們是：

敏捷流程將項目劃分為更小的部分，稱為“用戶故事”，每個部分代表用戶為軟件請求的特定功能。那些從事項目工作的人員就像待辦事項列表一樣堅持這些部分，優先考慮那些需要先完成的部分，然後將其他人分組到最後期限的迭代中 – 通常在兩週的時間內。

我們的想法是，一旦迭代完成，開發人員應該能夠將產品發送給用戶進行測試，然後可以根據反饋進行構建。此過程創建的軟件更適合用戶需求。

它還允許開發人員一次一個地滿足特定需求，而不是從一個全面的列表開始，並提供在此過程中發現新需求的機會，因為用戶可以在測試時更改他們對功能的想法。

每次迭代的持續時間始終是固定的，以確保開發人員及其用戶能夠定期查看項目的方向和需求列表。但是，固定期限意味著項目永遠不會超過計劃。

除敏捷外，DevOps還是另一種在企業社區中越來越受歡迎的IT方法。然而，對於兩者之間的關係仍然存在一些混淆，一些組織將它們視為單獨的學科，一些組織認為它們基本相同。

實際上，兩個陣營都是正確的; DevOps和敏捷有很多相似之處，但它們在某些關鍵方面也有所不同，並且通常適用於不同的任務。這兩種方法都側重於快速迭代，定期用戶反饋和高度靈活性，所有這些都是為了在更短的時間內為最終用戶提供更多功能。

但是，雖然敏捷通常主要關注流程和工作流，但DevOps通常更加重視工具和基礎架構。DevOps大量使用持續交付，持續集成和容器工具，允許快速修訂和敏捷方法所青睞的小團隊。

在許多方面，DevOps可以被認為是敏捷的延伸。通常，公司將在其軟件開發中採用敏捷實踐，只有在產品完成後才恢復非敏捷方法 – DevOps只是將敏捷背後的態度擴展到產品的整個生命週期。