安利一篇文章,说明SCRUM为什么永远不会起作用。需强调,如作者开篇解释的,作者本身是SCRUM坚定实践者,信仰敏捷。本文的目的,是基于as negative as possible情况下,总结SCRUM失效的原因,纯理论推导的结果。这种方法类似《思考,快与慢》提到的事前验尸法,先假设会失败,然后推因,最可能是什么原因造成的?其实企业跟人一样,表象各有不同,但归根到底就那么几个根因,死活无法改变。因此其总结的失败原因,极具参考价值。特别在传统企业,习惯瀑布式方法论,组织层级冗余,弱矩阵结构,对于实施敏捷的阻力,深有感触。举个例子,最近在做的项目,业务方反对敏捷实施。理由一业务是全链条关联的,不能先上一部分再上一部分;二是项目不着急,没必要采用这种大家都不熟悉的方法;三是认为会牺牲质量,先上的功能没有得到充分的调研、测试。蓝图阶段,只有做全范围内的调研与方案,才能保证各个功能模块的质量。其实说到底,还是业务敏捷跟不上。这很难改善,因为人不会变化。干系人拒绝不确定性,抵制透明。让一帮传统企业的大叔陪你玩敏捷?
Anyway,原文链接如下。
https://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/
原文翻译如下:
因为本文标题具有争议性,我需先做下解释:本文所写仅是个人观点,无关我的雇主,如果以后我还有雇主的话。。。此外,我本人是SCRUM和其他敏捷方法的忠实粉丝,毕竟我是从中受益的。最后再强调下,我百分百确信SCRUM适用于软件开发。
我真的喜欢SCRUM,并在过去5年中一直使用。我在多次会议中做了SCRUM的报告,并写了一篇相关文献。敏捷宣言距今已十年,我认为可以采用 Edward de Bono‘s black hat方法来分析SCRUM失效的原因。
原因1:
SCRUM的基础是相信他人。创造一个安全的环境,保证我们彼此开放,从错误中学习。但这很难实现。许多领导是容易炸毛的(我的领导不是,他是个nice guy)。职场上存在许多alpha雄性领导者,对你、过程、你的成长毫无兴趣。开放只会伤害你的职业生涯。不会有机会让你去犯错、去接受风险。
原因2:
SCRUM原则“给予足够的自由度才能发挥人最大的价值”,是站不住的。公司给予最小的自由度因为软件开发者通常所得报酬是过低的,特别与他们的领导相比。这也是他们想成为管理层或架构师的原因,可以愉快的摸鱼并获得更高的奖金。
原因3:
基于上一个原因,我们仍需要在SCRUM团队上加一层项目管理,来保证最小量的输出。所以管理上可能不会变化,分配任务给组员,适度管理开发人员,要求做进度汇报等项目工作。所有这些管理工作会使团队效率变慢。
原因4:
SCRUM只是一个方法论。我已见过许多失败的方法论,留下一地困惑的people。如果你已陷入到一个传统、不理解敏捷的组织中,很难发生任何改变。SCRUM不会改善你的软件,这取决于人。环顾四周,你的开发者都是average joe(张三李四普通人),因为钱就那么点。
原因5:
SCRUM并不会实现商业价值。熟悉业务的同事不愿参与到你的项目中。他们更愿意与客户打交道,而不是一帮码农,花额外时间了解纯IT的概念。所以团队只能选择初级业务人员作为PO。另外,ICT部门本身就是成本中心,何谈商业价值?
原因6:
敏捷团队应该持续改进,这也是SCRUM中回顾会议的意义。哪些做的好,哪些待改进。但人们真的愿意去改进吗?这需要提出可能的改进措施。然后可能就会由提出者去执行了,这往往意味着出离舒适圈。人们害怕变化,因而拒绝改进。旧的习惯也许有问题,但起码能用,能维持。
原因7:
PO聚焦what及why,开发团队决定how。如此分离的目的是团队聚焦质量并保证长期高效。但实际并非如此,PO关注功能的时效性,而不是软件质量。出于对关键顾客或其他相关方的承诺,PO在意的是在deadline之前完成特性。不要以为团队可以压过这位初级业务PO,他背后往往站着高层级业务领导。而作为开发人员,成本中心的一份子,你只是可随时被外包替换的资源,如何谈激励与信任?
原因8:
上一个原因有关质量。追求进度会拉低软件质量。另一方面,当关注质量时,生产力会提高。但average joe开发人员并不关心质量啊。质量差,开发会多花些功夫,但谁会关心?项目经理或者SM,会怪罪于不完善的项目计划。并不会因为采用SCRUM,生产力受到更多重视。
原因9:
“但如果我们只构建必要特性,至少我们控制了最低总成本。”这是一个天真的想法。你并没有构建必要的特性。很多时候签订的是固定总价合同,或者政府的包干合同。你被选择是因为价低者得,甲方会确保你的交付物满足了事前约定的要求。而这其中至少有一半的需求,并没有商业价值。你是无法糊弄甲方项目经理的,他是位alpha职场人,保证你会交付所有的特性:(