從研發團隊管理及產品發展的角度看 DevOps

timwang.work@gmail.com 1
1
從研發團隊管理及
產品發展的角度看DevOps
Tim Wang
2019/12/19
Agile Taipei
Meetup
#1912 加開場

2
Tim Wang
MOXA Networking
Network System Division
PO / 後端架構 / UX / SRE (內部服務)
徵才 (RD/SDET/PMM)
Scrum & DevOps evangelist
貓奴 / 日旅愛好者

3
2008.01 進入職場
2019.04 取得CSPO
2013.10 兼任管理職
2015.XX 團隊試行 Scrum
2016.12 Agile Tour Taipei
2017.XX 團隊試行 DevOps
2018.09 DevOpsDays Taipei 講者
2019.05 轉職兼任產品人(PO)
2018.01 兼任SW Project Manager
2019.07 團隊試行DevSecOps

4
## 本日話題預期圍繞在
- 人、團隊與組織
- 探索、遞交與回饋
- 引領與創造

5
# 軟體研發團隊在
長銷型產品公司的困境

6
## Define 困境
- 推動工程文化(例如DevOps)，好難
- 推動組織變革(例如敏捷)，更難
- 問出為什麼進而看見全貌，超難

7
## 去年DevOpsDays會後得到的提問…
1. 你做這些……你們 PM……?
2. 你做這些……你們 IT ……?
3. 你做這些……你們主管……?

8
資訊軟體服務業佔70%

9
資訊及通訊傳播業 < 3%
宗教、政黨、日常維修、…

10
- DevOps 社群參加者有明顯的群聚
- 案例多樣性不足、業態經驗感覺難以複製、領域法遵限制
- Cloud Native 不只是那張 landscape，也是組織構型
- 製造業留下的人力體系與固有經驗
- C-Phase、我們沒有要維運啊(IT才要維運)
- 倖存者偏誤
- 期望能靠突變而非演化來獲得生存能力

11
廣義上的軟體產品維運是什麼？
確保軟體發佈能夠快速上線及可靠穩定
加新需求必須做好實作隔離及測試
修正已知問題並定義釋出策略
確保一系列產品能夠長期穩定運作
說穿了運維的目的大致相同，差在細節跟手段
…

12
「隊形」

13
## 組織不含 Cloud Native 的 DNA 時
- “IT” 負責的是企業運維：網路要通、電腦要
修、資安認證、盜版軟體、內部系統、工廠
生管系統…
- “IT” 不想也沒空去搞懂Dev/Ops在搞什麼，
但總歸大家最好不要惹麻煩…
Dev端要發起DevOps，
通常得兼當SRE(那條龍)

14
「隊形」

15
Waterfall
Sprint 1
Sprint 4
Box 1 Box 2 Box 5
Sprint 2
Sprint 3
Development
QA Testing
非戰鬥編組下的現實
(Non-feature team) Actual Releasable
Sprint 5
Box 3 Box 4

16
## 組織不含 Cloud Native 的 DNA 時
- 能夠讓 QA 與軟體工程流程充分結合的公司，
我的觀察仍是少數 (即便是純軟)
- 自動化測試開發(SDET)人才非常稀缺
- DevOps 沒起來、測試流程不連貫，敏捷很
快會卡彈
敏捷很容易得到
理所當然的失敗

17
新產品/專案開發
文件(SRS/SAS)驅動開發
文件能抄就抄能少則少
舊產品/專案維護
技術債只修復不重構
能只改軟體就不改硬體
可行性研究
AI, Big Data, Cloud, …
Buzzword-driven
系統元件改版
作業系統、瀏覽器升級
產品硬體料件漲價/停產得換料
軟體得改但不能影響到使用情境
看見全貌 - 需求的來源？
70%維運

18
## 電子業留下的 PM 特色
- 偏重專案管理
- 規格可以用抄的
- 成本優先、唯快不破
- 看似一切都有公式可循
- 原廠roadmap
- 不太需要探索與試驗 (可能也不敢..)

19
## 專案生命週期大不同
- 產品公司
- 運氣好(或不好?)可以做一輩子
- 研究指出EOL前70%時間在維護
- 很多人夢想當甲方，有些人最後選擇加入乙方
- 專案公司
- 一個大 timebox，驗收完解脫
- 科技服務公司盛行，人力即商品，預算轉為營運支出(OPEX)

