精實軟體度量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 …

Release n Release n+1 backlog

透過回饋提升價值

分析

開發

測試

回饋

分析

開發

測試

回饋

分析

開發

測試

回饋

分析

開發

測試

回饋

分析

開發

測試

回饋

分析

開發

測試

回饋

產品發佈計畫

發佈 發佈

回饋有效性取決於回饋提供者是否是真正產品的使⽤用者或是決策者，還有回饋收集者的⽔水準

 減少沒發揮價值的特性

造成浪費的⼼心態

業務 客⼾戶 團隊

現在如果不把可能的需求全講出來，以後就沒有機會了

客⼾戶想要什麼太難猜了，盡量把客⼾戶想要的功能塞進去

這個新技術很有趣，趕快來試試看

開發過程

發布後度量發布前評估

特性需求

價值結果

回應速度

• 影響回應時間的系統因素

• 評估交付週期是否有最佳化的空間

半成品(WIP)

Little’s Law: ⽣生產週期 = 半成品數量 / 產能

問題：假設某個⼯工程師⼀一天能完成⼀一件任務，以下兩種任務安排的結果有何不同？

(1) 交辦10件任務，10天後驗收 (2) 每天交辦1件任務，當天驗收，連續10天

系統資源使⽤用率

價值流圖分系需求定義

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%

累積流量圖

團隊產能

• 度量產能

• 如何提⾼高系統效率

產能的可靠性

迭代速率 開發節奏

⼀一個迭代完成的故事點數 代碼簽⼊入頻率

通過DoD品質保證驗證 建構頻率

提⾼高系統效率

• 提⾼高個體的交付能⼒力

• 最佳化系統的結構

• 減少浪費

減少軟體開發的浪費半成品 部分完成的⼯工作

額外過程 書⾯面報告、⼯工作記錄

額外特性 嘗試新技術

任務切換 同時進⾏行多項任務

等待 等待設備、⼈人員

移動 找尋協助、⽂文件轉移

缺陷 錯誤造成重⼯工

內部質量

• 內建品質 vs 技術債

• 技術債的來源

• 技術債的度量

技術債• 在開發和設計的時候選擇了權宜之計取得短期的⽅方便快捷，卻給⽇日後帶來額外的代價

來源 形式

進度壓⼒力

沒有重構

缺乏紀律 沒有⾃自動化測試

短期利益

架構設計不良

度量技術債• 程式碼⾵風格檢查

• 程式碼單元複雜度 - 圈複雜度

• 程式碼單元內聚度 - 缺乏內聚⽅方法數量

• 程式碼單元耦合度 - 類別抽象耦合、分散複雜度

• 潛在缺陷檢查

外部品質

• 度量外部品質

• 提升開發過程品質

度量產品品質

使⽤用者滿意度 產品可靠性

正⾯面反應

負⾯面反應

故障機率

故障成本

嚴重程度

缺陷密度 修復週期

提升開發品質防範缺陷 更早發現缺陷

提升技術

降低複雜度

TDD & 單元測試

減少迴歸缺陷

單元測試

配對編程 功能測試

⾯面對⾯面溝通 團隊程式碼⾛走查

ATDD / BDD

持續整合

系統測試

能⼒力

• 個⼈人能⼒力

• 學習型組織

個⼈人能⼒力

技術能⼒力 ⾃自主能⼒力

解決問題

完成任務

⾃自主啟動

獨創能⼒力

將想法實現

前瞻性

教育訓練

社交能⼒力

幫助同事

輔助團隊

堅持

學習型組織• 創造持續學習的機會

• 促進探尋與對話的機會

• ⿎鼓勵合作和團隊學習

• 使⼈人們能尋求共同願景

• 聯繫組織與其所處的環境

• 建⽴立捕獲和共享學習的系統

• 為持續學習提供戰略層⾯面的領導⼒力量

導⼊入與推廣

準備 評估 設計 部署 回饋 推廣

確定業務⺫⽬目標 度量資料消費者 ⺫⽬目前度量實踐

設定計畫範圍 找到切⼊入點 找出負責⼈人 找出介⾯面⼈人

制定基準 細分⺫⽬目標 選擇⺫⽬目標

收集度量資料 使⽤用度量資料

建議願景 觸發⺫⽬目標 度量組織 度量推廣的⼈人群 實施

先導計畫準備階段

團隊專案部⾨門組織

根據⾵風險與成本決定涉及的範圍 先導計畫負責⼈人 計畫單位介⾯面⼈人

業務⺫⽬目標指引⽅方向降低進度與品質的⾵風險

加速缺陷的回饋能⼒力 加強測試

持續整合 單元測試 TDD

設計指標系統

縮短測試週

產品建構

團隊建構

單元測試

功能測試

整合測試

⾮非功能測試

建構

個⼈人建構

靜態檢查

跨職能團隊

嚴格執⾏行DoD

頻繁驗證

更早驗證

⾃自動化測試更快是技術問題

更早是管理問題

使⽤用度量資料

收集 使⽤用

⾮非侵⼊入式

視覺化呈現資料，關注趨勢⽽而⾮非絕對數字

幫助現場⼈人員理解度量背後的原因與原理 觀察缺陷密度

因地制宜

使⽤用累積流量圖判斷瓶頸

推廣精實軟體度量

度量造成的排斥情緒

• 度量不會幫產品直接創造價值 (客⼾戶)

• 度量可能會帶來懲罰 (個⼈人)

• 團隊只看到負擔⽽而不清楚價值 (團隊)

• 度量暴露問題卻沒有⾏行動，或⾏行動沒有結果 (組織)

實施營運週期圖

評估

設計

部署

回饋

評估

設計

部署

回饋

評估

設計

部署

回饋

度量體系的實施與營運

⾥里程碑 ⾥里程碑

評估

設計

部署

回饋

評估

設計

部署

回饋

評估

設計

部署

回饋