主题:【原创】闲聊敏捷开发——SCRUM(一) -- 哈酷

复 140 阅 160201
2009-06-08 22:33:26哈酷
1 【原创】闲聊敏捷开发——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正是为此而生的。

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

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

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

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

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

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

下一篇

关键词(Tags): #SCRUM#敏捷资深推荐:铁手, 通宝推:华恩,铁手,
主题:2236879
2012-08-25 05:59:07
山海马甲
2 赞一个写的很透彻。

帖:3776428 复 2236879
2012-08-25 08:37:04哈酷
3 等忙完这段我接着写

2年了,自己做公司,操心得很,一直闲不下来落笔。但对于SCRUM的管理有了更多的认识。

帖:3776462 复 3776428
2013-02-09 02:31:45
裸飞
4 哈酷兄最近闲下来了?

敏捷开发的坑啥时候能填上?

春节快乐!

帖:3844750 复 3776462
2013-02-10 09:28:47哈酷
5 被催填坑是一种荣幸

过去这年我的创业路惊心动魄,对SCRUM也有了更深的认识理解,很多想法需要在脑海中思考总结并在实践中检验,待我小有收获之时定不吝与兄台分享。

也祝你新春快乐。

通宝推:梦回唐朝,杀猪杀屁股,
帖:3845044 复 3844750
帖:3892813 复 3845044
2012-08-25 13:33:06
裸飞
4 那更要请教了

自己练摊之后看问题会更全面些,多了很多以前没有的视角,能够从更多的纬度看待管理,操作方面限制和方法也会更多,花等下文。

帖:3776613 复 3776462
2009-06-19 04:11:31哈酷
2 【原创】闲聊敏捷开发——SCRUM(六)

上次结尾讲到了考评,不出所料,说到考评环节,果然问题多多,我再次声明:这个考评部分确实和SCRUM培训教材上说的不同。SCRUM培训中没有对考评部分做什么特别说明,这部分确属是我自己的私货了。那么我为什么吃饱了非要提这个部分呢?

我费半天劲卖私货其实是抛个砖,希望能引玉。真心感谢大家的回复,说明大家一起在思考。这是伟大的思考和讨论,我们怀着人文精神,为人类寻找管理生产的方式……打住。

我必须把逻辑链整理一下,事情必须要说圆。

PO为什么要信任poker-plan会上team的报价?

当然我可以说PO要相信team,让他相信SCRUM,告诉他根据经验这样一定是对的,但别忘记PO有可能是外部客户,当我和客户解释的时候,必须要逻辑完美才能说服客户,高举SCRUM大棒是不行的。

即使是内部客户,我已经说服了大老板支持SCRUM,但如果不能让PO真正相信SCRUM,他们一样会抱怨的(以前瀑布式可能是TEAM抱怨,现在换人了而已),他们的抱怨一样影响工作成果。

PO在poker-plan会上是来买东西的。

想象有两条街,一条街都是国有企业,但隔壁一条街全是私营的,东西一样。假设你只能挑一条街去,你更相信哪边价廉物美?我选私营街。原因在于你相信自负盈亏的店铺才会有争夺业务的动力,才会把价格报的实在,东西也会做的好,是这个理不?

这里就是关键的逻辑起点,team成员必须有争做story的动力。这个动力来源何处本身倒不重要。

比如来源于团结,大家特别团结,混日子的会被眼神杀死,OK。

比如来源于自我实现的愿望,大家都有这种愿望,抢着做,OK。

比如来源于学习欲望,不断的想做点东西提高自己的能力,OK。

再比如,或者大家都是公司股东,都一股脑就想着把项目做完赚钱,也OK。

反正怎么都行,只要满足:team成员有争做story的动力。而且最好这个动力是能够摆上纸面的,要说服PO啊。

这并不容易啊!要知道很多story很无聊的,有聊的和无聊的工作也差不多是二八分,团队成员的动力来源能让大家争做这些无聊的工作么?

