Warren Sifre 是来自于 Allegient 的一位 BI 解决方案架构师,他在博客中分享了关于在数据仓库项目中实现敏捷的观点。他表示,为了实现这一目标,正确的团队组成与心态是必不可少的。
按照 Warren 的说法,一个数据仓库项目包括以下开发任务
- 数据剖析与数据建模
- ETL 开发与单元测试
- 语义层开发与 QA 测试
- 报表生成器开发
这些任务本质上存在着一些相互依赖,如果考虑在项目中实现敏捷,则应当考虑以下问题:
- 在没有完整的数据模型的条件下,如何设计报表?
- 在没有完整的数据模型的条件下,如何开发 ETL?
- 在没有完整的用例列表的条件下,如何设计数据模型?
为了实现敏捷,在项目启动之前必须要作出一些让步。Warren 提出了以下几点建议:
- 数据模型是永远不会一成不变的。
- 在整个项目或某个阶段中,会多次进行完整的历史数据加载。
- 对需求的变更可能会潜在影响你的一切。
- 在整个项目或某个阶段中,必须加入自动化测试开发的任务。
他表示,存在这些依赖的情况下,实施敏捷的关键在于协调,并将项目分解为多个阶段。每个阶段都应当设置一个针对该阶段目标的高层次概述。第一个阶段将对用户故事进行分解,提出验收标准并指出依赖所在。用户故事中还应当包括部署到 UAT 与生产环境所需的时间。将依赖与所需时间结合在一起,就能够得出该阶段所有待办事项的一个逻辑优先级顺序。
Mishkin Berteig 是 Berteig Consulting Inc. 的主席与联合创始人之一,他在最近的一篇博客中分享了他在一个数据仓库项目中实施Scrum 的经验。当时他担任了某个团队的教练,该团队当前的工作是将某个数据仓库从Oracle 迁移到Teradata,该公司为这个项目分配了30 个人。在实施Scrum 方法之前,该团队进行了大量的前期分析工作,并且完成了一份依赖图,其中包含了大约25000 张表、视图和ETL 脚本。这张依赖图保存在一个MS Access 数据库中。
Mishkin 建议该团队不要遵循这张依赖图,而是基于价值开展迁移工作。
我决定对他们基于依赖开展工作的方式提出质疑,因此我与产品经理进行了对话,以探讨是否有可能根据价值对工作进行排序:
- 淘汰 Oracle 数据仓库的许可与服务器,
- 清空磁盘空间、淘汰硬件
- 使用新硬件降低 CPU 占用
Mishkin 和产品经理一同根据商业价值对这个 MS Access 数据库进行了排序,他们对数据库中每项任务按照磁盘空间与 CPU 占用进行了一个非常简单的计算,这个具有 25000 个条目的数据库因而成为了产品待办清单。
Mishkin 要求团队将这些数据仓库表视为产品待办清单中的条目(PBI),并且(在生产环境中)同时运行 Oracle 和 Teradata,并在每个 Sprint 中及时更新,以实现数据在这两个平台中的迁移。该项目从这种方式中受益良多。
经过几轮 Sprint 之后,一共淘汰了 5 个 Oracle 许可。最终,这个为期两年,耗资两千万的项目获得了成功。每个 Sprint 都有新功能提交到生产环境中,并且让 Oracle 和 Teradata 保持同时运行,直到最后一个 Oracle 许可淘汰为止。由于早早地交付了价值,整个项目节约了很大的成本。
评论