scrum开发方法
一、Scrum概述
- Scrum本指橄榄球运动中的“争球”的动作——团队通力合作，在场地内传球。这个过程需要认真配合、信念一致、目标明确。这个过程完美体现了对一个团队的所有要求。
- 用Scrum命名一种开发过程，比喻开发团队在开发一个项目时，像打橄榄球一样迅速、激情，人人你争我抢地完成它。
- Scrum 方法——简单说，就是以 交付 与 迭代 为核心的方法。「每过一小段时间就停一停手头的工作，检查一下已经完成了哪些任务，看看这些任务是不是自己应该做的，看看有没有更好的方法」
二、Scrum中三个角色
1、Product Owner职责
| 职责 | 诠释 |
|---|---|
| 1. 对产品的ROI负责 | ROI = profitability of the product，ROI即为产品的盈利负责，或考虑产品的投资回报率。 |
| 2. 梳理产品列表，确定产品功能 | PO负责梳理产品列表，包括PBI的建立、细化、估算和排列优先级顺序。在估算期间负责澄清需求。 |
| 3. 参与规划活动，决定发布的日期和内容 | PO做组合规划、产品规划、版本规划和Sprint规划的重要参与者。 |
| 4. 定义接收标准并验证工作成果 | PO负责为每一个PBI定义验收标准，只有达到这些条件才确信功能需求和非功能需求已经满足。 |
| 5. 与开发团队合作 | PO必须经常与开发团队保持紧密合作，每天参与到团队活动中，产品负责人与开发团队一起确定Sprint目标。 |
| 6. 与利益干系人合作 | 产品负责人与利益干系人一起制定产品愿景，以及确定下一个版本的内容。内部利益干系人：业务系统负责人、行政管理人员、项目管理人员等外部利益干系人：客户、用户、合 作伙伴等。 |
2、Scrum Master职责
| 职责 | 诠释 |
|---|---|
| 1. 教练 | 关注每一个个体的思想和行为，并指导他们，让团队处于持续的提升，组织处于和Scrum团队真切合作的状态。 |
| 2. Scrum专家 | 搭建让团队合作的舞台，并提供清晰的边界。把敏捷的知识与经验传授给团队，确保团队理解并实践Scrum和其他相关的方法。 |
| 3. 推土机 | 推动一切阻碍开发团队工作的问题。在兼顾团队自组织能力的情况下，帮助团队解决影响团队工作进展的障碍。 |
| 4. 保护伞 | 保护开发团队免受外部的干扰，确保团队能集中精力完成冲刺。 |
| 5. 服务型领导 | 关注于团队成员的需求，以及通过实现组织的价值、原则和商业目标从而提供价值给顾客的人。 |
3、Scrum Team职责
| 职责 | 诠释 |
|---|---|
| 1. Sprint执行 | 开发团队的大部分时间都花在Sprint执行上。 |
| 2. 每日检视和调整 | 每个开发团队成员都应该参与每日站会，一起检验Sprint目标的进展情况，跟进当天的工作情况调整计划。 |
| 3. 梳理产品列表 | 每个Sprint都需要花一些时间来准备下一个Sprint，主要用来梳理产品列表，包括PBI的创建和细化、估算和排列优先级顺序。 |
| 4. Sprint规划 | 在Sprint计划会议（Sprint Planning Meeting）上，在ScrumMaster的引导下，开发团队和PO合作合作为下一个Sprint建立目标。 |
| 5. 检视和调整产品与过程 | 每个Sprint结束后，开发团队都要参加两个检视和调整的活动，即Sprint评审会议（Sprint Review Meeting）和 Sprint回顾会议（Sprint Retrospective Meeting）。评审会议上所有人一起评审当前Sprint完成的特性，并讨论下一步改进措施。回顾会议上Scrum团队检视和调整自己的Scrum过程和技术实践，进一步改善团队使用Scrum来交付业务价值的方法。 |
三、Scrum中三个工件
1、Product Backlog（产品功能列表）
- Product Backlog是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。内容包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。
- Product Backlog就是一个积压的需求池，池中内容如上页所述可以是需求、BUG、优化项等。对于这个池中优先级排序、删除、添加等只有PO才有权限操作。对于池中的的需求来源不一定只是PO收集，可以是来自各个相关干系人如开发、客户、测试等。
- Product Backlog形成于项目规划阶段，需求的粒度可以渐进明细进行细化，发布计划时只需要确定前面的1个或是几个Sprnit故事粒度，后面的需求可以滚动式的方式来做拆分细化。
注：Product Backlog由PO维护，但其估算是由团队来进行相关的粗略估算。
2、Spring Backlog（迭代冲刺列表）
迭代冲刺列表是当前Sprint需要完成的用户故事，是当前的冲剌列表。冲刺列表从已排序且经过估算的Product Backlog中挑选。后续这个迭代中的所有任务拆分和跟综都以此列表为准，Sprint Backlog一但确认后续对于新的添加随不可随意更改。敏捷虽然拥抱变化但也有自身的规范，当变更添加或是减少相对的User Store时，就要减少或放入相对故事点大小的其他用户故事。
3、Burn Down Chart（燃尽图）
燃尽图(Burn Down Chart)。是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的单项的数目。通常用于敏捷编程，下面是一个具有代表意义的燃尽图。
四、Scurm中四个会议
1、Sprint Planning Meeting（迭代计划会）
迭代计划会时间（timebox-时间盒）的长度与sprint长度有关，一般 2 hour/week时间会议安排，此会分为上下两个部分，上部分基本为确定Sprint目标挑选故事后半部分为技术架构讨论。
参会人员：PO, SM, Team
- 团队决定挑选将要完成那些User Store
- 团队决定这个Sprint中将完成的工作量
- 确认DOD
2、Sprint Review Meeting（迭代评审会）
冲刺回顾会由开发团队按照迭代速度确定的演示日期，向产品经理和其他成员演示Sprint的成果，对当前Sprint的结果和整个产品的开发状态达成共识，一般 1 hour/week时间会议安排。
参会人员：PO, SM, Team
- 即使有未完成的故事点也需要做评审会，尽量展现已完成的功能。完成意思是说评审、开发、验收测试等全部通过
- 如果PO想要改变功能添加一个新问题到产品Backlog中
- 如果对功能有一个新的想法,添加一个问题到产品Backlog中
- 如果小组报告项目遇到阻碍还没能解决,把问题加入障碍Backlog中
3、Sprint Retrospective Meeting（迭代回顾会）
冲刺回顾会一般和评审会议一起召开两者一前一后，一般 1 hour/week时间会议安排，同样此会也分为上下两个部分：
- 上部分：分析这个迭代中做的好的点与不好的点，确认需要改进的条目和具然条目的优先及，改进问题的方案。
- 下部分：对接下来的一个迭代进行粗略的用户故事讨论，并做好相关预备的一些提前工作确认。
参会人员：SM, Team, (PO)
4、Daliy Scrum Meeting（每日站会）
站会主要进行大家信息共享与工作透明，用于消除相关工作中的瓶颈和问题障碍。会议中大家自发组织无需要主持和被点名来进行工作说明，会中除开Scrum Master其他每一个人都应该说明自身的工作和遇到的问题，会议一般15 minute以内。
参会人员：SM, Team (有些干系人可参会但不出席)
- 昨天完成了什么工作
- 今天准备完成什么
- 遇到了什么问题
- 移动看版中完成的任务，主动领取新的任务
注： 只提出问题落实到对应的问题解决人，不处理的具体问题
五、尾声
敏捷性可以保证公司高效地运转吗？很遗憾，敏捷不能。彼得·德鲁克曾经说过一句让人印象深刻的话：“效率就是把事情做对，有效就是做正确的事。”敏捷性是要确保在错综复杂的市场环境里你具备足够的灵活性来调整自己以适应环境，即有效——做正确的事。
其实，敏捷转型对于团队中的每一个成员来说都是挑战。人的本性是讨厌改变的。所以不光是中国的团队在转型中会遇到严重的抵触，各个团队都会遇到。所以，单纯是因为惧怕改变而带来的抵触并不能成为拒绝转型的原因。你需要更多的智慧去解决这种抵触。
