敏捷测试转型 聊聊没有 35 岁焦虑的《人月神话》

鼎叔 · 2022年04月14日 · 540 次阅读

这是鼎叔的第十五篇原创文章。

行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》,大量原创思考文章陆续推出。

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

软件工程效能到底有没有银弹?
神话中,银弹就是可以让强大的狼人被一击毙命的武器。
这里的银弹,指的是一招制敌,提高数量级的效能水平,而不只是效能有明显改观。
这个话题在业界激烈讨论了几十年,普遍倾向的结论就是 -- 没有!
可以逐步改进,但不能成十倍的改进。
换句话说,如果有某个效能专家,说他的方案可以让你的研发团队取得脱胎换骨的成果,基本上就是个忽悠了。
下面来逐步剖析原因。

软工工程的固有难度
系统级软件产品和单一任务不同,和硬件产品也不同。
写一段可工作代码很容易,做一个编程产品,就困难了好几倍,因为你要定义接口,处理输入的范围,需要让人可理解的编程风格和设计文档,最后要进行彻底的测试。
从一个软件产品到一个系统产品,复杂度又提高了几倍。因为你要考虑可以和它交互的各种程序的集合,还要考虑接口规范和响应性能,还有系统资源的资源限制,比如内存,IO,硬件兼容性。对应的系统测试时间更是成倍增加。

“人月” 的概念误导
项目经理最喜欢做的报表,充斥着 “人月”- Man-Month 的统计指标,咋一看很容易让老板理解项目需要的资源,以及当前的进度还差多少。
技术人员在估算方面往往便乐观,项目方也不会给足够的时间矫正估算,当意识到进度偏差时,关键矛盾就出现了-
从外部增加人手,可以追赶上进度么?
从项目的真实数据统计来看,不行。就算进度最终追上了,付出的 Man-Month 远远超过预估的资源缺口。
疲于奔命的大型软件项目,就像一个焦油坑,项目经理投入的工程师越多,在坑里挣扎得越厉害,无力自拔,于事无补。

究其原因为何?
“人” 和 “月” 不是一个可以互换的概念,除非人和人完全不需要进行交流。大多数任务都不是可以并行的,人们直接协作交流的成本和人数的平方成正比。另外,新人加入项目需要一定的培训时间。
软件产品因为有激烈的时效竞争,不太接受过慢的交付周期。而向进度落后的项目额增加人手,只会使进度更加落后。悖论在此。
项目的进度偏差也不是一下子出现的,它来自于每一天的滞后,或者对其他人员进度的不信任。
一线经理出于利益本能,不愿意让老板看到计划的偏离,而是尝试独立解决问题。
正确的做法建议是:老板应该减少发号施令的压迫感,把行为控制在 “状态检查” 和 “问题行动 “层面,也许就可以顺利地拉开(藏着污垢的)地毯

高效的开发团队
就像一个外科手术团队,主刀医生(首席程序员/架构师)为主角,他专注于系统的思考设计,和成员的协调一致。其他的专业角色各司其职,彼此的交流简单直接,尽可能降低慌乱交接带来的高昂代价。
实现软件的易用性,本质上要设计出概念的完整性,对于复杂系统,这工作只能由很少数架构师完成,他们是用户利益的代言人,也是团队纪律的创建者。当各个工程师担负的功能实现可以和架构师的概念设计同步进行,个人创意反而可以顺利落实。
设计规范手册有利于规范大家的实现(降低沟通成本),建立缺陷排查日志,少量且关键的文档是至关重要的。
开发人员不愿意编写设计文档,通常并非是没有时间,而是不想把自己的思路暴露在大家的批评之下。
开发人员也不太喜欢画流程图,这是合理的,优雅的程序本身可以取代繁琐的流程图,程序即文档。
最后,高效的开发组织,也需要让技术专家获得不低于同级别管理人员的薪酬和福利。

