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

敏捷式是一個詞彙，描述軟體開發的方法，強調累加傳遞、小組共同作業、持續規劃和持續學習。 敏捷式術語於 2001 年在敏捷式宣言中創造。 宣言旨在建立原則，指導更妥善的軟體開發方法。 宣言的核心是宣告四個代表敏捷式運動基礎的值語句。 如書面所述，宣言指出：

我們得出了價值：

• 個人與互動，更甚於流程圖和工具。
• 偏向工作軟體更甚於完整文件。
• 偏向與客戶共同作業更甚於合約交涉。
• 因應變化，更甚於遵循計畫。

宣言並不表示這些語句右側的專案並不重要或需要。 相反地，左邊的專案會更加重視。

敏捷方法和做法

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

敏捷式方法通常稱為架構，是 DevOps 生命週期階段的完整方法：規劃、開發、傳遞和作業。 他們規定一種方法來完成工作，並明確指導和原則。

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

• 規劃撲克是一種共同作業估計做法，旨在鼓勵小組成員分享他們對完成之意義的認識。 許多人發現這個過程很有趣，它已證明有助於促進團隊合作和更好的估計。
• 持續整合 （CI） 是常見的敏捷式工程實務，涉及經常將程式代碼變更整合到主要分支。 自動化組建會驗證變更。 因此，整合債務的減少和不斷交付的主要分支。

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

敏捷式不是

隨著敏捷式的普及，許多陳規定型觀念和誤解對其有效性產生了負面陰影。 很容易說“是的，我們正在做敏捷，”沒有任何責任。 請記住這一點，請考慮一些敏捷式不是的事情。

• 敏捷式不是 牛仔編碼。 敏捷式不應該與軟體開發的「我們會在進行時找出」方法混淆。 這種想法離真相不能更遠了。 敏捷式需要 每個短期衝刺中提供給客戶的已完成 和明確值的定義。 雖然敏捷式重視個人和小組的自主性，但它強調一致的自主性，以確保提高自主性會產生更高的價值。
• 敏捷式並非沒有嚴謹和規劃。 相反地，敏捷式方法和做法通常會強調規劃專業領域。 關鍵是在整個專案中持續規劃，而不只是預先規劃。 持續規劃可確保小組可以從執行的工作中學習。 透過這種方法，他們將規劃的投資報酬率最大化。

“計劃是無價值，但規劃是一切。” — Dwight D. Eisenhower

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

為什麼是敏捷式？

那麼，為什麼有人會考慮敏捷式方法？ 很明顯，過去10-15年，圍繞建築軟體的參與規則已經從根本上改變。 許多活動看起來很類似，但我們套用它們的環境和環境明顯不同。

• 比較今天購買軟體與 2000 年代初的樣子。 人們開車到商店購買商務軟體的頻率為何？
• 請考慮如何從客戶收集有關產品的意見反應。 團隊如何了解人們在社交媒體之前對軟體的看法？
• 請考慮小組想要更新及改善其提供軟體的頻率。 每年的更新對現代競爭不再可行。

Forrester 的迭戈·洛·吉迪斯在他的博客 《轉換應用程序傳遞 》（2020年10月）中說，這最好。

“一切都發生了巨大的變化。 除了綠色和清潔，可持續性意味著我們今天建設的東西必須輕鬆和迅速地改變明天。 戰略規劃是短期的，規劃和變化是連續的。“迭戈·洛·吉迪斯，Forrester

這些規則已經改變，世界各地的組織現在會據此調整其軟體開發方法。 敏捷方法和做法不保證能解決每個問題。 但他們確實承諾建立一個文化和環境，其中解決方案會透過共同作業、持續規劃和學習，以及更頻繁地交付高品質軟體的願望。

下一步

決定將敏捷式路由移至軟體開發，可能會帶來一些有趣的機會來增強您的DevOps程式。 其中一個主要考慮著重於敏捷式開發與組織目前方法的比較和對比。