大家有人在用SCRUM吗？（技术讨论，长贴慎入）

空山鸟语

SCRUM是个当下非常时髦的jargon。不少公司都声称在推行Scrum，招人也要求有Scrum经验。如果你告诉别人你没用过Scrum，别人看你的眼光都好像城里人看乡下人似地。大家有人实际在用吗，效果如何？

按照Scrum的创始人之一Ken Schwaber估计：“75%尝试Scrum的组织无法获取他们预期的效果”。他给出的解释包括不应该干扰Sprint的执行、领导要对Scrum方法和开发团队充分信任等等。但是从我的角度看，这个Scrum好像也没有那么神奇，如果真的有这么高的失败率，不光是操作上的问题，我认为甚至于从理论上说这都是个不完备的体系。

一般来说一个软件项目的成功，需要首先对业务领域进行建模，然后把业务模型转换成技术方案，之后运用计算机软硬件加以实现，最后以构造的技术成果向业务领域进行反馈。从而完成业务领域和技术领域的交互。传统的瀑布型开发法、演进原型法、UP等等都是虽然形式不太一样，但都有这样一个过程的循环。后来的XP其实也是这样的。只不过它走向一个极端，把分析、设计、开发、反馈这四个过程混在一起，力图把开发过程中的交流最大化。

按照传统的软件工程的观点，一个软件项目的成功很大程度上依赖于对需求的把控。包括对于需求的挖掘、分析，需求范围的控制、需求变更的控制等等，都是项目管理的头等大事。项目成功的另一个重大课题是沟通，也就是怎么在业务领域跟技术领域之间进行有效的理解和反馈。这方面既包括两组不同的人之间的沟通也包括两个完全不同的知识领域间的沟通。从传统的瀑布模型到XP，可以看到项目中对于沟通是越来越重视了。

但是反观Scrum方法，开发团队得到的需求来源就是Back log，然后从中分批取出一些构成一个个的Sprint。这个Back Log怎么来的呢？product owner在制定这个Back Log时需要采用哪些方法呢？技术团队应该参与需求分析吗？对于这些问题Scrum都没有提及。貌似这些都不是Scrum关心的问题。

一般来说，除非是那种超级简单的项目，即使是需求非常明确了也还是需要有个设计的过程的。例如：数据库结构设计、软件的架构设计、UI设计、性能设计、可用性方案设计、测试方案、集成方案、数据迁移方案等等。这些都是需要在拿到需求规格说明书之后先有一个通盘的考虑的。在Scrum方法中，这方面的过程也没有体现。以从Back Log 到Sprint这种方式是不可能完成这么复杂的任务的。

而且Scrum描述的组织结构也很奇怪，product owner 负责产生back log，但是他不负责项目的整体成败；scrum master是项目团队之外的第三人，他的职责是“保护开发团队，使他们不受外界干扰，并负责与manager进行沟通“。这个Scrum master更不会负责项目的成败了。那么谁负责呢？PMP手册中，沟通管理是项目经理的职责中相当重要的一个方面，Scrum倒好，连项目经理的位置都找不到了，更别提项目关系人的沟通管理了。

对于这个问题解释不清其实是个非常致命的硬伤。项目管理不是写出能运行的代码这么简单。项目经理要做进度计划、资源计划、成本计划，要保证项目能使客户满意，还要能保证赚钱。这是工程跟工匠的思维方式的差别。但是如果到了出来Back Log从能评估时间成本，才能确定进度、资源，是不是太晚了？

所以我认为Scrum是个不可取的方法。在传统的软件过程从分析、设计、开发、测试、交付这个比较简化的过程链中间，Scrum它的概念覆盖到的也就是开发和测试两个阶段。他本身并不是针对于整个软件开发过程的方法。反而更像是开发团队内部管理的一个方法。而即便是用于开发团队内部管理，Scrum方法其实也是一个非常封闭保守的方法。说起来是Agile方法，但是实际上是反对沟通，拒绝变化的。所以实际上也不是什么好的方法。

