几周前看完「硝烟中的Scrum和XP」后，对于书中谈到的所有敏捷方法，无论是如何将繁杂的业务需求拆解成清晰的故事卡片，还是坚持每日站会，都很想尽快在团队中真实地操练一番，帮助团队完成敏捷转型，更好更快地交付产品。与此同时也生出了很多感慨，最大的就是看到作者2006年即在家中完成了本书，一本十三年前的作品放在今天我们依然感觉它是先进的和实用的，我们错过的太多，冰冻三尺非一日之寒，带领团队完成敏捷转型可能会碰到很多困难。
在近三周的敏捷实践中，我记录了三个我们碰到的关键问题，结合此书，谈谈我们是如何思考和解决这些问题的。
向PO以及其他团队成员推广三变量（范围、重要性、时间估算）原则
在我们开始的sprint前，大家已经达成一致，我们将本次sprint的长度确定为两周。那么最终的sprint backlog 就需要团队共同讨论了，问题也就如期而至。
当sprint 中的所有人都明白质量，特别是内部质量很重要时，就会发现范围、重要性、时间估算三者间微妙的关系。
希望PO对故事进行调整时，并不是一个很简单的事情，书中的一个方法是很合适的，就是由开发团队来提问，
例如「查询列表」故事中的查询条件是否需要加上起始时间和结束时间，「删除单条信息」应当做硬删除还是软删除，通过开发团队的问题引导PO理解为什么要调整某
个故事的时间估算，甚至放入下一个迭代，便可以逐步确定sprint的backlog。这个引导其实是将在开发过程中可能发生的讨论前置，让整个迭代更加可控。
向客户更快地交付完整的重要功能确实是最好的结果，但是当我们平衡范围、重要性和时间估算时，就会发现一定要遵循MVP的原则有所取舍。尽管这个原则看起来很简单，
但是在确定backlog的时候确实给了我们很多信心。
改变开发团队工作方式-站会、物理看板
在启动sprint前，其实开发团队对于scrum的理解程度是不一致的，而且多数没有过daily scrum的经验，更没有使用过物理看板。书中很直接地就向我们SM提出了一个重要的建议，就是应该让整个团队
都尽力更新物理看板，保持sprint backlog的及时性。在站会初期，我确实发现开发团队对卡片的熟悉程度整体不强，同时很多卡片都要到了站会的时候才想起来移动，这个时候通过鼓励开发团队，并且加强站会外的时间运用，增强卡片的流动性。经过一周的坚持站会和物理看板，也让团队切实体会到了敏捷的好处，极大地增强了协作。
对SM自身的提升
到底如何从开发人员过渡到SM，一直是萦绕在我心头的问题，尽管阅读了一些书籍，做了一些实践，仍然会担心自己在某些方面有大的缺失。在本书最后，提供了一个Scrum Master 检查列表。
这个表非常适合初期SM每天进行自我回顾，及时更正每天在站会等事项中的偏差，同时指导第二天乃至整个敏捷实践中的流程。检查列表是个很好的对照表，帮助SM自身做得更好。
在阅读了很多概念性、科普性的敏捷相关资料后，「硝烟中的Scrum和XP」的确是本可以让我们实操的书，类似于Q&A的形式，值得我们在学习实践Scrum过程中放在手边。
