本书是敏捷领域的经典图书，由敏捷先驱Ken Collier执笔，权威性毋庸置疑。全书分为两大部分，第一部分关注敏捷项目的管理技术和团队协调，介绍有助于敏捷DW/BI项目团体进行协作并取得成功的核心实践；第二部分展现一些技术方法，这些方法有助于持续产出符合上线质量的商业价值，方法包括最优设计推进、测试驱动的DW开发、版本控制和项目自动化。
本书适合IT决策者、数据仓库专业人士、数据库管理员、商业智能专家、数据库开发人员等相关技术人员阅读参考。

Jolt大奖获得者Pramod Sadalage和IBM Rational创始人Scott Ambler倾情推荐，高价值DW/BI系统开发的绝佳实践指南
从架构到管理，从自动化测试到持续集成，借助丰富的实际工作案例，全方位深入讲解敏捷DW/BI的关键技术和项目管理实践，有效缓解DW/BI项目风险，创新高价值的DW/BI 解决方案


这本书很好地解释了我们在实际中为什么要运用敏捷分析，以及如何运用敏捷分析。Ken从实际运用方法以及改进方法中汲取了很多经验。商业智能领域肯定能从中受益良多。
—— Dale Zinkgraf，资深商业智能构架师

本书的一个显著特点是涉猎范围广泛——从产品和待办事项管理到敏捷项目管理技巧；从团队自我组织到不断发展的设计实践；从自动化测试到构建管理及持续集成。即便你的项目与分析无关，本书中介绍的面向数据产品的相关内容，其处理方式对非分析型团队也非常有用。
—— Jim Highsmith，ThoughtWorks公司执行顾问，《Agile Project Management》作者

这本书抓住了未来十年商业智能分析项目获得成功的基本策略。Ken Collier已经提升了从业者的水准——你准备好迎接挑战了吗？
—— Scott Ambler，Agile and Lean的首席方法学家，IBM Rational创始人


本书介绍了在平台不可知的情况下整合基础设施的敏捷解决方案，这些基础设施包含不同运作方式、遗留问题，以及混合了商业和客户代码的专业系统。Collier通过丰富的工作实例展示了如何使用广泛的技巧来管理分析开发团队，如何支持巨大的和快速增长的数据量。无论你的项目是“后端”的数据管理，还是“前端”的商业分析，或是二者兼而有之，本书都将为你实现最优价值提供实用指导。
第一部分关注敏捷项目的管理技术和团队协作，介绍有助于敏捷DW/BI项目团队进行协作并取得成功的核心实践。
第二部分侧重于必要的能够持续传递商业价值并有质量保障的技术方法，包括最优设计推进、测试驱动的数据仓库开发、版本控制和项目自动化。



作者简介
Ken Collier　KWC技术公司创始人兼总裁，Cutter联盟敏捷开发和商业智能高级咨询顾问，专注于增强组织敏捷性，包括敏捷软件工程、敏捷分析以及客户公司的敏捷管理和领导。Ken自2003年起就致力于研究敏捷方法，并且倡导把敏捷方法应用于数据仓库、商业智能及分析，开创敏捷分析风格。作为很多敏捷DW/BI项目团队中的技术领导和项目经理，他不断地完善这些观点，同时也经常对DW/BI团队进行敏捷分析培训。他一直是很多美国和国际大会上敏捷DW/BI主题的主讲嘉宾，这些会议包括多个TDWI（The Data Warehousing Institute）国际会议，以及HEDW（Higher Education Data Warehouse）年度会议。


敏捷方法已经改变了软件开发领域，而现在，敏捷方法是时候改变分析领域了。本书提供了下个分析项目中改变敏捷方法所需的知识。
—— Pramod Sadalage，《Refactoring Databases: Evolutionary Database Design》合著者

本书是对基本原则的全面介绍，能够让团队比传统软件开发方式更快速、更有效地交付出高品质、高价值的、可用的商业智能系统。
—— Ralph Hughes， 《Agile Data Warehousing》的作者


使用敏捷方式，可以为任何数据仓库（DW）、商业智能（BI）或分析项目带来更多的创新、价值和更高的质量。然而，必须仔细地调整传统的敏捷方式，以适应DW/BI项目的独特之处。在本书中，敏捷先驱Ken Collier会告诉我们如何去做。
全书分为两部分，共10章，从架构到管理，从自动化测试到持续集成，通过丰富的工作实例，系统而深入地讲解敏捷DW/BI的基本原理、关键技术和项目管理实践，为在真实商业智能和数据仓库项目上应用敏捷分析方法提供系统实用指南。从管理角度，详细介绍敏捷分析的基本原则，敏捷项目管理的有效实践，包括章程、规划、执行和检测敏捷分析项目的有效实践，以及成立高度协作项目团队的指导原则和实践，展现如何使用案例和用户故事驱使价值持续传递，并讲解团队管理和领导的敏捷风格如何有效地替代传统命令控制风格；从技术角度，深入讲解能够持续传递商业价值并有质量保障的技术方法，包括最优设计推进、测试驱动的数据仓库开发、版本控制和项目自动化，以及应用敏捷分析时的一些注意事项。
本书内容全面，讲解深入，并且涵盖许多经过实践检验的解决方案， 适合IT决策者、数据仓库专业人士、数据库管理员、商业智能专家和数据库开发人员参考。

