AI导读
核心看点
- 基于真实40人团队实施Scrum与XP的实战经验
- 无理论废话，聚焦Backlog、Sprint计划等具体操作
- 强调根据环境取舍实践，拒绝照搬模仿
适合谁读
- 正在或准备实施敏捷开发的软件开发团队
- 希望了解Scrum落地细节的项目经理与教练
- 寻求从理论转向实践操作的敏捷初学者
读前提醒
- 本书为实践指南，建议结合当前项目边做边读
- 需理解上下文，切勿机械复制书中的具体做法
- 适合作为入门教材快速浏览，建立整体框架
读者共识
- 短小精干，言简意赅，极具实战参考价值
- 相比理论书籍，更侧重具体操作与问题解决
- 是敏捷入门的优秀读物，但需灵活变通应用
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "sprint会议是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，是scrum中最重要的活动。 sprint计划会议需要一些实实在在的结果： 1：sprint目标 2：团队成员名单以及投入程度 3：sprint backlog 4：确定好sprint演示日期 5：确定每日scrum会议的时间和地点"
- "我们已经证实，如果团队拥有高度的代码集体所有权，这个团队就会非常健壮，比如某些关键人物生病了，当前的sprint也不会因此隔屁着凉。"
- "对待离自身尚远的事物时，人们 可以把它分析的淋漓尽致；但到了自己身上，就往往成了当局者迷， 旁观者清。譬如青春、譬如爱情、譬如敏捷软件开发。"
- "通常我们会把 backlog 存放在共享的 Excel 文档里面（是为了多个 用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责 人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打 开这个文档，弄清一些事情，或者修改估算值。 基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放 到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会 导致锁操作或是合并冲突，这是最简单的方式。"
- "短的 sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错 误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而 来。 但是，时间长的 sprint 也不错。团队可以有更多时间充分准备、解 决发生的问题、继续达成 sprint 目标，你也不会被接二连三的 sprint 计划会议、演示等等压得不堪重负。 产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的 sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们 最终总结出了最喜欢的长度：三个星期。"
- "羞辱式做法： “如果你不知道怎么帮助团队，我建议你还 是回家去，或者看书，或者怎么都行。要不也可以找个地 方坐下，等别人需要帮忙的时候你就过去。” 守旧式做法：简单给他们分配个任务了事。 施加同事压力的做法： 对他们说，“Joe，还有 Lisa，你 们两个可以放松点，我们会站在这里慢慢等，直到你们找 到帮助我们完成目标的事情为止。” 奴役式做法：对他们说，“你们今天可以给大伙儿干干杂 活。倒咖啡、做按摩、清理垃圾、做午饭，一切一切大家 今天让你们做的事情。”你会惊讶的发现 Joe 和 Lisa 在霎 那之间就找出了有用的技术任务:o)"
- "如果每个人（所有的团队成员和产品负责人）离开会场时都面带微笑，第二天醒来时面带微笑，在第一次的每日例会上面带微笑，那sprint 计划会议就是成功的。"
- "迭代开发的基本需求: • 迭代要有固定时长(被称为“时间盒——timebox”),不能超过六个星期。 • 在每一次迭代的结尾,代码都必须经过 QA 的测试,能够正常工作。 Nokia 的 Scrum标准: • Scrum 团队必须要有产品负责人,而且团队都清楚这个人是谁。 • 产品负责人必须要有产品 Backlog,其中包括团队对它进行的估算。 • 团队必须要有燃尽图,而且要了解他们自己的生产率。 • 在一个 Sprint 中,外人不能干涉团队的工作。"
作者简介
Henrik Kniberg（[email protected]）是一名咨询师，在斯德哥尔摩的Crisp公司（www.crisp.se）工作。他的专长是Java和敏捷软 件开发。
自从第一本有关XP的书籍和敏捷宣言问世以来，Henrik就开始拥抱敏捷原则，并尝试在不同的组织中进行有效应用。在1998年至2003年间，他作为Goyada的合作创始人和CTO，构建并管理一个技术平台和30人的开发团队，充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信息：http://www.crisp.se/henrik.kniberg
目录
用户评论
要弄敏捷了
大三那年看scrum书，现在真地跑了一遍scrum，就像从图书馆底楼书架从tp393.92走到tp390一样…眼泪花花
言简意赅，可以做入门教材使用
说实话看下来没什么感觉，对实践性要求高的书籍得一边做一边看。主要是了解其中的理念，但和平时强调的“快速迭代”有什么本质区别？没看出来精髓所在。
短小精干
很实用的小书
可以落地的敏捷
简单明了，通俗易懂
对于项目管理来说值得一看
产品backlog是Scrum的核心。他就是一个需求或者故事或者特性等组成的列表。我们叫他故事（story），有时候也叫做backlog（条目 事项）
Story里面有一个how to demo（如何做演示），将输入的如何在sprint演示上进行示范，本质就是一个简单的测试规范。技巧1：让产品backlog停留在业务层次上。
作为技术人，很可能写技术点，而不是站在业务层面说东西。比如响应速度。出现这个问题问一下：“但是，为什么呢？”找到根本解决点。
所有重要的backlog条目都已经根据重要性呗评分过
技巧2：产品负责人应当理解每个故事的含义
技巧3：用excel来操作backlog而不是Jira
Sprint计划会议是Scrum中最重要的活动。
收藏