你需要一条怎样的牛仔裤?

0
238

1853年,美国加利福尼亚州发现金矿,人们从世界各地涌向这里,一时形成淘金热。一位做纺织品生意的犹太青年商人列维·司特斯(Levi strauss)灵机一动,将滞销帆布制成几百条裤子到淘金工地推销,意想不到大受欢迎。这就是全世界最受欢迎的牛仔裤品牌Levis。

去挖金矿的人是否都找到了金子我不知道,但Levi因为牛仔裤大赚了一笔是事实,不然也就没有现在Levis品牌了。

经常有人问我到底是做什么的,我说是软件工程,然后的对话就是:那我有个APP你能帮我开发吗?后面的对话就是各种不同频率的无法共振~~~。后来我就开始用这个“牛仔裤”的故事来解释,总算是可以少费点口舌了。说软件工程买卖仔裤的,还真是挺准确的,这是wiki上对Engineering这个词的定义:

Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, and processes.

https://en.wikipedia.org/wiki/Engineering

软件工程(Software Engineering)解决的是如何做好软件开发(Software Development)的问题,使用来自于科学,经济学,社会学以及日常中总结的各种方法,经验来帮助软件开发团队做好软件。说得好玄乎~~~实话实说,我也是今天才仔细琢磨了一下这个定义,翻译过来好高大上。不过话说回来,琢磨一下自己干的事儿,这些玩意还真都用得上。

好吧,我们先来看看到底什么是软件开发。

软件开发的本质

软件开发不就是把软件做出来么?这有什么可解释的?那我们比较一下同样是把一件东西做出来,软件开发和制造一辆汽车的过程有什么不同么?

最大的不同就是汽车下线以后是不能再回炉的,而软件是要经过多次回炉才能出厂的。没有哪个4S店允许你把车子送回厂家换个椅子啥的吧?可是你手机上的APP可是隔三差五在更新,每次更新可都是在“厂子”里从新过了一遍生产线的结果。如果你注意一下你用的app的版本,就算是你拿到的第一个版本,版本号也绝不是1.0;这意味着这个APP已经回炉了不知道多少遍了。

一个汽车工厂里面积最大的部分应该就是生产线了,在这个生产线上要完成所有零件的组装。如果按照这个思路去看软件开发,那么所谓的生产线就是“编译打包”或者说“持续集成”过程。你一定要问,为啥不是写代码的过程?因为在代码写出来之前,软件都处于设计过程,“零件”还没成型啊!你想想,上了生产线的汽车零件还允许工人现场打磨一下,修改一下尺寸吗?如果是这样,这个车你敢买吗?但软件的生产过程中的大部分时间,以及基本上所有参与者(包括写代码的程序员)都在进行设计工作,都是设计师,而不是工人,真正完成装配过程的“工人”是编译器,CI系统等已经高度自动化的程序。

这就是为什么管理程序员不能像管理工人一样,因为你需要他们去创造,而不是拿着做好的东西进行装配。同时,软件开发的本质也就决定了用管理工厂的思路来管理软件开发是行不通的,这也就是为什么用“瀑布”模式来管理开发过程会很别扭。

那么如何做好软件开发?那就是本文的重点,你需要一条怎样的牛仔裤?

软件工程的本质

先讲一个关于电厂的故事,这个故事来自于
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd

记得有个给我们上培训课的主讲老师是个须发皆白的老先生,进门后掏出一堆零件放在讲台上, 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水,点燃酒精灯,不一会儿水开了,从壶嘴里喷出了蒸汽,带动叶片旋转,然后小灯泡就亮了。
他说:这就是电厂。
他还说:如果烧的是煤炭,这就是燃煤电厂;如果烧的天然气,这就是燃气电厂;
如果获得热能的方式是核裂变,这就是核电厂;如果带动叶片的能量来自水从高处流向低处,这就是水电厂。
老先生说:你们或许会问 “那我们看到的电厂怎么这么复杂”,答案其实很简单, 电力项目需要复杂系统的目的,一是为了确保安全(Safety),二是为了提高效率(Efficiency)。

安全和效率就是工程技术的本质,在软件工程中,我们对“安全”的理解会更加宽泛,可以换做“质量”。

既然开发过程的大部分处于“设计”阶段,那么也就意味着在上生产线进行装配(编译打包)之前,软件一直处于不确定状态,因此传统的确定需求,完成设计,确保100%按照设计执行的思路是行不通的。我们必须找到适合软件开发的工程技术,这才出现了敏捷开发,极限编程,Scrum,Kanban等等;这些方法的本质都是要构建一个高度自适应的系统,以便适应这个不确定状态,所以软件开发中的效率问题的解决不是传统的标准化流程的思路,而是不停变化的思路,乍听上去会觉得一个不停变化的系统怎么会效率高呢?当然,最高效的系统一定是步调一致,统一执行的。软件开发系统其实也是这样,只是这个系统从一个高效状态到另外一个高效状态的转换是非常快的,可以说是在随时变化的。

解决了效率问题,我们来看看质量。什么是质量?我们再来讲一个故事:

一位老者去理发店剪头发,第一次去的时候理发店的店员非常热情,端茶送水,帮老者洗头,剪发,吹干,然后毕恭毕敬的送老者出门,收了30元的费用。老者很满意,过了1个月又去了这家理发店,这次店员没有迎来送往,只是剪了头发,也收了30元费用。老者虽然心里不高兴,但是头发是剪了,也算是OK了。又过了1个月,老者又去理发,这次店员再次笑脸相迎,全套服务,老者很高兴地走了。再过了1个月,老者又去,这次老者对着店员提了一个问题:我这30元到底买到的是什么服务?

