细读《硝烟中的Scrum和XP》，再想想我们做Scrum的经历，心里不禁想着：要是早一点看到这本书就好了。

为什么这本书叫硝烟呢？我理解是因为这是一本实战书，书中的内容来自于实战，从书中可以看出来一次次的实践、检查、调整，一次次的小战争。如果我们想要从这本书学到一些东西，可以应用到我们的工作中来，我们需要认同一个点：以目标为导向。

书中首先强调了目标。在Scrum里，目标是什么，怎么呈现呢？henrik认为目标是通过产品backlog来表现的，里面包含里故事和特性，按照重要程度进行排序，并且有估算。里面包含了客户想要的东西，并用客户语言来进行描述。对于每一个故事，henrik认为需要包含ID、名称、重要性、估算、验收测试、注释。验收测试很重要，故事是否满足要求，以验收测试作为标准。

目标确定之后，就开始做计划。在书中，henrik花了很大的篇幅来描述他们是怎么做计划的，在做计划之前还有个准备阶段，确保我们已经准备好了，可以做计划了。这个准备阶段也是我们做Scrum的时候，容易忽视的地方。henrik用了一章来描述准备工作，也给我们展现了一个DoR标准。

在迭代计划一章，henrik描述了PO和DT是怎么各司其职的：PO负责澄清用户故事和调整优先级，DT负责估算和决定接受多少用户故事。而对于质量，henrik的态度非常坚定。他描述了内部质量（用户看不到的要素，它对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等）和外部质量（用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣）。一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。松散的沙滩上怎么可能建起精美的楼阁？所以在任何时候，团队都要保证内部质量，这一点毋庸置疑，也没有折扣可将。现在如此、将来如此、一直如此、直到永远。

好的计划是成功的一半，迭代计划很重要。可是当我们时间不够了怎么办？我们要一直开下去吗？不是的。在敏捷开发里面，时间盒是一个非常重要的概念，如果时间到了，我们就要停止，然后可以决定是明天继续开迭代计划会，还是这个迭代先这么干着。这么干着会不舒服，可以让我们去学习，怎么去做调整，为以后做好迭代计划积累经验。

在迭代计划会上做计划？需要重申迭代目标。我们需要PO回答这样的问题：我们为什么要进行这个Sprint？为什么我们不直接放假算了？这可以让我们的PO去思考，从“为什么”的角度去思考，而不是从“是什么”的角度去思考。“为什么”更能打动人，更能做出非凡的产品。读到这里，我想起了“黄金圈法则”。

确定的“为什么”之后，我们来决定怎么做，怎么去达成Sprint目标。我们从产品待办列表里选择用户故事，来达成Sprint目标。在这里，我们要考虑两个问题：1、团队怎么决定把哪些故事放到Sprint里？2、PO怎么影响他们的决定？

先回答第二个问题，PO可以通过拆小故事，或者调整故事优先级来施加他们的影响；而团队可以通过本能反应，或者生产率来计算，这个Sprint可以接受多少个用户故事。我建议采用生产率来作为接受依据。生产率怎么得来呢？来自于我们的历史经验，可以随着项目的进展进行适度的调整。如果是第一个迭代怎么办？拍脑袋选一个吧。在计算生产率的时候，还涉及到用户故事的估算。henrik建议采用估算扑克的方式来进行。

在迭代计划会上，我们还需要明确“完成”的定义，团队需要就“完成”达成一致。最好的“完成”定义是：随时可以上线。

在我们已经决定了当前Sprint能够接受的用户故事之后，我们需要对用户故事进行拆分，把故事拆分成任务，并且对任务的工作量进行估算。故事和任务有什么区别呢？故事是可以交付的，而任务不可以。任务拆分的粒度是什么呢？建议拆分为每个人一天内可以完成。

然后对于技术需求和bug的处理，henrik也给出了建议。我们可以跟PO说清楚，但是技术需求是必须要做的，我们需要在每个迭代留出一些时间来做技术需求。而bug可以交给PO，由PO把bug和用户故事进行统一排序。当PO对技术不理解，不接受技术需求的时候怎么办呢？我们可以用事实来说服他，以过去几个迭代由于受到技术需求的影响，而造成生产率下降的事实来说服他。如果这还不能说服，那可以把技术需求包含在功能需求里面去做。这里回应了前面提到关于质量的坚定：质量是不可妥协的。