本人参加了敏捷培训，将培训内容结合自己的实践分享一下，希望对同行的小伙伴有所帮助。本文分以下几个部分：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培训，感觉还是有收获的，有兴趣的可以自己去了解，希望对想了解的童鞋有所帮助，有疑问的可以探讨。