![硝烟中的Scrum 和XP - [瑞典] Henrik Kniberg](https://static.book345.com/covers/9787302243335.jpg)
书籍介绍
《硝烟中的Scrum和XP——我们如何实施Scrum》源自真实的故事，Henrik Kniberg以过来人的身份，回顾了他在一年时间内带领40人团队实施敏捷转型和持续过程改进的亲身经历。在Henrik的领导下，团队经历了不同的规模，不同的sprint长度，不同的定义“done”的方式，不同格式的产品backlog和sprint backlog，不同的测试策略，不同的演示方式，同步多个Scrum团队工作的不同方式，如此等等。他们还尝试了XP实践——体验不同方式的持续构建、结对编程、测试驱动开发等，阐述了如何结合使用XP与Scrum。
开发团队需要了解一些Scrum 的基础知识。该怎样创建产品backlog， 对它进行估算？ 怎样把它转化成sprint backlog？怎样管理燃尽图（ burndown chart） ， 计算团队的生产率（ velocity） ？ Henrik 的书可以用作一些基础实践的入门指南，帮助团队从试用Scrum 中成长，最终成功地实施Scrum。
Henrik Kniberg（ henrik.kniberg@crisp.se）是一名咨询师，在斯德哥尔摩的Crisp 公司（www.crisp.se） 工作。他的专长是Java 和敏捷软件开发。
AI导读
核心看点
- 作者分享带领40人团队实施敏捷转型的真实经历
- 详细阐述Scrum与XP实践结合的具体操作细节
- 涵盖产品Backlog、Sprint计划及演示等全流程
适合谁读
- 正在实施或准备实施Scrum敏捷开发的团队
- 希望了解敏捷转型实操细节的软件工程师
- 寻求项目管理改进方法的敏捷教练与负责人
读前提醒
- 本书侧重实操How而非理论Why，适合新手入门
- 需结合自身体验阅读，避免生搬硬套书中做法
- 建议配合实际项目对照阅读，以加深理解
读者共识
- 被公认为极佳的Scrum实施指南与入门参考书
- 内容简洁实用，像Cookbook般随手翻阅有收获
- 强调因地制宜，反对机械模仿，需灵活变通
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "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 中,外人不能干涉团队的工作。"
目录
用户评论
知道为什么吵闹组迟到要在罐子里放钱了，显然他们看了这本书。19.2万
读的多了就觉得敏捷的书大抵类似，没我偶像的书值得反复阅读、推敲呀
对于正在实施敏捷软件开发模式的团队有很好的参考作用，可以了解有哪些好的实践方法。一本小册子，有很好参考价值！
理清工作思路→确定工作量（全体会议）→确定交付日期（全体会议）→分配工作内容（技术团队内部会议）→公布工作量及目标（对外公布）→及时更新工作进度（对外公布）
一本讲how而不讲why的小书，适合新手，当然有经验的人也可以参考，@凉粉小刀 的翻译很流畅
作为一部小品还是有些参考价值的，不过还是太浅，实际运用还是要结合自身场景深入定制
干货满满，总结很到位
很具体风趣的讲述实践经验，收获很大，只是不那么系统。
建议在了解scrum和xp基本信息后再来阅读。
小册子，干货满满，没有废话。理解SCRUM ,应用到团队和个人任务管理也非常好。虽然有1-2处多字，但不影响信息量纯度。20210730NO6
Z-Library
收藏