第1章 软件工厂
1.1 软件的生产力
软件行业的发展至今不足百年的时间,相比传统行业尤其是工业,成熟度还不算高,软件工程的学者和从业人员一直在摸索成熟的行业解决方案,从早年的软件质量工程、CMMI到2018年流行的敏捷、精益等方法,无不在尝试解决软件行业的诸多痛点,但是效果不是非常理想,印证了Fred Brooks所说的“没有银弹”。
“没有银弹”是Fred Brooks在1987年发表的一篇关于软件工程的经典论文。该论文强调真正的银弹并不存在,而所谓的没有银弹则是指没有任何一项技术或方法可以让软件工程的生产力在10年内提高10倍。
Brooks的理念触碰到了软件行业的本质问题之一:软件工程的生产力。
生产力是衡量某行业发展水平的重要指标,反观当今软件行业的发展水平,生产力低下,手工作坊模式的生产过程,例如,某移动运营商客户的BOSS系统因为规模庞大、业务复杂、业务流程关联性强、业务步骤多,致使新需求无法快速、高效、准确地得到满足,往往一个需求需要经过2~3个月的开发才能上线。加之软件行业衍生的所谓“外包行业”,价格无序竞争及管理混乱导致的质量“逆向选择”,致使当今国内的软件生产力水平极端低下。
生产力的三要素是劳动力、劳动工具、劳动对象,其中劳动力是最活跃的因素,劳动工具的变化即代表技术进步的快慢。
以银行软件外包行业的现状来看劳动力,我们认为,人员(劳动力)这个最活跃的因素并未被有效激活。某银行外包开发测试,通常采用招投标并派驻人员的方式进行,在国内缺乏行会结构的商业模式下,价格无序竞争,导致供应商以低于成本价的方式取得订单,以被迫提供低于软件生产质量水平要求的方式提供人力。而派驻到甲方场所的劳动力,在甲方不成熟的软件生产过程管理下,无法高效发挥生产力,缺乏归属感。甲方原本就不是专业的软件生产商,只能提供笨拙的生产管理规范和约束,加之生产场所往往处于租金昂贵的CBD,大规模生产软件所需的劳动力只能处于拥挤不堪的工作状态。《人件》里所提倡的得到高效项目团队的条件——管理人力资源、创建健康的办公环境、雇用并留用正确的人、高效团队形成、改造企业文化和快乐工作等就无从谈起。
思考和管理软件开发的最大问题是人(而不是技术),得到高效的项目和团队是软件行业必须考虑的问题。我们倡导软件行业要摒弃软件作坊的工作方式,转向成熟的工厂生产模式,目的是解放劳动力,在专业化、标准化的流水线上,才能有效地释放劳动者的生产力。
不可否认,软件生产与传统工业生产很大的一个区别在于,软件生产相当大的一部分劳动属于脑力劳动,如何激发脑力劳动者的积极性,让他们能在更舒适、更轻松的环境下工作,是必须考虑的问题之一。
我们认为,从根本上提升软件生产力,提高软件制作水平的方式是:软件工厂。
只有在软件工厂的规模化、大批量的软件生产过程中,才能提炼和总结各生产要素,以及生产要素的最佳实践。做一个简单的比喻就是:村里成立了一个纳鞋工作坊,把能纳鞋的老老少少都召集在一起,顶多能比比谁纳鞋快、谁纳鞋好,并不能从根本上提升鞋的工艺水平,更不要提促进鞋业生产力水平了。
1.2 软件工厂——软件的标准化生产
最近在与某移动运营商的一位领导交流时,我得到一些启发。他认为IT领域之所以没有出现垄断性的软件生产商,根本原因是缺乏标准。通信运营商领域是从 CT 领域发展起来的,CT领域是高度标准化的领域,国际行业标准非常完善,任何一家有志于进入CT 领域的设备生产商,只要生产的东西满足 CT 行业规范标准,就能参与竞争,而 IT领域并没有这样的标准化生产模式。因此IT领域要健康有效地发展下去必须IT CT化,必然需要像 CT 领域一样有一个统一的信息化体系标准,软件生产制作在整体信息化标准体系指导下进行,所有进入的厂商都按标准做事,集成容易,配合简单,最终实现业务能力完全开放,快速整合投入运营。
信息化体系标准,即IT系统采用CT化思路建设,将整个IT架构、IT基础设施视为一个整体,先考虑端到端,再界定其中的单元部分,以及每部分的功能、地位、与其他单元的关联性,每个单元可以按照生态域的逻辑进行工作,每个生态位必须满足两个基本条件:
(1)每个生态位单元都是一个开放领域,都可以满足标准自由竞争,让最强者生存。
(2)能满足可替换性。
只要满足以上两个基本条件,就能实现信息化系统快速整合上线,实现能力完全开放(对内、对外、对入口)。
1.2.1 标准化生产模式需要一个集成底座——PaaS
在上述理论指导下,标准化生产模式得以实现,我们可以借助流行的PaaS平台来提供生产要素集成的底座。具体来说,就是PaaS平台要实现什么目标?我们的PaaS平台将来一定是一个应用的生态平台,为了让应用生态更好地衔接,底层应包括以下关键性要求。
(1)与外界资源的交换、通信,包括对外的能力API。
(2)内部支撑所有应用需要的功能,这些功能会以稳定的API层存在,成为移动业务所有应用标准化的基础,比如RESTFUL、OSLC、LinkedData。
(3)数据层是一系列数据容器,支撑移动业务所有的数据。数据容器必须是抽象的结构,和底层数据库无关。
1.与外界的交互设计
与外界的资源交换、交互通信必须采用统一的 API,这种信息交换方式类似于细胞膜的物质交换方式。对于外界来说,内部是一个封闭的未知领域,不管内部怎么变化、怎么更改,通过API调用就能得到想要的结果。
例如,当你需要一个地图查找功能时,一般来说是实现一个地图应用,如高德地图、百度地图等,但如果这个地图应用出现问题就找不到需要的结果。如果PaaS通过API形成统一的对外能力(地图能力),那么业务系统只需要调用地图API。至于内部是使用高德地图、百度地图还是别的地图,都没有关系,不固定,可随时切换。对外能力 API 固定下来了,与外部的所有交换都是透明的,用户可以随时获取自己想要的结果。
2.数据容器设计
PaaS平台管理的数据必须是非数据库方式存储的,必须是面向实体的。
采用RDF框架进行业务实体的序列化(Data Serialization),当把内存对象从一个地方传输到另一个地方时,中间必然存在一种形式,比如文本,把一个对象变成半结构化的文本,这个过程就是序列化过程。实体的序列化包括了一系列对象的序列化,账户、用户、客户等都是对象,对象要序列化,数据容器的存储基础应该是对象的序列化,而不是现在的关系型数据库。数据存储最终要采用混搭的结构(如SQL+NoSQL),实现混搭模式的关键是序列化。
这样改造之后,PaaS管理的数据层就变成了一系列数据容器,数据容器都变成微服务结构,必须满足 OSLC、LinkedData、序列化等标准,这样数据和应用就可以随时像Docker封装好的集装箱一样移动。
3.能力开放设计
能力开放不仅指对内的能力开放,还包括对外(合作伙伴)的能力开放,争夺生态入口的能力开放。具体设计需要从以下三个角度考虑。
(1)通过构建应用生态中稳定的“冻土层”,以 API 层的形式存在,支撑所有信息化建设和业务应用的快速功能整合开发、上线。
(2)以可插拔的架构设计模式对外暴露生态位,合作伙伴可随时竞争生态位,可随时替换,可随时部署上线运营。
(3)通过标准化的IT流程管控设计、成本模型设计、结构化的架构设计,形成开放的移动运营商IT CT化管理、建设、运营能力,在C端或B端的入口争夺中(如园区生态圈、金融生态圈等)应用强有力的IT CT化开放能力。
1.2.2 标准化软件生产流水线
衡量社会生产力水平发展的主要标志是生产工具。
马克思主义认为,生产力发展的主要标志是生产工具的发展和变革,生产力的发展水平如何主要体现在生产工具的水平上。社会发展的各个阶段就是以生产工具的发展水平来划分的。
软件行业处于发展的初级阶段,从生产工具的发展水平就可以看出来。
高阶的软件制作方式应该是将业务需求和设计作为生产流水线的原材料输入,生产线先自动产生所需软件,然后部署上线投产使用。
而现在的软件生产模式是:软件需求无法精确表达、设计与代码脱节无法直接映射,缺乏高级的生产工具,依赖人工编程的方式进行软件生产,这样必然导致软件生产严重依赖程序员的“创造性智力劳动”,以及程序员的工艺水平。
由于软件制作过程高度依赖人,而人又是容易出错的,所以我们会看到程序员辛辛苦苦、信心满满地编码出来的产品,传递给大量的测试人员进行大规模测试后,却发现大批量的“缺陷”,返工成本居高不下。更要命的是,测试人员也是人,测试人员也会出错,无法覆盖大规模复杂应用的所有代码执行路径,从而导致这些“缺陷”交付给最终客户和用户,在上线之后才被发现。
高级的生产力水平应该是依赖高水平的生产工具的,但反观我们现在的软件制作过程,工具应用得好的少之又少,我们尝试分析了一下原因。
首先,不擅长生产软件的甲方不务正业地拉扯几个人凑成一个所谓的软件研发部门,采用大量的外包方式,找了一批价格低廉的外包劳动力,在不管开发商采用何种方式、何种技术、何种工具的情况下,吭哧吭哧地雕琢起所谓的“业务支撑系统”来,发现问题了再改造、升级。可想而知,在这种软件生产模式下,没有人会考虑如何利用工具,也没有人会考虑如何改造和提升生产工具的水平。
其次,工具的价格与价值认可问题。有些专业的工具生产厂商,如 IBM、HP 等,在某些领域做出了比较专业的生产工具,但是这些生产工具通常价格高昂,甲方要么没钱采购;要么觉得软件生产者已经转为外包供应商,他们自然应该自带工具提供服务,结果是,外包供应商能满足合同要求就不错了,还要增加生产工具成本,自然不乐意;要么采购之后束之高阁,因为某些工具是用来规范约束开发商的开发行为的,开发商存在抵触心理,工具自然不会被用起来,有些工具是需要专业技术人员操作的,而无序低价竞争下所提供的劳动力是无法及时有效掌握这些技术的,加之劳动者流动率高,工具应用形成最佳实践的机会不大。
从本质上来看,是小规模作坊生产软件的模式导致对工具应用的需求不大。只有流水线作业的工厂,才会对工具应用带来的效率提升、生产力提高有迫切需求。