21
需求規格
散亂不清
變更
難以追溯
沉重的
技術債
散亂多變
的工具鏈
測試牽涉
系統組態
多樣的
釋出組合
訊息遲滯
透明不足

22
Topic 2:
從Dev端發起的DevOps經驗

23
過去常見的景象
一包 Legacy Code 他的版控長這樣
好心的前輩寫的
Readme.txt

24
共通點？
1. 過程蓋很久
2. 擺著沒處理
(或因故處理不了)
3. 突然要拆很麻煩
4. 面臨時間壓力
糟了，是世界奇觀

25
版控一切該版控的產物
“軟體開發的本質：獲取及保存知識” by Terry Yin
追溯變更
知識資產管理
Ref: https://hackmd.io/@ModernWeb/BkNErphQm 遺留代碼經濟學 - Terry Yin

26
需求分析文件
追蹤進度/變更
變更透明易分享
需求統整管理
追溯變更
透明共享

28
進版前相互把關
看板帶來數字感
看板進度透明化
追溯變更
透明共享

30
人
案
週報系統化
數據趨勢透明化
專案分配透明化
透明共享

32
改變溝通工具
透明共享

34
靜態掃描
歷史資產管理
透明共享
[目的]
掌握 Duplications
避免 Memory Leak

35
Design
Implement
Evaluate
Release
• 分析架構，盤點信任邊
界及確保風控對策
• 盤點外部工具使用計畫
• 進行SAST靜態掃描、取
得報告進行統合呈現
• 以 Jenkins 依照品質門
檻進行流程控制與通知
• 進行DAST動態掃描、
黑箱弱掃
• 確認開源工具授權合規、
無重大已知漏洞
• 產出 Software BOI
• 針對釋出檔案進行簽章
及/或產生 MD5 hash
• 針對可轉散佈的封裝，
以 Virustotal 確保無惡
意程式並取得整合報告
E-test
接軌 DevSecOps 引入安全開發流程 (SSDLC)

36
Build/Unit .Test
Kernel Driver
Build/Unit Test
API DLL
Release Signing
(non-Win10)
Pack cabinet
file (*.cab)
EV Signing
(Win10)
Submit to MS
HW Dev Center
等待回應
Generate
hash log
Pack runtime
components
(*.msi)
Build/Pack
utilities (*.msi)
Pack samples
(*.msi)
Pack installer
(exe)
Submit to
VirusTotal
等待回應
產品釋出的
Value Stream
工具鏈整合
釋出組態管理
[目的]
全面導入自動化
盤點釋出過程，找出過
程費時或前置時間
[成果]
視實際狀況可在 25 分
鐘左右產出交付檔案
節省前置作業及等待時
間約30分鐘
> 10 mins
> 10 mins

37
Kernel
Driver
Unit test Build
Release
Signing
(Attestation
signing)
Pack
cabinet file
Local EV
Signing
MS HDC
(傳送並等待)
API DLL Unit test Build Smoke Test
Middleware
Utility
Unit test Build Smoke Test
Component
(msi)
Generate
hash log
Pack
runtime
Pack
utilities
Installer
(exe)
連結
需要的元件
VirusTotal
(傳送並等待)
主動通知
業務單位
流程解耦合
工具鏈整合
釋出組態管理
[改進點]
- 沒彈性
- Artifacts 重複產生
- Artifacts 不易取得
[成果]
視實際狀況可在 2 ~ 16
分鐘內產出交付檔案

39
Artifact Repository
Infra. Automation
待測平台 (IoT) 待測平台 (PC-based)
從交付到部署
[成效]
- 自動化設定平台組態
- 自動化測試腳本的遞
送與執行
- 整合測試帶來高信任
Continuous Delivery
Cont. Deploy
組態自動化
簡化硬體測試

40
套件管理標準化
全自動迴歸測試
組態自動化
簡化硬體測試
任何人都可以輕易取
得最新的可執行檔
(展示/測試/知道進度)

41
導入平台虛擬化
效能監控與通知

44
需求
設計
開發
驗證
封裝
交付
整合
確認
回饋
分享
建立開發流程

45
## Key Takeaways
1. 建立訊息透明化的共識
2. 版控做紮實再講自動化
3. 紀錄一切值得紀錄的變更
4. 自動化一切值得自動化的工作
5. 持續觀察流程並調整
6. 思考如何減少平台的維運成本

46
所以，怎麼跟老闆溝通？
想想過去的成功方程式是什麼

