书籍介绍
这不本教人机械套用流程的敏捷手册，而是一份团队在真实泥淖里摸爬滚打后的复盘。它最打动人的，是那种「别被方法绑架」的清醒：sprint 长短是产品负责人与开发妥协出的三周，backlog 就放在能多人同时编辑的共享文档里而非版本库——作者坦然承认这些「不够正规」的做法，却换来少得多的合并冲突。书里对 Scrum Master 的描写尤其鲜活：不是坐等求助的救火员，而是会施压、会催促的「团队清道夫」。它反复强调的关键词是快速反馈与集体代码所有权——关键人生病，sprint 也不至于停摆。适合两类人：正被流程僵化困住的实践者，以及想看清敏捷「落地时到底长什么样」的初学者。它不承诺标准答案，只给你一面试镜。
作者简介
亨里克·克里伯格 (Henrik Kniberg)，男，作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。
马蒂斯·斯加林 (Mattias Skarin)，男，看板早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。
李剑，男，全栈程序员，2004年参加工作至今，目前专注于移动开发领域。曾任ThoughtWorks高级咨询师和InfoQ首席编辑。出版的作品恰好可以凑够朋友圈九宫格，算是为国内敏捷社区的发展做了一些微不足道的贡献。
AI导读
核心看点
- 真实还原团队落地Scrum与Kanban的实战过程
- 详解Sprint计划、每日站会及回顾等核心环节
- 对比分析Scrum与Kanban，探索混合使用策略
读者共识
- 内容务实接地气，被誉为敏捷开发的实战指南
- 篇幅短小精悍，适合快速阅读并立即投入实践
- 强调从失败中学习，敏捷重在行动而非空谈理论
精彩摘录
- "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 中,外人不能干涉团队的工作。"
用户评论
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
总的来说是一本接地气的敏捷实践指南，相信做过敏捷开发的阅读此书都会不时会心一笑，推荐。
清华大学出版社的其他书籍查看全部
求书
收藏