前言

互联网时代，产品迭代速度快，传统的瀑布流开发模型已经无法满足产品快速开发的需求，敏捷开发的思想应运而生。
考拉技术团队在CEO的大力推行下，一直沿用scrum开发模型，保证产品每周一次的迭代。今天我们先来入个门，了解下scrum模型的基本内容。

一、传统开发模型

在开始介绍scrum模型之前，我们先来回顾下之前软件开发模式。
起初，软件开发最基础的模型叫做瀑布模型（Waterfall Model）。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。瀑布模型下的产品开发各部分都是独立分开，各不干扰，一般适应于大型软件。但瀑布模型也存在不能在开发过程更改需求、无法赶上变化迅速的市场，容易造成资源浪费等缺点。
在这个基础上，引入敏捷开发模型对于小开发团队来说是比较合适的。

二、scrum的简介

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

Scrum作为敏捷的方法之一，用不断迭代的框架方法来管理复杂产品的开发。

原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。

三、scrum的优势

灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出，容易学习。
Why choose Scrum？ 原因如下（敏捷宣言）：

个体交互重于过程和工具；
可用的软件重于完备的文档；
客户协作重于合同谈判；
响应变化重于遵循计划。

概况地说，它适用于快速变化的市场，可以根据客户不断更换的需求，调整产品的方向，按时交付客户想要的产品。这在今天竞争激烈的市场来说，优先于竞争对手交付一个不完美但能不断改进优化的产品是非常重要的。

四、scrum中3个关键角色

scrum团队的成员由开发人员、测试人员以及其他帮助研发的人组成：
核心团队：

Scrum Master——项目负责人，帮助团队完成工作，组织日常会议和保障其他工作展开；
Team——开发人员，经常扮演多种角色，开发人员兼职测试，测试人员搬砖文案；
Product Owner——产品负责人，确定产品特性，提出产品亮点。
scrum团队的规模不宜过大，一般在3-9人为佳。

五、scrum流程

建立Product Backlog
记录已知需求并调整。
在整个开发过程中，Product Owner要不断的把已知的所有需求记录到这里面来，任何时间或步骤中产生的新需求都需要进行更新。scrum团队总是先开发对需求方具有较高价值的需求。
需求方为了能更加清晰表达需求，可用user story描述需求。user story是从用户/需求方的角度对产品的某个功能进行的简短描述，具体格式如下：

一个story的大小以及复杂度应以能在一个sprint中完成为宜。如果user story横跨了几个sprint，那个就需要进行分解成若干个task（任务），每个task的时间最好不要超过8小时.
Sprint Planning
在scrum中，sprint定义为产品的迭代周期。一般是1~6周。在一个sprint开始前，定义本次sprint要讨论的backlo为sprint backlog. 它是团队在sprint要完成的任务。
为了确定团队内部任务以及具体分工，需要进行sprint planing，由Scrum Master决定需求，然后将任务拆分，估时，并完成分配。当任务分配之后，要记录到sprint backlog中。在sprint中，scrum团队从backlog中挑选最高优先级的需求进行开发。在每次例会之后，由Scrum Master更新backlog。
Daily Scrum
也称为每日站会，一般不超过15min。参会的成员由核心团队的成员组成，每个人只说3个问题：
今天完成了哪些任务？明天的任务是什么？今天遇到了哪些问题？
每日站会的主要作用是update整个团队的进度，会上成员提出的问题不进行详细讨论，会议后master对这些问题进行解决。
Sprint Review
总结sprint的会议，在会议上会将本次sprint的新功能展示出来，并收取反馈，为下一次新的需求做准备。
Retrospective Meeting
反思sprint的会议，目的是回顾sprint过程组内成员的表现。为了让成员能够更加真实反思自己的工作情况，安全的讨论环境是必须的。在回顾会议上，主要做这三件事情：
good--如果我们可以重做同一个sprint，哪些做法是可以保留的？
could have done better--如果我们可以重做同一个sprint，哪些做法需要改变？
improvement--如何改进的具体想法？

六、scrum工具

任务板
任务板用可视化方式展示，将一个sprint分为四个阶段：
Product Backlog：按照需求的优先级，将团队在sprint中要进行的backlog放在该列；
To Do ：将当前sprint需要完成的任务放入该列；
In Progress：当团队开发进行某个任务之后，便将任务对应的卡片放到该列中。如果该任务在该列中所处时间超过1天，则应该将任务拆分为更小的部分，并将新任务放到该列中，移出原有的任务。若一个新任务因某个障碍无法完成，master就会将其标记为障碍，用特定红点标记。
Done：完成一个任务之后，便将任务放到该列。继续开始下一个任务。
看板（kanban）开发方法作为一种敏捷方式，在改善协助，优化管理、提高交付速度、质量以及灵活性方面有显著作用。下篇文章会着重讲述kanban开发模型在技术团队中的应用。
燃尽图
sprint的开发时间需要团队跟进，燃尽图可以帮助团队评估sprint开发任务的时间以及效率。
燃尽图是以图表展示随着时间的减少工作量的完成情况。燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。为了更好表示任务开发情况，团队每天要更新燃尽图，并且要根据燃尽图中任务的完成情况对任务进行调整：如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。
为了方便管理燃尽图，在设计燃尽图的时候，从简出发。
Jira
作为敏捷团队用来管理开发项目流程以及进展的工具，Jira提供了丰富的功能，方便开发团队对开发中的问题进行记录跟踪，并通过可视化图表展现出来。当团队进行一次sprint时，Jira会帮你记录任务的完成状态，团队的分工情况以及完成情况。，支持将任务简化，把开发时间分配到每个具体任务中，在规定的时间内完成任务。这与敏捷开发的思想不谋而合。

七、结束语

尽管scrum很美好很轻量，但是这种模型不一定适用于所有的企业。为了保持产品的快速优化，团队在进行敏捷开发模式的同时，还应该注重敏捷开发过程的不断优化。敏捷的出发点是为了提高工作效率，以人为本。没有谁的敏捷之路是一帆风顺，不断优化，小步快跑的方式才是敏捷可行的路。