当DW/BI项目开始腐坏
大多数数据仓库开发者都经历过不太成功的项目。你甚至可能经历过项目失败的痛苦。几年前，我为一家中型公司工作，公司想用一个正确架构的数据仓库取代现有的本地报告应用。我的项目角色是首席架构师和技术总监。这个项目非常糟糕地结束了，我们的解决方案最终也被遗弃。一开始，项目呈现出成功和用户满意的态势。然而，尽管开发人员、项目经理和利益相关者尽了最大的努力，项目超出预算并超过了计划时间，用户对成果也感到不满。因为这个项目极大地激励我去做到让敏捷原则和实践适应数据仓库和商业智能（DW/BI）开发，所以我会做一个简短回顾，为在本书中展现的敏捷DW/BI原则和实践提供依据。它可能和你经历过的项目有类似之处。
关于项目
本节概述了该项目的本质特征，包括下面的内容。
现有的应用程序。公司现有的报告应用程序在内部叫做“数据仓库”，它明显歪曲了用户对数据仓库应用会提供什么的理解。事实上数据模型是一个遗留操作型数据库的部分复制。这个复制的数据库不包含任何的数据清理，并且被大量自定义的用作生成报告的Java代码填充。用户在不同时期都要求增加新的自定义报告功能。应用因为那些很少使用的专业报告功能而变得不堪重负。所有报告都是一成不变的报告。系统没有针对分析活动进行优化，也不提供先进的分析能力。
项目动力。因为现有的“数据仓库”没有按照数据仓库最佳实践来进行架构，所以它达到了持续满足用户需求需要的可维护性和可扩展性的实际极限。此外，如果一个新的计费系统正要上线，很明显不容易调整现有的系统适应新的数据。因此，可见正确设计数据仓库十分重要。
外部驱动。数据仓库项目是一个销售团队的最初设想，这个团队是全球领先的数据仓库和商业智能软件供应商之一的销售团队。在提供指导和售前支持时，这个销售团队帮助项目赞助商了解项目，并向拥有最好行业实践知识、经验丰富的商业智能咨询师寻求帮助。虽然在销售方面做了很多努力，项目的范围、成本和进度的初步估计，显得过于雄心勃勃。
开发团队。开发团队是外部数据仓库承包商。因为公司现有的IT人员有其他优先的工作，公司没有那些具备深厚商业知识或现有操作系统知识的开发人员。然而，开发团队在公司找到了商业和技术专家，从软件供应商那里获得了技术专家。虽然最初的发现工作充满了挑战，但所有的利益相关者都积极参与了。
客户。新数据仓库的主要“客户”是公司财务部门，项目由首席财务官提供资金。他们有一个相对集中的目标——获得更可靠的收入和盈利信息。他们也有大量现成的报告，在常规基础上用于商业分析，为需求分析提供一个合理基础。
项目管理。项目管理（PM）由企业IT部门负责，他们使用传统项目管理研究所/项目管理知识体系（PMBOK）实践。IT团队同时参与其他两个大型开发项目，项目都直接或者间接地影响数据仓库范围。
托管环境。因为有限的资源和基础设施，公司IT领导最近决定和一个应用服务提供商（ASP）合作，为新开发的生产系统提供托管服务。数据仓库将托管在位于美国西海岸的设施中，而公司总部在东海岸。不能解决的问题是，地理分隔的确对大量数据移动有影响，因为操作型系统仍然在东海岸的企业IT基础设施中。
项目成果
最初的项目计划要求初始数据仓库在三个月内完成，但这个发布周期太雄心勃勃了。在项目启动之后，整整8个月才完成，晚了5个月！用户验收测试并不顺利。用户对项目延迟已经很恼火，当他们终于看到所承诺的功能时，得到的功能和期望的功能有着很大差距。由于项目延迟很常见，所以在努力回到正轨时，一般会增加开发团队的人数。正如Fred Brooks说的“在延期项目内增加人员只会让项目更延期”（Brooks 1975）。最终，项目成本远远超过预算，用户不满意，项目被搁置直到下一步计划可以延续开发。
追溯
那么谁是罪魁祸首？每一个人！用户感觉开发者“未击中目标”，没有实现他们的所有需求。开发者感觉用户的期望没有被妥善管理，项目范围超出了控制。项目发起人感觉供应商过度承诺、较少实现。供应商感觉这个公司的内部政治和组织问题应该受到谴责。最后，组织中的多数IT人员感觉缺乏所有权，并偷偷地庆祝失败。
项目最终沦为一系列的会议，在会议中进行合同和项目文档的审查，看看谁应该承担责任。你知道吗？涉及的每一个人都应该承担责任。除了数据仓库开发的常规技术挑战外，以下内容被确定为项目失败的根源：
合同没有平衡好范围、时间进度和资源的问题。
需求是不完整的、模糊的和开放的。
批准的需求和设计文档有相互矛盾的解释。
开发者花很多个夜晚和周末试图响应用户更改和新要求，却不断地陷入混乱。
技术团队害怕公开即将到来的失败预警信号，继续努力兑现不切实际的承诺。
开发者没有充分理解用户的需求或者期望，也没有很好地管理需求更改。
现有的知识基于之前的报告应用，使得用户对数据仓库的目的有着明显误解（不是数据仓库的好模型）。
供应商提出了雄心勃勃的承诺，开发者不能在预期的时间内按时交付。
项目经理没有管理用户期望。
IT人员隐瞒了开发者的重要信息。
ASP合作伙伴没有提供开发者期望的连接性水平和技术支持。
事后看来，在项目的最后几天，以下几个事情是显而易见的：
在开发者、用户、利益相关者和内部IT专家之间的高度互动，可以确保正确地理解所有参与者的意图。尽早且频繁地交付可用的软件，不论这些软件多么简单，都能大大降低用户的误解，提高他们预期的精度。更加注重用户协作能够避免对需求进行解释时的前后矛盾。关注并响应变化的项目计划比满足一系列“冻结”的合同要求更有利于提高用户对最终产品的满意度。最后，不要去责怪谁，引起这个项目和其他数据仓库项目失败的根源，是开发者和用户之间理解及期望的鸿沟。
关于本书
大约是同一时间，还沉浸在失败痛苦项目的阵痛中，我遇到了Jim Highsmith，敏捷运动的缔造者之一（《自适应软件开发》、《敏捷软件开发生态系统》和《敏捷项目管理》的作者，本书所属系列的《敏捷软件开发系列》的编辑）。Jim倾听了我对项目困难的抱怨，传授给我很多经验，我开始思索敏捷方法如何适应DW/BI系统开发。不幸的是，我遇到Jim时已经太晚了，不能拯救那艘还在下沉的船。从那时起，我和Jim成了很好的朋友，几乎每周都边喝咖啡边交换想法。当然，几乎都是他分享很好的点子，我尽可能地吸纳它们。Jim成了我的敏捷导师，自从我们第一次见面后，我暗下决心在今后的职业生涯中要确保再也不会遇到失败的DW/BI项目。现在看起来这是个很大胆的目标，但是我相信人生苦短，不应该承受那些注定会失败的项目；敏捷开发是一个我们所掌握的最好的项目风险缓解方法；敏捷开发是革新我们可用的高价值、高品质、可用的DW/BI系统的最佳方法。这就是本书所讲述的内容：
缓解DW/BI项目风险
创新高价值的DW/BI 解决方案
玩得开心
从上一次痛苦的项目经历之后，我有了很多很好的机会，使敏捷开发方法适应DW/BI系统开发的独特特点。和一些非常有才华的敏捷DW/BI从业者共事，我成功地适应、实现和细化了一整套项目管理和技术实践，并创造了敏捷分析开发方法。
这种适应是不平凡的，我们要面对很多重要且独特的但是主流软件开发人员不用面对的挑战。DW/BI开发者需要处理集成了商业软件和编写自定义代码（ETL脚本、SQL、MDX及常见应用程序）的混搭组合。DW/BI开发团队往往拥有广泛且方向不同的技术人员。DW/BI开发基于大量数据，并基于一个操作型、遗留和专业系统的复杂混合物。DW/BI系统开发平台经常是高端专用服务器或者服务器集群，复制沙箱开发和测试就会更加困难。因为这些和更多其他原因，敏捷软件开发方法并不总是能够轻松地适应DW/BI系统开发，我遇到了一些放弃尝试的DW/BI开发者。本书将介绍对敏捷DW/BI来说必不可少的关键技术和项目管理实践。每个实践将用一个例子彻底地阐述和论证，我将会告诉你如何修改每个实践，让它更好地适应具体情况。
本书的读者对象是以下三类人员：
想学习敏捷技术、学习如何将敏捷技术应用到熟悉且复杂的DW/BI开发中的DW/BI从业者。我为这些读者提供了涉及商业智能和以数据为中心项目的敏捷技术及项目管理技术细节。
那些想知道怎么把熟悉的敏捷实践应用到DW/BI系统开发复杂性中的敏捷实践者。为这些读者我阐述了商业智能项目的特点，它们显著不同于软件开发项目的系统，我展示了如何让敏捷准则和实践适应这些独特的特点。
有责任监督计划投资组合的IT和工程管理者，包括数据仓库、商业智能和分析项目。这类读者既没有深厚的商业智能技术专长，也没有敏捷方法专长。我为这些读者展示了对一个方法的介绍，这个方法可以帮助大家提高项目成功和取悦客户的可能性。
虽然本书不是DW/BI系统基础的引子，但是我经常会为了第二类读者，偶尔偏移主题到DW/BI基础上。那些熟悉商业智能的读者可以轻松地跳过这些内容。
顺便说一下，虽然我不是所有类型企业IT系统的专家，例如企业资源计划（ERP）实现，但是我有理由相信敏捷分析的原则和实践可以轻松地适应这些类型，在这些环境中很好地工作。如果你是一名IT执行者，你可能要思考组织中更广泛的敏捷开发背景。
为什么是一本敏捷DW/BI的书
在过去几年中，敏捷软件开发运动持续爆发。敏捷成功的故事比比皆是。经验证据持续增加，强有力地支持了敏捷软件开发。敏捷社区在过去短短几年中急剧增长，很多大型企业在他们的IT和工程部门都采用了敏捷。关于敏捷软件开发各个方面的书籍也在增多。
不幸的是，在数据和商业智能社区，敏捷方法没有得到大面积的普及。由于一些奇怪的原因，数据社区和软件开发社区一直彼此独立地成长和发展。在一个社区中发生的大突破在另一个社区往往不会发生。20世纪90年代面向对象的繁荣就是一个典型的例子。软件开发社区把面向对象融入他们的DNA中，已经获得了巨大的收益，但是面向对象的数据库开发仍然是数据社区的非主流。
不论何时，在与DW/BI从业者和数据库开发者交谈时，他们常见的反应都是敏捷方法不适用于以数据为中心的系统开发。他们的论据是广泛而多样的，几乎都基于神话、谬论和误解，例如“发展和更改数据模型太耗时了。在开始开发报告和其他用户功能之前，你必须完成物理数据模型。”
现实是，对于以数据为中心的系统，没有任何特殊的地方会让敏捷准则无关或者不适当。敏捷实践必须适应挑战，以数据为中心的系统开发必须采用不同的工具集。虽然目前很多关于敏捷概念和技术的书籍直接与数据社区有关，但是它们中的大多数并不直接与数据头脑读者对话。不幸的是，目前的很多敏捷书籍使用最新平台、框架和程序语言，过于狭窄地专注于那些新的、零起点的软件开发。这就很难让读者去推断在这些书中展现的理念，到底是针对数据库开发、数据仓库开发、ERP实施，还是遗留系统的开发。
敏捷作家和数据库专家Scott Ambler撰写了关于敏捷数据库开发和数据库重构（一个敏捷实践）的书籍，以促进数据库社区进行敏捷对话。同样，我写本书邀请DW/BI社区进行敏捷运动，因为敏捷是一个在大型复杂DW/BI系统方面工作得更好的方式。2008年Ralph Hughes的书《敏捷数据仓库》(Agile Data Warehousing)上架销售（Hughes 2008）。Ralph为Scrum和eXtreme Programming（XP）技术适应数据仓库的细微差别做出了杰出的贡献，这其中的大多数概念也在本书中得以展现。此外，本书的目标是深入到很多需要以敏捷方式来开发的技术实践中。
敏捷分析—我的用意是什么
我选择“敏捷分析”(Agile Analytics)这个技术术语，除了它能精确地捕捉我的重点外，更多的是因为它朗朗上口、易于管理。它涵盖了敏捷数据仓库、商业智能和分析包。数据仓库社区使用术语数据仓库指代后端管理和数据分析准备；商业智能指代面向用户的前端应用，从仓库分析展现数据。术语“分析”经常用于表明包含数据定量分析（例如，预测建模、统计分析等）的更先进的商业智能方法。此外，行业术语“商业智能”有时候是一个含糊、包罗万象的术语，包括任何与数据驱动商业流程（商业性能管理、客户关系管理等）或者决策支持（记分卡、仪表盘等）有关的东西。
我使用敏捷分析的称呼并不意味着敏捷方法只适用于某一类面向用户的BI应用开发。敏捷方法对数据仓库开发和商业智能以及分析应用开发都是适用和适应的。对于很多人来说，敏捷BI开发区域更容易想象，因为人们经常想当然地认为数据仓库已经建好了、填充完了。当然，一个已经存在的数据仓库简化了建立BI应用的必要工作。然而，你不应该借此来认为数据仓库必须比BI应用优先完成。实际上，敏捷分析是一个用户价值驱动的方法，高价值的BI能力驱动支持数据仓库组件的进化发展。这样，我们就能避免过度构建数据仓库去支持超过其预期的目的。
在本书中，我主要专注于DW/BI系统的核心—数据仓库。本书中使用的“商业智能”术语或者BI术语应包括分析、报告和查询应用。当使用DW/BI系统术语时，你应该推断我的意思是核心数据仓库和任何供应仓库的性能应用，例如一个财务仪表板、一个预测门户或者其他一些BI应用。然而，DW/BI的首字母缩写有时候会比较笨重，我偶尔可能会单独使用BI。大多数情况下，你应该认为我的意思包含DW。书中也涉及一些先进的BI概念，例如数据挖掘和数据可视化。我把具体BI项目(例如CRM实施)留给读者去推断实践。所有原则仍然适用。
谁应该读本书
敏捷DW/BI团队不仅仅由开发者组成。它包含客户（用户）社区（提供需求）；商业利益相关者社区（监视BI系统对业务改善的影响）；以及技术社区（开发、部署和支持DW/BI系统）。这些社区由一个项目经理、一个业务分析师（或产品负责人）和一个赞助执行人联系在一起。这些社区中的每一个都在项目成功中扮演着至关重要的作用，也都需要一套定义良好的有效敏捷实践。本书将涉及一个或者多个社区的业务和技术读者。
在本书中的一切不是对每个人都有意义，但是有一些内容对每个人都有意义。我和很多组织工作过，他们寻求敏捷训练、辅导和指导。我偶尔会打消敏捷只适于开发者和技术人员的神话。
在一家邀请我去工作的公司里，赞助培训的一个执行者这样说：“如果我们的工程师开始敏捷开发，我们可以更快地完成项目，我们的客户也会更开心。”这句话代表了一些不幸的误解，可能会让敏捷团队扫兴。
第一，成功的敏捷需要所有团队成员的思维有所改变。客户社区成员必须明白他们的时间被要求用于探索和练习新完成的功能，同时提供持续的写入和反馈。管理团队成员必须充分考虑项目风险和不确定性，调整他们的期望，团队也要适应不可避免的变化。技术团队必须学会整个包含大量纪律和严密性的新的工作方式。项目界面社区必须致力于日常项目解决，转变他们的角色，给项目成功做出贡献。
第二，敏捷并不总是意味着更快地完成项目。即使是最好的项目团队在完成的工作范围方面也会有局限性。敏捷实践督导团队，尽早传递高价值和最大风险的功能。因此，敏捷DW/BI系统能够早点推出是可能的，前提是最关键的功能完成并被接受。然而，我建议不要明显加快项目周期，尤其是在开始时。另一方面，相比传统DW/BI开发方法，敏捷能提高质量和客户满意度。
采用敏捷DW/BI成功的底线需要所有上述项目社区的成员的认识、理解和承诺。出于这个原因，我尝试把本书设计为提供一些和大家都有关系的内容。
本书是如何组织的
本书分为两个部分。第一部分侧重于敏捷项目管理技术和团队协作，具体包括以下几章。
第1章提供了DW/BI方法的概述和基线。
第2章介绍了一组有效的实践，包括章程、规划、执行和检测一个敏捷分析项目。
第3章介绍了一组成立一个高度协作项目团队的指导原则和实践。
第4章介绍了故事驱动替代传统需求分析，展现了如何使用案例和用户故事驱使价值持续传递。
第5章介绍了一个团队管理和领导的敏捷风格如何有效地替代传统命令控制风格。
第一部分是写给任何涉及敏捷分析项目的人，从赞助执行人、项目经理到商业分析师和产品负责人，再到技术总监和交付团队成员。这几章建立了一套核心实践，可帮助敏捷项目社区开辟一条道路，一起走向成功。
第二部分侧重于必要的、能够持续传递商业价值并有质量保障的技术方法。这一部分包括以下几章。
第6章展示了进化设计过程是如何工作的，确保产出高品质的数据模型和最小技术债务的系统组件。
第7章介绍了一组自动测试的实践和工具，为了使用一个测试为先的方法，建立数据仓库和商业智能组件。
第8章介绍了一系列保持整个DW/BI系统在版本控制下和配置管理的技术和工具。
第9章展示了如何把测试自动化和版本控制实践组合起来，建立一个持续集成环境，保证不断发展的系统的质量。
第10章包括一些剩余的因素和注意事项，它们对成功采用敏捷分析方法至关重要。
我把这部分作为现代开发实践的集合，这些实践用在每个DW/BI项目上，做到敏捷或者保持传统（例如，瀑布式开发）。然而，当采用敏捷分析方法时，这些技术实践是必不可少的。这些方法建立了最小化但足够的一组必要的技术实践，以成功地持续、渐进和进化地传递高价值的DW/BI系统。
当然，这些技术章节应该由技术团队领导和团队成员阅读。然而，我也建议非技术项目团队成员阅读这几章的每个导言部分。这样做将帮助非技术成员建立对这些实践目的的共识，能欣赏技术团队努力的价值。
本书该怎么读
我认为敏捷分析技术可支持下列要点。
敏捷DW/BI管理：一系列致力于帮助你运行项目的实践，包括敏捷前兆、敏捷项目管理方法、敏捷团队、开发者-用户界面等。
敏捷DW/BI技术方法：一系列实践，致力于开发和传递高价值、高品质、可用的DW/BI系统，包括具体的技术实践，例如故事驱动开发、测试驱动开发、构建自动化、代码管理和重构等。
各章被组织成这些主要部分。每一章专门针对一个关键实践或者一组相关实践，以本章要点的高层概述开始，逐渐深入主题。有些章内容足够丰富，足以成为一本书。在这种情况下，我的目标是让读者对这个话题有坚实了解，并为其深入自学提供动力。
如果你想对敏捷DW/BI有一个高水平理解，那么阅读每一章开头的初步概述就足够了。在这些概述中我的目标是为每一个敏捷DW/BI实践提供一个准确的写照，但是这些部分不讲述所有必要的技术。
如果你是一个数据仓库经理、项目赞助者或者任何需要很好地理解实践而不深入技术细节的人，那么我建议你阅读每一章的中间部分，尤其是项目管理部分。这些部分旨在提供对如何使用这些技术或者理解它们如何用于项目的足够深入的理解。
如果你是一个日常项目团队成员（项目经理、技术团队成员、业务分析师、产品经理等），我建议你阅读每一个项目管理章节（第一部分）的细节和例子。这些旨在给你一组具体的技术，以应用于你的释放规划、迭代集合和所有其他项目管理及用户协作活动。如果你是技术社区的一名成员，第二部分就很适合你。
关于DW/BI技术有一句话：和技术无关。我使用很多技术栈来完成DW/BI的开发，这些技术栈包括IBM DB2为中心、Oracle为中心、SAS为中心、Microsoft为中心以及各种混合技术的技术栈。当某些技术能比其他技术更好地走向敏捷DW/BI时，我深信本书介绍的指导原则和实践是技术独立的，不论你的工具是什么，都可以做到有效。
数据仓库和商业智能工具供应商的数目在不断增加，他们标榜他们的商品为敏捷。前瞻性的供应商的工具和工具组，例如WhereScape、Pentaho和Balanced Insight等提供了成为敏捷的令人兴奋的可能性。虽然我并不相信你一定得使用这些工具才能采用敏捷方法，但是它们肯定给敏捷团队提供了一些巨大的好处。敏捷软件开发社区从这些自动化困难的开发活动的工具中获得了很大的益处，我也期待着我们的社区能够随时从供应商那里获得益处。同时，我会告诫你不要相信在你开始成为敏捷之前，你必须拥有这些工具。相反，我鼓励你以敏捷技术和实践开始，在你确定工具足够有益处时，逐渐地采用该工具。
致谢
没有这些关键人物的贡献，我永远也不会得到我需要写进本书的经验和知识。我尊重和感谢这些朋友和同事，让我和他们有许多非常宝贵的互动，并且得到最终在敏捷分析方法中运用的协作。
首先我的朋友Jim Highsmith是我开始敏捷之旅最信赖的顾问和导师。在我第一次遇见他时，Jim正着手撰写《敏捷项目管理》的第1版，他让协作看起来如此简单，我觉得我也该试试。事实证明，这比看他做要难太多了。每周和Jim的早餐讨论，是我书中概念成形的关键。他自愿担当我的编辑，审查初稿，帮助我把文章变得更具凝聚力和连贯性。Jim不断挑战我的假设，给我新的想法和新的方法来思考开发的复杂性。就算写书不是我的最高优先级时，他也没有放弃。谢谢你，Jim。
Jim介绍我和Luke Hohmann认识，那时Luke正在寻找一个同时具备数据仓库经验和敏捷知识的人。Luke是我见过的最具远见的人之一。我足够幸运成为Luke创新理念的首席架构师：一个复杂的托管企业DW/BI 产品，由Luke的一个客户提供。这个项目的复杂性和Luke深厚的敏捷技术知识，使我（和我的团队）深刻理解了将敏捷软件方法应用于DW/BI开发的精妙之处。本书中的概念源自在后续的项目上已经完善和成熟的经验。7年过去了，Luke已经成为我很好的朋友，我非常珍惜他的智慧和远见。谢谢你，Luke。
上述项目的团队仍然是我经历过的最好的敏捷团队，不论是作为参与者还是敏捷教练。团队成员包括David Brink、Robert Daugherty、James Slebodnick、ScottGilbert、Dan O’Leary、Jonathon Golden和Ricardo Aguirre。每个团队成员都带来了一系列特殊的技能和观点，经过一个三年之久的项目，这些朋友和队友帮我找出为DW/BI开发提供敏捷技术的有效方法。从那之后我有很多和这些朋友共事的项目机会，进一步完善了敏捷分析概念。这些团队成员验证和调整了在复杂和真实情况下的敏捷分析实践，他们功不可没。谢谢你们。
Jim Highsmith还介绍我和Scott Ambler认识。Scott领导了为以数据为中心的系统开发提供敏捷的变革。幸运的是，对于我们所有人来说，Scott是一个多产的作家，无私地在他的书中和他的ambysoft.com网站上，分享他的想法。我从和他的对话以及他的著作《敏捷建模》、《敏捷数据》、《敏捷统一过程》和《数据库重构》（与Pramod Sadalage合著）中获益良多。在早期关注DW/BI中的敏捷的日子中，Scott和我经常感叹我们的观念：数据社区不重视敏捷的益处，软件社区不重视数据库开发和系统集成的独特挑战。Scott花费了很多时间审阅本书。他让我思考很多，和我分享我可能会错过的理念。谢谢你，Scott。
在和Addison-Wesley的编辑Chris Guzikowski与编辑助理Raina Chrobak合作之前，我并不真正了解一个人有“圣贤的耐性”的真实含义。事实证明，我是一个痛苦的、进度缓慢的作家，并不擅长在写作最后期限前应用敏捷原则。非常非常感谢Raina 和Chris，他们非常有耐心，我在最后期限之后才完成协作。希望以后有机会作为作家救赎我自己。
Ralph Hughes的《敏捷数据仓库》在我写本书时上架销售。Ralph和我在那时结识，并成为朋友和同事。感谢他在这个领域的工作、和我进行的讨论以及他分享给我的经验。虽然我尽量不重复Ralph已经出版的内容，但是我深信我们的做法是一致的并且互补。期待在我们的思想成熟发展时，与Ralph合作。
最后，在本书中展现的观点，从愿意审阅初稿的，并给我指导的那些聪敏、深思熟虑的人们身上获益良多。除了Scott和Jim的审阅处，还要特别感谢Jonathon Golden，我的项目自动化大师，以及Israel Gat，敏捷先驱和技术债专家。还要感谢DW/BI专家Wayne Eckerson和Dale Zinkgraf，以及敏捷数据专家Pramod Sadalage为我提供的宝贵意见。他们的贡献是无价的。

