《Scrum精髓》读后感-冲刺

大约是在2014年的时候拜读了《Scrum精髓》这本书，并在之后的三年里，一直以各种方式进行实践和尝试，从5人的Scrum，再到20人的SoS，直至60人的LeSS，再又回归到5人的Scrum，在不同的团队规模下，Scrum在推进和实践的过程中总是伴随着种种现实的问题，尽管《Scrum精髓》这本书提供了很好的敏捷框架，但是有些时候，书中提到的比如团队的自组织往往是一个很美好的理想，而在理想之下，便是我们应该如何通过理论联系实际，完成Scrum的落地工作。

因此在重新读完此书以后，打算按照本书的结构，并结合我日常实践Scrum的过程，简单的聊聊Scrum实践过程中遇到的问题。

冲刺的实践

冲刺便是我们经常所提到的迭代，每一轮迭代对于团队来说都是一次挑战，如何完成此轮迭代的目标，是团队所关注的最重要的事，而作为Scrum master，还会关注团队如何在每一轮迭代中做得更好。

在Scrum落地的过程中，迭代是最容易实践的一种方式，在刚开始推行冲刺的工作方式时，可以给团队的工作安排的少一些，让团队适应冲刺的工作流程和节奏后，逐渐的增加工作量，切忌不可为了一个承诺上线时间节点，而逼迫团队疯狂的加班，这样往往会导致团队整体效率的下降，同时对频繁的上线抱有怨言。

迭代模式落地过程中最大的障碍是团队工作流程的调整，从之前动藉一个月需求整理、两个月开发的瀑布模式中走出来，把每一次循环的周期减少到一周或者两周的时间段上，这其中最容易遇到的问题是团队关注点变成了一个又一个的小功能特性上，而忽视了那些不紧急但重要的工作，这就需要PO在进行需求整理的时候，不能完全的专注在各个业务方反馈的细节问题之中，把自己变成传话筒的角色，也需要站在更高的层面上，思考全局的设计和长远的规划。

冲刺的节奏

我们实行过周五、周一、周四的上线节点，最后选择了每周二至下周一作为一轮迭代的方式，这样时间安排的好处在于：

1、预留了周末两天作为每轮迭代的缓冲，不会在最后关头发现时间不够的问题；

2、周一上线后如果出现严重问题，则可以牺牲下一个迭代，用一个完整的一周的时间解决问题；

3、将上线前的评审会、上线后的发布会、回顾会议、团队例会和团队计划会议都压缩到周一下午完成，作为一轮迭代结束后的休息，也减少了零散开会的干扰；

4、经过周末两天的休息，周一上午的发布可以更加轻松和专注一些，而不会因为每天的工作导致注意力下降，引发一些低级错误。

在团队早期的时候，建立冲刺的概念可以为后续普及Scrum打下良好的基础，我们在最初两个人的时候，便已经按每周一轮上线的节奏进行工作，在几个月以后，才调整成了两周一轮上线。早期通过一周一轮的迭代可以让团队快速的适应频繁交付的节奏，当团队适应了迭代的节奏后，两周一轮的迭代可以让团队不是那么紧张，有更充裕的时间去规划和实施一些不紧急但重要的事，比如项目的服务治理、整体企业内部流程规划等。

冲刺的目标

每轮冲刺的目标往往是计划会议中最头痛的一件事，PO总是希望团队可以多交付，而团队总是看起来想少干一点，如果PO有manager的权利的话，很容易就变成了“你们必须给我做完，不行就加班。”的结果，如果PO和团队的地位是平等的话，有时候就会变成“这个需求就没想清楚，我们怎么做？”、“你这个需求涉及到XXX系统的接口，这轮迭代干不完。”的状态，

目标的设定必须是团队在一起讨论并达成共识的，因此一个好的leader将会是促进团队共同合作的基础，有了这个基础，团队在制定目标时就会少了很多烦恼和痛苦，减少PO和团队之间对立情绪的很重要的一点是，不要在团队中在设一个和PO平级的leader，而最好让PO肩负起团队精神领袖的职责，当然这对PO的要求会高很多，但是作为和业务接触最为频繁的人，PO更能把团队的产出转化成商业价值。

冲刺的目标并不是一个军令状，见过很多团队在迭代快要结束的时候，用疯狂的加班来追赶进度，以免被领导训斥，这样的文化反而不利于Scrum的落地，敏捷原则里提到，“承认无法一开始就把事情做对”，因此失败是团队中每一个成员都应该接受的现实，失败无时不在，因此不要为了避免显而易见的失败而丧失了团队固有的节奏，也不要为了掩盖失败而去寻找各种借口，当一个团队可以真实的面对失败时，他们才可以从失败中获得成长。

我的团队在一次一个月的迭代中失败的很彻底，开发任务完成了一半，没有任何特性交付，好在我已经提前和公司高层进行过沟通，对于这轮交付的延期大家也都心里有数，因此我通过这一次迭代的失败，着重于让团队承认自己出现的问题，在回顾会议的时候，团队里的每一个人都在强调外部的因素导致需求的变更，无法按时交付，并认为大家已经完成了50%的工作。在这样的情况下，我意识到如果团队以这样的态度来面对这一轮迭代的失败的话，是无法收到好的回顾效果的，因此我在会议中发了火，并逼迫团队承认了他们的失败。当然会议的效果并没有完全达到我的预期，如果用引导和提问的方式会更好一些，不过在让团队接受失败的同时，也必须要让他们知道失败带来的不好的后果，以免团队误以为失败是可以无条件被接受的，从而对目标抱有无所谓的态度。

总结

个人的看法，冲刺是Scrum最核心的部分，通过快速的迭代来缩短反馈环的周期，以达到相应变化的目的，冲刺的概念在落地的过程中，关注的核心在于节奏的把握和目标的制定，每一轮的冲刺都是对团队的一次挑战，也同样是让团队进步的一次机会，通过冲刺的方式，不断的让团队实现小目标，进而实现一个更大的目标，便是“小步快跑”的思路的应用，当然这需要PO不断的把控方向，在战略上做好规划和设计，以免被众多的小目标迷失了大的方向。

下一篇：《Scrum精髓》读后感-需求和用户故事