敏捷整洁之道--Uncle Bob正本清源

如果你知道Bob大叔,如果你对他的整洁之道有所耳闻,你一定能想象这场直播具有的非凡意义。从2001年敏捷宣言的诞生,到2009年《代码整洁之道》的面世,再到之后的《代码整洁之道:程序员的职业素养》、《整洁结构之道》,今年,刚好整整20年,Bob大叔创作的《敏捷整洁之道:回归本源》构成了“整洁三部曲”,其背后的思想和历程值得每一位希望写出整洁代码的程序员挖掘。

鲍勃大叔《Clean Agile》翻译版《敏捷整洁之道》
您还没有拥有吗?扫描上方二维码
只需一张毛爷爷即可获得由敏捷大咖「申健」「熊节」
亲笔签名的『限量版』图书

另外,还有一点难得的是,这场直播请到的嘉宾正是“整洁三部曲”的译者,时隔十年,齐聚一起,为你解码“Bob大叔”关于整洁代码的核心理念和价值。

观点提要:申健老师以“Bob大叔对敏捷清理门户”这样极具话题性的主题,展开讲解了人们对敏捷的误解,批判了大型伪敏捷,最后给出了敏捷在企业落地的建议。

(这篇回放稿总共接近4万字,在这里小编尽量保证不曲解大咖们的原意,将其主要观点和精华浓缩出来,呈现给大家,希望大家有所收获。)

正本清源:Bob大叔欲对敏捷行业清理门户

分享嘉宾:申健

优普丰敏捷学院首席敏捷教练,自2007年开始敏捷实战。国际Scrum联盟CST认证培训师和CTC认证教练,极限编程实践者。擅长结合教练技术等软技能助力金融、通信、互联网等企业进行敏捷转型咨询和落地。《敏捷整洁之道:正本清源》译者。

主题由来

敏捷这个概念太火了,吸引了方方面面的人进来,传统的咨询行业,一些卖工具的都来了,都打着敏捷的旗号,把这个行业就搞乱了。

所以Uncle Bob在这本书里讲了业务实践、技术实践、团队实践,然后告诉大家我们本来的敏捷是怎么回事,不是你现在卖的那套东西。

对敏捷的误区

对敏捷最大的一个误区——敏捷就是快,用了敏捷以后,原来3个月的项目,我现在一个月就能做出来,那都是不可能的,那都是骗子。

敏捷其实是想要打破原有传统的瀑布式工作方法,以前很多公司的项目开发流程都是先做需求,把需求都搞清楚,再做开发,然后再做测试,然后再做上线。

你会发现这个方式并不适合于软件开发这种智力型的、创造型的行业,早在1970年,这个人叫Winston Royce,他写了一篇文章,批判阶段性Gate based process,说这个方式不适合,结果瀑布模型流传到现在,很多公司,包括我们一些客户的公司仍然还是这样一个开发模式。再加上2000年左右,由于CMMI传入中国,不能说它们没有作用,当时可能是对中国的软件工程行业也起了一些作用,但是逐渐就演化成一种企业资质的一种方式,咨询师跟评估师串通一气,给你刷一个证,最后发现能力完全还是没有提高。

在现实中,人们对敏捷现在还有其它的期望。

第一,我抄。我没有什么创新能力,但是我抄竞品,比比皆是。Uncle Bob说了,敏捷不见得能帮你少花时间,只是能让你该去抄哪,你抄作业得抄对了吧。

第二,少招点人,资源利用率提高点,这也没有错,但敏捷不见得能帮你提高产能,只是能增加一些可管理性,可管理性来自于哪呢?来自于透明性,信息可视化、透明性,然后你才有机会做检视和调整。你如果信息不够透明,你也没有机会检视、调整。