“这本书很好地解释了我们在实际中为什么要运用敏捷分析，以及如何运用敏捷分析。Ken从实际运用方法以及改进方法中汲取了很多经验。商业智能领域肯定能从中受益良多。”

——Dale Zinkgraf，资深商业智能构架师

“本书的一个显著特点是涉猎范围广泛——从产品和待办事项管理到敏捷项目管理技巧；从团队自我组织到不断发展的设计实践；从自动化测试到构建管理及持续集成。即便你的项目与分析无关，本书中介绍的面向数据产品的相关内容，其处理方式即使对非分析型团队也非常有用。”

——Jim Highsmith，ThoughtWorks公司执行顾问，《Agile Project Management》作者

“这本书抓住了未来十年商业智能分析项目获得成功的基本策略。Ken Collier已经提升了从业者的水准——你准备好迎接挑战了吗？”

——Scott Ambler，Agile and Lean的首席方法学家，IBM Rational创始人



Collier介绍在平台不可知的情况下整合基础设施的敏捷解决方案，这些基础设施包含不同运作方式、遗留，以及混合了商业和客户代码的专业系统。Collier通过丰富的工作实例展示如何使用广泛的技巧来管理分析开发团队，如何支持巨大的和快速增长的数据量。无论你的项目是“后端（back-end）”的数据管理，还是“前端（front-end）”的商业分析，或是二者兼而有之，本书都将为你实现最优价值提供实用指导。


 第一部分关注敏捷项目的管理技术和团队协作，介绍有助于敏捷DW/BI项目团体进行协作并取得成功的核心实践。
 第二部分侧重于必要的能够持续传递商业价值并有质量保障的技术方法，包括最优设计推进、测试驱动的数据仓库开发、版本控制和项目自动化。

