查看原文
其他

软件研发的十大浪费:研发效能的另一面

朱少民 软件质量报道 2022-10-26

“两打程序员,3年时间,4732个bugs,和对非凡软件的不懈追求”
《梦断代码》这本书,是我十几年前看的,一口气读完。当时我还在Cisco(思科)工作,感觉研发团队犯过的错误,在这本书中基本都能见到。
当年Lotus 1-2-3的设计者Mitchell Kapor,离开Lotus后成立了开源应用基金会(OSAF),招募了一批很牛的程序员,开发号称革命性的下一代个人信息管理系统--Chandler。这个团队似乎不缺钱、不缺技术、不缺经验,但偏偏不能发布一款看似简单的软件。6年过去了,Chandler 勉强挣扎着发布了0.7版,花掉几百万美元,但最终还是失败了,梦断代码。
在长达6年的马拉松里面,犯了一系列的错误,导致本来很有希望的项目半死不活。例如,Chandler项目成员决定用P2P架构来共享日历,但没有全力设计相关算法或协议,而是花大量时间去讨论Chandler的界面,这一拖就是几个月,最后P2P架构被彻底放弃,这是极大的浪费。像这种做了,然后被推翻了,在软件研发中也司空见惯。
上一篇讨论了 软件研发效能的负面清单:哪项是头号敌人?今天,讨论软件研发效能的另一面,即软件效能的反面,造成软件效能低下的 “浪费”。浪费可以分为:
  • 直接浪费:不需要的开发成本或直接能感受到的浪费,如(没人使用的代码;被注释掉的代码,从未被使用过的功能、过度测试等;

  • 间接浪费:不是直接能看到的开发成本,如低劣的质量、代码复杂度、沟通效率低等带来的额外成本。

这里不管它是直接成本,还是间接成本,不看它产生的原因,而是看它产生的结果,我把它总结为十大浪费。
第10大浪费:做的工作没有及时发挥效益
例如,写完的代码没有及时提交到代码库中去构建,还在开发人员本地机器中;通过测试的功能还没有交付给用户用,相当于在公司的库存中,没有产生效益。
第9大浪费:不同角色或不同任务之间的切换
例如,一个人参与多个项目,需要在不同的任务间切换,熟悉过多的业务和项目背景,经常切换思维、切换虚拟的工作空间,会造成比较多的时间浪费。
第8大浪费:软件中不必要的交接
软件中任务的交接,自然会增加学习成本,增加了沟通的成本,虽然在日常软件研发中不可避免存在交接,但不必要的交接或过度的交接,都会带来浪费,例如:
  • 人员流动率比较大(如高于20%),老人和新人的工作交接
  • 开发人员和测试人员间的交接,如开发、测试是两个相对独立的团队;
  • 软件从开发到部署的交接(如果实施有效的DevOps,这种成本就很低)

第7大浪费:过度的工作(超出范围)
因为缺乏有效的流程、文档和一致性要求等,工作中没有准确了解项目或任务的范围,做了范围之外的工作,或者不能做到恰到好处,包括过度管理、过度测试、写了过多的文档、过度沟通(太多的会议)等。
第6大浪费:等待
许多人等待其他人的工作,例如团队的沟通协作不够主动,等待其他人找上门;开发测试配合不默契,测试等待开发提交新的版本;各个环节衔接不好,中间都会有等待。即使是一个团队或一项工作内都有等待,例如没做到持续测试,中间会有等待。有时测试环境没准备好,无法做测试,也会有等待。
第5大浪费:一而再再而三地重复犯错
没有做根因分析,头痛医头、脚痛医脚。团队中有些人不犯了,但另一些人再犯;某些团队不犯了,但其它团队再犯;犯的错误可能各种各样,包括糟糕的计划、错误的文档版本等。
第4大浪费:重复造轮子
市面上已有开源工具或成熟的商业工具,不是直接拿来用,或直接购买工具等,而是自己开发。
第3大浪费:返工
由于缺乏统一规范、系统复杂、人员能力弱,导致低劣的质量、产生很多缺陷,造成重新设计、重新写代码,都是返工。过度的代码重构、回归测试等都归为返工带来的浪费。
第2大浪费:无用的功能和代码 
无用的功能和代码,类似“生产过剩”,根据一些数据统计的结果,在现有的软件应用程序中,多达2/3功能几乎或从未被使用过。包括没人使用的代码、被注释掉的代码等。
第1大浪费:整个产品方向性错误 
对用户需求、业务理解的方向性错误,整个产品上线后失败,没人用。

参考:

软件研发的头号敌人是谁?
欢迎扫码参加问卷调查,非常感谢!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存