硝烟中的Scrum和XP (豆瓣)

副标题: 我们如何实施Scrum
作者: Henrik Kniberg
译者: 李剑
出版社: infoQ
出版年: 2008
页数: 133
ISBN: 9789781430329

8.8

(186人评价)

50.5%

41.4%

8.1%

0.0%

想读在读读过

评价:

内容简介 · · · · · ·

　　在本书中，作者Henrik Kniberg讲述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等，还试过了把XP跟Scrum组合。
　　本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。

作者简介 · · · · · ·

　　Henrik Kniberg（henrik.kniberg@crisp.se）是一名咨询师，在斯德哥尔摩的Crisp公司（www.crisp.se）工作。他的专长是Java和敏捷软件开发。
　　自从第一本有关XP的书籍和敏捷宣言问世以来，Henrik就开始拥抱敏捷原则，并尝试在不同的组织中进行有效应用。在1998年至2003年间，他作为Goyada的合作创始人和CTO，构建并管理一个技术平台和30人的开发团队，充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信息：http://www.crisp.se/henrik.kniberg

目录 · · · · · ·

第1章简介
免责声明
撰写本书的原因
Scrum到底是什么
第2章我们怎样编写产品backlog
额外的故事字段
· · · · · · (更多)

豆瓣成员常用的标签(共41个) · · · · · ·

Scrum(118) 项目管理(76) 敏捷(57) 敏捷开发(52) 软件工程(36) agile(25) XP(23) 软件开发(15)

喜欢读"硝烟中的Scrum和XP"的人也喜欢 · · · · · ·

: Scrum敏捷项目管理

: 项目管理艺术

: Scrum敏捷项目管理实战

: Effective Java 中文版

: 项目管理修炼之道

: 人月神话

: 重构

: Getting Real

: 成为技术领导者

: Effective Java中文版

读书笔记 · · · · · · (共2篇)
我来写笔记

按有用程度 按页码先后 最新笔记

第42页

bob.jiang

有关Sprint计划： 1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说 1.1 产品backlog必须存在 1.2 只能有一个产品backlog和一个产品负责人 1.3 所有重要的backlog已经根据重要性打过分。 1.4 产品负责人应该理解每个故事的含义。总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprin... (更多)

有关Sprint计划：
1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说
1.1 产品backlog必须存在
1.2 只能有一个产品backlog和一个产品负责人
1.3 所有重要的backlog已经根据重要性打过分。
1.4 产品负责人应该理解每个故事的含义。
总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprint可以完成的backlog）
2. Sprint计划有哪些产出结果：
2.1 Sprint目标
2.2 团队成员名单，以及他们的投入度
2.3 Sprint Backlog （应该是产品Backlog中重要性最高的一部分）
2.4 确定好的Sprint演示日期
2.5 确定好每日站会的时间地点
3. 如何决定哪些故事需要放到sprint里面？
3.1 本能反应 - 比如Scrummaster问团队，这个sprint我们可以完成这3个故事吗？
3.2 生产率(Velocity)计算 - 根据过去的sprint进行下一次的生产率估算
4. sprint计划会议时，把用户故事打印成索引卡，在每个选择的故事下细分任务（用便签）Henrik提供了一个非常好生产索引卡的脚本 http://blog.crisp.se/henrikkniberg 5. 不能带来直接价值，需要完成但又不属于可交付的故事，称之为“技术故事”
例如“安装持续集成服务器”、“重构代码”等
6. 让别人了解我们的sprint
sprint信息页示例
xxx team sprint nn
sprint goal
- xxxxxxxxxxxxxxxx
sprint backlog
- b1
- b2
estimated velocity:
schedule
- sprint duration: 2011-11-30 to 2011-12-29
- daily meeting: 9:30-9:45, in team room
- sprint demo: 2011-12-29 in meeting room
team
- James
- Tom
- Jessica
- Rav (收起)

2011-11-30 12:16:31 回应

收藏
推荐
第5页

bob.jiang

如何写产品backlog（或者叫用户故事）: 故事包含这些字段， ID 唯一标识 NAME 用户故事名字，简短的描述 IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。 ESTIMATION 估算 HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。 NOTE 备注 ========================================= 额外的故事字段， TRACK 类别，比如“后台系统”或者“.. (更多)

如何写产品backlog（或者叫用户故事）:
故事包含这些字段，
ID 唯一标识
NAME 用户故事名字，简短的描述
IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。
ESTIMATION 估算
HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。
NOTE 备注
=========================================
额外的故事字段，
TRACK 类别，比如“后台系统”或者“优化”的分类
COMPONENTS 组件，比如“数据库”“客户端”“服务器”
REQUESTOR 请求者，谁最先提出的这个需求，方便后续的反馈和跟踪
BUG ID 直接把BUG关联到用户故事 (收起)

2011-11-28 09:02:37 回应

收藏
推荐

第5页

bob.jiang

如何写产品backlog（或者叫用户故事）: 故事包含这些字段， ID 唯一标识 NAME 用户故事名字，简短的描述 IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。 ESTIMATION 估算 HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。 NOTE 备注 ========================================= 额外的故事字段， TRACK 类别，比如“后台系统”或者“.. (更多)

如何写产品backlog（或者叫用户故事）:
故事包含这些字段，
ID 唯一标识
NAME 用户故事名字，简短的描述
IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。
ESTIMATION 估算
HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。
NOTE 备注
=========================================
额外的故事字段，
TRACK 类别，比如“后台系统”或者“优化”的分类
COMPONENTS 组件，比如“数据库”“客户端”“服务器”
REQUESTOR 请求者，谁最先提出的这个需求，方便后续的反馈和跟踪
BUG ID 直接把BUG关联到用户故事 (收起)

