《硝烟中的scrum和xp》读书笔记

翻译的不错， 浅显易懂， 非常具有实战意义。完全是作者亲身体会的总结。不过感觉scrummaster相关的东东介绍的太少了。

====================以下是读书笔记的分割线===================

Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。

Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。

产品 backlog是 Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。

一个backlog条目就是一个story, 包括：
id,
name,
优先级,
估算时间(多少人天),
如何演示(最终的结果是个什么样子, 简单的描述就是“先这样做，然后那样做，就应该得到……的结果  ”, 可以理解为测试的伪代码),
备注(相关信息, 解释说明, 相关资料引用, 一般都比较简短)

如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。

不断的问产品负责人“但是这样做是为什么呢”这样的问题，一直问下去，直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事, 最开始的技术描述只会作为一个注解存在。

在 sprint 计划会议之前，要确保产品 backlog 的井然有序。

产品负责人应当理解每个故事的含义. 他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里。

产品负责人有决定每一个故事优先级的权利

Sprint 计划会议非常关键，应该算是 Scrum中最重要的活动

每个故事的三个重要变量:范围, 估算, 重要性
范围和重要性由产品负责人制订, 估算由开发人员制订

何为"范围": 比如做某件事情, 是否还需要做另外一件事

产品质量分为内部质量和外部质量, 可以先发布一个很简陋, 运行很慢的系统, 也就是外部质量很差的系统, 然后再进行调整, 但是内部质量(可维护性, 代码可读性, 测试覆盖率和重构)决没有讨价还价的余地

Scrum中的一切事情都有时间盒。

当开了长时间的会议依然没法确定一个sprint计划, 可以规定一个最终的时间期限, 如果还是没法做出, 就另外安排一个时间来开sprint计划会议， 而不是一味延长时间

scrum的要求: 把事情完全做对, 达到完全可交付的状态, 事情只做了一半, 它的价值就是0.

一旦时间估算值比较大, 其精确程度就很难把握

通过对故事的演示, 来揭示故事的范围

故事和任务的区别:故事是可以交付的东西, 是产品负责人关心的, 任务是不可交付的, 产品负责人无须关心

无论你的 sprint backlog 是什么形式，都要尽力让整个团队参与到保持 sprint backlog 及时更新的工作中来。

ScrumMaster为团队提供支持，消除他们的障碍

回顾是 Scrum中第二重要的事件（最重要的是 sprint 计划会议），因为这是你做改进的最佳时机！

回顾会议中, 问"如果时间可以倒流，从第一天重新开始这个 sprint，那你觉得哪些事情会用其它方式来做？"

很多时候，只要能清楚地指出问题所在，到了下一个sprint，问题也许就自行解决了。

Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。

结对编程令人精疲力竭，不能全天都这样做。

结对编程可以增进团队间的知识传播。速度快到令人难以想象。

多数情况下，开发人员掌握TDD的唯一方式就是跟一个熟悉 TDD的人一起结对编程，一旦掌握以后，他就会受到彻底的影响，从此再也不想使用其它方式工作。

HSQLDB 用作嵌入式的内存数据库，在测试中使用。

Jetty用作嵌入式的内存 Web 容器，在测试中使用

刚开始应该想办法提高手工测试的效率。

一开始就应该保持设计简单化，然后不断进行改进；而不是一开始努力保证它的正确性，然后就冻结它，不再改变。

你可以打破这里的任一规则，不过一定要有个好理由，并且记录下来。

“测试人员”指的是“主要技能是测试的人”，而不是“只做测试的人”。

开发人员常常都是很差劲的测试人员。尤其是他们测试自己代码的时候。

测试人员应该跟编写测试代码的开发人员一起结对编 程。如果测试人员根本不会编程，他也应该跟开发人员结对，即便 他只能坐在一边看，让开发人员敲键盘。相对于好的开发人员，好 的测试人员常常能想出多种不同类型的测试，所以他们可以互补。

即使所有的编程活动都已完成，距离产品发布还有很遥远的距 离。至少复杂系统是这样的。

在 Scrum 团队中含有兼职成员一般都不是什么好主意。

“团队凝聚力”是Scrum的核心要素之一，如果一个团队合作工作达多个sprint之久，他们就会变得非常紧密。

Scrum master 检查列表(职责)
创建sprint信息(目标, 团队大小, 时间估算), 昭示天下
确保晨会正常开始和结束
增删sprint中的故事
向团队传达项目进度(backlog, 燃尽图)
排除开发过程中的障碍和干扰
sprint演示, 并昭示天下
组织召开sprint回顾会议
总结本次sprint经验教训和更新实际生产率估值


八卦
作者Henrik 在东京长大，目前与他的妻子 Sophia 和两个孩子生活在斯德哥尔摩。他在空闲时间还是一个活跃的音乐家，跟本地乐队一起创作乐曲，玩贝司和键盘。

评论

4 楼 cectsky 2011-04-16  

scrum建议一般sprint有2到4周，当然可以根据具体情况调整

3 楼 macrochen 2011-04-08  

rzkr 写道

你现在在淘宝?

是的, 你还在武钢吗?

2 楼 rzkr 2011-04-07  

大爷的, 应该回复的是你另一篇读书笔记.

1 楼 rzkr 2011-04-07  

"看完之后发现scrum还算简单, 而且我们目前的日常开发管理, 与scrum非常类似, 计划安排也算是仅仅有条. 不过scrum中有一些东西规定的非常死, 还不是很理解, 比如说一个sprint是30个日历日(为什么不是60, 不是15? 实际上我们是两周), 每天必须开晨会(我们团队内部从开始每天早上一次, 到每隔一天一次, 到现在干脆不开了, 貌似也没什么问题, 关键是我们team人少, 感觉没有开的必要), 还有燃尽图, 这本书中我没有看到详细的介绍, 主要是任务时间估算方面的, "

       这本书去年也看过,对SRCUM也算了解,但并没有说一个SPRINT具体是30天还是60天? 就像你读书笔记本写的一样, 它仅仅框架, 而如何使用确在于使用它的人.

      几个项目跟你们一样, 都是两周. daily scrum meeting我们每天都会开, 除了大家回答那三个问题, 我们也会适当的开些玩笑, 活跃一些团队的气氛.

      你现在在淘宝?