最近看了一篇关于如何做好站会（Daily Scrum, Daily Standup）的文章。文章内容且不论，第一段文字里讲到站会作为“仪式”，就像是“神圣不可侵犯的惯例”，这个观点让我不禁莞尔。

在我的工作生涯里，我有幸近距离观察过几个高效团队——那种非常敏捷、非常卓越的团队。在这些团队身上，我可以看到很多敏捷元素，例如高度纪律性、集体所有制（Collective Ownership）、充分沟通与协作、快速交付……但是没有一个团队是一丝不苟地或是松散地用Scrum方式运作。

那么，是何种神秘调料让这些团队变得高效，成为敏捷的团队？其实答案在上面已经给出——这些团队秉持着敏捷的价值观，每个团队成员都在身体力行之，那么无论团队的运作方式是什么样的，团队都是具备高度敏捷性（Agility）的。

这也正是Doing Scrum和Being Agile的区别。并非是，只要开始用Scrum框架来运作团队，有了3355，团队就敏捷了。Scrum的意义在于持续地帮助团队接纳敏捷的价值观，并将之反应在日常工作当中。无论是3个角色，还是5个仪式，概莫能外。【注：3355指3个角色、3个产出物、5个仪式、5个价值观。其中价值观的采纳是最困难的，因为它们不是流程性的，而是观念上的】

作为仪式性的站会，是用来提醒团队，我们确实地同时工作在最高优先级的一个或两个故事上吗？我们真的关注彼此在做的事情吗？我们在做的事情真的能够对齐在一起吗？我们在日常工作中做到及时地、充分地沟通了吗？进一步地，我们是否每天都在有所进步？尽管有那么多关于站会（或是其它仪式）的Tips，但是在我看来，如果一定要找一个有价值的出来，那就是保持站会时间不超过15分钟。如果我们严格地遵照了站会的所有Tips，却并没有开始真正地反省并拥抱站会背后的价值观，那么我得说，站会是完全没用的！而反之，如果我们不断反省并改进，那么站会是不是一定要回答那三个问题，或者站会是否必要，都是可以讨论的。

同理，其它的Scrum仪式、或者更激进一些地，整个Scrum，都是并非不可改变的。说到此，我很难想象一个团队在采纳了Scrum一年、两年、甚至三年后，依然严格地运行在Scrum框架下。Scrum是改变的起点，而非终点。一个敏捷的团队如果运作在Scrum框架下，反而可能受到负面影响。

对于正在Scrum框架下改进的团队，请不妨停下来思考一下，每个Scrum的角色、每个产出物、每个Scrum仪式，其背后的意义和价值观是什么？你和你的团队是否真的接纳了这些价值观？你们是否每天都在寻找可以改进的方面？你们是否可以在秉持这些价值观的前提下去简化或者替换Scrum的部分或是全部？记住，Scrum是改进的起点，但绝非终点。

【那些高效团队是怎样运作的】

虽然每个高效团队都有自己独特的运作机制，难以直接模仿，但是借鉴一下他山之玉，可以帮助开拓思路。

2012年的时候有一次机缘巧合之下，我认识了豆瓣的一位员工。当时我完全不知道豆瓣拥有卓越的工程师文化，所以在了解到豆瓣没有采纳Scrum或类似的迭代式敏捷框架的时候，我很热心地向他推荐Scrum。过了一段时间，这位豆瓣员工邀请我访问豆瓣办公室。第一时间踏入豆瓣的办公室，我就知道当初我的推荐是多么荒谬了。

办公桌都是没有隔断或者障碍的长条桌，不会给沟通带来阻碍。相邻员工之间的距离既不会远到难以交谈，也不会近到彼此干扰。到处都是白板，因此无须四处预定会议室……好的环境促进团队更好地沟通。

在交谈中我进一步地了解到，豆瓣员工的collective ownership意识很强，并且通过code review、code dojo、持续集成等很多方法加强成员之间对彼此工作的关注与协作（同时强调对质量的追求）。版本发布速度非常快，并持续从真正的用户那里寻求反馈。产品人员与研发团队之间的沟通也是非常顺畅的；需求呈现的形式不是用户故事，但一样关注用户场景、不追求功能的完备性但追求快速用户反馈。

这样的环境，加上这样的价值观，我们不难看出，豆瓣自己的运作模式，是远远要比Scrum更加高效的。同时，豆瓣模式背后的价值观，又与Scrum框架背后的价值观是一致的。我们并非为了Scrum而Scrum，而是为了接纳敏捷价值观、并将其体现在团队日常运作当中，因而选择一个相对容易的轻量级敏捷框架作为改进的起点。如果忘却了初衷，为了Scrum而Scrum，那就太糟糕了。

感谢我的两位好友申健和侯伯薇在文章内容方面提出宝贵的建议。