描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787111688488丛书名: 智能系统与技术丛书
内容简介
本书通过示例向你展示如何通过敏捷过程交付良好的数据产品，以及如何组织和管理快节奏的团队，在生产环境中解决大规模的新数据问题。它将为你提供组织工作的方法，如何为数据设置可交付成果，如何在看似永无止境的任务中管理时间，如何理解数据，以及如何增加团队的透明度。书中所有的例子都来自真实的团队、真实的会议和真实的数据。
目 录
前言
关于作者
关于技术审查人
第1章 尽早交付1
1.1 入门3
1.2 用于规划的数据分析 7
1.3 创造价值9
1.4 从尽早交付到持续交付11
1.4.1 更多实体 12
1.4.2 更多属性 13
1.4.3 更多市场 15
1.4.4 更高的质量 15
1.4.5 平台即产品：更多垂直商业和客户 16
1.5 尽早且持续交付价值16
1.6 结论 20
第2章 需求变化21
2.1 为变化而构建 22
2.1.1 为变化而构建度量 22
2.1.2 为变化而构建管道 24
2.1.3 为变化而构建模型 27
2.1.4 为变化而构建架构 35
2.2 为变化而构建测试和监控 37
2.2.1 监控增量变化：数据DRI37
2.2.2 哨兵实体 38
2.2.3 日常判断指标 39
2.2.4 测试特征40
2.2.5 测试学习后的模型 41
2.2.6 带标签的训练数据 41
2.3 响应客户DSAT43
2.3.1 确定DSAT的类别44
2.3.2 定期自我评估：数据滚动和质量审查46
2.3.3 度量竞争对手48
2.4 结论50
第3章 持续交付51
3.1 验证代码更改52
3.2 持续集成系统53
3.3 持续部署系统54
3.4 验证数据更改56
3.5 持续部署数据58
3.6 决定发布什么59
3.7 结论60
第4章 与业务人员保持一致61
4.1 日常的重要性61
4.2 集中办公的优势64
4.3 业务驱动的Scrum团队65
4.4 与业务人员合作了解数据68
4.5 帮助业务人员了解机器学习的局限性69
4.6 与业务人员沟通工程的节奏：我们如何做Scrum71
4.6.1 Scrum团队72
4.6.2 组合和产品待办事项72
4.6.3 用户故事75
4.6.4 任务77
4.6.5 冲刺82
4.6.6 通过邮件与业务人员沟通Scrum状态89
4.7 结论93
第5章 激发个体94
5.1 频繁重写95
5.2 发现和培养激发个体96
5.2.1 面试与招聘98
5.2.2 激发个体的职业生涯管理103
5.3 为激发个体创造一个生产力环境106
5.3.1 内外循环106
5.3.2 寻找工具、监控和编制文档107
5.3.3 开发人员NSAT109
5.4 支持组织外部的激发个体110
5.5 结论111
第6章 有效沟通112
6.1 围绕数据的讨论必须是交互式的118
6.2 数据工具基础119
6.2.1 数据讨论工具的要求119
6.2.2 进行快速评估120
6.2.3 实例挖掘122
6.2.4 抽样策略122
6.2.5 迭代差分124
6.3 数据可视化124
6.4 召开有效的会议是一种技能126
6.5 结对和并行标记127
6.6 数据滚动128
6.7 演示会议130
6.8 结论133
第7章 监控134
7.1 监控工作软件135
7.1.1 示例系统：离开时间135
7.1.2 基于活动的监控136
7.1.3 用于分析跟踪的Azure数据资源管理器139
7.2 监控可以告诉你什么141
7.2.1 工作软件是否真的可工作141
7.2.2 什么地方出现了问题141
7.2.3 有多快142
7.2.4 业务目标是否真的达成143
7.2.5 是否真正满足了客户需求144
7.2.6 数据和模型如何使用145
7.3 结论146
第8章 可持续开发147
8.1 我们是否在正确的可持续节奏上148
8.1.1 放慢节奏149
8.1.2 加快节奏150
8.2 调整节奏的重要性151
8.3 可持续节奏与实时网站153
8.4 可持续节奏与多个开发地域155
8.5 结论155
第9章 技术卓越157
9.1 敏捷软件工程实践158
9.2 数据项目的技术卓越162
9.2.1 度量自身162
9.2.2 建立指标时开发模型165
9.2.3 为推理系统编写测试166
9.2.4 自定义标注工具168
9.2.5 存储和版本化训练与评估数据169
9.2.6 管理模型170
9.3 数据项目的良好设计171
9.3.1 数据模型中的表示和标识173
9.3.2 表示不确定175
9.3.3 代表输入176
9.4 结论177
第10章 简洁178
10.1 勤于完成任务描述179
10.1.1 不明确的工作179
10.1.2 致命的连词181
10.1.3 跨任务的依赖关系和假设181
10.2 尽早集成183
10.3 基线和启发式方法183
10.4 认识到限制184
10.5 管理HiPPO185
10.6 快速失败186
10.7 构建、购买或使用开源187
10.8 结论189
第11章 自组织团队190
11.1 团队组成191
11.2 团队由个体组成192
11.3 鼓励团队的个体特性194
11.4 跨多个自组织团队的管理196
11.5 被授权的团队可以推动团队发展和产品演进197
11.6 好事如何出现198
11.7 培养自组织团队199
11.8 工程原理与概念完整性200
11.9 结论201
第12章 调整202
12.1 回顾202
12.2 五个为什么204
12.3 调整指标205
12.4 展望未来206
12.5 结论207
第13章 总结208
关于作者
关于技术审查人
第1章 尽早交付1
1.1 入门3
1.2 用于规划的数据分析 7
1.3 创造价值9
1.4 从尽早交付到持续交付11
1.4.1 更多实体 12
1.4.2 更多属性 13
1.4.3 更多市场 15
1.4.4 更高的质量 15
1.4.5 平台即产品：更多垂直商业和客户 16
1.5 尽早且持续交付价值16
1.6 结论 20
第2章 需求变化21
2.1 为变化而构建 22
2.1.1 为变化而构建度量 22
2.1.2 为变化而构建管道 24
2.1.3 为变化而构建模型 27
2.1.4 为变化而构建架构 35
2.2 为变化而构建测试和监控 37
2.2.1 监控增量变化：数据DRI37
2.2.2 哨兵实体 38
2.2.3 日常判断指标 39
2.2.4 测试特征40
2.2.5 测试学习后的模型 41
2.2.6 带标签的训练数据 41
2.3 响应客户DSAT43
2.3.1 确定DSAT的类别44
2.3.2 定期自我评估：数据滚动和质量审查46
2.3.3 度量竞争对手48
2.4 结论50
第3章 持续交付51
3.1 验证代码更改52
3.2 持续集成系统53
3.3 持续部署系统54
3.4 验证数据更改56
3.5 持续部署数据58
3.6 决定发布什么59
3.7 结论60
第4章 与业务人员保持一致61
4.1 日常的重要性61
4.2 集中办公的优势64
4.3 业务驱动的Scrum团队65
4.4 与业务人员合作了解数据68
4.5 帮助业务人员了解机器学习的局限性69
4.6 与业务人员沟通工程的节奏：我们如何做Scrum71
4.6.1 Scrum团队72
4.6.2 组合和产品待办事项72
4.6.3 用户故事75
4.6.4 任务77
4.6.5 冲刺82
4.6.6 通过邮件与业务人员沟通Scrum状态89
4.7 结论93
第5章 激发个体94
5.1 频繁重写95
5.2 发现和培养激发个体96
5.2.1 面试与招聘98
5.2.2 激发个体的职业生涯管理103
5.3 为激发个体创造一个生产力环境106
5.3.1 内外循环106
5.3.2 寻找工具、监控和编制文档107
5.3.3 开发人员NSAT109
5.4 支持组织外部的激发个体110
5.5 结论111
第6章 有效沟通112
6.1 围绕数据的讨论必须是交互式的118
6.2 数据工具基础119
6.2.1 数据讨论工具的要求119
6.2.2 进行快速评估120
6.2.3 实例挖掘122
6.2.4 抽样策略122
6.2.5 迭代差分124
6.3 数据可视化124
6.4 召开有效的会议是一种技能126
6.5 结对和并行标记127
6.6 数据滚动128
6.7 演示会议130
6.8 结论133
第7章 监控134
7.1 监控工作软件135
7.1.1 示例系统：离开时间135
7.1.2 基于活动的监控136
7.1.3 用于分析跟踪的Azure数据资源管理器139
7.2 监控可以告诉你什么141
7.2.1 工作软件是否真的可工作141
7.2.2 什么地方出现了问题141
7.2.3 有多快142
7.2.4 业务目标是否真的达成143
7.2.5 是否真正满足了客户需求144
7.2.6 数据和模型如何使用145
7.3 结论146
第8章 可持续开发147
8.1 我们是否在正确的可持续节奏上148
8.1.1 放慢节奏149
8.1.2 加快节奏150
8.2 调整节奏的重要性151
8.3 可持续节奏与实时网站153
8.4 可持续节奏与多个开发地域155
8.5 结论155
第9章 技术卓越157
9.1 敏捷软件工程实践158
9.2 数据项目的技术卓越162
9.2.1 度量自身162
9.2.2 建立指标时开发模型165
9.2.3 为推理系统编写测试166
9.2.4 自定义标注工具168
9.2.5 存储和版本化训练与评估数据169
9.2.6 管理模型170
9.3 数据项目的良好设计171
9.3.1 数据模型中的表示和标识173
9.3.2 表示不确定175
9.3.3 代表输入176
9.4 结论177
第10章 简洁178
10.1 勤于完成任务描述179
10.1.1 不明确的工作179
10.1.2 致命的连词181
10.1.3 跨任务的依赖关系和假设181
10.2 尽早集成183
10.3 基线和启发式方法183
10.4 认识到限制184
10.5 管理HiPPO185
10.6 快速失败186
10.7 构建、购买或使用开源187
10.8 结论189
第11章 自组织团队190
11.1 团队组成191
11.2 团队由个体组成192
11.3 鼓励团队的个体特性194
11.4 跨多个自组织团队的管理196
11.5 被授权的团队可以推动团队发展和产品演进197
11.6 好事如何出现198
11.7 培养自组织团队199
11.8 工程原理与概念完整性200
11.9 结论201
第12章 调整202
12.1 回顾202
12.2 五个为什么204
12.3 调整指标205
12.4 展望未来206
12.5 结论207
第13章 总结208
前 言
本书诞生于一次偶然的相遇。2012年7月，当时Eric Carter刚刚回到美国，此前他在德国工作了三年，向欧洲市场推出了微软的一款购物搜索产品。他非常失望，因为他在欧洲努力的项目被叫停，所以他需要寻求新的发展。当在Bing（微软的搜索引擎）寻找机会时，他遇到了Matthew Hurst。Matthew是微软Live Labs的一名成员，Live Labs是一个创新小组，负责探索围绕搜索、云和连接技术的新解决方案和应用。从那时起，他就开始研究地图和本地搜索的各种形式，通常是研究将搜索主题与地址连接起来的功能。Eric和Matthew之间是相辅相成的伙伴关系，他们的合作极大地提高了Bing本地搜索的质量，并终引领两人踏上了数据工程项目如何从敏捷原则的应用中获益的探索之旅。
敏捷宣言（全称：敏捷软件开发宣言）于2001年由17个签署者共同签署，总结为四个价值观（个体和互动的价值高于流程和工具；工作的软件的价值高于详尽的文档；客户合作的价值高于合同谈判；响应变化的价值高于遵循计划）和十二原则。在本书中，我们将依次检查每一条原则，并将它们与我们在许多项目和上下文中使用数据和推理方法的经验联系起来。
当两位作者见面时，Bing的本地搜索产品在很大程度上还处于开发阶段。本地商业目录的质量正在改善，但比起当时的市场领导者谷歌仍有很大差距。Matthew当时在本地搜索数据团队，他和团队的其他成员一直在探索一些创新的想法，以更好地利用Web并集成机器学习来显著改善目录。Eric在Bing的本地搜索空间发现了许多需要直面的挑战，并决定以工程经理的身份加入Bing的本地数据团队。
在Eric职业生涯的这个阶段，他对在微软管理团队并不陌生，他曾参与过几个Visual Studio相关产品的开发以及现在已经取消的“购物搜索”项目。然而，正是在参与Visual Studio相关产品开发期间，他发现了敏捷的内在价值，以及遵循敏捷原则的团队是多么高效和欢乐。他想把这些也带到他的新团队中，却发现自己陷入了一个困境—如何将敏捷应用到一个更多是生产数据而不是生产软件的团队中？要将敏捷引入数据工程团队，需要哪些东西？
这并不简单。首先，敏捷就像一个入侵的国外代理。因为原本的团队文化是关于大概念的，通过实验、长期研究和大量试错科学项目来发掘，而所有这些似乎都与敏捷原则（如Scrum、迭代开发、可预测性、简洁和频繁交付可工作的软件）背道而驰。对于一个专注于创建包含世界上所有的商业机构的非常精确的数据库的团队来说，定义“完成”几乎是不可能的。毕竟，数据中不变的就是将包含错误—工作从字面上来讲永远不可能完成。面对诸如与利益相关者沟通、团队如何以及在哪里取得进展，确定某个特定的开发投入是否值得，以及确保以定期但可持续的节奏交付改进等挑战，现代敏捷方法显然是至关重要的。但是，在一个由数据科学家和传统工程师组成的、致力于面向数据的可交付成果的团队中，如何应用敏捷？
传统的敏捷流程旨在减少不确定性和回答诸如“客户想要什么”以及“如何可靠并持续地交付软件”之类的问题，但在这个新的项目、新的世界中，我们已经知道了客户想要什么（一个完美的本地商业目录），但我们需要回答诸如“数据中有什么”“基于这些数据我们能交付什么”之类的问题。我们需要敏捷方法，但需要的是针对现代的、复合型人才组成的数据工程团队改进后的敏捷方法。
随着探索下一代机器学习挑战的深入，我们发现，敏捷原则毫无疑问可以应用于解决问题和减少数据的不确定性，进而打造一个更快乐和高效的团队。
因此我们整合了敏捷方法论的这个现代化版本，希望本书所提供的经过验证的指南和来之不易的见解，能帮助个体、技术领导者和管理者在当今机器学习和大数据领域令人兴奋的工作中更富有成效。
敏捷宣言（全称：敏捷软件开发宣言）于2001年由17个签署者共同签署，总结为四个价值观（个体和互动的价值高于流程和工具；工作的软件的价值高于详尽的文档；客户合作的价值高于合同谈判；响应变化的价值高于遵循计划）和十二原则。在本书中，我们将依次检查每一条原则，并将它们与我们在许多项目和上下文中使用数据和推理方法的经验联系起来。
当两位作者见面时，Bing的本地搜索产品在很大程度上还处于开发阶段。本地商业目录的质量正在改善，但比起当时的市场领导者谷歌仍有很大差距。Matthew当时在本地搜索数据团队，他和团队的其他成员一直在探索一些创新的想法，以更好地利用Web并集成机器学习来显著改善目录。Eric在Bing的本地搜索空间发现了许多需要直面的挑战，并决定以工程经理的身份加入Bing的本地数据团队。
在Eric职业生涯的这个阶段，他对在微软管理团队并不陌生，他曾参与过几个Visual Studio相关产品的开发以及现在已经取消的“购物搜索”项目。然而，正是在参与Visual Studio相关产品开发期间，他发现了敏捷的内在价值，以及遵循敏捷原则的团队是多么高效和欢乐。他想把这些也带到他的新团队中，却发现自己陷入了一个困境—如何将敏捷应用到一个更多是生产数据而不是生产软件的团队中？要将敏捷引入数据工程团队，需要哪些东西？
这并不简单。首先，敏捷就像一个入侵的国外代理。因为原本的团队文化是关于大概念的，通过实验、长期研究和大量试错科学项目来发掘，而所有这些似乎都与敏捷原则（如Scrum、迭代开发、可预测性、简洁和频繁交付可工作的软件）背道而驰。对于一个专注于创建包含世界上所有的商业机构的非常精确的数据库的团队来说，定义“完成”几乎是不可能的。毕竟，数据中不变的就是将包含错误—工作从字面上来讲永远不可能完成。面对诸如与利益相关者沟通、团队如何以及在哪里取得进展，确定某个特定的开发投入是否值得，以及确保以定期但可持续的节奏交付改进等挑战，现代敏捷方法显然是至关重要的。但是，在一个由数据科学家和传统工程师组成的、致力于面向数据的可交付成果的团队中，如何应用敏捷？
传统的敏捷流程旨在减少不确定性和回答诸如“客户想要什么”以及“如何可靠并持续地交付软件”之类的问题，但在这个新的项目、新的世界中，我们已经知道了客户想要什么（一个完美的本地商业目录），但我们需要回答诸如“数据中有什么”“基于这些数据我们能交付什么”之类的问题。我们需要敏捷方法，但需要的是针对现代的、复合型人才组成的数据工程团队改进后的敏捷方法。
随着探索下一代机器学习挑战的深入，我们发现，敏捷原则毫无疑问可以应用于解决问题和减少数据的不确定性，进而打造一个更快乐和高效的团队。
因此我们整合了敏捷方法论的这个现代化版本，希望本书所提供的经过验证的指南和来之不易的见解，能帮助个体、技术领导者和管理者在当今机器学习和大数据领域令人兴奋的工作中更富有成效。
Eric Carter
Matthew Hurst
2019年6月
评论
还没有评论。