大廠的敏捷開發方法上

大廠是如何開發軟件項目的呢？其實大廠做項目也無特別之處，也就是工程中常見的“分而治之”策略：大項目拆成小項目，大服務拆成小服務，大團隊拆成小團隊。

服務之間通過約定好的標準協議進行通信，架構上將大服務拆分隔離成微服務，大團隊按照業務或者服務拆分成小組，按照流程規範保障協作。最終，各個小組負責的內容其實就不錯了。

所以歸功於現在微服務、容器等新技術，可以將負責的業務主機拆分，讓很多公司能真正敏捷起來。

我們知道，團隊要實施敏捷，不僅要小，組織還要扁平化，相對來說，美國互聯網大企業做的很好，組織架構扁平，工程師地位很高。

下面我們一起來學習一下大廠具體應用敏捷的方法。

和敏捷相關的主要流程規範

一切工作任務圍繞Ticket開展
早些年的項目開發，都是圍繞項目計劃開展的，把甘特圖打印貼到牆上，方便團隊成員看項目進展到什麼地步了，敏捷開發後，就變成了看板。

所謂的看板，就是把白板分成幾個欄，每一欄爲一類，分別寫着“To Do”、“In Process”、“Done”等，再把工作任務變成一個個五顏六色的即時貼，根據狀態貼在不同的欄下面。

慢慢的物理看板變成了電子看板，通過各種項目管理軟件來管理跟蹤這些任務，即時貼也變成了Ticket(也叫Issue).逐漸的，所有的開發任務也就和Ticket掛鉤了：
彙報一個Bug，提交一個Ticket；
提交一條需求，提交一個Ticket；
要重構一下代碼，提交一個Ticket；
看板這種基於Ticket來管理跟蹤任務的方式，看起來繁瑣，其實是一種特別高效的方式。
每一個任務的狀態都可以被跟蹤：什麼時候開始做的，誰在做，昨晚沒有
整個團隊的進度一目瞭然
Ticket和敏捷開發中的Backlog(任務清單)結合，通過Ticket可以收集管理整個項目的Backlog和當前Sprint(迭代)的Backlog.
有了看板，大家每天上班來的第一件事就是打開看板，看看當前Sprint還有哪些Ticket沒有完成，哪些已經完成，哪些還在進行中，非常直觀。

    作爲項目組成員，就無需在手頭的任務完成後問項目經理接下來做什麼了，從“To Do”一欄裏挑選一個Ticket繼續做就可以；對於項目經理，從“To Do”就能看到還有哪些Ticket沒有做，“In Process”裏還有哪些正在進行，如果發現哪一欄的Ticket好久沒有動，比較多，就需要注意風險管控了。

基於Git和CI的開發流程

    如果團隊用瀑布模型來開發，最頭疼的事情就是代碼不穩定和部署太困難。

    早些年的源代碼管理，大家都是在Master(主幹)上進行開發，所以master分支的代碼極其不穩定，一不小心就會被合入不穩定代碼。所以一般在版本發佈前都有一段代碼分支鎖定期，這段時間代碼合入是嚴格受控的。

    測試環境的部署也是難題，服務一多，編譯時的各種依賴和環境的配置就要格外注意，更新測試環境就是一個大工程，需要專門有人負責測試環境。

    對於“代碼凍結”和“專人部署”方案，一點不敏捷，好在基於Git的開發流程和結合CI的自動測試部署很好了解決了這兩大難題。

Git本來只是源代碼管理工具，但是其有強大的分支管理和靈活的權限控制，配合一定的開發流程，可以幫助我們很好的控制代碼質量。

    我們現在假設master的代碼是穩定的，那如何保證新加入的代碼也穩定呢？答案就是代碼審查(Code Review)和自動化測試。如果代碼有嚴格的審查，並且所有自動化測試都能測試通過，可以認爲代碼質量是可靠的，當然前提是自動化測試代碼要有一定的覆蓋率。

    每次往master合入內容前，不是直接提交代碼到master，而是基於當前穩定的master，克隆一個branch分支出來，基於branch去開發，開發完成後提交一個PR（Pull Request請求）。

PR提交後，我們可以清楚的看到代碼哪裏改動了，其他人可以針對每一行代碼寫評論提出修改意見，確認代碼沒問題了就可以通過代碼審查。

    接下來剩下自動化測試問題，就該CI（持續集成）登場了。

    CI就類似一個機器人，每次你提交一個PR（嚴格來說是Commit）到源代碼服務器，CI立刻就知道了，然後它創建一個純淨的運行環境，download我們提交的代碼，下載安裝所有的依賴庫，然後運行我們的測試代碼，運行完畢後把測試結果報告給我們，測試結果只管的反饋在PR上，綠色表示通過，紅色表示不通過。

