Scrum敏捷过程实践

经典的敏捷过程 (Scrum)

敏捷的开发宣言

1、个体和交互胜过过程和工具

2、可工作的软件胜过面面俱到的文档

3、客户协助胜过合同谈判

4、响应变化胜过遵循计划

敏捷专用软件有很多，例如：

VersionOne、ScrumWorks、XPlanner

但由于软件使用需要学习成本，研发人员不适应，所以我们还是采用了纸板的方式，直观高效

步骤一：Sprint会议

Sprint目标

团队成员名单

sprint backlog

sprint 要完成多少故事

sprint demo 日期

Daily Scrum 时间地点

会议议程

0.5h 负责人对目标整体进行介绍

1.5h团队估算时间

1h 团队选择要放入sprint 中的故事，计算生产率

会议过程中是下面这样的方式，白板左边最重要，右边最不重要，由设计、研发、测试共同决定重要程度，进行临时调整排序

会议产出下面的Product Backlog表格，每一条是一个任务，理论上应该为用户故事(User Story)但是实际执行过程中发现，程序员更希望细化为一个任务，这里有些偏离了Scrum的方向，但是从实际效果来看没有收到影响。

由Product Backlog的Excel表格自动生成下面的任务卡片

Sprint会议结束后会将卡片贴到敏捷板上，敏捷板通常放置在离研发最近的位置上，随时可以看到，敏捷板的布局如下：

从左到右：1. 未完成 2. 研发完成待测试 3. 测试完成

步骤二：正式迭代

一开始所有卡片都在1区，随着Sprint进行，卡片一一移动到3区，理想状态下，在迭代结束时应该所有的卡片都移动到了3区

期间，没有其他需求进入，设计、研发、测试都为了sprint计划定制的Backlog努力，安心不被打扰

这个过程当中，每天小组都开站立会议，10分钟内，每个人描述

自己昨天做了什么

今天要做什么

有何困难

步骤三：Sprint Demo会议

在一个迭代周期结束时要进行Sprint Demo 演示，这个过程任何人都可以参与，包括其他项目组、领导，没有实际任务考核，压力来自于团队内部，演示效果决定了大家对这个小组成员能力的评估

Sprint Demo的优点：

团队的成果得到认可

其他人了解团队在做什么

吸引相关人员注意，得到反馈

使团队完成100%的工作，而不是99%

Sprint Demo 原则

目标清晰

不要花太多时间准备

节奏要快

注重表示业务层，而不是技术细节

不需要演示bug和微不足道的小特性

步骤四：Sprint Review回顾会议

参与人员为小组内部人员，其他相关人员不得加入，属于团队内省阶段，大家将目前的问题暴露出来，以供下一个迭代时改进

Sprint Review 回顾

做改进的最佳时期

怎样做才能让下一个sprint更好

Good/Better

Improvements

至此，一个Sprint迭代完成，这个过程的周期根据具体情况来拟定，一开始我们使用3周，发现不利于变化，随后更新为单周迭代，三周大迭代(可发布)，这样既保证了相对稳定，又满足了需求变化的特性，同时也对Sprint进行了一些简化。

实际的效果较为理想，但是执行阶段

END