47
Toyota Production System (TPS)
Just-In-Time Production (JIT)
成本(少浪費)、快、標準化
做太多
等待
輸送
加工
庫存
動作
不良品
產能太低的工人

48
Six Sigma
品質、去變異(少浪費)、經驗/統計
https://en.wikipedia.org/wiki/Six_Sigma

49
ISO 9000
數據化、流程化、全力發揮(人)
https://en.wikipedia.org/wiki/Six_Sigma
超越客戶期望
完全投入達成組織目標
為了組織利益完全投入貢獻所能
流程化管理
持續改善是持續性目標
以資料/資訊做決策

50
數據化、標準化
省成本、速度快、品質好
人、機、料、法、環

51
https://dotblogs.com.tw/jimmyyu/archive/2015/08/30/how-to-earn-the-respect.aspx
老闆在乎的事
情其實可以用
Lean及價值流
去溝通，但大
家都在講工具，
卻忘了三步工
作法的第一步
是什麼…

52
識別價值流

53
消除浪費
增強學習
延遲決定
儘快發布
下放權力
嵌入品質
全局優化
LEAN software development

54
DevOps 是可行的
先找到痛點，再談工具輔助

55
#3 DevOps對研發團隊
留用育選
的重要性

56
## 3.1 關於「留」

57
為什麼不是選育用留？XD

58
Ref: DevOps Meetup #? 新時代的人力資源觀念與變革, 晉麗明

59
## 走人的節奏
- 新人進來沒空或不會帶
- 知識管理與傳承在有與沒有之間
- 把工具鏈通通建起來就花了半個月
- 突然就要拿木棒去拆世界奇觀
- 業務邏輯沒有測試保護
- 穩定到沒機會摸新技術或賭博式的拼裝車
想要我的知識嗎? 可以全部都送給你，我都
放在Email跟Slack裡了，去找吧！

60
Ref: https://www.weibo.com/2518512474/Ih60Zl0IP
公務員、三師
科技新貴
金融海嘯、費用化
網路世代、易受影響
敏捷、扁平化溝通

61
需求亂開、市況混沌
工作沒成就感
軟體人覺得很賽想逃
去哪當RD都很賽
還是轉職位吧！
(主管/PM/Sales)
歷練不完整
只有工程實作
缺乏商業/管理思維
不會做訪談/收集需求
不會開規格/管專案
不會帶團隊/做領導
產品滯銷/開不出產品
研發能量停滯
競爭力下降
常見的悲劇循環

62
為什麼不是選育用留？
從已經有的開始改變

63
## 3.2 關於「用」

64
## DevOps 提升效率省時，然後呢？
- 重視可測性、品質保護
- 學需求分析、架構設計
- 學系統工程、實驗設計
- 學商業思維，拉高視角

65
Sprint 2
Box 1 Box 2
Sprint 4
Sprint 3
Sprint 1
Box 3 Box 4
10% 20% 70%
10% 20% 70%
15% 25% 60%
20% 30% 50%
Automated regression Automated regression Automated regression
automated
Automated regression Automated regression
Automated regression
測試發展策略
UI test API test Unit test
Iterations
Test
coverage

66
老闆
Sales / BD
主管 / PM
基層 / RD
商機 / 價值
方案 / 需求
設計 / 架構
自動化省時
正向循環
負向循環
上游思維

68
### 3.3 關於「育」

69
## 我的作法
- 落實知識管理
- 優先順序：文件 (有目錄/易搜尋) → Test case (TDD/BDD)
- 用系統封存知識，用系統的維護、延展及演習做訓練
- 增加回饋頻率
- 每月/每季的 1 on 1 取代年度性的績效考核(PA)
- 充分利用Retrospective / Refinement 的場合
- 鼓勵參與多樣化學習
- 社群活動
- 小班制的技術實作課程

70
## 資料/數據導向
- “It’s science.”
- 取代拍腦袋決策
- 正面看待數據的文化
- 成員的感覺是組織文化的投射
- 正面的文化感覺滿是能量
- 負面的文化感覺盡是負擔今日產
出行數
只有50？
雜碎！

71
•碼農、版控
Dev
• 持續整合、自
動測試組態管理、持
續交付、持續部署、
系統架構
DevOps
•法遵、資安議題
•不要上CVSS、不要侵
權
DevSecOps
•
•商業思維、需求分析、
產品規格、合約、成本
BizDevSecOps

72
### 3.4 關於「選」

