本文主要是介绍敏捷开发系列终极之旅 第六站（像橄榄球运动一样富有激情的SCRUM），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
由来
为什么是Scrum？Scrum原本的意思是橄榄球运动的一个专业术语，指：“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球”。在敏捷开发系列中，把一种开发流程命名为Scrum，其实就意味着，这种敏捷开发的流程，就像是大家在一起打橄榄球，敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。
概念
什么是Scrum？Scrum是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程，主要用于产品开发或工作管理。Scrum于1995年提出，并在2001年同其他方法论一起组成“敏捷联盟（Agile Alliance）” 。Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。
特点
- 敏捷的流程，可用于管控研发工作
- 现有设计流程的总结
- 以团队为基础，是一种在需求迅速变化情况下迭代的、增量的开发系统和产品的方法
- 控制由利益和需求冲突导致混乱的流程
- 改善交流、协调合作的最优方式
- 检测产品开发和生产过程中障碍并将其去除的方式
- 最大化生产率的一种方法
- 适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
- 让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
Sprint（迭代）
- Scrum的项目过程由一系列的Sprint组成
- Sprint的长度一般控制在2~4周
- 通过固定的周期保持良好的节奏
- 产品的设计、开发、测试都在Sprint期间完成
- Sprint结束时交付可以工作的软件
- 在Sprint过程中不允许发生变更
开发流程
Scrum敏捷开发，是对流程控制比较严格的。每个环节都有一套完整的过程和严格的时间控制，我们项目组的主要开发过程如下图所示：
角色
ScrumMaster
- 保证Scrum团队可以遵守Scrum的价值，实践和规范
- 帮助Scrum团队和组织采用Scrum模式进行项目流程组织
- 指导并带领团队变得更加高效，实现更高质量
- 保护团队不要受到外界因素的干扰
- 保证各个不同角色之间的良好协作，消除障碍
- 帮助PO更好的利用团队的能力
- 不要管理团队
产品负责人PO（Product Owner）
- PO是一个人并只能由一个人来担任
- 负责管理产品待办事项表（Product Backlog）并保证其对于客户和团队保持透明度
- 对产品待办事项表进行优先级排序
- 与团队一起来进行工作量估算
- 对于项目的成功负责并保证投资回报率（ROI）
团队Team
- 最佳团队大小：5~9人
- 多功能团队：程序员，测试人员，设计师，数据库管理员和架构师
- 保证团队成员全职参与开发
- 自我管理，没有头衔之分，不组建子团队
- 成员更替只能在迭代之间进行，更佳方式是在发布之间进行
需要注意的是，第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。
迭代会议
每日站立会议
- 站立进行
- 在固定的时间，固定的地点
- 问题：你昨天完成了哪些工作？今天要完成哪些工作？遇到了什么困难？
- 仅仅作为信息沟通用途，不解决任何问题
- 不向任何人汇报
- 15分钟
迭代计划会议
- 进行迭代规划
- PO向团队介绍Product Backlog
- 团队在PO的协助下充分了解Product Backlog
- 确定迭代目标和迭代合约
- 对Product Backlog进行细分并创建Story（一个具体的任务）
迭代评审会议
- 团队展示完成的功能并收集反馈
- 对未完成的功能进行描述并说明原因
- PO接受/不接受当前迭代
- 邀请所有人，包括客户参与
- 4小时
迭代回顾会议
- 哪些做的好
- 哪些做的不好
- 哪些可以改进
- 进团队成员参与
- 4小时
项目管理工具
- 禅道
- JIRA
- 其他。。。
在项目初期，我们用到的管理工具是国内的一款开源软件——禅道，在项目初期，这款软件还是很强大的。开发团队在迭代计划会议中细化Product Backlog中的任务，生成一个个小的Story，然后由PO把这些Story更新到项目管理工具上（禅道）。
然后组员登录该系统，根据喜好选择并领取任务，需要注意的是，每个成员可以领取多个任务，但每天只能有一个任务是“处理中”状态，这能确保组员能够专心完成某一个任务，而不用三心二意。如果这个任务和其他任务有依赖，则可以与PO协商之后，把该任务先改为“挂起”状态，开始另一个任务。
随着开发的进行，我们的管理工具由禅道换成了JIRA，对于Scrum来说，JIRA更加的适合一些，因为JIRA在设计理念中就已经包括了Product Backlog、Sprint、Story等这些元素。同样的，由PO建立Story，组员去自由选择领取喜欢的Story进行开发。
适用的项目
刚刚了解Scrum的朋友，经常会有这样的疑问：到底什么样的项目适合使用Scrum呢？我们也一直在探讨。首先，我们来看一下关于过程的定义。过程控制通常有两种形式，一种是预定义过程，另一种则是经验性过程。
预定义过程
- 每一项工作都可以被完全理解
- 给予合理的输入定义，每次便可以得到相同的输出
- 过程启动后，允许运行直到结束，每次运行产生相同的结果
预定义过程的示例比如：生产混凝土的过程，只要原料配比确定，加入的顺序以及搅拌动作、搅拌时间确定，那么产出的结果将完全一样。
传统的瀑布开发模式是基于预定义过程来设计的。
经验性过程
- 过程是不能够完全预定义好
- 结果是不可预知的
- 生产过程是不可重复的
- 通过不断的检查和调整使得过程能够产出我们需要的结果
经验性过程的示例比如：一场足球赛，我们不可能规定好每个人的动作，我们也不能预测比赛的结果，我们只能通过激励，通过不断检视和调整团队，让他们发挥到更好的水平，以达成战胜对手的目标。
Scrum是一个经验性过程，它的核心是在项目的整个过程中提供给项目的参与者以及干系人高度的透明性，基于透明性来进行不断的检查和调整，通过不断的检查和调整持续的优化过程和产出结果，提升团队交付能力，以此达到按时交付高质量的，客户真正需要的产品。
适合管理复杂的项目
基于上述的对比，显而易见的是管理这种复杂的项目，我们不可能在一开始把整个的过程预先定义好，项目的结果如何，我们也很难再一开始就完全预知，项目存在很多的不确定性，整个项目过程也是不可能重复进行的。所以，管理这样的项目需要使用Scrum这样的经验性的过程来达到更好的效果。
一点经验
关于迭代计划会议
在Scrum敏捷开发中，迭代计划会议是项目开始之前很重要的一个会议，它决定了项目能否顺利的执行下去。而且，在迭代计划会议上，PO、架构师、开发小组成员要对Product Backlog中的需求进行细化分解，分解成最小的任务，最好是彼此没有依赖（期望值，一般这个很难实现）。任务越小，完成每一个任务花费的时间也就会越少。在分解任务时，需要小组成员给该任务评估开发时间，即用多长时间能够完成该任务（Story）。
开发中的沟通问题
在开发中，组员之间、组员与ScrumMaster之间、以及组员与客户之间的沟通是相当重要的，如果在开发中，遇到什么不确定的需求或者问题，要及时的与ScrumMaster反应，以免做一些无用之功，时间对于Scrum成员来说是很宝贵的。ScrumMaster应该确保每个成员每天的有效工作时间，为每一个成员排除一切阻碍他们开发的困难，及时发现，及时沟通，及时解决。
结语
最后，说一点别的东西。就目前软件开发的现状来说，需求的变更是很平常的事情，初期客户由于不了解自己具体所要的系统，而描述的不清楚，但随着开发的进行，随着沟通的增多，客户会越来越清楚想要开发的系统，因此在开发中经常会变更需求。
对于变更需求，传统的开发方式已经很难应对这种情况了。而敏捷开发就是应对这种需求变更最好的方式，以最小的核心需求进行开发，同时每一个迭代之后，都会以最新的需求作为目标，因此每一个迭代都会与客户的目标很接近，最终会完美的交付客户需求的系统。这就是敏捷开发的魅力所在，以最小的代价，完成最伟大的作品。
这篇关于敏捷开发系列终极之旅 第六站（像橄榄球运动一样富有激情的SCRUM）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
