敏捷方法已在软件开发中变得无处不在,提供了灵活性、适应性和协作性。然而,当涉及到硬件时,情况就有所不同了。开发团队渴望,并且经常受到压力,要实现与软件团队相同的敏捷带来的好处,但却难以应用相同的原则和策略。对敏捷方法持有健康怀疑态度的开始,很快就会转变为挫败感,以及迅速回归到勉强能忍受的传统瀑布式技术。
在这个由三部分组成的博客系列中,我们将深入探讨在电子硬件开发中应用敏捷的复杂性。这第一部分探讨了在敏捷框架内,硬件开发与其软件对应部分的五个基本不同之处。
在即将到来的文章中,我们将探讨敏捷“大师”如何可能会误导团队,然后,最终,硬件团队如何“重新思考”常见的软件(SW)策略以获得敏捷原则的真正好处。
硬件和软件开发之间最明显的区别在于它们输出的性质。软件产出的是无形产品,可以轻松地以最小的成本进行更新和修改。相比之下,硬件结果为有形的、实体的产品,这些产品需要经过严格的设计、原型制作和制造过程。硬件的物理性质使其本质上不如软件灵活,因为更改通常涉及昂贵的重新工具设置和生产调整。敏捷开发之所以根植于其适应变化需求的能力,在硬件开发中面临挑战,这是因为物理迭代的性质更为僵硬和成本更高。
敏捷的迭代方法是为快速、连续的软件开发周期而优化的,在这些周期中,变更可以轻松实施、测试和发布。在硬件开发中,开发和测试日益功能化的解决方案的迭代需要集成物理组件、制造和组装。这一根本差异要求在硬件和电子开发中对敏捷原则进行细致的应用,强调更加精确的规划和针对性的学习方法,以尽量减少频繁的物理修改需求。
与软件相比,硬件开发本质上需要更长的开发周期。设计、原型制作、测试和制造的复杂过程引入了软件开发快速周期中不存在的依赖性。虽然短开发周期、反馈循环和快速适应变化的需求是敏捷开发好处的核心,但硬件的自然延长时间线带来了挑战。
在敏捷软件环境中,团队可以迅速根据用户反馈或市场变化进行调整。在硬件开发中,变更更耗时且成本更高,需要采取更加谨慎的方法。敏捷原则必须被定制以适应更长的迭代周期、更复杂的组件集成、无情的交货时间和共享资源,以及内部和外部的依赖性。
敏捷的基石之一是其能力,即使在开发过程的后期也能接受变化。然而,硬件开发往往需要更加谨慎的前期设计,因为修改物理属性所关联的挑战。与软件不同,在软件中可以在任何阶段进行调整,硬件设计决策必须在过程的早期做出,以最小化成本高昂和耗时的返工。团队必须清楚地理解在哪里、如何以及为什么冻结设计的部分内容,同时为了实现项目目标,尽可能长时间地保持战略价值区域的开放。
这种前期设计要求挑战了敏捷原则中对变化的响应超过遵循计划的原则。虽然迭代和灵活性仍然至关重要,但硬件开发团队必须在适应性和需要更严格设计方法之间找到平衡。这要求对敏捷采取更加结构化的方法,早期在项目中纳入迭代规划和设计周期,以减轻后期修改相关的风险。
电子硬件开发与复杂的供应链动态密切相关,涉及各种组件、材料和制造过程。与可以通过互联网即时分发的软件不同,硬件开发依赖于物理组件的可用性和及时交付,更不用说对物料清单(BOMs)、制造变更等的细致管理了。 敏捷强调协作和持续交付,对依赖错综复杂的供应商和制造商网络的硬件开发团队来说,这带来了挑战。这些团队还必须处理库存管理,支持独特的库存单位(SKUs),并更新现场材料。想象每个月向制造商或分销商发布一个新版本的芯片组或PCB,管理各种产品变体的范围很快就会变得几乎不可能。为了应对这些挑战,需要将敏捷原则调整为包括与供应商、制造商和其他利益相关者之间的强大沟通、协作和发布策略。透明度,以及产品更新和发布的智能节奏,对于管理期望和确保整个价值链的需求得到满足至关重要。
敏捷开发依赖于跨功能的合作,将具有不同技能和视角的个体聚集在一起。在软件开发中,这通常涉及开发人员、测试人员和产品负责人之间的合作。在硬件开发中,合作不仅包括这些角色,而且还扩展到包括各种机械工程师、电气工程师、设计师、制造专家和固件开发人员在内的多样化团队。
硬件开发的跨学科性质要求敏捷团队具有更广泛和多样化的技能集。确保这些不同学科之间有效的沟通、合作和计划成为一个独特的挑战。敏捷方法必须适应以促进不仅是硬件和软件团队之间,而且还强调一种整体方法,以满足每个硬件学科的需求,同时使它们与项目目标保持一致。并且尽量减少开销和摩擦。
虽然敏捷已经在软件开发领域证明是一个游戏规则改变者,但将其应用于硬件开发需要一个深思熟虑和细腻的方法。认识并解决两者之间固有的差异对于成功整合至关重要。本系列的第一部分已经揭示了硬件开发中五个挑战传统敏捷实践的关键区别。
你是否对通过敏捷方法论的视角探索硬件开发的世界,并学习在该领域成功所需的知识感兴趣?观看网络研讨会!