《硝烟中的Scrum与XP》这本书应该算是敏捷方面比较有影响的书籍之一。
曾经在2018年年末拿起这本书来读，当时还在咨询公司做顾问，为银行和车企的客户做过敏捷转型项目。兴致盎然读了前面几章，中途因为工作太过于忙碌暂放下。
机缘巧合，在2020年年初加入一家正在开展数字化转型的美国医疗科技公司，敏捷转型是他们整个转型中一个很重要的部分。在公司和2个Scrum团队成员，从团队组建到逐步展开敏捷，朝夕相处了半年多，今天再次拿起了这本书来读，一气呵成地读完只用了不到三天。深切感受到 “纸上读来终觉浅，绝知此事要躬行”。 深入地和团队合作的这段时间中，对书中的非常多实际场景感同身受。下面，就我体验最深的也是目前经历得几点和大家分享我的感受。
无休止的 sprint 计划会议……
每个迭代组织了多个Scrum会议，最让团队以及我本人感受痛苦当属需求梳理会和计划会。需求梳理会上，产品经理会和整个开发团队介绍业务需求，回答开发的问题，帮助开发来理解需求；计划会上也有类似的环节。总之，遇到了一个复杂的需求，相对关注的几个同事会热烈且不间断地讨论非常久，我印象最深刻的一次，曾经从下午开到过晚上将近11点（晚饭时间除去）。然而，公司文化以以人为本为主，每个季度都会和大家统计改进问题，开会时间的控制就成了领导们从上到下都关注的事情。而我作为所有敏捷会议的组织者，更被加上会议时间管控这个OKR。
遇到这种情况怎么办？书中提供另一种方法的是：“告诉团队和产品 负责人：“这个会议要在 10 分钟以后结束。我们到目前为止还没 有一个真正的 sprint 计划。” 并在准时终止会议。
从最近的迭代开始，我开始尝试这种方法，可以说效果还是不错的。让团队来选择，会议继续是继续超时开还是先结束。无论结果如何都是团队地选择，相应对会议时间的抱怨会减少，同时也有助于团队成员自己形成对时间和节奏的把控。
怎样让别人了解我们的SPRINT
如何让组织内部的大家都了解到敏捷团队都在做些什么？这一条真的很重要。相信大多数组织中的高层领导是没有精力登录到JIRA上面查看每个Sprint的具体工作，而高层对敏捷的支持又是非常之重要。同时除了敏捷团队之外，每个组织内部会有其他的团队或部门，不是很了解敏捷到底是怎么做得。所以，有一个帮助组织内部所有成员了解Sprint的方式很重要。
2020疫情关系，大家集体居家办公，没有办法借助办公室公共区域的看板，无形之中好像增添了一些阻碍。好在公司的电子办公系统完善，同时借助Confluence，我会在上面发布每个Sprint信息，十分便捷。已经开始在新的迭代做这件事情，后续的效果持续观望。：）
验收测试应该作为 sprint 的一部分么？
最后谈一下对验收测试的想法。 书中，作者的观点是，现实中大部分团队没有把验收测试作为Sprint的一部分。关于这一点，我是赞同的。很多团队迭代终止于产品经理的验收（注意不是UAT,客户验收）。 行业的不同，从产品经理验收到达客户验收，中间这段路程还会经历什么，时间多久其实都是不一样的。以我现在所在的医疗行业为例，这个行业合规比较多，大家都会更加谨慎一些。而其他行业，比如互联网，产品经理可以直接代表用户，那其实他验收了就可以。所以总之就是，不同行业具体看情况，采用最适合的，团队都认可的方式就好。
除了上面3条之外，书中提到XP的实践也非常有实际意义。我所在的组织已经开展了类似的活动，比如： Code Review, 重构。
