主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

看了代码ABC的测试驱动开发，不免有写点东西的冲动。再不写担心被河里其他大牛抢着写掉了。来西西河那么久了，自己就这么点货色，不抖一抖过意不去。

我要声明的是，我写的东西不代表SCRUM培训，如果我说的部分内容和你接受过的SCRUM培训老师说法有差异，不用奇怪，我并不推销这个，我只谈自己的想法。培训老师讲的东西很多太抽象，培训SCRUM的时候也经常有讲师被问倒问死的情况发生。

我自己运用SCRUM进行项目管理，我相信能够回答绝大多数问题，我经常在吃饭的时候给公司员工讲SCRUM，所以养成了尽量通俗的讲解习惯，也养成了回答问题的习惯。所以大家随便回帖提问。我发现这个东西要理解透就得一问一答才行。

我不打算像SCRUM培训那样一上来先介绍SCRUM 的那些复杂的规则，那些规则会给不了解SCRUM 的同学造成一个复杂繁冗的误解，我打算通过我的理解来推导出SCRUM 的规则，以使大家理解SCRUM的规则真正的本意。

如果你对SCRUM有所耳闻，就一定会对它复杂的规则搞的很头痛，在项目实践中，人们常常会问我或者问自己以下问题：

我们为什么要这些规则？这些规则到底对项目是起推动作用还是约束作用？

客户还会问“人类创造性的思想精华居然被规则束缚，这是好的管理方法么？”。

开发组员会问，“我们有必要开那么多会么？这些会难道不是浪费时间么？”

在我写完这个东西以后能够就回答完这些问题了。

我认为在讨论之前，必须先把项目环境假设的糟糕一点。为什么呢？因为我曾经遇到其他一些项目管理人员谈到他们SCRUM用的很顺利。但一问具体内容，他们并没有遇到恶劣的环境，在我看来很多谈不上是SCRUM的运用成功，只能说还没有遇到显示其SCRUM威力的地方而已。

那么什么是糟糕的项目环境呢？我先想到以下三个，如果你们想到更多，请跟贴，我看看SCRUM能否解决。

1， 客户的需求频繁变更

2， 项目组士气低落

3， 资金规模有限

SCRUM主要是为了解决第一个问题，如果运用得当可以顺带解决第二个问题，然后帮助你接受第三个问题。

需求变更相对于开发组的外部就是来自客户，这里客户是个泛指，如果是公司内部开发，那么策划人员就可以算作客户，反正谁提需求谁算客户。

一开始谁都不希望发生变更的，即使客户也是不希望发生的，大家都希望有个清晰的文档，按部就班做完拉倒。有时候开发组明知这是不可能的，于是他们的期待的是客户先给出一个大方向，然后在开发过程中渐渐细化这些需求。其实这里已经开始埋下隐患——由于需求并不清晰，所以对工作量的需求同样是不清晰的，之后的‘细化’极可能被演变成‘变更’。为了一个词去争论的事情多得不胜枚举，开发组认为是‘变更’，而客户能举出好几个词（polish, jump, improvement, 甚至debug也算）来夺取道德上的制高点，拒不承认‘变更’。

客户天生就是提需求的，同时对产品缺乏细节概念，更糟的是一边开发一边展开想象的翅膀自由翱翔，在翱翔的过程中产生无数灵感。甚至鼓励开发组员一起翱翔。但很快开发组员就对翱翔失去了兴趣，他们只希望谁能来把客户这个翱翔的翅膀收下来。渐渐的，开发组员对于项目管理人员‘好坏’的定义变成了谁能搞定客户的灵感就是达人，有些管理人员只能想方设法和客户套近乎，然后含沙射影的指出“您的某某提议不太可行，是否再考虑一下？”。形成这样的现象很多人认为是正常的，理由来自于那句“客户是上帝”，客户真的是上帝么？但是，为什么这个上帝对自己要的东西缺乏那么多的了解呢？这个上帝只是出钱或者代表了出钱的人而已，所以把客户捧成上帝的根源只是把钱当作上帝。

我们都知道这个客户并非真正的神，他不可能无所不知，开发组员把怨气出在这个客户的无知上其实是不对的。因为如果开发组员期待一个“很懂，很有远见”的客户出现，那么和等待“神迹”没什么两样。

对当今变化迅速的市场来说，半年的开发时间内就可能遇到竞争对手拿出新创意和新想法，于是别人的新想法也会冲击到自己正在进行的项目设计上。即使没有竞争对手的产品来影响客户的想法，客户自己随着产品的日趋成形，也会冒出‘灵感’来‘完善’和‘改进’产品，如果客户不这么做，拘泥于‘当初说好这样，所以只能这样’的约束，结果很可能是这个产品还没有上市就要被淘汰了。那么有没有预见性特别强的客户呢？当然是有的，但是这样的客户是可遇不可求的，更何况，再强的预见性也是有时限的，来个两三年的开发周期也很正常，当初哪个‘上帝’能预见到两三年后市场的变化和自己想法的变化呢？前者也许预见起来还稍微容易点，而后者是不可能预见的。

既然如此，对于开发组来说就要理解需求变更其实是常态，需求不变更反而是理想主义。

我们真正需要的不是好的客户，而是好的机制来对应需求变更。SCRUM正是为此而生的。

在公司里讲到这里的时候，有些同事会问：老白，你是不是要说什么加强沟通之类的话了？

不，在我看来那是屁话，废话。先不说沟通本身也是要成本的（时间成本，茶水成本，打印成本，翻译成本……），关键是具有不同知识背景的客户和项目组沟通困难是显而易见的，项目组花费大量时间给客户解释为什么你的需求不可行，客户花费大量时间给项目组解释这个需求多么重要，项目组骂客户你们为什么一开始不想到这种需求并写进文档，客户说这不是和你们讨论嘛……最后大家精疲力尽还是你要什么就什么吧。

在我管理的项目中，如果项目组员有热情参与客户的需求讨论，那是最好，如果不愿意也无所谓。客户本来就是提需求的，客户的需求可以认为代表着市场方向，客户的出发点是从市场方向来主导的，而项目组出发点是迭代啊底层啊客户端啊服务端之类客户听不懂的单词，在两者知识结构差异下，这种沟通经常就是鸡同鸭讲。

很多项目管理会采用一个简单粗暴的手段来解决需求变更，就是规定一个时间点，一刀砍下，很早就告诉客户，那个时间点以后不要再变更了。显然时间点定的越早，项目组越高兴，但客户越不满意，因为他们无法对应市场或者自己的灵感来‘改进’产品了。

这个方法不能说没有用，但并没有解决问题，因为那个时间点之后的需求就禁止变更了，只是把矛盾累积到最后去了而已。先不说扯皮扯出那个时间点是个很费口水的事情，就算达成了那个时间点的共识，过了点以后，客户往往还是不甘心，还是会以各种各样的理由来把自己的变更加进去。

那么还是那个问题，依然是需要一个机制来对应需求变更。

下一篇

• 【原创】闲聊敏捷开发——SCRUM（二）
• ※ 西河文萃 第25期 2009年8月11日 ※中