O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
精實軟體度量
Hugo
1/7/2015
度量的⺫⽬目的
回饋
改善
蘿蔔
棒⼦子
度量是
• 組織脈絡中形成的⼀一套共識
• 經驗模型 ➟ 量化模型
• 包含⼈人、流程、⼯工具的動態系統
系統
數據收集/整理
系統輸出系統干預
⺫⽬目標與環境訊息
度量不是
• 軟體開發固有的活動
• 跟績效直接相關
• 免費的
度量體系是引導團隊達
成業務⺫⽬目標的整套策略
組織⺫⽬目標 決策情境 指標體系
業務⺫⽬目標
開發⺫⽬目標
時間
地點
⼈人物
事件
設計
運作
[業務] 如何贏過對⼿手?
• 速度 - ⽐比對⼿手更早發表產品,快速反應市場變化
• 產能 - 相同的研發規模,更有⽣生產⼒力,更短開發時間
• 價值 - 產品命中市場需求,提⾼高獲利,擴⼤大市佔率
[開發] 怎麼達成期望?
• 價值 - 依照優先順序,交付最有價值的東⻄西
• 速度 - 縮短開發週期,快速反應業務需求
• 效率 - 提⾼高開發效率,增加組織競爭優勢
• 品質 - 落實品質保證活動,滿⾜足客⼾戶要求
• 能⼒力 - 擁有⽐比...
使⽤用度量的⼈人們
管理層 專案管理 ⼯工程師
戰略定位
戰略⺫⽬目標達成
競爭環境
客⼾戶滿意度
權衡上級⺫⽬目標
產品線管理
版本控管
⼈人員管理
資訊⽣生產者
受影響的⼈人
決策的組織脈絡
• 產品缺陷帶來的影響
• 參與⼈人員⽔水準,技術、決策能⼒力⼈人員⽐比例
• 需求變化的頻率與程度
• 團隊對混亂和秩序的偏好
• 產品與專案的規模
(context)
專案的決策階段
定義 執⾏行 維護
問題
⺫⽬目標
作法
管理:何時干預
專案:提供資料
團隊:了解現況
管理:客⼾戶滿意
專案:管理回應
團隊:是否加班
度量物件模型
交付流程 交付物件 度量邊界
視覺化
看板
卡⽚片
拉動
Specific
Measurable
Achievable
Relevant
Time-bound
完成的定義
(Definition of
Done, DoD)
看板牆
分解度量物件
委推賣出
⿈黃⾦金投資
委託買⼊入及時賣出即時買⼊入
即時交易 委託交易
信託投資
豐富⽅方便的
理財服務
使⽤用者故事
特性
Epic
投資主題
專案
專案
企業
團隊
DoD 檢查列表
需求釐清
功能設計
程式撰寫
單元測試
功能測試 系統測試
效能測試
特性完成 迭代完成 發佈完成
持續改善
計畫
執⾏行
檢查
⾏行動
根據已知資料,
設定合理⺫⽬目標,預測
未來可能發⽣生的狀況,
制定可⾏行的計畫
借助度量資料,
辨別現實與預期的
差異、⾯面臨的問題、
改善的空間
價值
效率能⼒力
品質
持續
改善
回應
速速
團隊
產能
內部
質量
外部
質量
內部
質量
外部
質量
外部
質量
命中
率
滿意
度
宗旨
⺫⽬目標
度量
優先順序
有效性 可靠性 成本
指標是否真實
反映現況
資料收集與分
析結果是否客
觀、可靠
度量資料收集
與分析的成本
階段 導⼊入 成⻑⾧長/成熟 衰退
⺫⽬目標
市佔率
先佔優勢
樹⽴立⾼高階形象
拉開競爭優勢
延⻑⾧長⽣生命週期
獲取更多利潤
度量重⼼心 市場反應速度 提升品質
降低成本
提⾼高效率
價值
• 如何提⾼高交付的價值
• 如何度量交付的價值
識別與切割⾼高價值特性
A1=20
A2=10
A3=10
A4=5
B1=20
B3=5
B2=15
B4=5
A1=20
A2=10
A3=10 A4=5
B1=20
B3=5
B2=15
B4=5
C1=15 …
C2=15 …
Rele...
透過回饋提升價值
分析
開發
測試
回饋
分析
開發
測試
回饋
分析
開發
測試
回饋
分析
開發
測試
回饋
分析
開發
測試
回饋
分析
開發
測試
回饋
產品發佈計畫
發佈 發佈
回饋有效性取決於回饋提供者是否是真正產品
的使⽤用者或是...
 減少沒發揮價值的特性
