技術團隊領導人

AgileCommunity.TW
2020.03.21 分享

Transcript

1. 技術團隊領導人 成為Tech Team Lead的歷程
2. 大綱 • 敏捷管理/開發導入的那些事 • 產品開發的構想 • 領域驅動實務應用 • 軟體架構設計 • 中台概念
3. 敏捷管理/ 開發導入的 那些事
4. 瀑布歲月 快樂的豬 or 痛苦的蘇格拉底
5. Scrum導入
7. 抱歉… 我導入失敗了
8. 故事開始
9. 如同遊戲機般 可隨意切換遊戲 的網路平台 產品目標
10. 組織 RD團隊 QA團隊 BA團隊 IT團隊 平台開發團隊 + 企業整合團隊 + 核心開發團隊 遠在另一端的辦公室,與任何一個RD團隊,距離都很遙遠 與平台開發團隊位置較近,但是成員都沒有相關領域知識與經驗 伺服器管理,產品環境手動上版
11. Demo會議 回顧會議 • 找BA作確認 • 每個月跟老闆 確認 • 僅開發人員 • 其他開發部門 發言人 Product Backlog 制定 • BA團隊產出 • C_O初步確認 • BA團隊與RD Manager確認 Planning會議 • RD經理解釋 需求 • RD團隊理解 需求與估算 每日會議 • RD團隊 • 其他開發部門 發言人 • 僅有Daily Build • 沒有CI,無法CD • 沒有TA設定 • 沒有單元測試 • 沒有產品路徑 • 沒有利害關係 人管理 • 功能團隊 • …. 2週
12. 噩夢般的經歷
13. 雖然慘烈,還是學 到了點什麼
14. 看法方法導入
15. 事件的起因 1個月 禁止第4,5方支付
16. 沒有解法….
17. PM也剛好離職
19. 戰鬥!
20. 其實我腦袋一片空白
21. 不過上個月 我學了看板方法…
22. 分享我的看 板方法的戰 鬥歷程
23. 先搞懂流程 Backlog Working on Verify Deployed 順序
24. 光是這個階段 就快要搞死我 了…
25. 泳道 Backlog Working on Verify Deployed Emergency 特殊流程 泳道 Backlog Working on Verify Deployed Emergency Normal Bug Enhancement Emergency Definition of Done • 通過系統測試 • 通過允收測試 • 可發佈
26. 工作故事 2020-03-23 As a …. I want to…. So that …. Lisa 預計完成的日期 完成的子任務數 User story的負責人 (負責不一定就是全由他做) Start: 2020-03-01 End: 2020-03-22 開始日期,結束日期 User story描述
27. 拉式系統 Backlog Working on Verify Deployed Emergency In progress Done Pull
28. 瓶頸處理 每個系統都擁有瓶頸,而處理 瓶頸有五個步驟: 1.找出瓶頸 2.確保瓶頸總是滿載 3.調整瓶頸區接鄰區域的工 法 4.增加資源到瓶頸區 5.若第4步打破了瓶頸,就再 回到步驟1 1 Identify the constraint 2 Exploit the constraint 3 Subordinate everything else to the constraint 4 Elevate the constraint 5 Go back To step #1
29. 訊號 Backlog Working on Deployed Emergency In progress Done Verify Buffer 額外多一個欄位
30. 指標 2020-03-23 As a …. I want to…. So that …. Lisa Start: 2017-06-01 End: 2017-06-22 Backlog Working on Deployed Emergency 3 Verify 2 Buffer 3 前導時間= 完工日期 – 收單日期 吞吐量 = 單位時間的完工數量 前導時間 工期
31. 再製品的那些事… Backlog Working on Deployed 5 Verify 5 Buffer 3 反 覆 切 換 反 覆 切 換 沒人理 等很久 Backlog Working on Deployed 1 Verify 1 Buffer 1 好無聊! 瓶 頸 間 動不了 做完了,動不了 Cycle Time = Work in Progress Throughput (Little’s Law) 團隊在製品上限計算: Step1. 一個團隊成員估算其工作能力為2 2 * 5 = 10 Step2. 提升壓力,可以先從少一個人算起 2*4 = 8
32. One-Piece Flow 每個階段在完成一定的批 量之後才交由下一個階段 每個階段在完成自己階段 的工作之後,交由下一個階 段 Batch Producing One-Piece Flow
33. 之後就讓團 隊自動導航
34. 解決方案 的選擇 參考鏈結
35. 容器化與CI/CD
36. 先大量收集 案例和資訊
37. 你看見的是什麼
38. 關鍵在於思考
39. 深刻思考 順序 協同 相關 相似
40. 這是一場漫長 的戰鬥….
41. 整合是工程問題 發布是業務問題 最後的絮語
42. 產品開發
43. 每個人都 該有夢想
44. 做產品，從使用者著手
45. 關於用戶畫像 用戶 畫像 目標 方式 組織 標準 驗證 描述人、認識人、了解人、理解人 • 非形式化手段:文字、 語音、圖像、視訊… • 形式化手段 結構化、非結構化 常識、共識、知識體系 • 依據: 事實、推理過程 • 檢驗 做產品先從TA 著手,因為很多 初期產品決策 都是為了更輕鬆 獲得期望的客戶
46. 更多維度的用戶畫像 客戶維度 用戶溝通 資訊 用戶基本 資訊 用戶產品 使用資訊 用戶聯絡 資訊 用戶事件 用戶資產 資訊 用戶財務 資訊 用戶風險 資訊 • 用戶姓名 • 客戶性質資訊 • 產品類型 • 購買時間 • 再購時間 • 用戶聯絡資訊 包括: 聯絡地址、 公司網址 • 重大事件: 公司開業,生日…等 • 違約事件: 逾期付款…等 • 可疑事件: 灰色地帶的操作 • 用戶資產相關 資訊 • 用戶利潤 貢獻度 • 信用評級 • 黑名單 • 用戶建議、 申訴、回訪、 投訴…等 傳統用戶畫像資料緊緊來自 業務資訊，事件資訊，關係 資訊…等多條資訊佚失或不足 很難形成準確、全方位的畫像 引入大數據，實現客戶360度 立體化像 業 務 系 統 資 料 用 戶 基 本 產 品 資 訊 訂 單 資 訊 客 服 資 訊 企 業 內 外 大 數 據 社 交 媒 體 社 交 網 站 流 量 日 誌 參考連結
47. 每個人都有多 個腳色 不要用腳色 作為用戶畫像
48. 思考怎麼吸引到 第一隻羊
49. 想要獲得第一隻羊,一定要能抓眼球 Averager is out!
50. 設計
51. 持續探索和思考
53. 你需要一些工具幫忙 影響力地圖 使用者旅程地圖 使用者故事地圖 服務藍圖 事件風暴
54. 分析/解構- 以事件風暴為例
55. 分析/解構- 以事件風暴為例 Inception Design
56. 感觸
58. 好產品 + 好服務 = 一筆好生意 何不再加一點服務?
59. 什麼是服務設計? 服務設計是以使用者為中心的方法，聚焦在顧客的體驗上，以提升 服務前端的品質為成功的關鍵及價值所在。期望在使用者體驗 及顧客旅程中，讓使用者感動且成為具有創新的標的。 Team Lead需要理解服務設計, 才能夠設計出適合的產品。
60. 從使用者旅程地圖著手 參考
61. 痛點 癢點 爽點 來自於恐懼,會直接驅動行為 滿足虛擬的自我 需求即時被滿足 參考連結 三個切入點
62. 峰終定律
63. 情緒地圖+峰終定律 峰 值 終 值 底線 峰值和終值都是製造產品 良好體驗和印象的關鍵點, 更重要的是不能觸碰客戶 的底線!
64. 有時候失敗不是 你所想像的原因
65. 利害關係人 策略: 保持滿意 策略: 重點管理 策略: 持續管理 策略: 保持溝通 風險
66. 軟體架構設計
67. 軟體設計針對什麼需求作設計? 功能性需求 非功能性需求
68. 架構設計的意義
69. 架構設計的意義 營運期
70. 架構的維度 二維架構 三維架構 四維架構 架構的完整度與完備度是一體
71. 寫程式不容易,管理物件狀態更不容易
72. 軟體架構制定限制和原則
73. 軟體架構品質因子(Factor)
75. 架構設計的根本 在於抽象力
76. 拐點來啦
77. 架構的基本原則 如何判斷重複的程式碼? 不僅是二維,三維架構也 可以套用 易變或著很久不變
78. DRY的描述 “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” Andy Hunt – The Pragmatic Programmer
79. DRY套用的準則- 限界上下文 + 通用語言
80. 越貼近I/O,則越容易變動 越富含領域知識,越不容易變動
81. 不與人相依的模組,受到其它模組干擾的機率=0
82. 六角 洋蔥 Clean Domain Model都在內核
83. 軟體架構的本質
85. 架構 參考鏈結
86. 模式的六大基本元素 Name 模式名稱 給模式一個名稱,可以方便聯想 與促進溝通。 Context 問題的背景 描述問題發生的背景和 情境。 Problem 問題 描述問題 Force 問題的限制 問題本身的限制或需要補充 的特性,以便提供解決方案的 參考。 Solution 解決方案 解決問題的方法。 Resulting Context 後續的邊際效應 套用解決方案之後產生的結果, 以及衍生的後續情況。 參考鏈結
87. 領域模型三步工作法- 捕捉, 嵌合, 保護 Capture Embedded Protect
88. 微服務
89. Monolith V.S. Micro Service 參考鏈結
90. 微服務架構-3維
91. 微服務架構-2維 參考鏈結
92. 微服務的基石 Core Business Logic Transport Service Discovery Metrics Rate Limiting Tracing Circuit Breaking App Logging Audit Logging Service Registry Security Caching Strategy Alerting Contract Testing Deploy Strategy Core Biz Logic Service Metrics Application Logging Business analytics Balancing, Limiting, Safety Operational Metrics Transport Endpoint Service 參考鏈結
93. 參考資料 服務協作
94. 服務通訊 - 同步 v.s. 非同步通訊 同步 完整的 請求/響應 週期 非同步 微服務之間的內部溝通 (EventBus: 如 AMQP) 非同步 微服務之間的內部溝通 (Polling: 如 Http) 參考鏈結
95. 微服務架構(MSA) V.S. 服務導向架構(SOA) 比較項目 MSA SOA 適用系統 快速迭代的網路應用系統 靜態的、企業級的大型應用系統 服務粒度 服務功能單一、粒度小 服務包含的功能多，服務多樣化，粒度大 通訊機制 REST, RPC等輕量級通訊機制 SOAP等重量級通訊機制 實現方式 RESTful Web Service, ESB等 部署方式 服務部署為服務組件，在獨立的程序中，部署較為複雜 服務部署為應用系統,在統一的平台中,部署比較簡單 中心模式 去中心化 有中心組件，如: ESB 支援業務變化 高，敏捷 低 併發訪問機制 簡單，分散式 複雜，集群式 基礎設施 MSA提倡構建細粒度服務，致力於構建鬆耦合的輕量級 架構,是面向服務模組級別的實現方式。其服務發現機制、 安全性、可靠性、負載均衡、服務管理、服務監控與日 誌等諸多功能都是其中的服務組件 集中式企業服務匯流排(ESB)進行跨平台的大規模整合和持續的 改進業務流程,是企業級的應用架構,企業服務匯流排承擔了: 資 料轉換、服務查詢、智能路由、授權、安全性、可靠性、負載 均衡、服務管理、服務監控與日誌等諸多功能,結構較龐大複雜
96. 採用微服務帶來的挑戰 商業風險 98%遇到識別根本問題與 商業風險直接的關係 除錯 73% 發現在微服務環境中, 除錯是很困難的 資料量負擔 17% 不知道該如何治理不斷增加 的資料量 Log的成本 21% 意識到log的匯總成本 越來越高 維運 56% 每添加一個微服務 就增加了維運上的挑戰 技能 45% 不具備建構和管理微服務 的能力 參考鏈結
97. 微服務類型 技術型 業務型 • 基礎應用功能 • 如: 快取、郵件寄送、Session管理 • 功能單一 • 複用性高 • 業務應用功能 • 如: 會員、訂單、倉儲 • 業務聚焦 • 複用性僅在同業態，否則極低
98. Gateway設計樣式
99. 微服務前後端連接
100. 微前端 參考鏈結
101. 微服務測試
102. Best Practice 1. 判斷是否適合微服務 2. 定義你的微服務 3. 使用DDD來設計微服務 4. 取得組織和團隊領導的支持 5. 使用RESTful API尤佳 6. 依微服務調整組織結構 7. 為每一個為服務配置獨立的資料儲存體 8. 基於領域設計API,以及動態API文件 9. 配合DevOps 10. 在監控上多多投資
103. 分散式交易: SAGA 利用事件或是Http的Request/Response 中間某個流程出了問題
104. 統一Log儲放 每個服務都有專屬的Log 針對Gateway收集Log, 集中放置
105. 團隊組織
106. Micro Service Pattern
107. 該如何切 割微服務?
108. 領域驅動 實務應用
109. 問題域 & 解決方案域 領域包含: 問題 + 解決方案域 問題域: 待解決的商務挑戰 解決方案域: 問題域的解決方案 限界上下文(Bounded Context)是具體解決方案的邊界 問題域依照商業性質切割為多個子領域(Subdomain)
110. 實際例子 為什麼引擎是Core Subdomain?
111. 商業
112. 價值 獨特價值
113. 對應
114. 探索限界上 下文
115. Bounded Context Map 參考鏈結 限界上文對應到商業是什麼?
116. 商業架構 商務能力 資訊 價值流 組織 利害關 係人 願景和 戰略 行動和 專案 決策和 事件 指標和 度量 產品和 服務 政策和 法規 商業架構是剖析企業的好工具
117. 商業能力 人力資本 管理 人才管理 招募 開發 保留 評估 推薦 新 血 商業能力 商業功能 商業活動 實現 概念性 邏輯性 實現 目 標
118. 限界上下文對應子領域
119. 限界上下文對應子領域
120. 限界上下文圖 U U U D D D
121. 限界上下文圖 (Context Map)
122. 完整範例
123. 範例: 限界上下文溝通 + CQRS 參考鏈結
124. 領域驅動設計的戰術概觀 參考鏈結
125. 戰略分析 參考鏈結
127. 從DDD到微服務 限界上下文 > 微服務顆粒度 > 聚合
128. 中台
129. 過去的企業系統如同煙囪
130. 業務需求和系統響應能力 業務對系統的需求 系統響應業務能力 (傳統專案建構方式) 業 務 需 求 和 系 統 響 應 能 力 非互聯網時代 互聯網時代
131. 企業需要 超神速反應
132. 中台概念 前台 靈活 緩衝的橋樑 後台 穩定 中 台 連結技術和場景、打破內部隔閡 提供可復用能力、避免重複建設 敏捷服務用戶 基礎服務能力支持 • 快速使用能力 • 快速擴展業務 • 小成本試錯、快速迭代 • 微服務架構 • DevOps基礎設施 • 公共服務設施
133. 中台的由來
134. 阿里巴巴的企業架構演化 初期 共享業務 加入1688 提煉共享 業務 中台雛形
135. 啟動 交易 檢查 庫存 其他 服務 新增訂單流程 啟動 交易 交易 日誌 其他 服務 新增訂單流程 啟動 交易 檢查 團購 訂單 其他 服務 新增訂單流程 會員管理 前端 會員服務 商品管理 前端 商品服務 交易管理 前端 交易服務 支付管理 前端 支付服務 會員資料庫 商品資料庫 交易資料庫 支付資料庫 共 享 服 務
136. 阿里巴巴的技術架構演進 IOE 分散式 平台化 中台化 業務快速上線 • 單一Java網站 • 幾十人到幾百 人共同維護 全棧分散式 • 分散式呼叫 • 分散式DB • 服務註冊 全平台化(拓寬邊界) • 持續優化領域模型 • 簡單復用 中台化 • 統一業務能力認識 • 能力地圖
137. 中台方法 1. 戰略升級 中台建設一定要上升到 企業高層層面,圍繞核心 戰略規劃分步實施,以小 步快跑方式在過程中不斷 檢驗與糾正。 2. 組織升級 傳統企業業務的割裂,其 根源往往來自組織架構的 分割。業務需要涉及到 跨部門協同時,”部門牆”情況 嚴重,中台建設必須結合組織優化 兩者並行。 3. 流程升級 傳統企業通常採用”流水線”作業 的方式。結合商業套件實現流程 進化,中台更關注業務領域自身的 能力與流程共享。流程升級必不 可少。 4. 技術升級 隨著互聯網業務的不斷創新,企業 通過IT技術升級實現業務敏捷創新、 隨需而變、資料即時共享打通。 中台是由上而下的變革工程,全員共識是關鍵。
138. 典型的業務中台建設路徑 1. 決心變革 2. 成功試點 3. 持續融合 戰略共識 賦能、消化 迭代、優化 • 高層推行，全員共識 • 總體規劃、分步驟實施 • 找準切入點，解決具體業務問題 • 明確的業務目標和範圍 • 驗證過的技術平台 • 驗證過的中台方法論 • 靠譜的團隊 • 磨合出自己的中台理念和規範 • 優化組織、提升中台效率 • 與原廠技術、業務共同發展 • 構建自己的業務能力生態
139. 中台組織的啟發來源 小團隊在前線隨機應變 後方有強大火力支援
140. 中台組織=敏捷組織
141. 導入中台後的工作流變化 資料 策略 執行 現在: 資料驅動 過去: 業務驅動 資料 策略 執行 單點、各渠道割裂的營銷活動。 由資料中台統籌、多渠道策略配合 的營銷活動。
142. 實例: 中台組織運作 需求分析 平台已有能力 發現 業務流程定制 開發 解決方案 發布 業務技術開發團隊 業務領域抽象 規範制定 業務領域能力 推廣和接入 基於場景的能力 解決方案沉澱 中台營運團隊 基礎能力開發 基礎能力註冊 新能力沉澱 中台技術開發團隊 中 台 中 台 業 務技 術 營 運 技 術
143. 中台軟體架構 前台 業務中台 資料中台 後台
144. 企業級架構設計的難點 割裂 標準化 包容性 企業經營是一個整體 業務卻常常是分場景 企業管理強調標準化 一線業務創新卻是個性化 企業內部流程需要管控 同時又需要開放與整合多種外部場景 與多個合作夥伴
145. 企業級架構的層次 商業架構 戰略, 商業流程,組織, 功能 資料架構 業務實體, 資料 應用架構 應用程式元件, SOA架構 技術架構 硬體架構,元件,部署
146. Pace-Layer架構 創新系統 差異系統 紀錄系統 • 解決方案透過大型專案的多個階段提供 • 預期系統生命週期為中長期(3~4年) • 客制化服務,商業邏輯都放在這一層 • 預期系統生命週期較長 • 變更控制較為嚴格，資料受到嚴密監控 • 核心交易處理 • 概念驗證,功能少並且可能手動部署 • 在解決方案穩定之前,無須正式的變更管理 • 運行幾個月後,決定是進入成熟方案,或是取消 Rate of Change API Design Change Control Testing Regine 快 慢 特 定 可 重 用 寬 鬆 嚴 格 手 動 自 動
147. 中台的真意 業務前台 (電商、銷售、客服) 業務中台 (研發、共享業務) 業務後台 (施工、生產、物流) 應用前台 應用中台 應 用 架 構 資料架構 (資料中台) 資料架構 (資料中台) 業務前台 業務中台 業務後台 客服中心、 加油站、經銷商 組織中台 (總部: 人財物和營運) 分 公 司 1 分 公 司 2 分 公 司 N … 組 織 後 台 組 織 前 台 業 務 驅 動 技 術 驅 動 通過資訊資源整合、優化組織體系、促進業務變革 業務架構 IT架構 企業架構
148. 中台設計關鍵元素 SOA Micro-Service Domain-Driven-Design
149. 業務中台的實踐 參考鏈結 問題域 解決方案域 問題域 微服務邊界 API設計 服務間通訊協定 DDD領域建模 微服務設計 精實需求管理 微服務邊界 拆分維度 需求變化 為服務開發實踐 自動化維運 灰度發布 CI/CD 全功能團隊 CodeReview A/B測試 自動化測試 測試金字塔 Agile & DevOps 需求分層與優先級 服務治理策略 問題域 解決方案域 問題域 基礎工程能力 服務註冊與發現 API Gateway 容器化 日誌收集與分析 遺留系統分析 依賴 決定 決定
150. 阿里巴巴業務架構 存款交易 貸款交易 理財交易 消費交易 訂 單 購 物 車 交易中心 現金支付 餘額支付 紅包支付 積分支付 組合 支付 收銀 台 支付中心 抽獎 秒殺 優惠買單 立減 營銷中心 註冊、登入 安全、核身 會話管理 用戶資料維護 用戶中心 電子帳戶開戶 帳戶加掛 綁卡 電子帳戶動賬 帳戶中心 產品模板 產品類目 產品組態 上架、下架 產品中心 對帳 清算 文件下載 結果下載 清算中心 權益發放 權益消費 發放規則 權益核銷 積 分 優 惠 券 權益中心 協議資料 業務資料 系統參數 通用資料 資料 同步 資料 推送 基礎中心 檔案收集 資料清洗 文件儲存 搜尋 日誌分析中心 報文流水號 資料庫主鍵 訂單流水號 業務ID 日誌分析中心 參數訂閱 變更監控 參數加載 參數下載 變更 通知 接收 參數 儲存 組態中心 分散式服務 框架(EDAS) 分散式資料集 (DRDS + MySQL) 分散式佇列 (MQ) 分散式快取 (Redis) 分散式交易 (GTS) 即時監控服務 網路銀 行 手機 銀行 發現精 彩 支付 網關 直銷 銀行 商城 開放 應用 能力開放 (API, H5, SDK) 外連 網關 電商 P2P 企業 直連 第三方系統 IaaS(VMware) 展示端 支付寶 國壽 銀聯 公民 聯網和查 人行 徵信 … 第三方系統 信用卡 核心 借記卡 核心 ECIF 基金 系統 理財 系統 貸款系統 行內系統 中間 業務 保險 系統 交易 來源 業務 應用 業務 中台 基礎 服務 (PaaS) 基礎設施 (IaaS)
151. Recap 產品 力 管理 力 開發 力
152. 在哪裡被打倒 就在哪裡躺好
153. 有時候你覺得很 挫敗
154. 你還有社群夥伴