什麼是敏捷式 (Agile) 開發?
敏捷式是一個詞彙,描述軟體開發的方法,強調累加傳遞、小組共同作業、持續規劃和持續學習。 敏捷式術語於 2001 年在敏捷式宣言中創造。 宣言旨在建立原則,指導更妥善的軟體開發方法。 宣言的核心是宣告四個代表敏捷式運動基礎的值語句。 如書面所述,宣言指出:
我們得出了價值:
- 個人與互動,更甚於流程圖和工具。
- 偏向工作軟體更甚於完整文件。
- 偏向與客戶共同作業更甚於合約交涉。
- 因應變化,更甚於遵循計畫。
宣言並不表示這些語句右側的專案並不重要或需要。 相反地,左邊的專案會更加重視。
請務必瞭解敏捷式不是一 回事。 您不會 執行敏捷式作業。 相反地,Agile 是推動軟體開發方法的思維。 因為沒有任何單一方法適用於所有情況,因此 Agile 一詞來代表各種方法與指令清單中的 value 語句一致的做法。
敏捷式方法通常稱為架構,是 DevOps 生命週期階段的完整方法:規劃、開發、傳遞和作業。 他們規定一種方法來完成工作,並明確指導和原則。
Scrum 是最常見的敏捷式架構,也是大多數人從頭開始的架構。 另一方面,敏捷式做法是在軟體開發生命週期階段套用的技術。
- 規劃撲克是一種共同作業估計做法,旨在鼓勵小組成員分享他們對完成之意義的認識。 許多人發現這個過程很有趣,它已證明有助於促進團隊合作和更好的估計。
- 持續整合 (CI) 是常見的敏捷式工程實務,涉及經常將程式代碼變更整合到主要分支。 自動化組建會驗證變更。 因此,整合債務的減少和不斷交付的主要分支。
這些做法,就像所有敏捷式做法一樣,都會攜帶 敏捷 式卷標,因為它們與敏捷式指令清單中的原則一致。
隨著敏捷式的普及,許多陳規定型觀念和誤解對其有效性產生了負面陰影。 很容易說“是的,我們正在做敏捷,”沒有任何責任。 請記住這一點,請考慮一些敏捷式不是的事情。
- 敏捷式不是 牛仔編碼。 敏捷式不應該與軟體開發的「我們會在進行時找出」方法混淆。 這種想法離真相不能更遠了。 敏捷式需要 每個短期衝刺中提供給客戶的已完成 和明確值的定義。 雖然敏捷式重視個人和小組的自主性,但它強調一致的自主性,以確保提高自主性會產生更高的價值。
- 敏捷式並非沒有嚴謹和規劃。 相反地,敏捷式方法和做法通常會強調規劃專業領域。 關鍵是在整個專案中持續規劃,而不只是預先規劃。 持續規劃可確保小組可以從執行的工作中學習。 透過這種方法,他們將規劃的投資報酬率最大化。
“計劃是無價值,但規劃是一切。” — Dwight D. Eisenhower
- 敏捷式並不是缺乏藍圖的藉口。 這種誤解可能對敏捷式運動整體造成最大傷害。 遵循敏捷式方法的組織和小組絕對知道他們要去哪裡,以及想要達成的結果。 將變更辨識為程式的一部分,與每周、短期衝刺或月份的新方向不同。
- 敏捷式不是沒有規格的開發。 任何專案中都需要讓小組保持 一致的原因 和 運作方式 。 規格的敏捷式方法包括確保規格 大小正確,且會適當反映小組順序和交付方式。
- 敏捷式無法容納非計劃性的工作和其他中斷。 請務必依排程完成短期衝刺。 但只是因為有一個問題出現,副追蹤開發並不意味著短期衝刺必須失敗。 Teams 可以事先為問題和非預期的問題指定資源來規劃中斷。 然後,他們可以解決這些問題,但持續追蹤開發。
- 敏捷式不適用於大型組織。 常見的抱怨是,在大型團隊中,共同作業是敏捷式方法的關鍵元件。 另一個抱怨是,敏捷式可調整的方法引進了可折衷彈性的結構和方法。 儘管有這些誤解,但可以成功調整敏捷原則。 如需克服這些困難的相關信息,請參閱 將 Agile 調整為大型小組。
- 敏捷式沒有效率。 為了適應客戶不斷變化的需求,開發人員會投資每次反覆項目來示範工作產品並收集意見反應。 的確,這些工作可減少花費在開發上的時間。 但儘早納入客戶要求,可節省大量時間。 當功能與客戶的願景保持一致時,開發人員可避免大幅整頓。
- 敏捷式不適合現今的應用程式,通常以數據流為中心。 這類專案通常涉及比使用者介面更多的數據模型化和擷取-轉換-載入 (ETL) 工作負載。 這個事實使得很難以一致、緊密的排程來示範可使用的軟體。 但是藉由調整目標,開發人員仍然可以使用敏捷式方法。 開發人員可以專注於執行數據實驗,而不是努力完成每個反覆專案的工作。 與其每隔幾周呈現工作產品,不如說是想進一步了解數據。
那麼,為什麼有人會考慮敏捷式方法? 很明顯,過去10-15年,圍繞建築軟體的參與規則已經從根本上改變。 許多活動看起來很類似,但我們套用它們的環境和環境明顯不同。
- 比較今天購買軟體與 2000 年代初的樣子。 人們開車到商店購買商務軟體的頻率為何?
- 請考慮如何從客戶收集有關產品的意見反應。 團隊如何了解人們在社交媒體之前對軟體的看法?
- 請考慮小組想要更新及改善其提供軟體的頻率。 每年的更新對現代競爭不再可行。
Forrester 的迭戈·洛·吉迪斯在他的博客 《轉換應用程序傳遞 》(2020年10月)中說,這最好。
“一切都發生了巨大的變化。 除了綠色和清潔,可持續性意味著我們今天建設的東西必須輕鬆和迅速地改變明天。 戰略規劃是短期的,規劃和變化是連續的。“迭戈·洛·吉迪斯,Forrester
這些規則已經改變,世界各地的組織現在會據此調整其軟體開發方法。 敏捷方法和做法不保證能解決每個問題。 但他們確實承諾建立一個文化和環境,其中解決方案會透過共同作業、持續規劃和學習,以及更頻繁地交付高品質軟體的願望。
決定將敏捷式路由移至軟體開發,可能會帶來一些有趣的機會來增強您的DevOps程式。 其中一個主要考慮著重於敏捷式開發與組織目前方法的比較和對比。