更新時(shí)間:2020-07-17 來源:黑馬程序員 瀏覽量:
WHAT? 敏捷開發(fā)的定義
敏捷軟件開發(fā)是基于敏捷宣言定義的價(jià)值觀《敏捷軟件開發(fā)宣言》和原則《敏捷軟件的十二條原則》的一系列方法和實(shí)踐的總稱。自組織、跨職能團(tuán)隊(duì)運(yùn)用適合他們自身環(huán)境的實(shí)踐進(jìn)行演進(jìn)得出解決方案。換句話說敏捷開發(fā)是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力,只要在符合價(jià)值觀和原則的基礎(chǔ)上能讓開發(fā)團(tuán)隊(duì)擁有應(yīng)對快速變化需求的能力,這就叫做敏捷開發(fā)。
敏捷開發(fā)宣言
官方原文: http://agilemanifesto.org/ ,中文翻譯內(nèi)容如下:
·個(gè)體和互動(dòng)高于流程和工具
·工作的軟件高于詳盡的文檔
·客戶合作高于合同談判
·響應(yīng)變化高于遵循計(jì)劃
解讀:
·以人為本,沒有比面對面交流更高效的溝通渠道了,基于互相信任的前提,敏捷提倡自治的全功能團(tuán)隊(duì)。在工作形式上,整個(gè)團(tuán)隊(duì)平時(shí)坐在一起工作,從物理空間上創(chuàng)造了更加便捷面對面的溝通機(jī)會(huì)。在團(tuán)隊(duì)職責(zé)上,團(tuán)隊(duì)內(nèi)部具備完成軟件交付的角色(能力),團(tuán)隊(duì)所有人對軟件的質(zhì)量負(fù)責(zé),開發(fā)過程由團(tuán)隊(duì)內(nèi)部把控,業(yè)務(wù)價(jià)值團(tuán)隊(duì)內(nèi)部快速流動(dòng),在任何環(huán)節(jié)都能及時(shí)獲得反饋。同時(shí),每個(gè)角色都更容易從全局視角去思考軟件,避免了傳統(tǒng)部門墻模式下的視角割裂和協(xié)作障礙。
·為客戶交付可工作的軟件是我們的核心目標(biāo),我們應(yīng)該盡早交付可進(jìn)行端到端測試的代碼,該目標(biāo)決定了我們不應(yīng)該花過多精力在面面俱到的文檔上,但這不代表我們要抵制任何文檔。實(shí)踐證明,輕量級(jí)的文檔策略有助于團(tuán)隊(duì)高質(zhì)量交付可工作的軟件。
主動(dòng)擁抱變化,及時(shí)響應(yīng),持續(xù)交付。
·通過高效的協(xié)作,獲取快速的反饋,從而盡早做出調(diào)整,減少浪費(fèi)
敏捷開發(fā)十二原則
官方原文: http://agilemanifesto.org/principles.html ,中文翻譯內(nèi)容如下:
·我們最重要的目標(biāo),是通過及早和持續(xù)不斷地交付有價(jià)值的軟件使客戶滿意;
·欣然面對需求變化,即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢,敏捷過程掌控變化;
·經(jīng)常地交付可工作的軟件,相隔幾星期或一兩個(gè)月,傾向于采取較短的周期;
·業(yè)務(wù)人員和開發(fā)人員必須相互合作,項(xiàng)目中的每一天都不例外;
·激發(fā)個(gè)體的斗志,以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援,輔以信任,從而達(dá)成目標(biāo);
·不論團(tuán)隊(duì)內(nèi)外,傳遞信息效果最好效率也最高的方式是面對面的交談;
·可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn);
·敏捷過程倡導(dǎo)可持續(xù)開發(fā)。責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù);
·堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì),敏捷能力由此增強(qiáng);
·以簡潔為本,它是極力減少不必要工作量的藝術(shù);
·最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì);
·團(tuán)隊(duì)定期地反思如何能提高成效,并依此調(diào)整自身的行為表現(xiàn)。
WHY? 為何使用敏捷
在敏捷開發(fā)還沒有出來之前,大部分公司的開發(fā)模式基本都采取瀑布式開發(fā)。而瀑布式開發(fā)往往具有如下幾個(gè)特點(diǎn):
·文檔:尤其看重文檔,項(xiàng)目初期就要求文檔設(shè)計(jì)的非常完善,一切以詳細(xì)的文檔為導(dǎo)向
·開發(fā)周期:固定且漫長,至少以數(shù)月為單位,團(tuán)隊(duì)成員嚴(yán)格按照項(xiàng)目排期進(jìn)行開發(fā)
·人員規(guī)模:人數(shù)眾多,一般都是整個(gè)技術(shù)部門全員一起參與某一開發(fā)周期的項(xiàng)目開發(fā)
·需求變動(dòng):定好的需求,一般不會(huì)變動(dòng),所以需求一開始就要設(shè)計(jì)的非常完善
·返工:由于軟件生命周期嚴(yán)格按順序劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫、軟件測試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng),并且規(guī)定了它們自上而下、相互銜接的固定次序,如同瀑布流水,逐級(jí)下落。那么一旦開始進(jìn)入開發(fā),那么不可能返工,因?yàn)榉倒?huì)帶來巨大的成本開銷。
·版本變更:每個(gè)項(xiàng)目項(xiàng)目開發(fā)階段都會(huì)有明確的目標(biāo),目標(biāo)如果未完成不會(huì)進(jìn)入下一階段,也就意味著版本變更不會(huì)太頻繁
根據(jù)傳統(tǒng)瀑布式開發(fā)的以上特性,我們發(fā)現(xiàn),面對互聯(lián)網(wǎng)時(shí)代用戶多變的需求,如果按照瀑布式開發(fā)進(jìn)行,那么幾乎很難響應(yīng)需求的變更,難以做到快速交付新版本的產(chǎn)品。而并不是說瀑布式開發(fā)就一定不行,在傳統(tǒng)行業(yè)依然是主流開發(fā)模式。
而敏捷開發(fā)由于迭代周期短(一般周為單位)、人員規(guī)模少、隨時(shí)響應(yīng)變化,具有更大的靈活性、更少的投入、更高效的開發(fā)、更及時(shí)的交付、更大程度的降低風(fēng)險(xiǎn)(及時(shí)了解市場需求,降低產(chǎn)品不適用風(fēng)險(xiǎn))。從這個(gè)方面來講敏捷開發(fā)是完全可以適用互聯(lián)網(wǎng)時(shí)代下用戶多變的需求,也就是我們常說的小步快跑,將一個(gè)大的需求拆分成各個(gè)小的需求,針對某個(gè)階段的小需求,組織少量的人員,借助于一定的規(guī)范、流程、工具、會(huì)議,從而達(dá)到快速交付上線的目的。
HOW? 如何實(shí)施敏捷
互聯(lián)網(wǎng)IT職能團(tuán)隊(duì),如果要實(shí)施敏捷開發(fā)離不開四要素:規(guī)范、流程、工具、會(huì)議。敏捷的核心是人,只有人人參與遵守約定,那么敏捷開發(fā)才能高效進(jìn)行。如下圖,敏捷開發(fā)流程圖。
規(guī)范
規(guī)范是一種契約精神,要求團(tuán)隊(duì)所有成員都要遵守約定,把控規(guī)范細(xì)節(jié),最終高質(zhì)量交付成果。
軟件編碼規(guī)范
編碼規(guī)范,規(guī)定團(tuán)隊(duì)技術(shù)人員在編寫代碼時(shí)應(yīng)該遵守的開發(fā)規(guī)則,比如命名規(guī)范、日志規(guī)范、注釋規(guī)范、單元測試規(guī)范、異常處理規(guī)范等等。
數(shù)據(jù)庫設(shè)計(jì)規(guī)范
數(shù)據(jù)庫設(shè)計(jì)規(guī)范,要求技術(shù)人員在設(shè)計(jì)數(shù)據(jù)庫時(shí)要考慮表設(shè)計(jì)、索引設(shè)計(jì)、SQL編寫等方面的規(guī)則。
API設(shè)計(jì)規(guī)范
API規(guī)范一般意義指的是前后端分離時(shí)服務(wù)端網(wǎng)關(guān)系統(tǒng)對外提供的API規(guī)范,除此之外,在分布式環(huán)境中,服務(wù)端各模塊系統(tǒng)會(huì)進(jìn)行接口間通信,寫接口時(shí)也要求遵守設(shè)計(jì)規(guī)范。
GIT管理規(guī)范
GIT管理規(guī)范,要求技術(shù)人員在分支命名、提交注釋、代碼合并等方面要遵守特定的規(guī)則。
版本管理規(guī)范
版本管理規(guī)范,軟件發(fā)布包的版本號(hào)管理要遵守特定的規(guī)則,每次版本升級(jí)的變更特性列表要求詳細(xì)編寫。
測試規(guī)范
測試規(guī)范,用于約定測試團(tuán)隊(duì)的測試范圍和測試標(biāo)準(zhǔn),具體包括功能測試、接口測試、性能測試、自動(dòng)化測試。
郵件規(guī)范
郵件規(guī)范,約定團(tuán)隊(duì)成員要遵守發(fā)送郵件的標(biāo)題名編寫規(guī)范,不同類型的郵件對應(yīng)的標(biāo)題關(guān)鍵字各不相同,方便及時(shí)通過關(guān)鍵詞搜索歷史郵件。另外根據(jù)團(tuán)隊(duì)不同,有的團(tuán)隊(duì)可能會(huì)要求團(tuán)隊(duì)成員發(fā)送每日日報(bào)、每周周報(bào),日報(bào)和周報(bào)都是通過郵件的形式進(jìn)行發(fā)送。
部署規(guī)范
部署規(guī)范,用于約定生產(chǎn)服務(wù)的部署方式,具體采用金絲雀部署、藍(lán)綠部署、還是其他部署方式。
結(jié)對編程
結(jié)對編程,一般指的是2個(gè)人同時(shí)負(fù)責(zé)共同模塊功能的開發(fā)。兩個(gè)人在一起探討很容易產(chǎn)生思想的火花,不容易走上偏路,可以共同分析設(shè)計(jì)、寫測試用例、編寫代碼。結(jié)對編程還有個(gè)好處就是,當(dāng)一方開發(fā)人員離職時(shí),不至于花費(fèi)很多的交接時(shí)間,不會(huì)出現(xiàn)因?yàn)榫o急需求來臨時(shí)由于某開發(fā)人員離職造成無人可以負(fù)責(zé)的現(xiàn)象。
流程
一般互聯(lián)網(wǎng)公司的開發(fā)流程按照順序大致分為如下幾個(gè)階段:
需求整理階段、排期設(shè)計(jì)階段、開發(fā)階段、測試階段、部署階段。整個(gè)流程在實(shí)施的過程中必要時(shí)允許返工,允許駁回需求并且可隨時(shí)調(diào)整需求。
需求整理階段
一般是產(chǎn)品部門負(fù)責(zé),產(chǎn)品從需求池中根據(jù)優(yōu)先級(jí)篩選出優(yōu)先級(jí)最高的需求進(jìn)行詳細(xì)設(shè)計(jì),并產(chǎn)出PRD成果給到技術(shù)部門。
排期設(shè)計(jì)階段
排期先要先進(jìn)行需求評審,需求評審會(huì)由產(chǎn)品負(fù)責(zé)人發(fā)起,評審會(huì)中所有參與人就需求的問題進(jìn)行討論,需求敲定后,技術(shù)部門負(fù)責(zé)人或本次迭代負(fù)責(zé)人將詳細(xì)的項(xiàng)目開發(fā)計(jì)劃發(fā)送至所有干系人。
特殊說明的是,如經(jīng)驗(yàn)證出現(xiàn)不合理需求問題,開發(fā)團(tuán)隊(duì)可打回需求拒絕排期開發(fā)。
開發(fā)階段
開發(fā)階段各成員按照計(jì)劃有序進(jìn)行開發(fā),開發(fā)過程有任何需求疑問及時(shí)找產(chǎn)品經(jīng)理溝通,產(chǎn)品經(jīng)理如在開發(fā)過程中有緊急臨時(shí)需求,可組會(huì)討論后,優(yōu)先緊急需求的開發(fā);如有需求變動(dòng),可調(diào)整排期后重新發(fā)出排期計(jì)劃。
注意強(qiáng)調(diào)單元測試的必要性,開發(fā)人員必須為自己編寫的代碼質(zhì)量負(fù)責(zé),自測完畢后才可提交給測試人員。
測試階段
開發(fā)完畢自測通過后,開發(fā)人員通知測試人員基于測試項(xiàng)目分支開始進(jìn)行測試環(huán)境的測試,如果出現(xiàn)任何BUG則將BUG提交到缺陷管理系統(tǒng),開發(fā)人員根據(jù)BUG列表修復(fù)后更新BUG任務(wù)狀態(tài),然后測試復(fù)測。直到測試部門測試完畢后,符合上線要求后,方可通知運(yùn)維部門進(jìn)行上線操作。
特殊說明的是,如出現(xiàn)提測的功能部署后系統(tǒng)不能正常運(yùn)行影響測試,測試團(tuán)隊(duì)可打回給開發(fā)拒絕本次測試,直到開發(fā)提測的代碼沒問題為止。
部署階段
部署階段,可分為預(yù)發(fā)環(huán)境部署和生產(chǎn)環(huán)境部署,流程大致相似。都是基于完成測試成功的對應(yīng)環(huán)境的項(xiàng)目分支通過CI工具進(jìn)行持續(xù)集成和部署。部署時(shí)的網(wǎng)關(guān)開關(guān)切換機(jī)制應(yīng)考慮到位,盡量做到部署時(shí)對用戶無感知,部署完畢后測試人員在生產(chǎn)環(huán)境仍需復(fù)測一次,確保上線成果的正確性。
一定要保證如果部署過程出現(xiàn)問題要有完善的回滾機(jī)制。
工具
敏捷團(tuán)隊(duì)若要執(zhí)行落地離不開很多高效的協(xié)作工具,這里我列舉一些非常實(shí)用的工具供大家參考,工具的安裝步驟不在本文的講解范圍內(nèi)。
代碼管理工具
一般選用基于GIT協(xié)議的分布式代碼管理工具進(jìn)行代碼管理,常用的有g(shù)itlab、gitee、github。
項(xiàng)目管理工具
項(xiàng)目管理工具的意義在于管控所有迭代過程中的具體任務(wù),用于跟進(jìn)開發(fā)進(jìn)度、管控開發(fā)效率。常用的工具有tower、jira。每個(gè)迭代周期內(nèi)的任務(wù)會(huì)在排期過程中由部門負(fù)責(zé)人分配給每個(gè)人員,任務(wù)完畢后要求及時(shí)拖動(dòng)任務(wù)狀態(tài),方便領(lǐng)導(dǎo)跟進(jìn)查看進(jìn)展。
知識(shí)庫工具
知識(shí)庫管理工具的作用在于團(tuán)隊(duì)協(xié)作的所有資料,方便團(tuán)隊(duì)成員有需要時(shí)隨時(shí)進(jìn)行查看。比如產(chǎn)品團(tuán)隊(duì)會(huì)將每個(gè)版本的產(chǎn)品PRD文件放入產(chǎn)品團(tuán)隊(duì)的知識(shí)庫目錄下,開發(fā)團(tuán)隊(duì)會(huì)將開發(fā)設(shè)計(jì)架構(gòu)圖、API接口文檔等放入技術(shù)團(tuán)隊(duì)的知識(shí)庫目錄下,類似的,所有團(tuán)隊(duì)都可將用于團(tuán)隊(duì)協(xié)作的資料存入本團(tuán)隊(duì)對應(yīng)的知識(shí)庫目錄中。
缺陷管理工具
缺陷管理工具用于測試團(tuán)隊(duì)在測試階段提交BUG任務(wù)給開發(fā)人員,常見的工具有禪道、jira。
持續(xù)集成工具
持續(xù)集成工具目的在于實(shí)現(xiàn)自動(dòng)構(gòu)建、測試、打包、部署到各個(gè)環(huán)境中,建議使用docker進(jìn)行進(jìn)行部署,保證各個(gè)環(huán)境中系統(tǒng)運(yùn)行不會(huì)出現(xiàn)環(huán)境問題。目前主流的持續(xù)集成工具有Jenkins、Bamboo。
SQL審核工具
生產(chǎn)系統(tǒng)上線后,如果出現(xiàn)BUG要修復(fù)生產(chǎn)數(shù)據(jù),應(yīng)由開發(fā)人員提交修復(fù)的SQL到審計(jì)系統(tǒng)中并提交申請,團(tuán)隊(duì)負(fù)責(zé)人負(fù)責(zé)一審,DBA負(fù)責(zé)二審,二審?fù)ㄟ^后SQL會(huì)自動(dòng)執(zhí)行。SQL審計(jì)工具上所有提交的SQL操作日志全部都會(huì)保留下來,方便追責(zé)時(shí)隨時(shí)查看。常見的SQL審核工具有Yearning。
容器管理工具
用于對docker進(jìn)行編排管理,比如常用的docker動(dòng)態(tài)擴(kuò)容、升級(jí)等。目前主流的的容器編排工具是K8S。
運(yùn)維安全管理工具
主要用于管理機(jī)房或者云端所有服務(wù)器資源,控制開發(fā)人員權(quán)限,所有開發(fā)人員如需登錄目標(biāo)服務(wù)器,必須登錄安全管理機(jī)后才有權(quán)限訪問。常用的安全管理工具是jumpserver。
會(huì)議
敏捷開發(fā)宣言強(qiáng)調(diào)個(gè)體溝通的重要性,所以會(huì)議的形式能增強(qiáng)溝通及時(shí)發(fā)現(xiàn)并修正問題,如下列舉了敏捷開發(fā)過程中常見的會(huì)議類型。
每日站立會(huì)議
站會(huì)有兩種,早晨站立會(huì)或晚間站立會(huì)(不同的團(tuán)隊(duì)只要求其中一種即可),站立會(huì)在每天固定的時(shí)間要求大家放下手中的活全體起立,每個(gè)團(tuán)隊(duì)成員挨個(gè)發(fā)言,向所有成員分享上一日活今日完成的任務(wù)、遇到的問題、接下來的計(jì)劃,如有阻礙開發(fā)進(jìn)展的問題可提出但不展開討論,會(huì)后關(guān)聯(lián)人再詳細(xì)溝通。站會(huì)期間,有的團(tuán)隊(duì)會(huì)采用看板形式(實(shí)際就是一個(gè)白畫板多泳道)自己拖動(dòng)任務(wù)狀態(tài)。
迭代總結(jié)會(huì)議
迭代總結(jié)會(huì)議一般在某個(gè)迭代完成后盡快召開,此會(huì)議的目的在于復(fù)盤上次迭代過程中的整體情況,包括好的和不好的,好的繼續(xù)精進(jìn),不好的要反思改正。
代碼Review會(huì)議
代碼檢查會(huì)議,會(huì)根團(tuán)隊(duì)實(shí)際情況不定期的召開,目的在于規(guī)范團(tuán)隊(duì)開發(fā)人員的編碼規(guī)范,要求注重代碼質(zhì)量。
每周總結(jié)會(huì)議
每周總結(jié)會(huì)議,一般定在每周五進(jìn)行召開,目的在于總結(jié)本周團(tuán)隊(duì)的整體的工作進(jìn)展,遇到的問題;會(huì)上有問題要及時(shí)匯總,要求問題負(fù)責(zé)人會(huì)后及時(shí)給出解決方案和時(shí)間節(jié)點(diǎn)。
技術(shù)分享會(huì)議
技術(shù)分享會(huì),會(huì)根據(jù)團(tuán)隊(duì)情況不定期召開,目的在于讓有經(jīng)驗(yàn)的團(tuán)隊(duì)成員分享實(shí)戰(zhàn)經(jīng)驗(yàn),提升團(tuán)隊(duì)整體水平。
總結(jié)
如上,你大概花費(fèi)10分鐘就基本了解了敏捷開發(fā)團(tuán)隊(duì)的樣貌,結(jié)果你發(fā)現(xiàn)傳說中的敏捷開發(fā)也并沒有那么的神奇。如果你的團(tuán)隊(duì)中出現(xiàn)了我文章提到的敏捷實(shí)施離不開的規(guī)范、流程、工具、會(huì)議這四要素的內(nèi)容,那么你的團(tuán)隊(duì)就是一支敏捷開發(fā)的團(tuán)隊(duì)。
猜你喜歡:
黑馬程序員java培訓(xùn)課程