在商业分析工作中，观点用于为倡议的具体上下文提供任务和技术重点。大多数倡议可能会涉及一个或多个观点。BABOK指南中包含的观点包括：
这些观点并不意味着代表了所有可能的观点，商业分析人员可以从中获得经验。 BABOK 指南中讨论的观点代表了写作时最常见的一些商业分析观点。
任何给定的倡议都包括一个、多个或所有这些观点。例如，一项倡议可能有一个技术组件（信息技术视角），技术组件可以意味着业务流程的变化（业务流程管理视角），该倡议可能会决定使用敏捷方法来完成部分或全部工作（敏捷视角）。另一个倡议可能需要合并两个组织，并需要考虑业务能力以及转型如何影响这些能力（业务架构视角），商业领袖需要更新的信息来进行决策和分析（商业智能视角）。大型或复杂的倡议可能会同时采用所有视角。
虽然 BABOK 指南中概述的商业分析任务旨在适用于所有商业分析领域，但它们也与每个具体的商业分析视角有关。 视角提供了以适合上下文的方式更专注于商业分析工作的方法。 视角有助于从当前所处的角度解释和理解 BABOK 指南中的知识区域和任务。
每个视角都遵循一个常见的结构：
- 范围变更，
- 商业分析范围，
- 方法、途径与技术，
- 基础能力，以及
- 对知识领域的 影响。
敏捷视角
敏捷视角突出了在敏捷环境中进行商业分析的独特特点。
敏捷是一种灵活的心态，体现在一套价值观和原则中，并通过各种互补的做法来展示。 敏捷倡议涉及持续变化。 在敏捷倡议上工作的商业分析师不断重新评估、调整和调整他们的工作和策略。 商业分析师在最后负责的时间点进行分析并交付工作成果，以使敏捷团队能够不断地灵活应对变化；详细的分析工作不是提前完成，而是在适当的时间有效地利用敏捷团队。
敏捷商业分析确保在正确的时间，为敏捷团队提供正确的详细程度的信息。商业分析师帮助敏捷团队回答如下问题：
- 我们要满足什么需求？
- 这个需求值得满足吗？
- 我们应该提供什么来满足这种需求？
- 为了满足这种需求，我们应该做什么？
在敏捷项目中，商业分析工作持续进行，并且高度依赖于人际交往技术，如沟通、促进、辅导和协商。商业分析师是敏捷团队的积极涉众，经常推动规划、分析、测试和演示活动。在敏捷团队中，产品负责人/所有者、商业分析师或其他明确定义的角色 5可以执行商业分析。商业分析师帮助团队识别假设和其他项目的变更。
根据敏捷扩展的BABOK指南，对商业分析在敏捷方法中的角色、心态和实践进行了更全面的论述，并提供了有关敏捷宣言的价值观和原则的详细信息。
敏捷宣言 ( www.agilemanifesto.org)。
1 范围变更
在敏捷项目中工作的商业分析师与业务发起人合作，以战略方式帮助定义提议的产品或功能如何与组织的目标保持一致。他们与各种涉众和变更团队合作，将产品愿景分解为优先级 6列表，列出需要完成的工作项。 优先级列表（或优先级积压列表）通常侧重于结果产品所需的能力，并强调首先实现价值最高的部分。
商业分析师可以作为涉众 7代理，或直接与发起人或产品所有者合作。
在敏捷环境中，变化和对变化做出快速响应是可以预期的。敏捷团队会交付小而逐步的变更，并承诺在一个迭代周期内只关注优先级最高的工作项。这使得敏捷团队能够以最小的影响来处理即将到来迭代周期中的新变更。一个迭代就是一个已商定的工作时间范围。
需求通过持续探索和分析业务需求 8来制定。需要注意的是，尽管大多数敏捷方法都是迭代的，但并非所有迭代方法都是敏捷的。也有几个非迭代的敏捷方法，如看板方法。
在敏捷项目中，范围不断演变。 这是由待办事项清单管理的，该清单会持续进行评审 9并重新排序优先级。 该过程有助于细化和重新定义范围，以满足不断变化和新兴的业务需求。
如果出现重大变化，严重影响项目的总体价值和目标，项目可以被暂停并重新评估。
.1 变革广度
敏捷方法用于满足企业的各种需求。最常见的敏捷实践是在软件开发项目中使用。然而，许多组织已经开始在与软件无关的变化上应用敏捷原则，如流程工程和业务改善。以敏捷方式开展的倡议可以在一个部门内进行，也可以在一个组织的所有团队、部门和分支机构之间展开。
对于刚刚接触敏捷思维和实践的组织来说，关注持续改进、不断变化的行为以及取得进展的能力使组织能够朝着文化上采纳敏捷思维的方向前进。采用敏捷心态是指在文化上接受敏捷原则，而不是将敏捷视为一种要实施的方法或做法。
.2 变化的深度
采用敏捷方法的举措通常构成更大范围的工作计划的一部分，该工作计划可能包括组织变革、业务流程再工程或业务流程变更。敏捷工作流通常是，但并不总是以软件开发为中心。其他程序的元素可以使用敏捷或其他适当的方法来开发。敏捷原则和实践通常成功地应用于在：
- 客户有明确的承诺，并由授权的主题专家（SME）参与，
- 业务需求或提议的解决方案复杂或复杂，
- 业务需求正在发生变化或未知，仍在涌现。
敏捷方法可以用于首次开发解决方案或维护和增强现有解决方案的倡议。例如，如果变更具有关键任务，则可以添加流程以满足监管要求并处理项目的最关键任务方面。
.3 交付的价值与方案
敏捷方法交付的价值和解决方案与其他任何倡议类似。 敏捷方法与传统方法的不同之处在于，它强调通过高度协作的方式及早交付价值，并使用侧重于持续改进的适应性规划。
敏捷方法通过敏捷团队不断审查和反馈所执行的工作来提供价值。涉众有机会经常性地审查产品，从而能够及早发现任何遗漏的需求。随着时间的推移，解决方案会不断发展，并期望对变化做出快速且灵活的响应。清晰、透明的所有沟通对于确保敏捷团队的努力与组织的需求和期望保持一致至关重要。
在一个新的团队中，商业分析师经常在敏捷团队成员和外部涉众之间建立关系和信任方面发挥核心作用，以帮助进行持续的合作讨论和参与。这种互动使敏捷团队能够准确地交付满足不断变化的涉众需求的价值。
.4 交付方法
敏捷方法侧重于人际互动、透明沟通以及持续向相关方交付有价值的变更。
每种敏捷方法都有其独特的特点，使团队能够选择最适合手头任务的方法。一些敏捷团队发现，在其环境限制下工作需要一种混合或结合的方法。
参见BABOK指南的敏捷扩展，了解不同的敏捷交付方法。
.5 重要假设
敏捷环境中的假设通常包括：
- 即使在开发后期，欢迎变更要求。
- 业务问题可以简化为一组需求，这些需求可以通过技术组合或业务流程变化来满足。
- 敏捷举措让客户充分参与，并赋予 SME 完全接受敏捷方法的能力。
- 理想情况下，团队成员人数保持不变，成员不会被不断调到其他团队。
- 人们更喜欢多学科、并肩工作的团队，这可以鼓励面对面交流更加高效有效。然而，敏捷方法在分布式团队中也能很好地发挥作用，只要适当的支持和沟通渠道到位即可。
- 如果团队需要，团队成员可以在团队中扮演多个角色（例如：跨职能团队），只要团队拥有适当的技能。
- 团队成员具有通过定期检查实现持续改进和成功价值交付的心态。
- 敏捷团队是有权且自组织的。
2 商业分析范围
.1 变更发起人
敏捷倡议的发起方需要熟悉敏捷哲学、心态和方法，也要乐于接受来自涉众的不断反馈，并做出妥协。
敏捷发起人明白并接受：
- 适应性规划，而非预测性规划，
- 为工作周期设定固定的时间段，以及
- 发起方参与的需求和价值。
发起方（或授权的领域主题专家）与敏捷团队的积极参与对于使发起方能够预览并理解正在开发的产品至关重要，同时让发起方有机会向团队提供持续反馈，并根据需求变化调整产品。
.2 变更目标和代理
当组织文化、工作环境 适合于密集协作、频繁沟通以及持续交付适当解决方案价值时， 敏捷方法最为成功。
敏捷团队通常是小团队或由多个小团队组成的团队。简单的扁平结构并不改变交付成果可能会影响大量涉众的事实。变革代理人，也被称为涉众，不会因为使用敏捷而有所不同。在采用敏捷方法进行变革时，主要涉众可能包括：
- 敏捷团队领导：团队工作的推动者。敏捷团队领导者通常与项目经理具有相同的软技能，但完全将规划、调度和优先级分配任务委托给团队。在所有敏捷方法中，首选的服务型领导而不是传统的命令和控制管理。根据方法的不同，这个角色可以称为 Scrum 专家、迭代周期经理、团队领导或教练。
- 客户代表或产品所有者：负责确保正在进行的更改解决了其被要求解决的问题。在 Scrum 中，这个角色被称为 产品经理。动态系统开发方法 (DSDM) 将此角色称为先知，而极限编程 (XP) 则将其称为客户代表。
- 团队成员：由技术专家和客户代表组成的专家或领域专家。根据倡议的规模和具体背景，团队内的个人有不同的专长。可用性专家、 技术架构师 和 数据库管理员 只是此类提供支持的专门角色中的一部分示例。 外部涉众：所有可能不被视为团队成员，但对项目结果感兴趣或仅仅需要完成项目的其他涉众，在团队中发挥辅助作用。
. 3 商业分析师职位
敏捷团队可能有一名或多名具有商业分析技能的成员，他们可能有也可能没有商业分析师的职称。对跨职能团队成员的认识使商业分析超越了单一专家角色。
在敏捷团队中，商业分析活动可以由以下人员或组合完成：
- 团队中的商业分析师，
- 客户代表或产品所有者，或
- 将这些活动分配给团队。
有关详细信息，请参 BABOK 指南的阅敏捷扩展。
.4 商业分析结果
在敏捷环境中，商业分析将人们聚集在一起，并确保正确的涉众在正确的时间参与敏捷团队。开放沟通与协作是成功进行敏捷项目中的商业分析的主要成果之一。
商业分析师确保项目愿景和方向与组织目标和商业需求保持一致。 商业分析师在定义项目的完成战略标准方面有共同责任，并在项目期间协助定义接受标准 10。他们还促进产品愿景声明的制定。 产品愿景声明是一种常见的初始交付成果。
文档严谨性和风格在很大程度上取决于生成它的目的和上下文。敏捷方法更倾向于适量及时地编写文档，而不是预先定义文档交付模型。这种文档方法允许尽可能多地包含引入的更改，同时保持更改成本低廉。审计或合规报告等强制性文档仍作为每个交付周期的一部分进行编制。重要的是，文档要满足已识别的需求，并且提供的价值要大于制作和维护它们的成本。
3 方法和技术
.1 方法
敏捷是一系列方法的总称。所有敏捷方法都使用商业分析，但只有少数明确说明了商业分析角色。任何敏捷方法的主要特征都是它与敏捷宣言的价值观和原则的一致性。敏捷团队可能会实施或演进一系列方法，这使他们能够根据项目类型和工作环境更有效地提供价值。
表11.1.1 敏捷方法
| 方法 | 简短描述 |
|---|---|
| Crystal Clear | 属于水晶系列方法论之一，该系列根据硬度和颜色定义。硬度代表业务重要性或潜在危害程度，随着重要性增加，需要更严格和前瞻性的规划。颜色表示项目的沉重程度，涉及多个维度，如所需人数和项目中的风险元素。 |
| Disciplined Agile Delivery (DAD) | 一种决策过程框架，融合了多种敏捷方法的思想。旨在从项目启动直至交付全程提供支持。DAD并不规定死板的做法，允许团队自定义自己的生命周期和方法。 |
| Dynamic Systems Development Method (DSDM) | 一种项目交付框架，重点在于初期就确定成本、质量和时间，而通过调整要交付的功能来管理不确定性。使用MoSCoW优先级排序技术进行范围管理。通过时间盒（具有明确结果的短期聚焦时间段）来管理工作进度。 |
| Evolutionary Project Management (Evo) | 一种渐进式开发和交付系统的项目管理方法。强调为多个利益相关者量化价值，并基于这种价值（可度量）计划增量。使用影响力估算 11表作为正式技术，评估解决方案在给定成本下为多个利益相关者提供价值的能力。 |
| Extreme Programming(XP) | 以其将有益的软件工程技术推向极端的概念命名。该理念关注技术开发过程，特点包括结对编程、测试驱动开发以及其他针对技术实践的工匠精神方法。XP的技术实践经常与敏捷管理框架结合使用。 |
| Feature Driven Development (FDD) | 专注于从客户价值功能角度开发工作软件。例如，在高层次范围界定之后，确定功能列表，所有规划、设计和开发均基于功能集进行。 |
| Kanban | 不需要固定迭代。工作通过开发过程作为连续的活动流进行移动。一个关键特点是限制任何时候正在进行的工作量（称为在制品限制或WIP）。团队仅同时处理固定数量的任务，并且只有在保持下游流畅性且完成上一任务后，才能开始新任务。 |
| Scaled Agile Framework® (SAFeTM) | 一种在企业级规模实施敏捷实践的框架。它突出了从团队到项目再到企业各级别所需的个人角色、团队、活动和工件，以实现敏捷扩展。 |
| Scrum | 一种基于经验过程控制的轻量级过程管理框架。工作在一个系列的固定长度迭代（称为Sprint，持续不超过一个月）中进行。每个Sprint结束时，团队必须产出高质量的工作软件，足够好以至于可以潜在地发布或以其他方式交付给客户。 |
.2 技术
下表列出了在敏捷方法中常用的技术。有关这些技术的更详细描述，请参阅《敏捷扩展至商业分析知识体系指南》。 表 11.1.2：敏捷方法中使用的技术
| 技术 | 简介 |
|---|---|
| 行为驱动开发（BDD） | 一种通过将产品需求表述为具体示例来增强利益相关者与团队成员间沟通的方法。 |
| 加野分析（Kano Analysis） | 一种用于理解哪些产品特性有助于驱动客户满意度的技术。 |
| 轻量级文档编写 | 一种指导敏捷项目中所有文档产生的原则。目的是确保所有文档都是为了满足即将来临的需求而编写，对利益相关者具有明确价值，并且不产生不必要的负担。例如，在项目后期基于稳定内容和作为产品测试一部分编写的验收测试编写系统概述文档。 |
| MoSCoW优先级划分 | 一种在增量和迭代方法中优先级排序故事（或其他元素）的方法。MoSCoW（必须有、应该有、可以有、不会有）提供了一种方法，使各方就产品中交付某个故事或其他价值单元的相对重要性达成共同理解。 |
| 用户画像（Personas） | 虚构的人物或典型代表，展示了典型用户与产品的交互方式。 |
| 规划研讨会 12 | 一种协作研讨会，用于让敏捷团队确定在一定时间段内（如一次版本发布）可以交付多少价值。 |
| 目标一致性模型（Purpose Alignment Model） | 用于在客户和价值背景下评估想法的模型。 |
| 真实期权（Real Options） | 一种帮助人们了解何时做决策而不是如何做决策的方法。 |
| 相对估算（Relative Estimation） | 使用故事点或理想天数的团队估算技术，故事点表示用户故事 13开发的相对复杂度，理想天数表示完成故事所需的总体工作量。 |
| 反思会（Retrospectives） | 类似于经验教训 14技术的一个术语。反思会关注团队合作过程的持续改进，并在敏捷项目每次迭代结束后举行。 |
| 故事拆解（Story Decomposition） | 确保产品需求以适当详细程度呈现，并源自有价值的业务目标。 |
| 故事地图（Story Mapping） | 提供了一个视觉和实体视图，显示解决方案应支持的一系列活动序列。 |
| 故事版（Storyboarding） | 通过视觉和文本详细描绘代表用户与系统或业务交互的活动序列。 |
| 价值流映射（Value Stream Mapping） | 提供一个全面、基于事实的时间序列视图，展示了向客户交付产品或服务所需的全部活动流。 |
4 基础技能(基本功)
敏捷是一种心态。敏捷商业分析师体现了敏捷宣言的价值观和原则，这些价值观和原则基于对产品开发的人本主义观点，即沟通与协作为基础的过程。请参阅《商业分析知识体系指南》中的敏捷扩展部分，了解商业分析师的原则描述。在采用敏捷思维和理念时，商业分析师需要培养以下技能：
- 沟通与协作：能够传达发起方的愿景和需求；协助影响他人支持该愿景；参与并可能促进优先事项的谈判；并在解决方案结果上促进合作一致。
- 耐心和宽容：在压力下保持自我控制的能力，以及与他人互动时保持开放的心态。
- 灵活性和适应性：跨职能技能集，使商业分析师能够跳出自己的专业领域，支持其他团队成员。
- 能力处理变化：能够快速评估变化的影响，并确定在频繁变化的需求中，什么为业务提供了价值，并协助或维护待办事项工作清单的重新排序。
- 能够识别业务价值：能够理解变化和新功能如何实现业务价值并支持愿景。
- 持续改进：定期与敏捷团队一起回顾，如何变得更加高效。
5 影响知识领域
本节解释了敏捷方法中特定的商业分析实践如何映射到babok指南中定义的商业分析任务和实践。它还描述了每个知识领域是如何应用于或修改为敏捷学科的。
每个知识领域都列出了与敏捷视角相关的技术。 在 BABOK 指南中的“技术”章节中可以找到 BABOK 指南技术。 在《BABOK指南敏捷扩展》中有详细介绍敏捷扩展技术。 本节不是要列出所有技术，而是要突出商业分析师在知识领域内执行任务时所使用的技术类型。
.1 商业分析规划与监控
在敏捷方法中，详细的商业分析计划可以推迟到开始活动之前完成，而不是像预测性项目那样提前完成。
在项目开始时，会制定商业分析活动的初步计划。然后，在每个迭代开始之前更新该计划，以反映变更并确保计划始终保持最新状态。涉众的参与和投入是敏捷项目成功的关键。商业分析师积极规划与涉众进行接触、互动和协作。沟通通常更为非正式，商业分析交付成果往往是对话和协作的结果，而不太强调书面文件。
BABOK 指南 技术
敏捷扩展技术
- 轻量的文档
- 相对估算
- MOSCOW优先级
- 反思会
- 人物角色
.2 需求挖掘与协作
在敏捷项目中，不断进行渐进式需求挖掘和详细说明。最常见的模式是在初始提取活动中确定解决方案的高层次愿景和范围，并为交付产品制定一个基于里程碑的初步计划。每个周期都会对在该周期内开发的积压项目进行更详细的需求挖掘。需求获取活动的目的是产生足够的细节，以确保当前的工作正确完成，同时朝着目标努力。敏捷方法旨在最小化需求细化与解决方案实施之间的时间。强烈关注与涉众的合作需求获取方法，例如研讨会。
BABOK 指南 技术
- 接受与评价标准
- 过程建模 21
- 原型制作
- 积压管理
- 评审
- 头脑风暴 22
- 范围建模
- 协作游戏
- 涉众列表、地图或人物角色
- 概念建模 23
- 接口分析 24
- 应用案例和场景
- 思维导图
- 用户故事
- 非功能需求分析 25
- 研讨会
敏捷扩展技术
- 行为驱动设计
- 故事版
- 用户故事地图
- 人物角色
- 轻量的文档
.3 需求生命周期管理
随着敏捷举措的展开，范围会越来越具体。人们预计需求会发生变化，设计也会随着时间的推移而演变。基于价值和开发优先级对功能进行排序来驱动每个迭代周期的工作。在每个迭代结束时，与涉众验证不断演化的解决方案，而不是正式的需求批准流程。 BABOK 指南 技术
- 接受与评价标准
- 优先级
- 评论
- 背包管理
- 研讨会
- 协作游戏
敏捷扩展技术
- 堆积分析
- 故事分解
- MoSCoW 优先级规划
- 故事映射法
.4 策略分析
当需求、解决方案或变更范围不确定时，通常会采用敏捷方法。战略 26分析是敏捷倡议持续的一部分，以确保交付的解决方案继续为涉众提供价值。敏捷团队成员利用战略分析来帮助理解并定义产品愿景，并开发和调整开发路线图，同时对相关风险进行持续评估。每次迭代都会重新评估提出的解决方案，以确保它能够有效地实现业务目标。敏捷项目的适应性意味着根据组织的目标变化而调整项目不会破坏；相反，这是流程的一个预期部分。
BABOK 指南 技术
- 积压管理
- 概念建模
- 头脑风暴
- 指标和关键绩效指标
- 商业能力分析 27指标（KPIs）
- 协作游戏
- 范围建模
- 研讨会
敏捷扩展技术
- 目标对齐模型
.5 需求分析与设计定义
在敏捷项目中，需求会逐步细化。分析与设计工作会在迭代过程中或迭代开始前的“及时”阶段完成，要么就在解决方案组件开发之前的那个迭代周期内。
在迭代之前进行的分析是为了为团队提供足够的信息来估计计划中的工作。 迭代期间进行的分析是为了为团队提供足够的信息来构建或交付计划中的工作。
模型和其他分析设计技术通常是非正式使用的，一旦它们完成了自己的使命，可能不会被维护。应使用支持逐步详细说明、根据学习进行调整并避免团队过早选择解决方案的分析设计方法。敏捷团队倾向于在最低级别的分解中使用用户故事，并且通常通过可接受标准来支持，这些标准捕获了有关故事如何实施时的行为的分析和设计细节。在每个迭代结束时与相关者验证正在发展的解决方案。
BABOK 指南 技术
- 协作游戏
- 过程分析 28
- 概念建模
- 过程建模
- 接口分析
- 非功能需求分析
- 优先级
- 范围建模
敏捷扩展技术
- 甘特图分析
- 轻量级文档
- MoSCoW 优先级法
- 实物期权
- 使用案例和场景
- 用户故事
- 研讨会
- 故事阐述
- 故事地图法
- 故事版绘画
- 行为驱动开发
- 故事分解
- 目标对齐模型
- 价值流分析
6. 解决方案评估
在敏捷项目中，涉众和敏捷团队不断评估和评价随着增量式构建和细化而发展的解决方案。 在每个开发周期结束时，与涉众一起对正在演进的解决方案进行评估，以确保交付成果符合他们的需求并满足期望。 商业分析师会在产品发布之前确保产品符合预期，并确定可以为业务增加价值的新机会。
BABOK 指南 技术
- 接受与评价标准
- 原型制作
- 评论
- 商业能力分析
- 涉众列表、地图或角色
- 指标和关键绩效指标（KPI）
- 使用案例和场景
- 非功能需求分析
- 用户故事
- 研讨会
- 过程分析
敏捷扩展技术
- 人物角色
- 价值流分析