写点什么

熊节谈精益在软件开发中的应用

2010 年 12 月 21 日

InfoQ 编辑在 QCon 北京大会期间,就精益的概念在软件开发中的运用和实施等话题采访了 ThoughtWorks 的高级咨询顾问熊节。

InfoQ**:首先很欢迎你接受我们这次的采访。我知道待会儿你会给大家做一个非常精彩的讲座,是关于精益的一些概念在软件开发中的应用。我们知道精益当中有个很经典的概念叫做5S。那么,你觉得5S在软件开发当中应该怎么体现呢?**

熊节:这个去看看工厂里面怎么做 5S,就知道它在软件里面怎么做了,之前你们公司有没有做过 5S 呢?

InfoQ:没有。

熊节:有些公司可能向日本或台湾那边学做 5S。怎么学呢?指派干部部门的秘书小妹妹,每天下班的时候,跑到开发人员那儿去说:“现在要做 5S 了,大家把自己的写字台收干净,东西要规整好哦……”这就是很多软件企业里面 5S 的做法。有用吗?去把人家的书桌收拾好有什么用呢?他工作的场地不在那里,而是在他的电脑里、服务器上、配置库以及代码里面。所以要做 5S,首先要想清楚哪里是你的工作场地。要针对工作场地做 5S。在一个车间里面,地上有油、有土,东西乱七八糟地堆着,就要把这个车间扫干净。那么软件开发的工作场地在哪儿呢?不是在桌上。它在某一个虚拟的地方,在代码库里面。所以要在软件行业做 5S,第一件需要想清楚的事情就是你要针对这个虚拟的工作区做 5S,而不是在实际的工作区做 5S。把这个问题想清楚了以后,其它的问题就迎刃而解了。首先要去看这个虚拟的工作区里,代码库、构建流程、测试、文档……这些东西存在哪些混乱?存在哪些不整洁?针对这些不方便的东西做 5S,才是抓到了这个问题的关键。

InfoQ**:我知道5S里面有一个是叫做修养或是素养单词,主要是说人。那么这个单词,你觉得对于我们一般开发人员来说,意味着什么呢?**

熊节:“5S”,从头开始看。第一个整理(SEIRI),就是把不要的东西扔掉;第二个整顿,就是把需要用的东西整一下,把放得乱七八糟的东西放在方便的地方,随手就能用;第三个清扫,原来不干净的地方把它扫干净;第四清洁,扫干净了以后,从现在开始我们有了一个漂亮的环境,同时从现在开始我们要保持它清洁。那么在这个过程当中做的所有事情,都是对提高员工的素质、素养很有帮助的。这些员工原来是处在一种“如入鲍鱼之肆,久而不闻其臭”环境中。他们觉得这个产品做了十几年,有两千万多行代码,东西难找一点,构建慢一点是必然的。

毕竟是这么大的产品,只能忍一下。于是他们对于其他的东西就没有追求了。但如果对工作环境没有追求,他们对软件的质量也不会有追求的。那么如果通过 5S 的活动把这些事情修正过来。员工原来觉得工作环境就是那样,已经习惯了,突然做了一段时间 5S,比如两个星期或者一个月,把代码库整得干干净净的,各种工具都在手边,很容易拿到……他们的心情就会不一样了——原来我们是可以把事情做好的,是可以把这个软件做得卓越的。那么,工作环境做好以后,员工就会对这个软件中的一些小 BUG、不好的代码、差几个 TIPS 的性能……产生更多的想法了——不行,我不能让这种东西放在这儿,我要去把它做好。这就是员工的素养。如果让他处在一个很糟糕的环境中,他就不会想把这个软件做得很卓越。

InfoQ:我看你待会的讲座当中还会提到湖水跟岩石这样的问题。这是个比较有意思的问题,当湖水比较高的时候,大家都看不到岩石。那么从你的角度来看,我们怎么能在湖水比较高的时候,也能去把那些岩石的问题慢慢识别出来,或者尽早地解决掉呢?

熊节:之所以讲湖水和岩石,就是因为基本上不可能。举个很简单的例子,你走到一个程序员身边,看到他在敲几条命令。假设他要编译、链接、上传到一个服务器、做一下验证,你看他每次都敲这么几条命令。你说:“你烦不烦啊,我们写个脚本吧?你原来可能要敲 5 分钟,还得盯着它。我们写个脚本,一点,它就自己跑出去了。这样你的 5 分钟就省出来了。”“可是省 5 分钟时间有什么意义呢?现在编译一下就要 20 分钟,还是增量编译,如果要全量编译的话要 2 个小时。从 20 分钟里面省 5 分钟对我没意义。”这就是他的湖水。据我观察的现象是,对一个软件来说,编译时间就决定了这个团队的节奏。如果一个软件系统的编译时间要一个小时的话,这个团队对于半个小时时间的浪费是没感觉的。他觉得反正编译一下都要一个小时,这半个小时有什么关系呢,它还在编译,它没编译好呢。

