什麼是敏捷式 (Agile) 開發？

Agile 是一個詞彙，描述軟體發展的方法，強調累加傳遞、小組共同作業、持續規劃和持續學習。 Agile一詞是在 2001 年敏捷式資訊清單中建立的。 資訊清單已設定為建立原則，以引導更妥善的軟體發展方法。 資訊清單的核心會宣告四個值語句，代表敏捷式移動的基礎。 如所撰寫，資訊清單會指出：

我們已獲得價值：

• 個人與程式與工具的互動。
• 有效用的软件胜过全面的文档。
• 客户协作胜过合同协商。
• 回應因應遵循計畫而變更。

資訊清單不表示這些語句右側的專案並不重要或必要。 相反地，左側的專案會更重視。

敏捷式方法和做法

請務必瞭解敏捷式不是 一件事。 您不會 執行敏捷式作業。 相反地，Agile 是推動軟體發展方法的思維。 因為沒有任何單一方法適用于所有情況， 所以 Agile 一詞會代表各種方法與資訊清單中的 value 語句一致的做法。

通常稱為架構的敏捷方法，是 DevOps 生命週期階段的完整方法：規劃、開發、傳遞和作業。 他們會指定一個方法，以清楚的指引和原則來完成工作。

Scrum 是最常見的敏捷式架構，也是大部分人一開始的架構。 另一方面，敏捷式做法是在軟體發展生命週期階段套用的技術。

• 規劃 Poker 是共同作業估計做法，其設計目的是鼓勵小組成員瞭解 完成的意義 。 許多人都發現程式有趣，並經過證實可協助促進團隊合作和更好的估計。
• 持續整合 (CI) 是常見的敏捷式工程做法，涉及經常將程式碼變更整合到主要分支。 自動化組建會驗證變更。 因此，整合債務和持續交付的主要分支會減少。

這些做法就像所有敏捷式做法一樣，會攜帶敏捷式標籤，因為它們與 敏捷 式資訊清單中的原則一致。

什麼是敏捷式

隨著敏捷式的受歡迎程度，許多造型和誤譯都會對其有效性產生負面陰影。 很容易說「是，我們正在執行敏捷式」，而不需要任何責任。 請記住這點，請考慮一些敏捷式不是的事項。

• 敏捷式不是 精靈程式碼。 敏捷式不應與軟體發展的「我們將瞭解」方法混淆。 這種想法無法更進一步地從事實開始。 敏捷式需要每個短期衝刺中傳遞給客戶的完成和明確值 定義 。 雖然個人和小組的敏捷式價值自主性，但它強調對齊的自主性，以確保增加的自主性會產生更高的價值。
• 敏捷式不需更嚴格且規劃。 相反地，敏捷式方法和實務通常會強調規劃中的專業領域。 關鍵在於在整個專案中持續規劃，而不只是預先規劃。 持續規劃可確保小組可以從他們執行的工作中學習。 透過這種方法，它們會將投資報酬率最大化 (ROI) 規劃。

「計畫不具價值，但規劃是所有專案」— Dwight D.Eisenhower

• 敏捷式並非缺乏藍圖的一種需求。 這種誤解可能會對敏捷式移動整體造成最大損害。 遵循敏捷式方法的組織與小組，絕對知道他們要在哪裡進行，以及想要達成的結果。 將變更辨識為程式的一部分，與每週、短期衝刺或月份的新方向樞紐不同。
• 敏捷式不是在沒有規格的情況下進行開發。 任何專案中都需要讓小組保持一致 的原因 和運作 方式 。 規格的敏捷式方法包括確保規格 的大小正確，並適當地反映小組順序和傳遞的運作方式。
• 敏捷式無法容納非計劃性的工作和其他中斷。 請務必依排程完成短期衝刺。 但只是因為發生問題，所以側溯開發並不表示短期衝刺必須失敗。 Teams 可以事先為問題和非預期的問題指定資源，以規劃中斷。 然後他們可以解決這些問題，但持續追蹤開發。
• 敏捷式不適用於大型組織。 常見的抱怨是共同作業是敏捷式方法的重要元件，在大型小組中很困難。 另一個底框是 Agile 的可調整方法引進了可危害彈性的結構和方法。 雖然有這些誤解，但可以成功調整敏捷式原則。 如需克服這些困難的相關資訊，請參閱 將 Agile 調整為大型小組。
• 敏捷式沒有效率。 為了適應客戶的變化需求，開發人員會投資每次反復專案來示範工作產品並收集意見反應。 這些工作確實會減少他們花費在開發上的時間。 但提早納入客戶要求可節省大量時間。 當功能與客戶的願景保持一致時，開發人員可避免大幅調整這一行。
• 敏捷式不適合現今的應用程式，通常著重于資料流程。 這類專案通常牽涉到比使用者介面更多的資料模型化和擷取轉換載入 (ETL) 工作負載。 這項事實使得很難以一致且緊密的排程來示範可用的軟體。 但藉由調整目標，開發人員仍然可以使用敏捷式方法。 開發人員可以專注于執行資料實驗，而不是完成每個反復專案的工作。 他們不需要每隔幾周呈現工作產品，而是要進一步瞭解資料。

為什麼是 Agile？

因此，任何人為何會考慮敏捷式方法？ 清楚的是，建置軟體的參與規則在過去 10-15 年基本上已變更。 許多活動看起來很類似，但我們套用它們的環境和環境明顯不同。

• 比較目前與 2000 年代初期購買軟體的相似性。 人們如何推動市集購買商務軟體？
• 請考慮如何從客戶收集有關產品的意見反應。 小組如何瞭解人們在社交媒體之前對軟體的想法？
• 請考慮小組想要更新及改善其傳遞軟體的頻率。 年度更新不再適用于新式競賽。

Forrester 的 Blob Lo Guidice 在部落格中指出， 轉換應用程式傳遞 (2020 年 10 月) 。

「所有專案都已大幅變更。 除了綠色和乾淨之外，永續性也表示我們現今建置的專案必須輕鬆且快速地在明天變更。 策略性計畫是短期的，而規劃和變更是連續的。」— 為 一個 為 為Rester 的 Lo Guidice

這些規則已變更，而世界各地的組織現在會據以調整其軟體發展方法。 敏捷式方法和做法不會承諾解決每個問題。 但是，他們確實承諾建立文化與環境，其中解決方案會透過共同作業、持續規劃和學習，以及更頻繁地寄送高品質軟體。

後續步驟

決定採用敏捷式軟體發展路線，可能會帶來一些有趣的機會來增強您的 DevOps 程式。 一組主要考慮著重于 敏捷式開發 與組織目前方法的比較和對比。