什么是敏捷開(kāi)發(fā)？十分鐘了解

WHAT? 敏捷開(kāi)發(fā)的定義

敏捷軟件開(kāi)發(fā)是基于敏捷宣言定義的價(jià)值觀《敏捷軟件開(kāi)發(fā)宣言》和原則《敏捷軟件的十二條原則》的一系列方法和實(shí)踐的總稱。自組織、跨職能團(tuán)隊(duì)運(yùn)用適合他們自身環(huán)境的實(shí)踐進(jìn)行演進(jìn)得出解決方案。換句話說(shuō)敏捷開(kāi)發(fā)是一種應(yīng)對(duì)快速變化的需求的一種軟件開(kāi)發(fā)能力，只要在符合價(jià)值觀和原則的基礎(chǔ)上能讓開(kāi)發(fā)團(tuán)隊(duì)擁有應(yīng)對(duì)快速變化需求的能力，這就叫做敏捷開(kāi)發(fā)。

敏捷開(kāi)發(fā)宣言

官方原文： http://agilemanifesto.org/ ，中文翻譯內(nèi)容如下：

·個(gè)體和互動(dòng)高于流程和工具

·工作的軟件高于詳盡的文檔

·客戶合作高于合同談判

·響應(yīng)變化高于遵循計(jì)劃

解讀：

·以人為本，沒(méi)有比面對(duì)面交流更高效的溝通渠道了，基于互相信任的前提，敏捷提倡自治的全功能團(tuán)隊(duì)。在工作形式上，整個(gè)團(tuán)隊(duì)平時(shí)坐在一起工作，從物理空間上創(chuàng)造了更加便捷面對(duì)面的溝通機(jī)會(huì)。在團(tuán)隊(duì)職責(zé)上，團(tuán)隊(duì)內(nèi)部具備完成軟件交付的角色(能力)，團(tuán)隊(duì)所有人對(duì)軟件的質(zhì)量負(fù)責(zé)，開(kāi)發(fā)過(guò)程由團(tuán)隊(duì)內(nèi)部把控，業(yè)務(wù)價(jià)值團(tuán)隊(duì)內(nèi)部快速流動(dòng)，在任何環(huán)節(jié)都能及時(shí)獲得反饋。同時(shí)，每個(gè)角色都更容易從全局視角去思考軟件，避免了傳統(tǒng)部門(mén)墻模式下的視角割裂和協(xié)作障礙。

·為客戶交付可工作的軟件是我們的核心目標(biāo)，我們應(yīng)該盡早交付可進(jìn)行端到端測(cè)試的代碼，該目標(biāo)決定了我們不應(yīng)該花過(guò)多精力在面面俱到的文檔上，但這不代表我們要抵制任何文檔。實(shí)踐證明，輕量級(jí)的文檔策略有助于團(tuán)隊(duì)高質(zhì)量交付可工作的軟件。

主動(dòng)擁抱變化，及時(shí)響應(yīng)，持續(xù)交付。

·通過(guò)高效的協(xié)作，獲取快速的反饋，從而盡早做出調(diào)整，減少浪費(fèi)

敏捷開(kāi)發(fā)十二原則

官方原文： http://agilemanifesto.org/principles.html ，中文翻譯內(nèi)容如下：

·我們最重要的目標(biāo)，是通過(guò)及早和持續(xù)不斷地交付有價(jià)值的軟件使客戶滿意；

·欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化；

·經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期；

·業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外；

·激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)；

·不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談；

·可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)；

·敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)；

·堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)；

·以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)；

·最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)；

·團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的行為表現(xiàn)。

WHY? 為何使用敏捷

在敏捷開(kāi)發(fā)還沒(méi)有出來(lái)之前，大部分公司的開(kāi)發(fā)模式基本都采取瀑布式開(kāi)發(fā)。而瀑布式開(kāi)發(fā)往往具有如下幾個(gè)特點(diǎn)：

·文檔：尤其看重文檔，項(xiàng)目初期就要求文檔設(shè)計(jì)的非常完善，一切以詳細(xì)的文檔為導(dǎo)向

·開(kāi)發(fā)周期：固定且漫長(zhǎng)，至少以數(shù)月為單位，團(tuán)隊(duì)成員嚴(yán)格按照項(xiàng)目排期進(jìn)行開(kāi)發(fā)

·人員規(guī)模：人數(shù)眾多，一般都是整個(gè)技術(shù)部門(mén)全員一起參與某一開(kāi)發(fā)周期的項(xiàng)目開(kāi)發(fā)