造成浪費的⼼心態
業務 客⼾戶 團隊
現在如果不把
可能的需求全
講出來,以後
就沒有機會了
客⼾戶想要什麼
太難猜了,盡
量把客⼾戶想要
的功能塞進去
這個新技術很
有趣,趕快來
試試看
開發過程
發布後度量發布前評估
特性需求
價值結果
回應速度
• 影響回應時間的系統因素
• 評估交付週期是否有最佳化的空間
半成品(WIP)
Little’s Law: ⽣生產週期 = 半成品數量 / 產能
問題:假設某個⼯工程師⼀一天能完成⼀一件任務,以
下兩種任務安排的結果有何不同?
(1) 交辦10件任務,10天後驗收
(2) 每天交辦1件任務,當天驗收,連續...
系統資源使⽤用率
價值流圖分系
需求定義
1 ⼈人
L/T=10
W/T=2.29
分析設計
3 ⼈人
L/T=6
W/T=2.5
程式撰寫
3 ⼈人
L/T=13
W/T=2.5
功能測試
2 ⼈人
L/T=8
W/T=5
系統測試
1 ⼈人
L/T=13
W...
累積流量圖
團隊產能
• 度量產能
• 如何提⾼高系統效率
產能的可靠性
迭代速率 開發節奏
⼀一個迭代完成
的故事點數
代碼簽⼊入頻率
通過DoD品質
保證驗證
建構頻率
提⾼高系統效率
• 提⾼高個體的交付能⼒力
• 最佳化系統的結構
• 減少浪費
減少軟體開發的浪費
半成品 部分完成的⼯工作
額外過程 書⾯面報告、⼯工作記錄
額外特性 嘗試新技術
任務切換 同時進⾏行多項任務
等待 等待設備、⼈人員
移動 找尋協助、⽂文件轉移
缺陷 錯誤造成重⼯工
內部質量
• 內建品質 vs 技術債
• 技術債的來源
• 技術債的度量
技術債
• 在開發和設計的時候選擇了權宜之計取得短期的⽅方便
快捷,卻給⽇日後帶來額外的代價
來源 形式
進度壓⼒力
沒有重構
缺乏紀律 沒有⾃自動化測試
短期利益
架構設計不良
度量技術債
• 程式碼⾵風格檢查
• 程式碼單元複雜度 - 圈複雜度
• 程式碼單元內聚度 - 缺乏內聚⽅方法數量
• 程式碼單元耦合度 - 類別抽象耦合、分散複雜度
• 潛在缺陷檢查
外部品質
• 度量外部品質
• 提升開發過程品質
度量產品品質
使⽤用者滿意度 產品可靠性
正⾯面反應
負⾯面反應
故障機率
故障成本
嚴重程度
缺陷密度 修復週期
提升開發品質
防範缺陷 更早發現缺陷
提升技術
降低複雜度
TDD & 單元測試
減少迴歸缺陷
單元測試
配對編程 功能測試
⾯面對⾯面溝通 團隊程式碼⾛走查
ATDD / BDD
持續整合
系統測試
能⼒力
• 個⼈人能⼒力
• 學習型組織
個⼈人能⼒力
技術能⼒力 ⾃自主能⼒力
解決問題
完成任務
⾃自主啟動
獨創能⼒力
將想法實現
前瞻性
教育訓練
社交能⼒力
幫助同事
輔助團隊
堅持
學習型組織
• 創造持續學習的機會
• 促進探尋與對話的機會
• ⿎鼓勵合作和團隊學習
• 使⼈人們能尋求共同願景
• 聯繫組織與其所處的環境
• 建⽴立捕獲和共享學習的系統
• 為持續學習提供戰略層⾯面的領導⼒力量
導⼊入與推廣
準備 評估 設計 部署 回饋 推廣
確定業務⺫⽬目標
度量資料消費者
⺫⽬目前度量實踐
設定計畫範圍
找到切⼊入點
找出負責⼈人
找出介⾯面⼈人
制定基準
細分⺫⽬目標
選擇⺫⽬目標
收集度量資料
使⽤用度量資料
建議願景
觸發⺫...
先導計畫準備階段
團隊
專案
部⾨門
組織
根據⾵風險與成本

