Product owner (BA) Sprint backlog
CBAP提升业务思考能力与分析水平,培养商业头脑。
Product owner (BA) Sprint backlog
完成估算 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
系统介绍课程
需要记忆每个领域包含的任务名称,及输入输出
领域的相关方/技巧等重在理解
需求分析的旧版定义:一组任务和技术如何应用到工作中的组织架构/流程/运作方式等分析,在分析中发现问题,提供解决方案解决问题,为组织带来价值 。
课程分成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