過分強調並專注於docker、Jenkins、測試框架、Mock框架或持續集成服務器等工具，有悖於敏捷宣言 -- 和流程與工具相比，個體與交互更為重要。

案例背景：

• B公司部門組成：
• B公司某業務線下的一個後台服務業務團隊，這個團隊負責網頁搜索產品的後台服務。該服務是一個相對獨立的子系統，接受其他服務的請求，也將自己服務的處理結果提供給其他服務使用。
  • 由一個程序模組組成，
  • 總體代碼量約為10萬行，
  • 全部由C++語言編寫，
  • 每個模組都是一個單獨的程序服務（可以認為是微服務），
  • 運行在近300台服務器上。從前端的資料流獲取開始，再到資料流的解析、分類入庫。
  
  
• 工作模式
  • 分支開發、集中聯調階段，測試人員參與較少
  • 程式碼管理：分支開發、主幹發布
  
  

16.1 改進的關鍵點

16.1.1 改進方法論

• 目標驅動
• 從簡單問題開始
• 持續改善

16.1.2 定義改進目標

• 工作過程中的痛點
  • 部門負責人的期望
  • 團隊管理者交付的壓力
  • 項目負責人的煩惱
• 制訂合理的階段性改進目標
  • 短期目標
    • 項目近預期時間交付
    • 創建新的軟體開發協作方式
    • 建立必要的基礎設施，以支持之後的持續交付
  • 中期目標
    • 縮短發布週期，可以快速上線
    • 不降低生產環境的品質
    • 降低測試人力總投入
• 改進目標對應兩個實施階段
  • 第一階段，敏捷101
  • 第二階段，DevOps轉型

16.2 第一階段：敏捷101

• 簡介
  • 也稱為Water-Scrum-fall模式，指瀑布開發框架模式下，對各階段內部進行迭代時間盒的劃分
  • 迭代週期通常為1~4週。開發階段內的每個迭代週期內，都會發生需求分析、程式開發、測試活動。並且每個開發迭代結束時做演示驗收
  • 進入開發階段後，仍舊有需求收集、分析和計劃的階段，並且在結束後也會再安排1~2個作為系統測試迭代
  • 最後安排系統試營運階段，然後再正式上線
• 特點：
  • 瀑布開發模式中的幾大階段沒有變化，只對各階段內部活動進行適當調整
  • 此模式常應用在對於持續交付理解不深、研發基礎設施不完備，但希望進行改善的團隊
  
  

16.2.1 做個靠譜的計劃

• 需求拆分，開發負責人根據下列3個要求作拆分，並交給測試人員進行評審和補充後，再次相互討論並達成意見一致
  • 每個需求實現少於三天
  • 拆分要遵循INVEST原則
    • 獨立的（Independent）
    • 可協商的（Negotiable）
    • 有價值的（Valuable）
    • 可估算的（Estimatable）
    • 較小的（Small)
    • 可測試的（Testable）
  • 拆分過程中的權衡
• 相對估算，使用排序法對需求估算，排序法有2主張(12)與4前提(36)
  • 將較多的需求放一起，結合上下文做比較 (降低因人員能力差異帶來的偏查)
  • 在需求的數量較多時，項目整體規模評估會相對準確
  • 每個需求至少有兩個人較了解，且是可以完成的
  • 不需要評估測試活動的工作量 (開發環節才是系統的瓶頸，若測試環節就會成為瓶頸甚至可認為開發資源已投入過多)
  • 所有需求都拆解，並且規模不會相差太多
  • 需求的個數相對較多
• 初始計劃
  • 理想情況下，每週工作時間是多少
  • 理想情況下，每週能完成多少需求
  • 實際每週最有可能開發完成多少需求
  • 如何處理整個項目開發過程中的線上需求變更
    • 例如是在發布主幹上拉一條項目開發分支，所有人以這個分支進行開發。對於臨時的緊急需求，在線上發布版本分支上單獨拉分支，快速修復線上問題或開發緊急需求，再快速合併上線
  • 系統測試的時間在哪裡？
  • 其他類型的測試怎麼辦？
  • 計劃時還需要考慮依賴因素
    • 例如考慮業務或技術上，是否與其他團隊有依賴的關係？
  • 項目計劃在整體上要加一個緩衝時間

