2020年9月18日 DEC培訓

一、Devops導論（董越）

概述

軟件工程

核心思想：工程化。
為了解決軟件危機，用工程化方法開發軟件。要有嚴格的計劃和周期。

敏捷——>精益：消除各種浪費

精益：定義工作目標，定義價值，識別價值流，流動，拉動，盡善盡美。

將關注點從自身轉移到客戶，關注價值流。

持續集成

• 為了避免獨自前進太遠
• 頻繁測試，驗證質量

通常狹義、不涉及SIT、UAT等

持續交付

軟件可隨時發布上線，交付測試。
持續交付是一種能力，能夠讓給各類變更（如新特性、配置變更、缺陷修復、嘗試性內容等）以安全、快速、可持續的方式交付到生產環境或用戶手上

架構和技術方面

結構化變成——>面向對象變成——>軟件復用
實體機——>虛擬機——>容器——>函數服務
微服務、云原生
思路：盡量做到復用

DevOps誕生

原因：軟件交付的形式的巨大變化：本地安裝——>在線服務
部門墻：Dev團隊與Ops團隊
DevOps的目的是期待更順暢的協作：Dev、QA、Ops
是“法”的維度

廣義的DevOps

將Devops在本時代下的實踐整合在一起
DevOps = 精益敏捷 + 持續交付 + 容器化 + 微服務
DevOps = Dev + QA + Sec + Ops
DevOps = 軟件開發交付運營的最佳實踐

DevOps的優化目標

產品定義側

• CEO、產品經理
• 設計產品，探索和發現有用價值
• 多嘗試，盡快反饋，迅速調整

產品實現側

• 開發、測試、運維、安全
• 提供產品和服務，落地實現價值

——>在具體場景下的多快好省：更高產能、更快響應速度、適當的質量、合理的成本

不是所有項目都適合DevOps

DevOps的十個核心策略

細粒度低耦合

不僅僅是軟件架構，也適用于組織架構
組織架構的考量：全棧團隊更快速
集中辦公的效率？

工具、環境、方法的優化，可以擴張團隊的職能，讓團隊提高自服務的能力

小批量持續流動

瀑布——>Scrum——>以特性為顆粒度的交付（不再趕發布火車）
需求拆分
限制在制品數量
持續集成、持續交付
去掉發布窗口

綜合手段保證質量和安全

擴展測試的定義
各階段的綜合保證：綜合考慮測試的性質放在合適的位置
“便宜”的測試，盡量左移
"貴"的測試，進行右移

自動化與自助化

自動化好處：省時間、省成本、可重復、完備記錄
單個活動的自動化+流程的自動化
自動化——>自助化
工具的穩定性

加速各項活動

硬件能力
并行
避免重復
只關注增量
緩存

關注各個過程活動中的加速

及時修復

涵蓋范圍：測試階段、發布后
如何實現：及時通知、優先處置、修不如退、便捷排查

完備記錄、充分展現

自動化不僅僅關注往前推動，還關注記錄

• 工作項、sprint backlog、看板墻
• 流水線相關信息展現
• 版本控制&制品管理
• 對外來資產的管理
• 權限管理策略
  • 組織內開源有利于協作
• 數據備份

保持一致性

內容涵蓋：可重復性、標準化、組織級統一、運行環境一致性
實現方法：規范化、內化到工具、版本控制、代碼化
有章可循的適度靈活
配置參數兩類

• 隨著系統演化的升級：類似源碼的管理方法
• 對于每個具體環境的改變的變化：采用別的管理方式

協調完成整體功能

架構層面：接口定義、接口管理、兼容性
管理層面：SoS、SAFe、LeSS、DAD
工程層面：特性涉及多個部署單元的改動、集成、發布涉及多個部署單元、完整性、順序、摘除與回退

基于度量的持續改進

組織結構與文化

1.1 關鍵思路：自主性

• 溝通、協調需要精力
• 協作帶來排隊和等待

特性團隊：長期的、具備交付價值所需的各種角色的、可以協同完成完整用戶價值交付的團隊

1.2 各職能之間的協作

