经典的敏捷过程 (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