第三,按时上线。按时上线当然也挺重要,但是敏捷不见得能帮你确保时间,它只是摧毁你不切实际的幻想。什么叫不切实际的幻想?就是我到每个时间点,我想要的东西都能上去,不太可能,即使都上去了,通常你也会得到程序员的偷工减料,因为程序员都是高智商人士,他们是非常清楚如何偷工减料,所以你逼他,他就会给你采取那些办法。

第四,营业额。用了之后,我的经营业绩是不是能提升,营业额增加了,客户量也增加了。恐怕不行,敏捷只是能让你更早的知道你哪个产品方向行不通,但是并没有办法让你知道你哪个方向能够行得通。

而且敏捷是一套工作方法,它能够助力你业务功能上线、交付,但是它与营业额、用户量或者钱的增加,并没有直接的关联关系。

最后要讲的一点,不管是极限编程还是Scrum,他们都是一些框架和实践集。但我们很多客户想要落地,要的是敏捷转型或者叫变革管理,这是正交的两回事。在这里先放一句,你要分成两个角度去看,实践集放在那里,但是我们怎么走过去,这是另外一回事。

不管是哪种方法,都是通过一种叫做加速反馈机制来破解复杂性,为什么要敏捷?大家常见的需求经常变更、软件质量差、可维护性差,导致项目失败率。

首先他们讲需求没有不变,因为业务就是在变的,因为市场是在变的,所以不要幻想说我代码能够整整齐齐写干净,然后放在那里供起来,这是不可能的。

第二个就是你的团队、人员、资源能力是一个动态的变化,人员有流动,今天走俩,明天来俩,太正常了。这个敏捷就靠什么呢?就是我们走一步看一步吧,“天下难事必作于易,天下大事必作于细”,你把困难的事拆成简单的,大事拆小,才能够去应对,敏捷里面就能把大的组织拆成小团队,把大的产品需求拆细,拆成用户故事,拆成小任务,把大的时间周期拆成小的、迭代的周期,然后把代码也写的越小越好,都是在破解复杂性,就是反馈机制才是敏捷的根本。

批判大型伪敏捷

市面上有一些方法论,号称叫规模化敏捷,套了一个敏捷的帽子,其实就是原来的瀑布改了名字,仍然是一个传统的矩阵结构,这是一种误区。

还有人说敏捷宣言没区分IT敏捷还是业务敏捷,他就没搞明白,IT敏捷和业务敏捷之间是不是一回事,IT敏捷是干什么的,软件开发敏捷是怎么达到的,是通过屏蔽验证达到的,把代码写清楚,然后通过咱们讲的持续集成、开发迭代,去看跟需求方讲的是不是一样的,是不是人家要的。

业务敏捷是什么?你的诉求是说我的公司能够在市场环境里面增强能力,听起来没错,但是业务方向,战略上其实不一定是通过迭代来进行或者达成的,它可能是通过资源交换来达成,另外它可能是通过广撒网来达成,所谓广撒网就是我孵化好几个业务方向,我看哪个行我就做哪个,像腾讯叫赛马机制。

Martin Fowler当然也是极限编程,和Uncle Bob一样,是极限编程的发起人或者是主要成员之一。他们都在喷SAFe的一个所谓规模化敏捷的东西,包括敏捷宣言其他创始人都对这个东西Say No,说这个东西根本就不是敏捷,套上敏捷的帽子来骗人。

Uncle Bob在《敏捷整洁之道》这本书里讲了一句话,他说敏捷是解决小团队的问题,不是解决大团队的问题,他说大团队、大项目的应对之道,几十年前就已经解决了,怎么解决?咱们讲的矩阵式结构、层级式结构,这就是解决之道。事情分解,已经解决了,但是小团队如何协作的问题没解决,这是提出敏捷的原因。

敏捷在企业的落地

所谓敏捷规模化,在大型产品里面多团队合作、多人合作的时候,解除依赖才是敏捷应对之法。