決定涉及的範圍
先導計畫負責⼈人
計畫單位介⾯面⼈人
業務⺫⽬目標指引⽅方向
降低進度與
品質的⾵風險
加速缺陷的
回饋能⼒力
加強測試
持續整合
單元測試
TDD
設計指標系統
縮短測試週
產品建構
團隊建構
單元測試
功能測試
整合測試
⾮非功能測試
建構
個⼈人建構
靜態檢查
跨職能團隊
嚴格執⾏行DoD
頻繁驗證
更早驗證
⾃自動化測試
更快是技術問題
更早是管理問題
使⽤用度量資料
收集 使⽤用
⾮非侵⼊入式
視覺化呈現資料,關
注趨勢⽽而⾮非絕對數字
幫助現場⼈人員理解度
量背後的原因與原理 觀察缺陷密度
因地制宜
使⽤用累積流量圖判斷
瓶頸
推廣精實軟體度量
度量造成的排斥情緒
• 度量不會幫產品直接創造價值 (客⼾戶)
• 度量可能會帶來懲罰 (個⼈人)
• 團隊只看到負擔⽽而不清楚價值 (團隊)
• 度量暴露問題卻沒有⾏行動,或⾏行動沒有結果 (組織)
實施營運週期圖
評估
設計
部署
回饋
評估
設計
部署
回饋
評估
設計
部署
回饋
度量體系的實施與營運
⾥里程碑 ⾥里程碑
評估
設計
部署
回饋
評估
設計
部署
回饋
評估
設計
部署
回饋
Próximos SlideShares
Carregando em…5
×

精實軟體度量

963 visualizações

Publicada em

《精實軟體度量》讀書心得報告

Publicada em: Engenharia
  • Seja o primeiro a comentar