·需求變動(dòng)：定好的需求，一般不會(huì)變動(dòng)，所以需求一開(kāi)始就要設(shè)計(jì)的非常完善

·返工：由于軟件生命周期嚴(yán)格按順序劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫(xiě)、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。那么一旦開(kāi)始進(jìn)入開(kāi)發(fā)，那么不可能返工，因?yàn)榉倒?huì)帶來(lái)巨大的成本開(kāi)銷(xiāo)。

·版本變更：每個(gè)項(xiàng)目項(xiàng)目開(kāi)發(fā)階段都會(huì)有明確的目標(biāo)，目標(biāo)如果未完成不會(huì)進(jìn)入下一階段，也就意味著版本變更不會(huì)太頻繁

根據(jù)傳統(tǒng)瀑布式開(kāi)發(fā)的以上特性，我們發(fā)現(xiàn)，面對(duì)互聯(lián)網(wǎng)時(shí)代用戶多變的需求，如果按照瀑布式開(kāi)發(fā)進(jìn)行，那么幾乎很難響應(yīng)需求的變更，難以做到快速交付新版本的產(chǎn)品。而并不是說(shuō)瀑布式開(kāi)發(fā)就一定不行，在傳統(tǒng)行業(yè)依然是主流開(kāi)發(fā)模式。

而敏捷開(kāi)發(fā)由于迭代周期短(一般周為單位)、人員規(guī)模少、隨時(shí)響應(yīng)變化，具有更大的靈活性、更少的投入、更高效的開(kāi)發(fā)、更及時(shí)的交付、更大程度的降低風(fēng)險(xiǎn)(及時(shí)了解市場(chǎng)需求，降低產(chǎn)品不適用風(fēng)險(xiǎn))。從這個(gè)方面來(lái)講敏捷開(kāi)發(fā)是完全可以適用互聯(lián)網(wǎng)時(shí)代下用戶多變的需求，也就是我們常說(shuō)的小步快跑，將一個(gè)大的需求拆分成各個(gè)小的需求，針對(duì)某個(gè)階段的小需求，組織少量的人員，借助于一定的規(guī)范、流程、工具、會(huì)議，從而達(dá)到快速交付上線的目的。

HOW? 如何實(shí)施敏捷

互聯(lián)網(wǎng)IT職能團(tuán)隊(duì)，如果要實(shí)施敏捷開(kāi)發(fā)離不開(kāi)四要素：規(guī)范、流程、工具、會(huì)議。敏捷的核心是人，只有人人參與遵守約定，那么敏捷開(kāi)發(fā)才能高效進(jìn)行。如下圖，敏捷開(kāi)發(fā)流程圖。

規(guī)范

規(guī)范是一種契約精神，要求團(tuán)隊(duì)所有成員都要遵守約定，把控規(guī)范細(xì)節(jié)，最終高質(zhì)量交付成果。

軟件編碼規(guī)范

編碼規(guī)范，規(guī)定團(tuán)隊(duì)技術(shù)人員在編寫(xiě)代碼時(shí)應(yīng)該遵守的開(kāi)發(fā)規(guī)則，比如命名規(guī)范、日志規(guī)范、注釋規(guī)范、單元測(cè)試規(guī)范、異常處理規(guī)范等等。

數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范

數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范，要求技術(shù)人員在設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)要考慮表設(shè)計(jì)、索引設(shè)計(jì)、SQL編寫(xiě)等方面的規(guī)則。

API設(shè)計(jì)規(guī)范

API規(guī)范一般意義指的是前后端分離時(shí)服務(wù)端網(wǎng)關(guān)系統(tǒng)對(duì)外提供的API規(guī)范，除此之外，在分布式環(huán)境中，服務(wù)端各模塊系統(tǒng)會(huì)進(jìn)行接口間通信，寫(xiě)接口時(shí)也要求遵守設(shè)計(jì)規(guī)范。

GIT管理規(guī)范

GIT管理規(guī)范，要求技術(shù)人員在分支命名、提交注釋、代碼合并等方面要遵守特定的規(guī)則。

版本管理規(guī)范

版本管理規(guī)范，軟件發(fā)布包的版本號(hào)管理要遵守特定的規(guī)則，每次版本升級(jí)的變更特性列表要求詳細(xì)編寫(xiě)。

測(cè)試規(guī)范

測(cè)試規(guī)范，用于約定測(cè)試團(tuán)隊(duì)的測(cè)試范圍和測(cè)試標(biāo)準(zhǔn)，具體包括功能測(cè)試、接口測(cè)試、性能測(cè)試、自動(dòng)化測(cè)試。

郵件規(guī)范

郵件規(guī)范，約定團(tuán)隊(duì)成員要遵守發(fā)送郵件的標(biāo)題名編寫(xiě)規(guī)范，不同類型的郵件對(duì)應(yīng)的標(biāo)題關(guān)鍵字各不相同，方便及時(shí)通過(guò)關(guān)鍵詞搜索歷史郵件。另外根據(jù)團(tuán)隊(duì)不同，有的團(tuán)隊(duì)可能會(huì)要求團(tuán)隊(duì)成員發(fā)送每日日?qǐng)?bào)、每周周報(bào)，日?qǐng)?bào)和周報(bào)都是通過(guò)郵件的形式進(jìn)行發(fā)送。

部署規(guī)范

部署規(guī)范，用于約定生產(chǎn)服務(wù)的部署方式，具體采用金絲雀部署、藍(lán)綠部署、還是其他部署方式。

結(jié)對(duì)編程

結(jié)對(duì)編程，一般指的是2個(gè)人同時(shí)負(fù)責(zé)共同模塊功能的開(kāi)發(fā)。兩個(gè)人在一起探討很容易產(chǎn)生思想的火花，不容易走上偏路，可以共同分析設(shè)計(jì)、寫(xiě)測(cè)試用例、編寫(xiě)代碼。結(jié)對(duì)編程還有個(gè)好處就是，當(dāng)一方開(kāi)發(fā)人員離職時(shí)，不至于花費(fèi)很多的交接時(shí)間，不會(huì)出現(xiàn)因?yàn)榫o急需求來(lái)臨時(shí)由于某開(kāi)發(fā)人員離職造成無(wú)人可以負(fù)責(zé)的現(xiàn)象。

流程

一般互聯(lián)網(wǎng)公司的開(kāi)發(fā)流程按照順序大致分為如下幾個(gè)階段：

需求整理階段、排期設(shè)計(jì)階段、開(kāi)發(fā)階段、測(cè)試階段、部署階段。整個(gè)流程在實(shí)施的過(guò)程中必要時(shí)允許返工，允許駁回需求并且可隨時(shí)調(diào)整需求。

需求整理階段

一般是產(chǎn)品部門(mén)負(fù)責(zé)，產(chǎn)品從需求池中根據(jù)優(yōu)先級(jí)篩選出優(yōu)先級(jí)最高的需求進(jìn)行詳細(xì)設(shè)計(jì)，并產(chǎn)出PRD成果給到技術(shù)部門(mén)。

排期設(shè)計(jì)階段

排期先要先進(jìn)行需求評(píng)審，需求評(píng)審會(huì)由產(chǎn)品負(fù)責(zé)人發(fā)起，評(píng)審會(huì)中所有參與人就需求的問(wèn)題進(jìn)行討論，需求敲定后，技術(shù)部門(mén)負(fù)責(zé)人或本次迭代負(fù)責(zé)人將詳細(xì)的項(xiàng)目開(kāi)發(fā)計(jì)劃發(fā)送至所有干系人。

特殊說(shuō)明的是，如經(jīng)驗(yàn)證出現(xiàn)不合理需求問(wèn)題，開(kāi)發(fā)團(tuán)隊(duì)可打回需求拒絕排期開(kāi)發(fā)。

開(kāi)發(fā)階段

開(kāi)發(fā)階段各成員按照計(jì)劃有序進(jìn)行開(kāi)發(fā)，開(kāi)發(fā)過(guò)程有任何需求疑問(wèn)及時(shí)找產(chǎn)品經(jīng)理溝通，產(chǎn)品經(jīng)理如在開(kāi)發(fā)過(guò)程中有緊急臨時(shí)需求，可組會(huì)討論后，優(yōu)先緊急需求的開(kāi)發(fā);如有需求變動(dòng)，可調(diào)整排期后重新發(fā)出排期計(jì)劃。

注意強(qiáng)調(diào)單元測(cè)試的必要性，開(kāi)發(fā)人員必須為自己編寫(xiě)的代碼質(zhì)量負(fù)責(zé)，自測(cè)完畢后才可提交給測(cè)試人員。

測(cè)試階段

開(kāi)發(fā)完畢自測(cè)通過(guò)后，開(kāi)發(fā)人員通知測(cè)試人員基于測(cè)試項(xiàng)目分支開(kāi)始進(jìn)行測(cè)試環(huán)境的測(cè)試，如果出現(xiàn)任何BUG則將BUG提交到缺陷管理系統(tǒng)，開(kāi)發(fā)人員根據(jù)BUG列表修復(fù)后更新BUG任務(wù)狀態(tài)，然后測(cè)試復(fù)測(cè)。直到測(cè)試部門(mén)測(cè)試完畢后，符合上線要求后，方可通知運(yùn)維部門(mén)進(jìn)行上線操作。

特殊說(shuō)明的是，如出現(xiàn)提測(cè)的功能部署后系統(tǒng)不能正常運(yùn)行影響測(cè)試，測(cè)試團(tuán)隊(duì)可打回給開(kāi)發(fā)拒絕本次測(cè)試，直到開(kāi)發(fā)提測(cè)的代碼沒(méi)問(wèn)題為止。

部署階段

部署階段，可分為預(yù)發(fā)環(huán)境部署和生產(chǎn)環(huán)境部署，流程大致相似。都是基于完成測(cè)試成功的對(duì)應(yīng)環(huán)境的項(xiàng)目分支通過(guò)CI工具進(jìn)行持續(xù)集成和部署。部署時(shí)的網(wǎng)關(guān)開(kāi)關(guān)切換機(jī)制應(yīng)考慮到位，盡量做到部署時(shí)對(duì)用戶無(wú)感知，部署完畢后測(cè)試人員在生產(chǎn)環(huán)境仍需復(fù)測(cè)一次，確保上線成果的正確性。

一定要保證如果部署過(guò)程出現(xiàn)問(wèn)題要有完善的回滾機(jī)制。

工具

敏捷團(tuán)隊(duì)若要執(zhí)行落地離不開(kāi)很多高效的協(xié)作工具，這里我列舉一些非常實(shí)用的工具供大家參考，工具的安裝步驟不在本文的講解范圍內(nèi)。

代碼管理工具

一般選用基于GIT協(xié)議的分布式代碼管理工具進(jìn)行代碼管理，常用的有g(shù)itlab、gitee、github。

項(xiàng)目管理工具

項(xiàng)目管理工具的意義在于管控所有迭代過(guò)程中的具體任務(wù)，用于跟進(jìn)開(kāi)發(fā)進(jìn)度、管控開(kāi)發(fā)效率。常用的工具有tower、jira。每個(gè)迭代周期內(nèi)的任務(wù)會(huì)在排期過(guò)程中由部門(mén)負(fù)責(zé)人分配給每個(gè)人員，任務(wù)完畢后要求及時(shí)拖動(dòng)任務(wù)狀態(tài)，方便領(lǐng)導(dǎo)跟進(jìn)查看進(jìn)展。

知識(shí)庫(kù)工具

知識(shí)庫(kù)管理工具的作用在于團(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í)庫(kù)目錄下，開(kāi)發(fā)團(tuán)隊(duì)會(huì)將開(kāi)發(fā)設(shè)計(jì)架構(gòu)圖、API接口文檔等放入技術(shù)團(tuán)隊(duì)的知識(shí)庫(kù)目錄下，類似的，所有團(tuán)隊(duì)都可將用于團(tuán)隊(duì)協(xié)作的資料存入本團(tuán)隊(duì)對(duì)應(yīng)的知識(shí)庫(kù)目錄中。

缺陷管理工具

缺陷管理工具用于測(cè)試團(tuán)隊(duì)在測(cè)試階段提交BUG任務(wù)給開(kāi)發(fā)人員，常見(jiàn)的工具有禪道、jira。

持續(xù)集成工具

持續(xù)集成工具目的在于實(shí)現(xiàn)自動(dòng)構(gòu)建、測(cè)試、打包、部署到各個(gè)環(huán)境中，建議使用docker進(jìn)行進(jìn)行部署，保證各個(gè)環(huán)境中系統(tǒng)運(yùn)行不會(huì)出現(xiàn)環(huán)境問(wèn)題。目前主流的持續(xù)集成工具有Jenkins、Bamboo。

SQL審核工具

