迷失在Scrum – 猪眼看Scrum 

Scrum 作为一种最近非常流行的敏捷方法论。有很多文章都讲到Scrum 的好处，Scrum 的最佳实践等等。 本文无意再次强调这些而只是列举了一些在实际采纳Scrum的过程中不适当的做法，并和最佳实践做一下简单的对比。或许其中有些夸张，不过，请在怒斥之前对比下自身所在团队的实践。

PS: 俺长期战斗在生产第一线，按照Scrum 的说法，俺这样的角色是猪，所以副标题是，猪迷失在Scrum中。

0/ 团队成员 (Team member)

应该由那些人组成Scrum的团队？Scrum要求有三类基本的团队成员，一个Scrum Master，一个Product Owner，以及若干普通成员。很有意思的一点，Scrum实践推荐团队人员不要太多，一般5到9人。何故？效率！敏捷强调沟通，人员太多严重影响沟通效率。

对几个人的小项目来说，Scrum团队很简单，把人都拉在一起，基本上正好符合最佳实践。

对大型项目来说，如果要采用Scrum 的方式，在组队问题上最忌讳的大概就是把所有人看做一个团队。人太多了，沟通没法弄。几十个人分散在不同的小项目组，这些人按职责分可以看出测试人员，前台人员，后台人员；按功能模块也能很自然的分开。为什么不按这些分几个团队呢？把不相关的人拉在一起开短会，做回顾，能有多少是共同的问题呢？如果一个人提出的问题，超过半数人完全不知所云，这又能解决什么问题？

但也不是说非5到9人不可，在保证沟通效率的前提下，稍微多些人应该也可以接受，视具体情况而定。

1/ Product Owner

1/ 每日短会 (Daily Scrum)

每日短会大概是Scrum 实践中最容易被采纳的了。因为简单，当然用好了效果也会非常好。

善做表面功夫的人喜欢每天开短会，而常常选择性忽视其他Scrum 实践要素。我们是Scrum啊，你没见每天早上我们都凑一块说几句吗？我所经历过的一次就是，项目经理大手一挥：我们要Scrum喽，大家都过来开会。好家伙，将近三十号人全凑过来了。现在呢？已经没人理这样的短会了。

每日短会是要发现问题的。一两天没有问题算正常，但是持续一段时间大家都没问题就应该算是一个迹象–项目遇到了问题，或者是大家不敢提问题，或者是大家不知道存在什么问题。对于没人敢提出问题的情况，Scrum Master应该做检讨，是什么压制了团队成员的主动性。对于不知道存在哪些问题的情况，Scrum Master和Product Owner都要做检讨，Scrum不是光开短会那么简单，作为敏捷实践，Scrum有像Backlog 之类的诸多工具，项目的知识不只是在某几个人的脑子里，是应该团队共享的。不论哪种情况，经理们都要注意了，尽早改善情况，不要等项目失败了再追悔莫及。

没有采纳Backlog 等工具，其实也不怕。如果大家都明确在讨论什么，能够互相给出建议，那也是效果不错的沟通。要是就项目经理和路人甲知道怎么回事，拜托，大家都很忙。

2/ 冲刺（Sprint）

你见过百米线一直在变的比赛吗？

那对发布时间一直变的产品你感觉怎么样呢？尤其这个产品还是亲身参与其中的，没错，很让人沮丧，看不到尽头。对传统的瀑布式开发来说是这样。对短期冲刺来说情况可能稍微复杂一点。
Scrum 的每一个冲刺，要完成哪些功能，优先级怎么样，都是冲刺开始之前约定好的，根据团队的平均工作速率做的估算，而且每个冲刺的产出，应该都是可交付的。

好吧，我们的Scrum就一个冲刺就完成了。恩，要么你这个项目很短，一个月就可以搞定。要么你就是过来砸场子的瀑布流。

一般来说Scrum推荐的冲刺时间是一个月，但在实践中大家说法不一。基本上，观点讨论倾向于，开始用比较短的冲刺周期，评估出可信的团队开发行进速度；随着团队对Scrum 的接受，再根据客户的响应情况，定出一个合理的冲刺周期。

3/ 任务列表（Backlog）

每天工作干什么？完成情况怎么样？都需要有个地方说明，在Scrum [...]