BI实施方法论（零星种种）

昨天看一博客http://tdwi.org/Blogs/WayneEckerson/List/Agile-BI.aspx，里面几篇文章都很不错，很切合实际，没有空话。主要讲了三个问题：

1 为了屏蔽源系统的变化，ETL不直接query源系统的表，而是规定接口让源系统导出文本文件。这个没什么新意。

2 通常BI项目人员分为如下团队：需求分析、数据建模、ETL架构开发、测试和维护。每个团队基本独立。我做的第一个项目，也是很大的一个项目（30/一年）就是这种架构。这种组织方式把每一层都隔离开来，可能会产生如下问题：

• 信息经过层层传递之后会失真
• 下一层的人员由于不了解上一层的情况以及最终的需求,往往不能很好的完成任务。比如说ETL开发人员，映射文件写好了，ETL开发人员只需按照映射文件开发就行了，但是映射文件也不可能把所有都描述清楚和仔细了，总有需要ETL开发人员自己思考和拿捏的地方，由于他不知道最终需求，他如何去选择？
• 这种架构方式的假设基础是每一层都能把自己负责的部分做好，而且是一次性的。但这根本不是现实情况，因为需求分析人员也不可能完全正确理解了业务需求，数据建模人员也不一定对源数据完整的探查过并了解各种数据异常。所以最终的映射文件肯定是有很多错误的。这种错误需要不断迭代反馈修改。但是这种明确的分层肯定是不利于很好完成迭代修改的。
• 推卸责任。最好推卸责任的是ETL开发人员，因为刚才所说，前面两层肯定有很多错误的，所以当出现问题并证明确实是前面两层的问题时，ETL开发人员可以理直气壮的说不是我的错，所以即使当发现前两层的错误时，他并没有很强的动力的去提出来。
• 不要测试团队。这个问题又回到ETL开发人员。由于有了测试人员，ETL开发人员对于自己编写的程序不会非常用心的考虑周全，因为后面有测试团队等着。到时正式环境出了问题，也可以推诿说是测试团队没有完成自己的工作。

所以比较好的方式是每个个体都要对需求分析至ETL开发全部负责，或者以小团队方式运作。但是这需要每个成员的能力全面且经验丰富。也许没有完全合适的人员，但是可以按照这种方式运行下去，人员会得到培养锻炼最终成为合格人员。综合起来：这种架构不适合当前乙方盛行的形式，因为很多乙方人员的能力经验欠缺且甲方不可能给予他们一个培养锻炼的过程，另一方面，我觉得也不适合建立数据仓库的初始阶段，适合数据仓库已经搭建起来后的需求增加和变更阶段。

3 就是物理地让业务人员和BI团队坐在一起，叫proximity。

总结起来没有离开Scrum、Agile等概念。