敏捷开发——硝烟中的Scrum和XP

第二章 我们怎样编写产品backlog

• backlog包括：ID、名称、重要性、初始估算、如何演示、注解（额外的故事字段：类别、组件、请求者、Bug跟踪ID）

产品Backlog(示例)

ID	名称	重要性	初始估算	如何演示	注解
1	存款	30	5	登录，打开存款界面，存入10欧元.	需要UML顺序图。目前不需要考虑加密。

• backlog停留在业务层次上

  开发团队：如何解决问题；

  产品负责人：关注业务目标；

  示例：

  故事——“给Events表添加索引”[错误，可以加进注解]，目标也许是“提高在后台系统中搜索时间表单的响应速度”[正确]。

  ​

第三章 我们怎样准备sprint计划

确保backlog井然有序（产品的backlog必须存在）

标准

• 只能有一个产品的backlog和一个产品负责人
• 所有重要的backlog都根据重要性被评过分
• 产品负责人理解每个故事的含义
• 使用Jira（Bug跟踪系统）存放产品backlog
• 使用VersionOne、ScrumWroks这种敏捷过程工具

第四章 我们怎样制定sprint计划

计划会议产生的效果：

• sprint目标
• 团队成员名单
• sprint backlog
• 确定好sprint演示日期
• 确定每日Scrum会议的时间和地点

每个故事有三个变量：范围（包含哪些故事）、重要性、估算

产品负责人必须参加

产品负责人设置：范围和重要性

团队设置：估算

不能在质量上让步

如果sprint会议超出了计划时间，直接打断会议。

sprint会议日程

• 13：00——17：00（每小时休息10分钟）
• 13：00——13：30 产品负责人对sprint目标进行总体介绍，概括产品backlog
• 13：30——15：00 团队估算时间，必要时可以拆分backlog
• 15：00——16：00 团队选择放入sprint的故事
• 16：00——17：00 为每日scrum会议安排固定时间和地点

确定sprint长度，3周不错

确定sprint目标，可以在wiki上列出来，方便大让所有人都知道我们在干什么

产品负责人可以通过更改backlog的重要性来影响sprint

通过估算生产率来决定把哪些故事放到sprint里面

明确故事内容

把故事拆分成任务：

• sprint计划会议要足够长，保证有时间进行任务拆分

定下每日例会的时间地点 ？讨论什么，多长时间

• 技术故事

第5章 我们怎样让别人了解我们的sprint

第6章 我们怎样编写sprint backlog

燃尽图

• y轴故事数量
• x轴时间

当每日的点连到一起的曲线在x轴y轴的斜线之上，表示放到sprint中的故事多了。反正表示少了。

第7章 我们怎样布置团队房间

让团队坐到一起

第8章 我们怎样进行每日例会

• 不超过15分钟
• 更新任务版
• 处理迟到的家伙
• 处理不知道干什么的家伙

第9章 我们怎样进行sprint演示

• 必须做
• 团队成果得到认可
• 得到重要反馈
• 讨论
• 迫使去完成一些真正的工作
• 确保清晰阐述sprint目标
• 节奏要快
• 关注业务层次

第10张 我们怎样做sprint回顾

• 1到3小时
• 哪些做得好
• 哪些可以做的更好
• 那些需要改进

在团队间传播经验

第11章 sprint之间的休整时刻

最好的安排

周四	周五	周六	周日	周一
09-10:Sprint 1 demo	实验日			9-13:Sprint 1 demo

第12章 怎样制定发布计划，处理固定价格的合同

• 定义你的验收标准
• 对重要的条目进行时间估算
• 估算生产率
• 统计一切因素，生成发布计划
• 调整发布计划

第13章 我们怎样结合使用Scrum和XP

• 结对编程
• 测试驱动开发
• 增量设计：一开始保持设计简化，不断改进
• 持续集成：每天晚上，持续构建服务器都会从头构建产品，并且向我们的内部文档门户上发布二进制文件、文档、测试报告、测试覆盖率报告和依赖性分析等等
• 集体代码所有权
• 代码标准
• 充满信息的工作空间：需要里有个人管理任务版和“怎样布置团队空间”
• 可持续的开发速度/精力充沛地工作：正常上下班

第14章 我们怎样做测试

• 把验收测试阶段缩到最短
• • 提高代码质量
  • 提高测试效率
  • 把测试人员放到Scrum中（除了测试还要做，搭建测试环境、明确需求等等）
  • 减少sprint工作

别把最慢的一环逼得太紧（开发、测试等）

第15章 我们怎样管理多个Scrum团队

• 创建多少个团队
• • 分拆成彼此不干扰的小团队
  • 宁可团队数量少，人数多
• 最佳的团队规模
• • 3到8个人最佳，人多把最差的排除
• 几个团队做一个sprint
• 团队中分配人手：指定一个人分配和团队自己决定

第16章 我们怎样管理分布式团队

• 能够一起结对编程
• 能够在每日例会上面对面交流
• 在任何时候都能够面对面讨论
• 可以真正的碰面与交往
• 整个团队可以主动举行会议
• 团队对sprint backlog、sprint燃尽图、产品backlog和其他信息传递设备有相同的理解

第17章 ScrumMaster检查列表

• sprint开始阶段
• • sprint计划会议之后，创建sprint信息页面
  • 给每个人发邮件，声明新的sprint启动
  • 更新sprint数据文档：估算生产率、团队大小和sprint长度
• 每一天
• • 确保每日scrum会议可以按时开始结束
  • 为了保证sprint可以如期完成，适当的增删故事
  • 团队了解backlog和燃尽图
  • 确保存在的问题和障碍都能被解决。
• 在sprint结束时
• • 开放式sprint演示
  • 演示前一天告知所有人
  • 整个团队一起开sprint回顾会议
  • 更新sprint数据文档