2020年9月18日 DEC培訓(xùn)
一、Devops導(dǎo)論（董越）
概述
軟件工程
核心思想：工程化。
為了解決軟件危機(jī)，用工程化方法開發(fā)軟件碳柱。要有嚴(yán)格的計(jì)劃和周期。
敏捷——>精益：消除各種浪費(fèi)
精益：定義工作目標(biāo)熬芜，定義價(jià)值莲镣，識(shí)別價(jià)值流，流動(dòng)涎拉，拉動(dòng)瑞侮，盡善盡美。
將關(guān)注點(diǎn)從自身轉(zhuǎn)移到客戶鼓拧，關(guān)注價(jià)值流半火。
持續(xù)集成
- 為了避免獨(dú)自前進(jìn)太遠(yuǎn)
- 頻繁測試，驗(yàn)證質(zhì)量
通常狹義毁枯、不涉及SIT慈缔、UAT等
持續(xù)交付
軟件可隨時(shí)發(fā)布上線，交付測試种玛。
持續(xù)交付是一種能力藐鹤，能夠讓給各類變更（如新特性、配置變更赂韵、缺陷修復(fù)娱节、嘗試性內(nèi)容等）以安全、快速祭示、可持續(xù)的方式交付到生產(chǎn)環(huán)境或用戶手上
架構(gòu)和技術(shù)方面
結(jié)構(gòu)化變成——>面向?qū)ο笞兂伞?gt;軟件復(fù)用
實(shí)體機(jī)——>虛擬機(jī)——>容器——>函數(shù)服務(wù)
微服務(wù)肄满、云原生
思路：盡量做到復(fù)用
DevOps誕生
原因：軟件交付的形式的巨大變化：本地安裝——>在線服務(wù)
部門墻：Dev團(tuán)隊(duì)與Ops團(tuán)隊(duì)
DevOps的目的是期待更順暢的協(xié)作：Dev、QA质涛、Ops
是“法”的維度
廣義的DevOps
將Devops在本時(shí)代下的實(shí)踐整合在一起
DevOps = 精益敏捷 + 持續(xù)交付 + 容器化 + 微服務(wù)
DevOps = Dev + QA + Sec + Ops
DevOps = 軟件開發(fā)交付運(yùn)營的最佳實(shí)踐
DevOps的優(yōu)化目標(biāo)
產(chǎn)品定義側(cè)
- CEO稠歉、產(chǎn)品經(jīng)理
- 設(shè)計(jì)產(chǎn)品，探索和發(fā)現(xiàn)有用價(jià)值
- 多嘗試汇陆，盡快反饋怒炸，迅速調(diào)整
產(chǎn)品實(shí)現(xiàn)側(cè)
- 開發(fā)、測試毡代、運(yùn)維阅羹、安全
- 提供產(chǎn)品和服務(wù)勺疼，落地實(shí)現(xiàn)價(jià)值
——>在具體場景下的多快好省：更高產(chǎn)能捏鱼、更快響應(yīng)速度执庐、適當(dāng)的質(zhì)量、合理的成本
不是所有項(xiàng)目都適合DevOps
DevOps的十個(gè)核心策略
細(xì)粒度低耦合
不僅僅是軟件架構(gòu)导梆，也適用于組織架構(gòu)
組織架構(gòu)的考量：全棧團(tuán)隊(duì)更快速
集中辦公的效率轨淌？
工具、環(huán)境问潭、方法的優(yōu)化猿诸，可以擴(kuò)張團(tuán)隊(duì)的職能，讓團(tuán)隊(duì)提高自服務(wù)的能力
小批量持續(xù)流動(dòng)
瀑布——>Scrum——>以特性為顆粒度的交付（不再趕發(fā)布火車）
需求拆分
限制在制品數(shù)量
持續(xù)集成狡忙、持續(xù)交付
去掉發(fā)布窗口
綜合手段保證質(zhì)量和安全
擴(kuò)展測試的定義
各階段的綜合保證：綜合考慮測試的性質(zhì)放在合適的位置
“便宜”的測試梳虽，盡量左移
"貴"的測試，進(jìn)行右移
自動(dòng)化與自助化
自動(dòng)化好處：省時(shí)間灾茁、省成本窜觉、可重復(fù)、完備記錄
單個(gè)活動(dòng)的自動(dòng)化+流程的自動(dòng)化
自動(dòng)化——>自助化
工具的穩(wěn)定性
加速各項(xiàng)活動(dòng)
硬件能力
并行
避免重復(fù)
只關(guān)注增量
緩存
關(guān)注各個(gè)過程活動(dòng)中的加速
及時(shí)修復(fù)
涵蓋范圍：測試階段北专、發(fā)布后
如何實(shí)現(xiàn)：及時(shí)通知禀挫、優(yōu)先處置、修不如退拓颓、便捷排查
完備記錄语婴、充分展現(xiàn)
自動(dòng)化不僅僅關(guān)注往前推動(dòng)，還關(guān)注記錄
- 工作項(xiàng)砰左、sprint backlog、看板墻
- 流水線相關(guān)信息展現(xiàn)
- 版本控制&制品管理
- 對外來資產(chǎn)的管理
- 權(quán)限管理策略
- 組織內(nèi)開源有利于協(xié)作
- 數(shù)據(jù)備份
保持一致性
內(nèi)容涵蓋：可重復(fù)性沦泌、標(biāo)準(zhǔn)化、組織級(jí)統(tǒng)一孩饼、運(yùn)行環(huán)境一致性
實(shí)現(xiàn)方法：規(guī)范化镀娶、內(nèi)化到工具汽畴、版本控制忍些、代碼化
有章可循的適度靈活
配置參數(shù)兩類
- 隨著系統(tǒng)演化的升級(jí)：類似源碼的管理方法
- 對于每個(gè)具體環(huán)境的改變的變化：采用別的管理方式
協(xié)調(diào)完成整體功能
架構(gòu)層面：接口定義罢坝、接口管理嘁酿、兼容性
管理層面：SoS、SAFe娱仔、LeSS游桩、DAD
工程層面：特性涉及多個(gè)部署單元的改動(dòng)借卧、集成、發(fā)布涉及多個(gè)部署單元陪每、完整性镰吵、順序锌订、摘除與回退
基于度量的持續(xù)改進(jìn)
組織結(jié)構(gòu)與文化
1.1 關(guān)鍵思路：自主性
- 溝通辆飘、協(xié)調(diào)需要精力
- 協(xié)作帶來排隊(duì)和等待
特性團(tuán)隊(duì)：長期的蜈项、具備交付價(jià)值所需的各種角色的、可以協(xié)同完成完整用戶價(jià)值交付的團(tuán)隊(duì)
1.2 各職能之間的協(xié)作
- 每個(gè)團(tuán)隊(duì)都盡量是全功能的團(tuán)隊(duì)
- 工具&環(huán)境團(tuán)隊(duì)
- 方法&流程團(tuán)隊(duì)
- 其他情況
1.3 負(fù)責(zé)不同開發(fā)內(nèi)容的團(tuán)隊(duì)的劃分
長期團(tuán)隊(duì)
獨(dú)立完成特性代碼改動(dòng)
運(yùn)用康威定律：通過組織的改進(jìn)跑芳，來推動(dòng)產(chǎn)品的改進(jìn)
有負(fù)責(zé)公共品的團(tuán)隊(duì)
層級(jí)：還是需要部分劃分來進(jìn)行層級(jí)管理
其他情況
1.4 團(tuán)隊(duì)規(guī)模
兩個(gè)披薩原則：5-9人合適
自主 和 專注
DevOps文化
設(shè)置共同目標(biāo)
尊重和信任
及時(shí)和充分的溝通
聚焦于解決問題并改進(jìn)機(jī)制
鼓勵(lì)學(xué)習(xí)和探索
其他
二博个、精益敏捷（丁曉嬌）
基礎(chǔ)
參考書
- 《精益思想》
- 《看板方法》
- 《Scrum敏捷軟件開發(fā)》
五大原則：定義價(jià)值盆佣，識(shí)別價(jià)值流，流動(dòng)虑灰，拉動(dòng)穆咐，盡善盡美佃蚜。
拉動(dòng)：讓客戶按需求去拉動(dòng)庸娱，而不是硬推給客戶不想要的；只有被客戶和下游拉動(dòng)時(shí)熟尉，價(jià)值才流動(dòng)
流動(dòng)：從按“部門”和“批量”轉(zhuǎn)化為“生產(chǎn)團(tuán)隊(duì)”和“連續(xù)流”
價(jià)值流中的浪費(fèi)：
- 部分完成的工作（未被集成的代碼）
- 額外過程
- 額外特性：最大化的做當(dāng)下的需求，不要考慮額外的工作
- 任務(wù)調(diào)換：任務(wù)調(diào)整斤儿、切換時(shí)候的浪費(fèi)
- 移動(dòng)：針對強(qiáng)矩陣組織，打破部門墻恐锦。不需要協(xié)調(diào)資源去做事情往果。
- 缺陷：提前發(fā)現(xiàn)問題一铅，成本可降低
- 等待：等待開發(fā)潘飘、等待測試、等待部署，都需要透明化艰毒，想辦法去消除等待
- 管理活動(dòng)：盡量自主去解決問題
為什么要精益敏捷開發(fā)
做到多快好省。通過強(qiáng)調(diào)價(jià)值蜀肘、流動(dòng)和人員，就可以提高質(zhì)量稽屏，降低成本幌缝，加快交付速度
敏捷研發(fā)模型
Scrum：透明化、檢查反饋诫欠、持續(xù)改進(jìn)
長期：向團(tuán)隊(duì)同步價(jià)值、確定使命和目標(biāo)
中期：制定需求和版本中期規(guī)劃
迭代前：需求準(zhǔn)備浴栽，優(yōu)先級(jí)
迭代中：需求池荒叼、每日站會(huì)時(shí)間把握、暴露問題典鸡、sprint review還是需要的
兩周一回顧
3355：3個(gè)角色被廓、3個(gè)工件、5個(gè)活動(dòng)萝玷、5個(gè)價(jià)值觀
五大常見實(shí)踐：
- 測試驅(qū)動(dòng)開發(fā)
- 集體所有權(quán)：針對代碼嫁乘，所有人員可以看到整個(gè)工程的代碼
- 風(fēng)險(xiǎn)和效能的權(quán)衡
- 持續(xù)集成
- 重構(gòu)：優(yōu)雅性的提升，每個(gè)迭代要解決部分技術(shù)債問題
- 結(jié)對編程：code review的進(jìn)一步
看板方法
一種基于精益思想的軟件開發(fā)方法球碉，其五大實(shí)踐：
- 透明化
- 規(guī)則顯示化
- 限制在制品
- 管理流動(dòng)
- 建立反饋蜓斧，持續(xù)改進(jìn)
透明化
針對不同公司、不同場景組織架構(gòu)下睁冬，浪費(fèi)的活動(dòng)定義不一樣
價(jià)值活動(dòng)：需求分析挎春、編碼、……豆拨、部署
I型浪費(fèi)：
- TO C場景下的編寫文檔
- 跨團(tuán)隊(duì)溝通
- 系統(tǒng)間聯(lián)調(diào)
II型浪費(fèi)：
- 協(xié)調(diào)團(tuán)隊(duì)排期
- 部署申請
限制在制品的價(jià)值直奋、原則和方法
什么是在制品
又稱WIP，“進(jìn)行中”能交付客戶價(jià)值的工作施禾，包括待開發(fā)的需求脚线，未被集成的代碼，未測試的代碼弥搞，未部署的制品等邮绿。
為什么？
- 精益思想之流動(dòng)：小批量拓巧，讓價(jià)值流動(dòng)起來
- 在制品越多斯碌，切換和等待產(chǎn)生，反饋環(huán)被拖長
- 通過限制在制品肛度，有效識(shí)別和消除浪費(fèi)傻唾，加速流動(dòng)
- 提高質(zhì)量，減少復(fù)雜度，提高專注度
基本原則
- 限制在制品不是目的冠骄，改進(jìn)才是伪煤；限制過程也是個(gè)改進(jìn)過程
- 人員閑置或工作閑置
- 沒有限制是不對的
- 更低比更高好，但不要使得組織壓力過大凛辣，開始時(shí)設(shè)置大些抱既，建立改進(jìn)驅(qū)動(dòng)力后，逐步調(diào)低
- 停止啟動(dòng)扁誓，聚焦完成
- 單件流"1"并不是答案
思路
限制在制品的過程就是發(fā)現(xiàn)問題和驅(qū)動(dòng)改進(jìn)的過程
方法
- 基于列的在制品限制（更傾向）
- 對于瓶頸處的處理方法——約束理論
- 挖掘策略：挖掘瓶頸處的問題防泵，并解決它
- 保護(hù)策略：如設(shè)置緩沖區(qū)（比如開發(fā)->測試，中間增加“待測試”緩沖區(qū)）
- 服從策略：改善瓶頸效能所需要的變化通常不發(fā)生在瓶頸處蝗敢，關(guān)注整體端到端（可調(diào)用其他資源協(xié)助）
- 突破策略：比如資源增加（最后再考慮這種策略）
- 對于瓶頸處的處理方法——約束理論
- 基于整個(gè)團(tuán)隊(duì)限制
- 按人員限制在制品
管理流動(dòng)方法
管理并監(jiān)控看板的工作流動(dòng)
- 限制在制品
- 顯示化等待列和實(shí)踐捷泞，并縮短等待
- 消除阻塞，永遠(yuǎn)不要被阻塞——敏捷開發(fā)的最高指示
- 避免返工
- 打造跨職能團(tuán)隊(duì)
- 設(shè)定SLA或需求前置時(shí)間目標(biāo)
- 通過每日站會(huì)及時(shí)發(fā)現(xiàn)和跟進(jìn)阻礙流動(dòng)的問題
- 識(shí)別和管理瓶頸
每個(gè)教練要定制適合自己團(tuán)隊(duì)的scrum+kanban研發(fā)模型
需求管理活動(dòng)
用戶故事 VS 工作故事
用戶故事：AS...（角色）寿谴，I WANT...（活動(dòng)目標(biāo)）锁右，SO I CAN...（價(jià)值原因）
工作故事：WHEN...（場景），I WANT...（活動(dòng)目標(biāo)）讶泰，SO I CAN...（價(jià)值原因）
基本要素：標(biāo)題咏瑟、描述、驗(yàn)收條件(DoD)痪署、優(yōu)先級(jí)码泞、大小
產(chǎn)品參與驗(yàn)收
六個(gè)特性：INVEST
從用戶角度拆到最小可測試，可獨(dú)立交付的最小用戶功能
產(chǎn)品經(jīng)理從用戶價(jià)值角度拆狼犯，RD從獨(dú)立負(fù)責(zé)人浦夷，風(fēng)險(xiǎn)可控角度去拆
要權(quán)衡管理成本，對于技術(shù)性團(tuán)隊(duì)辜王，下太重管理成本可能做不下去劈狐。
需求拆分
需求拆分是后續(xù)所有過程的基礎(chǔ)
- 面臨的挑戰(zhàn)
- 如何拆出既能體現(xiàn)進(jìn)度又能在一個(gè)迭代內(nèi)完成的故事
- 如何避免拆出瀑布型階段任務(wù)
- 不會(huì)花費(fèi)太多時(shí)間
- 不會(huì)迷失在網(wǎng)絡(luò)上太多的拆分方法
需求拆分方法
復(fù)雜型故事：涉及基礎(chǔ)架構(gòu)型故事，無法拆分呐馆，占比較小
符合型故事：包含多個(gè)更小的故事肥缔，可以拆分，占比較大
針對業(yè)務(wù)人員汹来，需要了解無法拆分的原因续膳。SPIDR方法
5）. Spikes：刺入探索法。在不知道客戶需求的情況下
2）. Paths：路徑分析法收班》夭恚客戶如何使用功能，客戶路徑摔桦。
1）. Interfaces：場景界面法社付。理清什么場景下客戶的需求承疲，通過什么樣的功能來滿足痛點(diǎn)。
4）. Data：數(shù)據(jù)因素法鸥咖。與Rules類似燕鸽，逐步將數(shù)據(jù)補(bǔ)充給用戶。
3）. Rules：規(guī)則分析法啼辣。在Paths考慮的情況下啊研，可通過迭代的方式逐步增加規(guī)則。
INTERFACE法
PATHS
DATA
RULES
SPKIES
使用MVP來探索用戶的需求
需求估算方法
建議需求估算不要花費(fèi)太多時(shí)間
統(tǒng)計(jì)各種SIZE需求花費(fèi)的歷史數(shù)據(jù)鸥拧，可計(jì)算花費(fèi)人天党远，適合中長期規(guī)劃估算
理想人天：比較難以估準(zhǔn)。
根據(jù)自己的團(tuán)隊(duì)文化進(jìn)行估算需求規(guī)劃和發(fā)布
通過用戶故事地圖富弦，按照場景和大功能進(jìn)行需求歸類麸锉，再從每個(gè)版本規(guī)劃功能（產(chǎn)品經(jīng)理的職責(zé)）
跨團(tuán)隊(duì)敏捷（Scrum of Scrum）
適用場景：團(tuán)隊(duì)需求耦合、團(tuán)隊(duì)技術(shù)架構(gòu)耦合舆声，且團(tuán)隊(duì)人數(shù)也較多的時(shí)候，需要拆分多個(gè)Scrum小團(tuán)隊(duì)柳爽，通過SoS方法進(jìn)行協(xié)作
盡量不要走版本火車的模式媳握，通過管理手段應(yīng)該避免浪費(fèi)，而不是增加浪費(fèi)
產(chǎn)品經(jīng)理團(tuán)隊(duì)制定愿景磷脯、對齊中長期目標(biāo)蛾找、橫向?qū)R需求優(yōu)先級(jí)并驅(qū)動(dòng)一起做計(jì)劃
跨團(tuán)隊(duì)需求引入特性技術(shù)負(fù)責(zé)人，把控和對齊方案
社區(qū)溝通架構(gòu)和技術(shù)演進(jìn)和成長赵誓，促進(jìn)人員能力提升和跨團(tuán)隊(duì)溝通
Sos擴(kuò)展實(shí)踐
- 產(chǎn)品經(jīng)理團(tuán)隊(duì)內(nèi)定期產(chǎn)品發(fā)布規(guī)劃打毛，關(guān)注整體目標(biāo)
- 產(chǎn)品經(jīng)理團(tuán)隊(duì)內(nèi)主動(dòng)對齊需求優(yōu)先級(jí)和依賴
- PM聯(lián)合技術(shù)負(fù)責(zé)人溝通和對齊方案
- 共享團(tuán)隊(duì)chengyuan
- 成立集成團(tuán)隊(duì)專注解決項(xiàng)目集成過程中各種問題
Sos擴(kuò)展實(shí)踐
- 從產(chǎn)品交付價(jià)值角度建立產(chǎn)品backlog，可分不同團(tuán)隊(duì)子視圖
- 產(chǎn)品級(jí)是用戶故事視圖俩功，研發(fā)級(jí)是用戶故事拆分出的任務(wù)視圖幻枉。
- 團(tuán)隊(duì)間協(xié)調(diào)實(shí)踐
- 團(tuán)隊(duì)建設(shè)同步迭代解耦（迭代日歷）
- 派代表參加SoS會(huì)議（定期解決協(xié)作問題）
- 擴(kuò)展Sprint計(jì)劃實(shí)踐
- 產(chǎn)品經(jīng)理和技術(shù)負(fù)責(zé)人提前溝通對齊
- 計(jì)劃日錯(cuò)開
- 大房間（集中辦公）
