Scrum对于老板的价值何在?

作者:张书迪

这篇文章是写给致力于推广Scrum的项目经理们的,我的很多客户都问过我这样的问题:他们用了Scrum一段时间了,发Scrum确实是个好东西,能够有效的提高团队的生产力,鼓舞团队士气,降低外界对团队的干扰,以及卜啦卜啦卜啦一大堆的好处,但是老板们,尤其是那些非软件开发出身的老板们,却对Scrum仍然无动于衷,得不到老板的支持,推行Scrum举步维艰,想要说服老板,却又不知道如何去打动他们,Scrum中也丝毫没有说老板们在Scrum中能获得啥东西,那么Scrum对于老板的意义到底何在呢?

想回答这个问题,要先看看Scrum到底解决了软件开发中的什么问题?项目经理们最常见的问题就是进度、质量、成本,不过说实话,Scrum没有良好的解决任何一个问题。

所有搞过软件的人都知道,软件延期的本质是人类大脑对于复杂问题(如一个软件)的预测能力有限导致的,软件是复杂的,正如Ken Schwaber所说,世界上最后一个简单的软件还是上个世纪40年代的事情了, Scrum自己也说它和其他任何软件方法一样,不是银弹,不能解决延期问题,它只能良好的预测即将发生的延期而已。

软件开发的成本基本上就是研发人员的工资,如果进度问题没有解决的话,成本问题也就无从谈起了。

质量问题做敏捷的朋友们都知道确实是有很良好的改善,不过有多少是Scrum的功劳呢?TDD、自动化测试、持续集成、结对编程等等都不是Scrum的实践,大概Scrum中对于质量的控制就是一个评审会了吧,不过说实话,我见过很多团队也使用Scrum,但是同样也做出了质量相当悲催的软件。

然而项目经理们天天向老板们汇报的进度质量成本问题真的是他们所关心的吗?我看不见得,老板开公司的目的不是想得到一个优秀的进度质量成本报告,他们开公司的目的是要赚钱的,要赚钱就要先投钱,然后产出价值,产出高于投入,就赚到钱了,否则就赔钱,这是最基本的商业运作原则,软件公司也不例外。软件开发是一个商业运作的过程,是投资者投入资本让研发团队创造价值的过程,对于投资者来说,神马编码技术,神马管理方法的,都是浮云,只有投入产出比,才是他们最关心的,他们期望投入的每一分钱,都能够产出更多的价值。

Scrum所能够解决的,也正是这个投入产出比的问题。

Scrum要求每一个Sprint结束后,都要获得一个可工作的软件,为什么要求是可工作的软件,而不是一份设计文档或是一批代码?那是因为只有可工作的软件才能为公司创造最高的价值,任何中间过程文档或产物几乎无法为投资者创造任何价值。就像敏捷宣言中所说,可工作的软件胜过复杂的文档,这句话实际上是警告开发团队的,同学们,别看你们已经搞了好几千页的文档,写了多少万行的代码,这些都是浮云,没有一个能拿出去卖钱的,所以当项目经理拿着精心编写的设计文档去见老板的时候,向来都是得不到什么好脸色的。不论是谁,投了几个月的辛苦钱以后,都不想看到一些根本卖不掉的东西。要求必须产出可工作的软件,恐怕只有敏捷开发才会有这样的要求,其他的什么瀑布模型,原型法,RUP抑或是曾经炒的很热的CMMI,都统统忘记了这一商业运作的基本要求。

Scrum要求对Product Backlog按照价值进行严格的排序,必须从排序最高的Story开始做起,为什么?因为一个叫做20/80的理论告诉我们,20%的功能可以创造出80%的商业价值,而在软件界的实际情况是:7%的功能就能够创造出80%的商业价值!以上数据是源自于一个对软件功能使用情况的调查,一个权威调查公司调查了市面上上百款商业软件,发现只有7%的功能是大家经常使用的,15%左右的功能是偶尔使用的,33%的功能是基本不用的,而有45%的功能是从来没有被用到的!我相信公司老板们看到了这个数据后一定悔的肠子都清了,好家伙,45%的钱被完全浪费了,33%的钱扔在了大家基本不需要的东西上,只有区区7%的钱投在了正确的地方,这种资产利用率,恐怕要让所有的董事会大发雷霆的,不过这就是软件行业的现状,发展了60年后的现状。

老板是理性的,创造出完美的软件来满足客户的全部需求并不是他们的目标,而软件工程领域的诸多方法,都是在告诉大家如何做出一款完美的软件,程序员们也被教育成了完美主义者,公司老板与开发者之间不可调和的矛盾也由此而产生。Scrum教育大家不要追求完美,而是要在有限的资源里提供最大的客户价值,这一点与老总们的商业目标不谋而合,这也使得Scrum成为了欧美软件公司接受度最高的研发管理方法。

商人们常说一句话:时间就是金钱!商场如战场,战场上也有一句话:兵贵神速。可见速度与效率,是商场上克敌制胜的法宝,Scrum也正突出这个“快”字,Scrum将软件的交付周期由瀑布时代的数年,迭代开发时代的半年缩短到了一周到一个月,交付周期短了,应对市场变化的能力也就提高了,而Scrum对于变更的管理更是在相应变化能力与持续交付能力之间获得了一个良好的平衡点,在客户的需求变化由于女人的心情的时代里,Scrum比其他任何方法都提供了更好的持续交付能力与相应变化的能力,这正是公司老板们梦寐以求的能力,是他们通往睡觉睡到自然醒,数钱数到手抽筋的最佳途径!

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/yock_zhang/archive/2011/01/30/6169483.aspx

原帖地址:http://community.techexcel.com.cn/010DevSuite/news/955ScrumtoBoss

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结