Product owner (BA) Sprint backlog
CBAP®商业分析师（高级）认证培训课程
CBAP提升业务思考能力与分析水平，培养商业头脑。
价格
¥ 5000.00
该课程属于 CBAP®国际商业分析师认证备考班
请加入后再学习
完成估算 estimation任务的方法：
1 自上而下 对整体依据经验粗略估计
2 自下而上 详细分解工作，准确度较高，适合对详细非常了解的情况
3 参数法 根据指标（比如用例数量/页面数量）估计工作量级
4 拍脑袋 Rough order of magnitude
5 rolling wave 刚开始粗颗粒度，随着推进用更准确的估算方法
6 delphi 向专家收集信息，经多轮达成一致认可
7 pert 三点情况，估算最好/最差/最可能的情况，做计算。三种情况的权重不同，例：
估值=（最好+最差+最可能*4）/6
估算的准确性
不同的方法，有不同的准确性。自下而上的准确性最高，拍脑袋的准确性最低
估算信息的来源
1. 组织架构的知识库，经验教训
2.领域专家（内/外部）
3.自身过往经验
估算的精确度可靠性
1.一个方法的多次估算的结果差异是否小，如果小则精确度高
2.借助不同的方法估算，或者不同人分别评估。如果评估出的值相似，则准确度高
估算的人员
1.团队内部 比如项目经理
2.外部专家
完成经验教训任务的方法：
这个任务可以参考的工具：
访谈？？
组织规范/标准流程
专家判断
方法论/框架
干系人分析方法 了解干系人
需求分析工作计划
1.可交付的成果/工作成果
a. 定义：制定计划时，某个时间，向某个人干系人交付的成果
b. 围绕交付内容，具体分析需要的活动
2.确定每一项工作需要的时间/资源
a.干系人/团队人员的时间安排
b.优先级
c.预算
3.复杂性和风险
a.人员数量
b.变化规模
c.地理位置/文化差异/时区
d.技术复杂度
e.BA的风险
BA的经验/领域知识
干系人的沟通经验/态度/分配的时间
文化不同
影响力
3.制定的计划
计划不仅影响到BA，也影响提供信息/知识的人，需要把计划告知到所有参与到BA活动的干系人，然后把BA工作结果告知到干系人，干系人可能需要批准。
总结瀑布方法论和敏捷方法论
预测型方法论 瀑布
适合情况： 需求已经有了正式批准
风险：提前分析风险
周期：长期交付
进度模式：一步一步完成
文档：正式，详细
需求变更：正式变更流程批准
沟通：正式会议
适应性方法论 敏捷
适合情况：在开始的时候对需求没有充足的了解，在过程中增项提升去达到现状的期望。
风险：高
周期：适应短期/快速交付
进度模式：迭代
文档：最少，概况
需求变更：需求变更是正常情况，非正式流程
沟通：非正式会议
3.1 plan business analysis approach 和 3.2 plan stakeholder engagement 同步进行
3.1 plan business analysis approach
输入：needs
输出：BA approach
Planning approach分成两类
predictive aprroaches预测性方法
比如说瀑布形的项目需要提前预测
adaptive approaches适应性方法
快速型交付价值，迭代式完成价值交付
瀑布模型 the waterfall model
需求=》设计=》实施=》验收=》维护
螺旋模型 the spiral model
每个迭代是个小型的瀑布
The Unified Process 介于瀑布和迭代模式
用例驱动：用于功能性需求的分析，测试验证
分析背景目标=》详细分析=》解决方案构建=》移交
agile methodologies-scrum 敏捷
角色：
产品负责人更解决BA
开发团队
敏捷教练 保证整个团队以敏捷的方式完成项目
工件：
产品未完项表，需求列表
冲刺列表 每次冲刺在1到4周
增量成果 直接让用户用或演示
燃尽图 了解当前项目的进展情况 用来衡量剩余工作的情况
仪式：
sprint planning meeting 当前sprint需要完成的工作/预算
daily scrum meeting 日会 总结前一天工作的情况/问题/难点
sprint retrospective 用户演示，团队回顾，经验教训总结
敏捷宣言：
个体及个体间的互动 而非流程
工作软件 而非文档
客户协作 而非合同谈判
应对改变 而非预先制定的计划
需求变更需要客户批准，邮件把需求变更发给客户，和客户沟通3天不回复，即默认同意
这个图是输入输出图，数据流向图
绿色箭头是输出
虚线箭头是指导方针
编号不是先后顺序
3.1 BA工作总体计划方法-》输出工作计划/考虑（可能是非实体输出）
3.2 干系人沟通计划 什么时间什么方式沟通
3.3 BA计划决策方式 比如说需求优先级 谁/以什么标准划分需求优先级，需求变更的流程/依据/批准人
3.4 BA信息管理 需求重用/需求依赖关系
输入的定义：开始一项任务需要具备的，转化为输出的条件。把输入改头换面后变成输出。是另外一项任务的输出。
可能来自于BA工作的以内和以外，包括用户的顾虑，干系人的态度。
以外：solution
输入可能是不完整，足够开始启动任务的要求即能启动任务。所有输入完整后，任务才能结束。
输出的定义：每项任务的结果，可能是在任务中新创建的，也可能是对输入的改头换面。
干系人：
BA
客户
业务专家
终端用户
实施专家
运维
项目经理
法律法规的制定人/监管机构，比如PMO
赞助人/主导人
供应商
测试
六大知识领域：
1. 战略分析：定义问题/设定目标和范围。
2. 需求分析和设计定义：前置步骤1，解决方案的输入。
3. 解决方案评估：前置步骤2，前提条件是已有解决方案。在评估过程中可能会发现问题，需要讨论问题，解决问题。流程回到步骤1战略分析，重复步骤1到3。
4.发掘和协作：持续进行的工作。发掘需求，和干系人沟通收集信息，步骤1到3都涉及到发掘和协作。
5.需求生命周期管理：持续进行的工作。需求批准/需求变更管理，需求优先级划分，需求重用
6.需求规划和监督：持续进行的工作。对实际效果进行监控，用经验教训分析偏差。
Knowledge area tasks
1.任务的定义：一个相对独立的工作，有一个输出
2.按一定顺序/同步的执行任务
3.BABOK没有规定任务执行顺序，BABOK不是方法论，是一个工具箱
4.需求分析可以是对现状做分析(战略分析领域)/衡量解决方案的效果（解决方案评估）
需求分类
business requirement : 事情的目标。应用到整个企业或业务领域的业务/商务需求。
stakeholder/user requirement: 哪些人会用到或受到影响，他们具体的要求是什么。敏捷项目利用用户故事呈现，包含actor/action。瀑布性项目需要方案，涉及业务流程，用户体验的设计。
solution requirements: 业务解决方案所有的细节，包含功能/属性。理论上实施团队依靠此实现需求，但实际可能还有需要确认的方面。
需求收集和分析的过程不是一步完成的，需要迭代完成以上三个步骤。建议初步调研时不要调研的特别细节
Transition requirements: 转换/过渡需求，在解决方案部署前的过渡方案（人员培训解决方案/数据迁移）。特点：有一定时效性
解决方案在使用阶段仍产生作用，比如某些需求是持续性的（用户在线率）。在使用解决方案过程中对功能做调整是正常情况。
前三个在解决方案前完成，最后一个在解决方案后完成。
solution requirements:
分成
1. functional requirements 功能性需求
2. non - functional requirements 性能/可用性/安全性，影响需求方案的被接受程度，如果不能满足需求可能导致整体解决方案失去价值
例：
1. 比如12315功能性满足，但性能不满足
2. 登录后的页面数据加载量大，导致用户登录后系统加载慢，用户体验差，导致客户体验差。原因是服务器在外国，国内显示慢。后来在需求方案中加了性能要求即非功能性需求。
Requirements & Design(what & how)
需求是解决方案的团队的输入，解决团队也会做输出（比如测试用例）给BA确认。
六大领域：
Needs: 重点问题或机会
Change：针对某个问题或可开发机会，在组织层面应对，所以需求改变
Contexts: 组织内外部结构/人员影响因素的总和
Solutions: 考虑到内外部因素的解决问题的方案
Stakeholders: 干系人
Value：问题解决产生的价值，解决方案是否能产生足够的价值（需要考虑各个因素和组织架构）
Business Analysis Information
the broad and diverse sets of information that business analysts analyze, transform, and report;
It is information of any kind—at any level of detail—that is used as an input to, or is an output of, business analysis work.
商业分析信息：最重要的概念是requirement 需求收集/需求分析/需求管理。
需求收集过程中访谈过程中产生的访谈记录，干系人表达的需求/限制条件/顾虑/解决方案，分析后产生需求。
Design 实现需求/解决方案的设计（偏业务领域的设计+UI）
how：解决方案
what：需求
实际工作中 design和requirement很难分割开
Requirement
能被团队其他成员使用的反馈需求的展现形式（文档/图表）
Organization组织
管理层设计目标
Enterprise 目标达成的多组织构成的整体
组织和组织以外的环境因素
Plan
需求分析的工作内容/工作量/时间/资源/approach 的规划
Risk
将来有可能发生的事件，带有不确定性，如果发生会有负面/正面影响
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the
globally recognized standard for the practice of business analysis.
全球范围内认证的BA知识体系
The BABOK® Guide describes business analysis knowledge areas, tasks, underlying competencies, techniques and perspectives on how to approach business analysis.
系统介绍课程
需要记忆每个领域包含的任务名称，及输入输出
领域的相关方/技巧等重在理解
需求分析的旧版定义：一组任务和技术如何应用到工作中的组织架构/流程/运作方式等分析，在分析中发现问题，提供解决方案解决问题，为组织带来价值 。
需求分析的新版定义：Business analysis is the practice of enabling change in an enterprise（包含公司外的上下有） by defining needs and recommending solutions that deliver value to stakeholders.
needs：工作中需要解决的问题，或机会。通常不清晰，需要和干系人调研。调研干系人，干系人可能说的是解决方案，或有误解。需求分析需要定义问题，需要用ppt等方式呈现问题。
requirements：是收集问题后的分析结果
stakeholders：工作中的相关方/人(包含解决方案的施加方)
BA这个工作是做什么的：是客户和解决团队之间沟通的桥梁。为解决方案的设计和实施提供输入，也就是requirements。
Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement.
BABOK领域内定位BA是在项目中或在公司中（业务顾问）
PMI领域内定位BA是在项目中的角色
It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state.
分析现有流程或未来希望达成的流程
课程分成12个单元，基本参考BABOK书籍
第一单元对应第一章
介绍背景/结构/重要概念
第二单元对应第二章
介绍重要概念：需求/干系人
第三到第八章
需求分析的六大领域，每个领域有任务，任务的输入输出是什么
第九章
基本能力：沟通/协调
第十章
六大领域工作中需要的方式方法：interview
考试实际占了比重
第十一章 视角
在特别行业的应用：IT 敏捷 业务流程管理 商业智能 商业架构
第十二单元
不是BABOK书内容，是考试指导
Agile-iteration-just enough, just in time
Prective-requirement are define at a rather early stage-deliverables at the final stage
Interfaces-departmental
Roles and permission matrix
use case
Crud: create read update delete
Variance-root cause analysis
Data mining