以我比较狭隘的思想揣测，Scrum方法十有八九是一群开发人员连续加班之后一起发牢骚的时候想出来的方法。尽管Scrum声称能解决很多问题，但实际上这是一个不系统、不全面的方案，很可能什么也解决不了。我估计没有多久大家就会忘了它，又开始追逐下一个概念了。

ginobilis

原帖由 空山鸟语 于 15-6-2011 07:52 发表

                               
登录/注册后可看大图

哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

我做technical consulting的  确实是按工时计价，但是关于这个问题我跟scrum training讨论过。他认为即便是传统的固定合同，以TDD+每个sprint交付这种形式，风险也比传统方式小很多。因为传统瀑布容易把风险积累到最后不可收拾，scrum把风险分散了。而且就算合同是传统的，一般客户也愿意参加每个sprint的review来验收功能模块，客户还是希望早点看到能运行的功能的。

如有兴趣 可以参考下我公司里某个scrum 项目的现实进程   http://blogs.perficient.com/mult ... ficient-scrum-team/

空山鸟语

哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

ginobilis

原帖由 空山鸟语 于 14-6-2011 22:37 发表

                               
登录/注册后可看大图

楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

我也是混混，Scrum只主要价值就是降低项目风险 最短时间交付最有价值部分。但是也正是因为太注重交付，我认为就有点不Agile了
以我个人的观点，Scrum对需求的要求可以概括成Adapter to client。所以很欢迎有任何需求变更，那scrum观点来讲，一开始就把需求考虑得很完善很详细，本来就不Agile了。还是做一步交付一步，随时让客户满意这种方式更好。甚至每个Sprint Review时候要交出来的product，也没有任何文档或PPT - 'Slides are lies'。 Review meeting上，让product owner玩交付的产品玩到满意，那就是scrum就最终目地达到。在Scrum实践中，需求最细化的文档很多就是细化的user story，比如里面对各个字段的要求进行说明。
Scrum项目里没有项目经理，只有scrum master，其实你前面也提到，scrum master没有起到管理作用，主要任务是对项目排除一切障碍。这种管理模式其实和scrum的起源也有关，scrum起源于橄榄球运动，这项运动本质上要求各个队员竭自己所能，没有明确的分工。“每个成员都可以干所有的事情，每个成员又都有选择权干自己最能干的事情。” PM的角色被基本弱化了。Master除了领导一些常规事务外，和其他开发人员也没啥区别。Scrum team 里只有三种role: Scrum master, team member, Product owner. PM这个角色是不存在的。

Scrum好处主要站在客户角度，确实对于中小型项目而言。如果很好实践，scrum客户满意度超高。一来TDD+CI等上去后  代码质量绝对有交代，二来每个礼拜都交付，客户风险很小。我们瀑布经常碰到的问题就是整个项目delay，客户恼火。但是以每个sprint交付的模式，而且还是所有user stories已经被prioritized的情况下。客户认为最有价值的东西以最短的时间进行交付，即使最后因为经济原因项目终止，大多数可用的价值已经被交付。因为Scrum对交付的要求很高，必须是potential shipable product。所以根据我的经验 中小型客户还是欢迎scrum的

[ 本帖最后由 ginobilis 于 15-6-2011 00:43 编辑 ]

空山鸟语

楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

ginobilis

我自己是certificated scrum master. certificated scrum product owner,certificated scrum developer但是我也不太喜欢用scrum
对于中小型项目来说  客户是挺喜欢scrum的。风险最小，每个sprint做出来的都是priority 最高 potential shipable product. 就算最后项目出现问题。最大价值的部分也都deliver了
但是对于程序员来说scrum那么繁多的ceremonies就感觉死板，甚至不Agile了。有些企业执行了scrum 但不agile，比如yahoo
像TDD，当然有很多好的方面，但是我也确实感觉到影响了我的开发效率，总之不爽
总体来说scrum太注重deliver，对于架构设计很忽视，我不认为能适用于大型项目
当然我觉得学学还是好的，比如学学scrum的CI 标配selenium + hudson + SVN+sonar 虽然我还没来澳洲，但scrum那些破证和一通吹牛搞不好哪天来澳洲找工作会有那么点用呢  呵呵

Richard.G