代碼審查和自動測試問題都解決了後，就可以合併到master了，我們可以認爲合併到master的代碼是穩定的。



下面以一個開發任務爲例，大致講解一下應用敏捷開發方法的基本開發流程：
把要開發的Ticket從“To Do”欄移動到“In Process”欄
從主幹master創建一個分支branch，基於分支去開發功能或修復Bug
編寫單元測試代碼和集成測試代碼，是否TDD不重要
持續提交代碼更新到分支，直到完成
創建PR，邀請別人Review代碼，根據Review結果，可能還需要更新幾次
CI在每一次提交代碼到代碼庫時都會自動運行，運行的目的如下:
代碼格式是不是符合規範
運行單元測試代碼
運行集成測試
最終CI把執行結果顯示在PR上，綠色通過紅色不通過
PR能合併到master需要滿足兩個條件：CI變綠+代碼Review通過
PR合併後，CI自動構建Docket Image，講Image部署到開發環境
響應的Ticket從看板上的“In Process”欄移動到“Done”欄
正常來說，我們是需要嚴格遵守開發流程的，但偶爾有緊急任務，來不及寫測試代碼，我們針對這種情況，一定要再創建一條Ticket跟蹤，確保後續補上測試代碼，不要欠下技術債務。

部署上線流程

最早的時候，程序員自己管服務器，但是這過於隨意，導致出現很多問題，於是出現了專門的運維團隊，講開發好的程序編譯好，數據生成腳本寫好，然後寫成部署文檔，交給運維去手動部署，過程繁瑣慎重，遇到打補丁還要延遲。

這些年隨着隨着容器化、微服務、DevOps技術和概念的興起，部署變得高效，以前是運維人員按照文檔部署，現在是DevOps寫自動化部署工具，開發人員自己去部署生產環境，大廠的部署也都實現了自動化，但是流程受到控制：
部署的不再是程序代碼，而是Docker的Image，每次代碼合併後CI會自動生成Image，測試也是基於Image
部署生產環境之前，現在內部的測試環境充分測試
部署生產環境前，需要審批確認，有Ticket跟蹤
部署是部分部署監測OK後再全量部署
整個過程都有監控報警，出現問題及時回滾
如果一切順利，整個生產環境的服務部署過程通常只要幾分鐘就完成了，這以前簡直是不敢想象的事情。

每日站立會議

敏捷開發中，每日站會是非常有名的，但凡實施敏捷開發的小組，每天上班第一件事情，就是一起開一個站會，溝通一下項目的基本情況和進展，開完會全身心去幹活。

是不是站着開會其實不重要，重點是要高效溝通反饋

開會時間控制在半個小時內，半小時內不能完成的應該另外組織會議。

在敏捷的Scrum中，有一個角色Scrum Master(敏捷教練，敏捷大師),主要任務就是保證各種敏捷流程的，他來主持會議，控制好會議節奏，主要有如下三個話題
成員輪流發言
每個人輪流介紹一下，昨天干了什麼事情，今天計劃做什麼事情，工作上有無障礙無法推進。通過這樣的形式，項目成員可以相互瞭解任務進展，有困難可以互相支援，及時發現問題和風險，當然每個人對自己提出的目標需要信守承諾，努力完成。
檢查最新的Ticket
每天理會需要檢查一下新增的Ticket，甄別一下優先級，然後決定是放到當前Sprint，還是放到Backlog任務清單，這個階段要注意不能發散，不要針對Ticket的細節過多討論，有需要討論的收集放到“問題停車場”。
停車場問題
總結

    在敏捷開發中的概念有Backlog、持續交付、每日站會等，這些概念最終要變成實踐的話，必須通過一定的流程規範來保障這些概念的實施。

    這就是爲什麼公司要寫自動化測試代碼，用Jira、禪道項目管理軟件來管理任務，每天開站立會議，代碼審查,都是爲了保障敏捷的正常實施。

    我們在實施敏捷開發的項目工作時可以多觀察和敏捷相關的流程規範，再結合敏捷開發中的知識點，就能很好的幫助我們理解敏捷開發，理解流程規範背後的理論依據。

此環節，大家可以針對之前來不及討論的問題進行討論，能在會議時間內解決的問題，立馬解決，不能解決的私下討論或者再組織會議。