所以如果不把编译的节奏缩短到一定程度,这些细小的浪费在人的心理上是没有意义的,也感觉不到。只有当你想各种办法,把编译并行、优化链接结构,把编译时间缩短到三分钟,这个时候程序员就有感觉了——我三分钟就编译好了,但是我还要五分钟来做这些乱七八糟的事情才能看到结果——于是他受不了了,就会动手去解决这个问题。在没有足够短的编译节奏的情况下,你跟程序员讲:“这是浪费,你要去解决这个,要自动化。”他也许会听你的去做,但是他没有主动的意识。那么你去讲这件事情,会讲得非常辛苦。就像在湖水底下找岩石,做起来非常困难,会费很大的劲。也就是说,最简单的办法就是把湖水降下来,把周期缩短,周期缩短了以后,很多的问题自然而然就会有人去解决了。

InfoQ:那你觉得这个观念是对我们一般的开发人员来说,还是对领导而言?

熊节:对所有人。

InfoQ:那么你又会用什么方法去跟他们解释这样的问题?比如说,你是不是说服了一些中上层的领导?

熊节:这个很难,但相对来说中上层领导反而更容易说服一些。对中上层领导来说,他是能理解交付周期的意义的。一个软件是三个月才能交付一次,还是每一个星期都能达到交付状态,这个对于领导来说非常有意义。知道了这个,他就有更多的信心、胆量去跟他的客户谈或做出承诺:“给我排优先级……你要来参加我的演示……我要跟你讨价还价……”所以跟领导去讲湖水和岩石的问题还比较容易,去和干活的小兵讲湖水和岩石就很难了。

InfoQ:直到他遇到困难了?让他们感觉到这个紧迫性吗?

熊节:对,这种紧迫性,很多时候,特别刚开始的时候——也就是那种不断完善、不断追求这个软件卓越的素养没有形成之前——有时候就是靠领导去压的。必须做这件事情,不要问为什么,反正我们要做。

InfoQ:那么有时候在一开始,从政策上面高压下来,你觉得还是很有效果的,对吗?

熊节:要两方面,一方面领导去压,另一方面领导去压的时候再找个人来唱白脸,在下面给大家宣讲道理和理论。敏捷、精益、丰田生产……很多各种理论。给兄弟们讲讲道理,兄弟们说:“对,道理是这样的!”然后领导拍一个板:“我们就这么干。”兄弟们说:“行,那就挑战一把,就这么干!”

InfoQ:那么换句话说,很多时候实施精益,实施敏捷,还是需要从上往下来压。这可能是中国现在的很多企业比较合适一条途径?

熊节:我觉得这个跟中不中国没关系。这必然是上下一起使力的结果。就是说领导的决心一定是非常重要的。领导有了决心以后,对落实到基层的具体解决问题的支持,是一定要有的。这两方面的合力才能让这个事情朝着好的方向发展。如果领导没有这个决心,一些真正重要的改变就不会发生。如果这种真正重要的改变不发生的话,那么在这些小程序员的手上去做再多的优化,最后对于整个这个交付来说都是没意义的。于是大家就会发现,虽然做了一些优化,学了一些新技术,做了一些改变,自己感觉还不错,但是对于整个交付没意义,到时候该加班还是加班,那么大家就会对这个事情失去信心了。所以说领导的一种决心、一种毅力是非常重要的,这个我觉得跟中不中国是没关系的。

InfoQ:我们都在实施一些精益,包括一些敏捷,你觉得在你跟你客户的合作过程当中,客户常会犯的实施精益方面的一些错误,或者说一些理解上的问题会有哪些,你和我们分享一下好吗?

熊节:这个太多了,我想想看。

InfoQ:举几个大家常见的,可能每个人都会犯的例子。也是对我们软件从业人员的一种警示或者一种忠告吧。

熊节:你想听哪一个级别的,行政管理者的,还是项目管理者的,还是真正做事情的人员的?

InfoQ:说个行政管理者的,再说个开发人员的吧?