我能想到的办法就是计点,很多工作PO觉得优先度很高,但很无聊,大家都不愿意做,那么一定点数比较高,点数高了,自然有人愿意做了,这是符合市场经济价值观的。为什么点数高了就有人愿意做了呢?要让他心甘情愿的做,前提还是这个点数对他是有激励作用的。至于多大程度上的激励,当然可以先约法三章。甚至只是打出来给大家看的,但不要忘记,即使只是打出来看,也是软激励,也是有用的。如果不幸团队成员士气很低,软激励不起作用了,那么只好直接和奖金挂钩了,挂钩程度越大,激励越大,同时‘竞争过度’的可能性也越大。

另一方面讲,因为team成员在意自己的积点,那么就会更加在意和PO的沟通,从而确保自己的story能够顺利validate,从而做下一个story。这就是自负盈亏才能够价廉物美的道理。

我一开始就说过,要把项目环境考虑的糟糕一点,糟糕的环境包含了三个方面:

1,客户的需求频繁变更

2,项目组士气低落

3,资金规模有限

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

我特意扯出计点考评的原因就是为了第二个方面啦。因为我认为SCRUM培训中这个环节有缺失。导致了逻辑链不完整,这样事情就说不圆。SCRUM项目失败的原因很多,其中很多一开始就败了,有一个重要原因就是没能把事情说圆,于是大家抱着强烈的怀疑执行着纸上写的规章,尤其是PO他们带着这样的怀疑,事情就很难办好。

如果哪位同学能够不用计点考评,就可以把这个问题解决,我老白真心求教。真的,吃管理饭可不是动嘴皮子驳理论,项目好坏事关真金白银。现实很残酷,我手下没那么多士气高水平高并且带着强烈自我实现欲望的程序员团队,有限的奖金也希望能够用在实处,留下英才。

最近有点忙了,接下来不定期更新。

通宝推:我爱我家fh,
帖:2258899 复 2236879
2009-06-19 11:19:54james
3 花您,顺便请教.

如果team的成员达成一个私下的协议,平均每次出价都在自己出价的基础上提升100%,这样team成员的工作可以变得轻松,收入不会减少,当然这有个前提是点数决定收入,而不是项目的总预算;或者说,项目的总预算是可以变的,但是单位点数对应的报酬不变; 如果反之,项目的总预算不变,那这样的出价结果就是预算必须增加了. SCRUM是如何应对这种情况的?

帖:2259477 复 2258899
2009-06-21 07:22:20哈酷
4 可以代表PO提问了,楼下糯米园子正好回答了

只要人数不太少,那么价格联盟难以成功,掌握有限的‘竞争’是可以控制到最适合你们TEAM的状况的。

帖:2262299 复 2259477
2009-06-19 12:03:10糯米园子
4 价格联盟在自由竞争的框架下从来成功过吗?

没成功过吗?成功过吗?没成功过吗?.....哈哈哈哈

好吧,根据一个被广泛认可的竞争模型,Bertrand model(或者叫Bertrand competition)

我个人不看好这样的价格联盟可以持续下去..

更何况,PO无论何时都有抽身而去的权力,无非是他要做一个权衡. 所以一直加价是拿不住PO的...

帖:2259515 复 2259477
2009-06-21 07:30:39
哈酷
5 不错,PO的优势是与生俱来的(由资本带来的)

PO搞垮价格联盟是很轻易的事情。这也是说服他们相信SCRUM的一条。

帖:2262315 复 2259515
2009-06-18 08:24:54zhengyi1998
2 【求助】问个傻问题

在公司作内部项目的时候, 用了一下scrum。 开发人员可以及时得到 PO的反馈。

不太明白的是, 如果给客户作项目, 怎么预估多少人月呢。 如果不明确说明, 客户有怎么会同意签约呢。 总不能说 6个人月, 干到哪算哪

帖:2257193 复 2236879
2009-06-19 02:34:51哈酷
3 先看

哈酷:一点不白痴,很实际的问题

此外:有可能遇到‘坚持认为自己不会有修改’的客户。这种客户往往很初级(客户确实有三六九等)。那就要通过一些手段,让他了解‘需求变更是常态’。教育客户真的很需要技巧。

帖:2258772 复 2257193
2009-06-18 23:33:55糯米园子
3 我个人的想法

第一轮谈的时候,谈要做什么,做出一个宽松的预算,给后面的变更留出余地.

还有一个办法是,对于后加的功能,签订维护协议,在运营后的几年里分批支付.

帖:2258474 复 2257193
帖内引用