原帖由 空山鸟语 于 8-6-2011 15:53 发表

                               
登录/注册后可看大图

你家娃贵姓？看起来好口爱啊。

  谢谢！！ 俺家娃的确怪腔比较多。不过楼歪的太厉害了，哈哈

空山鸟语

你家娃贵姓？看起来好口爱啊。

Richard.G

原帖由 空山鸟语 于 8-6-2011 14:42 发表

                               
登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我是真倒霉啊，从来没有碰到agile或者scrum的项目，看来waterfall和V－MODEL要用到老了。。。。  

woodheadz

原帖由 空山鸟语 于 8-6-2011 14:42 发表

                               
登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我们现在的产品待实现的story上百个,还不是好端端的在用Backlog。 Backlog又不是用来描述需求的，里面的项目仅仅是一个周期里面要完成的内容，能有多少呢？你把所有的用例一股脑放到backlog里，还指望完全依赖Backlog帮你管理需求，当然用起来就很头疼。
一个方法提出来，具体应用时得根据实际情况确定应用方法，生搬硬套用起来当然就很别扭。
Scrum的确不大合适太大的项目， 但这个和用例数量是没有关系的。

空山鸟语

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能力了。在小纸片上写用例肯定表达能力不如UML里的用例那么强，而且数量还不能太多，那就只能适合很小的项目了。

liluliang

scrum实在不适合业务逻辑相对复杂的系统
前几周公司内部推广了jira上的一个新组件GreenHopper，说是专门支持scrum模型的
刚开始花花绿绿的挺好看
后来上百个card一出来，我看了真想吐
现在已经没人用了。。。

black_zerg

agile 四个目标还是没什么问题的，其实说的就是不要瞎搞，总之要让客户高兴，结果后来那些方法我觉得都是反agile的

空山鸟语

This is really really a good idea!

sliuhao

原帖由 yuba 于 8-6-2011 13:21 发表

                               
登录/注册后可看大图

支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

老油条

yuba

支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

key

原帖由 空山鸟语 于 4-6-2011 14:42 发表

                               
登录/注册后可看大图

在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。 ...

呵呵，还是小心点。
要知道全球目前大量软件公司转向Agile，
以你个人的观察和思考就下结论，未必有说服力。

空山鸟语

在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。不用讲太多理论模型，如果大家都觉得不爽那就肯定是有问题了。估计真正的Agile原教旨主义者也就是Thoughtworks这种公司吧，大部分公司都是以混搭为主的。
俱往矣，数澳洲IT民工，算我一个。来了这面带队做项目的机会估计比较渺茫了。

最近赋闲在家，每天富裕时间一大把，正好翻箱倒柜把自己不太熟的东西拿出来晒晒。通过大家的讨论，基本看清了，scrum真的是黔之驴啊。下次Interview的时候如果有人再提scrum就可以理直气壮地直接鄙视回去了。呵呵。

key

原帖由 coredump 于 3-6-2011 22:57 发表

                               
登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

这个事老core说过两次了，
但每次都只是点到即止，希望能多分享一下。

woodheadz

原帖由 coredump 于 3-6-2011 22:57 发表

                               
登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

哈哈，同感！
我觉得把很多精力花到过程里是件很恶心的事，尤其对小点的团队而言，大家遵循一些尽量简单的基本原则就好，出现问题再针对问题个别解决。
对于大团队嘛，最佳实践就是把它分成小团队

[ 本帖最后由 woodheadz 于 3-6-2011 23:04 编辑 ]

coredump

原帖由 woodheadz 于 3-6-2011 22:45 发表

                               
登录/注册后可看大图

重型过程确实是这样。 我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全 ...

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

coredump

XP 我感觉是很快就知道什么意思了，要传达什么精神，要达到什么目的
SCRUM 给人云山雾绕的感觉，我们现在就是SCRUM team，说实话，我不知道确切什么是SCRUM

woodheadz

讨论那么多，总结起来我觉得还就是一句话：没有银弹。
SCRUM也罢，XP也罢，如果想着一旦实施后就能给团队带来如何如何的改观，最后的结果一定是失望。
尤其通过管理手段自上而下实施类似SCRUM这类敏捷方法的做法，实在是和敏捷方法的核心价值相悖，结果多半就是鸡飞狗跳，一地鸡毛。