73
## 過往常見的模式
- 選人的傾向
- 高重疊率，確保大家都會一樣的東西，降低離職風險
- 高手 = 立刻可以上工作現在規劃的工作
- 分工方式
- 新人進來就是要 maintain、扛賽，這叫做磨練、OJT
- 讓資深去做新議題、做研究

75
## 新的做法
- 選人的傾向
- 無限學習者，願意持續找更好的方式改進自己及團隊
- 願意為團隊好的人
- 學習！熱情！快速迭代！（看似廢話，容易嗎？XD）
- 分工方式
- 只需要具備學習語言/框架的機動性，不一定需要跟資深一樣
的skillset
- 維護舊產品要學習的是“產品知識”，繁雜流程封存在系統中，
交給系統搞定
成員怎麼挑？

76
如果挑錯人可能會引發受害者循環
↓
自動化是不是要裁員？
透明化會不會被找碴？
長週期的品質比較好！

77
DevOps在產品面的意義

78
### 產品負責人(PO/PM)的責任
- 從0到1的探索、雛型實現、驗證
- 引領而非管理
- 質化分析 – 假設 – 量化回饋
- UX很重要，但很多時候你不一定有headcount去養研究員
- 從1到10、100、1000的放大迭代
- 移除阻礙，降低前置時間 (lead time)
- 找對TA，增加用戶接觸面，持續獲得回饋
- 團隊參與決策、參與感、成就感

79
Impact Mapping Event Storming UX prototyping

80
Product Dev.
Life Cycle
回饋收集
定義路線圖
方案設計
開發實作
方案驗證
行銷準備
市場發行
PMM
Mkt
PMM PdM(PO)
PdM(PO)
UX
Architect
RD
RD
QA
SDET
Architect
PjM
PdM(PO) PMM
PdM(PO)
PdM(PO)

81
## DevOps對產品負責人的意義?
- 加速整個 PDLC 循環
- 確保釋出品質
- 提高觸及率
- 以實際回饋數據驗證假設

82
## 產品跟雲沒有直接關連，還有搞頭嗎?
- 使用者旅程地圖(UJM)盤點，設計回饋系統
- 在風險可控的前提下擴大回饋面
- 借助雲服務建立實驗機制
產出交付
透過管道
提供到客戶端
客戶端有環境
且能夠安裝
NOC/SOC:
審核後佈署
工廠:
IT準備離線環境
數周後…
數周後…

83
Non-web-based? 何不考慮IaC+拋棄式環境?
獲取回饋用的 SaaS 服務

84
## 導入雲方案後的優缺點
- 優點
- 實驗組態多樣化(編OPEX就好)、Log檔多樣
- 隔離內部資源減少資安疑慮、也提高存取效能
- 前線Demo、發表會、徵才、面試…
- 減少自行維運成本
- 缺點
- 需要更加的一條龍…XD (but why not?)

85
要總結啦！

86
三步工作法之一
- PO/PM
- UX research
- Value Stream Mapping and/or Impact Mapping
- User Story Mapping and/or Event Storming (DDD)
- 支持以完整的能力編組來構造團隊
- RD
- Trunk-based development & CI
- Feature toggle
- Infra. as Code
- Event-driven and event-storing
- Kata

87
三步工作法之二
- PO/PM
- Retrospective (回顧)
- Refinement (微調)
- Data-centric (資料驅動)
- RD
- 測試金字塔、行為測試
- 埋 Log 輔助做分析決策 (前後端都可)
- System thinking (系統思維)
- Business Awareness (商業思維)

88
三步工作法之三
- PM & RD
- 價值導向
- 假設(hypothesis)驅動
- 信任
- 夥伴關係
- 負責而不咎責

89
帶團隊的課題：
讓團隊具有快速釋出、回應的能力，並培養成長思維
管產品的課題：
如何協助團隊建立價值回饋循環，以成就感驅動眾人

90
“Be the change you want to
see in the world.”
—Mahatma Gandhi

91
Q&A

92
DevOps Taipei Community
 https://www.facebook.com/DevOpsTaiwan/
Agile Community in Taiwan
 https://www.facebook.com/AgileCommunity.tw/
Domain Driven Design Taiwan
 https://www.facebook.com/DDDCommunity.tw/

從研發團隊管理及產品發展的角度看 DevOps

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 從研發團隊管理及產品發展的角度看 DevOps

Semelhante a 從研發團隊管理及產品發展的角度看 DevOps (20)

從研發團隊管理及產品發展的角度看 DevOps

Notas do Editor