2011-11-28 09:02:37 回应

收藏
推荐
第42页

bob.jiang

有关Sprint计划： 1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说 1.1 产品backlog必须存在 1.2 只能有一个产品backlog和一个产品负责人 1.3 所有重要的backlog已经根据重要性打过分。 1.4 产品负责人应该理解每个故事的含义。总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprin... (更多)

有关Sprint计划：
1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说
1.1 产品backlog必须存在
1.2 只能有一个产品backlog和一个产品负责人
1.3 所有重要的backlog已经根据重要性打过分。
1.4 产品负责人应该理解每个故事的含义。
总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprint可以完成的backlog）
2. Sprint计划有哪些产出结果：
2.1 Sprint目标
2.2 团队成员名单，以及他们的投入度
2.3 Sprint Backlog （应该是产品Backlog中重要性最高的一部分）
2.4 确定好的Sprint演示日期
2.5 确定好每日站会的时间地点
3. 如何决定哪些故事需要放到sprint里面？
3.1 本能反应 - 比如Scrummaster问团队，这个sprint我们可以完成这3个故事吗？
3.2 生产率(Velocity)计算 - 根据过去的sprint进行下一次的生产率估算
4. sprint计划会议时，把用户故事打印成索引卡，在每个选择的故事下细分任务（用便签）Henrik提供了一个非常好生产索引卡的脚本 http://blog.crisp.se/henrikkniberg 5. 不能带来直接价值，需要完成但又不属于可交付的故事，称之为“技术故事”
例如“安装持续集成服务器”、“重构代码”等
6. 让别人了解我们的sprint
sprint信息页示例
xxx team sprint nn
sprint goal
- xxxxxxxxxxxxxxxx
sprint backlog
- b1
- b2
estimated velocity:
schedule
- sprint duration: 2011-11-30 to 2011-12-29
- daily meeting: 9:30-9:45, in team room
- sprint demo: 2011-12-29 in meeting room
team
- James
- Tom
- Jessica
- Rav (收起)

2011-11-30 12:16:31 回应

收藏
推荐

第42页

bob.jiang

有关Sprint计划： 1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说 1.1 产品backlog必须存在 1.2 只能有一个产品backlog和一个产品负责人 1.3 所有重要的backlog已经根据重要性打过分。 1.4 产品负责人应该理解每个故事的含义。总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprin... (更多)

有关Sprint计划：
1. 如何准备Sprint计划 - 在Sprint计划会议之前，确保产品backlog的井然有序。（不是说所有故事都已经定义好，所有估算都正确；而是说
1.1 产品backlog必须存在
1.2 只能有一个产品backlog和一个产品负责人
1.3 所有重要的backlog已经根据重要性打过分。
1.4 产品负责人应该理解每个故事的含义。
总之是在sprint计划会议之前，需要有本次计划会议的输入，可以讨论的产品backlog。（即潜在下个sprint可以完成的backlog）
2. Sprint计划有哪些产出结果：
2.1 Sprint目标
2.2 团队成员名单，以及他们的投入度
2.3 Sprint Backlog （应该是产品Backlog中重要性最高的一部分）
2.4 确定好的Sprint演示日期
2.5 确定好每日站会的时间地点
3. 如何决定哪些故事需要放到sprint里面？
3.1 本能反应 - 比如Scrummaster问团队，这个sprint我们可以完成这3个故事吗？
3.2 生产率(Velocity)计算 - 根据过去的sprint进行下一次的生产率估算
4. sprint计划会议时，把用户故事打印成索引卡，在每个选择的故事下细分任务（用便签）Henrik提供了一个非常好生产索引卡的脚本 http://blog.crisp.se/henrikkniberg 5. 不能带来直接价值，需要完成但又不属于可交付的故事，称之为“技术故事”
例如“安装持续集成服务器”、“重构代码”等
6. 让别人了解我们的sprint
sprint信息页示例
xxx team sprint nn
sprint goal
- xxxxxxxxxxxxxxxx
sprint backlog
- b1
- b2
estimated velocity:
schedule
- sprint duration: 2011-11-30 to 2011-12-29
- daily meeting: 9:30-9:45, in team room
- sprint demo: 2011-12-29 in meeting room
team
- James
- Tom
- Jessica
- Rav (收起)

2011-11-30 12:16:31 回应

收藏
推荐
第5页

bob.jiang

如何写产品backlog（或者叫用户故事）: 故事包含这些字段， ID 唯一标识 NAME 用户故事名字，简短的描述 IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。 ESTIMATION 估算 HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。 NOTE 备注 ========================================= 额外的故事字段， TRACK 类别，比如“后台系统”或者“.. (更多)

如何写产品backlog（或者叫用户故事）:
故事包含这些字段，
ID 唯一标识
NAME 用户故事名字，简短的描述
IMPORTANCE 重要性，表明故事有多重要。一个小提示，重要性之间要留有余地，比如20 40 60这样进行设置。
ESTIMATION 估算
HOW TO DEMO 如何演示，等同于ACCEPTANCE TEST，怎么操作才能完成客户的要求。
NOTE 备注
=========================================
额外的故事字段，
TRACK 类别，比如“后台系统”或者“优化”的分类
COMPONENTS 组件，比如“数据库”“客户端”“服务器”
REQUESTOR 请求者，谁最先提出的这个需求，方便后续的反馈和跟踪
BUG ID 直接把BUG关联到用户故事 (收起)

2011-11-28 09:02:37 回应

收藏
推荐