下载掌阅APP，畅读海量书库
立即打开
本节介绍敏捷开发BI方法，即解决如何去做的问题。
敏捷开发模式更适合轻量级的BI项目开发，其优点在于高效与简捷。Scrum是最为常见的敏捷开发方法，图1.5.1为Scrum方法的开发流程。
图1.5.1
想全面了解有关Scrum方法的读者可参考相关专业书籍。本节仅在《Scrum最佳指南》一书中挑选以下几条重点原则加以介绍：
● 设立产品待办事项列表、规划与增量环节。
● 在项目初期交付最小可行性产品。
● 商业智能与预测分析。
● 积极接受变更需求（包括在项目后期）。
● 鼓励项目人员参与Daily Scrum（站立会议）。
● 设立Scrum角色。
● 在Sprint结束时会举行Sprint评审和Sprint回顾会议。
Scrum方法是增量交付产品，开发团队在了解项目需求后，会将需求分解为待办列表（Backlog List），每项包含一个简短描述、时间估算、商业价值评估和优先次序。产品负责人会定期回顾待办事项，及时删除不需要的事项或添加新的事项。然后，项目会被划分为块，每个块为一个冲刺（Sprint）。理想中，每个冲刺的时间长度应相同（通常为14天到30天）。根据商业价值和优先次序，团队会往块中填充待办事项，形成冲刺代办事项（Sprint Backlog）并分配给团队成员。一个冲刺交付的产品被称为增量，增量总和则等于最终交付的产品。图1.5.2为具体的代办事项内容与事项分配示意图，图1.5.3为待办事项与冲刺的关系。
图1.5.2
图1.5.3
冲刺的目标为交付一个完整的MVP（Minimum Viable Product，最小可行性产品）。以图1.5.4中所示的自行车为例，每一次迭代交付的产品是一个完整的可以使用的产品，而下一个版本是基于前一版本开发的，因此，迭代自身是符合自然事物发展规律的，并且特别适用于轻量级别产品的开发。
图1.5.4
图1.5.5为项目4要素构成图。在Scrum方法中，成本、质量与时间因素都是不变的，而项目范围可根据实际情况进行调整。Scrum方法不回避变更需求，当在固定因素条件下与新变更需求发生冲突时，项目负责人需重新定义交付的MVP范围。
图1.5.5
体量轻的团队可以进行Daily Scrum，会议主要讨论项目更新与下一步行动计划、目前的阻力等问题。通常Daily Scrum为15分钟。每位成员需要回答3个基本问题：
● 至上次Daily Scrum后，我有什么更新。
● 在下次Daily Scrum前，我将会做什么。
● 目前我遇到了什么挑战。
Daily Scrum应在固定时间、固定场所举行，一周5天共花费75分钟，与开一次普通会议所花费的时间相当，但效率显著提高了。Daily Scrum避免了团队成员懈怠并持续输出。
敏捷的概念虽然很简单，但在真正实践时会遇到不少问题。图1.5.6为Micro BI设定的Scrum角色职能，其中有3个必要专属角色：产品负责人、产品开发团队和业务领域专家。业务领域专家岗位是一个服务型岗位，以“服务”的理念提供Scrum方法和流程管理，让大家一起克服项目中的困难。需要注意，Scrum原则上是专人专岗，但在小团队中，一位成员有可能身兼多职。
图1.5.6
在冲刺结束前，团队可以举办评审，向产品负责人和利益相关者演示可用的产品并接受评价。回顾是为了更好地前进，在冲刺结束后，团队还可以召开回顾会议，目的是总结经验与教训，如图1.5.7所示。
图1.5.7
下面将CRISP-DM模型与Scrum方法合并到一起，组合成敏捷BI开发方法。该方法适用于轻量级BI项目的开发。图1.5.8为敏捷BI开发方法流程图。
图1.5.8
以下针对流程图中的几个特色环节进行探讨。
此环节在于收集用户的分析需求，分析师应该引导用户提出具体、明确的分析目的。例如，通过图1.5.9所示的表格，帮助用户梳理初步分析需求。
图1.5.9
在明确了用户的分析需求后，下一步是对需求进行范围及优先度评估。将优先度从高到低进行排序。
在此步骤中，分析师会与用户一起评估现有哪些数据可被使用，是否足以支撑分析所需，为后面的建模工作奠定基础。为了标准化该流程，笔者设计了一套数据收集模板工具，具体包含以下几个组件。
● 主数据表 ：如图1.5.10所示，列出了所涉及的主数据表。
● 事实数据表 ：如图1.5.11所示，列出了所涉及的事实表。
● 数据关系 ：如图1.5.12所示，列出了所涉及的表之间的关系。
● 度量 ：如图1.5.13所示，列出了需要的度量名称、定义与公式。
图1.5.10
图1.5.11
图1.5.12
图1.5.13
有的读者会问，该如何对项目进行成本控制？在每个项目初始阶段，Micro BI团队都会提供40小时的顾问支持作为项目投入成本，这部分支持是不收取费用的。项目开发的完成度与用户自身的成熟度及沟通效率是成正比的。当40小时用完后，项目没有完工怎么办？图1.5.14给出了答案，在此情况下，业务人员可以选择通过正常付费项目的形式继续剩余的工作，或以自助的方式完成。
图1.5.14
这样做也对项目的风险进行了控制，假设项目中途因故终止，损失的成本可控制在40小时以内。项目的终止不是一件负面的事情，相反，通过敏捷的方式在短时间内完成评估，其本身就是一件非常有价值的事情。