兩者之間的區別在於開發完畢之後發生的事情。
早期,軟體開發並沒有特定的管理流程。隨後出現了瀑布開發流程,它提出軟體開發活動可以用開發和構建應用所耗費的時間來定義。
那時候,由於在開發流程中沒有審查環節和權衡考慮,常常需要花費很長的時間來開發、測試和部署軟體。交付的軟體也是帶有缺陷和 Bug 的品質較差的軟體,而且交付時間也不滿足要求。那時候軟體專案管理的重點是長期而拖沓的計劃。
瀑布流程與三重約束模型相關,三重約束模型也稱為專案管理三角形。三角形的每一個邊代表專案管理三要素的一個要素: 範圍、時間和成本。正如 Angelo Baretta 寫到,三重約束模型“認為成本是時間和範圍的函數,這三個約束以一種確定的、可預測的方式相互作用。……如果我們想縮短時間表(時間),就必須增加成本。如果我們想增加範圍,就必須增加成本或時間。”
瀑布流程來源於生產和工程領域,這些領域適合線性化的流程:正如房屋封頂之前需要先蓋好支撐牆。相似地,軟體開發問題被認為可以通過提前做好計劃來解決。從頭到尾,開發流程均由路線圖清晰地定義,沿著路線圖就可以得到最終交付的產品。
最終,瀑布模型被認為對軟體開發是不利的而且違反人的直覺,因為通常直到開發流程的最後才能體現出專案的價值,這導致許多專案最終都以失敗告終。而且,在專案結束前客戶看不到任何可以工作的軟體。
敏捷採用了一種不同的方法,它拋棄了規劃整個專案,承諾估計的時間點,簡單的遵循計劃。與瀑布流程相反,它假設和擁抱不確定性。它的理念是以響應變化代替討論過去,它認為變更是客戶需求的一部分。
敏捷由敏捷宣言代言,敏捷宣言定義了 12 條原則(LCTT 譯註:此處沒有採用本文原本的簡略句式,而是摘錄了來自敏捷軟體開發宣言官方的中文譯本):
敏捷的四個核心價值觀是(LCTT 譯註:此處譯文同樣來自敏捷軟體開發宣言官方):
這與瀑布流程死板的計劃風格相反。在敏捷流程中,客戶是開發團隊的一員,而不僅僅是在專案開始時參與專案需求的定義,在專案結束時驗收最終的產品。客戶幫忙團隊完成驗收標準,並在整個過程中保持投入。另外,敏捷需要整個組織的變化和持續的改進。開發團隊和其他團隊一起合作,包括專案管理團隊和測試團隊。做什麼和計劃什麼時候做由指定的角色領導,並由整個團隊同意。
敏捷軟體開發需要自適應的規劃、演進式的開發和交付。許多軟體開發方法、框架和實踐遵從敏捷的理念,包括:
所有這些已經被單獨用於或一起用於開發和部署軟體。最常用的是 Scrum、看板(或 Scrumban)和 DevOps。
Scrum 是一個框架,採用該框架的團隊通常由一個 Scrum 教練、產品經理和開發人員組成,該團隊以跨職能、自主的工作方式運作,能夠加快軟體交付速度從而給客戶帶來巨大的商業價值。其關注點是較小增量的快速迭代。
看板 是一個敏捷框架,有時也叫工作流管理系統,它能幫助團隊視覺化他們的工作從而最大化效率(因而變得敏捷)。看板通常由數位或物理展示板來呈現。團隊的工作在展示板上隨著進度而移動,例如從未啟動到進行中,一直到測試中、已完成。看板使得每個團隊成員可以隨時檢視到所有工作的狀態。
DevOps 是一種文化,是一種思維狀態,是一種軟體開發的方式或者基礎設施的方式,也是一種構建和部署軟體和應用的方式。它假設開發和運維之間沒有隔閡,他們一起合作,沒有矛盾。
DevOps 基於其它兩個領域的實踐: 精益和敏捷。DevOps 不是一個公司內的崗位或角色;它是一個組織或團隊對持續交付、持續部署和持續整合的堅持不懈的追求。Gene Kim(Phoenix 專案和 Unicorn 專案的作者)認為,有三種方式定義 DevOps 的理念:
DevOps 不會憑空產生;它是一種靈活的實踐,它的本質是一種關於軟體開發和 IT 或基礎設施實施的共用文化和思維方式。
當你想到自動化、雲、微服務時,你會想到 DevOps。在一次訪談中,《加速構建和擴張高效能技術組織》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 這樣解釋到:
- 軟體交付能力很重要,它極大地影響到組織的成果,例如利潤、市場份額、品質、客戶滿意度以及組織戰略目標的達成。
- 優秀的團隊能達到很高的交付量、穩定性和品質;他們並沒有為了獲得這些屬性而進行取捨。
- 你可以通過實施精益、敏捷和 DevOps 中的實踐來提升能力。
- 實施這些實踐和能力也會影響你的組織文化,並且會進一步對你的軟體交付能力和組織能力產生有益的提升。
- 懂得怎樣改進能力需要做很多工作。
DevOps 和敏捷有相似性,但是它們不完全相同,一些人認為 DevOps 比敏捷更好。為了避免造成混淆,深入地了解它們是很重要的。
敏捷 | DevOps |
---|---|
從客戶得到反饋 | 從自己得到反饋 |
較小的發布週期 | 較小的發布週期,立即反饋 |
聚焦於速度 | 聚焦於速度和自動化 |
對業務不是最好 | 對業務最好 |
敏捷和 DevOps 是截然不同的,儘管它們的相似之處使人們認為它們是相同的。這對敏捷和 DevOps 都是一種傷害。
根據我作為一名敏捷專家的經驗,我發現對於組織和團隊從高層次上了解敏捷和 DevOps 是什麼,以及它們如何幫助團隊更高效地工作,更快地交付高品質產品從而提高客戶滿意度非常有價值。
敏捷和 DevOps 絕不是對抗性的(或至少沒有這個意圖)。在敏捷革命中,它們更像是盟友而不是敵人。敏捷和 DevOps 可以相互共同作業一致對外,因此可以在相同的場合共存。