扫码阅读
手机扫码阅读

聊聊没有35岁焦虑的《人月神话》

92 2024-01-12

这是鼎叔的第十五篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。


这篇展开聊聊畅销40多年的《人月神话》中的核心观点和个人启发。

软件工程效能到底有没有银弹?

神话中,银弹就是可以让强大的狼人被一击毙命的武器。

这里的银弹,指的是一招制敌,提高数量级的效能水平,而不只是效能有明显改观。

这个话题在业界激烈讨论了几十年,普遍倾向的结论就是--没有!

可以逐步改进,但不能成十倍的改进。

换句话说,如果有某个效能专家,说他的方案可以让你的研发团队取得脱胎换骨的成果,基本上就是个忽悠了。

下面来逐步剖析原因。

软工工程的固有难度

系统级软件产品和单一任务不同,和硬件产品也不同。

写一段可工作代码很容易,做一个编程产品,就困难了好几倍,因为你要定义接口,处理输入的范围,需要让人可理解的编程风格和设计文档,最后要进行彻底的测试。

从一个软件产品到一个系统产品,复杂度又提高了几倍。因为你要考虑可以和它交互的各种程序的集合,还要考虑接口规范和响应性能,还有系统资源的资源限制,比如内存,IO,硬件兼容性。对应的系统测试时间更是成倍增加。

“人月”的概念误导

项目经理最喜欢做的报表,充斥着“人月”- Man-Month的统计指标,咋一看很容易让老板理解项目需要的资源,以及当前的进度还差多少。

技术人员在估算方面往往便乐观,项目方也不会给足够的时间矫正估算,当意识到进度偏差时,关键矛盾就出现了-

从外部增加人手,可以追赶上进度么?

从项目的真实数据统计来看,不行。就算进度最终追上了,付出的Man-Month远远超过预估的资源缺口。

疲于奔命的大型软件项目,就像一个焦油坑,项目经理投入的工程师越多,在坑里挣扎得越厉害,无力自拔,于事无补。

究其原因为何?

“人”和“月”不是一个可以互换的概念,除非人和人完全不需要进行交流。大多数任务都不是可以并行的,人们直接协作交流的成本和人数的平方成正比。另外,新人加入项目需要一定的培训时间。

软件产品因为有激烈的时效竞争,不太接受过慢的交付周期。而向进度落后的项目额增加人手,只会使进度更加落后。悖论在此。

项目的进度偏差也不是一下子出现的,它来自于每一天的滞后,或者对其他人员进度的不信任。

一线经理出于利益本能,不愿意让老板看到计划的偏离,而是尝试独立解决问题。

正确的做法建议是:老板应该减少发号施令的压迫感,把行为控制在“状态检查”和“问题行动“层面,也许就可以顺利地拉开(藏着污垢的)地毯


高效的开发团队

就像一个外科手术团队,主刀医生(首席程序员/架构师)为主角,他专注于系统的思考设计,和成员的协调一致。其他的专业角色各司其职,彼此的交流简单直接,尽可能降低慌乱交接带来的高昂代价。

实现软件的易用性,本质上要设计出概念的完整性,对于复杂系统,这工作只能由很少数架构师完成,他们是用户利益的代言人,也是团队纪律的创建者。当各个工程师担负的功能实现可以和架构师的概念设计同步进行,个人创意反而可以顺利落实。

设计规范手册有利于规范大家的实现(降低沟通成本),建立缺陷排查日志,少量且关键的文档是至关重要的。

开发人员不愿意编写设计文档,通常并非是没有时间,而是不想把自己的思路暴露在大家的批评之下。

开发人员也不太喜欢画流程图,这是合理的,优雅的程序本身可以取代繁琐的流程图,程序即文档。

最后,高效的开发组织,也需要让技术专家获得不低于同级别管理人员的薪酬和福利。

设计的质量

软件在最初开发时,都是减少熵(减少混乱)的过程,在后期维护时,就变成了增加熵(增加混乱)的过程,这是所有软件的宿命,再好的维护也就是延缓软件退化到不可用的周期。

因此,架构师要学会基于变更而设计实验性的产品,如果发现用户对这个产品并不满意,要能够有计划地抛弃原型开发。开发人员交付的是用户满意度,而不仅仅是有形的产品。

如果我们在开发之前,能提交测试规格说明给专职的测试小组,那么产品的完整性和明确性就能得到详细检查。