16.2.2 開發階段啟航

• 迭代週期的選擇
  
  • 水位當作開發的時間範圍，岩石當作日常問題
  • 若以傳統模式開發，此時問題難以暴露出來
  • 若以迭代模式開發，因為交付時間變短，相當於水位變低，問題就能提早凸顯出來。但是水位的高低的選擇，則需要團隊視情況而決定
• 團隊協作流程
  • 每個迭代的工作約定
  • 對於單個需求的開發流程約定
    • 批量開發，批量提測：指開發人員等到全部或大部分功能開發完成後，再一起聯合驗證
    • 單例開發，即時提測：指每當開發人員開發完一個需求之後，就即刻交給測試人員進行驗證
    
    

16.2.3 對過程品質的約束

• 如何能自覺遵守CI定律？
• 編譯時間過長
  • 開發人員寫完程式碼，提交前在自己機器上運行命令腳本，將SVN當前版本耗與patch一起提交給服務端，空閒時就會自動編譯。若出錯就會得到反饋，若沒問題開發人員則可提交程式碼
  
  
• 開發人員無法運行自動化測試
  • 迭代開發中，自動化測試的第一個用戶是開發人員，來檢查新增修改的程式碼是否正常
• 自動化測試的策略。根據自動化測試金字塔理論及團隊狀況做出測試約定
  • 單元測試
  • 模組自動化測試
  • 服務接口自動化測試
  • 子系統級自動化測試
  • 大環自動化測試
  
  
• 自動化測試所需運行環境不足怎麼辦
• 如何確定一個需求可以提測
  • 測試人員在開發人員的機器上體驗過該需求
  • 所有自動化測試都通過。
• 如何作性能與壓力測試
  • 對開發人員的工作要求
    • 在迭代開發的工作模式下，所有需求是依據PARID五因素綜合優先級排入迭代計劃當中，這會要求開發人員盡量能夠多了解和修改不同的模組功能
  • 團隊的自我主動改進
    • 每個迭代舉行回顧會議，對工作過程中成員的協作方式、工作活動的約定、團隊面臨的問題及可能的解決方案進行討論
  • 不能修改最初估算的大小
    • 新增需求：以前未評估過，所以需要快速討論、估算，以便加入開發計劃當中
    • 已估需求：單個需求估算本就不精確，原先的估算是基於整體的總量評估，因此不太會因為個別需求重新評估而偏差太多

16.2.4 階段性改進點

• 業務目標合理
• 項目計劃透明
• 流程"自定義，自遵守"，團隊確保高品質交付
• 定期主動回顧，而非事件驅動的回顧
• 通過細粒度需求組織開發流程
• 持續集成六步提交法
• 適當是用自動化測試，提高品質反饋效率

16.3 第二階段：DevOps轉型

• 透過敏捷101的方式，對於時程預估、開發團隊的合作、測試流程都有一定的成長，團隊開始朝向小批量生產的方式開發，並且開始有比較頻繁的成果發佈(ex.兩週一次)
• 從過去的分支開發、合併主線內容到分支、集中測試，改為主線開發、分支發布的城際快線開發模式
  • 在wiki上可以知道每個發布的時間點，以及對應的發布列表
  • 客戶可以隨時提交需求
  • 需求列表中，不但有客戶要求，還包含自我優化需求排程

16.3.1 與維運人員的衝突

• 因為頻繁的發布，引發維運人員的憂慮
  • 過去測試時間那麼長，上線的系統還是會出現各種問題，現在測試的時間縮短後(測試左移，導致最後上線前測試時間縮短)，那上線一定會更容易出問題
  • 我會被累死，部署到多台主機，以前三個月加班一次，現在變成兩週就要加班一次
