敏捷度量實戰：如何度量并改進團隊績效 ( 簡體 字) |
| 作者：[美]克里斯托弗· W.H.戴維斯（Christopher W.H.Davis） | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：機械工業出版社 |  3dWoo書號： 50917
詢問書籍請說出此書號！【缺書】
NT售價： 295 元 |
| 出版日：3/26/2019 |
| 頁數：186 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787111617495 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
| 前言： |
內容簡介：本書主要講述如何收集度量數據，并分析這些數據，來衡量團隊的績效。全書分為三個部分：“測量敏捷性能”，“收集和分析團隊的數據”和“將度量應用于你的團隊，過程和軟件”。第1部分介紹度量開發過程出現的問題，以及如何將敏捷度量應用于你的團隊。第2部分介紹特定類型的數據，如何在你的團隊中使用該數據，以及你能夠從該數據獲得什么信息。第3部分介紹你能夠使用前兩部分所獲得的數據來做一些工作。本書注重理論與實踐相結合，尤其適合開發人員、測試人員、項目經理等各類管理人員使用，具有很好的應用參考價值。也可以作為敏捷度量愛好者學習和應用的參考書。還可以作為一些培訓機構的參考用書。 |
目錄：第1部分 度量敏捷團隊
第1章 度量敏捷性能
1.1收集，度量，應用，重復--反饋循環
1.1.1 什么是度量?
1.2敏捷團隊為什么困于測量
1.2.1 問題：定義敏捷度量并不簡單
1.2.2 問題：敏捷專注于產品而不是項目
1.2.3 問題：沒有統一的視圖來管理數據
1.3 度量可以回答哪些問題以及數據來源
1.3.1 跟蹤項目
1.3.2 源代碼管理
1.3.3 構建系統
1.3.4 系統監控
1.4 分析數據以及如何應用這些數據8
1.4.1 弄清楚重要問題
1.4.2 可視化數據1
1.5 應用經驗教訓
1.6 取得所有權以及衡量團隊
1.6.1 達成共識
1.6.2 度量的反對者
1.7 小結
第2章 現場觀察項目
2.1 一個典型的敏捷開發項目
2.1.1 Blastamo音樂公司使用敏捷度量
2.2 產生的問題
2.3確定最佳的解決方案
2.4分析和呈現數據
2.4.1 解決問題
2.4.2 為領導可視化最終產品
2.5 構建系統和提高過程
2.5.1 使用數據改善每天所做的事情
2.6 小結
第2部分 收集和分析團隊的數據
第3章 項目跟蹤系統的趨勢和數據
3.1 使用PTS數據的典型敏捷度量
3.1.1 下降
3.1.2 速度
3.1.3 累積流量
3.1.4 交付時間
3.1.5 錯誤計算
3.2 能夠使用大量的數據進行分析
3.2.1 提示1：確保每個人都使用PTS
3.2.2 提示2：使用盡可能多的數據標記任務
3.2.3 提示3：估算任務完成的時間
3.2.4 提示4：任務完成時清楚地定義
3.2.5 提示5：明確定義任務的完成時間
3.3 關鍵項目管理度量；發現數據趨勢
3.3.1 任務工作量
3.3.2 錯誤
3.3.3 衡量任務移動，重復率和工作流
3.3.4 使用標簽排序
3.4 案例研究：確定項目的技術債務趨勢
3.5 小結
第4章 源代碼管理的趨勢和數據
4.1 什么是源代碼管理？
4.2 準備分析：生成最豐富的數據集
4.2.1 提示：使用分布式版本控制和拉請求。
4.3 使用的數據以及來自SCM的數據
4.3.1 從DVCS獲取數據
4.3.2 從集中式SCM獲取數據
4.3.3 單獨從SCM獲取數據
4.4 關鍵SCM度量：發現數據趨勢
4.4.1 標注SCM活動
4.5案例研究：轉向拉請求工作流并進行質量工程
4.6 小結
第5章 來自CI和部署服務器的趨勢和數據
5.1 什么是持續開發
5.1.1 持續集成
5.1.2 連續交付
5.1.3 連續測試
5.2 準備分析：生成最多的數據集
5.2.1 設置交付管道
5.3 可以從CI的API獲得要使用的數據
5.3.1 獲得CI服務器的數據
5.3.2 單獨從CI獲取什么
5.4 CI關鍵度量：找出數據的趨勢
5.4.1 獲取CI數據并將其添加到圖表中
5.5 案例研究：使用CI數據衡量過程變化的好處
5.6 小結
第6章 開發系統的數據
6.1 為分析做準備：能夠收集最豐富的數據集
6.1.1 在開發周期中添加任何度量
6.1.2 使用應用程序性能監控系統的功能
6.1.3使用日志記錄的最佳做法
6.1.4 使用社交網絡與客戶聯系
6.2使用APM系統中的數據
6.2.1 服務器運行狀況統計
6.2.2 客戶使用率
6.2.3 語義日志分析
6.2.4 用于收集開發系統數據的工具
6.3 案例研究：團隊過渡到DevOps模式并持續交付
6.4 小結
第三部分 度量團隊，過程和軟件
第7章 使用從各個部分所收集的數據
7.1 組合數據點創建度量
7.2 使用數據來定義“好”
7.2.1 將主觀性轉變成客觀性
7.2.2 落后于良好的版本
7.3 創建度量的方式
7.3.1 步驟1：瀏覽數據
7.3.2 步驟2：分解問題以確定跟蹤對象
7.3.3 步驟3: 通過創建多個數據點的公式以創建度量
7.4 案例分析：創建和使用一個新度量，以測試持續交付版本的質量
7.5 小結
第8章 測量軟件的質量
8.1 準備分析：設置以測量你的代碼
8.2 使用代碼“ilities”測量軟件非功能性需求
8.3 測量可維護性
8.3.1 MTTR和交付時間
8.3.2 添加SCM數據和構建數據
8.3.3 代碼覆蓋率
8.3.4 添加靜態代碼分析
8.3.5 添加更多的PTS數據
8.4 測量可用性
8.4.1 可靠性和可用性
8.4.2 安全性
8.5 案例研究：尋找交付時間內出現的異常
8.6小結
第9章 發布度量
9.1 為用戶提供合適的數據
9.1.1 團隊的工作方式
9.1.2 管理者想看到的信息
9.1.3 高管關心的事情
9.1.4 使用度量的影響
9.2 不同的發布方式
9.2.1構建儀表板
9.2.2 使用電子郵件
9.3 案例研究：從可見性轉向戰略目標
9.4 小結
第10章 根據敏捷原則衡量你的團隊
10.1 將敏捷原則分解成可度量的部分
10.1.1 將原則與交付周期保持一致
10.2 軟件有效性的三原則
10.2.1 衡量有效性軟件
10.3 4個有效測量過程的原則
10.3.1 測量有效過程
10.4 有效團隊所遵守的四原則
10.4.1 衡量一個有效的開發團隊
10.5 有效需求的一條原則
10.5.1 測量有效需求10
10.6 案例研究：一個新的敏捷小組
10.7 小結
附錄A使用ELK手動分析
A.1 設置系統
A.1.1 檢查數據庫
A.1.2 配置數據收集器
A.2 創建儀表板
A.3 小結7
附錄 B使用Grails收集源系統數據
B.1 架構預覽
B.1.1 域對象
B.1.2 你使用到的數據
B.1.3 數據收集服務
B.2 小結
|
| 序： |