精實軟體度量

  1. 1. 精實軟體度量 Hugo 1/7/2015
  2. 2. 度量的⺫⽬目的 回饋 改善 蘿蔔 棒⼦子
  3. 3. 度量是 • 組織脈絡中形成的⼀一套共識 • 經驗模型 ➟ 量化模型 • 包含⼈人、流程、⼯工具的動態系統 系統 數據收集/整理 系統輸出系統干預 ⺫⽬目標與環境訊息
  4. 4. 度量不是 • 軟體開發固有的活動 • 跟績效直接相關 • 免費的
  5. 5. 度量體系是引導團隊達 成業務⺫⽬目標的整套策略
  6. 6. 組織⺫⽬目標 決策情境 指標體系 業務⺫⽬目標 開發⺫⽬目標 時間 地點 ⼈人物 事件 設計 運作
  7. 7. [業務] 如何贏過對⼿手? • 速度 - ⽐比對⼿手更早發表產品,快速反應市場變化 • 產能 - 相同的研發規模,更有⽣生產⼒力,更短開發時間 • 價值 - 產品命中市場需求,提⾼高獲利,擴⼤大市佔率
  8. 8. [開發] 怎麼達成期望? • 價值 - 依照優先順序,交付最有價值的東⻄西 • 速度 - 縮短開發週期,快速反應業務需求 • 效率 - 提⾼高開發效率,增加組織競爭優勢 • 品質 - 落實品質保證活動,滿⾜足客⼾戶要求 • 能⼒力 - 擁有⽐比競爭對⼿手更快的學習能⼒力
  9. 9. 使⽤用度量的⼈人們 管理層 專案管理 ⼯工程師 戰略定位 戰略⺫⽬目標達成 競爭環境 客⼾戶滿意度 權衡上級⺫⽬目標 產品線管理 版本控管 ⼈人員管理 資訊⽣生產者 受影響的⼈人
  10. 10. 決策的組織脈絡 • 產品缺陷帶來的影響 • 參與⼈人員⽔水準,技術、決策能⼒力⼈人員⽐比例 • 需求變化的頻率與程度 • 團隊對混亂和秩序的偏好 • 產品與專案的規模 (context)
  11. 11. 專案的決策階段 定義 執⾏行 維護 問題 ⺫⽬目標 作法 管理:何時干預 專案:提供資料 團隊:了解現況 管理:客⼾戶滿意 專案:管理回應 團隊:是否加班
  12. 12. 度量物件模型 交付流程 交付物件 度量邊界 視覺化 看板 卡⽚片 拉動 Specific Measurable Achievable Relevant Time-bound 完成的定義 (Definition of Done, DoD)
  13. 13. 看板牆
  14. 14. 分解度量物件 委推賣出 ⿈黃⾦金投資 委託買⼊入及時賣出即時買⼊入 即時交易 委託交易 信託投資 豐富⽅方便的 理財服務 使⽤用者故事 特性 Epic 投資主題 專案 專案 企業 團隊
  15. 15. DoD 檢查列表 需求釐清 功能設計 程式撰寫 單元測試 功能測試 系統測試 效能測試 特性完成 迭代完成 發佈完成
  16. 16. 持續改善 計畫 執⾏行 檢查 ⾏行動 根據已知資料, 設定合理⺫⽬目標,預測 未來可能發⽣生的狀況, 制定可⾏行的計畫 借助度量資料, 辨別現實與預期的 差異、⾯面臨的問題、 改善的空間
  17. 17. 價值 效率能⼒力 品質 持續 改善 回應 速速 團隊 產能 內部 質量 外部 質量 內部 質量 外部 質量 外部 質量 命中 率 滿意 度 宗旨 ⺫⽬目標 度量
  18. 18. 優先順序 有效性 可靠性 成本 指標是否真實 反映現況 資料收集與分 析結果是否客 觀、可靠 度量資料收集 與分析的成本
  19. 19. 階段 導⼊入 成⻑⾧長/成熟 衰退 ⺫⽬目標 市佔率 先佔優勢 樹⽴立⾼高階形象 拉開競爭優勢 延⻑⾧長⽣生命週期 獲取更多利潤 度量重⼼心 市場反應速度 提升品質 降低成本 提⾼高效率
  20. 20. 價值 • 如何提⾼高交付的價值 • 如何度量交付的價值
  21. 21. 識別與切割⾼高價值特性 A1=20 A2=10 A3=10 A4=5 B1=20 B3=5 B2=15 B4=5 A1=20 A2=10 A3=10 A4=5 B1=20 B3=5 B2=15 B4=5 C1=15 … C2=15 … Release n Release n+1 backlog
  22. 22. 透過回饋提升價值 分析 開發 測試 回饋 分析 開發 測試 回饋 分析 開發 測試 回饋 分析 開發 測試 回饋 分析 開發 測試 回饋 分析 開發 測試 回饋 產品發佈計畫 發佈 發佈 回饋有效性取決於回饋提供者是否是真正產品 的使⽤用者或是決策者,還有回饋收集者的⽔水準
  23. 23.  減少沒發揮價值的特性
  24. 24. 造成浪費的⼼心態 業務 客⼾戶 團隊 現在如果不把 可能的需求全 講出來,以後 就沒有機會了 客⼾戶想要什麼 太難猜了,盡 量把客⼾戶想要 的功能塞進去 這個新技術很 有趣,趕快來 試試看
  25. 25. 開發過程 發布後度量發布前評估 特性需求 價值結果
  26. 26. 回應速度 • 影響回應時間的系統因素 • 評估交付週期是否有最佳化的空間
  27. 27. 半成品(WIP) Little’s Law: ⽣生產週期 = 半成品數量 / 產能 問題:假設某個⼯工程師⼀一天能完成⼀一件任務,以 下兩種任務安排的結果有何不同? (1) 交辦10件任務,10天後驗收 (2) 每天交辦1件任務,當天驗收,連續10天
  28. 28. 系統資源使⽤用率
  29. 29. 價值流圖分系 需求定義 1 ⼈人 L/T=10 W/T=2.29 分析設計 3 ⼈人 L/T=6 W/T=2.5 程式撰寫 3 ⼈人 L/T=13 W/T=2.5 功能測試 2 ⼈人 L/T=8 W/T=5 系統測試 1 ⼈人 L/T=13 W/T=5 版本發佈 1 ⼈人 L/T=0 W/T=0 開發階段 ⼯工作⼈人數 處理週期 實際時間 10天 6天 13天 8天 13天 0天 1天 1天 1天 2天 30天 創造價值 等待時間 等待⽐比例 77.10% 58.33% 80.77% 37.50% 61.54% 0%
  30. 30. 累積流量圖
  31. 31. 團隊產能 • 度量產能 • 如何提⾼高系統效率
  32. 32. 產能的可靠性 迭代速率 開發節奏 ⼀一個迭代完成 的故事點數 代碼簽⼊入頻率 通過DoD品質 保證驗證 建構頻率
  33. 33. 提⾼高系統效率 • 提⾼高個體的交付能⼒力 • 最佳化系統的結構 • 減少浪費
  34. 34. 減少軟體開發的浪費 半成品 部分完成的⼯工作 額外過程 書⾯面報告、⼯工作記錄 額外特性 嘗試新技術 任務切換 同時進⾏行多項任務 等待 等待設備、⼈人員 移動 找尋協助、⽂文件轉移 缺陷 錯誤造成重⼯工
  35. 35. 內部質量 • 內建品質 vs 技術債 • 技術債的來源 • 技術債的度量
  36. 36. 技術債 • 在開發和設計的時候選擇了權宜之計取得短期的⽅方便 快捷,卻給⽇日後帶來額外的代價 來源 形式 進度壓⼒力 沒有重構 缺乏紀律 沒有⾃自動化測試 短期利益 架構設計不良
  37. 37. 度量技術債 • 程式碼⾵風格檢查 • 程式碼單元複雜度 - 圈複雜度 • 程式碼單元內聚度 - 缺乏內聚⽅方法數量 • 程式碼單元耦合度 - 類別抽象耦合、分散複雜度 • 潛在缺陷檢查
  38. 38. 外部品質 • 度量外部品質 • 提升開發過程品質
  39. 39. 度量產品品質 使⽤用者滿意度 產品可靠性 正⾯面反應 負⾯面反應 故障機率 故障成本 嚴重程度 缺陷密度 修復週期
  40. 40. 提升開發品質 防範缺陷 更早發現缺陷 提升技術 降低複雜度 TDD & 單元測試 減少迴歸缺陷 單元測試 配對編程 功能測試 ⾯面對⾯面溝通 團隊程式碼⾛走查 ATDD / BDD 持續整合 系統測試
  41. 41. 能⼒力 • 個⼈人能⼒力 • 學習型組織
  42. 42. 個⼈人能⼒力 技術能⼒力 ⾃自主能⼒力 解決問題 完成任務 ⾃自主啟動 獨創能⼒力 將想法實現 前瞻性 教育訓練 社交能⼒力 幫助同事 輔助團隊 堅持
  43. 43. 學習型組織 • 創造持續學習的機會 • 促進探尋與對話的機會 • ⿎鼓勵合作和團隊學習 • 使⼈人們能尋求共同願景 • 聯繫組織與其所處的環境 • 建⽴立捕獲和共享學習的系統 • 為持續學習提供戰略層⾯面的領導⼒力量
  44. 44. 導⼊入與推廣 準備 評估 設計 部署 回饋 推廣 確定業務⺫⽬目標 度量資料消費者 ⺫⽬目前度量實踐 設定計畫範圍 找到切⼊入點 找出負責⼈人 找出介⾯面⼈人 制定基準 細分⺫⽬目標 選擇⺫⽬目標 收集度量資料 使⽤用度量資料 建議願景 觸發⺫⽬目標 度量組織 度量推廣的⼈人群 實施
  45. 45. 先導計畫準備階段 團隊 專案 部⾨門 組織 根據⾵風險與成本
 決定涉及的範圍 先導計畫負責⼈人 計畫單位介⾯面⼈人
  46. 46. 業務⺫⽬目標指引⽅方向 降低進度與 品質的⾵風險 加速缺陷的 回饋能⼒力 加強測試 持續整合 單元測試 TDD
  47. 47. 設計指標系統 縮短測試週 產品建構 團隊建構 單元測試 功能測試 整合測試 ⾮非功能測試 建構 個⼈人建構 靜態檢查 跨職能團隊 嚴格執⾏行DoD 頻繁驗證 更早驗證 ⾃自動化測試 更快是技術問題 更早是管理問題
  48. 48. 使⽤用度量資料 收集 使⽤用 ⾮非侵⼊入式 視覺化呈現資料,關 注趨勢⽽而⾮非絕對數字 幫助現場⼈人員理解度 量背後的原因與原理 觀察缺陷密度 因地制宜 使⽤用累積流量圖判斷 瓶頸
  49. 49. 推廣精實軟體度量
  50. 50. 度量造成的排斥情緒 • 度量不會幫產品直接創造價值 (客⼾戶) • 度量可能會帶來懲罰 (個⼈人) • 團隊只看到負擔⽽而不清楚價值 (團隊) • 度量暴露問題卻沒有⾏行動,或⾏行動沒有結果 (組織)
  51. 51. 實施營運週期圖 評估 設計 部署 回饋 評估 設計 部署 回饋 評估 設計 部署 回饋 度量體系的實施與營運 ⾥里程碑 ⾥里程碑 評估 設計 部署 回饋 評估 設計 部署 回饋 評估 設計 部署 回饋

×