架构怎么组,不是说我画一个所谓的规模化敏捷图形架构问题就解决了,他一定是靠不断的沟通,跨团队的协调机制,你放一个集中化的架构团队架构师,仍然解决不了这个问题。

剩下还有一些组织的转型、组织障碍的移出、内部社区等等还有自动化测试这事怎么做,都知道自动化测试好,都知道重构好,大型遗留代码,几年甚至十几年留下来的,想补,别说想补重构,补自动化测试,你看都看不懂,人员流动你看都看不懂,你怎么补,所以这也有一个策略的问题。

另外就是绩效考评,这个在企业中是绕不开的,敏捷方法,各个方法都没有提到说应该怎么考评,那我觉得绩效考评根本也不是敏捷要去直接解决的问题,他就是看你公司的导向,你想公司业绩是什么样的或者工作方法像什么,你就考核什么就行了。

另外还有一些配套的事情,包括我们给一些企业做落地转型,发现产品经理能力不行,或者BA需求分析能力不行,就是编程基本功的问题,最后都会落到基本功的问题,你就是不会,你用什么方法论他也做不出来。

程序员的基本功写代码,你知道程序员最头疼的事就是起名字,再加上英语不好,业务领域知识不知道,就只能起到像Run、Process、Handle等等这个水平。Uncle Bob在之前的一本书也提到你要想知道代码质量的好坏,就是数数这个程序员在阅读别人的代码时心里骂了多少次WTF。

怎么练基本功,Uncle Bob提出来极限编程,现在市面上其实也有一些练基本功的培养的方式,包括线上线下的基本功练习,程序员练功房、工具箱练功房等等,Scrum联盟他有一个CST的课程也是在讲这些极限编程手艺,还有一些朋友在做直播,直播就是写代码,直播做重构,直播给你讲集成,这些都是值得大家去参考的一些资源。

另外还有敏捷合同,敏捷合同像Craig Larman等等给出了一些合同的思考和模板,因为你如果像传统像项目管理签的这种合同,时间范围成本都定死了,当不可避免的需求到来的时候,你就没有任何变化的余地,所以敏捷合同签署也是有一定学问的。

最后是教练式的领导力,这个特别有意思,在Clean Agile这本书里面,Uncle Bob除了讲团队实践、基础实践和业务实践之外,特意开了一章讲敏捷教练的事情,我理解他以前这些事情管理的东西其实不是特别在意,但是现在随着敏捷教练行业的兴起,他也提出了一些自己的想法。

我们知道市面上比较流行的敏捷教练的入门学习可能就是美国Scrum联盟CSM培训认证,但是上了这么一个课并不代表你对敏捷有了了解,只是一个入门。再往上就是要真正成为一个敏捷教练要发展自己的软技能,软技能通常指Facilitation会议引导的技巧,还有coaching教练式对话的技巧,包括教练式领导力的技巧才是帮助人们慢慢去转变的一个方式。

总结一下,用Uncle Bob这句话说,敏捷是一种帮助小团队运作小项目的小方法,任何大项目都是由若干小项目组成的。所以以小见大,梦想要大,步子要小,别总扯什么大型敏捷,大型咨询,没有用,先把小团队运作好了,然后慢慢暴露组织中的组织结构问题,互相依赖的问题,去推进整个组织或者更大范围的转变才是正道,上来就想搞一个大型敏捷框架也好,实践也好,往上一套基本上就是输在起跑线上了。

所以我也奉劝行业中的各位敏捷教练,包括我们自己,一起共勉。还是先把小团队的敏捷之道搞好,如果丢了代码年头太多,想法拾起来,如果没有任何代码基础,给别人做敏捷咨询的话,最好先学学潘石屹,了解一下程序员的工作情况才能更好的理解敏捷到底是怎么一回事。

Clean三部曲更多直播内容记录

https://mp.weixin.qq.com/s/7z-xlQmuZd_snw7dP_Utxg


觉得本文有帮助,长按二维码进行微信打赏