敏捷产品开发是软件方法在实体产品制造过程中的应用。从某种意义上说,就是使用敏捷式方法构建产品,或者更直白地说,像开发软件一样开发硬件。
敏捷开发并不是一个新概念。在许多人心中,与 SaaS、云计算等众多围绕数字化转型概念的技术一样,敏捷开发未来也将成为一项无处不在的技术。然而,好多硬件制造商似乎还没有意识到这一点。在他们的认知中,敏捷开发是一种软件开发理念,这好像没什么问题…但是,在实体产品上下文中,敏捷产品开发完全不是这么回事,只是许多人还没有完成思维转变。
在这篇博客中,我们将探索敏捷产品开发的所有不同角度,从它在软件领域的发展历程到它的价值和原则,再到它为什么也适用于硬件产品开发。
敏捷开发原则的确切起源不得而知,不过,我们倒是知道这个术语完全形成是在什么时候。敏捷宣言诞生于 2001 年,当时 17 名软件开发人员聚集在一起,讨论轻量级开发理念背后的潜力和战略。从这段发展历程来看,它好像仅涉及软件领域。宣言可以分解为 12 个核心原则和 4 个中心价值,而所有这些都旨在推动提升协同能力、提高透明度和加快产品交付速度。
一经发布,敏捷宣言迅速在软件领域普及,人们大多将其视为普遍适用的积极因素。一如其设计理念,敏捷开发可以提高工作效率、缩短产品交付时间,加强团队之间的沟通,在工作地点分散的情况下,效果尤其明显。
然而,尽管所有积极因素都在软件领域一一应验,但硬件领域的相关人士还是对敏捷开发的适用性持怀疑态度。采用敏捷式方法完成的工作可分解成若干冲刺 – 预先设定的工作持续时间通常持续既定的数周,最终输出为可交付的产品。这在软件领域完全可行,但在硬件领域似乎行不通 – 至少当冲刺必须持续数周,且在每个冲刺结束时的期望结果仅仅是一个可用产品时是这样。
但是,对相关价值和原则探究一番后,我们大多可以做出一些调整,以支持产品开发中的敏捷式方法。深入研究价值和原则,更好地了解敏捷思维。
如前所述,敏捷开发的 12 个原则在设计之初只是面向软件开发;其精神要义确实也非常契合硬件开发,但可能需要进行一定调整,才能适应实体产品(而不是数字产品)的创建过程。我们将逐一说明。
“为确保客户满意度,首先要做到尽早、持续交付意义重大的软件。”
在敏捷开发中,沟通至关重要。应鼓励客户尽早并持续参与产品开发,方便他们针对需求和期望及时提供准确反馈。这样做可以减少不一致风险,还能让团队在必要时快速向客户提出质疑或疑问。
“即使到了开发后期,也应积极接受变革。敏捷流程利用变革来为客户创造竞争优势。”
敏捷开发接受不断变化的需求。在传统的瀑布式开发流程中,后期的临时变动会造成重大损失;而在敏捷开发中,变动(即使是在开发的后期)不会遭到任何排斥,因为它反应了实际情况。市场、竞争和客户需求总是在持续变化和发展。随着项目的推进,不断将新信息整合到最终设计中非常重要。
“频繁地交付可用软件,交付间隔从几周到几个月不等,时间越短越好。”
敏捷式方法的一个重要优势在于它可以精简产品开发。宣言指出,至少每两个月交付一次产品。对于硬件设计,特别是大型、复杂的产品,这么短暂的交付时间或许根本不可能,但还是有必要为项目设定明确的目标和具体的检查点并适当收集反馈。
“在整个项目开发期间,业务人员和开发人员几乎每天都要合作。”
在敏捷式方法中,任何人都不能游离于团队之外。有关各方和开发人员频繁沟通,有助于确保项目资源充分,顺利推进。日常工作中,面对面会议十分常见,Slack 频道等协同工具和其他实时云解决方案又能进一步提升协同效果。
“围绕积极向上的员工来构建项目。为他们提供必要环境和支持,相信他们能够完成工作。”
赋能是敏捷开发的关键要素;个人和团队都应该能够从项目成功中收获成就感,也能在保证专注工作的状态下获得支持。从某种程度角度来看,该原则教育我们不要纠结于对错,相反,团队应该能够承担一定风险,做出各种尝试,然后讨论结果是否可行。在项目中相互学习是实现迭代改进的重要举措。
“无论是向开发团队传达信息,还是开展内部沟通,面对面交谈都是一种行之有效的方式。”
敏捷宣言指出,没有什么可以代替直接沟通。2001 年,视频通话对于普通人还是遥不可及,虚无缥缈。现在,已经司空见惯。无论是远程沟通还是当面对话,在减少不确定性和加强团队协同方面,没有什么可以取代直接、面对面互动。
“行之有效的软件是衡量进展的主要手段。”
这种说法同样适用于实体产品的开发,其中“行之有效”是一种相对概念。开发一种满足所有要求的全新医疗设备可能需要两年时间。但是,借助敏捷式方法,您可以将大型项目分解为更多管理元素和目标,在推进过程中安排反馈时间。与其说要构建“行之有效”的产品,它更侧重于不同的截止日期,以实现构建可用实体产品的最终目标。
“敏捷流程应当能够促进可持续发展。赞助者、开发人员和用户应该始终能够保持恒定的开发节奏。”
敏捷式方法是迭代的,这意味着应采用恒定且稳定的速度来开发产品。敏捷开发过程中会创建一个进度计划,在其中充分考虑可用资源和项目需求。项目应为所有任务和整体反思预留足够时间。
“持续关注技术卓越和设计优化可以提高敏捷性。”
这是我们永不停歇的追求。关注过程中的细节,确保卓越实践得到全方位实施,这可以让您在遇到意外障碍时轻松改变方向或做出调整。
“简单(大幅减少不必要工作)是一门艺术。”
这一点放在产品设计领域也依然正确:设计简单,体验更好。
“卓尔不凡的架构、需求和设计通常源自自发组织的团队。”
帮助团队探索高效工作方式可能会带来意想不到的结果。
“团队应定期反思如何提升工作效率,然后对自己的行为进行相应调整。”
敏捷流程是周期性的,因此我们有必要在整个过程中定期反思并做出相应调整。这样可以营造积极向上的氛围。
了解了敏捷开发的原则后,接下来,我们一起探讨如何将这些原则应用到当今竞争激烈的实体产品市场。
乍一看,多次迭代的想法似乎违背了敏捷式方法在产品开发中的适用性。但是,持续生产一种可用产品,只为在下一个冲刺阶段中立即迭代,循环往复,直到生产出最终产品,这种做法显然并不可行。这在很大程度上解释了为什么许多制造商只把敏捷开发当作一种软件工具。
然而,现实情况更为复杂,归根到底,这是照搬采用和适当调整之间的选择。完全照搬敏捷原则势必会给硬件制造商带来各种不合理的要求。相比之下,如果能将敏捷开发融入硬件思维,我们就可以把敏捷开发的精髓复刻到制造领域了。现在,我们来细细探索如何做到这一点。
所有产品开发都有生命周期,涵盖从概念到产品发布的整个过程。冲刺只是细化生命周期阶段的另一种方式。冲刺的重点是要有一个明确的可实现目标。在软件领域,这通常意味着发布一款产品。然而,对于硬件领域,最终目标并没有这么直接。只要有可衡量进展就已足够,这可以帮助我们将复杂的硬件开发分解成清晰连贯的各个阶段。
即使是医疗保健等受监管行业也可以使用敏捷式方法。如果平均产品开发周期为两年,那么制造商应该考虑半年内的实际完成情况。两年的周期就变成了四个冲刺,中间还需要加上检查和产品评估。借助敏捷式方法,制造商可以为自己设定基准、定期检查团队完成情况,提高硬件开发流程的透明度。
分布式硬件制造的想法并不新鲜。事实上,对于许多企业来说,分布式生产已经存在数十年(甚至更长时间)了。敏捷产品开发就是为硬件制造商提供现代工具,大幅提高分布式工作的能力。这不仅关乎视频会议软件,更是一种全新的思维方式,要求我们优先考虑跨团队协同,改善内部沟通和合作。
今天,沟通和协同比以往任何时候都更重要。市场不确定因素越来越多,部分是由于客户期望。客户知道自己想要什么,也希望尽快获取期望产品 – 这可能会缩短预期上市时间。组织还必须准备好应对供应链的不确定性、不断变化的全球环境以及许多其他复杂情况。
敏捷产品开发采纳了敏捷宣言的精华内容(包括部门和有关各方之间与日俱增的内部沟通次数、频繁的产品开发交流、清晰定义的目标、自发组织、劲头十足的团队结构)并将其引入硬件领域。
组织不必全面采用敏捷式方法就能感受到它的些许优势。企业面临的情况各不相同,而敏捷开发就是为实现灵活性而来。如前所述,通往成功的过程中通常需要不断调整而不是照搬采用。敏捷产品开发可以帮助组织加快创新速度,交付卓越产品,在日益动荡的形势下应对各种不确定性。
任何一种产品开发方法都有其优点和缺点。提前了解可以帮助团队充分发挥敏捷式方法的优势,做到扬长避短。要深入了解,请参阅敏捷产品开发的 3 大核心优势。
敏捷开发很可能代表了团队和公司产品开发方式的转变。要营造支持氛围,让团队参与进来,不妨探讨敏捷产品开发的含义,尤其是它的价值和原则,同时了解如何将这些原则应用到您的项目。
敏捷开发需要跨部门团队之间频繁开展实时沟通。而他们需要工具来支持这种工作方式;处理大型复杂产品设计文件时,电子邮件不再适用。云原生 CAD 和 PLM 解决方案等工具能够比先前基于安装/文件的工具更好地服务于敏捷产品开发。除了这些核心产品以外,还可以借助增强的通信和协同工具(例如 Slack、Miro、Smartsheet、JIRA 等)。共享系统加速了多个有关各方和团队(包括自由设计师、供应商和合作伙伴等外部参与者)之间的协同。
团队在逐渐过渡到敏捷式方法的过程中,不需要全盘接受或否定。敏捷式方法的某些内容可能不太适用于您的公司。取其可用,祛其无效,持续专注改进流程。
在敏捷式方法细化的冲刺中,通过完成预定成果展示检查点和分享相关进展,逐步达成目标。确保团队不仅有时间对产品进行迭代,还有精力对过程提供反馈。整合产品反馈,将其运用到下一个冲刺。有了追求成长的心态,团队就能随时直面失败,然后从错误中吸取教训。
敏捷式方法和瀑布式方法都是用于执行和管理的项目管理方法,但它们截然不同。
敏捷式方法优先考虑迭代式开发,团队可以在几周或几个月内快速开发和微调产品,同时以近乎恒定的频率获得客户反馈。相比之下,在瀑布式方法中,每个过程都遵循线性路径:过程沿着一个方向在各个阶段中移动,回溯基本不太可能,或者过于昂贵而不实用或不可持续。每个阶段都非常注重优化,直到看到有效进展。
敏捷式方法更关注周期而不是阶段。开发人员和有关各方协作设计,并在整个过程中提供反馈。目标在一次次“冲刺”中完成,通常由客户直接输入。客户要求进行产品和团队冲刺,把所有精力都投入到满足第一个既定目标。之后,客户会给出反馈,团队实施相应更改,迭代过去的设计,从而快速创建新产品。冲刺时间往往很短(几天到几周),专注于快速完成小目标,而不是优先考虑获得显著成就。使用敏捷设计方法,反馈和对话在设计阶段就开始了。
否,敏捷式方法的原则和核心价值绝不仅仅适用于软件开发。始于软件,但企业现在也逐渐意识到灵活性、适应性和协作性更强的项目管理方法确实可以带来巨大价值。
敏捷开发分为五个阶段,整个流程也算是结构清晰,但这几个阶段本身并不是要遵循的步骤。它们相互重叠,出现新信息或需求时,可以随时重新访问。
这个阶段为所有敏捷项目奠定了基础;要在其中定义愿景,列出要完成的目标。
这一阶段需要回答以下问题:
在最初的愿景阶段清晰阐释所有因素(对象、目标、方式、时间),在下一个阶段开始细化。
本阶段为头脑风暴,每个人都可以提出自己的想法,然后大家一起思考。在思考过程中,将根据项目的指定参数(即资源,时间等)决定可行事项与不可行事项。
在这个阶段中,团队成员会初步形成大体的产品要求,深入了解不同团队成员的工作量,制定交付计划(通常为分阶段时间表),确定和减少风险及依赖关系,以及估计成本。
进入本阶段,项目处于正如火如荼的状态,团队要根据愿景和时间表开发产品。然而,他们会遇到一些小问题,而这正是敏捷开发真正发挥作用的时候。通过频繁检查和沟通,我们可以管理工作负载,保持卓越实践,有效应对任何挑战。团队应该根据需要协同工作,在相关方面时刻保持沟通交流。在产品开发的各个时间节点,应定期安排针对所有有关各方的检查。
在产品开发过程中,随着新信息的出现,修改、更改和更正不可避免。这就是调整阶段(很可能还需要在推测、探索阶段进行重新调整)。这个阶段的关键在于向有关各方征求意见,了解他们的不同观点和专业知识。换句话说,一旦项目产出了具体成果,就需要分析目标是否达成。在调整阶段,要考虑来自不同群体的反馈,列出必要改进,然后制定下一次迭代计划。
诚然,敏捷开发是一个周期性迭代的过程,但项目还是要有一个结果。产品投入生产后,或者关键功能更新完成后,我们当然要庆祝成功,但也要对过程进行评估,全面分析,收集反馈,然后将心得体会整合到下一个项目。
敏捷式方法之所以效果更好,是因为它了解产品开发不是一个线性流程;它可以为我们打造一个框架,允许团队有效响应变化、风险和不确定性。它强调协同包容和灵活调整。它还将客户置于流程和产品的核心,从而最终实现更好的产品设计。