Scrum敏捷精要
本文抽取Scrum中的一些重要思想和概念，对Scrum敏捷执行的主题流程进行精要的介绍。
一、基本思想
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
二、主要特性：
- 迭代式、增量式
- 自组织的小团队
- 快速反馈的短周期
- 按照业务价值的优先级排序
三、scrum中的角色
Stakeholders：利益相关人
Scrum master：保证流程正确
四、开发过程
- 产品规划
- 编制用户故事列表（Product Backlog）
- 制定迭代计划（Sprint Planning）
- 迭代开发
- 迭代评审、回顾
- 制定发布计划（Release Planning）
五、用户故事
icesrcum：用户故事管理软件
用户故事是什么？
描述系统需求的一个单元，（“谁” “做什么”）[ “目的”]
特性：
- 独立
- 可更改
- 有价值
- 可估计
- 大小合适
- 可测试
实践：
- Product Owner提出最初的产品设想，主要的用户故事
- 头脑风暴
- IceScrum
- 任何人都可以创建用户故事，新创建的故事放在Sandbox中
- 开会讨论，建立用户故事列表（Product Backlog）
六、迭代计划
- 调整用户故事（增加、删除、修改、改变优先级等）
- 确定迭代时间长度
- 描述迭代目标
- 按照优先级选取用户故事
- 每个用户故事的工作量估计
- 任务分解
- 确定迭代演示和回顾日期，并立刻发出会议通知
- 确定每日站立会议时间，并立刻发出会议通知
每个用户故事的工作量估计
- 用户故事描述的比较详细，单位： “理想人天”
- 使用“计划扑克牌”（Planning Poker），可选值：0 ， 1 ， 2 ， 3，5 ， 8 ， 13 ， ？
- 理想人天*1.5
- 关于迭代速率（velocity）的历史数据
- 团队成员都可以针对用户故事给出自己的工作量评估牌
任务分解
- 会议结束之后，所有细分任务都有一个明确的责任人
- 确定迭代演示和回顾日期，并立刻发出会议通知
- 确定每日站立会议时间，并立刻发出会议通知
七、迭代开发
- 团队沟通和协作
- 参考使用XP（极限编程）的工程实践，如持续集成、重构、结对编程等
- 代码审查
- Bug生命周期管理
每日站立会议主题：昨天做了什么，今天计划什么，有什么问题（迭代计划并不确定任务的完成时间段）
实践：
及时更新IceScrum系统中任务的状态
不定期的结对编程
代码审查
-
- 迭代内，所有代码都要被审查
持续集成
-
- 持续构建
- 持续审查
- 持续测试
- 持续数据库集成
- 持续部署
- 持续通知
Bug跟踪：
- 我们目前使用Redmine作为工具
- 任何人发现bug，都可以提交
- 一些小的功能增强，也可以bug的方式进行跟踪
八、迭代演示和回顾
迭代演示 （Sprint Review）
- 一定要有一个可工作的迭代增量
- 对管理层：更好的项目可视度
- 对团队：阶段性压力、阶段性成就感 – 激励团队
迭代回顾（Sprint Retrospective）
- 针对工程实践，而不是产品功能本身
- 做得好的：用户故事裁剪
- 需要改进的：持续集成
实践：
- Scrum Master主持会议
- 查看迭代目标和迭代内承诺交付的用户故事
- 产品演示
九、发布计划
工作量估计
速率（velocity）估计
- 根据以往迭代，进行估计
- 留有余地
确定之后，要明确告知团队和相关利益负责人
可以调整
- 记住，范围（发布那些用户故事）是有弹性的
十、Scrum整体流程最佳实践
- 估计用户故事之前，要明确其范围
- 使用“计划扑克牌”（Planning Poker）的技术进行估计
- 端到端的集成，从第一个迭代开始，贯穿始终
- 迭代计划会议上明确任务分解和责任人
- 迭代演示和回顾日期在迭代计划会议之后就确定，并立刻发出会议通知
- 渐进式功能开发，过早优化是陷阱
