![硝烟中的Scrum 和XP - [瑞典] Henrik Kniberg](https://static.book345.com/covers/s/9787302243335.jpg)
书籍介绍
这不本告诉你 Scrum 该怎么做的标准手册，而是一份带着体温的实践记录。作者没有搬出敏捷教条，而是把一年内带领 40 人团队转型时的真实抉择摊开给你看：sprint 到底多长？结论是妥协出来的三周，产品负责人想要短的，开发想要长的。产品 backlog 为什么不放进版本控制，只放在共享文档里？任务板上出现警示标记意味着什么？面对“今天不知道干什么”的同事，是用羞辱、施压还是别的办法？这些细节里藏着比流程更重要的东西——团队如何在真实约束下自己长出秩序。它适合那些正在实施或准备实施敏捷、却被各种“依样葫芦”困住的团队。读它得到的不是可复制的模板，而是“尽信书不如无书”的清醒：每个项目都不同，真正能落地的，是你自己权衡后的答案。
AI导读
核心看点
- 作者分享带领40人团队实施敏捷转型的真实经历
- 详细阐述Scrum与XP实践结合的具体操作细节
- 涵盖产品Backlog、Sprint计划及演示等全流程
读者共识
- 被公认为极佳的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
清华大学出版社的其他书籍查看全部
下载
收藏