閱讀英文

共用方式為


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

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

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

我們得出了價值:

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

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

敏捷方法和做法

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

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

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

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

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

敏捷式不是

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

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

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

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

為什麼是敏捷式?

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

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

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

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

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

下一步

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