• 每個團隊都盡量是全功能的團隊
• 工具&環境團隊
• 方法&流程團隊
• 其他情況

1.3 負責不同開發內容的團隊的劃分

長期團隊
獨立完成特性代碼改動
運用康威定律：通過組織的改進，來推動產品的改進
有負責公共品的團隊
層級：還是需要部分劃分來進行層級管理
其他情況

1.4 團隊規模

兩個披薩原則：5-9人合適
自主 和 專注

DevOps文化

設置共同目標
尊重和信任
及時和充分的溝通
聚焦于解決問題并改進機制
鼓勵學習和探索
其他

二、精益敏捷（丁曉嬌）

基礎

參考書

• 《精益思想》
• 《看板方法》
• 《Scrum敏捷軟件開發》

五大原則：定義價值，識別價值流，流動，拉動，盡善盡美。

拉動：讓客戶按需求去拉動，而不是硬推給客戶不想要的；只有被客戶和下游拉動時，價值才流動

流動：從按“部門”和“批量”轉化為“生產團隊”和“連續流”

價值流中的浪費：

1. 部分完成的工作（未被集成的代碼）
2. 額外過程
3. 額外特性：最大化的做當下的需求，不要考慮額外的工作
4. 任務調換：任務調整、切換時候的浪費
5. 移動：針對強矩陣組織，打破部門墻。不需要協調資源去做事情。
6. 缺陷：提前發現問題，成本可降低
7. 等待：等待開發、等待測試、等待部署，都需要透明化，想辦法去消除等待
8. 管理活動：盡量自主去解決問題

為什么要精益敏捷開發
做到多快好省。通過強調價值、流動和人員，就可以提高質量，降低成本，加快交付速度

敏捷研發模型

Scrum：透明化、檢查反饋、持續改進

長期：向團隊同步價值、確定使命和目標
中期：制定需求和版本中期規劃
迭代前：需求準備，優先級
迭代中：需求池、每日站會時間把握、暴露問題、sprint review還是需要的
兩周一回顧
3355：3個角色、3個工件、5個活動、5個價值觀

五大常見實踐：

• 測試驅動開發
• 集體所有權：針對代碼，所有人員可以看到整個工程的代碼
  • 風險和效能的權衡
• 持續集成
• 重構：優雅性的提升，每個迭代要解決部分技術債問題
• 結對編程：code review的進一步

看板方法

一種基于精益思想的軟件開發方法，其五大實踐：

• 透明化
• 規則顯示化
• 限制在制品
• 管理流動
• 建立反饋，持續改進

透明化

針對不同公司、不同場景組織架構下，浪費的活動定義不一樣
價值活動：需求分析、編碼、……、部署
I型浪費：

1. TO C場景下的編寫文檔
2. 跨團隊溝通
3. 系統間聯調

II型浪費：

1. 協調團隊排期
2. 部署申請

限制在制品的價值、原則和方法

什么是在制品
又稱WIP，“進行中”能交付客戶價值的工作，包括待開發的需求，未被集成的代碼，未測試的代碼，未部署的制品等。

為什么？

• 精益思想之流動：小批量，讓價值流動起來
• 在制品越多，切換和等待產生，反饋環被拖長
• 通過限制在制品，有效識別和消除浪費，加速流動
• 提高質量，減少復雜度，提高專注度

基本原則

• 限制在制品不是目的，改進才是；限制過程也是個改進過程
• 人員閑置或工作閑置
• 沒有限制是不對的
• 更低比更高好，但不要使得組織壓力過大，開始時設置大些，建立改進驅動力后，逐步調低
• 停止啟動，聚焦完成
• 單件流"1"并不是答案

思路
限制在制品的過程就是發現問題和驅動改進的過程

方法

• 基于列的在制品限制（更傾向）
  • 對于瓶頸處的處理方法——約束理論
    1. 挖掘策略：挖掘瓶頸處的問題，并解決它
    2. 保護策略：如設置緩沖區（比如開發->測試，中間增加“待測試”緩沖區）
    3. 服從策略：改善瓶頸效能所需要的變化通常不發生在瓶頸處，關注整體端到端（可調用其他資源協助）
    4. 突破策略：比如資源增加（最后再考慮這種策略）
