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

Transcript

1. timwang.work@gmail.com 1 1 從研發團隊管理及 產品發展的角度看DevOps Tim Wang 2019/12/19 Agile Taipei Meetup #1912 加開場
2. timwang.work@gmail.com 2 2 Tim Wang MOXA Networking Network System Division PO / 後端架構 / UX / SRE (內部服務) 徵才 (RD/SDET/PMM) Scrum & DevOps evangelist 貓奴 / 日旅愛好者
3. timwang.work@gmail.com 3 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. timwang.work@gmail.com 4 4 ## 本日話題預期圍繞在 - 人、團隊與組織 - 探索、遞交與回饋 - 引領與創造
5. timwang.work@gmail.com 5 5 # 軟體研發團隊在 長銷型產品公司的困境
6. timwang.work@gmail.com 6 6 ## Define 困境 - 推動工程文化(例如DevOps)，好難 - 推動組織變革(例如敏捷)，更難 - 問出為什麼進而看見全貌，超難
7. timwang.work@gmail.com 7 7 ## 去年DevOpsDays會後得到的提問… 1. 你做這些……你們 PM……? 2. 你做這些……你們 IT ……? 3. 你做這些……你們 主管……?
8. timwang.work@gmail.com 8 8 資訊軟體服務業佔70%
9. timwang.work@gmail.com 9 9 資訊及通訊傳播業 < 3% 宗教、政黨、日常維修、…
10. timwang.work@gmail.com 10 10 - DevOps 社群參加者有明顯的群聚 - 案例多樣性不足、業態經驗感覺難以複製、領域法遵限制 - Cloud Native 不只是那張 landscape，也是組織構型 - 製造業留下的人力體系與固有經驗 - C-Phase、我們沒有要維運啊(IT才要維運) - 倖存者偏誤 - 期望能靠突變而非演化來獲得生存能力
11. timwang.work@gmail.com 11 11 廣義上的軟體產品維運是什麼？ 確保軟體發佈能夠快速上線及可靠穩定 加新需求必須做好實作隔離及測試 修正已知問題並定義釋出策略 確保一系列產品能夠長期穩定運作 說穿了運維的目的大致相同，差在細節跟手段 …
12. timwang.work@gmail.com 12 12 「隊形」
13. timwang.work@gmail.com 13 13 ## 組織不含 Cloud Native 的 DNA 時 - “IT” 負責的是企業運維：網路要通、電腦要 修、資安認證、盜版軟體、內部系統、工廠 生管系統… - “IT” 不想也沒空去搞懂Dev/Ops在搞什麼， 但總歸大家最好不要惹麻煩… Dev端要發起DevOps， 通常得兼當SRE(那條龍)
14. timwang.work@gmail.com 14 14 「隊形」
15. timwang.work@gmail.com 15 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. timwang.work@gmail.com 16 16 ## 組織不含 Cloud Native 的 DNA 時 - 能夠讓 QA 與軟體工程流程充分結合的公司， 我的觀察仍是少數 (即便是純軟) - 自動化測試開發(SDET)人才非常稀缺 - DevOps 沒起來、測試流程不連貫，敏捷很 快會卡彈 敏捷很容易得到 理所當然的失敗
17. timwang.work@gmail.com 17 17 新產品/專案開發 文件(SRS/SAS)驅動開發 文件能抄就抄能少則少 舊產品/專案維護 技術債只修復不重構 能只改軟體就不改硬體 可行性研究 AI, Big Data, Cloud, … Buzzword-driven 系統元件改版 作業系統、瀏覽器升級 產品硬體料件漲價/停產得換料 軟體得改但不能影響到使用情境 看見全貌 - 需求的來源？ 70%維運
18. timwang.work@gmail.com 18 18 ## 電子業留下的 PM 特色 - 偏重專案管理 - 規格可以用抄的 - 成本優先、唯快不破 - 看似一切都有公式可循 - 原廠roadmap - 不太需要探索與試驗 (可能也不敢..)
19. timwang.work@gmail.com 19 19 ## 專案生命週期大不同 - 產品公司 - 運氣好(或不好?)可以做一輩子 - 研究指出EOL前70%時間在維護 - 很多人夢想當甲方，有些人最後選擇加入乙方 - 專案公司 - 一個大 timebox，驗收完解脫 - 科技服務公司盛行，人力即商品，預算轉為營運支出(OPEX)
20. timwang.work@gmail.com 20 20 需求規格 散亂不清 變更 難以追溯 沉重的 技術債 散亂多變 的工具鏈 測試牽涉 系統組態 多樣的 釋出組合 訊息遲滯 透明不足
21. timwang.work@gmail.com 21 21 Topic 2: 從Dev端發起的DevOps經驗
22. timwang.work@gmail.com 22 22 過去常見的景象 一包 Legacy Code 他的版控長這樣 好心的前輩寫的 Readme.txt
23. timwang.work@gmail.com 23 23 共通點？ 1. 過程蓋很久 2. 擺著沒處理 (或因故處理不了) 3. 突然要拆很麻煩 4. 面臨時間壓力 糟了，是世界奇觀
24. timwang.work@gmail.com 24 24 版控一切該版控的產物 “軟體開發的本質：獲取及保存知識” by Terry Yin 追溯變更 知識資產管理 Ref: https://hackmd.io/@ModernWeb/BkNErphQm 遺留代碼經濟學 - Terry Yin
25. timwang.work@gmail.com 25 25 需求分析文件 追蹤進度/變更 變更透明易分享 需求統整管理 追溯變更 透明共享
26. timwang.work@gmail.com 26 26 進版前相互把關 看板帶來數字感 看板進度透明化 追溯變更 透明共享
27. timwang.work@gmail.com 27 27 人 案 週報系統化 數據趨勢透明化 專案分配透明化 透明共享
28. timwang.work@gmail.com 28 28 改變溝通工具 工作規劃透明化 透明共享 (Fig. 1) 日常透過便利貼進行一些活動，例如讓成員 對於一個大需求(epic)提出自己的想法、如 何拆解工作？避免像 Ruddy 老師也提到的 跑 Scrum 跑到不知道 Story 的全貌是什麼。 也會在需求完成後做回顧會議，了解過程中 做的好或不好的地方，給予鼓勵或協助。 (Fig. 2) 日常聯絡工具使用 Hipchat/Slack 這類協 作工具平台，不使用 Line / 微信 ，避免與 私人訊息混雜在一起，公私分離。每天上班 第一件事是在固定的頻道上發表「昨天做什 麼、今天預計做、以及可能需要的協助」， 可以幫助大家做自我計畫、事後回查及增加 內部透明度，彼此提供協助。
29. timwang.work@gmail.com 29 29 靜態掃描 歷史資產管理 透明共享 [目的] 掌握 Duplications 避免 Memory Leak
30. timwang.work@gmail.com 30 30 Design Implement Evaluate Release • 分析架構，盤點信任邊 界及確保風控對策 • 盤點外部工具使用計畫 • 進行SAST靜態掃描、取 得報告進行統合呈現 • 以 Jenkins 依照品質門 檻進行流程控制與通知 • 進行DAST動態掃描、 黑箱弱掃 • 確認開源工具授權合規、 無重大已知漏洞 • 產出 Software BOI • 針對釋出檔案進行簽章 及/或產生 MD5 hash • 針對可轉散佈的封裝， 以 Virustotal 確保無惡 意程式並取得整合報告 E-test 接軌 DevSecOps 引入安全開發流程 (SSDLC)
31. timwang.work@gmail.com 31 31 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
32. timwang.work@gmail.com 32 32 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 分鐘內產出交付檔案
33. timwang.work@gmail.com 33 33 Artifact Repository Infra. Automation 待測平台 (IoT) 待測平台 (PC-based) 從交付到部署 [成效] - 自動化設定平台組態 - 自動化測試腳本的遞 送與執行 - 整合測試帶來高信任 Continuous Delivery Cont. Deploy 組態自動化 簡化硬體測試
34. timwang.work@gmail.com 34 34 套件管理標準化 全自動迴歸測試 組態自動化 簡化硬體測試 任何人都可以輕易取 得 最新的可執行檔 (展示/測試/知道進度)
35. timwang.work@gmail.com 35 35 導入平台虛擬化 效能監控與通知
36. timwang.work@gmail.com 36 36 測試環境 Intranet Internet DevOps 內部服務平台
37. timwang.work@gmail.com 37 37 需求 設計 開發 驗證 封裝 交付 整合 確認 回饋 分享 建立開發流程
38. timwang.work@gmail.com 38 38 ## Key Takeaways 1. 建立訊息透明化的共識 2. 版控做紮實再講自動化 3. 紀錄一切值得紀錄的變更 4. 自動化一切值得自動化的工作 5. 持續觀察流程並調整 6. 思考如何減少平台的維運成本
39. timwang.work@gmail.com 39 39 所以，怎麼跟老闆溝通？ 想想過去的成功方程式是什麼
40. timwang.work@gmail.com 40 40 Toyota Production System (TPS) Just-In-Time Production (JIT) 成本(少浪費)、快、標準化 做太多 等待 輸送 加工 庫存 動作 不良品 產能太低的工人
41. timwang.work@gmail.com 41 41 Six Sigma 品質、去變異(少浪費)、經驗/統計 https://en.wikipedia.org/wiki/Six_Sigma
42. timwang.work@gmail.com 42 42 ISO 9000 數據化、流程化、全力發揮(人) https://en.wikipedia.org/wiki/Six_Sigma 超越客戶期望 完全投入達成組織目標 為了組織利益完全投入貢獻所能 流程化管理 持續改善是持續性目標 以資料/資訊做決策
43. timwang.work@gmail.com 43 43 數據化、標準化 省成本、速度快、品質好 人、機、料、法、環
44. timwang.work@gmail.com 44 44 https://dotblogs.com.tw/jimmyyu/archive/2015/08/30/how-to-earn-the-respect.aspx 老闆在乎的事 情其實可以用 Lean及價值流 去溝通，但大 家都在講工具， 卻忘了三步工 作法的第一步 是什麼…
45. timwang.work@gmail.com 45 45 識別價值流
46. timwang.work@gmail.com 46 46 消除浪費 增強學習 延遲決定 儘快發布 下放權力 嵌入品質 全局優化 LEAN software development
47. timwang.work@gmail.com 47 47 DevOps 是可行的 先找到痛點，再談工具輔助
48. timwang.work@gmail.com 48 48 #3 DevOps對研發團隊 留用育選 的重要性
49. timwang.work@gmail.com 49 49 ## 3.1 關於「留」
50. timwang.work@gmail.com 50 50 為什麼不是選育用留？XD
51. timwang.work@gmail.com 51 51 Ref: DevOps Meetup #? 新時代的人力資源觀念與變革, 晉麗明
52. timwang.work@gmail.com 52 52 ## 走人的節奏 - 新人進來沒空或不會帶 - 知識管理與傳承在有與沒有之間 - 把工具鏈通通建起來就花了半個月 - 突然就要拿木棒去拆世界奇觀 - 業務邏輯沒有測試保護 - 穩定到沒機會摸新技術 或 賭博式的拼裝車 想要我的知識嗎? 可以全部都送給你，我都 放在Email跟Slack裡了，去找吧！
53. timwang.work@gmail.com 53 53 Ref: https://www.weibo.com/2518512474/Ih60Zl0IP 公務員、三師 科技新貴 金融海嘯、費用化 網路世代、易受影響 敏捷、扁平化溝通
54. timwang.work@gmail.com 54 54 需求亂開、市況混沌 工作沒成就感 軟體人覺得很賽想逃 去哪當RD都很賽 還是轉職位吧！ (主管/PM/Sales) 歷練不完整 只有工程實作 缺乏商業/管理思維 不會做訪談/收集需求 不會開規格/管專案 不會帶團隊/做領導 產品滯銷/開不出產品 研發能量停滯 競爭力下降 常見的悲劇循環
55. timwang.work@gmail.com 55 55 為什麼不是選育用留？ 從已經有的開始改變
56. timwang.work@gmail.com 56 56 ## 3.2 關於「用」
57. timwang.work@gmail.com 57 57 ## DevOps 提升效率省時，然後呢？ - 重視可測性、品質保護 - 學需求分析、架構設計 - 學系統工程、實驗設計 - 學商業思維，拉高視角
58. timwang.work@gmail.com 58 58 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
59. timwang.work@gmail.com 59 59 老闆 Sales / BD 主管 / PM 基層 / RD 商機 / 價值 方案 / 需求 設計 / 架構 自動化省時 正向循環 負向循環 上游思維
60. timwang.work@gmail.com 60 60 ### 3.3 關於「育」
61. timwang.work@gmail.com 61 61 ## 我的作法 - 落實知識管理 - 優先順序：文件 (有目錄/易搜尋) → Test case (TDD/BDD) - 用系統封存知識，用系統的維護、延展及演習做訓練 - 增加回饋頻率 - 每月/每季的 1 on 1 取代年度性的績效考核(PA) - 充分利用Retrospective / Refinement 的場合 - 鼓勵參與多樣化學習 - 社群活動 - 小班制的技術實作課程
62. timwang.work@gmail.com 62 62 ## 資料/數據導向 - “It’s science.” - 取代拍腦袋決策 - 正面看待數據的文化 - 成員的感覺是組織文化的投射 - 正面的文化感覺滿是能量 - 負面的文化感覺盡是負擔 今日產 出行數 只有50？ 雜碎！
63. timwang.work@gmail.com 63 63 碼農、版控 Dev 持續整合、自動測試 組態管理、持續交付、 持續部署、系統架構 DevOps 法遵、資安議題 不要上CVSS、不要侵權 DevSecOps 商業思維、需求分析、 產品規格、合約、成本 BizDevSecOps
64. timwang.work@gmail.com 64 64 ### 3.4 關於「選」
65. timwang.work@gmail.com 65 65 ## 過往常見的模式 - 選人的傾向 - 高重疊率，確保大家都會一樣的東西，降低離職風險 - 高手 = 立刻可以上工作現在規劃的工作 - 分工方式 - 新人進來就是要 maintain、扛賽，這叫做磨練、OJT - 讓資深去做新議題、做研究
66. timwang.work@gmail.com 66 66
67. timwang.work@gmail.com 67 67 ## 新的做法 - 選人的傾向 - 無限學習者，願意持續找更好的方式改進自己及團隊 - 願意為團隊好的人 - 學習！熱情！快速迭代！（看似廢話，容易嗎？XD） - 分工方式 - 只需要具備學習語言/框架的機動性，不一定需要跟資深一樣 的skillset - 維護舊產品要學習的是“產品知識”，繁雜流程封存在系統中， 交給系統搞定 成員怎麼挑？
68. timwang.work@gmail.com 68 68 如果挑錯人可能會引發受害者循環 ↓ 自動化是不是要裁員？ 透明化會不會被找碴？ 長週期的品質比較好！
69. timwang.work@gmail.com 69 69 DevOps在產品面的意義
70. timwang.work@gmail.com 70 70 ### 產品負責人(PO/PM)的責任 - 從0到1的探索、雛型實現、驗證 - 引領而非管理 - 質化分析 – 假設 – 量化回饋 - UX很重要，但很多時候你不一定有headcount去養研究員 - 從1到10、100、1000的放大迭代 - 移除阻礙，降低前置時間 (lead time) - 找對TA，增加用戶接觸面，持續獲得回饋 - 團隊參與決策、參與感、成就感
71. timwang.work@gmail.com 71 71 Impact Mapping Event Storming UX => Wireframing
72. timwang.work@gmail.com 72 72 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)
73. timwang.work@gmail.com 73 73 ## DevOps對產品負責人的意義? - 加速整個 PDLC 循環 - 確保釋出品質 - 提高觸及率 - 以實際回饋數據驗證假設
74. timwang.work@gmail.com 74 74 ## 產品跟雲沒有直接關連，還有搞頭嗎? - 使用者旅程地圖(UJM)盤點，設計回饋系統 - 在風險可控的前提下擴大回饋面 - 借助雲服務建立實驗機制 產出交付 透過管道 提供到客戶端 客戶端有環境 且能夠安裝 NOC/SOC: 審核後佈署 工廠: IT準備離線環境 數周後… 數周後…
75. timwang.work@gmail.com 75 75 Non-web-based? 何不考慮IaC+拋棄式環境? 獲取回饋用的 SaaS 服務
76. timwang.work@gmail.com 76 76 ## 導入雲方案後的優缺點 - 優點 - 實驗組態多樣化(編OPEX就好)、Log檔多樣 - 隔離內部資源減少資安疑慮、也提高存取效能 - 前線Demo、發表會、徵才、面試… - 減少自行維運成本 - 缺點 - 需要更加的一條龍…XD (but why not?)
77. timwang.work@gmail.com 77 77 要總結啦！
78. timwang.work@gmail.com 78 78 三步工作法之一 - 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
79. timwang.work@gmail.com 79 79 三步工作法之二 - PO/PM - Retrospective (回顧) - Refinement (微調) - Data-centric (資料驅動) - RD - 測試金字塔、行為測試 - 埋 Log 輔助做分析決策 (前後端都可) - System thinking (系統思維) - Business Awareness (商業思維)
80. timwang.work@gmail.com 80 80 三步工作法之三 - PM & RD - 價值導向 - 假設(hypothesis)驅動 - 信任 - 夥伴關係 - 負責而不咎責
81. timwang.work@gmail.com 81 81 帶團隊的課題： 讓團隊具有快速釋出、回應的能力，並培養成長思維 管產品的課題： 如何協助團隊建立價值回饋循環，以成就感驅動眾人
82. timwang.work@gmail.com 82 82 “Be the change you want to see in the world.” —Mahatma Gandhi
83. timwang.work@gmail.com 83 83 Q&A Backend Frontend SW PM …and we are hiring!
84. timwang.work@gmail.com 84 84 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/