标签 软件工程 下的文章

由一个软件库存问题想到的

近期产品线出现这样一个“怪现象”:许多已经完成编码并具备提交给测试组的版本没有测试人员对应。测试部那边给出的策略是:按版本优先级从高到低依次测 试。这样一来一些重要版本需要到3个月甚至更长时间之后才能开始测试。可以肯定这种现象是生产环节的一个问题,但用什么理论去解释和分析这个问题呢?我想 到了“库存” – 软件库存。

Joel说软件》的那个Joel曾写过一篇名为《软件库存》的文章,也正是看了那篇文章后,我才第一次了解到软件库存这个概念。库存似乎是传统制造业中 的一个概念,但软件开发其实也是广义产品生产的一种,虽然有其特殊性,因此有些产品制造方面的理论是可以应用于软件生产过程中的,软件库存就是其中之一。

传统制造业的库存较为容易理解,零件、原材料、半成品以及未卖出去的最终产品这些都可以理解为库存。而软件生产中的库存都包含哪些内容和环节呢?一旦形成库存,利弊又有哪些呢?

* 未纳入开发的需求/特性

这里所说的需求/特性是经过决策后将来要开发的且能带来价值的,而不是为了大而全而滥芋充数的那种。这类需求/特性可理解为已经采购并存放在库中尚未投入 生产的原料库存。这类库存如果变得很大,则很可能说明产品市场场景甚好,但也可能是现有的生产能力出现了不足;如果这块库存过小或没有,则会导致后期开工 不足,或者说产品的持续成长前景黯淡,市场对其的需求也不乐观了,组织对此情况应做出迅速反应。

* 已经开发完毕但未经测试的半成品

开发人员开始投入,根据需求/特性疯狂编码、单元测试,生产出未经专业测试的半成品。这些半成品因其中潜在的许多缺陷而不能作为最终商品投放市场,因此无 法收回成本并赚取利润。一旦这个环节形成库存,则说明后续质量验证环节的生产能力与软件开发环节的生产能力出现了不匹配,这将导致版本中的问题不能尽快地 暴露,使得问题流向其他版本或其他系统中,直到测试开始后才能发现,后续要花费更多的工作量做关联的修正。这也是我所在产品线所遇到的棘手问题,唯一的方 法就是提高质量验证环节的生产能力,至于如何提高,因地制宜,这里不表。而较小的库存或这个环节无库存,也会导致后续质量验证环节的开工不足,或衔接出现 节奏性的问题。

* 未上市或未卖出的成品

当产品顺利通过质量检测部门的测试后,便可正式发布,变成最终产品- 成品,交付到最终用户那里。但如果这个环节出现库存,问题将变得严重得多。要么是前期市场估计过于乐观,要么是行销人员不给力,要么则是生产过剩,没有做 好库存管理等等。如果这个环节库存过小,则最终客户依旧无法及时得到产品,不利于保持客户粘性,客户很可能退而求其次,选择其他厂商的产品了。

以上简要分析既提到了不能忽视库存的存在,也说到了无库存的危害。传统制造行业一直在追求着一种“零库存”的概念,所谓“零库存”,是指物料(包括原材 料、半成品和产成品等) 在采购、生产、销售、配送等一个或几个经营环节中,不以仓库存储的形式存在,而均是处于周转的状态。它并不是指以仓库储存形式的某种或某 些物品的储存数量真正为零,而是通过实施特定的库存控制策略,实现库存量的最小化。在软件生产领域也可借鉴这一概念,在各个环节努力维持合理且适当的库 存,这对整个生产过程是大有裨益的。

可以看出“零库存”的一个精要就是及时收回产品的投资,获得利润,保持生产过程的持续有效进行。这让我想到了当今软件过程的演化:从最初的瀑布过程到目前 流行的迭代和敏捷等过程,以及流行的持续交付等概念,它们似乎都是在追求“零库存”,追求快速回流价值。或者说库存理论潜在地催生了敏捷、持续交付等概念 的迅速发展,并让人们看到其中的裨益所在。

软件业的'图纸'在哪里?

上周日和橱柜公司商量好,下午三点到我的房子量尺,橱柜设计师按时到达,拿着一卷尺开始了测量工作。有过装修经历的人都知道:在装修公司进场之前需要橱柜设计师出一份水电改造图,便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通,这不由得让我想起这样一个问题:"软件开发领域的"图纸"在哪里呢"?

"图纸"是建筑行业的标准的共同语言,它能让设计师与施工者无缝沟通,同时由于建筑图纸的形象性,普通人看了基本也能了解一二,这样普通用户和设计师沟通起来也是很容易的,即使是一个外国设计师设计的图纸,只要使用了标准的图纸符号,中国的施工者也可以完美的将之实现出来,反之中国设计师的作品,外国施工人员也亦然可以实现之。软件行业的人总喜欢拿软件开发与建筑行业做比较,设计模式就是其中最典型的例子。不过这么多年来,软件开发过程仍然无法达到建筑业的那么"精确",这里的精确不是指过程和进度的精确,而是沟通的"精确"。

软件开发领域的"报怨声"已经持续了几十年了,需求分析人员无法获取用户的准确需求、系统设计人员无法将自己的全部设计思想很好的传达给编程实现人员,人们都在抱怨:缺少一种"共同语言",能让他们之间"无缝的沟通"。软件业的大师们绞尽脑汁、费尽心思、提出了多种沟通语言,以试图解决这个问题。这里面最著名的莫过于由OMG组织于20世纪末推出的"统一建模语言(UML)"了,顾名思义,UML试图统一软件开发领域所有过程阶段的"沟通标准",需求阶段有Use Case图;设计阶段有组件图、类图;部署阶段有部署图,另外还有序列图、状态图、活动图作为辅助。UML到目前为止也从1.0发展到了2.0版本,但其实际应用情况如何呢?乐观点说是:没有"图纸"在建筑领域应用的那么广;如果从我了解的和接触的实际情况来看,UML已经过了其高峰期,开始变得"不瘟不火"。

程序员多数喜欢简单化、个性化和形象化的表达思想,一块白板,无拘无束。虽然UML在形象化上做的还不错,但是却始终无法打动程序员的心扉。从另一个事实来讲,图纸是建筑行业的门槛或者说是基础,而与之对应,代码才是软件行业的门槛。这样一来似乎代码才应该是一种共同的语言,在"敏捷软件开发"的附录中就有这样一篇文章:"源代码即设计"。那是否说:"代码"就是"软件业的图纸"呢?"代码"在设计开发人员之间可以说是基本无缝的,但是对于普通客户而言,代码似乎太专业了。其实在建筑行业"图纸"也多在设计师和设计师、设计师与施工人员之间做沟通之用,大项目中少有客户与设计师沟通时使用"图纸",多数会用外观效果图。这样一来似乎软件开发领域的"代码"与建筑业"图纸"的概念达到了一定的一致性。"代码"作为沟通媒介的前提是:代码和设计的统一。为了达到这一目的,需要代码结构清晰,可读性,可沟通性要好,这也势必需要实现人员提高编码技艺。都说编程是一门艺术,从这里来看,名符其实。如果承认"代码"这一地位,那么实际上是确定了一个方向,以后向这个方向努力就是了,众所周知的"敏捷"在这个方向上做出了努力。

上面也已经说过,"代码"过于专业,并不能作为"统一沟通媒介"来统一整个软件开发过程,看来我们只能继续期待头脑中理想的"图纸"的出现了,也许它会诞生于将来的一个突破性的"发明"或"发现“;也可能它将是一个永远的"梦"。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats