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

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

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

敏捷開發(fā)宣言

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

·個體和互動高于流程和工具

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

·客戶合作高于合同談判

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

解讀：

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

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

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

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

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

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

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

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

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

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

·激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖俊Ｌ峁┧璧沫h(huán)境和支援，輔以信任，從而達成目標；

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

·可工作的軟件是進度的首要度量標準；

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

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

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

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

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

WHY? 為何使用敏捷

在敏捷開發(fā)還沒有出來之前，大部分公司的開發(fā)模式基本都采取瀑布式開發(fā)。而瀑布式開發(fā)往往具有如下幾個特點：

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

·開發(fā)周期：固定且漫長，至少以數(shù)月為單位，團隊成員嚴格按照項目排期進行開發(fā)

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

·需求變動：定好的需求，一般不會變動，所以需求一開始就要設(shè)計的非常完善

·返工：由于軟件生命周期嚴格按順序劃分為制定計劃、需求分析、軟件設(shè)計、程序編寫、軟件測試和運行維護等六個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。那么一旦開始進入開發(fā)，那么不可能返工，因為返工會帶來巨大的成本開銷。

·版本變更：每個項目項目開發(fā)階段都會有明確的目標，目標如果未完成不會進入下一階段，也就意味著版本變更不會太頻繁

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

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

HOW? 如何實施敏捷

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

規(guī)范

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

軟件編碼規(guī)范

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

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

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

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

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

GIT管理規(guī)范

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

版本管理規(guī)范

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

測試規(guī)范

測試規(guī)范，用于約定測試團隊的測試范圍和測試標準，具體包括功能測試、接口測試、性能測試、自動化測試。

郵件規(guī)范

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

部署規(guī)范

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

結(jié)對編程

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

流程

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

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

需求整理階段

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

排期設(shè)計階段

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

特殊說明的是，如經(jīng)驗證出現(xiàn)不合理需求問題，開發(fā)團隊可打回需求拒絕排期開發(fā)。

開發(fā)階段

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

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

測試階段

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

特殊說明的是，如出現(xiàn)提測的功能部署后系統(tǒng)不能正常運行影響測試，測試團隊可打回給開發(fā)拒絕本次測試，直到開發(fā)提測的代碼沒問題為止。

部署階段

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

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

工具

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

代碼管理工具

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

項目管理工具

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

知識庫工具

知識庫管理工具的作用在于團隊協(xié)作的所有資料，方便團隊成員有需要時隨時進行查看。比如產(chǎn)品團隊會將每個版本的產(chǎn)品PRD文件放入產(chǎn)品團隊的知識庫目錄下，開發(fā)團隊會將開發(fā)設(shè)計架構(gòu)圖、API接口文檔等放入技術(shù)團隊的知識庫目錄下，類似的，所有團隊都可將用于團隊協(xié)作的資料存入本團隊對應(yīng)的知識庫目錄中。

缺陷管理工具

缺陷管理工具用于測試團隊在測試階段提交BUG任務(wù)給開發(fā)人員，常見的工具有禪道、jira。

持續(xù)集成工具

持續(xù)集成工具目的在于實現(xiàn)自動構(gòu)建、測試、打包、部署到各個環(huán)境中，建議使用docker進行進行部署，保證各個環(huán)境中系統(tǒng)運行不會出現(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到審計系統(tǒng)中并提交申請，團隊負責(zé)人負責(zé)一審，DBA負責(zé)二審，二審?fù)ㄟ^后SQL會自動執(zhí)行。SQL審計工具上所有提交的SQL操作日志全部都會保留下來，方便追責(zé)時隨時查看。常見的SQL審核工具有Yearning。

容器管理工具

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

運維安全管理工具

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

會議

敏捷開發(fā)宣言強調(diào)個體溝通的重要性，所以會議的形式能增強溝通及時發(fā)現(xiàn)并修正問題，如下列舉了敏捷開發(fā)過程中常見的會議類型。

每日站立會議

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

迭代總結(jié)會議

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

代碼Review會議

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

每周總結(jié)會議

每周總結(jié)會議，一般定在每周五進行召開，目的在于總結(jié)本周團隊的整體的工作進展，遇到的問題;會上有問題要及時匯總，要求問題負責(zé)人會后及時給出解決方案和時間節(jié)點。

技術(shù)分享會議

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

總結(jié)

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

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