我们再来举个例子:全世界质量最好的汽车是丰田汽车,但你知道为啥是丰田汽车吗?那是因为如果你买了一辆质保3年10万公里的丰田汽车,在第4年/11万公里的时候它出现问题的几率比其他厂商的品牌要高!对你没听错,要高!

结合这2个例子,你应该会理解质量到底是什么了?虽然作为消费者,你会觉得这个丰田车质量定义有点无法接受,但是高质量永远不是在造万年船,永远是在一定范围内定义的标准,而高质量就意味着偏差小。

软件开发中,制定标准并持续的检查偏差就是保证质量的思路,这里面有很多方法,如:持续集成,测试驱动开发,编码规范,完成规范,流程规范;甚至包括自动化部署,云计算环境的使用等都和质量相关。但是要提高质量,则在标准和检查的基础上还需要“持续改进”。有人问,测试那里去了,测试不是提高质量的方法吗?其实测试只解决了“检查偏差”的问题,要提高质量,以上3个要素缺一不可。

还有一些如微服务架构,SOA,可测试性,可部署性的软件架构思路也都和效率和质量相关。

一直想写一篇关于软件工程的文章,可惜总是没有提笔。昨天看了博客园的另外一位朋友的文章,觉得还是应该写一写,就算是一点感悟分享给大家。

这位朋友的文章链接在这里,推荐给大家
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd


更新 2015-12-20:
以下是本文发布到博客园以后一位网友的2条回复

没太明白质量的那两个例子。请教一下理发的例子是啥意思?另外关于丰田汽车的质量问题,在我看来这并不是质量高的表现啊。我所理解的质保期应该只是顾客期望的一部分,比如我买一个东西,质保期是2年,但这个东西我可能会期望用5年甚至8年、10年。只是在头两年里我的期望更高,我希望它不要出问题或很少很少出问题。因为就算你能够免费质保,我还嫌每次联系克服很烦呢。但是过了质保期之后,顾客的期望肯定不会突然变成0,实际上顾客通常仍然会有较高的期望,只是期望值会随着时间逐渐递减。所以过了质保期就容易出问题的产品肯定不是好产品,而你却说好的产品应该这样,这一点我很难理解和认同。我觉得这样的做法是在钻法律和道德的…

`虽然作为消费者,你会觉得这个丰田车质量定义有点无法接受,但是高质量永远不是在造万年船,永远是在一定范围内定义的标准,而高质量就意味着偏差小。`这个就更难认同了!产品是什么?你这么说的时候又把用户摆在了什么位置呢?偏差小如果是指技术精度还可以理解,但这里你显然指的是另外一层意思。往小了说,我觉得你这篇文章观点不正;往大了说,我认为你的价值观有点问题!

以下是我的答复:

首先理发那个例子,只需要反过来考虑:如果老者第一次去理发的时候店家只提供了剪发服务,收取30元钱。那么后续的麻烦估计就都省去了。老者不高兴的原因,不是在乎多了一杯水,而是忽有忽无的水,这样他无法预期得到的服务。
另外,就是那30元很重要,其实这定义了可以获得服务的多少;用更少的钱获得更多的服务,和用有限的服务获取更多的钱--永远是消费者和提供者的博弈。一旦双方发生了真实交易,其实就定义了“质量”。

回到丰田车的问题,签订购车合同时所确定的条款实际就是限定了一定成本所提供的服务内容,这就是质量的定义。

不要混淆了”机率高“和”一定出问题“的概念,概率高不等于一定出现。

最后,谈”质量“不能只从消费者的角度出发,应该把提供者和消费者放到同等的地位考虑。

这些都是我的个人感悟,没有对错,开放讨论;关于正斜的问题,站在地上看坡上是斜的,反之亦然~~~大家都是习惯站在自己角度考虑问题,能跳出来,不容易。

以下是Wiki上对质量(Quality)的定义:

In business, engineering and manufacturing, quality has a pragmatic interpretation as the non-inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly.

https://en.wikipedia.org/wiki/Quality_(business)

另外,找到的一些关于质量的定义,我觉得这个可能更多的指向软件行业

In an information technology product or service, quality is sometimes defined as “meeting the requirements of the customer.” The term quality assurance describes any systematic process for ensuring quality during the successive steps in developing a product or service. ISO 9000 is a standard for ensuring that a company’s quality assurance system follows best industry practices.

http://www.businessdictionary.com/definition/quality.html

看上去,在我之前的故事和解释中弱化了满足需求(meet requirement)这个前提条件,也就是说在满足需求的前提下制定标准,检查标准并持续改进就是质量管理的3个核心,这样可能就相对全面了。需求和标准之间一定是有联系的,需求直接做为标准的一部分,再叠加上用户没有明确提出但我们仍然需要满足的,应该可以涵盖所有质量的标准。不过,这里面最大的问题是:如何搞清楚用户的需求,用户是否很明确的知道自己的需求,又是否能够准确的描述/传递这些需求给到提供者。

我仍然觉得控制用户的需求比花精力搞清楚他们的需求更容易做到(也更现实),做为用户也更容易接受;这就好像你去餐馆吃饭,首先会拿到菜单,而不是服务员直接问你:“想吃啥?我们啥都能做!”。如果有服务员这样问我,那我一定会琢磨半天,回答她:“随便!”。我估计这是每个人最痛恨的2个字,至少我最怕人家这样回答我 … … 不过话说回来,我们在和用户谈需求的时候,得到答案比这个“随便”又能强到那里去呢?


 

 

请关注微信公众号 devopshub,获取更多关于DevOps研发运维一体化的信息

qrcode_for_gh_b7c158df1fd1_430

- leansoftx.com -