书籍介绍
本书真实反映了一个团队的精益敏捷落地过程。第1部分介绍了团队是如何实施主流敏捷方法Scrum的。主题涵盖如何写产品列表，如何准备、制定、公开和编写计划，如何布置团队空间，如何开每日站会，如何做演示和回顾，如何对待固定价格的合同，如何结合使用Scrum和XP，如何做测试，如何管理多个团队，如何管理分布式团队。最后，作者还给出了一个很有价值的Scrum Master检查清单。第2部分主要介绍Scrum和Kanban的结合使用。在对比两者之后，作者通过一个具体的案例来说明如何搭配使用两种方法来实现价值大化。
AI导读
核心看点
- 真实还原团队落地Scrum与Kanban的实战过程
- 详解Sprint计划、每日站会及回顾等核心环节
- 对比分析Scrum与Kanban，探索混合使用策略
适合谁读
- 正在实施或准备尝试敏捷开发的软件团队
- 需要具体操作指南的Scrum Master与产品经理
- 对精益敏捷实践感兴趣的软件开发初学者
读前提醒
- 本书侧重实操经验，非理论教条，需结合场景理解
- 部分内容与《硝烟中的Scrum和XP》重合，可互补阅读
- 建议对照自身团队现状，反思并调整现有工作流程
读者共识
- 内容务实接地气，被誉为敏捷开发的实战指南
- 篇幅短小精悍，适合快速阅读并立即投入实践
- 强调从失败中学习，敏捷重在行动而非空谈理论
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "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)，男，作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。
马蒂斯·斯加林 (Mattias Skarin)，男，看板早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。
李剑，男，全栈程序员，2004年参加工作至今，目前专注于移动开发领域。曾任ThoughtWorks高级咨询师和InfoQ首席编辑。出版的作品恰好可以凑够朋友圈九宫格，算是为国内敏捷社区的发展做了一些微不足道的贡献。
用户评论
Scrum好玩，Kanban有点简单过度。敏捷实践就是了解之后看着来。还有就是得团队一致，不然都是瞎搞。
有一部分内容与《硝烟中的scrum和xp》重合，依然很实战，写了很多实战经验，读完有新感悟，用起来，做才是最好的得到
敏捷开放就像 OKR 一样，大部分项目都觉得自己多敏捷多 OKR，然而真正做到的就寥寥无几。
说实话，不太切合实际。介绍的比较零散，没有条理
恶补了很多自己以前忽视的地方和自以为然的地方，有了新的认识
十分实用 作为Scrum小白也能轻松理解 里面很多小tips切实回答了我阅读过程中的“发问”。还是要实操才能对scrum有更全面的理解和灵活的运用
First time to know Kanban is a methodology rather than a simple tool. This is real management!
实操性很强的小册子。相较上一版，增加的 Scrum 和 Kanban 对比的部分很不错。原来我们现在用的更接近两声部 Scrum：计划声部和发布声部。
书不厚，写得很务实。第一部分偏细节，主要介绍了作者如何运用scrum进行软件开发，对于小白又想启用scrum，是特别好的参考.
第二部分对于重要概念做了介绍，没时间细看《scrum精髓》，通过这部分有非系统的基本概念认识也是OK的。
特别喜欢封皮儿那段文字：Lean
and Agile are siblings.
大象难跳舞，除非组织铁了心、有家底地可以做到“自上而下”和“自下而上”的创新
InfoQ 有免费的电子书，是本书 scrum 部分，纸质书进行了重编辑、优化
https://www.infoq.cn/minibook/scrum-xp-from-the-trenches
总的来说是一本接地气的敏捷实践指南，相信做过敏捷开发的阅读此书都会不时会心一笑，推荐。
收藏