为数据仓库、商业智能和分析 调整敏捷实践
摘要
业务调查显示，不到30%的数据仓库和商业智能（DW/BI）项目能够实现预算、进度和质量方面的既定目标。敏捷方法已被建议作为可能的解决方案，但由于典型的DW/BI项目规模较大，应用敏捷价值观和原则可能存在困难。本文提出了以下研究问题：敏捷实践能否适应DW/BI开发？哪些因素影响敏捷DW/BI开发？通过使用问卷开展了六次半结构化访谈。采用基于实证的理论方法对访谈记录进行编码。分析得出了八个类别：业务价值、项目管理、敏捷开发、共享理解、技术能力、高层管理承诺、复杂性以及组织文化。基于这些类别，提出了一个研究框架。研究发现表明，敏捷方法仅适用于DW/BI项目的某些方面，且需要与项目管理实践相结合以增强效果。
关键词
敏捷、分析、商业智能、数据仓库
引言
商业智能与分析已成为实践者和研究人员的重要研究领域，反映了当代企业组织中需要解决的数据相关问题的规模和影响（H. 陈，江，& 斯托里，2012）。数据仓库（DW）为这一决策支持基础设施提供了基础（阿里亚昌德拉 & 沃森，2010）。商业分析（BA）有助于理解数据中包含的信息，并得出对未来业务决策最为重要的洞察（夏尔达，德伦，特班，& 金，2015）。BA 包含数据挖掘（ DM），后者利用模式识别、统计和数学技术，通过分析和人工智能非平凡地提取隐含的、先前未知且有用的信息（李 & 邵，2001）。商业智能 （BI）结合了架构、数据库、数据仓库、分析工具和应用程序（夏尔达等，2015）。BI 与 BA 或 BI 与分析的定义存在相当大的重叠。本文探讨了为 DW/BI 应用敏捷开发实践，其中 DW/BI 指使用数据仓库的商业智能与分析应用。
研究发现，59%的商业智能项目失败，且不到30%的商业智能项目能够实现业务目标（ http://www.silvon.com/blog/bi‐initiatives‐fail/ 最后访问于2017年8月15日）。森、拉马穆尔蒂和辛哈 （2012）将这些失败归因于数据仓储流程的成熟度不足。Takecian等人（2013）指出，传统的数据仓库构建流程不允许快速和部分交付功能特性，而数据仓库项目高失败率的最重要原因之一是开发周期过长，导致向最终用户交付功能特性的时间延迟。通常，当数据仓库系统最终可用时，已实现的一些功能已经过时，而新的需求则被推迟到后续的开发阶段。巴雷特和巴特（2006 年）指出，"大爆炸"式的数据仓库方法几乎总是以灾难告终，主要原因是数据仓库项目难以良好扩展。商业智能领域也面临挑战，因为需要快速响应每天可能需要分析的大量外部数据（达文波特，巴特，比恩，2012）。
数据仓储项目通常规模较大，且一直难以开发和实施（Sen 等，2012）。在数据仓库/商业智能的早期阶段，平台投资主要集中在由信息技术部门主导的大规模系统报告的整合与标准化项目。这些项目往往具有高度的管控性和集中性，由信息技术部门编写生产报告，并分发给广泛的各类信息使用者和分析师（H. 陈 等，2012），此时采用结构化的方法仍然可行。近年来，数据仓库/商业智能项目的开发面临更多挑战（Collier，2011；达文波特 等，2012）。这些挑战包括项目规模进一步扩大、存储的数据类型更加多样化，其中部分数据通过 NoSQL 系统进行处理 （Sadalage & Fowler，2012）、更广泛的业务用户要求获得更精准的预测能力，以及对更具交互性的分析方式、洞察力的需求增加，再加上动态环境导致需求波动剧烈。
自2001年提出敏捷宣言以来，敏捷开发一直是一个热门讨论话题（Batra,VanderMeer, & Dutta, 2011；Erickson,Lyytinen, & Siau, 2005；Fowler & Highsmith, 2001）。有充分证据表明，敏捷方法可提高软件开发项目的成功率（Ambler, 2012；Sarker,Munson,Sarker, & Chakraborty, 2009；Sheffield & Lemétayer, 2013）。近年来，实践者声称可以采用敏捷方法来促进数据仓库/商业智能（DW/BI）中的敏捷性（Collier, 2011；Hughes, 2012）。Krawatzeck和Dinter（2015）开展了一项文献调查，从四个行动类别------原则、方法、技术和技术------来研究敏捷商业智能。然而，由于敏捷方法传统上用于可由单个团队管理的小型项目 （Dybå & Dingsøyr, 2008），而数据仓库/商业智能开发的项目复杂性较高，因此在数据仓库/ 商业智能中应用敏捷方法的具体机制仍不明确，其适用性也变得值得商榷。本研究提出以下研究问题以解决此问题：敏捷实践能否适应数据仓库/商业智能开发？哪些因素影响敏捷数据仓库/商业智能开发？
下一节讨论了敏捷实践可能需要为数据仓库/商业智能开发进行调整的原因。随后是研究方法论的描述。结果部分提供了从数据分析中得出的类别和子类别列表，以及相关的数据引文。讨论部分将结果与现有文献相结合，并为衡量分析中出现的构念提供了依据。意义部分总结了研究的主要研究发现，并提出了一个研究框架。具体而言，该研究鼓励将敏捷实践与项目管理相协调。
在数据仓库中践行敏捷原则
敏捷软件开发一直是应对小型项目中需求波动的推荐方法（Dingsøyr,Nerur,Balijepally, & Moe, 2012；Fowler & Highsmith, 2001；Nerur & Balijepally, 2007）。敏捷开发主要应用于小型项目（Dybå & Dingsøyr, 2008年），尽管在莱芬韦尔（Leffingwell, 2007）提出适用于大型敏捷项目的框架之后，近年来对规模化敏捷开发的兴趣日益增加（Dikert,Paasivaara, & Lassenius, 2016）。目前尚无充分证据表明敏捷软件开发已被广泛应用于数据仓库/商业智能 领域，而该领域具有数据量、多样性、波动性和真实性同时并存的特点（Phillips‐Wren & Hoskisson, 2015）。在他的书籍中，科利尔（Collier, 2011年，第6页）提出了以下宣言，这是针对数据仓储和商业智能领域对原始敏捷宣言（http://agilemanifesto.org/）的一种变体。
我们通过实践并帮助他人实践，正在探索出开发数据仓储和商业智能系统更好的方法。通过这项工作，我们逐渐认识到以下价值：
• 个体和互动高于流程和工具
• 可运行的数据仓库/商业智能系统高于详尽的文档
• 最终用户和利益相关者的协作高于合同谈判
• 响应变化高于遵循计划
Tha也就是说，虽然右侧的项目有其价值，但我们更重视左侧的项目。
科利尔（2011年）承认，数据仓库/商业智能系统从根本上不同于应用软件，但"尽管如此，敏捷的核心价值观对于数据仓库/商业智能系统的开发仍然非常相关。"该宣言以一句缓和的表述结束："尽管右侧的内容也有价值，但我们更重视左侧的内容"，但这并未说明左侧价值观应比右侧价值观重要多少。从历史来看，重点主要放在左侧的价值观上。
根据格拉泽、道尔顿、安德森、康拉德和什鲁姆（2008年）的观点，《敏捷宣言》经常被解读为：右侧的内容------这些通常出现在过多的计划驱动、合同驱动、标准和审计驱动环境中 的项目------不仅仅是价值较低，实际上被视为毫无价值。数据仓库/商业智能系统属于大型系统，设想在实施可能产生战略影响且成本高达数百万美元（克里希南，2013年）的系统时，完全没有合同和计划是不可想象的。在数据仓库/商业智能背景下，无论左右两侧价值观的相对权重问题仍是一个实证问题，两者都可能发挥作用。
首先，个人与互动相对于流程和工具的比较在某种程度上是次要的。处理大量数据依赖于熟练的工具。例如，如果测试和集成需要自动化------可以认为这能显著提升敏捷性------那么使用工具是不可避免的。术语'流程'似乎与官僚主义相关联，但最终，即使是Scrum和XP（Beck， 2000；Schwaber，2004）等敏捷方法，也是通过遵循流程和工作流来实现纪律性的。因此，在数据仓库/商业智能领域，工具和流程可能与个人和互动同样重要。
其次，数据仓库/商业智能强调对数据的组织和分析，这可能需要文档记录，因为元数据并非自描述。诸如"勉强足够的文档"之类的术语是主观的，可能会误导读者认为几乎不需要或完全不需要进行文档工作。假设一个数据仓库/商业智能项目的原始数据包含数百个表，甚至可能有数千个字段；在这种情况下，大量的元数据需要合理程度的文档记录，其中可能包括描述、来源和版本控制。
第三，大型项目需要合同来保护客户和供应商双方的利益；即使开发是内部进行的，也应有问责制措施以确保资金被有效使用。在数据仓库/商业智能项目中，来自客户或供应商方面的机会主义行为可能比在常规应用中更常见，因为决策支持是一个模糊且无明确界限的概念。像销售订单这样的事务具有合理且定义明确的边界，而预测、预报和灵活报告则可能随着最终用户的意愿而不断扩展。众所周知，用户在说明他们希望从决策支持场景中获得什么方面存在困难（Naumann & Jenkins，1982）。当然，敏捷方法由于快速反馈可能是有益的；然而，可以很容易地想象到不可避免的范围蔓延将如何损害供应商的财务利益，特别是当开发受到固定价格和固定进度的限制时；相反，按时间和人工计费的合同可能会损害客户方的利益。这些看似对立的力量需要取得平衡。
响应变化胜于遵循计划固然是一个值得称赞的目标；然而，大型项目可能需要一定程度的规划 （Boehm & Turner, 2004）。总体而言，在数据仓库/商业智能背景下，这些相互竞争的原则如何权衡尚不明确。敏捷原则被赋予了较大权重朝向敏捷价值观的左侧，关注个体和互动、可运行的软件、客户协作以及响应变化。像数据仓库/商业智能系统这样的大规模项目可能需要包含一些来自敏捷价值观右侧的原则，相应的实践可能更倾向于基于规划的方法。
数据收集与研究方法
采用半结构化问卷（见附录）对敏捷和数据仓库/商业智能文献中提到的关键问题进行分析后编制而成。该问卷用作访谈的引导工具，并在访谈前几天分发给受访者，以便他们有时间思考相关问题。问卷要求受访者报告其在数据仓库/商业智能开发方面的经验，特别是涉及成功或失败的因素。部分问题基于在数据仓库/商业智能开发中应用敏捷价值观和原则的情况。其他一些问题涉及ETL（提取、转换、加载）或处理数据量、多样性、波动性和真实性的问题，其余问题则涉及数据仓库/商业智能开发中的组织和沟通方面。受访者被告知，数据仓库/商业智能还包括分析和大数据等主题，只要与数据仓库/商业智能开发相关，他们可以自由讨论任何问题。访谈者在讨论中保持平衡，以确保基本覆盖所列问题，同时允许受访者自主选择深入探讨某个特定问题的细节。
决定根据开发是内部（即在公司内部）还是外部（即涉及客户‐供应商安排的外包）来选择两类企业。从位于美国波士顿的一家医疗中心（企业A）中选择了两名受访者R1和R2。该机构是全国领先的学术性医疗中心之一，并与一所顶尖医学院相关联。该机构因其在健康信息技术领域的领导力而获得高度评价，拥有超过1000名全职医务人员。受访者R1是首席信息官，R2是该医疗中心的商业智能主管。受访者R3是一家位于美国东南部的企业（企业B）的软件开发主管，他还负责管理该公司的数据仓库/商业智能项目，并开展敏捷开发培训。受访者R4拥有博士学位，在数据仓库/商业智能领域拥有16年经验，是一家位于西部地区的大型服务公司（企业C）的高级数据科学家。受访者R5（企业D）在软件开发方面有6年的敏捷相关经验，在数据仓库/商业智能方面有两年经验。他目前在一家总部位于波士顿的大型国际银行的私人银行分部工作，工作地点位于美国东南部。在访谈时，受访者R6（企业E）正担任一家管理美国东南部大型机场的政府机构的商业智能主管。企业A、D和E从事内部数据仓库/商业智能开发，而企业B和 C则为外部客户进行开发。
根本的研究问题涉及识别适用于数据仓库/商业智能（DW/BI）环境的软件开发实践。当缺乏理论框架或关键类别时，首选的方法是进行基于实证的理论研究（Corbin & Strauss, 2014; Glaser, 1992）。本研究采用改进的基于实证的理论方法中的开放编码和轴向编码方案（Corbin & Strauss, 2014），以识别类别和子类别。在此，理论开发被理解为指一组经过充分发展的类别（主题、概念），这些类别通过关系陈述系统地建立并解释其属性和维度，并相互关联（Hage, 1972）。尽管本研究并未提出一个具体的理论，但在结论部分提出了一个初步的研究框架。
马塔维尔和布朗（2013）讨论了采用基于实证的理论方法的不同方式，并指出所有基于实证的理论研究项目的共同点是：在一个普遍感兴趣的研究领域中进行探索，而无需非常具体的研究问题或假设。基于实证的理论采用持续比较法，要求将数据分解为可管理的部分将每个部分进行比较，找出其相似性和差异性（Corbin & Strauss, 2014）。性质相似的 数据 被归入同一概念标题之下。持续比较要求在生成 概念 的同时，研究者不断比较 指标 ，以完善逐步形成的概念（Adolph, Hall, & Kruchten, 2011）。在 开放编码 阶段， 指标 被赋予临时的概念名称。随着 编码 的继续以及对 指标 的审查，概念名称将根据相似性进行比较。一个 指标 可能是一个句子、一段文字，或代表一个 编码 单元的多个段落。在 主轴 编码 阶段，名称相似的概念被归为一组，并赋予 类别 名称。相似的 类别 进一步被归入更高层次的 类别。
所有受访者均不反对使用敏捷方法，但每个人都对方法论、组织、技术、需求和沟通方面的问题发表了看法，并引用了相关言论加以说明。分析中出现了一个核心类别------情境化敏捷。在数据仓库/商业智能领域，情境化敏捷意味着多种情境因素会影响竞争性敏捷价值在特定数据仓库/商业智能项目中的应用程度。结论部分提出了关于情境化敏捷的研究框架。
结果
通过NVivo分析得出了八个类别：业务价值、敏捷开发、共同理解、复杂性、项目管理、技术能力、高层管理承诺以及组织文化。每个类别包含两到四个子类别（见表1）。需要注意的是，某些类别如组织文化更侧重于敏捷开发，某些类别如高层管理承诺更侧重于项目管理，而某些类别如复杂性则与敏捷开发和项目管理均相关。
业务价值
所有受访者都强调了业务价值的重要性，这在NVivo分析中被提及的次数最多。事实上，一位首席信息官受访者R1提到，波动性、真实性、数据量和多样性这四个V都可以管理，而唯一具有挑战性的V是业务价值。
R1:我唯一关心的V是价值。
R4: 价值非常、非常关键，你必须让客户持续相信项目及其能够交付的价值。因此，如果客户开始怀疑（价值），那么这就是一个危险信号，表明项目将无法完成。
优先级排序
通过优先级排序可以实现价值，优先级排序在项目内部以及跨项目中都非常重要，它体现了客户在预算、进度、需求和质量方面的偏好。受访者R2提到，由于预算和人员可用性问题，他们只能开展有限数量的项目。受访者R3强调了优先级排序的重要性，并指出项目规模并不重要，而成功与失败的概念可能较为模糊，因为不同的利益相关者可能对最终产品的结果评估不一致。
R3:从本质上讲，商业智能非常主观。我查看一个仪表板时，我希望采取某些行动；而你查看同一个仪表板时，可能会希望采取不同的行动。我不认为所有的商业智能项目都可以简单地划分为成功或失败。也许只是某个常见的指标缺失了，而提出该意见的人------归根结底，那也只是个人观点而已。
另一个问题是客户可能有不切实际的期望。正如受访者R2所言，提出需求容易，但实现起来却很难。
R2:然后我们有更多的额外请求，但这些项目更多是由业务方推动的，但他们没有意识到或理解其中的挑战或技术部分。他们期望的速度比我们快，而我们交付他们所要求的内容又显得太慢，并且也没有一种能够应用的方法论，从项目开始到结束提供良好的支持，以确保在时间表内完成。很多时候，这些项目都超过了截止日期。
运营与分析的和谐
受访者R1更关注分析对运营的支持能力。他不确定其企业中的数据仓库是否能交付价值，除非能够将其整合到工作流中，例如医生与患者互动时的工作流程。他认为，传统的数据仓库和商业智能处于一种旧的范式中，将运营和分析视为分离的。
| 维度 | 维度的操作化定义 | 子维度 |
|---|---|---|
| 业务价值 | 一种持续考虑的思维方式 利益相关者收益超过成本的部分 | 优先级排序 |
| 业务价值 | 一种持续考虑的思维方式 利益相关者收益超过成本的部分 | 运营分析和谐 |
| 敏捷开发 | 价值、原则和实践源自 敏捷宣言 | 迭代开发 |
| 敏捷开发 | 价值、原则和实践源自 敏捷宣言 | 业务‐信息技术协作 |
| 敏捷开发 | 价值、原则和实践源自 敏捷宣言 | 响应变化 |
| 敏捷开发 | 价值、原则和实践源自 敏捷宣言 | 方法论适应 |
| 共同理解 | 在不同利益相关者之间就问题和 问题达成共同理解 | 模糊性 |
| 共同理解 | 在不同利益相关者之间就问题和 问题达成共同理解 | 领域知识 |
| 共同理解 | 在不同利益相关者之间就问题和 问题达成共同理解 | 发现 |
| 项目管理 | 规划和行动，以促进目标的实现 项目 | 合同 |
| 项目管理 | 规划和行动，以促进目标的实现 项目 | 管理范围蔓延 |
| 项目管理 | 规划和行动，以促进目标的实现 项目 | 管理期望 |
| 项目管理 | 规划和行动，以促进目标的实现 项目 | 文档 |
| 技术的 能力 | 设计、开发和实施的能力 | 开发工具 |
| 技术的 能力 | 设计、开发和实施的能力 | 架构 |
| 技术的 能力 | 设计、开发和实施的能力 | 灵活设计 |
| 高层管理 承诺 | 高层管理对项目的承诺 通过提供资源、领导者、治理 结构，并解决由此产生的问题 部门数据孤岛引起的问题。 | 领导力 |
| 高层管理 承诺 | 高层管理对项目的承诺 通过提供资源、领导者、治理 结构，并解决由此产生的问题 部门数据孤岛引起的问题。 | 管理数据孤岛 |
| 高层管理 承诺 | 高层管理对项目的承诺 通过提供资源、领导者、治理 结构，并解决由此产生的问题 部门数据孤岛引起的问题。 | 治理 |
| 复杂性 | 由于组件间高度交互以及 组件之间的不兼容性引起的困难 | 数据集成 |
| 复杂性 | 由于组件间高度交互以及 组件之间的不兼容性引起的困难 | 数据质量 |
| 复杂性 | 由于组件间高度交互以及 组件之间的不兼容性引起的困难 | 缺乏协调 |
| 组织文化 | 基本假设和共享的核心价值观 | 自主性 |
| 组织文化 | 基本假设和共享的核心价值观 | 透明度 |
| 组织文化 | 基本假设和共享的核心价值观 | 灵活思维 |
R1:作为一名信息技术领导者，我认为如果我们继续用旧的范式来思考这个问题，将是一种错失良机⋯⋯我需要让我的核心开发人员在运营系统本身中发现分析的价值。
敏捷开发
鉴于问卷关注的是敏捷价值观和原则，敏捷开发成为一个重要的类别并不令人意外；然而，它并未成为压倒性的主导类别，因为许多受访者认为，仅靠敏捷方法本身并不是最重要的考虑因素。此外，受访者并没有盲目地认同这些价值观和原则，而是对许多价值观进行了适当的调整。采用Scrum的受访者R3提出了一种独特的敏捷开发视角，使用60‐40或 70‐30的经验法则来权衡相互竞争的敏捷价值观，并用于规划交付成果的范围。受访者R5和 R6则认为数据仓储方面更偏向于以计划为导向，而业务智能和分析方面则更偏向于敏捷导向。
R5:特别是商业智能的报告和分析，具有很大的敏捷应用范围。
R6:我们最初是从数据仓库的开发开始的。因此，我们在这一方面投入了大量工作。而这种开发更多是采用标准开发方式，而非敏捷开发，因为我认为数据仓储需要更多的规划，而且由于数据量庞大，如果需要进行更改，流程会更慢。例如，如果你必须修改ETL，或向数据仓库添加之前未规划的内容，就会耗费更多时间。
迭代开发
受访者R3、R5和R6认为迭代开发很重要。来自医疗中心的受访者R1和R2未过多讨论迭代开发。受访者R4认为迭代开发很重要，但认为两到三周的迭代周期过于严格。然而，所有受访者均认为在数据仓库/商业智能中实施迭代开发是可行的。
R4:所以这是敏捷的另一个方面，我并没有看到期望能在四到六周内交付成果。因此，似乎天平已经过度偏向了另一端。以前会有持续两三年的项目，那样不好；而现在天平又完全摆向另一边，要求每六周就必须交付一次成果。这对软件来说是可行的，但对于数据相关的项目，如数据仓储、数据库、数据科学或分析项目，则并不适用。
业务与IT协作
受访者R2、R3和R4从传统意义上理解业务‐IT协作。然而，首席信息官R1对业务‐IT协作的看法更为广泛。他认为，IT人员与业务人员之间的联系需要制度化，并消除障碍，以避免各团队陷入各自的功能专业化之中。他希望看到跨职能的协作能够自然形成，而不是被迫产生。
应对变化
受访者 R3 提出了一个独特的视角，来应对即便是在开发后期发生的变化。他提出，在许多软件开发情境中，60‐40 或 70‐30 的经验法则都是适用的。例如，这些比例可用于衡量敏捷宣言左侧价值相对于右侧价值的重要程度。此外，
方法论适应
除R3外的受访者并不遵循严格的敏捷开发。这并不是因为他们不认同敏捷价值观，而是他们认为方法论只是开发流程中的一个输入因素，而该流程本身面临许多重大挑战。敏捷开发可以发挥作用，但必须根据具体情况进行调整。
R6: It was not an 有条理的 type of Scrum -- 那里没有 团队 that were 正式地 已识别。
R2: And the 方法论 is 不断发展的， and 那就是 more 创新的 and 创意 因为 再次 if 如果我在自己的任何项目上都局限于使用敏捷或Scrum或其他任何敏捷方法论， 那么我可能无法成功交付想要实现的目标。因此，我必须保持灵活，必须另辟蹊径，必须提出不同的方法论和不同的方式。我们可能会采用敏捷方法论中的一些片段，但并不意味着要在整个IT或业务工作流程中强制实施完整的敏捷流程。这可能是一种多种方法论的混合模式。
共同理解
尽管共享理解有可能被视为业务‐信息技术协作的一个方面，但在本研究中其重要性足够显著，因而成为一个独立的类别。实现共享理解凸显了沟通的重要性。
模糊性
模糊性被提及为一个必须解决的常见问题。在医疗保健行业，由于广泛的编码、法规、规则和逻辑，可能会产生模糊性。受访者R3提到，模糊性可能在任何情况下出现，但通过有效的沟通可以解决。
领域知识
在医疗保健等知识密集型行业中，共同理解的问题会变得更加严重。领域的复杂性可能导致共同理解方面的问题。一个专业可能需要十年时间才能掌握。在医疗机构中，医生们专注于人体不同系统的诊疗。而开发人员在努力跟上自身职业发展的同时，可能会发现医疗保健领域带来的额外要求令人望而生畏，尤其是在试图理解和满足用户需求时。
R2:我们不是医生，因此他们可能会使用一些需要字典才能理解的缩写词。他们可能会说，"给我糖尿病、糖尿病患者、高血压、心力衰竭的指标"，然后就走开了。但当你收到这个请求时，这并不明确表示存在一个包含所有患者的列表，其中一列标注为"糖尿病"，另一列标注为"心力衰竭"。它可能指的是某些诊断代码，特定的诊断代码，而不是完整的诊断代码。
发现
发现会议是在与多位利益相关者进行互动交流并达成共同理解后，对项目做出的初步高层次阐述。受访者R3是一位敏捷爱好者详细规划了发现流程，这也有助于他们进行估算。该流程表明，敏捷开发具有很强的纪律性，可用于数据仓库/商业智能开发。
R3:作为团队的一部分，我们首先会问的问题是："嘿，各位，让我们来做一次发现会议，讨论一下你们希望我们构建的内容。"因此，我们会花两天时间，从高层面对这些内容进行罗列。无论对方有什么想法或愿景，我们都会让他们对其进行优先级排序。一旦问题陈述写好后，你就可以开展这次发现会议，以识别出其中所有的依赖关系以及各个功能或可交付成果。
项目管理
敏捷开发的支持者通常会略过项目管理这一话题。数据分析表明，在数据仓库和商业智能的大型项目领域中，项目管理是一个关键因素，能够缓解敏捷开发的风险。尽管项目管理包含多个方面，但本研究中凸显了四个关键因素：合同、管理范围演化、管理期望以及文档。需要注意的是，这些因素强化了敏捷价值观中右侧内容的重要性。实际采用的数据仓库/商业智能方法论由源自敏捷开发与项目管理相结合的一系列实践构成。
合同
受访者R3是一位敏捷倡导者，他用60:40的经验法则总结了协作与合同的关系------协作固然重要，但这并不意味着合同不重要。没有合同，客户和供应商都无法感到安全，而安全感是建立信任与协作的前提。
R3:但根据客户的许可，我完全有权终止项目或扩大范围。比如，如果我们已经花完了所有资金，那么我们会暂停下来，然后询问客户：您认为当前的范围足够了吗？如果客户回答：不，我们还需要更多。好的，那么我们将如何支付呢？⋯⋯优先级是，我们要有协作，要明确对客户最有价值的内容，并交付这些内容。但这一切都由合同指导。我们必须有法律保障；否则，客户可能会直接拿走产品并离开。
管理范围的演变
内部处理项目的受访者并未抱怨范围蔓延。许多人认为范围蔓延是数据仓库和商业智能不可避免的副作用。事实上，受访者R2提到，他不会孤立地或临时性地看待一份报告。如果某份报告对一个部门或分部很重要，那么它很可能对其他部门也很重要。因此，他们成立了一个团队来运行价值驱动的"分诊系统"，该系统评估请求并尝试建立各个请求之间的关联。有时项目会自行发展，远远超出预期范围。由于关注业务价值（即重视收益而非成本），这种扩展并不总是被视为问题，尽管范围仍需管理。然而，代表外部合作中供应商一方的受访者R4则遇到了范围蔓延的问题，并将其归因于其销售团队签订的有缺陷的协议。
R4:因此，那些项目未成功的原因之一就是范围蔓延，即供应商和客户之间对于承诺内容的理解存在差异。通常情况下，销售人员几乎会同意所有要求，然后一旦合同签署，他们就拿到了销售佣金。接着，像我这样的人就要去交付了。而这正是问题所在当我们开始提出问题并试图更详细地定义事物时，一些问题就会浮现出来。
管理期望
正如受访者R4所暗示的，需要对期望进行管理，否则客户将期望供应商盈利范围内无法交付的内容。敏捷原则强调即使在项目后期也要响应客户发起的变更，但这一原则是有限度的。在内部项目中，由于缺乏合同，可能导致超出初始范围的大量变更请求。这正是许多受访者不信任敏捷软件开发某些方面的原因。受访者R2认为敏捷开发是以计划为导向的，并对时间表和工作有合理的定义。这种情况或许是因为敏捷通过分配特定周期来强化纪律性，在此期间开发团队不受变更和外界影响的干扰。
文档
文档在敏捷开发领域中名声不佳；然而，对于数据仓库/商业智能项目而言，文档具有一定的重要性。受访者R3提出，嵌入代码中的文档是更受青睐且无缝的方法。在医疗保健等复杂领域，正式的文档可能是必要的。总体而言，在本研究中，文档并未成为一个关键因素。
技术能力
敏捷宣言的价值观之一强调个体和互动胜于工具和流程。互动对于达成共同理解显然非常重要。然而，本研究的结果表明，工具不仅重要，而且是管理数据仓库/商业智能系统日益增加的复杂性的手段。
开发工具
受访者R5强调了工具的重要性，并将其列为关键成功因素。
R5:我们的主要工作是获取许多报告并与数据一起工作。因此，我们需要大量工具，这些工具无疑是我们的团队成功所需的重要因素之一。
根据受访者R1的说法，诸如NoSQL软件等新兴工具对数据仓库和商业智能开发产生了重大影响。由于这些工具基于不同的范式，不仅数据仓库/商业智能部门，整个信息技术部门都需要发展技术能力以挖掘其业务价值。市场正在提供更广泛的工具，以加速数据仓库/商业智能的开发并处理各种类型的数据。
R1：我认为，如果回顾IT领域内行业以往的运作方式，企业一直采用某种特定的开发方法论和存储架构。如今，谷歌、脸书和亚马逊等公司已经开发出自己的后端存储平台，彻底改变了这一格局。因此，只要我们选择了正确的平台，海量数据完全不会让我感到畏惧。像DynamoDB、MongoDB这样的平台能够处理大量结构化和非结构化数据，并能在毫秒内完成处理，从而将其价值集成到我的运营系统中。
架构
在小型敏捷项目中，架构可能并不重要，但在数据仓库和商业智能领域，必须提前规划架构，以建立一个增强敏捷性的基础。受访者R3介绍了他的企业对敏捷方法的调整，其中包括在启动由其改进版Scrum所管理的冲刺之前，设置一个分离的架构阶段。
灵活设计
数据仓库和商业智能面临的挑战之一是实现灵活设计。开发人员需要预见超出有限报告集的潜在报告生成需求。换句话说，该设计需要具备适应性。
R2:我可能会将其链接到一些实际的访问类型------可能从其他系统获取一些额外的数据。因此，从一开始就了解这一点或明确知道此项目的范围，有助于我们构建更具动态性的数据仓库，即能够适应变化和新请求的数据仓库。
高层管理承诺
数据仓库和商业智能项目通常拥有较大的预算，因此会受到高管层的关注。如果没有首席信息官或发起人的支持，数据仓库/商业智能项目可能会停滞不前。因此，无形因素，尤其是在高级管理层方面的因素，在确保项目成功方面起着重要作用。这些因素与项目的管理层面相关，而非编码方面。
领导力
数据仓库/商业智能项目可能需要一位倡导者，他能够激励团队、提供资源、协商立场，并在情况偏离正轨时保持承诺。领导力是一个关键因素，特别是当项目具有战略价值时。
R4:该项目在两年半后被放弃，因为在项目进行到两年时，主要的执行发起人（一位高级副总裁）转到了另一家银行。这才是导致项目终止的原因，而不是因为人们意识到这个项目行不通。当时我们仍在努力推进项目，但一旦这位执行发起人离开，六个月之内项目就逐渐停滞了。
管理孤岛
对于受访者R4而言，孤岛效应是最大的障碍。敏捷开发可以解决仅限于项目开发方面的问题。然而，项目是一种社会技术现象，项目的社会层面有时可能超出任何方法论的范畴。例如，如果项目需要不同组织单位之间的合作，但这些单位没有共同工作的积极性或协商意愿，那么开发方法论就无法解决这一问题。
R4: 因此，如果项目复杂性本身是一个问题，那么像敏捷这样的方法论就会奏效，但它无法克服一些其他组织问题。例如，如果某些相关方对该项目成功没有太多激励，那么敏捷就无法克服这种阻力。
治理
由于数据仓库/商业智能项目的规模较大，建立针对行动和问责制的制度化规则非常重要。依赖临时性规则应对特定情况是低效的。缺乏通用的被接受的规则可能导致无政府状态，从而造成缺乏合作、协调和问责制。敏捷开发可以通过纳入治理框架的指导方针而受益。
R1:治理是信息技术中最被低估的成功因素之一。每当我审视任何一个组织或刚开始进入一个组织时，我几乎首先想要解决的就是治理问题。治理就像氧气一样。我认为，没有治理，我们将寸步难行。
复杂性
复杂性的来源有很多。明显的是四个V：数据量、速度、真实性和多样性。令人意外的是，受访者并未将数据量视为关键的复杂性因素。数据集成类别涉及数据的多样性以及各种请求。数据质量关乎真实性，也可能导致数据集成问题。此外，还有一些组织的因素阻碍了数据的共享。
数据集成
根据受访者R2的说法，他的医疗中心在数据集成方面的问题相当严重，以至于敏捷方法论无法奏效。他认为数据仓库/商业智能项目不仅涉及数据集成，还涉及协调各种请求。由于需要与不同人群打交道所带来的复杂性，使得应用敏捷方法论变得困难。
数据质量
相关的问题是数据质量。例如，如果每个部门都有其自身的客户标识方法，那么要开展涉及跨部门分析的工作将会很困难。
R4: 因此，商业智能系统相关人员已经讨论了至少15到20年，但在本案例中，却没有一个标识符------客户级别的标识符。系统中没有任何内容可以表明这是您的信用卡账号，这是您的银行客户识别号。完全没有。因此，这又是一个巨大的挑战，因为缺乏统一的客户视图。每个孤岛拥有多个数据仓库、多个数据库，而这些数据存储彼此之间并不互通。
缺乏协调
此子类别与管理数据孤岛的问题相关。然而，缺乏协调是一个组织问题，主要源于多个利益相关者之间的依赖关系。如果存在不愿合作或缺乏与利益相关者合作的积极性，协调问题可能会加剧。
R4:首个成功的项目的复杂性------我们可以分阶段进行，比如先做国家A，然后是国家B、区域 C，以此类推。然而在这个项目中，尽管只涉及美国，但银行内部却有五到六个不同的部门或数据孤岛。这些数据孤岛之间没有协作，我认为项目之所以失败，是因为存在这些不同的相关方，而它们本应共享数据。正是由于银行内部不同数据孤岛之间缺乏协调，导致了项目的失败。该项目在两年半到三年后被放弃。因此，并不是我们没有尝试；我们实际上努力了两年半以上。
组织文化
数据所有权可能因信息所带来的权力而引发地盘意识；因此，各部门可能不愿意放弃数据。此外，业务和信息技术部门可能各自拥有专业知识和偏见，从而妨碍协作。放弃数据、跨部门合作以及与来自不同领域的人协作可能会产生摩擦和冲突。有时，仅靠治理是不够的，还需要组织文化的根本转变，以防止此类冲突并促进共享。
自主性
在设定行动规则和问责制的总体治理框架内，应给予人员足够的自主性，以增强赋权感和主人翁意识。自主性还能激发创造力，帮助人们提出创新的解决方案。
R1:你必须发挥团队成员的优势；必须理解他们的思维方式。然后退后一步，给予充分的自主空间和授权，不要试图强加解决方案，而是尽量让他们直面问题。
透明度
业务部门是数据仓库/商业智能项目中的重要参与者，必须积极参与。信息技术部门需要在各个方面对业务部门保持透明度，以便业务方能够信任信息技术方，并有意义地参与创造业务价值。透明度不仅仅是治理问题。
R1:通过向我们的业务用户明确告知有限的IT资源具体花费在哪些地方以及这些资源正在用于哪些项目，我们已经将透明度提升到了极致。
灵活的心态
几十年前，信息技术部门占据主导地位，业务部门不得不主动寻求其支持。信息技术人员是高技能的专业人士，有时这种成就感可能导致僵化，进而影响与业务部门的协作，而这种协作对于从数据仓库/商业智能项目中实现价值至关重要。数据仓库/商业智能开发团队在内部应对开发复杂性的同时，需要将业务部门视为平等的合作伙伴。
讨论
定性分析所确定的类别揭示了几个可能影响敏捷方法论应用的情境因素。受访者中没有人对使用敏捷方法论表示异议，但在大多数情况下，实际采用的方法论是一种变体，该变体基于情境因素考虑了相互竞争的敏捷价值的两个方面。与右侧相关联的项目管理问题同样重要。根据对 emergent 类别的审查，建议将一个核心类别------情境化敏捷------作为数据仓库/商业智能领域开发实践的代表。上下文对于数据仓库/商业智能开发至关重要，因为项目的更大复杂性和组织覆盖范围会影响敏捷开发与项目管理之间的协调。
多个受访者提到了组织方面的问题，尤其是R1、R2和R4；技术问题被R1、R5和R6强调；方法论问题由R3突出；领域知识问题则由R2提出。对于处于分析前沿的人员而言，开发工具受到青睐。总体观点认为，敏捷开发在商业智能方面更有用，而项目管理在数据仓储方面更有用。接下来的讨论试图整合本研究的研究发现与文献相结合，以便为构念的测量提供概念基础。此外，讨论部分为下一节提出的框架提供了桥梁。
商业价值
本研究中被引用最多的因素是业务价值，指的是预算、进度、质量、满意度和需求实现等传统衡量指标。许多研究人员都强调了业务价值在分析领域的重要性（Kiron & Shockley, 2011；LaValle, Hopkins, Lesser, Shockley, & Kruschwitz, 2010），因为数据仓库、商业智能和分析项目成本较高。然而，项目成功有时具有主观性，因为不同的利益相关者会从各自的角度看待业务价值。一个数据仓库/商业智能开发工作，如同其他软件项目一样，可以通过包含客户满意度、与战略目标的一致性、成本、进度、团队满意度和质量等指标的仪表板进行评估（Siau, Long, & Ling, 2010），而这些指标有时可能相互冲突，或被不同的利益相关者以不同方式评判（McLeod, Doolin, & MacDonell, 2012）。
此外，根据A公司首席信息官的说法，如果分析与运营相分离，业务价值将会降低，因为医疗保健的节约、以患者为中心的护理以及错误预防都发生在医疗专业人员与患者互动的过程中。拉瓦勒等人（2010）报告称，表现最佳的组织利用分析来指导日常运营的可能性是其他组织的两倍。
敏捷开发
鉴于问题的性质，敏捷开发作为一个重要类别出现并不令人意外。然而，正如实证文献中所观察到的（Cao, Mohan, Xu, & Ramesh, 2009），必须对开创性文献（Fowler & Highsmith, 2001）中规定的敏捷价值观和原则的许多基本假设进行适当调整。例如，尽管迭代开发的作用得到了认可，但受访者建议采用更长的迭代周期，这一点在实践者文献中也已有提及（Couture, 2013年）。在客户‐供应商合作中，协作是在合同框架下进行的（Lacity, Khan, & Willcocks, IN）。
关于敏捷宣言，由于响应性需求与项目规模之间的冲突，敏捷价值观的左侧与右侧之间存在一种拉力。自敏捷方法论被考虑用于较大项目以来，这种平衡行为一直是一个问题（Batra, Xia, VanderMeer, & Dutta, 2010；Boehm & Turner, 2004；Glazer et al., 2008年）。其中一位受访者针对许多项目问题采用了一种60:40规则，包括如何权衡敏捷价值观的左侧与右侧；因此，应对变化的权重将高于规划，但两个方面的价值观都会被考虑。右侧价值观的重要性表明了项目管理的重要作用。
项目管理
敏捷方法通常回避项目管理问题（Turk, France, & Rumpe, 2005）。软件开发需要进行管理，因为在为客户创造价值的过程中，项目必须满足信息技术的预算和进度要求，即使该项目是公司内部的（McLeod & MacDonell, 2011年）。当供应商和客户为外部相关方时，合同管理等问题在大型项目中变得尤为重要（Lacity 等, 2009）。如果没有一个明确客户期望的发现流程，在商业智能中使用合同可能会具有挑战性（Larson & Chang, 2016）。可能需要实施能够平衡客户与供应商相互竞争利益的合同（Larman & Vodde, 2010; Pilios, 2015）。通常的问题不在于需求变更是否可以解决，而在于额外成本将由谁承担以及如何核算（Pilios, 2015）。
范围蔓延在较小的软件开发项目中并不一定是不良现象，但在数据仓库/商业智能外部项目中需要加以管理，因为这会带来成本影响；在数据仓库/商业智能内部项目中也需要管理，因为必须对临时请求进行评估，以确定是否涉及其他利益相关者可能会从新的需求中受益。即使在内部项目中，也需要管理期望，因为从业务方看来似乎是一个简单的请求，但从信息技术角度来看，由于存在依赖关系和其他利益相关者的参与，可能变得非常复杂。敏捷开发需要结合各种情境因素与项目管理相协调。业务价值可以被视为敏捷开发与项目管理保持一致所带来成果的结果。
共同理解
文献中广泛支持共享理解；例如，Arias、Eden、Fischer、Gorman 和 Scharff（2000）指出，在大规模软件开发中，对人类、社会和文化系统的理解非常重要，利益相关者之间的共享理解对于协作设计至关重要。沟通对话视角（艾森伯格 & 古道尔, 2004）提出了对话的三个主要观点：公平事务、共情对话和真实会面。这三个观点均属于共享理解这一大类别。公平事务提供了一种沟通视角，使所有参与者都有能力表达自己的意见和观点。共情对话是指能够理解或想象他人所理解或想象的世界。真实会面则是超越角色或视角的人与人之间的真实交融。
本研究中出现了共享理解的三个子类别：领域知识、模糊性和发现。在某种程度上，这些子类别对应于三种沟通对话视角。领域知识差距可以通过共情对话来解决，而发现则可以通过真实会议最大化。模糊性可以通过公平事务来解决，尽管其他两种对话视角也可以发挥关键作用。共享理解应能同时提升敏捷开发和项目管理（Batra, Xia, & Rathor, 2016；McLeod & MacDonell, 2011）。
技术能力
在敏捷开发中，工具相对于个人和互动处于次要地位（Larman，2004）。然而，当代的分析环境正受到工具可用性的显著影响（Russom，2013年）；例如，基于Hadoop的库和 NoSQL数据库管理系统日益普及，为某些应用提供了成本更低、速度更快的方式来实现更高的价值（Sadalage & Fowler，2012）。由于集成这些工具所需的多样化技术和技能组合，建立IT基础设施变得更加困难。以业务为导向、可扩展且灵活的技术框架是商业智能项目成功的关键因素（Yeoh & Koronios，2010）。
研究显示，信息技术能力和组织敏捷性具有积极影响（Lu & Ramamurthy, 2011年）。信息技术能力已通过三个子类别进行衡量：IT基础设施能力、IT业务覆盖能力以及IT主动立场（Lu & Ramamurthy, 2011年）。IT基础设施能力主要通过技术和工具因素来衡量。在利用新技术提升业务价值方面，拥有具备相应技能的IT人员尤为关键。此外，IT基础设施的灵活性对组织敏捷性具有显著影响（X. 陈 & 邵, 2012）。因此，敏捷价值观中提到的"个体和互动"与"流程和工具"之间的相对侧重开始变得模糊。因此，工具应增强数据仓库/商业智能开发中的敏捷性。
高层管理承诺
坚定的管理层支持与赞助是商业智能项目的关键成功因素（Yeoh & Koronios, 2010）。战略层面的无形因素会影响企业的绩效（Teece, Pisano, & Shuen, 1997年）。敏捷实践关注战术性因素，但由于这些方法最初应用于小型项目，因此未包含战略问题。数据仓库/商业智能和分析项目需要大量的财务资源，并且在缺乏高层支持和承诺的情况下往往容易失败。数据仓库/商业智能项目需要一位倡导者，即来自信息技术或业务部门的高级经理，能够从高管层获得支持和承诺（Grossman & Siegel, 2014）。领导力对于管理职能孤岛或其他冲突至关重要。
治理结构有助于利益相关者做出决策，优先考虑分析机会（Grossman & Siegel, 2014），并明确各利益相关者之间参与的基本框架，从而建立促进合作、协调和知识共享的规则。关于领导力和治理的问题更多地与项目管理相关，在大型战略性项目中，还需与敏捷软件开发相协调，以满足当代数据仓库/商业智能应用中常见的敏捷性需求。
复杂性
四个因素------数据量、多样性、速度和真实性------被认为是导致当代数据仓库/商业智能和分析中复杂性问题的原因（Abbasi, Sarker, & Chiang, 2016）。本研究的结果表明，数据量的担忧较少，但其他因素可能相互作用，造成数据集成问题。特别是，真实性最受关注，并引发数据质量问题。例如，同一公司的不同部门可能没有共同的客户标识符，无法将一个部门的行为与另一个部门关联起来以预测行为或检测欺诈。此类结构性问题无法通过敏捷方法解决。或许，复杂性的关键根本原因在于情境因素，如项目规模，或组织因素，如协调各方利益相关者利益和行为的困难。因此，复杂性可能既影响敏捷开发，也影响项目管理实践。
复杂性可能对敏捷开发产生负面影响，而对项目管理产生正面影响。更全面地看待项目复杂性的方式是从技术与组织、静态与动态视角共同进行考察（Xia & Lee, 2003）。
组织文化
分析领域的技术进步是显著的（Hu, Wen, Chua, & Li, 2014），但如果不能首先解决数据集成问题，业务价值承诺就无法实现（Dong & Srivastava, 2013）。组织中的深层结构性问题需要其文化发生改变。组织文化通常以基本价值观为基础来理解（Leidner & Kayworth, 2006）。例如，一个组织可能重视权力，参与者可能认为保护地盘很重要；在这种情况下，利益相关者可能会认为，保护地盘和权力意味着不与其他部门合作。深陷地盘之争的组织文化必然会妨碍数据集成工作的推进。
根据这项研究，三种可以增强合作与融合的文化价值观是自主性、透明度和灵活的心态。自主性可以赋能个人，从而降低他们参与地盘之争的可能性（Wynen, Verhoest, Ongaro, & Van Thiel, 2014）。透明度通过促进问责制来增强信任，尤其是在业务与信息技术之间（Norman, Avolio, & Luthans, 2010）。灵活的心态则包容他人的观点，并体现学习的意愿（Conboy, 2009）。此类组织文化变革可能解决某些开发方法无法克服的结构性问题。幸运的是，敏捷实践似乎正是基于类似的文化价值观，并可提供坚实的方法论基础，以促进自主性、透明度和灵活的心态。事实上，除了单位规模（组织 vs. 项目）之外，组织文化这一类别与敏捷开发非常相似。
启示
Collier（2011年）和Hughes（2012）的近期实践书籍表明，在数据仓库/商业智能环境中应用敏捷价值和原则具有明确的可能性。然而，目前尚无系统性研究来说明敏捷实践如何被适应于数据仓库/商业智能开发。
该研究旨在揭示敏捷实践的适应情况，并识别此类项目开发的关键因素。分析得出了八个类别，每个类别包含若干子类别，涉及组织、方法论和技术方面的关切。
结果表明，多个情境因素影响数据仓库/商业智能的敏捷开发，因此需要平衡相互竞争的敏捷价值。这种模式与传统的敏捷软件开发不同，后者更倾向于优先考虑左侧的敏捷价值而非右侧。数据仓库/商业智能的敏捷开发需要与项目管理相协调。由此产生的框架被称为情境化数据仓库/商业智能敏捷开发，该框架将流行的敏捷价值与项目管理相结合，以应对数据仓库/商业智能项目。
基于邵等人（2010）提出的框架，该框架描绘了从组织输入构念到通过流程构念中介的成功路径，图1展示了情境化敏捷数据仓库/商业智能的初步研究框架。业务价值受两个流程构念的影响：敏捷开发和项目管理。而这些流程构念又受到技术能力、高层管理承诺、复杂性、共享理解以及组织文化等情境因素的影响。其中，技术能力、共享理解和组织文化可能对敏捷开发有正面影响，复杂性对敏捷开发有负面影响但对项目管理有正面影响，共享理解和高层管理承诺对项目管理有正面影响。所提出的研究框架需要基于问卷调查的实证支持，并可通过结构方程建模技术进行分析。
该研究的主要贡献在于，通过规定一种更具平衡性的竞争价值组合，并要求将项目管理实践与敏捷开发相结合，从而将数据仓库/商业智能与传统软件开发区分开来。如果需要对数据仓库/商业智能项目的左右两侧进行权衡，那么一个合理的启发式比例可能是60:40，且可利用情境因素进一步调整该比例。右侧的问题要求项目管理发挥重要作用。
结论
将敏捷开发与项目管理相结合的一种方法是研究大规模敏捷开发（如SAFe（Knaster & Leffingwell, 2017；Leffingwell, 2007）和LeSS Scrum（Larman & Vodde, 2016））中的价值和原则。这些方法论中规定的价值和原则不同于敏捷宣言的原则；例如，更加重视诸如问题等方面的从经济视角出发，注重系统思维，并与跨领域规划保持同步。这些原则可以与敏捷开发和项目管理相契合；例如，Gowan、Mathieu 和 Hey（2006年）提出了挣值管理，这是一种迭代方法，专注于对预算和进度的持续评估。
该研究强调了技术在数据仓库/商业智能开发中的重要性。与个体和互动相比，敏捷价值观对工具的重视程度较低。然而，商业智能向分析和大数据的扩展主要由工具推动，这些工具能够提供成本更低、响应时间更短且吞吐量更高的解决方案；例如，NoSQL 技术正变得越来越普及（Sadalage & Fowler, 2012）。总体而言，数据仓库/商业智能开发应被视为一种社会技术现象，需认识到方法论、组织和技术问题的作用。因此，数据仓库/商业智能开发可能不同于传统的软件开发，后者更适合直接应用敏捷方法论。