之前, 小編在《從瀑布式到 DevOps, 開發(fā)流程經(jīng)歷了什么?》一文中, 梳理了軟件開發(fā)流程的大致演變過程。
其實(shí), 在早期軟件開發(fā)還是「小作坊」作業(yè)的時(shí)候, 沒有形成所謂的開發(fā)流程方法論, 開發(fā)特別倚重個(gè)人能力, 大多都雜亂無章, 所以效率也不高。
20 世紀(jì) 70 年代, 從瀑布式開發(fā)開始, 開發(fā)流程有了一套自己的方法論。一路發(fā)展演進(jìn), 先后涌現(xiàn)了敏捷和 DevOps 等新興理念。可以看出的是, 軟件開發(fā)規(guī)模越來越大, 要求的速度卻越來越快。
01 開發(fā)流程正在「提效」路上一去不回頭
上世紀(jì) 50 年代, 一種項(xiàng)目管理三角 (也稱的三重約束、鐵三角或項(xiàng)目三角) 的模型開始被人們廣泛使用。
三角模型被用來約束項(xiàng)目的發(fā)展過程, 它認(rèn)為:
質(zhì)量工作是由該項(xiàng)目的預(yù)算、時(shí)間和功能來限制;
項(xiàng)目經(jīng)理可以約束之間的平衡;
一個(gè)約束的變化需要其他約束的變化來補(bǔ)償, 否則質(zhì)量將受到影響。
例如, 可以通過增加預(yù)算或縮小范圍來更快地完成項(xiàng)目。同樣, 增加范圍可能需要相應(yīng)增加預(yù)算和進(jìn)度。削減預(yù)算而不調(diào)整時(shí)間表或范圍會導(dǎo)致質(zhì)量下降。也就是說, 好、快、便宜 (范圍、時(shí)間和成本), 只能選擇兩個(gè)。
在早期, 瀑布式開發(fā)與三角模型相關(guān)聯(lián), 由此表明:軟件開發(fā)可以由應(yīng)用程序創(chuàng)建或構(gòu)建所花費(fèi)的時(shí)間長度來定義。
然而, 在當(dāng)時(shí), 創(chuàng)建、測試和部署軟件通常需要很長時(shí)間, 因?yàn)樵陂_發(fā)過程中沒有制衡。結(jié)果是軟件質(zhì)量不佳, 存在缺陷和錯(cuò)誤以及未滿足的時(shí)間表。因此, 瀑布式開發(fā)的重點(diǎn)是軟件項(xiàng)目的長期計(jì)劃。
這種思維方式來自制造和工程, 其中線性過程是有意義的——你先建墻, 再建屋頂。同樣, 軟件開發(fā)問題被視為可以通過計(jì)劃解決的問題。從開始到結(jié)束, 開發(fā)過程都由路線圖明確定義, 路線圖將導(dǎo)致產(chǎn)品的最終交付。
但是, 瀑布式被認(rèn)為是對軟件開發(fā)有害的, 因?yàn)橥ǔＶ钡巾?xiàng)目周期的最后階段才能確定其價(jià)值, 并且在許多情況下項(xiàng)目都失敗了。此外, 客戶直到項(xiàng)目結(jié)束才能看到可運(yùn)行的軟件。
事情在敏捷時(shí)代發(fā)生了改變。
敏捷采取了一種不同的方法, 不再規(guī)劃整個(gè)項(xiàng)目, 承諾預(yù)計(jì)日期, 并對計(jì)劃負(fù)責(zé)。而是假設(shè)并擁抱不確定性, 改變被認(rèn)為是滿足客戶需求的一種方式。
它定義了以下 12 條原則:
(引用)
1. 我們的首要任務(wù)是通過早期和持續(xù)交付有價(jià)值的軟件來滿足客戶。
2. 歡迎不斷變化的需求, 即使是在開發(fā)后期。
3. 敏捷流程利用變化來獲得客戶的競爭優(yōu)勢。
4. 頻繁地交付可工作的軟件, 從幾周到幾個(gè)月不等, 優(yōu)先考慮較短的時(shí)間范圍。
5. 業(yè)務(wù)人員和開發(fā)人員必須在整個(gè)項(xiàng)目中每天一起工作。
6. 圍繞積極的個(gè)人建立項(xiàng)目。
7. 為他們提供所需的環(huán)境和支持, 并相信他們會完成工作。
8. 向開發(fā)團(tuán)隊(duì)和在開發(fā)團(tuán)隊(duì)內(nèi)部傳達(dá)信息最有效的方法是面對面交談。
9. 工作軟件是進(jìn)度的主要衡量標(biāo)準(zhǔn)。
10. 敏捷流程促進(jìn)可持續(xù)發(fā)展。贊助商、開發(fā)者和用戶應(yīng)該能夠無限期地保持恒定的步伐。
11、對卓越技術(shù)和良好設(shè)計(jì)的持續(xù)關(guān)注可提高敏捷性。
12、團(tuán)隊(duì)定期反思如何提高效率, 然后相應(yīng)地調(diào)整和調(diào)整其行為。
從敏捷開始, 短時(shí)間和高效率成為開發(fā)理念中的一個(gè)重點(diǎn)。而 DevOps 則更進(jìn)一步。
某種程度上,DevOps 是一種文化、一種心態(tài)、一種軟件開發(fā)或基礎(chǔ)架構(gòu)的方式, 以及一種構(gòu)建和部署軟件和應(yīng)用程序的方式。其中的精髓是:開發(fā)和運(yùn)維之間沒有墻;它們同時(shí)工作, 沒有孤島。
DevOps 正是基于精益和敏捷兩個(gè)實(shí)踐領(lǐng)域。雖然敏捷和 DevOps 有很多不同之處, 但它們都尋求解決復(fù)雜問題、提高質(zhì)量并圍繞軟件設(shè)計(jì)進(jìn)行創(chuàng)新。
與此同時(shí),DevOps 加快了開發(fā)和運(yùn)維人員之間的工作, 還減少了 Dev 和 Ops 之間的分工。這是因?yàn)?DevOps 要求持續(xù)部署、交付和集成。團(tuán)隊(duì)合作是一體的;問題和故障由開發(fā)、運(yùn)維和其他實(shí)體共同擁有, 例如質(zhì)量保證 (QA)、測試、自動化等。
敏捷與 DevOps 的區(qū)別
總的來說, 無論是敏捷還是 DevOps, 都旨在幫助團(tuán)隊(duì)更快、更高效地工作, 更快地交付高質(zhì)量產(chǎn)品和提高客戶滿意度。
02 天下武功唯快不破!
在敏捷時(shí)代, 一批輕量的軟件工程方法和框架相繼誕生, 它們共同的特點(diǎn)是, 相對傳統(tǒng)軟件工程, 都遵循演進(jìn)和迭代的模型, 過程更加輕量靈活, 以 Scrum 和極限編程 (ExtremeProgramming) 為代表。
早期的敏捷專注的是研發(fā)交付階段, 站在業(yè)務(wù)的角度, 它的目標(biāo)是幫助產(chǎn)品和研發(fā)團(tuán)隊(duì)提升敏捷響應(yīng)能力。但在 DevOps 時(shí)代,IT 不僅要保證產(chǎn)品的開發(fā)和交付, 系統(tǒng)部署和運(yùn)行同樣重要。在敏捷開發(fā)的理念之上, 又補(bǔ)上了運(yùn)維的部分。
目前,DevOps 仍處于高速發(fā)展階段。南京大學(xué)軟件研發(fā)效能實(shí)驗(yàn)室發(fā)布的 DevOps ·云原生 2021 年度中國調(diào)查報(bào)告》顯示,2021 年國內(nèi)企業(yè)的 DevOps 工具的普及程度較 2019 年有明顯上升趨勢。
因此, 為了達(dá)到更快更好的開發(fā)目標(biāo), 不斷有新式的開發(fā)工具涌現(xiàn)出來。
一方面, 不同工具在各領(lǐng)域全面開花, 一起助推 DevOps 的落地。比如 JIRA、Trello 等敏捷開發(fā)工具,Maven、NPM、Gradle 等持續(xù)交付工具,Zabbix、Elastic、Grafana、Kafka、Ansible、Logstash、Prometheus 等自動運(yùn)維工具等等。
另一方面, 一些集大成的工具也同時(shí)應(yīng)用自動化、AI 等技術(shù), 以更好地實(shí)現(xiàn)功能。其中, 飛算 SoFlu 全自動軟件工程平臺便是其中的一個(gè)代表。
飛算 SoFlu 是近年發(fā)布的新一代 JAVA 開發(fā)工具, 截至目前已在包括醫(yī)療、金融、制造、零售等在內(nèi)的多個(gè)行業(yè)使用。
全自動平臺可以通過降低準(zhǔn)入門檻、人力成本和溝通成本, 來極大提升企業(yè)的開發(fā)效率。以工具為核心, 制訂好管理流程, 利用科學(xué)的管理方法, 讓程序員在操作工具時(shí)有規(guī)可循, 從而降低管理風(fēng)險(xiǎn)和溝通風(fēng)險(xiǎn)。
以某大型國有企業(yè)開發(fā)的「百萬人使用級別的電商平臺」項(xiàng)目為例。此前, 該企業(yè)組建數(shù)十人團(tuán)隊(duì)完成開發(fā), 上線后卻在功能性、穩(wěn)定性、安全性等方面問題不斷, 且無法在短期內(nèi)修復(fù)。在使用飛算 SoFlu 全自動軟件工程平臺后, 該企業(yè)僅投入 6 位研發(fā)人員 45 天就高效完成開發(fā)、測試、聯(lián)調(diào)、上線全流程任務(wù)。
具體來說, 單就 Excel 表格文件解析這個(gè)高頻開發(fā)功能, 這在之前, 即使是一個(gè)經(jīng)驗(yàn)豐富的程序員, 也至少需要花費(fèi)半天時(shí)間。但是飛算能夠?qū)r(shí)間壓縮到以分鐘計(jì)算:
1. 編程邏輯流程化, 十分鐘完成開發(fā), 完全不用敲代碼, 拖拉拽即可完成后端開發(fā)。
2. 豐富的組件支持, 涵蓋數(shù)據(jù)庫、redis、api、mongoDB、子流程組件等, 支持循環(huán)、條件判斷、函數(shù)調(diào)用, 通過拖拉拽的方式以及參數(shù)配置實(shí)現(xiàn)等同編寫復(fù)雜代碼的業(yè)務(wù)邏輯。
3. 函數(shù)齊全, 各種 API 函數(shù)應(yīng)有盡有, 快速解決業(yè)務(wù)及功能上的各種需求。
