本人参加了敏捷培训,将培训内容结合自己的实践分享一下,希望对同行的小伙伴有所帮助。本文分以下几个部分:1.什么是敏捷思维?2.scrum框架以及流程 3.团队各个角色的职责 4.作为po(产品)的工作 5.技巧。
一,什么是敏捷思维
敏捷核心思维:价值驱动,适应变化,自组织团队
1.价值驱动:关注高优先级目标,重要的事情放在第一位
在传统的瀑布流工作里,团队是按部就班工作的,同时会进行很多研发工作,敏捷团队会将项目拆分为很多story,基于用户痛点做价值排序,将最有价值的story放在最上面优先开发。尽早交付并把成果展示给用户,验证我们对市场和需求的认知。
在有限的时间成本下做更有价值的事,优先交付最核心的价值。
2.适应变化-频繁交付可见成果,频繁确认,确保交付正确的成果
你是否遇到过当整个开发完成提交的时候,客户说这个不是我想要的,然后就是长期的修改,客户不断提出修改需求,最后团队疲惫不堪。为什么你的成果客户不认可呢?寄希望在前期的需求沟通上其实是很困难的,客户不看到实体时,他是什么想法都没有的,但是他自己确在跟你的沟通中一直脑补。那敏捷是怎么做的呢?敏捷是不断试验性的过程,通过频繁和客户确认成果,收集反馈,调整自己的方向,最终达成。
敏捷关注持续交付可见的正确成果
3.自组织团队-目标驱动,共享责任
在一个复杂的环境下,管理层会成为瓶颈,自组织团队更高效,面对面沟通是团队最高效的合作方式。组建一个5-9人的跨职能团队,团队自我管理,共同完成目标,共享责任。
总结:价值驱动,尽早开始并交付,将成果展示给用户以获得反馈,用最少的资源创造最大的价值;使用经验性的过程,快速迭代,持续确认,确保交付正确的成果;团队应该尽可能的自组织和自管理,会进行互相配合的团队才能制造好的产品并拥有搞得生产效率。
个体与交互重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划。
二,scrum框架和流程
scrum框架
三个角色:product owner;scrum master;development team
三个工件:产品backlog;sprint backlog;产品增量
五个活动:产品backlog梳理;sprint计划会;每日站会;sprint评审会;sprint回顾会
五个价值:勇气;开放;专注;承诺;尊重
scrum流程
1.投资人/用户/市场/BOSS提出愿景
2.po整理需求池,做需求pk(确定哪些需求要做,排列优先级)
3.迭代计划( 确定每个迭代的目标)
4.sprint backlog(即将进行的冲刺列表)
5.迭代执行(包含可能N个冲刺,每日站会回顾昨天,明确今天的工作,分配各自的任务)
6.交付产品增量
7.迭代评审(po和其他干系人验收)
8.迭代回顾(master和团队参与)
9.回到需求池,开始下个迭代
容易出问题的是,站会不是汇报给master自己的工作成果,而是和团队沟通,弱化个人强化团队意识。我们昨天完成了什么?遇到哪些问题需要什么支持?今天要完成哪些story,大家各自领自己的任务。在站会po基本不发言,需要需求澄清可以在会后单独讲解,从而让站会时间缩短,控制在10min-15min。站会是团队的站会,需要团队自我管理,优秀的master可以训练和引导团队进行自我管理。
产品backlog是提前一个sprint的准备的,时间在上个sprint的需求澄清到下个sprint的需求澄清之间。po需要确认story边界,写验收标准,UI界面确认,工作量规模,需求优先级排列,技术风险和依赖管理。
step1:确定产品愿景(目标客户,用户痛点,产品亮点,竞争优势或差异化特性)
step2:建立业务流(故事地图的框架)
讨论可能的潜在用户角色,讨论各角色的主要活动,根据时间线排列
step3:写故事,构建故事地图
将用户的活动细化,写更小颗粒的用户故事;基于用户痛点,提炼MVP,按照价值驱动增量交付的思路建立产品发布规划
step4:为故事写验收条件
step5:为PBI排优先级
Must have-必备的重要功能;Should have-很重要但短期内有替代解决方法的功能;Could have-如果没有时间可以在发布中不予考虑的功能;Wont have this time-客户期望拥有但同时承认需要在后期发布中实现的功能。
考虑价值,成本,风险,紧迫程度,依赖。还有一种Kano模型,建议首个版本考虑给客户提供魅力型需求,让用户对产品有很高的好感度。
step6:敏捷估算(估算成本,周期,了解投资回报率,做计划)
注意:这里是很容易搞错概念的地方,这里的估算是相对估算,数字大小代表的是规模而不是时间,这里涉及团队速率的概念。首先团队要有故事点的概念,通常将用户故事中团队认为最小的那个设定为1个故事点。团队速率是一个scrum团队在一个sprint中实际完成的故事点数。
step7:sprint执行
三,三个角色的职责
1.团队-足球型团队
跨职能(UI+产品+测试+开发);T型技能;自组织;5-9人;负责承诺工作;有权力做达成承诺所需的任何事;在开放的空间,坐在一起;能够自己解除冲突;有自己的规则礼仪
什么是自组织团队?
授权团队,自管理;团队有权进行设计,计划和执行任务;团队自己监督和管理他们的工程过程和进度;团队自己决定如何开展工作。
2.scrum master
培训,引导,辅导,启发,协调
A.为scrum流程负责
保证团队正确的运用scrum,遵守流程;保证团队良好协作,自组织,工作高效;协调和组织scrum会议;与所有角色协同工作,移除障碍;管理团队内外依赖;支持团队,作为团队和外部的接口,屏蔽外界对团队的干扰。
B.是一个服务式的领导
通过自己的个人影响力来领导团队,而不是权利和命令;master的领导艺术在于帮助团队发现问题,引导团队自己解决问题;保护团队,确保团队纪律的执行
C.是改革的发起人
帮助产品负责人利用scrum最大化产品投资回报率并达成产品目标;用任何可能的方式帮助团队提升他们的生产力;帮助团队改进工程实践和工具,以使每个功能增量都是可交付的
D.每天的工作内容
关注团队,看他们是否专注在所承诺的工作上;确保scrum在按照正确的方式运行,并维护你子集的障碍列表;使用你全部的感觉包括常识来发现问题;帮助团队,保护团队;通过启发式的问题,引导团队自己发现问题,解决问题。
3.product owner
职责如下:
A.定义产品的愿景
B.定义产品的特性,决定版本日期和内容
C.负责产品的盈利能力和投资回报率
D.根据市场价值对特性进行优先级排序
E.可以在每个sprint改变特性喝优先级
F.接收或拒绝工作的结果
作为产品经理要避免告诉别人如何做开发,避免直接安排开发任务,不要在sprint中间该修改内容,不要强迫团队做他们不愿意做的事情,需要对团队诚实,需要做好准备后让团队开发。产品负责任需要花一半时间和客户,销售,市场在一起,另一半时间和开发在一起告诉他们正确的需求。
四,产品Backlog(PBI);story;敏捷估算;sprint执行
1.PBI
合适的详细程度,渐进明细,逐步细化。就是说越是近的需求越是详细,而且越是小,可实现,优先级越高。
PBI是一个动态列表,需要产品经常调整和维护排列。包含用户故事和技术故事(架构师/开发)。
2.story
用户故事描述的三要素:角色,活动,价值。
作为一个(角色),我想要(活动),以便于(商业价值)
举例:作为一个求职人员,我想要通过求职网站发布简历,以便于对我有兴趣的公司可以及时找到我。
用户故事的特征:独立可交付的,细节可协商的,可估算规模,足够小的,可测试的
如何分解用户故事?
根据角色(从不同用户的角度),根据业务行为(添加,删除,修改,浏览等),根据数据的分类(名称和介绍,可以浏览产品价格)
如何写验收条件?
Given(前提)+When(用户行为触发点)+Then(结果输出)
例G:我付款100美元预订了一个三周后从上海飞北京的航班;W:在航班起飞前一周,我取消了该行程;T:我应该得到预订机票半价的退款。
3.故事地图
横坐标代表时间线,从左到右是业务流程上的各种角色,纵坐标是商业价值高低。
五,技巧
1.每日站会
每天15min的状态会议;每天同一时间同一地点;针对sprint的检查适应;回答三个问题(昨天,今天,阻碍)
2.sprint评审会
输入:sprint目标;sprint承诺的产品待办条目;团队完成的条目;没有完成的待办条目;团队所做的重要决定;团队遇到的障碍
输出:版本计划的评审结果和结果更新;评审总结和改进
参与者:po,scrum master,团队,管理层,客户,干系人
3.sprint回顾会
输入:sprint评审结果;sprint工作成果;团队碰到的问题;团队对当前sprint工作的想法
输出:start,stop,continue
参与者:scrum master,team
时间盒:2h
以上是本人参加享知信息科技公司的scrum培训,感觉还是有收获的,有兴趣的可以自己去了解,希望对想了解的童鞋有所帮助,有疑问的可以探讨。