• 基于整個團隊限制
• 按人員限制在制品

管理流動方法
管理并監控看板的工作流動

• 限制在制品
• 顯示化等待列和實踐，并縮短等待
• 消除阻塞，永遠不要被阻塞——敏捷開發的最高指示
• 避免返工
• 打造跨職能團隊
• 設定SLA或需求前置時間目標
• 通過每日站會及時發現和跟進阻礙流動的問題
• 識別和管理瓶頸

每個教練要定制適合自己團隊的scrum+kanban研發模型

需求管理活動

用戶故事 VS 工作故事

用戶故事：AS...（角色），I WANT...（活動目標），SO I CAN...（價值原因）
工作故事：WHEN...（場景），I WANT...（活動目標），SO I CAN...（價值原因）

基本要素：標題、描述、驗收條件(DoD)、優先級、大小
產品參與驗收

六個特性：INVEST
從用戶角度拆到最小可測試，可獨立交付的最小用戶功能

產品經理從用戶價值角度拆，RD從獨立負責人，風險可控角度去拆

要權衡管理成本，對于技術性團隊，下太重管理成本可能做不下去。

需求拆分

需求拆分是后續所有過程的基礎

1. 面臨的挑戰

• 如何拆出既能體現進度又能在一個迭代內完成的故事
• 如何避免拆出瀑布型階段任務
• 不會花費太多時間
• 不會迷失在網絡上太多的拆分方法

2. 需求拆分方法
   復雜型故事：涉及基礎架構型故事，無法拆分，占比較小
   符合型故事：包含多個更小的故事，可以拆分，占比較大
   針對業務人員，需要了解無法拆分的原因。

3. SPIDR方法

5）. Spikes：刺入探索法。在不知道客戶需求的情況下
2）. Paths：路徑分析法?？蛻羧绾问褂霉δ埽蛻袈窂?。
1）. Interfaces：場景界面法。理清什么場景下客戶的需求，通過什么樣的功能來滿足痛點。
4）. Data：數據因素法。與Rules類似，逐步將數據補充給用戶。
3）. Rules：規則分析法。在Paths考慮的情況下，可通過迭代的方式逐步增加規則。

INTERFACE法

image.png

PATHS

image.png

DATA

image.png

RULES

image.png

SPKIES
使用MVP來探索用戶的需求

4. 需求估算方法
   建議需求估算不要花費太多時間
   統計各種SIZE需求花費的歷史數據，可計算花費人天，適合中長期規劃估算
   理想人天：比較難以估準。
   根據自己的團隊文化進行估算

5. 需求規劃和發布
   通過用戶故事地圖，按照場景和大功能進行需求歸類，再從每個版本規劃功能（產品經理的職責）

跨團隊敏捷（Scrum of Scrum）

適用場景：團隊需求耦合、團隊技術架構耦合，且團隊人數也較多的時候，需要拆分多個Scrum小團隊，通過SoS方法進行協作

盡量不要走版本火車的模式，通過管理手段應該避免浪費，而不是增加浪費

產品經理團隊制定愿景、對齊中長期目標、橫向對齊需求優先級并驅動一起做計劃

跨團隊需求引入特性技術負責人，把控和對齊方案

社區溝通架構和技術演進和成長，促進人員能力提升和跨團隊溝通

Sos擴展實踐

• 產品經理團隊內定期產品發布規劃，關注整體目標
• 產品經理團隊內主動對齊需求優先級和依賴
• PM聯合技術負責人溝通和對齊方案
• 共享團隊chengyuan
• 成立集成團隊專注解決項目集成過程中各種問題

Sos擴展實踐

• 從產品交付價值角度建立產品backlog，可分不同團隊子視圖
  • 產品級是用戶故事視圖，研發級是用戶故事拆分出的任務視圖。
• 團隊間協調實踐
  • 團隊建設同步迭代解耦（迭代日歷）
  • 派代表參加SoS會議（定期解決協作問題）
• 擴展Sprint計劃實踐
  • 產品經理和技術負責人提前溝通對齊
  • 計劃日錯開
  • 大房間（集中辦公）