敏捷开发是一种观点和价值观，倡导不断响应变化 。敏捷开发产生以前，由于软件开发和传统行业天然的有着鸿沟，几乎用尽了以往所有的经验办法，都没法做到详实的很精确的控制。有人便提出了，既然不能控制变化，何不去响应这种变化，敏捷宣言也由此产生。

但敏捷开发实际上只是个概念，而怎么落实这个概念呢，怎么转变成敏捷团队呢，就需要运用敏捷的各种方法论和实践。例如，源于丰田公司的精益软件开发，新兴测试方式-探索性测试，测试驱动开发等。

相比其他的敏捷方法，Scrum覆盖了从需求到上线的全过程，因而备受产品研发团队的青睐，接下来我们重点讲讲Scrum。

标准的Scrum流程

Scrum是一系列实践和预定义角色的过程骨架 ，定义了要达成敏捷的流程和方法。简单来说，你想要成为Scrum团队，你都需要什么样的角色、做什么样的事、开什么样的会……只要按照Scrum的方法论去做，你就能变成Scrum团队，也就是敏捷团队。

Scrum团队一般有三种角色： Product Ower（PO）、Scrum Master、 Dev Team 。标准的Scrum运行流程是，PO基于产品愿景，创建多个产品Backblog，即所要完成的各种功能需求，然后产品Backblog会被拆分成一个个Sprint，在一个个Sprint周期之内，不断地完善产品。

在Sprint计划会议上，PO会基于产品Backblog的优先级，筛选出最应该做的Backblog，然后让成员给Backblog打分，确定Backblog的规模。然后，PO再规划好每个Sprint的需要做的内容。接着就开始Sprint周期，由团队成员去设计、编码、测试等。Sprint完成后，每个成员用Demo演示自己负责的Backblog，让PO评估是否完成。最后在Sprint复盘会上 ，整个团队沟通上个Sprint执行中的问题和改进点。这就是一个完整的Sprint的流程。

我们是怎么做的？

上面说的是比较理想化的Scrum流程，但实际工作场景中，我们总会遇到各式各样的问题，接下来我会讲我所在的团队是怎么执行Scrum的。

1、需求管理

管理需求的第一步首先是要进行需求的收集。我们的需求来源除了产品经理自己通过市场调研等各种渠道分析出的需求，来自用户的需求、建议、缺陷，都是由销售、客户成功的同事在一个公开的项目（公共Backlog）中提交，需求卡片中我们会设置的一些关键属性，如需求描述、功能分类、需求类型、需求来源等。

由产品经理（PO）牵头，连同设计师组成需求评审小组，每周四定期将本周创建出来的问题统一处理，并加以分类；评审小组会对这些需求，进行合理性的评估、优先级的评估、异常处理结果等。评审过的需求形成产品Backlog。

2、迭代规划

产品经理会根据产品Backlog列表，联合设计、开发人员做工作量的预估和安排，在迭代开始前召开迭代计划会议，从中挑选出N个Story作为本次迭代完成的目标，确认需求交付的验收标准，然后把这个Story进行细化，形成一个Sprint Backlog。

有经验的Scrum团队会根据任务规模，安排迭代的数量，确定一个迭代。任务规模并不是一个“／人／天”的单位，而是敏捷团队通过长期实践确定的需求规模的描述单位，建议敏捷团队在开始阶段将规模设置为，团队内一般水平工程师一天的工作量，后续不断优化调整。

3、进度管理

通过故事板、燃尽图、任务列表等视图，团队成员能随时了解到迭代情况和进度。每日站会上，我们会用Worktile故事板展示当前Sprint的进度，并通过每个人的发言了解成员工作的进度。

此外，产品负责人会定期查看Sprint燃尽图，查看迭代工作总量中仍需完成的工作余量，如果实际工作线高于计划曲线，则意味着剩下的工作量比预期多，Sprint可能有失败的风险。

4、评审回顾，总结沉淀

开发负责人总结代码构建和审查情况，测试负责人总结此迭代的测试报告，产品负责人总结进度过程的得失，记录改善结果，应用到下一次迭代中。
这些可用Worktile在线文档协作完成。

产品负责人总结进度过程的得失，可依据项目中的【统计报表】和【迭代概述】。

Scrum有哪些会议？

标准的Scrum流程包含了四个类型的会议，即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective，每类会议主要做些什么呢？

——————————————————
Worktile拥有专业的敏捷研发模板，能适配整个敏捷开发周期，贯穿需求管理、迭代规划、进度管理、缺陷追踪、总结沉淀等流程。更有数据源级别的可配置化模板、精细化角色模式、集成了100+第三方应用，欢迎大家免费试用。→Worktile敏捷开发

拓展阅读：
《Worktile 敏捷开发解决方案来》
《Worktile 首席架构师详解：如何让敏捷更好地落地？》