woodheadz

原帖由 black_zerg 于 3-6-2011 22:22 发表

                               
登录/注册后可看大图

我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。 大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把 开发人员当工具当机器看，认 ...

重型过程确实是这样。 我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全是两回事的，但也有规模不小的项目最后通过大量的会议和沟通基本完成了用户需求的。 所以我觉得对重型方法也不能一杆子打死。
当然重型方法从来都会扼杀创造力，而且单个成员的工作效益远不及小团队成员。但大项目就是如此，也是无可奈何。

空山鸟语

真正好的程序员应该不是只会敲键盘，应该能一针见血地提出有价值的解决方案。在这点上我完全同意。其实所谓的XP所追求的最高境界也就是这样：团队里面每一个人都既是高水平的程序员又是很不错的业务分析人员，旁边随时坐个客户代表。效率特高、文档特少、客户特满意，项目特赚钱，程序员也特赚钱。人人堵满意，呵呵。

但是这样的理想状态却是不稳定的，很容易就会失去平衡。比方说如果工作量超出了团队的生产力极限，需要增加相对水平差一些的程序员进来，以前的程序员就得抽出很多时间指导新人了。他自己就没办法象以前那样专心搞技术了。如果新加入的成员很多，甚至就得考虑职责分化，安排专门的人来负责整个团队的协调了。

再比如，如果碰到了比较陌生或者比较复杂的项目需求，以往的经验可能就遇到了瓶颈，没办法象以前那样运用自如了。这时候与其让开发团队在战斗中成长，还不如引进一个对这个领域比较熟悉的人专门负责需求分析呢。

所以说楼上描述的团队结构，或者说XP的团队结构，适合于比较熟悉的项目环境和不太大的项目中。在这个之外就不是很合适了。

从管理的角度来说，随着组织的膨胀，组织的人均效率和组织的智商是不断降低的。大团队肯定比小团队效率低，小团队肯定不如最好的个人效率高。这个是已经有了结论的东西。讨论一下团队的组织形式还是挺有价值的，不定哪天就能用得到。

TonyPan

原帖由 black_zerg 于 3-6-2011 22:22 发表

                               
登录/注册后可看大图

我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。 大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把 开发人员当工具当机器看，认 ...

你说的这些都是实践中天天发生在我周围的事情，scrum催生了一堆天天开会，指手画脚的人，把这些人拉来干活，屁都干不出来。也就是这些人最为支持这个神奇的方法论，让他们变得无比有价值。我们几个主要的经理对当前技术并不是很了解，现在招了几个senior的开发员，所以把希望都寄托在scrum上，让各个项目能够自己管自己，我只能称这个叫掩耳盗铃，画饼充饥。可惜老板不懂这两个成语。

black_zerg

我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。 大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把 开发人员当工具当机器看，认为这个就是体力劳动，实际上杀灭了创造力，同时这些模棱两可的理论支持养活了一大帮闲人，又给了懒汉滥竽充数的机会，最终的结果就是毁掉团队，项目没人负责任，强的人走人，弱的反而都留下来混。当然仁者见仁智者见智。楼上是可能没见过那些真的耗你budget的，一个简单需求能开十几个会还在那里讨论，然后manager唯一会做的就让你报百分之几的数字，就这些个人就这么点破事就浪费掉你一半的预算，然后程序员就开始不爽开始糊弄manager,反正大家空对空的瞎扯，真干活的都是吃力不讨好那还谁愿意花时间在研究技术琢磨怎么提高设计上？ 大家都学着吹牛开会，有机会就 delegating 去。这些中间环节本来是能精简就精简，但如果你插一个人在那里，他会往死里强调和拉长他的工作，没有困难还制造好多困难，客观地说：不是方法不重要，而是这些脱离实际的过度强调方法太容易让混混钻空子毁掉项目预算和破坏团队文化。

[ 本帖最后由 black_zerg 于 3-6-2011 22:32 编辑 ]

TonyPan

