敏捷开发之三——像橄榄球运动一样scrum

scrum原本的意思是 ，在橄榄球比赛中，“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球”。在敏捷开发系列中，把一种开发流程命名为Scrum，其实就意味着，这种敏捷开发的流程，就像是大家在一起打橄榄球，敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。

概念：

什么是scrum？scrum是一中灵活的软件管理方式，他可以帮助驾驭迭代，递增的软件开发过程。主要用于产品开发和工作管理。scrum在1995年提出，并在2001年与其他方法并称为“敏捷联盟”。scrum提出了一种经验方法，它使得团队成员能够独立的，集中的在创造性环境下工作。

特点：

敏捷的流程，可用于管控研发。

现有设计流程的总结。

以团队为基础，在需求迅速变化的情况下迭代的，增量开发系统和产品的方法。

控制由利益和需求冲突导致的混乱流程。

改善交流，协调合作的最优方式。

检测产品开发和生产过程中障碍并将其去除的方法。

最大化生产率的方法。

适用于单一的项目到整个组织，scrum可以组织多件具有相关性的产品开发以及拥有超过千名开发者的项目实施过程。

让每个参与者都对自己所做的工作及自己做出的贡献感到骄傲，并让他们发挥最好水平。

sprint（迭代）

scrum有一系列的迭代组成。

迭代长度一般控制在2-4周

通过固定的周期保持良好的节奏

产品的设计开发和测试都在sprint内完成

sprint结束时交付可以使用的软件。

在sprint过程中不可以发生改变

流程：

scrum对流程有比较严格的把控。

角色：

scrummaster：

保证团队可以遵循scrum的价值，实践和规范。

帮助scrum团队和组织采用scrum模式进行项目管理流程组织。

指导并带领团队变得更加高效，实现更高质量。

保证各个角色良好协作，消除障碍。

帮助po更好的利用团队的能力。

不要管理团队。

产品负责人（PO）

PO是一个人并只能由一个人来担任

负责产品待办事项表（backlog）并保证对客户的透明度

对产品待办事项进行优先级排序。

与团队一起进行工作量的估算

对于项目的成功负责，并保证投资回报率（ROI）

团队Team（最佳团队5-9人）

多功能团队：程序，测试，设计师，数据库管理员和架构师。

保证团队成员全职参与开发。

自我管理。没有头衔之分，不组建子团队。

成员更替只能在迭代之间进行，更佳方式是在发布之间。

迭代会议：

站立会议

在固定时间，固定地点

昨天做了什么，今天要做什么，遇到了什么困难

仅仅作为信息沟通用途，不解决任何问题。

不想任何人汇报

15 min

迭代计划会议

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应该确保每个成员每天的有效工作时间，为每一个成员排除一切阻碍他们开发的困难，及时发现，及时沟通，及时解决。
结语
最后，说一点别的东西。就目前软件开发的现状来说，需求的变更是很平常的事情，初期客户由于不了解自己具体所要的系统，而描述的不清楚，但随着开发的进行，随着沟通的增多，客户会越来越清楚想要开发的系统，因此在开发中经常会变更需求。
对于变更需求，传统的开发方式已经很难应对这种情况了。而敏捷开发就是应对这种需求变更最好的方式，以最小的核心需求进行开发，同时每一个迭代之后，都会以最新的需求作为目标，因此每一个迭代都会与客户的目标很接近，最终会完美的交付客户需求的系统。这就是敏捷开发的魅力所在，以最小的代价，完成最伟大的作品。