Upgrade to Pro — share decks privately, control downloads, hide ads and more …

技術團隊領導人

國昭
March 21, 2020

 技術團隊領導人

AgileCommunity.TW
2020.03.21 分享

國昭

March 21, 2020
Tweet

More Decks by 國昭

Other Decks in Programming

Transcript

  1. 組織 RD團隊 QA團隊 BA團隊 IT團隊 平台開發團隊 + 企業整合團隊 + 核心開發團隊

    遠在另一端的辦公室,與任何一個RD團隊,距離都很遙遠 與平台開發團隊位置較近,但是成員都沒有相關領域知識與經驗 伺服器管理,產品環境手動上版
  2. Demo會議 回顧會議 • 找BA作確認 • 每個月跟老闆 確認 • 僅開發人員 •

    其他開發部門 發言人 Product Backlog 制定 • BA團隊產出 • C_O初步確認 • BA團隊與RD Manager確認 Planning會議 • RD經理解釋 需求 • RD團隊理解 需求與估算 每日會議 • RD團隊 • 其他開發部門 發言人 • 僅有Daily Build • 沒有CI,無法CD • 沒有TA設定 • 沒有單元測試 • 沒有產品路徑 • 沒有利害關係 人管理 • 功能團隊 • …. 2週
  3. 泳道 Backlog Working on Verify Deployed Emergency 特殊流程 泳道 Backlog

    Working on Verify Deployed Emergency Normal Bug Enhancement Emergency Definition of Done • 通過系統測試 • 通過允收測試 • 可發佈
  4. 工作故事 2020-03-23 As a …. I want to…. So that

    …. Lisa 預計完成的日期 完成的子任務數 User story的負責人 (負責不一定就是全由他做) Start: 2020-03-01 End: 2020-03-22 開始日期,結束日期 User story描述
  5. 指標 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 前導時間= 完工日期 – 收單日期 吞吐量 = 單位時間的完工數量 前導時間 工期
  6. 再製品的那些事… 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
  7. 關於用戶畫像 用戶 畫像 目標 方式 組織 標準 驗證 描述人、認識人、了解人、理解人 •

    非形式化手段:文字、 語音、圖像、視訊… • 形式化手段 結構化、非結構化 常識、共識、知識體系 • 依據: 事實、推理過程 • 檢驗 做產品先從TA 著手,因為很多 初期產品決策 都是為了更輕鬆 獲得期望的客戶
  8. 更多維度的用戶畫像 客戶維度 用戶溝通 資訊 用戶基本 資訊 用戶產品 使用資訊 用戶聯絡 資訊

    用戶事件 用戶資產 資訊 用戶財務 資訊 用戶風險 資訊 • 用戶姓名 • 客戶性質資訊 • 產品類型 • 購買時間 • 再購時間 • 用戶聯絡資訊 包括: 聯絡地址、 公司網址 • 重大事件: 公司開業,生日…等 • 違約事件: 逾期付款…等 • 可疑事件: 灰色地帶的操作 • 用戶資產相關 資訊 • 用戶利潤 貢獻度 • 信用評級 • 黑名單 • 用戶建議、 申訴、回訪、 投訴…等 傳統用戶畫像資料緊緊來自 業務資訊,事件資訊,關係 資訊…等多條資訊佚失或不足 很難形成準確、全方位的畫像 引入大數據,實現客戶360度 立體化像 業 務 系 統 資 料 用 戶 基 本 產 品 資 訊 訂 單 資 訊 客 服 資 訊 企 業 內 外 大 數 據 社 交 媒 體 社 交 網 站 流 量 日 誌 參考連結
  9. DRY的描述 “Every piece of knowledge must have a single, unambiguous,

    authoritative representation within a system” Andy Hunt – The Pragmatic Programmer
  10. 模式的六大基本元素 Name 模式名稱 給模式一個名稱,可以方便聯想 與促進溝通。 Context 問題的背景 描述問題發生的背景和 情境。 Problem

    問題 描述問題 Force 問題的限制 問題本身的限制或需要補充 的特性,以便提供解決方案的 參考。 Solution 解決方案 解決問題的方法。 Resulting Context 後續的邊際效應 套用解決方案之後產生的結果, 以及衍生的後續情況。 參考鏈結
  11. 微服務的基石 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 參考鏈結
  12. 服務通訊 - 同步 v.s. 非同步通訊 同步 完整的 請求/響應 週期 非同步

    微服務之間的內部溝通 (EventBus: 如 AMQP) 非同步 微服務之間的內部溝通 (Polling: 如 Http) 參考鏈結
  13. 微服務架構(MSA) V.S. 服務導向架構(SOA) 比較項目 MSA SOA 適用系統 快速迭代的網路應用系統 靜態的、企業級的大型應用系統 服務粒度

    服務功能單一、粒度小 服務包含的功能多,服務多樣化,粒度大 通訊機制 REST, RPC等輕量級通訊機制 SOAP等重量級通訊機制 實現方式 RESTful Web Service, ESB等 部署方式 服務部署為服務組件,在獨立的程序中,部署較為複雜 服務部署為應用系統,在統一的平台中,部署比較簡單 中心模式 去中心化 有中心組件,如: ESB 支援業務變化 高,敏捷 低 併發訪問機制 簡單,分散式 複雜,集群式 基礎設施 MSA提倡構建細粒度服務,致力於構建鬆耦合的輕量級 架構,是面向服務模組級別的實現方式。其服務發現機制、 安全性、可靠性、負載均衡、服務管理、服務監控與日 誌等諸多功能都是其中的服務組件 集中式企業服務匯流排(ESB)進行跨平台的大規模整合和持續的 改進業務流程,是企業級的應用架構,企業服務匯流排承擔了: 資 料轉換、服務查詢、智能路由、授權、安全性、可靠性、負載 均衡、服務管理、服務監控與日誌等諸多功能,結構較龐大複雜
  14. 採用微服務帶來的挑戰 商業風險 98%遇到識別根本問題與 商業風險直接的關係 除錯 73% 發現在微服務環境中, 除錯是很困難的 資料量負擔 17%

    不知道該如何治理不斷增加 的資料量 Log的成本 21% 意識到log的匯總成本 越來越高 維運 56% 每添加一個微服務 就增加了維運上的挑戰 技能 45% 不具備建構和管理微服務 的能力 參考鏈結
  15. 微服務類型 技術型 業務型 • 基礎應用功能 • 如: 快取、郵件寄送、Session管理 • 功能單一

    • 複用性高 • 業務應用功能 • 如: 會員、訂單、倉儲 • 業務聚焦 • 複用性僅在同業態,否則極低
  16. Best Practice 1. 判斷是否適合微服務 2. 定義你的微服務 3. 使用DDD來設計微服務 4. 取得組織和團隊領導的支持

    5. 使用RESTful API尤佳 6. 依微服務調整組織結構 7. 為每一個為服務配置獨立的資料儲存體 8. 基於領域設計API,以及動態API文件 9. 配合DevOps 10. 在監控上多多投資
  17. 問題域 & 解決方案域 領域包含: 問題 + 解決方案域 問題域: 待解決的商務挑戰 解決方案域:

    問題域的解決方案 限界上下文(Bounded Context)是具體解決方案的邊界 問題域依照商業性質切割為多個子領域(Subdomain)
  18. 商業架構 商務能力 資訊 價值流 組織 利害關 係人 願景和 戰略 行動和

    專案 決策和 事件 指標和 度量 產品和 服務 政策和 法規 商業架構是剖析企業的好工具
  19. 商業能力 人力資本 管理 人才管理 招募 開發 保留 評估 推薦 新

    血 商業能力 商業功能 商業活動 實現 概念性 邏輯性 實現 目 標
  20. 中台概念 前台 靈活 緩衝的橋樑 後台 穩定 中 台 連結技術和場景、打破內部隔閡 提供可復用能力、避免重複建設

    敏捷服務用戶 基礎服務能力支持 • 快速使用能力 • 快速擴展業務 • 小成本試錯、快速迭代 • 微服務架構 • DevOps基礎設施 • 公共服務設施
  21. 啟動 交易 檢查 庫存 其他 服務 新增訂單流程 啟動 交易 交易

    日誌 其他 服務 新增訂單流程 啟動 交易 檢查 團購 訂單 其他 服務 新增訂單流程 會員管理 前端 會員服務 商品管理 前端 商品服務 交易管理 前端 交易服務 支付管理 前端 支付服務 會員資料庫 商品資料庫 交易資料庫 支付資料庫 共 享 服 務
  22. 阿里巴巴的技術架構演進 IOE 分散式 平台化 中台化 業務快速上線 • 單一Java網站 • 幾十人到幾百

    人共同維護 全棧分散式 • 分散式呼叫 • 分散式DB • 服務註冊 全平台化(拓寬邊界) • 持續優化領域模型 • 簡單復用 中台化 • 統一業務能力認識 • 能力地圖
  23. 中台方法 1. 戰略升級 中台建設一定要上升到 企業高層層面,圍繞核心 戰略規劃分步實施,以小 步快跑方式在過程中不斷 檢驗與糾正。 2. 組織升級

    傳統企業業務的割裂,其 根源往往來自組織架構的 分割。業務需要涉及到 跨部門協同時,”部門牆”情況 嚴重,中台建設必須結合組織優化 兩者並行。 3. 流程升級 傳統企業通常採用”流水線”作業 的方式。結合商業套件實現流程 進化,中台更關注業務領域自身的 能力與流程共享。流程升級必不 可少。 4. 技術升級 隨著互聯網業務的不斷創新,企業 通過IT技術升級實現業務敏捷創新、 隨需而變、資料即時共享打通。 中台是由上而下的變革工程,全員共識是關鍵。
  24. 典型的業務中台建設路徑 1. 決心變革 2. 成功試點 3. 持續融合 戰略共識 賦能、消化 迭代、優化

    • 高層推行,全員共識 • 總體規劃、分步驟實施 • 找準切入點,解決具體業務問題 • 明確的業務目標和範圍 • 驗證過的技術平台 • 驗證過的中台方法論 • 靠譜的團隊 • 磨合出自己的中台理念和規範 • 優化組織、提升中台效率 • 與原廠技術、業務共同發展 • 構建自己的業務能力生態
  25. 導入中台後的工作流變化 資料 策略 執行 現在: 資料驅動 過去: 業務驅動 資料 策略

    執行 單點、各渠道割裂的營銷活動。 由資料中台統籌、多渠道策略配合 的營銷活動。
  26. 實例: 中台組織運作 需求分析 平台已有能力 發現 業務流程定制 開發 解決方案 發布 業務技術開發團隊

    業務領域抽象 規範制定 業務領域能力 推廣和接入 基於場景的能力 解決方案沉澱 中台營運團隊 基礎能力開發 基礎能力註冊 新能力沉澱 中台技術開發團隊 中 台 中 台 業 務技 術 營 運 技 術
  27. Pace-Layer架構 創新系統 差異系統 紀錄系統 • 解決方案透過大型專案的多個階段提供 • 預期系統生命週期為中長期(3~4年) • 客制化服務,商業邏輯都放在這一層

    • 預期系統生命週期較長 • 變更控制較為嚴格,資料受到嚴密監控 • 核心交易處理 • 概念驗證,功能少並且可能手動部署 • 在解決方案穩定之前,無須正式的變更管理 • 運行幾個月後,決定是進入成熟方案,或是取消 Rate of Change API Design Change Control Testing Regine 快 慢 特 定 可 重 用 寬 鬆 嚴 格 手 動 自 動
  28. 中台的真意 業務前台 (電商、銷售、客服) 業務中台 (研發、共享業務) 業務後台 (施工、生產、物流) 應用前台 應用中台 應

    用 架 構 資料架構 (資料中台) 資料架構 (資料中台) 業務前台 業務中台 業務後台 客服中心、 加油站、經銷商 組織中台 (總部: 人財物和營運) 分 公 司 1 分 公 司 2 分 公 司 N … 組 織 後 台 組 織 前 台 業 務 驅 動 技 術 驅 動 通過資訊資源整合、優化組織體系、促進業務變革 業務架構 IT架構 企業架構
  29. 業務中台的實踐 參考鏈結 問題域 解決方案域 問題域 微服務邊界 API設計 服務間通訊協定 DDD領域建模 微服務設計

    精實需求管理 微服務邊界 拆分維度 需求變化 為服務開發實踐 自動化維運 灰度發布 CI/CD 全功能團隊 CodeReview A/B測試 自動化測試 測試金字塔 Agile & DevOps 需求分層與優先級 服務治理策略 問題域 解決方案域 問題域 基礎工程能力 服務註冊與發現 API Gateway 容器化 日誌收集與分析 遺留系統分析 依賴 決定 決定
  30. 阿里巴巴業務架構 存款交易 貸款交易 理財交易 消費交易 訂 單 購 物 車

    交易中心 現金支付 餘額支付 紅包支付 積分支付 組合 支付 收銀 台 支付中心 抽獎 秒殺 優惠買單 立減 營銷中心 註冊、登入 安全、核身 會話管理 用戶資料維護 用戶中心 電子帳戶開戶 帳戶加掛 綁卡 電子帳戶動賬 帳戶中心 產品模板 產品類目 產品組態 上架、下架 產品中心 對帳 清算 文件下載 結果下載 清算中心 權益發放 權益消費 發放規則 權益核銷 積 分 優 惠 券 權益中心 協議資料 業務資料 系統參數 通用資料 資料 同步 資料 推送 基礎中心 檔案收集 資料清洗 文件儲存 搜尋 日誌分析中心 報文流水號 資料庫主鍵 訂單流水號 業務ID 日誌分析中心 參數訂閱 變更監控 參數加載 參數下載 變更 通知 接收 參數 儲存 組態中心 分散式服務 框架(EDAS) 分散式資料集 (DRDS + MySQL) 分散式佇列 (MQ) 分散式快取 (Redis) 分散式交易 (GTS) 即時監控服務 網路銀 行 手機 銀行 發現精 彩 支付 網關 直銷 銀行 商城 開放 應用 能力開放 (API, H5, SDK) 外連 網關 電商 P2P 企業 直連 第三方系統 IaaS(VMware) 展示端 支付寶 國壽 銀聯 公民 聯網和查 人行 徵信 … 第三方系統 信用卡 核心 借記卡 核心 ECIF 基金 系統 理財 系統 貸款系統 行內系統 中間 業務 保險 系統 交易 來源 業務 應用 業務 中台 基礎 服務 (PaaS) 基礎設施 (IaaS)