本书作者Henrik Kniberg以自己团队为例介绍如何实施Scrum，从介绍最基本的如何编写产品待办事项，到如何准备计划会，布置团队房间，如何开每日例会，怎样做评审，回顾会，再到怎样做发布，测试和管理多团队。这本书不是说教式的讲解理论知识，而是通过作者团队的成功案例来介绍怎么做的，我们当然要学习的是最佳实践，而不是单单停留在理论空想。

这本书适合小白读，也适合有scrum经验的人们读，你总会得到新的思路，想法和启发。

怎样编写产品backlog，在这一章节中介绍了作者团队编写产品待办事项的方法，除了基本的介绍和举例，令我受到启发的是在编写backlog的时候会定义这个backlog在验收时如何演示，这是我们从来没有思考过和实践过的，我个人认为在backlog里面添加这一字段真是令人眼前一亮，它能让需求更加明确，让团队很轻易的达成一致理解，真是太棒了！

怎样做planning中，提到了很多计划会议中的细节。例如，提到了每个故事的三个变量的平衡，范围，重要性和估算，其中范围和重要性由PO负责，估算由开发人员负责，那么还有一个变量质量呢，当然不可忽视，它由整个团队负责，当估算和PO预期不符，是牺牲质量还是缩小范围，显而易见。还提到了sprint的时间长短哪种更好呢，它各有好处，最终还是要找到团队适应的节奏，共同的心跳频率。对于sprint的目标，好像我的团队从来没有认真对待过，即使是敷衍都没有过，反思我们到底有没有认真想过我们为什么要进行这个sprint？就像作者说的不如直接放假算了。对于估算了解到还有直觉估算的方式，虽然适合小团队，但是似乎也很有意思，有机会可以尝试一下。还提到了像很多名词“昨日天气”，“投入程度”，其实在项目实践中都有用到，只是不知道还有专门名字表达他们。：）甚至细节提到了计划扑克的使用，你有没有真的思考过纸牌里0代表什么，？又代表什么呢？

怎样写sprint backlog一章中，印象深刻的是关于燃尽图，因为在工作中也经常向公司敏捷社区交付scrum培训，在讲解燃尽图的时候一直以来都是在说识别风险拿出去交付不了的故事，从来没有意识通过燃尽图识别需要增加故事的情况，也恰恰说明在日常工作中忽略了这一点。

布置房间一章中，提到让团队坐到一起，是的，深有体会，我们团队每天靠的很近，甚至有时候吼一嗓子就可以“把事办成”，以及让产品负责人的座位不要离团队太近，这个真的切中要害，产品负责人离团队太近很难不关注细节，也影响团队凝聚力，深有体会。

每日站会中，提到当有人不知道做什么时候，scrum master该如何做，以往我选择的是守旧式做法会去找事情给他们做，看到作者的建议后觉得还是有很多其他方式可以尝试，羞辱式，施加同事压力，奴役式，仿佛打开新世界的大门。

在sprint review中，很同意作者观点，即使很一般的演示，也会带来深远的影响，我们了解了真正完成的事，得到了认可，也吸引了干系人的注意，演示在某种程度上也是团队交流互动的机会。参加过很多团队的review会议，很多团队并没有意识到到底演示什么，演示一定是基于业务层次，做了什么，而不是技术细节的怎么做的，以及修理的bug和维护的边边角角就无需演示了。

sprint 回顾，作者认为是scrum中第二重要的事件，第一是计划会议，因为它是团第改进的最佳时机。很多书中都专门介绍如何做回顾，这本书中作者提到一个“知识桥梁”，团队中需要这样一个人做为知识的桥梁参加所有团队的回顾会在团队中传播经验，实践起来虽然很难，但不得不说很棒，值得借鉴。

组合使用scrum和XP，我们团队从最初转型到现在进入扩展框架，成功的转型的确得益于scrum和XP相结合的方式，scrum注重管理和组织实践，XP关注实际的工程实践，他们互为补充。结对编程，测试驱动开发，代码重构，持续集成的确帮助提升了产品质量，最直接的数据是产品上线后的bug率以及用户提出问题比以往的降低很多很多。开始很难，但一旦开始做就好起来了。最重要的是一定不要加班！

测试阶段，开发人员通常是最差劲的测试人员，尤其是测试自己的代码，想到当前项目，因为测试人员少，每个故事的测试用例要求开发人员提供，我看过很多开发人员写的测试用例，非常的技术角度，十分危险，想了很多办法改进，但仍然是个风险。

在怎样管理多团队中，提到宁可团队数量少，人数多，也比弄上一大堆总在相互干扰的小团队强。联想到自己当前的项目，一个scrum团队光开发人员就有十几个，这简直太恐怖了，一开始真的很头疼，一个站会能开四五十分钟，一度很想拆分团队，当深入探讨后，一但拆分，小团队间可见一定会有很多相互干扰，得不偿失，所以目前看来虽然很痛苦，但保持现状是最好的选择。

以上是我在初次读这本书后的记录和感想，相信当过一段时间几个月几年后再读，一定会有更多不一样的感受，非常同意翻本书译者李剑在序中所写：敏捷不是说出来的，是干出来的！