type
status
date
slug
summary
tags
category
icon
password
前言
在开始阅读本篇文章之前，我们需要明确 Agile 与 Scrum 之间的关系。
Agile（敏捷）是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
Scrum 项目管理是最流行的敏捷方法之一。
在本文中，我们主要介绍 Scrum 相关的一些概念以及流程。
Scrum vs Waterfall
首先让我们对瀑布流开发和敏捷开发的流程做一个对比。
瀑布流开发
瀑布式开发通常会花几个月时间来规划产品，然后再花几个月时间研发产品，接着进行产品测试、评审，最终发布产品。
重点是，如果市场需求或者技术环境发生变化，你此时研发出的产品很可能无法满足市场需求，瀑布式开发在遇到这种变化时会出现很多问题。
首先，产品规划必须早于后续工作之前完成，绝大部分案例中，规划环节结束时并没有有完全理解项目，但研发工作已经完成了。通常情况下，整个项目必须送回规划阶段，然后从头再来，否则，研发人员就会因为不明白产品规划而受到批评。这种情况会反复出现，比如研发完成了，进行产品测试，发现问题就得重新开发，有时甚至要重新规划产品，在接下来的几个步骤中，也会多次出现同样的问题，这很可能导致产品发布时间跳票，短则几个月，长则数年。
敏捷开发 Scrum
当我们用 Scrum 来实施敏捷开发时就大不相同了，整个项目会被分解长不同的小部分：
- 首先，我们围绕最小化可行产品的特性进行产品规划，我们把最小可行化产品开发出来；
- 接下来，我们测试和评审这个产品，直到准备发布
循环这个过程，我们就会得到一个可发布的产品。这个过程通常只需要一到三周左右，我们不断重复这个过程，以减少从产品规划到开发测试每个阶段的时间，我们去做详细的规划来完成下一个增量式发布。而你此时得到了几个增量式版本，称为 Sprint（冲刺），而你只是不断重复 Sprint 直到你的产品功能齐全。
相关概念
接下来我们来了解一下 Scrum 中涉及到的一些概念。
三个角色
在 Scrum 的方法体系内，有三个关键角色能帮助团队工作的更好：
- Product Owner（产品经理）：负责确定产品特性、提出产品亮点
- Scrum Master：整个团队的负责人，负责帮助团队尽其可能完成工作、组织日常会议和保障其他工作
- Team：由开发人员、测试人员、文案以及其他帮助研发的人组成，负责帮助产品完成
三种可视化文档
在 Scrum 的方法体系内，有三种可视化文档帮助团队记录工作：
- 产品需求列表（Product Backlog）
- 用户故事（User Stories）
- 燃尽图（Burndown Chart）
产品需求列表（Product Backlog）
产品经理会先从众多故事（stories）中筛选出优先项，并把它们列入产品开发列表中，需求列表会随着每次的 Sprint 迭代和更改。
用户故事（User Stories）
用户故事是一种表达产品需求的语言格式：
As a user, I need something so that reason
产品经理通过用户故事来了解需求的细节，为 Scrum 团队合理制定任务优先级，优先级最高的用户故事将进入 Sprint 待办列表，剩下的继续评估优先级，挪到下次 Sprint 中。
燃尽图（Burndown Chart）
燃尽图用于显示整个 Sprint 待办列表的进度，当燃尽图曲线接近于 0 时，也就意味着这次 Sprint 即将完工。
三种会议
Scrum 方法中有三种不同形式的会议需要用到：
- Sprint 计划会议
- 每日例会
- 回顾会议。
Sprint 计划会议（Sprint Planning）
Sprint 计划会议是产品经理、Scrum Master 和 Team 碰头的会议，用于讨论用户故事并估算任务量。
每日例会（Daily Scrum）
每日例会，也就是我们熟知的站会，整个团队会简述工作进度，并且讨论是否有任务需要搁置或是加派人手。
回顾会议（Sprint Review）
Sprint 临近尾声时，我们会进行 Sprint 回顾会议。
这时研发团队会向经理演示开发好的功能，然后整个团队讨论是否有需要改进的地方。
工作流程（Workflow）
了解了各种概念之后，我们一起来看一下 Scrum 的工作流程。
- 首先，产品经理把那些需要上线的产品特性做成产品需求列表（Backlog），然后由产品经理甄选出最优项，准备交给整个团队讨论。
- 第二阶段，召开 Sprint 规划会议，研发团队、产品经理和 Scrum Master 讨论用户故事优先项，并且决定下次 Sprint 要研发的需求项。
- 第三阶段，根据 Sprint 规划会议制定 Sprint 需求列表，这个列表就是指经过团队讨论后的用户故事，用于下次的 Sprint，会议结束后，整个研发团队和产品经理必须要对每个用户故事有深刻的理解。
- 第四阶段，研发团队要在一到三周的时间里开发完成 Sprint 列表中的需求。
- 在 Sprint 期间，每日站会用户团队来交流他们做完了什么，正在做什么，以及遇到的问题。
- Sprint 的产出是一个可以发布的产品版本，是否可发布由产品经理来决定，也可以在发布前增加新功能。
- 第五阶段，在 Sprint 结束时会举行 Sprint 回顾会议，由研发团队向产品经理做案例演示，同时团队一起反思工作中可以改进的地方，每次的 Sprint 结束后都要进行这种回顾。
结语
每个团队在进行敏捷开发的过程中，都会有不同的地方，也会遇到不同的问题，可能是因为组织文化导致的，而且敏捷自身也是在不断演化之中。这个时候就要求我们及时做出改变，不要因为某些问题而放弃敏捷开发。可以通过适当地调整来适应团队的实际情况，像架构一样不断地去演进。
- Author:大胖猫
- URL:http://preview.tangly1024.com/article/223f4632-e87d-8074-8826-c63aaf83b84a
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
