掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
兩者之間的區(qū)別在于開發(fā)完畢之后發(fā)生的事情。

創(chuàng)新互聯(lián)建站長期為上千客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺(tái),與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為樂昌企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè),樂昌網(wǎng)站改版等技術(shù)服務(wù)。擁有十年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
早期,軟件開發(fā)并沒有特定的管理流程。隨后出現(xiàn)了瀑布開發(fā)流程Waterfall,它提出軟件開發(fā)活動(dòng)可以用開發(fā)和構(gòu)建應(yīng)用所耗費(fèi)的時(shí)間來定義。
那時(shí)候,由于在開發(fā)流程中沒有審查環(huán)節(jié)和權(quán)衡考慮,常常需要花費(fèi)很長的時(shí)間來開發(fā)、測(cè)試和部署軟件。交付的軟件也是帶有缺陷和 Bug 的質(zhì)量較差的軟件,而且交付時(shí)間也不滿足要求。那時(shí)候軟件項(xiàng)目管理的重點(diǎn)是長期而拖沓的計(jì)劃。
瀑布流程與三重約束模型triple constraint model相關(guān),三重約束模型也稱為項(xiàng)目管理三角形project management triangle。三角形的每一個(gè)邊代表項(xiàng)目管理三要素的一個(gè)要素: 范圍、時(shí)間和成本。正如 Angelo Baretta 寫到,三重約束模型“認(rèn)為成本是時(shí)間和范圍的函數(shù),這三個(gè)約束以一種確定的、可預(yù)測(cè)的方式相互作用?!绻覀兿肟s短時(shí)間表(時(shí)間),就必須增加成本。如果我們想增加范圍,就必須增加成本或時(shí)間?!?/p>
瀑布流程來源于生產(chǎn)和工程領(lǐng)域,這些領(lǐng)域適合線性化的流程:正如房屋封頂之前需要先蓋好支撐墻。相似地,軟件開發(fā)問題被認(rèn)為可以通過提前做好計(jì)劃來解決。從頭到尾,開發(fā)流程均由路線圖清晰地定義,沿著路線圖就可以得到最終交付的產(chǎn)品。
最終,瀑布模型被認(rèn)為對(duì)軟件開發(fā)是不利的而且違反人的直覺,因?yàn)橥ǔV钡介_發(fā)流程的最后才能體現(xiàn)出項(xiàng)目的價(jià)值,這導(dǎo)致許多項(xiàng)目最終都以失敗告終。而且,在項(xiàng)目結(jié)束前客戶看不到任何可以工作的軟件。
敏捷Agile采用了一種不同的方法,它拋棄了規(guī)劃整個(gè)項(xiàng)目,承諾估計(jì)的時(shí)間點(diǎn),簡(jiǎn)單的遵循計(jì)劃。與瀑布流程相反,它假設(shè)和擁抱不確定性。它的理念是以響應(yīng)變化代替討論過去,它認(rèn)為變更是客戶需求的一部分。
敏捷由敏捷宣言Agile Manifesto代言,敏捷宣言定義了 12 條原則(LCTT 譯注:此處沒有采用本文原本的簡(jiǎn)略句式,而是摘錄了來自敏捷軟件開發(fā)宣言官方的中文譯本):
敏捷的四個(gè)核心價(jià)值觀是(LCTT 譯注:此處譯文同樣來自敏捷軟件開發(fā)宣言官方):
這與瀑布流程死板的計(jì)劃風(fēng)格相反。在敏捷流程中,客戶是開發(fā)團(tuán)隊(duì)的一員,而不僅僅是在項(xiàng)目開始時(shí)參與項(xiàng)目需求的定義,在項(xiàng)目結(jié)束時(shí)驗(yàn)收最終的產(chǎn)品??蛻魩兔F(tuán)隊(duì)完成驗(yàn)收標(biāo)準(zhǔn),并在整個(gè)過程中保持投入。另外,敏捷需要整個(gè)組織的變化和持續(xù)的改進(jìn)。開發(fā)團(tuán)隊(duì)和其他團(tuán)隊(duì)一起合作,包括項(xiàng)目管理團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)。做什么和計(jì)劃什么時(shí)候做由指定的角色領(lǐng)導(dǎo),并由整個(gè)團(tuán)隊(duì)同意。
敏捷軟件開發(fā)
敏捷軟件開發(fā)需要自適應(yīng)的規(guī)劃、演進(jìn)式的開發(fā)和交付。許多軟件開發(fā)方法、框架和實(shí)踐遵從敏捷的理念,包括:
所有這些已經(jīng)被單獨(dú)用于或一起用于開發(fā)和部署軟件。最常用的是 Scrum、看板(或 Scrumban)和 DevOps。
Scrum 是一個(gè)框架,采用該框架的團(tuán)隊(duì)通常由一個(gè) Scrum 教練、產(chǎn)品經(jīng)理和開發(fā)人員組成,該團(tuán)隊(duì)以跨職能、自主的工作方式運(yùn)作,能夠加快軟件交付速度從而給客戶帶來巨大的商業(yè)價(jià)值。其關(guān)注點(diǎn)是較小增量的快速迭代。
看板 是一個(gè)敏捷框架,有時(shí)也叫工作流管理系統(tǒng),它能幫助團(tuán)隊(duì)可視化他們的工作從而最大化效率(因而變得敏捷)。看板通常由數(shù)字或物理展示板來呈現(xiàn)。團(tuán)隊(duì)的工作在展示板上隨著進(jìn)度而移動(dòng),例如從未啟動(dòng)到進(jìn)行中,一直到測(cè)試中、已完成??窗迨沟妹總€(gè)團(tuán)隊(duì)成員可以隨時(shí)查看到所有工作的狀態(tài)。
DevOps 是一種文化,是一種思維狀態(tài),是一種軟件開發(fā)的方式或者基礎(chǔ)設(shè)施的方式,也是一種構(gòu)建和部署軟件和應(yīng)用的方式。它假設(shè)開發(fā)和運(yùn)維之間沒有隔閡,他們一起合作,沒有矛盾。
DevOps 基于其它兩個(gè)領(lǐng)域的實(shí)踐: 精益和敏捷。DevOps 不是一個(gè)公司內(nèi)的崗位或角色;它是一個(gè)組織或團(tuán)隊(duì)對(duì)持續(xù)交付、持續(xù)部署和持續(xù)集成的堅(jiān)持不懈的追求。Gene Kim(Phoenix 項(xiàng)目和 Unicorn 項(xiàng)目的作者)認(rèn)為,有三種方式定義 DevOps 的理念:
DevOps 不會(huì)憑空產(chǎn)生;它是一種靈活的實(shí)踐,它的本質(zhì)是一種關(guān)于軟件開發(fā)和 IT 或基礎(chǔ)設(shè)施實(shí)施的共享文化和思維方式。
當(dāng)你想到自動(dòng)化、云、微服務(wù)時(shí),你會(huì)想到 DevOps。在一次訪談中,《加速構(gòu)建和擴(kuò)張高性能技術(shù)組織》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 這樣解釋到:
DevOps 和敏捷有相似性,但是它們不完全相同,一些人認(rèn)為 DevOps 比敏捷更好。為了避免造成混淆,深入地了解它們是很重要的。
相似之處
不同之處
兩者的差異在于軟件開發(fā)完成后發(fā)生的事情。
敏捷中,不同的人負(fù)責(zé)軟件的開發(fā)、測(cè)試和部署。而 DevOps 工程角色負(fù)責(zé)所有活動(dòng),開發(fā)即運(yùn)維,運(yùn)維即開發(fā)。
DevOps 更關(guān)注于削減成本,而敏捷則是精益和減少浪費(fèi)的代名詞,側(cè)重于像敏捷項(xiàng)目會(huì)計(jì)和最小可行產(chǎn)品的概念。
敏捷專注于并體現(xiàn)了經(jīng)驗(yàn)主義(適應(yīng)、透明和檢查),而不是預(yù)測(cè)性措施。
總結(jié)
敏捷和 DevOps 是截然不同的,盡管它們的相似之處使人們認(rèn)為它們是相同的。這對(duì)敏捷和 DevOps 都是一種傷害。
根據(jù)我作為一名敏捷專家的經(jīng)驗(yàn),我發(fā)現(xiàn)對(duì)于組織和團(tuán)隊(duì)從高層次上了解敏捷和 DevOps 是什么,以及它們?nèi)绾螏椭鷪F(tuán)隊(duì)更高效地工作,更快地交付高質(zhì)量產(chǎn)品從而提高客戶滿意度非常有價(jià)值。
敏捷和 DevOps 絕不是對(duì)抗性的(或至少?zèng)]有這個(gè)意圖)。在敏捷革命中,它們更像是盟友而不是敵人。敏捷和 DevOps 可以相互協(xié)作一致對(duì)外,因此可以在相同的場(chǎng)合共存。

我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流