Downloaded 27 times
![[業務] 如何贏過對⼿手？
• 速度 - ⽐比對⼿手更早發表產品，快速反應市場變化
• 產能 - 相同的研發規模，更有⽣生產⼒力，更短開發時間
• 價值 - 產品命中市場需求，提⾼高獲利，擴⼤大市佔率](https://image.slidesharecdn.com/random-150107055147-conversion-gate01/75/slide-7-2048.jpg)
![[開發] 怎麼達成期望？
• 價值 - 依照優先順序，交付最有價值的東⻄西
• 速度 - 縮短開發週期，快速反應業務需求
• 效率 - 提⾼高開發效率，增加組織競爭優勢
• 品質 - 落實品質保證活動，滿⾜足客⼾戶要求
• 能⼒力 - 擁有⽐比競爭對⼿手更快的學習能⼒力](https://image.slidesharecdn.com/random-150107055147-conversion-gate01/75/slide-8-2048.jpg)
Uploaded byhugo lu
精實軟體度量
本文旨在探讨精实软件度量的重要性，包括为何度量应作为组织策略的一部分，以及如何通过度量实现业务与开发目标的对齐。文中强调度量不是软件开发固有的活动，而是一个动态系统的反馈过程，以提高效率、速度和产品质量。还提及了在实施度量时需克服的潜在抵制情绪，并提供了针对度量组织和推广的步骤和策略。
精實軟體度量
- 1.
- 2.
- 3. 度量是 • 組織脈絡中形成的⼀一套共識 • 經驗模型➟ 量化模型 • 包含⼈人、流程、⼯工具的動態系統 系統 數據收集/整理 系統輸出系統干預 ⺫⽬目標與環境訊息
- 4.
- 5.
- 6.
- 7. [業務] 如何贏過對⼿手？ • 速度- ⽐比對⼿手更早發表產品，快速反應市場變化 • 產能 - 相同的研發規模，更有⽣生產⼒力，更短開發時間 • 價值 - 產品命中市場需求，提⾼高獲利，擴⼤大市佔率
- 8. [開發] 怎麼達成期望？ • 價值- 依照優先順序，交付最有價值的東⻄西 • 速度 - 縮短開發週期，快速反應業務需求 • 效率 - 提⾼高開發效率，增加組織競爭優勢 • 品質 - 落實品質保證活動，滿⾜足客⼾戶要求 • 能⼒力 - 擁有⽐比競爭對⼿手更快的學習能⼒力
- 9.
- 10. 決策的組織脈絡 • 產品缺陷帶來的影響 • 參與⼈人員⽔水準，技術、決策能⼒力⼈人員⽐比例 •需求變化的頻率與程度 • 團隊對混亂和秩序的偏好 • 產品與專案的規模 (context)
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. 階段 導⼊入 成⻑⾧長/成熟衰退 ⺫⽬目標 市佔率 先佔優勢 樹⽴立⾼高階形象 拉開競爭優勢 延⻑⾧長⽣生命週期 獲取更多利潤 度量重⼼心 市場反應速度 提升品質 降低成本 提⾼高效率
- 20.
- 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.
- 23.
- 24.
- 25.
- 26.
- 27. 半成品(WIP) Little’s Law: ⽣生產週期= 半成品數量 / 產能 問題：假設某個⼯工程師⼀一天能完成⼀一件任務，以 下兩種任務安排的結果有何不同？ (1) 交辦10件任務，10天後驗收 (2) 每天交辦1件任務，當天驗收，連續10天
- 28.
- 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.
- 31.
- 32.
- 33.
- 34. 減少軟體開發的浪費 半成品 部分完成的⼯工作 額外過程 書⾯面報告、⼯工作記錄 額外特性嘗試新技術 任務切換 同時進⾏行多項任務 等待 等待設備、⼈人員 移動 找尋協助、⽂文件轉移 缺陷 錯誤造成重⼯工
- 35. 內部質量 • 內建品質 vs技術債 • 技術債的來源 • 技術債的度量
- 36. 技術債 • 在開發和設計的時候選擇了權宜之計取得短期的⽅方便 快捷，卻給⽇日後帶來額外的代價 來源 形式 進度壓⼒力 沒有重構 缺乏紀律沒有⾃自動化測試 短期利益 架構設計不良
- 37. 度量技術債 • 程式碼⾵風格檢查 • 程式碼單元複雜度- 圈複雜度 • 程式碼單元內聚度 - 缺乏內聚⽅方法數量 • 程式碼單元耦合度 - 類別抽象耦合、分散複雜度 • 潛在缺陷檢查
- 38.
- 39.
- 40. 提升開發品質 防範缺陷 更早發現缺陷 提升技術 降低複雜度 TDD &單元測試 減少迴歸缺陷 單元測試 配對編程 功能測試 ⾯面對⾯面溝通 團隊程式碼⾛走查 ATDD / BDD 持續整合 系統測試
- 41.
- 42.
- 43. 學習型組織 • 創造持續學習的機會 • 促進探尋與對話的機會 •⿎鼓勵合作和團隊學習 • 使⼈人們能尋求共同願景 • 聯繫組織與其所處的環境 • 建⽴立捕獲和共享學習的系統 • 為持續學習提供戰略層⾯面的領導⼒力量
- 44. 導⼊入與推廣 準備 評估 設計部署 回饋 推廣 確定業務⺫⽬目標 度量資料消費者 ⺫⽬目前度量實踐 設定計畫範圍 找到切⼊入點 找出負責⼈人 找出介⾯面⼈人 制定基準 細分⺫⽬目標 選擇⺫⽬目標 收集度量資料 使⽤用度量資料 建議願景 觸發⺫⽬目標 度量組織 度量推廣的⼈人群 實施
- 45.
- 46.
- 47.
- 48.
- 49.
- 50. 度量造成的排斥情緒 • 度量不會幫產品直接創造價值 (客⼾戶) •度量可能會帶來懲罰 (個⼈人) • 團隊只看到負擔⽽而不清楚價值 (團隊) • 度量暴露問題卻沒有⾏行動，或⾏行動沒有結果 (組織)
- 51.