敏捷开发技术丛书：《敏捷分析 价值驱动的商业智能和数据仓库系统开发》

[美] 科勒尔（Ken Collier） 著； 吴陈欣，杨晓丽，罗旭祥 译

机械工业出版社，2014年6月出版。

内容简介

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

内容摘读

记住，我们在敏捷分析开始中的目标是频繁发布符合上线质量、可用的软件，接受用户的反馈和验收。在每轮迭代或冲刺结束时，我们发布的软件都应该是符合上线质量的，甚至在胚胎时期就期待它们这样。这个目标需要一套完全不同的方法来确保质量。其中最重要的是在迭代期加入测试工作。

传统的BI开发方法在项目周期接近尾声时强行进行系统测试和验收测试周期。这样的后端测试通常需要手动执行并且很耗时。由于顶着要准时交付产物的压力，后端测试的工作常常做得不充分。我们需要为敏捷分析开发建立一套完全不同的测试标准。

首先，测试必须整合到开发流程里。每轮开发迭代期必须包括测试和质量相关的计划。这么做的优点之一是Bug没有机会在整个项目周期中越积越多，因为质量反馈总是很及时并且频繁地进行，一发现Bug就立刻处理了。测试专家成为开发团队不可或缺的成员，而不是开发周期尾声时的质量把关者。开发者在测试过程中变得不可或缺，他们把有效的测试方法视为个人技术的延伸来学习。每当我向一个新的敏捷团队初次介绍这个概念时，我常常被开发人员这样反驳“没有时间测试”或者“测试不是我的工作”。我总是很想说“如果构建一个高质量的BI系统不是你的工作，那么什么才是你的工作？”一旦测试融为开发过程的一部分，开发者通常会喜欢这样的工作方式。我已经认识了很多这样的BI开发人员，他们都问自己为什么不早点将测试和开发合并。

自动化测试对于集成测试来说至关重要。手动测试不适用于高度迭代的和自适应的开发环境。手动测试有两个关键问题。首先，它太费时了！还阻碍团队频繁地交付可用的软件。依赖手动测试的团队会让测试延期至专门的测试阶段，这就会导致Bug累积。其次，手动测试中的回归测试并不是可以充分重复运行的。虽然我们试图接受并且适应变化时，必须始终确保前面的迭代期里的功能做到“完成！完成！”并让它们在周围变幻莫测的系统里保持高质量。自动化测试在初始阶段需要下一些工夫，然后需要持续努力，但是一旦技术团队掌握了诀窍，他们就离不开它了。

什么是敏捷分析测试？

敏捷分析测试不仅仅是整合和自动化的，它比系统测试更加综合。BI团队把最后的系统测试作为BI开发中唯一需要的测试，我通常感到惊讶。敏捷分析开发者测试每个代码单元、每个集成点、每个数据结构、每个用户功能，以及完整的系统工作，无论它是多么不成熟。单元测试包括BI系统的最低等级组件，比如SQL脚本、ETL模块或者存储流程的测试。集成测试包括测试所有的数据转换点以及BI工具接受或返回数据的地方。当数据从源系统来到临时数据库，或者从临时数据库到多维数据库或OLAP引擎，在数据流入路径上的每个数据结构都必须测试到，以确数据完整性是保持原状或增强的。简单的错误，比如在临时数据库中复制一个VARCHAR（50）的值到VARCHAR（30）的域中，会严重破坏数据的完整性。最终，必须为每个最新开发出来的功能进行精确和接受度的测试。这样它做到了用户想要的、需要的或是期望的了吗？它正确实施了吗？虽然这是终极严峻考验，我们也要确信系统能够在整个过程流中能够运行良好。