敏捷度量實戰(zhàn)：如何度量并改進團隊績效

目錄
第1部分 度量敏捷團隊
第1章 度量敏捷性能
1.1收集，度量，應用，重復--反饋循環(huán)
1.1.1 什么是度量?
1.2敏捷團隊為什么困于測量
1.2.1 問題：定義敏捷度量并不簡單
1.2.2 問題：敏捷專注于產(chǎn)品而不是項目
1.2.3 問題：沒有統(tǒng)一的視圖來管理數(shù)據(jù)
1.3 度量可以回答哪些問題以及數(shù)據(jù)來源
1.3.1 跟蹤項目
1.3.2 源代碼管理
1.3.3 構建系統(tǒng)
1.3.4 系統(tǒng)監(jiān)控
1.4 分析數(shù)據(jù)以及如何應用這些數(shù)據(jù)8
1.4.1 弄清楚重要問題
1.4.2 可視化數(shù)據(jù)1
1.5 應用經(jīng)驗教訓
1.6 取得所有權以及衡量團隊
1.6.1 達成共識
1.6.2 度量的反對者
1.7 小結
第2章 現(xiàn)場觀察項目
2.1 一個典型的敏捷開發(fā)項目
2.1.1 Blastamo音樂公司使用敏捷度量
2.2 產(chǎn)生的問題
2.3確定最佳的解決方案
2.4分析和呈現(xiàn)數(shù)據(jù)
2.4.1 解決問題
2.4.2 為領導可視化最終產(chǎn)品
2.5 構建系統(tǒng)和提高過程
2.5.1 使用數(shù)據(jù)改善每天所做的事情
2.6 小結
第2部分 收集和分析團隊的數(shù)據(jù)
第3章 項目跟蹤系統(tǒng)的趨勢和數(shù)據(jù)
3.1 使用PTS數(shù)據(jù)的典型敏捷度量
3.1.1 下降
3.1.2 速度
3.1.3 累積流量
3.1.4 交付時間
3.1.5 錯誤計算
3.2 能夠使用大量的數(shù)據(jù)進行分析
3.2.1 提示1：確保每個人都使用PTS
3.2.2 提示2：使用盡可能多的數(shù)據(jù)標記任務
3.2.3 提示3：估算任務完成的時間
3.2.4 提示4：任務完成時清楚地定義
3.2.5 提示5：明確定義任務的完成時間
3.3 關鍵項目管理度量；發(fā)現(xiàn)數(shù)據(jù)趨勢
3.3.1 任務工作量
3.3.2 錯誤
3.3.3 衡量任務移動，重復率和工作流
3.3.4 使用標簽排序
3.4 案例研究：確定項目的技術債務趨勢
3.5 小結
第4章 源代碼管理的趨勢和數(shù)據(jù)
4.1 什么是源代碼管理？
4.2 準備分析：生成最豐富的數(shù)據(jù)集
4.2.1 提示：使用分布式版本控制和拉請求。
4.3 使用的數(shù)據(jù)以及來自SCM的數(shù)據(jù)
4.3.1 從DVCS獲取數(shù)據(jù)
4.3.2 從集中式SCM獲取數(shù)據(jù)
4.3.3 單獨從SCM獲取數(shù)據(jù)
4.4 關鍵SCM度量：發(fā)現(xiàn)數(shù)據(jù)趨勢
4.4.1 標注SCM活動
4.5案例研究：轉向拉請求工作流并進行質量工程
4.6 小結
第5章 來自CI和部署服務器的趨勢和數(shù)據(jù)
5.1 什么是持續(xù)開發(fā)
5.1.1 持續(xù)集成
5.1.2 連續(xù)交付
5.1.3 連續(xù)測試
5.2 準備分析：生成最多的數(shù)據(jù)集
5.2.1 設置交付管道
5.3 可以從CI的API獲得要使用的數(shù)據(jù)
5.3.1 獲得CI服務器的數(shù)據(jù)
5.3.2 單獨從CI獲取什么
5.4 CI關鍵度量：找出數(shù)據(jù)的趨勢
5.4.1 獲取CI數(shù)據(jù)并將其添加到圖表中
5.5 案例研究：使用CI數(shù)據(jù)衡量過程變化的好處
5.6 小結
第6章 開發(fā)系統(tǒng)的數(shù)據(jù)
6.1 為分析做準備：能夠收集最豐富的數(shù)據(jù)集
6.1.1 在開發(fā)周期中添加任何度量
6.1.2 使用應用程序性能監(jiān)控系統(tǒng)的功能
6.1.3使用日志記錄的最佳做法
6.1.4 使用社交網(wǎng)絡與客戶聯(lián)系
6.2使用APM系統(tǒng)中的數(shù)據(jù)
6.2.1 服務器運行狀況統(tǒng)計
6.2.2 客戶使用率
6.2.3 語義日志分析
6.2.4 用于收集開發(fā)系統(tǒng)數(shù)據(jù)的工具
6.3 案例研究：團隊過渡到DevOps模式并持續(xù)交付
6.4 小結
第三部分 度量團隊，過程和軟件
第7章 使用從各個部分所收集的數(shù)據(jù)
7.1 組合數(shù)據(jù)點創(chuàng)建度量
7.2 使用數(shù)據(jù)來定義“好”
7.2.1 將主觀性轉變成客觀性
7.2.2 落后于良好的版本
7.3 創(chuàng)建度量的方式
7.3.1 步驟1：瀏覽數(shù)據(jù)
7.3.2 步驟2：分解問題以確定跟蹤對象
7.3.3 步驟3: 通過創(chuàng)建多個數(shù)據(jù)點的公式以創(chuàng)建度量
7.4 案例分析：創(chuàng)建和使用一個新度量，以測試持續(xù)交付版本的質量
7.5 小結
第8章 測量軟件的質量
8.1 準備分析：設置以測量你的代碼
8.2 使用代碼“ilities”測量軟件非功能性需求
8.3 測量可維護性
8.3.1 MTTR和交付時間
8.3.2 添加SCM數(shù)據(jù)和構建數(shù)據(jù)
8.3.3 代碼覆蓋率
8.3.4 添加靜態(tài)代碼分析
8.3.5 添加更多的PTS數(shù)據(jù)
8.4 測量可用性
8.4.1 可靠性和可用性
8.4.2 安全性
8.5 案例研究：尋找交付時間內(nèi)出現(xiàn)的異常
8.6小結
第9章 發(fā)布度量
9.1 為用戶提供合適的數(shù)據(jù)
9.1.1 團隊的工作方式
9.1.2 管理者想看到的信息
9.1.3 高管關心的事情
9.1.4 使用度量的影響
9.2 不同的發(fā)布方式
9.2.1構建儀表板
9.2.2 使用電子郵件
9.3 案例研究：從可見性轉向戰(zhàn)略目標
9.4 小結
第10章 根據(jù)敏捷原則衡量你的團隊
10.1 將敏捷原則分解成可度量的部分
10.1.1 將原則與交付周期保持一致
10.2 軟件有效性的三原則
10.2.1 衡量有效性軟件
10.3 4個有效測量過程的原則
10.3.1 測量有效過程
10.4 有效團隊所遵守的四原則
10.4.1 衡量一個有效的開發(fā)團隊
10.5 有效需求的一條原則
10.5.1 測量有效需求10
10.6 案例研究：一個新的敏捷小組
10.7 小結
附錄A使用ELK手動分析
A.1 設置系統(tǒng)
A.1.1 檢查數(shù)據(jù)庫
A.1.2 配置數(shù)據(jù)收集器
A.2 創(chuàng)建儀表板
A.3 小結7
附錄 B使用Grails收集源系統(tǒng)數(shù)據(jù)
B.1 架構預覽
B.1.1 域對象
B.1.2 你使用到的數(shù)據(jù)
B.1.3 數(shù)據(jù)收集服務
B.2 小結