敏捷度量实战：如何度量并改进团队绩效 PDF下载

编辑推荐

从实战角度如何客观地衡量团队绩效含案例分析，由浅入深穿插8个典型案例，内容实用适合学习

无标题文档

；

内容简介

本书主要讲述如何收集度量数据，并分析这些数据，来衡量团队的绩效。全书分为三个部分：“测量敏捷性能”，“收集和分析团队的数据”和“将度量应用于你的团队，过程和软件”。第1部分介绍度量开发过程出现的问题，以及如何将敏捷度量应用于你的团队。第2部分介绍特定类型的数据，如何在你的团队中使用该数据，以及你能够从该数据获得什么信息。第3部分介绍你能够使用前两部分所获得的数据来做一些工作。本书注重理论与实践相结合，尤其适合开发人员、测试人员、项目经理等各类管理人员使用，具有很好的应用参考价值。也可以作为敏捷度量爱好者学习和应用的参考书。还可以作为一些培训机构的参考用书。

作者简介

自20世纪后期开始，作者一直担任开发团队的领导。他主要从事旅游、金融、医疗、电信和制造业等领域的软件开发工作，在世界各地领导了不同的团队。他是一个狂热的运动员，他喜欢美丽的美国俄勒冈州的波特兰市，那里有他的妻子和两个孩子。

敏捷度量实战：如何度量并改进团队绩效 PDF下载

目录第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 分析数据以及如何应用这些数据81.4.1 弄清楚重要问题1.4.2 可视化数据11.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：确保每个人都使用PTS3.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 测量有效需求1010.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 小结

前沿

团队应该定期反思如何提高效率，然后相应地调整其行为。 —agilemanifesto.org/principles.html开发团队应依据团队成员、时间承诺、正在开发的项目和所使用的软件，采取不同的方式进行敏捷度量。遵循“敏捷宣言”，团队应定期检查和调整其行为，并反思他们的工作绩效以及如何提高效率。本书讲述了如何收集能够衡量敏捷团队的数据，并分析这些数据，以发现问题并解决问题，使团队充分发挥其潜力。作者在多年的敏捷团队管理工作中，经常会发现团队成员喜欢根据直觉或者最新的博客帖子来检查和调整他们的工作。许多时候，他们不使用真实的数据来确定从哪个方面评估团队或过程。读者不需要走很远的路就可以查找今天进行开发、跟踪和监控所使用的数据，读者可以应用非常复杂的性能监控系统，跟踪有管理任务的系统，从而能够构建灵活、简单、功能强大的系统。团队每天多次自动发布新代码，读者可以使用这些数据来衡量团队，并调整开发过程。多年来，作者一直沿用这本书中的技术，这对于改变团队的工作思路影响很大。围绕数据展开对话，而不是脱离猜测或意见来揭示真正的问题，最终会富有成效。读者能够在团队中创建度量，并在例会、阶段总结或整个开发过程中使用这些度量，这有助于团队查找问题根源，排除干扰因素，使工作过程运转良好。管理人员和团队领导获得这些度量数据时通常会比较快乐，因为他们可以深入了解团队的真实表现。他们也可以看到采取的措施如何影响团队的工作，以及对最终目标的影响。当作者还是一名开发人员的时候，就开始使用这些技术，希望向领导层报告团队真实的表现。当作者转变为管理者的时候，开始从另一个角度来看待这些技术，鼓励团队做同样的事情，收集他们认为是重要的、能够反映他们日常工作的数据。当作者转变为高级管理者时，已经可以从更高的层次来看这些技术，如战略、举措和投资如何影响团队的协作，如何将一个团队的运行效率提高到另一个团队的水平之上，以及如何在更大程度上取得成功。无论读者在敏捷开发团队中担任什么角色，作者相信读者将能在组织中成功地应用这些技术。