在系统测试时,使用已完成充分调试的组件,会节约更多的时间。鼓励声明“已知BUG”,把还未修复的BUG带来的后果告知大家,以便仅聚焦解决新出现的问题。

另外,在变更控制上,和各种敏捷研发理论一致:有专人负责配置管理,隔离出变更范围(变化模块),每次增加一个组件,量子化提交独立变更,等等。

最后,回答--为什么没有银弹?

这么多年来,不管工程技术如何进化,银弹并没有出现的迹象。

我们要把软件工程的困难,分类为根本困难,和次要困难。前者是软件特性中固有的,后者是生产中出现的,但并非与生俱来的麻烦。

根本困难来自于概念结构,而不是如何验证细节:

一,复杂度

没有两个软件是部分相同的,即使有相同代码也会被合成子函数。而硬件,建筑,汽车等行业则不同,存在大量重复的部分。软件系统的内部状态特别复杂,导致设计和测试难度非常困难。软件扩展添加了不同的元素实体,导致交互数量非线性增加。软件的复杂度和数学,物理完全不同,后者是研究模型简化的特征。
复杂度带来一系列核心麻烦,无法规避:沟通,成本,可靠性,拓展难度,安全隐患。

二,一致性

工程师没有办法从科学信念中得到安慰,他面对的很多复杂度是随心所欲的,或者是人为制定的惯例,还需要保持各接口之间的一致性。

三,可变性

软件实体经常要持续变更,类似变化在工业制造产品出厂后发生的概率小得多。因为软件修改成本要低得多,再叠加大量新用户的不同想法,就面临频繁扩展的压力。另外,软件总是在一定硬件上开发的,硬件变化也带来软件适配的变化;软件总是处于一定的用户文化圈的,文化在持续变化,也就无情地强迫软件发生变化。

四,不可见性

软件是不可见的,无法可视化,因此阻碍了思路的交流。不像建筑图纸和分子模型,后者有几何抽象模型。

次要困难的解决则是富有成效的,确实带来工程效能在特定任务上的巨大效率。比如高级语言,分时处理,可视化编程,人工智能和专家系统等。

但纵观这些次要困难,解决的是具体“如何做”的问题,但无法解决“做什么”的问题,起到的只是促进作用。这些解决系统把具体应用的复杂度和实现程序做了分离处理。

我认为以上这一大段论述是软工工程理解上的经典思考,国内这二十年,不论技术工具更新了多少代,硬件强大了多少倍,准确定义一个知名产品依然是异常复杂的,几乎不可能的任务。从QQ到微信,从优酷到抖音,业务团队的规模从来没有明显下降,加班也没有明显减少,哪怕做的功能大同小异。

既然没有银弹,我们现在还能做什么?

虽然工程效能没有真正的捷径,但是显著提升效果的方法还是层出不穷的。不要把软件工程想象为“巨无霸”,而是想象成“微生物的世界”,没有一蹴而就,只有踏踏实实的尝试。

一,找到最优秀的架构师,让他负责整体的架构概念完整性。卓越的设计人员能带来优秀十倍以上的创造力。

二,尽可能购买第三方软件,尽量减少自行开发。商业软件包的增长,主要是因为硬件成本的大幅下降,导致为硬件定制软件的动力大幅下降。

三,引入需求精炼和快速原型工具,让客户尽快知道自己想要啥,概念上达成一致。产品原型就应该不断地被优化规格。

四,增量开发,让系统增长起来,而不是一步搭建到位。

从上可见,人月神话和敏捷观念非常一致,这也是敏捷教练圈会推荐这部经典作品的原因吧。

最后一个启发- 工程师的35岁悖论

这个热门的“操心”话题其实不值一驳。行业的观点很明确了,不论新语言,新工具如何发展,软件工程的本质效能不会突飞猛进。所谓35岁担忧,主要是说工程师年纪大了,学习新产品,新工具和新语言的速度弱于年轻工程师,且不论这个理由是否成立,但熟悉新技术新产品,从来不是软件从业者的核心价值。

能不能找到软件概念的本质,并帮助大家达成理解一致,拥抱敏捷的实践态度,这些才是关键,而这些都需要长期思考和经验的积累。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483798&idx=1&sn=9bb243214d159c5d3bd77cdf1ced5f88&chksm=c24fb4f4f5383de25683757d1e0455a9660dd98654173d6421b4565b70513182c3fd0ad488c7#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 4623
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线