（美）Ken Collier 著：暂无简介

吴陈欣　杨晓丽　罗旭祥　 译：暂无简介

近些年，互联网经济掀起风暴，大大小小的互联网公司一家家出现并迅猛发展。曾经的“只读式”互联网提供给我们很多的内容和很少的功能，我们只在互联网上阅读信息。那个时代已经远去，而今的Web 2.0互联网早已是“可读可写”，我们可以为互联网添加内容，甚至利用互联网来执行任务，实现自己的目标。我们可以在互联网上购买商品、计算房贷利息、预订酒店和机票、搜索问题的答案、分析处理海量数据、下载报表、听音乐、看电影……互联网已完全成为我们生活和工作中不可缺少的工具。随着互联网职能和业务的急速扩充，互联网公司内部的工作方式也发生了巨大变化。传统行业的人员不断地在向互联网转战，互联网从业者的数量达到空前规模。
混迹互联网行业这些年，在实际工作及和同行交流中发现因工作方式导致的不顺比比皆是。拜读Ken Collier的书更是深有感触，书中提及的各种负面做法在各互联网公司普遍存在。项目在需求还未明确时就定了上线时间，或是要求一个需90天完成的项目在30天内完成，只要你在互联网公司外驻足守候，你会发现很多技术人员都在凌晨离开公司。执行团队被要求在项目之初就评估细致的工时，而项目过程中又常发生需求变更，由此导致频繁的返工和加班。执行团队中不同职能的人员互相催赶工作进度，于是需要解释所需的工时。因为互联网常因业绩而追求上线速度，也因为业务量不断攀升，用户通常只涉足前期调研和可用性测试，全程参与项目的情况并不多见。不少管理层在项目全程只简单过问，甚至在项目产出时才第一次提出反馈意见……以上这般种种现象，相信互联网公司的技术同僚们都不陌生吧。
本书中的敏捷项目分析虽然只提到商业智能项目和数据仓库项目，但是其方法广泛适用于互联网中的其他项目，我们推荐所有的互联网从业者（尤其是管理层和执行团队）深入研究并借鉴书中的工作方法。用户故事、用例等这些概念对用户体验从业者来说都不陌生，也希望这些理念能在开发、测试等技术人员当中推广并被接受，这将会让项目大大受益。
感谢机械工业出版社给予我们宝贵的机会来翻译本书，这对我们来说也是一次学习的过程。本书对知识点的讲解十分透彻，引用的实际例子也让我们开拓了思维，看到了国外公司的团队是如何有效运作的。翻译完这本书，我们受益匪浅，希望书中的方法能够惠及各位同行。
最后，虽然我们在翻译过程中慎之又慎并且多次审查，但是书中仍难免存在疏漏和不当之处，恳请读者予以指正。

