第二章 我们怎样编写产品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数据文档