分享到
为什么Scrum不行?
 

作者:陈皓 ,发布于2011-08-03

 

这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们戴上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。)

因为本人经常站在Agile的风口浪尖,所以我有必要也来一个“免责声明”。Shit!其实我想来的是“不免责声明” ——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判,本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张,我只是想说,下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题,从而可以让你们明白软件开发中的人的重要性。

Reason 1: Scrum 的基石是相信人。创造一个安全的环境,这样每个人都能相互学习,相互直言。但是,这是不行的,这世上有很多人并不关心这些,而且政治和竞争到处都是,办公室里无小事,你和别人交心,你相信他们,最终受伤的你自己。你真的以为那里有空间让你可以去犯错,去冒险吗?别天真了!你啊,too young, too simple, sometimes naive!

Reason 2: Scrum 认为只要给员工足够多的自由员工就能做得最好。这该死是理论是基于什么玩意?不可能,人的天性是懒惰的,他们才不会把事做好的,他们只会做相应报酬的工作量,还可能基本还达不到其相应的报酬,大多数人都在混日子啊。尤其是和经理比起来,谁不想能尽快地成为经理或Team leader啊,因为那样他们就可以即不干活,又挣得多。另外,你给他们自由,你就会发现,他们会只会做他们感兴趣的事,要么聊QQ,要么打游戏,看闲书,反正不干正事。直到你催了,他们才动一动。

Reason 3: 因为前面的原因,所以,我们仍然要把一个PM放在Scrum团队的上面做管理,这样才会有产出。于是,PM给团队分配任何,管得细枝末节,事无巨细,天天让你做进度汇报,等等。直至把团队拖垮。

Reason 4: Scrum 只不过是一个流程。这世上有太多的流程,尤其是那那些操CMMi的公司。几乎所有玩CMMi流程的公司,你都能看到的是员工都是那一副副苦逼的脸。所以,Scrum的流程同样会这样。因为这些都不是开发团队自发出来的,而是上面管你喜欢不喜欢按给你的。 Scrum 根本不可能增进你的软件质量和技术,只能是优秀的人才才可能!使用Scrum的公司都是些吝啬鬼,他们不愿花大钱招优秀的人,他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率,Scrum成了push程序员最有用的工具。

Reason 5: Scrum delivers ‘business value’。不是这样的,实际上,Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队,那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝,花天酒地的,根本不会和你们那些奇怪的东西(如:backlog)或是那堆ugly的内向古怪的技术人员打交道,更别说什么技术了。所以,你的团队就像一个客服团队或救火队一样疲于奔命。

Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好,什么需要改进,并定义行动方案。你真的以为员工想进步吗?让他们不得不去想想自己和团队怎么进步,然后他们还不得不去执行行动方案。别天真了,人的天性是不喜欢改变的,人的天性是习惯于一些按部就般的事的,也许那样做令人讨厌,但是人家还是能干点东西出来。如果你逼着人家改变,你就是在压迫人家,人家自然会反抗。

Reason 7: Product Owner 专注于 ‘what’ 和 ‘why’ 的问题,开发团队决定 ‘how’。很不错的分工,于是可以造就一个即高速有重质量的团队。然而,这根本不行。你的Product Owner马上就想要这个功能,他才不管你的软件开发的技术难题,人家只要快,要你meet deadline,要你给我们重要的客户做出承诺。另外,你千万不要以为你们可以哄走这个初级的product owner,因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰,或者只是外包公司,你觉得可能吗?你觉得建立信任可能吗?

Reason 8: 软件质量和生产率成正比。也就是说,质量越高,生产率越高。如果质量不高,你开发效率就会低下,但是谁管呢?我们朝九晚五的上班,质量好了也是做8小时,质量差了也是做8小时,无所为嘛。另外,我们的 project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以,这根本 不可能。

Reason 9: “是的,如果我们只做需要的功能,那么我们就会最低的成本,对吗?”,为什么这世上总是会有这些幼稚的人?这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格(可能还会有回扣),为了打单子,销售什么都干得出来,让你去做项目是因为你是廉价劳动力,而且,他们会不断地加需求,因为软件合同谈好的价格时候,连需求都没有,你去做了才有,还是模糊和不确定或根本就是错的,然后需求是越来越多,越改越多。等你精疲力尽的时候,你才意识到,销售早就把你卖了。

爽啊,戴着黑礼帽思考问题比我想像中的要有趣得多,现在我必需要把它摘下来了。

看完这篇文章,你觉得是人的问题还是软件开发方法的问题?


 
相关文章

由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
 
相关文档

统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
 
相关课程

IT安全原理、框架与实践
ITIL认证
ITIL Foundation认证培训(ITIL V3 Foundation )
IT规划体系与实践
 
分享到
 
 
     


由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号