生產(chǎn)系統(tǒng)上線后，如果出現(xiàn)BUG要修復(fù)生產(chǎn)數(shù)據(jù)，應(yīng)由開(kāi)發(fā)人員提交修復(fù)的SQL到審計(jì)系統(tǒng)中并提交申請(qǐng)，團(tuán)隊(duì)負(fù)責(zé)人負(fù)責(zé)一審，DBA負(fù)責(zé)二審，二審?fù)ㄟ^(guò)后SQL會(huì)自動(dòng)執(zhí)行。SQL審計(jì)工具上所有提交的SQL操作日志全部都會(huì)保留下來(lái)，方便追責(zé)時(shí)隨時(shí)查看。常見(jiàn)的SQL審核工具有Yearning。

容器管理工具

用于對(duì)docker進(jìn)行編排管理，比如常用的docker動(dòng)態(tài)擴(kuò)容、升級(jí)等。目前主流的的容器編排工具是K8S。

運(yùn)維安全管理工具

主要用于管理機(jī)房或者云端所有服務(wù)器資源，控制開(kāi)發(fā)人員權(quán)限，所有開(kāi)發(fā)人員如需登錄目標(biāo)服務(wù)器，必須登錄安全管理機(jī)后才有權(quán)限訪問(wèn)。常用的安全管理工具是jumpserver。

會(huì)議

敏捷開(kāi)發(fā)宣言強(qiáng)調(diào)個(gè)體溝通的重要性，所以會(huì)議的形式能增強(qiáng)溝通及時(shí)發(fā)現(xiàn)并修正問(wèn)題，如下列舉了敏捷開(kāi)發(fā)過(guò)程中常見(jiàn)的會(huì)議類型。

每日站立會(huì)議

站會(huì)有兩種，早晨站立會(huì)或晚間站立會(huì)(不同的團(tuán)隊(duì)只要求其中一種即可)，站立會(huì)在每天固定的時(shí)間要求大家放下手中的活全體起立，每個(gè)團(tuán)隊(duì)成員挨個(gè)發(fā)言，向所有成員分享上一日活今日完成的任務(wù)、遇到的問(wèn)題、接下來(lái)的計(jì)劃，如有阻礙開(kāi)發(fā)進(jìn)展的問(wèn)題可提出但不展開(kāi)討論，會(huì)后關(guān)聯(lián)人再詳細(xì)溝通。站會(huì)期間，有的團(tuán)隊(duì)會(huì)采用看板形式(實(shí)際就是一個(gè)白畫(huà)板多泳道)自己拖動(dòng)任務(wù)狀態(tài)。

迭代總結(jié)會(huì)議

迭代總結(jié)會(huì)議一般在某個(gè)迭代完成后盡快召開(kāi)，此會(huì)議的目的在于復(fù)盤(pán)上次迭代過(guò)程中的整體情況，包括好的和不好的，好的繼續(xù)精進(jìn)，不好的要反思改正。

代碼Review會(huì)議

代碼檢查會(huì)議，會(huì)根團(tuán)隊(duì)實(shí)際情況不定期的召開(kāi)，目的在于規(guī)范團(tuán)隊(duì)開(kāi)發(fā)人員的編碼規(guī)范，要求注重代碼質(zhì)量。

每周總結(jié)會(huì)議

每周總結(jié)會(huì)議，一般定在每周五進(jìn)行召開(kāi)，目的在于總結(jié)本周團(tuán)隊(duì)的整體的工作進(jìn)展，遇到的問(wèn)題;會(huì)上有問(wèn)題要及時(shí)匯總，要求問(wèn)題負(fù)責(zé)人會(huì)后及時(shí)給出解決方案和時(shí)間節(jié)點(diǎn)。

技術(shù)分享會(huì)議

技術(shù)分享會(huì)，會(huì)根據(jù)團(tuán)隊(duì)情況不定期召開(kāi)，目的在于讓有經(jīng)驗(yàn)的團(tuán)隊(duì)成員分享實(shí)戰(zhàn)經(jīng)驗(yàn)，提升團(tuán)隊(duì)整體水平。

總結(jié)

如上，你大概花費(fèi)10分鐘就基本了解了敏捷開(kāi)發(fā)團(tuán)隊(duì)的樣貌，結(jié)果你發(fā)現(xiàn)傳說(shuō)中的敏捷開(kāi)發(fā)也并沒(méi)有那么的神奇。如果你的團(tuán)隊(duì)中出現(xiàn)了我文章提到的敏捷實(shí)施離不開(kāi)的規(guī)范、流程、工具、會(huì)議這四要素的內(nèi)容，那么你的團(tuán)隊(duì)就是一支敏捷開(kāi)發(fā)的團(tuán)隊(duì)。

猜你喜歡：
黑馬程序員java培訓(xùn)課程