基本信息
- 原书名：Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing
【插图】
编辑推荐
Jolt大奖获得者Pramod Sadalage和IBM Rational创始人ScottAmbler倾情推荐，高价值DW／BI系统开发的绝佳实践指南
从架构到管理，从自动化测试到持续集成，借助丰富的实际工作案例，全方位深入讲解敏捷DW／BI的关键技术和项目管理实践，有效缓解DW／BI项目风险，创新高价值的DW／BI解决方案
内容简介
书籍
计算机书籍
使用敏捷方式，可以为任何数据仓库(DW)、商业智能(BI)或分析项目带来更多的创新、价值和更高的质量。然而，必须仔细地调整传统的敏捷方式，以适应DW／BI项目的独特之处。在本书中，敏捷先驱Ken Collier会告诉我们如何去做。
全书分为两部分，共10章，从架构到管理，从自动化测试到持续集成，通过丰富的工作实例，系统而深入地讲解敏捷DW／BI的基本原理、关键技术和项目管理实践，为在真实商业智能和数据仓库项目上应用敏捷分析方法提供系统实用指南。从管理角度，详细介绍敏捷分析的基本原则，敏捷项目管理的有效实践，包括章程、规划、执行和检测敏捷分析项目的有效实践，以及成立高度协作项目团队的指导原则和实践，展现如何使用案例和用户故事驱使价值持续传递，并讲解团队管理和领导的敏捷风格如何有效地替代传统命令控制风格；从技术角度，深入讲解能够持续传递商业价值并有质量保障的技术方法，包括最优设计推进、测试驱动的数据仓库开发、版本控制和项目自动化，以及应用敏捷分析时的一些注意事项。
《敏捷分析：价值驱动的商业智能和数据仓库系统开发》内容全面，讲解深入，并且涵盖许多经过实践检验的解决方案，适合IT决策者、数据仓库专业人士、数据库管理员、商业智能专家和数据库开发人员参考。
计算机书籍
使用敏捷方式，可以为任何数据仓库(DW)、商业智能(BI)或分析项目带来更多的创新、价值和更高的质量。然而，必须仔细地调整传统的敏捷方式，以适应DW／BI项目的独特之处。在本书中，敏捷先驱Ken Collier会告诉我们如何去做。
全书分为两部分，共10章，从架构到管理，从自动化测试到持续集成，通过丰富的工作实例，系统而深入地讲解敏捷DW／BI的基本原理、关键技术和项目管理实践，为在真实商业智能和数据仓库项目上应用敏捷分析方法提供系统实用指南。从管理角度，详细介绍敏捷分析的基本原则，敏捷项目管理的有效实践，包括章程、规划、执行和检测敏捷分析项目的有效实践，以及成立高度协作项目团队的指导原则和实践，展现如何使用案例和用户故事驱使价值持续传递，并讲解团队管理和领导的敏捷风格如何有效地替代传统命令控制风格；从技术角度，深入讲解能够持续传递商业价值并有质量保障的技术方法，包括最优设计推进、测试驱动的数据仓库开发、版本控制和项目自动化，以及应用敏捷分析时的一些注意事项。
《敏捷分析：价值驱动的商业智能和数据仓库系统开发》内容全面，讲解深入，并且涵盖许多经过实践检验的解决方案，适合IT决策者、数据仓库专业人士、数据库管理员、商业智能专家和数据库开发人员参考。
作译者
Ken Collier KWC技术公司创始人兼总裁，Cutter联盟敏捷开发和商业智能高级咨询顾问，专注于增强组织敏捷性，包括敏捷软件工程、敏捷分析以及客户公司的敏捷管理和领导。Ken自2003年起就致力于研究敏捷方法，并且倡导把敏捷方法应用于数据仓库、商业智能及分析，开创敏捷分析风格。作为很多敏捷DW／BI项目团队中的技术领导和项目经理，他不断地完善这些观点，同时也经常对DW／BI团队进行敏捷分析培训。他一直是很多美国和国际大会上敏捷DW／BI主题的主讲嘉宾，这些会议包括多个TDWI(The Data Warehousing Institute)国际会议，以及HEDW(Higher Education Data Warehouse)年度会议。
目录
《敏捷分析：价值驱动的商业智能和数据仓库系统开发》
译者序
序 一
序 二
前 言
第一部分 敏捷分析：管理方法
第1章 敏捷分析概述2
1.1 阿尔卑斯风格的系统开发2
1.2 什么是敏捷分析5
1.2.1 敏捷分析的含义5
1.2.2 指导原则7
1.2.3 传言与误解7
1.3 数据仓库架构和技能9
1.3.1 数据仓库概念架构9
1.3.2 多样化、截然不同的技能10
1.4 为什么我们需要敏捷分析11
1.4.1 第一个事实：建立DW/BI系统是困难的11
1.4.2 第二个事实：DW/BI开发项目经常失败12
1.4.3 第三个事实：最好是快速失败和适应13
1.4.4 敏捷真的很好吗13
译者序
序 一
序 二
前 言
第一部分 敏捷分析：管理方法
第1章 敏捷分析概述2
1.1 阿尔卑斯风格的系统开发2
1.2 什么是敏捷分析5
1.2.1 敏捷分析的含义5
1.2.2 指导原则7
1.2.3 传言与误解7
1.3 数据仓库架构和技能9
1.3.1 数据仓库概念架构9
1.3.2 多样化、截然不同的技能10
1.4 为什么我们需要敏捷分析11
1.4.1 第一个事实：建立DW/BI系统是困难的11
1.4.2 第二个事实：DW/BI开发项目经常失败12
1.4.3 第三个事实：最好是快速失败和适应13
1.4.4 敏捷真的很好吗13
译者序
近些年，互联网经济掀起风暴，大大小小的互联网公司一家家出现并迅猛发展。曾经的“只读式”互联网提供给我们很多的内容和很少的功能，我们只在互联网上阅读信息。那个时代已经远去，而今的Web 2.0互联网早已是“可读可写”，我们可以为互联网添加内容，甚至利用互联网来执行任务，实现自己的目标。我们可以在互联网上购买商品、计算房贷利息、预订酒店和机票、搜索问题的答案、分析处理海量数据、下载报表、听音乐、看电影……互联网已完全成为我们生活和工作中不可缺少的工具。随着互联网职能和业务的急速扩充，互联网公司内部的工作方式也发生了巨大变化。传统行业的人员不断地在向互联网转战，互联网从业者的数量达到空前规模。
混迹互联网行业这些年，在实际工作及和同行交流中发现因工作方式导致的不顺比比皆是。拜读Ken Collier的书更是深有感触，书中提及的各种负面做法在各互联网公司普遍存在。项目在需求还未明确时就定了上线时间，或是要求一个需90天完成的项目在30天内完成，只要你在互联网公司外驻足守候，你会发现很多技术人员都在凌晨离开公司。执行团队被要求在项目之初就评估细致的工时，而项目过程中又常发生需求变更，由此导致频繁的返工和加班。执行团队中不同职能的人员互相催赶工作进度，于是需要解释所需的工时。因为互联网常因业绩而追求上线速度，也因为业务量不断攀升，用户通常只涉足前期调研和可用性测试，全程参与项目的情况并不多见。不少管理层在项目全程只简单过问，甚至在项目产出时才第一次提出反馈意见……以上这般种种现象，相信互联网公司的技术同僚们都不陌生吧。
本书中的敏捷项目分析虽然只提到商业智能项目和数据仓库项目，但是其方法广泛适用于互联网中的其他项目，我们推荐所有的互联网从业者（尤其是管理层和执行团队）深入研究并借鉴书中的工作方法。用户故事、用例等这些概念对用户体验从业者来说都不陌生，也希望这些理念能在开发、测试等技术人员当中推广并被接受，这将会让项目大大受益。
感谢机械工业出版社给予我们宝贵的机会来翻译本书，这对我们来说也是一次学习的过程。本书对知识点的讲解十分透彻，引用的实际例子也让我们开拓了思维，看到了国外公司的团队是如何有效运作的。翻译完这本书，我们受益匪浅，希望书中的方法能够惠及各位同行。
最后，虽然我们在翻译过程中慎之又慎并且多次审查，但是书中仍难免存在疏漏和不当之处，恳请读者予以指正。
混迹互联网行业这些年，在实际工作及和同行交流中发现因工作方式导致的不顺比比皆是。拜读Ken Collier的书更是深有感触，书中提及的各种负面做法在各互联网公司普遍存在。项目在需求还未明确时就定了上线时间，或是要求一个需90天完成的项目在30天内完成，只要你在互联网公司外驻足守候，你会发现很多技术人员都在凌晨离开公司。执行团队被要求在项目之初就评估细致的工时，而项目过程中又常发生需求变更，由此导致频繁的返工和加班。执行团队中不同职能的人员互相催赶工作进度，于是需要解释所需的工时。因为互联网常因业绩而追求上线速度，也因为业务量不断攀升，用户通常只涉足前期调研和可用性测试，全程参与项目的情况并不多见。不少管理层在项目全程只简单过问，甚至在项目产出时才第一次提出反馈意见……以上这般种种现象，相信互联网公司的技术同僚们都不陌生吧。
本书中的敏捷项目分析虽然只提到商业智能项目和数据仓库项目，但是其方法广泛适用于互联网中的其他项目，我们推荐所有的互联网从业者（尤其是管理层和执行团队）深入研究并借鉴书中的工作方法。用户故事、用例等这些概念对用户体验从业者来说都不陌生，也希望这些理念能在开发、测试等技术人员当中推广并被接受，这将会让项目大大受益。
感谢机械工业出版社给予我们宝贵的机会来翻译本书，这对我们来说也是一次学习的过程。本书对知识点的讲解十分透彻，引用的实际例子也让我们开拓了思维，看到了国外公司的团队是如何有效运作的。翻译完这本书，我们受益匪浅，希望书中的方法能够惠及各位同行。
最后，虽然我们在翻译过程中慎之又慎并且多次审查，但是书中仍难免存在疏漏和不当之处，恳请读者予以指正。
前言
当DW/BI项目开始腐坏
大多数数据仓库开发者都经历过不太成功的项目。你甚至可能经历过项目失败的痛苦。几年前，我为一家中型公司工作，公司想用一个正确架构的数据仓库取代现有的本地报告应用。我的项目角色是首席架构师和技术总监。这个项目非常糟糕地结束了，我们的解决方案最终也被遗弃。一开始，项目呈现出成功和用户满意的态势。然而，尽管开发人员、项目经理和利益相关者尽了最大的努力，项目超出预算并超过了计划时间，用户对成果也感到不满。因为这个项目极大地激励我去做到让敏捷原则和实践适应数据仓库和商业智能（DW/BI）开发，所以我会做一个简短回顾，为在本书中展现的敏捷DW/BI原则和实践提供依据。它可能和你经历过的项目有类似之处。
关于项目
本节概述了该项目的本质特征，包括下面的内容。
现有的应用程序。公司现有的报告应用程序在内部叫做“数据仓库”，它明显歪曲了用户对数据仓库应用会提供什么的理解。事实上数据模型是一个遗留操作型数据库的部分复制。这个复制的数据库不包含任何的数据清理，并且被大量自定义的用作生成报告的Java代码填充。用户在不同时期都要求增加新的自定义报告功能。应用因为那些很少使用的专业报告功能而变得不堪重负。所有报告都是一成不变的报告。系统没有针对分析活动进行优化，也不提供先进的分析能力。
项目动力。因为现有的“数据仓库”没有按照数据仓库最佳实践来进行架构，所以它达到了持续满足用户需求需要的可维护性和可扩展性的实际极限。此外，如果一个新的计费系统正要上线，很明显不容易调整现有的系统适应新的数据。因此，可见正确设计数据仓库十分重要。
外部驱动。数据仓库项目是一个销售团队的最初设想，这个团队是全球领先的数据仓库和商业智能软件供应商之一的销售团队。在提供指导和售前支持时，这个销售团队帮助项目赞助商了解项目，并向拥有最好行业实践知识、经验丰富的商业智能咨询师寻求帮助。虽然在销售方面做了很多努力，项目的范围、成本和进度的初步估计，显得过于雄心勃勃。
开发团队。开发团队是外部数据仓库承包商。因为公司现有的IT人员有其他优先的工作，公司没有那些具备深厚商业知识或现有操作系统知识的开发人员。然而，开发团队在公司找到了商业和技术专家，从软件供应商那里获得了技术专家。虽然最初的发现工作充满了挑战，但所有的利益相关者都积极参与了。
客户。新数据仓库的主要“客户”是公司财务部门，项目由首席财务官提供资金。他们有一个相对集中的目标——获得更可靠的收入和盈利信息。他们也有大量现成的报告，在常规基础上用于商业分析，为需求分析提供一个合理基础。
项目管理。项目管理（PM）由企业IT部门负责，他们使用传统项目管理研究所/项目管理知识体系（PMBOK）实践。IT团队同时参与其他两个大型开发项目，项目都直接或者间接地影响数据仓库范围。
托管环境。因为有限的资源和基础设施，公司IT领导最近决定和一个应用服务提供商（ASP）合作，为新开发的生产系统提供托管服务。数据仓库将托管在位于美国西海岸的设施中，而公司总部在东海岸。不能解决的问题是，地理分隔的确对大量数据移动有影响，因为操作型系统仍然在东海岸的企业IT基础设施中。
项目成果
最初的项目计划要求初始数据仓库在三个月内完成，但这个发布周期太雄心勃勃了。在项目启动之后，整整8个月才完成，晚了5个月！用户验收测试并不顺利。用户对项目延迟已经很恼火，当他们终于看到所承诺的功能时，得到的功能和期望的功能有着很大差距。由于项目延迟很常见，所以在努力回到正轨时，一般会增加开发团队的人数。正如Fred Brooks说的“在延期项目内增加人员只会让项目更延期”（Brooks 1975）。最终，项目成本远远超过预算，用户不满意，项目被搁置直到下一步计划可以延续开发。
追溯
那么谁是罪魁祸首？每一个人！用户感觉开发者“未击中目标”，没有实现他们的所有需求。开发者感觉用户的期望没有被妥善管理，项目范围超出了控制。项目发起人感觉供应商过度承诺、较少实现。供应商感觉这个公司的内部政治和组织问题应该受到谴责。最后，组织中的多数IT人员感觉缺乏所有权，并偷偷地庆祝失败。
项目最终沦为一系列的会议，在会议中进行合同和项目文档的审查，看看谁应该承担责任。你知道吗？涉及的每一个人都应该承担责任。除了数据仓库开发的常规技术挑战外，以下内容被确定为项目失败的根源：
合同没有平衡好范围、时间进度和资源的问题。
需求是不完整的、模糊的和开放的。
批准的需求和设计文档有相互矛盾的解释。
开发者花很多个夜晚和周末试图响应用户更改和新要求，却不断地陷入混乱。
大多数数据仓库开发者都经历过不太成功的项目。你甚至可能经历过项目失败的痛苦。几年前，我为一家中型公司工作，公司想用一个正确架构的数据仓库取代现有的本地报告应用。我的项目角色是首席架构师和技术总监。这个项目非常糟糕地结束了，我们的解决方案最终也被遗弃。一开始，项目呈现出成功和用户满意的态势。然而，尽管开发人员、项目经理和利益相关者尽了最大的努力，项目超出预算并超过了计划时间，用户对成果也感到不满。因为这个项目极大地激励我去做到让敏捷原则和实践适应数据仓库和商业智能（DW/BI）开发，所以我会做一个简短回顾，为在本书中展现的敏捷DW/BI原则和实践提供依据。它可能和你经历过的项目有类似之处。
关于项目
本节概述了该项目的本质特征，包括下面的内容。
现有的应用程序。公司现有的报告应用程序在内部叫做“数据仓库”，它明显歪曲了用户对数据仓库应用会提供什么的理解。事实上数据模型是一个遗留操作型数据库的部分复制。这个复制的数据库不包含任何的数据清理，并且被大量自定义的用作生成报告的Java代码填充。用户在不同时期都要求增加新的自定义报告功能。应用因为那些很少使用的专业报告功能而变得不堪重负。所有报告都是一成不变的报告。系统没有针对分析活动进行优化，也不提供先进的分析能力。
项目动力。因为现有的“数据仓库”没有按照数据仓库最佳实践来进行架构，所以它达到了持续满足用户需求需要的可维护性和可扩展性的实际极限。此外，如果一个新的计费系统正要上线，很明显不容易调整现有的系统适应新的数据。因此，可见正确设计数据仓库十分重要。
外部驱动。数据仓库项目是一个销售团队的最初设想，这个团队是全球领先的数据仓库和商业智能软件供应商之一的销售团队。在提供指导和售前支持时，这个销售团队帮助项目赞助商了解项目，并向拥有最好行业实践知识、经验丰富的商业智能咨询师寻求帮助。虽然在销售方面做了很多努力，项目的范围、成本和进度的初步估计，显得过于雄心勃勃。
开发团队。开发团队是外部数据仓库承包商。因为公司现有的IT人员有其他优先的工作，公司没有那些具备深厚商业知识或现有操作系统知识的开发人员。然而，开发团队在公司找到了商业和技术专家，从软件供应商那里获得了技术专家。虽然最初的发现工作充满了挑战，但所有的利益相关者都积极参与了。
客户。新数据仓库的主要“客户”是公司财务部门，项目由首席财务官提供资金。他们有一个相对集中的目标——获得更可靠的收入和盈利信息。他们也有大量现成的报告，在常规基础上用于商业分析，为需求分析提供一个合理基础。
项目管理。项目管理（PM）由企业IT部门负责，他们使用传统项目管理研究所/项目管理知识体系（PMBOK）实践。IT团队同时参与其他两个大型开发项目，项目都直接或者间接地影响数据仓库范围。
托管环境。因为有限的资源和基础设施，公司IT领导最近决定和一个应用服务提供商（ASP）合作，为新开发的生产系统提供托管服务。数据仓库将托管在位于美国西海岸的设施中，而公司总部在东海岸。不能解决的问题是，地理分隔的确对大量数据移动有影响，因为操作型系统仍然在东海岸的企业IT基础设施中。
项目成果
最初的项目计划要求初始数据仓库在三个月内完成，但这个发布周期太雄心勃勃了。在项目启动之后，整整8个月才完成，晚了5个月！用户验收测试并不顺利。用户对项目延迟已经很恼火，当他们终于看到所承诺的功能时，得到的功能和期望的功能有着很大差距。由于项目延迟很常见，所以在努力回到正轨时，一般会增加开发团队的人数。正如Fred Brooks说的“在延期项目内增加人员只会让项目更延期”（Brooks 1975）。最终，项目成本远远超过预算，用户不满意，项目被搁置直到下一步计划可以延续开发。
追溯
那么谁是罪魁祸首？每一个人！用户感觉开发者“未击中目标”，没有实现他们的所有需求。开发者感觉用户的期望没有被妥善管理，项目范围超出了控制。项目发起人感觉供应商过度承诺、较少实现。供应商感觉这个公司的内部政治和组织问题应该受到谴责。最后，组织中的多数IT人员感觉缺乏所有权，并偷偷地庆祝失败。
项目最终沦为一系列的会议，在会议中进行合同和项目文档的审查，看看谁应该承担责任。你知道吗？涉及的每一个人都应该承担责任。除了数据仓库开发的常规技术挑战外，以下内容被确定为项目失败的根源：
合同没有平衡好范围、时间进度和资源的问题。
需求是不完整的、模糊的和开放的。
批准的需求和设计文档有相互矛盾的解释。
开发者花很多个夜晚和周末试图响应用户更改和新要求，却不断地陷入混乱。
序言
Forward 序一
大约在7年前，我的朋友介绍我与Ken Collier相识。接下来的日子，我和Ken大约每周都一起喝咖啡（我们在亚利桑那州的Flagstaff组成了二人敏捷开发小组），我们谈论软件开发，谈论各种各样的敏捷，谈论滑雪、山地骑行，当然也谈论Ken的分析项目。早先Ken谈到一个停滞不前的项目时，我提及了“敏捷”这一概念，于是Ken决定在他的下一个项目中尝试实践敏捷，当时Ken冒出这么一句话：“这样看来，以前的项目真是糟透了！”
多年来，我听遍了所有可以想象到的诸如“因为我们是不同的，所以敏捷在公司内部不起作用”之类的话。而Ken从没有怀疑过敏捷，一开始他就在想如何让敏捷在商业智能和数据仓库项目上卓有成效，而不是去琢磨、质疑敏捷是否有效。Ken把每一个障碍都视为契机，并找到一种敏捷方式来攻克障碍。从撰写足以涵盖整个分析软件栈的用户故事，到想出如何在同样的多样栈里进行连续整合，任何时候Ken都是那么“敏捷”，就像他时刻在学习运用敏捷一样。今天Ken已经成为敏捷（being agile），而不仅仅是执行敏捷（doing agile）。
在接下来的多个分析项目里，有一个项目已运作三年多了，每个季度都会写出报告。Ken在这个项目里采用基础的敏捷管理方式和开发手段，并且提出创新的方式来将这些付诸实践。商业智能和数据仓库的开发者一直不太愿意使用敏捷（虽然这种现象已经在发生改变），一部分原因是他们不太了解如何在这么大的以数据为中心的项目中执行敏捷。分析项目同样遇到了和很多典型IT项目相同的问题——过长的开发周期、过多的费用，更关键的是不能满足客户需求。在这个竞争激烈的商业时代，这样的结果是无法令人接受的。
敏捷分析的一个显著特征是适用范围非常广泛：从产品和待办事宜的管理，到敏捷项目管理技术、自建团队、设计实践革新、自动化测试、管理建设、持续性整合。Ken的这套敏捷方法适用于广泛的以数据为导向的产品，甚至当你关注的不是分析性项目时，这套方法也是很有用的。
在每一个课题领域，Ken都是在基本的敏捷实践基础上，根据具体的分析项目对敏捷进行灵活调整和定制，以适应具体的项目。例如，商业智能和数据仓库团队在配置管理方面远不如软件开发团队；而分析团队在代码管理方面通常不擅长，包括Java、Ruby等计算机语言的代码执行、存储步骤程序、SQL以及特定工具代码。Ken用几章来回顾软件开发人员一直使用的技术，展示如何让这些技术更好地适应分析环境。Ken经常问分析团队:“如果你的服务器出了问题，你通常需要花多长时间修复？”他收集到的答案通常是“短的需要几周，长的干脆不修复了”。自动化搭建、整合、测试对于很多分析团队来说都是陌生的，所以Ken在版本控制和自动化搭建这两方面各用了一章，阐述如何建立一个快节奏的、连续整合的环境。
本书还专门开辟一章，阐述如何自定义测试驱动的开发流程，以适应分析环境。综合的自动化测试（从单元测试到验收测试）是敏捷开发方法中很重要的一环，也是完整的连续性整合的需要。
Ken的课题覆盖范围还延伸至架构领域。他倡导架构的革新（设计革新相关内容参见第6章），并且描述了具有适应性的架构模式样式。第6章介绍了一种有适应能力的分析架构，Ken在一个大项目里应用了它，这个项目曾经面临的一个主要挑战是项目的不断变更。和传统的“数据推动”不同，这种分析架构倡导“数据拉进”，和Kanban系统非常相似。
Ken的书深得我喜欢的地方可以概括为三点：（1）本书将敏捷的基本原理和操作实践应用于分析项目；（2）本书提出了技术和管理的实践（执行敏捷）和敏捷的核心原则（成为敏捷）；（3）最后，本书涵盖的主题范围之广令人惊讶（从架构到管理），并且都进行了深入的讲述，而不是蜻蜓点水般泛泛而谈。本书无疑是一本优秀著作，不论你正在从事以数据为中心的项目，还是商业分析项目，这本精良的著作都能够让你受益匪浅！
Jim Highsmith
Thoughtworks有限公司执行顾问
Forward 序二
多年前，我带头开发了数据仓库研究所地方协会的网站。在那之前两年时间我确定了规划，并且与很多人一起发展协会，举办会议。
作为这个项目的商业掌舵人，我很了解协会网站需要什么样的功能。我研究了登录系统以及协作系统，并且把这些特性标识到我的特征矩阵中。我已经准备好在三个月内自己建立一个新的系统。
不幸的是，这个项目走向了“合作”。主席分配一个人来管理这个项目，一个IT人员来搜集需求，一个营销人来协调整合已经存在的网站。我们确定定期碰面讨论解决方案。而这个项目也随即死亡。
在邮件告诉IT开发者我的需求并且和她进行一个简短的对话之后，我阅读了她收集的需求文档。我第一次感觉厄运到来了！当我读这份文档时我都认不出这是我自己的项目了（虽然我很精明）。我知道每个依据这份文档来工作的人（例如外包人员和开发人员）都不能做出接近我们需求的网站。
这个经历让我意识到，商业人士对软件开发中的传统IT方法是多么困惑，因为我目睹了IT人员如何将商业需求转化为IT语言。现在我也明白了为什么如此多的商业智能项目都失败了。
让敏捷来拯救我们吧。第一次读到敏捷开发技术时，我欣喜万分。一些具有商业头脑的人总算融入了IT的大家庭。而关于敏捷开发方法论的一切都变得完美。最重要的是，它改变了一个开发项目的权重分布，从IT团队转到了解决问题的商业运用者上。
大约在7年前，我的朋友介绍我与Ken Collier相识。接下来的日子，我和Ken大约每周都一起喝咖啡（我们在亚利桑那州的Flagstaff组成了二人敏捷开发小组），我们谈论软件开发，谈论各种各样的敏捷，谈论滑雪、山地骑行，当然也谈论Ken的分析项目。早先Ken谈到一个停滞不前的项目时，我提及了“敏捷”这一概念，于是Ken决定在他的下一个项目中尝试实践敏捷，当时Ken冒出这么一句话：“这样看来，以前的项目真是糟透了！”
多年来，我听遍了所有可以想象到的诸如“因为我们是不同的，所以敏捷在公司内部不起作用”之类的话。而Ken从没有怀疑过敏捷，一开始他就在想如何让敏捷在商业智能和数据仓库项目上卓有成效，而不是去琢磨、质疑敏捷是否有效。Ken把每一个障碍都视为契机，并找到一种敏捷方式来攻克障碍。从撰写足以涵盖整个分析软件栈的用户故事，到想出如何在同样的多样栈里进行连续整合，任何时候Ken都是那么“敏捷”，就像他时刻在学习运用敏捷一样。今天Ken已经成为敏捷（being agile），而不仅仅是执行敏捷（doing agile）。
在接下来的多个分析项目里，有一个项目已运作三年多了，每个季度都会写出报告。Ken在这个项目里采用基础的敏捷管理方式和开发手段，并且提出创新的方式来将这些付诸实践。商业智能和数据仓库的开发者一直不太愿意使用敏捷（虽然这种现象已经在发生改变），一部分原因是他们不太了解如何在这么大的以数据为中心的项目中执行敏捷。分析项目同样遇到了和很多典型IT项目相同的问题——过长的开发周期、过多的费用，更关键的是不能满足客户需求。在这个竞争激烈的商业时代，这样的结果是无法令人接受的。
敏捷分析的一个显著特征是适用范围非常广泛：从产品和待办事宜的管理，到敏捷项目管理技术、自建团队、设计实践革新、自动化测试、管理建设、持续性整合。Ken的这套敏捷方法适用于广泛的以数据为导向的产品，甚至当你关注的不是分析性项目时，这套方法也是很有用的。
在每一个课题领域，Ken都是在基本的敏捷实践基础上，根据具体的分析项目对敏捷进行灵活调整和定制，以适应具体的项目。例如，商业智能和数据仓库团队在配置管理方面远不如软件开发团队；而分析团队在代码管理方面通常不擅长，包括Java、Ruby等计算机语言的代码执行、存储步骤程序、SQL以及特定工具代码。Ken用几章来回顾软件开发人员一直使用的技术，展示如何让这些技术更好地适应分析环境。Ken经常问分析团队:“如果你的服务器出了问题，你通常需要花多长时间修复？”他收集到的答案通常是“短的需要几周，长的干脆不修复了”。自动化搭建、整合、测试对于很多分析团队来说都是陌生的，所以Ken在版本控制和自动化搭建这两方面各用了一章，阐述如何建立一个快节奏的、连续整合的环境。
本书还专门开辟一章，阐述如何自定义测试驱动的开发流程，以适应分析环境。综合的自动化测试（从单元测试到验收测试）是敏捷开发方法中很重要的一环，也是完整的连续性整合的需要。
Ken的课题覆盖范围还延伸至架构领域。他倡导架构的革新（设计革新相关内容参见第6章），并且描述了具有适应性的架构模式样式。第6章介绍了一种有适应能力的分析架构，Ken在一个大项目里应用了它，这个项目曾经面临的一个主要挑战是项目的不断变更。和传统的“数据推动”不同，这种分析架构倡导“数据拉进”，和Kanban系统非常相似。
Ken的书深得我喜欢的地方可以概括为三点：（1）本书将敏捷的基本原理和操作实践应用于分析项目；（2）本书提出了技术和管理的实践（执行敏捷）和敏捷的核心原则（成为敏捷）；（3）最后，本书涵盖的主题范围之广令人惊讶（从架构到管理），并且都进行了深入的讲述，而不是蜻蜓点水般泛泛而谈。本书无疑是一本优秀著作，不论你正在从事以数据为中心的项目，还是商业分析项目，这本精良的著作都能够让你受益匪浅！
Jim Highsmith
Thoughtworks有限公司执行顾问
Forward 序二
多年前，我带头开发了数据仓库研究所地方协会的网站。在那之前两年时间我确定了规划，并且与很多人一起发展协会，举办会议。
作为这个项目的商业掌舵人，我很了解协会网站需要什么样的功能。我研究了登录系统以及协作系统，并且把这些特性标识到我的特征矩阵中。我已经准备好在三个月内自己建立一个新的系统。
不幸的是，这个项目走向了“合作”。主席分配一个人来管理这个项目，一个IT人员来搜集需求，一个营销人来协调整合已经存在的网站。我们确定定期碰面讨论解决方案。而这个项目也随即死亡。
在邮件告诉IT开发者我的需求并且和她进行一个简短的对话之后，我阅读了她收集的需求文档。我第一次感觉厄运到来了！当我读这份文档时我都认不出这是我自己的项目了（虽然我很精明）。我知道每个依据这份文档来工作的人（例如外包人员和开发人员）都不能做出接近我们需求的网站。
这个经历让我意识到，商业人士对软件开发中的传统IT方法是多么困惑，因为我目睹了IT人员如何将商业需求转化为IT语言。现在我也明白了为什么如此多的商业智能项目都失败了。
让敏捷来拯救我们吧。第一次读到敏捷开发技术时，我欣喜万分。一些具有商业头脑的人总算融入了IT的大家庭。而关于敏捷开发方法论的一切都变得完美。最重要的是，它改变了一个开发项目的权重分布，从IT团队转到了解决问题的商业运用者上。
媒体评论
这本书很好地解释了我们在实际中为什么要运用敏捷分析，以及如何运用敏捷分析。Ken从实际运用方法以及改进方法中汲取了很多经验。商业智能领域肯定能从中受益良多。
——Dale Zinkgraf，资深商业智能构架师
本书的一个显著特点是涉猎范围广泛一一从产品和待办事项管理到敏捷项目管理技巧；从团队自我组织到不断发展的设计实践；从自动化测试到构建管理及持续集成。即便你的项目与分析无关，本书中介绍的面向数据产品的相关内容，其处理方式对非分析型团队也非常有用。
——Jim Highsmith，ThoughtWorks公司执行顾问，《Agile Project Management》作者
这本书抓住了未来十年商业智能分析项目获得成功的基本策略。Ken Collier已经提升了从业者的水准——你准备好迎接挑战了吗?
——Scott Ambler，Agileand Lean的首席方法学家，IBM Rational创始人
敏捷方法已经改变了软件开发领域，而现在，敏捷方法是时候改变分析领域了。本书提供了下个分析项目中改变敏捷方法所需的知识。
——Pramod Sadalage，(Refactoring Databases：Evolutionary Database Design)合著者
本书是对基本原则的全面介绍，能够让团队比传统软件开发方式更快速、更有效地交付出高品质、高价值的、可用的商业智能系统。
——Ralph Hughes，(Agile Data Warehousing)的作者
——Dale Zinkgraf，资深商业智能构架师
本书的一个显著特点是涉猎范围广泛一一从产品和待办事项管理到敏捷项目管理技巧；从团队自我组织到不断发展的设计实践；从自动化测试到构建管理及持续集成。即便你的项目与分析无关，本书中介绍的面向数据产品的相关内容，其处理方式对非分析型团队也非常有用。
——Jim Highsmith，ThoughtWorks公司执行顾问，《Agile Project Management》作者
这本书抓住了未来十年商业智能分析项目获得成功的基本策略。Ken Collier已经提升了从业者的水准——你准备好迎接挑战了吗?
——Scott Ambler，Agileand Lean的首席方法学家，IBM Rational创始人
敏捷方法已经改变了软件开发领域，而现在，敏捷方法是时候改变分析领域了。本书提供了下个分析项目中改变敏捷方法所需的知识。
——Pramod Sadalage，(Refactoring Databases：Evolutionary Database Design)合著者
本书是对基本原则的全面介绍，能够让团队比传统软件开发方式更快速、更有效地交付出高品质、高价值的、可用的商业智能系统。
——Ralph Hughes，(Agile Data Warehousing)的作者
书摘
第1章
敏捷分析概述
类似于敏捷软件开发，敏捷分析建立在一系列核心价值以及指导原则上。它不是一个死板固定的方法，而建立数据仓库、数据集、商业智能应用，以及分析应用的一种风格，这种风格专注于整个开发周期，尽早并持续不断地传达商业价值。在实际应用中，敏捷分析包含一系列需要高度训练的实践和技术，有些是为了适应企业中独特的数据仓库以及商业智能（DW/BI）的项目需求量身定制的。
敏捷分析包含项目计划、管理以及监测的实践；与商业用户和利益相关者的有效合作；并且要确保团队是卓越的。本章概述了敏捷分析的宗旨及后面各章会介绍到的实践和技术背后的基本规则。
“敏捷”在描述开发风格时是一个关键词。虽然它的意思非常明确，但不幸的是，敏捷不时被误认为是点对点、粗糙以及缺乏训练的代名词。敏捷确实需要依靠训练和严格，但这绝对不是一个沉重的或者非常隆重的过程，尽管一些方法论试图编纂它。因此，敏捷处于完整结构及正好足够的灵活性之间。有句话说，敏捷简单但不容易，建立在简单的价值以及原则上，只不过需要高度训练及严谨正确的执行。准确理解敏捷的特性是非常重要的，它们使得真正的敏捷过程区别于那些没有结构或者过于僵化的过程。本章的目的是使你认这些特性，了解敏捷分析的基本价值和准则，是敏捷社区已经尝试和检验的基本原理，并已适应数据仓库和商业智能开发。
1.1阿尔卑斯风格的系统开发
我是一个有点不切实际的登山运动员。我对翻越珠穆朗玛、纳普尔那峰以及其他那些海拔超过8000米的高山过程中的艰辛体验很着迷。这些探险十分复杂，包括挑战计划的制定、逻辑梳理、高度冒险和不确定性，甚至是随时面临死亡（每两个人爬上纳普尔那峰，就有另一个人在途中死亡），还有不可控变数导致的困难决策，以及得到成功的极度喜悦。尽管可能和冒险不完全相同，但建立一个复杂的商业智能系统非常像高海拔攀登。我们面临很多风险和不确定性：复杂的计划、在战斗中艰难决策，以及死亡的可能性。好吧，也许这不是最后的结局，但是你也很可能会得到类似的结果。不幸的是，建立数据仓库和商业智能系统的成功概率并不比高海拔攀登的成功率乐观。
在20世纪50年代至70年代，攀爬团队开始成功“征服”这些高山。在那时他们选择的登山风格叫做“围攻攀登”，这与军队远征有很多相似的地方。探险队被专制领导。通常来说，相较于其攀爬经验，这个领导者拥有更多军事领导经验。登山队需要很多搬运工支持。这些搬运工负责搬运很多齿轮和供给到基站以及更高的地方。实施围攻攀登探险需要花费一年多时间来计划，登山季节期间需要花费两个月甚至更多时间来执行。围攻攀登就像溜溜球，溜溜球的绳索沿着山脉慢慢升高。登山队沿着线路，建立很多临时站点，搬运工将供给慢慢搬运至更高的营地上。最终有一天，在所有这些支持下，顶尖的登山小队会向峰顶发起冲刺。他们从高处的营地离开，之后返回同一个营地。聪明的团队用这个方式在几年内成功地爬上了很多高山，但是这样的探险花费惊人，旷日持久，过程冗长复杂。
传统的商业智能系统开发和这样的围攻攀登很类似。虽然可以提供高品质、性能很好的工作系统，但是这些项目都非常昂贵，需要充足的计划，开发前也要有庞大的设计，以及很长的开发周期。和围攻风格的探险一样，所有能量都将汇聚到一点，并向峰顶发起冲刺。如果峰顶攀登失败，那么登山队就要花费大量时间返回基地，为另一次尝试重组团队。在我的职业生涯中（虽然我没那么老），我见到很多传统DW/BI项目的预算高达2000万美金甚至更多，长达18到24个月的开发时间。而当这样的项目失败时，典型的项目管理回应就是完全取消项目，而不去调整、适应，为了另一次“登顶尝试”重组团队。
20世纪70年代，一种新的叫做“阿尔卑斯风格”的全新登山方法的出现，使得一些小登山队能够以更快、更经济，并且只需达成更少协议的方式来攀爬上那些高山。阿尔卑斯风格登山方法仍然需要大量的计划、充足支持的团队、足够的传动装置和供给，以确保安全到达山顶。然而，不需要花费数月时间准备最后登顶冲刺的路线，阿尔卑斯风格登山者只需花费大约一个星期，将必不可少的登山装备搬运到更高的营地。如果条件合适，用这种登山风格能让登山队在短短十天内登上山顶。两到三名登山员组成的团队，能更轻、更快速地攀爬。如果条件不好，阿尔卑斯风格的登山者们则返回大本营，等待好时机，去开启另一次登顶行动。
敏捷DW/BI开发更像是阿尔卑斯风格的登山。至关重要的是，我们要有充足的计划、获得成功的必要支持，以及适量的协议。我们的“峰顶”是完成一个高质量、对用户而言有很高价值、可用的商业智能系统。和登山一样，攀上峰顶需要适当的环境。我们需要适量的规划—我们也要根据不断变化的因素和新消息修改我们的计划。我们需要为高风险和不确定性做足准备—我们也要能够迅速管理和回应那些风险，和那些显而易见的风险一样。我们需要大团队的支持和参与—但是我们也寻求团队的自我组织，而不是独裁式的领导风格。
敏捷分析是一种开发“风格”，而不是一种方法论或者一种架构。围攻风格与阿尔卑斯风格之间的界限并不那么清晰，阿尔卑斯风格的探险可能包含一些围攻风格的实践。每种风格通过其价值和基本纲领表述。每个阿尔卑斯风格探险队采用不同的攀登方法来支持一套共同的价值和原则。相似地，每个敏捷DW/BI项目团队也必须调整自身的技术、项目管理、客户协作方法来最好地支持敏捷价值和原则。
世界第一登山人Ed Viesturs拥有一个公式，或者说是核心价值。那就是他在高山上时的重要准则：“攀顶是可选择的，而下山是强制性的”（Viesturs and Roberts 2006）。我喜欢这个核心价值！因为它简单优雅，它为ED Viesturs在山峦上需要做出的所有决定提供了一个明确的依据。在攀登的压力下，或者是在强烈的挑战项目中，我们需要一个帮助我们做出决定的依据—这就好比我们的“北极星”。在2000年，一些最具影响力的应用软件开发者汇集到盐湖城，成立了敏捷联盟。通过分享和比较每个软件的开发风格，敏捷宣言为项目指导和决策提供了简单优雅的依据。敏捷宣言如下：
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和交互高于过程与工具
可用的软件高于详尽的文档
客户协作高于合同协商
响应变化高于遵循计划
也就是说，尽管右边的项目拥有其价值，但是我们更重视左边的价值体现。
敏捷分析概述
类似于敏捷软件开发，敏捷分析建立在一系列核心价值以及指导原则上。它不是一个死板固定的方法，而建立数据仓库、数据集、商业智能应用，以及分析应用的一种风格，这种风格专注于整个开发周期，尽早并持续不断地传达商业价值。在实际应用中，敏捷分析包含一系列需要高度训练的实践和技术，有些是为了适应企业中独特的数据仓库以及商业智能（DW/BI）的项目需求量身定制的。
敏捷分析包含项目计划、管理以及监测的实践；与商业用户和利益相关者的有效合作；并且要确保团队是卓越的。本章概述了敏捷分析的宗旨及后面各章会介绍到的实践和技术背后的基本规则。
“敏捷”在描述开发风格时是一个关键词。虽然它的意思非常明确，但不幸的是，敏捷不时被误认为是点对点、粗糙以及缺乏训练的代名词。敏捷确实需要依靠训练和严格，但这绝对不是一个沉重的或者非常隆重的过程，尽管一些方法论试图编纂它。因此，敏捷处于完整结构及正好足够的灵活性之间。有句话说，敏捷简单但不容易，建立在简单的价值以及原则上，只不过需要高度训练及严谨正确的执行。准确理解敏捷的特性是非常重要的，它们使得真正的敏捷过程区别于那些没有结构或者过于僵化的过程。本章的目的是使你认这些特性，了解敏捷分析的基本价值和准则，是敏捷社区已经尝试和检验的基本原理，并已适应数据仓库和商业智能开发。
1.1阿尔卑斯风格的系统开发
我是一个有点不切实际的登山运动员。我对翻越珠穆朗玛、纳普尔那峰以及其他那些海拔超过8000米的高山过程中的艰辛体验很着迷。这些探险十分复杂，包括挑战计划的制定、逻辑梳理、高度冒险和不确定性，甚至是随时面临死亡（每两个人爬上纳普尔那峰，就有另一个人在途中死亡），还有不可控变数导致的困难决策，以及得到成功的极度喜悦。尽管可能和冒险不完全相同，但建立一个复杂的商业智能系统非常像高海拔攀登。我们面临很多风险和不确定性：复杂的计划、在战斗中艰难决策，以及死亡的可能性。好吧，也许这不是最后的结局，但是你也很可能会得到类似的结果。不幸的是，建立数据仓库和商业智能系统的成功概率并不比高海拔攀登的成功率乐观。
在20世纪50年代至70年代，攀爬团队开始成功“征服”这些高山。在那时他们选择的登山风格叫做“围攻攀登”，这与军队远征有很多相似的地方。探险队被专制领导。通常来说，相较于其攀爬经验，这个领导者拥有更多军事领导经验。登山队需要很多搬运工支持。这些搬运工负责搬运很多齿轮和供给到基站以及更高的地方。实施围攻攀登探险需要花费一年多时间来计划，登山季节期间需要花费两个月甚至更多时间来执行。围攻攀登就像溜溜球，溜溜球的绳索沿着山脉慢慢升高。登山队沿着线路，建立很多临时站点，搬运工将供给慢慢搬运至更高的营地上。最终有一天，在所有这些支持下，顶尖的登山小队会向峰顶发起冲刺。他们从高处的营地离开，之后返回同一个营地。聪明的团队用这个方式在几年内成功地爬上了很多高山，但是这样的探险花费惊人，旷日持久，过程冗长复杂。
传统的商业智能系统开发和这样的围攻攀登很类似。虽然可以提供高品质、性能很好的工作系统，但是这些项目都非常昂贵，需要充足的计划，开发前也要有庞大的设计，以及很长的开发周期。和围攻风格的探险一样，所有能量都将汇聚到一点，并向峰顶发起冲刺。如果峰顶攀登失败，那么登山队就要花费大量时间返回基地，为另一次尝试重组团队。在我的职业生涯中（虽然我没那么老），我见到很多传统DW/BI项目的预算高达2000万美金甚至更多，长达18到24个月的开发时间。而当这样的项目失败时，典型的项目管理回应就是完全取消项目，而不去调整、适应，为了另一次“登顶尝试”重组团队。
20世纪70年代，一种新的叫做“阿尔卑斯风格”的全新登山方法的出现，使得一些小登山队能够以更快、更经济，并且只需达成更少协议的方式来攀爬上那些高山。阿尔卑斯风格登山方法仍然需要大量的计划、充足支持的团队、足够的传动装置和供给，以确保安全到达山顶。然而，不需要花费数月时间准备最后登顶冲刺的路线，阿尔卑斯风格登山者只需花费大约一个星期，将必不可少的登山装备搬运到更高的营地。如果条件合适，用这种登山风格能让登山队在短短十天内登上山顶。两到三名登山员组成的团队，能更轻、更快速地攀爬。如果条件不好，阿尔卑斯风格的登山者们则返回大本营，等待好时机，去开启另一次登顶行动。
敏捷DW/BI开发更像是阿尔卑斯风格的登山。至关重要的是，我们要有充足的计划、获得成功的必要支持，以及适量的协议。我们的“峰顶”是完成一个高质量、对用户而言有很高价值、可用的商业智能系统。和登山一样，攀上峰顶需要适当的环境。我们需要适量的规划—我们也要根据不断变化的因素和新消息修改我们的计划。我们需要为高风险和不确定性做足准备—我们也要能够迅速管理和回应那些风险，和那些显而易见的风险一样。我们需要大团队的支持和参与—但是我们也寻求团队的自我组织，而不是独裁式的领导风格。
敏捷分析是一种开发“风格”，而不是一种方法论或者一种架构。围攻风格与阿尔卑斯风格之间的界限并不那么清晰，阿尔卑斯风格的探险可能包含一些围攻风格的实践。每种风格通过其价值和基本纲领表述。每个阿尔卑斯风格探险队采用不同的攀登方法来支持一套共同的价值和原则。相似地，每个敏捷DW/BI项目团队也必须调整自身的技术、项目管理、客户协作方法来最好地支持敏捷价值和原则。
世界第一登山人Ed Viesturs拥有一个公式，或者说是核心价值。那就是他在高山上时的重要准则：“攀顶是可选择的，而下山是强制性的”（Viesturs and Roberts 2006）。我喜欢这个核心价值！因为它简单优雅，它为ED Viesturs在山峦上需要做出的所有决定提供了一个明确的依据。在攀登的压力下，或者是在强烈的挑战项目中，我们需要一个帮助我们做出决定的依据—这就好比我们的“北极星”。在2000年，一些最具影响力的应用软件开发者汇集到盐湖城，成立了敏捷联盟。通过分享和比较每个软件的开发风格，敏捷宣言为项目指导和决策提供了简单优雅的依据。敏捷宣言如下：
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和交互高于过程与工具
可用的软件高于详尽的文档
客户协作高于合同协商
响应变化高于遵循计划
也就是说，尽管右边的项目拥有其价值，但是我们更重视左边的价值体现。