我们公司自09年底开始实施scrum，到现在基本是鸡飞狗跳，几个所谓成功的项目也都是挂羊头卖狗肉的。同意LZ的一些观念，scrum的方法论更适用于原型功能的开发，对开发阶段的项目控制有明显帮助，对于开发人员内部的沟通也有促进，但是其作用不能涵盖过往瀑布模型的生命周期。

如同scrum鼓吹的那样，把product owner纳入到scrum团队，是开发者和需求者之间的沟通更加通畅，但在实践中呢？需求者与开发者之间的鸿沟，是有其天然的存在背景的，需求者从来不属于开发团队，不可能dedicate到一个项目中的，不是通过一个软件实施的方法论就能够改变的。折中后的妥协也只是用BA来带代替product owner的角色，传统PM成为scrum master，反倒不用队项目的整体成败负责，只需要督促scrum的运作，我个人的感觉就是能够指手画脚的地方多了，承担的责任却少了。可天下有这个便宜的事情吗？没有明确的项目总负责人，就只有整个团队一起负责，也就是不负责。

在具体实践中，backlog的定义完全是从需求角度定义的，在这个基础上定义user story，然后分拆到sprint，task。整个项目的详细设计过程被弱化到可以忽略的地步，最后的结果就是导致系统的模块性差，可重用性差。我们scrum团队内包含master，owner，BAs，Developers，Testers，号称各人的role不固定，可以合作完成task，实践中这属于bullshit，每人的技术背景和作用完全不同，基本还是各人干自己的一摊子，但因为同在一个scrum团队中，多了很多指手画脚，扯皮打架。敏捷的目标没实现，效率却大大降低。

或许我们公司实践中有失误的地方，但从结果看，很不理想。因为从管理层的各个经理以前都没有接触过这种方法论，我们花了大量的时间和精力去完善scrum的实施，但收效甚微。

软件项目的核心还是人，懂管理的人，懂技术的人，负责任的人，能拍板的人，没有什么方法论能够把垃圾变成牛人，但不当的方法论实践肯定可以毁掉牛人参与的项目。
现在行业里这个词火的不行，各种实践，争论一直没停过。帮助了多少公司成功实施项目我不清楚，但至少催生了一个推广scrum的市场。

woodheadz

原帖由 black_zerg 于 3-6-2011 21:17 发表

                               
登录/注册后可看大图

人在牛也不行？ 这么说吧，强势程序员绝对不是只知道敲键盘的，他必须要熟悉软件生命周期而且非常熟悉需求，知道怎么用最少的时间让客户绝对满意，如果你对自己的要求说只是会敲点代码，那根本就算不上什么牛程序员， ...

我看你是走极端了。
对于三五条枪的小团队而言，由个把你所描述的强势程序员带领可能是最佳方案。但对于十几几十人以上的大中型团队，不敲代码占预算的人就不是浪费了。而在类似外包开发之类的场景中，过程和方法就更重要了。
我自己是比较纯粹的技术人员，厌恶复杂的过程，现在也在一个相当技术化的弱过程团队中工作。

空山鸟语

17楼中提到的一些观点我非常赞成：

“对产品Backlog的指导太少”，尽管提到有“史诗->主题->故事->任务”这样令人头晕的名词，但是还是不成体系。Back Log的产生方法没有介绍，Back Log本身要达到什么标准也介绍的很粗。Work Breakdown Structure这样一个简单的词其实就足以覆盖所有这些术语，甚至内容还要更丰富一些。；

“在团队和业务的交流上会产生局限”，这就是我说的Scrum在沟通上的局限。Scrum还是聚焦在开发团队身上，对于业务层面的事情关注太少，两个不同领域间的沟通更是严重不足；

“Scrum暗中包含反管理”，这就是为什么我开玩笑说Scrum是几个技术人员头脑激荡的产物。靠团队的自我管理来实现项目的高效率，我认为即便不排除会有奇迹式的成功案例，但是总体而言，这始终不是特别有价值的尝试。即使在一些规模很小的项目中能取得成功，可能也多半是因为对于特定的情况而言，只需要比较简单的项目管理而已。