熊节:从行政人员的角度来说,最经常出现的一种情况,跟你前面的问题有点关系,就是所谓口头支持。“我们现在要精益,我们要改变我们的交付方式,我们要如何如何……”领导说:“行支持,干,就这么搞,好……”当时你觉得很有信心,然后真正去干的时候,比如,我现在要做持续集成,需要 50 台电脑。领导说:“不行,哪有那么多电脑,搞不了……”我需要几个人来把这个代码优化重构一下,让大家把这个代码库 5S 一下。领导说:“这不行,我们压力太紧,没有人手……”所以我现在经验多一点以后,就学会了看这种领导的脸色,他会上说多支持都没用,最后需要落到实处。我会想一些小办法去测试他,比如说搞个敏捷概要的培训。谁都知道敏捷概要其实没什么用,听完了之后,也学不到什么真正有用的东西。不行!我就要讲,不仅要讲,还要把所有的骨干都拉来听。这样就知道这个领导的支持力度了。他要是连他的骨干开发人员的半天时间都舍不得,那他一定舍不得花工夫做其他的事情,这个时候就会知道有问题了。这是行政管理者经常出的问题——他觉得他很支持,但是真正有问题的时候,要他投资源的时候,其实没那么支持。

然后呢,对于基层的真正在做事的这些人,包括项目经理、开发人员,特别是在原本的层级很明显的那种企业,一个比较大的问题就是他们会觉得这个是领导要做的事情,领导告诉他们怎么做,他们就去实施,很有行动力,指挥什么就做什么。但是这种做法可能搁在某一些特定的环境是可以的。在精益和敏捷的这种企业改善中,这种做法最终是行不通的。他们可以采取一些措施,比如说持续集成、做一些整改,这些措施可以做下去。但是最终,如果这个团队没有形成那种从基层的改善力,没有自己创新、去发现小问题、做小改变的那种行动力的话,这个改善最终是会停在那里的,还会再次腐败下去。当然这是两个方面的事,领导也要去推动这件事情。但对于基层来说,比如你是一个项目经理,带着十几个人,跟着大家一起加班的这样一个角色,当你听到这件事情的时候,你就应该去感觉——这件事情是不是领导真的要做?他是走过场的,还是他真的想有所改变?如果他真的想有所改变的话,这个改变一定是从基层去发起的,你需要做更多的事情来调动起这十几个人的主观能动性,那么这件事情才会不断延续并一直发展下去。

InfoQ:我想今天我们采访就到这里,非常感谢您,很期待你待会儿的演讲。


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2010 年 12 月 21 日 00:002336
用户头像

发布了 114 篇内容, 共 25.7 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

第二周 软件设计原则

WW

ARTS - Week 3

Khirye

ARTS 打卡计划 arts

架构师训练营 - 作业 - 第二周

心在飞

极客大学架构师训练营

week2 学习总结

Geek_2e7dd7

架构师训练营 第二周 作业

一雄

极客大学架构师训练营 作业 第二周

JVM的未来——GraalVM集成入门

孤岛旭日

Java 云原生 JVM GraalVM

命题作业—第二周

于江水

极客大学架构师训练营

Java参数传递分析

游侠最光阴

Java

服务治理之轻量级熔断框架:Resilience4j

CoderJ

架构师训练营 第二周 学习总结

一雄

学习 极客大学架构师训练营 第二周

第二周作业

远方

架构师训练营 第二周 作业

Poplar

程序员的晚餐 | 6 月 15 日 红烧带鱼和清蒸多宝鱼

清远

美食

学习总结—第二周

于江水

架构是训练营

游戏夜读 | 什么是全力以赴?

game1night

用 Explain 命令分析 MySQL 的 SQL 执行

程序员历小冰

MySQL explian

江帅帅:精通 Spring Boot 系列 02

奈学教育

Spring Boot

架构师训练营第二周课后作业一

不谈

极客大学架构师训练营

Spring Aware 你不能不知道的事

CoderLi

Java spring 程序员 源码分析 后端

第02周 开发编程框架 学习总结

Jaye

Class-only Protocols - class or AnyObject

SwiftMic

swift AnyObject

架构师训练营作业-Week2

wyzwlj

极客大学架构师训练营

第二周作业二:描述熟悉的框架,是如何实现依赖倒置原则

远方

架构师训练营第二周课后作业二

不谈

极客大学架构师训练营

第三周作业三:优化 Cache 类的设计

远方

架构师训练营 第二周作业

大丁💸💵💴💶🚀🐟

week2 作业

Geek_2e7dd7

做产品少走弯路:你必须掌握的知识

我是IT民工

产品 互联网 方法论 思维方式 知识体系

第二周作业

胡江涛

极客大学架构师训练营

第二周作业

andy

江帅帅:精通 Spring Boot 系列 02

古月木易

Sprint Boot

低代码的认知误区与落地实践

低代码的认知误区与落地实践

熊节谈精益在软件开发中的应用-InfoQ