• 透過讓維運人員參與團隊日常的運作，增加透明度
  • 開發負責人為維運人員詳細講解目前使用的研發流程模式，讓他了解目前對於程式碼品質的保障方式
  • 邀請維運人員參與開發團隊活動，參加日常工作的討論ex.參與站立會議、參與團隊衝刺週期後的回顧會議
  • 將維運人員加入開發團隊的工作溝通群中，以便隨時了解運作狀況，這維運人員不再視為開發團隊是一個看不到內部的「黑盒」
• 針對維運需求進行架構調整，讓維運人員的工作更有效率(過去對於維運的需求都以有空再來處理而忽悠過去，現在變成一個合作夥伴，一起讓讓部署過程可以更自動化)

16.3.2 高頻部署發布中的具體障礙

• 由於歷史共業，各模組的部署方式不一致，導致不利於統一維運
• 部分模組在部署時，維運人員需要手動創建某個目錄，備份程式運行時產生的臨時數據
• 同樣的模組在不同機器上的部署位置都有差別
• 同樣的模組在不同機器上對外的接口策略也不同
• 程式碼是用絕對路徑而非相對路徑
• 部署操作文件是由開發在部署前編寫(代表每次可能都不一樣，導致無法透過自動化反覆執行)，維運人員根據文件說明操作
• 開發環境的部署方式跟正式環境的部署方式不同
• 測試代碼存在QA的儲存庫，而不是跟著專案跑，導致只有QA才有辦法執行測試
• 開發環境、測試環境共用，導致髒資料議題
• 自動化測試覆蓋率不足，導致測試人員仍然需要執行很多手工回歸測試(每次上版都要手動測試全系統)

16.3.3 整體解決方案的設計

• 自動化測試策略的調整：
  • 把測試從QA擴展到全開發，對於開發人員進行單元測試框架的培訓
  • 減少不同層次間的重複測試，認知「通過低層次的測試來驗證很難在高層次驗證的測試」，找到最適合測試的階層，不是所有的測試都是交給QA執行整合測試

• 自動化測試的便捷性
  • 透過配置文件的方式讓不同的開發可以共用一個測試環境(ex.只要換不同的配置文件，系統就可以上到某一台測試主機，要換到另一台主機，只要更換配置文件不需要修改程式碼就可以遷移過去)
• 測試代碼同源
  • 把測試代碼放到專案裡面，而不是QA的儲存庫，這樣任何人都可以去執行測試
• 配置管理優化
  • 代碼庫結構
    • 程式資料夾有統一的結構，模組相關的就在該模組資料夾下(ex.該模組的測試，是放在該模組的test資料夾內，而不是整個系統的測試全部放一起)，該模組的config就放在該模組下
    • ex.單元測試就放在「模組a/test/unittest/測試案例1」
    • 會有output的資料夾，提供維運人員部署使用
  • 產出物的標準化與版本管理
    • 持續整合產出的成品，透過建構號(build_id)作為成品的唯一識別
    • 取代手工自行編譯
• 軟件包管理
  • 只有經過一系列的自動化測試，並經過測試人員手工驗證後，才在臨時構建成品庫中標記為「符合品質標準」，當要獲取某個版本部署時，只能從臨時構建成品庫中選擇那些符合品質標準的版本放入產品發布庫

16.3.4 DevOps階段的團隊改變

• 完整的跨功能團隊，維運積極參與團隊的日常工作迭代會議
• 所有內容都做版本控制，包括原始碼、測試程式、各類環境的配置、相關的打包及安裝腳本，以及一些數據
• 所有環境標準化管理，可以一鍵式準備好測試環境
• 建立完整的部署流水線，可以一鍵式發佈到多種部署環境

16.4 小結

• 所有改進都是一種一連串的連續流程，從明確目標、診斷問題、解決方案、持續運營優化
• 過程中抱持著持續學習的心態