WHAT? 敏捷開發的定義

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

敏捷開發宣言

官方原文： http://agilemanifesto.org/ ，中文翻譯內容如下：

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

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

·客戶合作高于合同談判

·響應變化高于遵循計劃

解讀：

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

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

主動擁抱變化，及時響應，持續交付。

·通過高效的協作，獲取快速的反饋，從而盡早做出調整，減少浪費

敏捷開發十二原則

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

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

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

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

·業務人員和開發人員必須相互合作，項目中的每一天都不例外；

·激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標；

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

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

·敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續；

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

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

·最好的架構、需求和設計出自自組織團隊；

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

WHY? 為何使用敏捷

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

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

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

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

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

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

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

根據傳統瀑布式開發的以上特性，我們發現，面對互聯網時代用戶多變的需求，如果按照瀑布式開發進行，那么幾乎很難響應需求的變更，難以做到快速交付新版本的產品。而并不是說瀑布式開發就一定不行，在傳統行業依然是主流開發模式。

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

HOW? 如何實施敏捷

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

規范

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

軟件編碼規范

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

數據庫設計規范

數據庫設計規范，要求技術人員在設計數據庫時要考慮表設計、索引設計、SQL編寫等方面的規則。

API設計規范

API規范一般意義指的是前后端分離時服務端網關系統對外提供的API規范，除此之外，在分布式環境中，服務端各模塊系統會進行接口間通信，寫接口時也要求遵守設計規范。

GIT管理規范

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

版本管理規范

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

測試規范

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

郵件規范

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

部署規范

部署規范，用于約定生產服務的部署方式，具體采用金絲雀部署、藍綠部署、還是其他部署方式。

結對編程

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

流程

一般互聯網公司的開發流程按照順序大致分為如下幾個階段：

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

需求整理階段

一般是產品部門負責，產品從需求池中根據優先級篩選出優先級最高的需求進行詳細設計，并產出PRD成果給到技術部門。

排期設計階段

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

特殊說明的是，如經驗證出現不合理需求問題，開發團隊可打回需求拒絕排期開發。

開發階段

開發階段各成員按照計劃有序進行開發，開發過程有任何需求疑問及時找產品經理溝通，產品經理如在開發過程中有緊急臨時需求，可組會討論后，優先緊急需求的開發;如有需求變動，可調整排期后重新發出排期計劃。

注意強調單元測試的必要性，開發人員必須為自己編寫的代碼質量負責，自測完畢后才可提交給測試人員。

測試階段

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

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

部署階段

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

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

工具

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

代碼管理工具

一般選用基于GIT協議的分布式代碼管理工具進行代碼管理，常用的有gitlab、gitee、github。

項目管理工具

項目管理工具的意義在于管控所有迭代過程中的具體任務，用于跟進開發進度、管控開發效率。常用的工具有tower、jira。每個迭代周期內的任務會在排期過程中由部門負責人分配給每個人員，任務完畢后要求及時拖動任務狀態，方便領導跟進查看進展。

知識庫工具

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

缺陷管理工具

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

持續集成工具

持續集成工具目的在于實現自動構建、測試、打包、部署到各個環境中，建議使用docker進行進行部署，保證各個環境中系統運行不會出現環境問題。目前主流的持續集成工具有Jenkins、Bamboo。

SQL審核工具

生產系統上線后，如果出現BUG要修復生產數據，應由開發人員提交修復的SQL到審計系統中并提交申請，團隊負責人負責一審，DBA負責二審，二審通過后SQL會自動執行。SQL審計工具上所有提交的SQL操作日志全部都會保留下來，方便追責時隨時查看。常見的SQL審核工具有Yearning。

容器管理工具

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

運維安全管理工具

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

會議

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

每日站立會議

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

迭代總結會議

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

代碼Review會議

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

每周總結會議

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

技術分享會議

技術分享會，會根據團隊情況不定期召開，目的在于讓有經驗的團隊成員分享實戰經驗，提升團隊整體水平。

總結

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

猜你喜歡：
黑馬程序員java培訓課程