译者序
序　一
序　二
前　言
第一部分　敏捷分析：管理方法
第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.4.5　敏捷分析的困难14
1.5　FlixBuster分析15
1.6　小结16
第2章　敏捷项目管理18
2.1　什么是敏捷项目管理19
2.2　连续性分阶段的DW/BI开发　　22
2.3　设想—探索取代计划—执行23
2.3.1　设想阶段23
2.3.2　探索阶段24
2.4　改变项目管理角色26
2.5　搞清楚敏捷“口味”的意义27
2.6　敏捷原则28
2.6.1　恰到好处设计29
2.6.2　同步日报30
2.6.3　把每件事都放到时间盒子中30
2.6.4　同处一室的团队32
2.6.5　注重技术债33
2.6.6　计划能力和监控速率34
2.6.7　跟踪每日进展35
2.6.8　监控故事完成，而不是任务时间39
2.7　小结40
第3章　社区、客户、协作42
3.1　什么是敏捷社区和敏捷协作43
3.2　敏捷项目社区47
3.3　信任等级49
3.4　协作机制50
3.5　消费者协作53
3.6　执行者协作56
3.7　决策者协作57
3.8　敏捷先决条件58
3.9　小结59
第4章　BI系统的用户故事61
4.1　什么是用户故事62
4.2　用户故事与需求64
4.3　从角色到用例，再到用户故事66
4.3.1　用户角色67
4.3.2　用例建模69
4.3.3　在事件流中找到用户故事71
4.3.4　用例场景72
4.4　分解叙事文72
4.5　什么是最短小、最简单的用户故事75
4.6　故事优先级和待办事项管理79
4.6.1　基于价值来评定优先级79
4.6.2　基于性能来评定优先级80
4.6.3　评定优先级的过程80
4.6.4　待办事项管理81
4.7　评估故事的分值82
4.8　停车场图表85
4.9　小结87
第5章　自我规划可以提升团队表现88
5.1　什么是自我规划的团队89
5.2　自我规划需要自律93
5.3　自我规划需要责任共担94
5.4　自我规划需要团队工作协议95
5.5　自我规划需要遵守承诺96
5.6　自我规划需要透明开发98
5.7　自我规划需要遵守公司标准99
5.8　小结100
第二部分　敏捷分析：技术方法
第6章　不断发展卓越的设计102
6.1　什么是进化设计104
6.2　需要多少前期设计107
6.3　敏捷建模108
6.4　数据模型模式110
6.5　管理技术债112
6.6　重构113
6.6.1　什么是重构115
6.6.2　什么时候重构117
6.6.3　如何重构118
6.6.4　关于重构最后的话119
6.7　部署仓库更改120
6.7.1　蓝绿部署121
6.7.2　数据库版本化122
6.8　其他采用发展方法的原因122
6.9　案例研究：自适应仓库架构124
6.9.1　产品演变125
6.9.2　架构概述126
6.9.3　观察型消息模型128
6.10　小结135
第7章　测试驱动的数据仓库开发137
7.1　什么是敏捷分析测试138
7.2　敏捷测试框架140
7.3　BI自动化测试143
7.3.1　BI测试过程144
7.3.2　数据库测试工具145
7.3.3　测试什么148
7.4　沙箱开发150
7.5　测试优先的BI开发153
7.5.1　单元测试驱动开发153
7.5.2　故事测试驱动的DW/BI开发155
7.5.3　生成故事测试155
7.6　BI测试指引157
7.7　安装时刻157
7.8　功能性的BI测试158
7.9　小结159
第8章　数据仓库的版本控制160
8.1　什么是版本控制161
8.2　存储库164
8.2.1　什么数据要存储164
8.2.2　什么数据不存储165
8.3　用文件夹来工作166
8.3.1　什么是版本167
8.3.2　打标、分支、合并168
8.3.3　解决冲突169
8.4　组织管理存储库171
8.4.1　注释文件171
8.4.2　目录172
8.5　打标和分支174
8.5.1　什么时候打标和分支174
8.5.2　为标签和分支命名176
8.5.3　保持简单178
8.6　选择有效的工具179
8.7　小结181
第9章　项目自动化182
9.1　什么是项目自动化183
9.2　快速入门185
9.3　构建自动化186
9.3.1　简易自动构建187
9.3.2　更加先进的自动构建189
9.3.3　什么时候开始194
9.4　持续集成195
9.4.1　构建频率195
9.4.2　预设构建196
9.4.3　触发构建196
9.4.4　设置持续集成197
9.5　按钮发布200
9.5.1　什么是发布200
9.5.2　准备发布200
9.5.3　绑定发布201
9.6　小结204
第10章　最后的话206
10.1　专注于真正的问题206
10.2　做到敏捷和执行敏捷207
10.3　粗糙问题209
10.4　新兴技术210
10.5　采用的策略211
10.5.1　可预见的混乱211
10.5.2　领导责任213
10.5.3　目标和商业校准213
10.5.4　敏捷采用路标方式213
10.5.5　培训和辅导214
10.5.6　衡量成功215
10.6　结束语215
参考文献与推荐阅读217