设计的质量
软件在最初开发时,都是减少熵(减少混乱)的过程,在后期维护时,就变成了增加熵(增加混乱)的过程,这是所有软件的宿命,再好的维护也就是延缓软件退化到不可用的周期。
因此,架构师要学会基于变更而设计实验性的产品,如果发现用户对这个产品并不满意,要能够有计划地抛弃原型开发。开发人员交付的是用户满意度,而不仅仅是有形的产品。
如果我们在开发之前,能提交测试规格说明给专职的测试小组,那么产品的完整性和明确性就能得到详细检查。
在系统测试时,使用已完成充分调试的组件,会节约更多的时间。鼓励声明 “已知 BUG”,把还未修复的 BUG 带来的后果告知大家,以便仅聚焦解决新出现的问题。
另外,在变更控制上,和各种敏捷研发理论一致:有专人负责配置管理,隔离出变更范围(变化模块),每次增加一个组件,量子化提交独立变更,等等。

最后,回答--为什么没有银弹
这么多年来,不管工程技术如何进化,银弹并没有出现的迹象。
我们要把软件工程的困难,分类为根本困难,和次要困难。前者是软件特性中固有的,后者是生产中出现的,但并非与生俱来的麻烦。

根本困难来自于概念结构,而不是如何验证细节:
一,复杂度
没有两个软件是部分相同的,即使有相同代码也会被合成子函数。而硬件,建筑,汽车等行业则不同,存在大量重复的部分。软件系统的内部状态特别复杂,导致设计和测试难度非常困难。软件扩展添加了不同的元素实体,导致交互数量非线性增加。软件的复杂度和数学,物理完全不同,后者是研究模型简化的特征。
复杂度带来一系列核心麻烦,无法规避:沟通,成本,可靠性,拓展难度,安全隐患。
二,一致性
工程师没有办法从科学信念中得到安慰,他面对的很多复杂度是随心所欲的,或者是人为制定的惯例,还需要保持各接口之间的一致性。
三,可变性
软件实体经常要持续变更,类似变化在工业制造产品出厂后发生的概率小得多。因为软件修改成本要低得多,再叠加大量新用户的不同想法,就面临频繁扩展的压力。另外,软件总是在一定硬件上开发的,硬件变化也带来软件适配的变化;软件总是处于一定的用户文化圈的,文化在持续变化,也就无情地强迫软件发生变化。
四,不可见性
软件是不可见的,无法可视化,因此阻碍了思路的交流。不像建筑图纸和分子模型,后者有几何抽象模型。

次要困难的解决则是富有成效的,确实带来工程效能在特定任务上的巨大效率。比如高级语言,分时处理,可视化编程,人工智能和专家系统等。
但纵观这些次要困难,解决的是具体 “如何做” 的问题,但无法解决 “做什么” 的问题,起到的只是促进作用。这些解决系统把具体应用的复杂度和实现程序做了分离处理。

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

既然没有银弹,我们现在还能做什么?
虽然工程效能没有真正的捷径,但是显著提升效果的方法还是层出不穷的。不要把软件工程想象为 “巨无霸”,而是想象成 “微生物的世界”,没有一蹴而就,只有踏踏实实的尝试。
一,找到最优秀的架构师,让他负责整体的架构概念完整性。卓越的设计人员能带来优秀十倍以上的创造力。
二,尽可能购买第三方软件,尽量减少自行开发。商业软件包的增长,主要是因为硬件成本的大幅下降,导致为硬件定制软件的动力大幅下降。
三,引入需求精炼和快速原型工具,让客户尽快知道自己想要啥,概念上达成一致。产品原型就应该不断地被优化规格。
四,增量开发,让系统增长起来,而不是一步搭建到位。

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

最后一个启发- 工程师的 35 岁悖论
这个热门的 “操心” 话题其实不值一驳。行业的观点很明确了,不论新语言,新工具如何发展,软件工程的本质效能不会突飞猛进。所谓 35 岁担忧,主要是说工程师年纪大了,学习新产品,新工具和新语言的速度弱于年轻工程师,且不论这个理由是否成立,但熟悉新技术新产品,从来不是软件从业者的核心价值。
能不能找到软件概念的本质,并帮助大家达成理解一致,拥抱敏捷的实践态度,这些才是关键,而这些都需要长期思考和经验的积累。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册