大多数敏捷“大师”对硬件开发的误解

敏捷方法论，源于软件开发领域，被誉为技术行业的变革力量。然而，当我们进入硬件和电子开发领域时，敏捷原则的看似顺畅适应遇到了一系列挑战和误解。在这三部分探索的第一部分中，我们分析了硬件与软件开发之间差异引起的敏捷挑战。在本文中，我们将检验由敏捷“大师们”传播的神话。

在深入探讨电子硬件开发中的敏捷细节之前，重要的是要澄清，我们的目的不是贬低敏捷教练和顾问。我们认识并感激他们帮助客户获得敏捷方法论好处的良好意图和热情。虽然一些批评可能源于对硬件细节的有限理解，但目的不是批评，而是有效地适应敏捷原则，以满足硬件开发的特定需求。我们的重点是调整敏捷策略，以在这一独特背景下发挥其好处，修改方法但保留原则。

谬论 #1: 你必须保持灵活并适应

敏捷大师正确地颂扬了迭代执行、反馈循环以及在软件的数字领域中蓬勃发展的快速适应能力的优点。然而，这些原则转移到硬件和电子的有形领域时，引入了一层在纯数字领域中未发现的复杂性。与软件相比，物理解决方案需要“完成”，以便订购零件、制造模具和满足严格的制造需求。敏捷对持续变化的呼吁与硬件的无情本质发生冲突，即使是在游戏后期需要进行的轻微更改也会产生连锁反应。

作为回应，修改敏捷开发以适应硬件开发需要一种范式转变。这不是关于无休止的修改，而是基于快速学习和执行周期的明智、战略性调整和原型设计。这些旨在在时间、预算和资源的限制条件下最大化价值。敏捷灵活性与物理产品最终需求之间的平衡需要更加谨慎的迭代计划和对整个项目风险降低的深刻承诺。

谣言 #2: 每个冲刺都必须开发一个可工作的原型

虽然敏捷纯粹主义者经常宣扬每两到三周开发一个完全功能的原型“冲刺”是实现敏捷的普遍“必须”，但这种方法在面对硬件和电子开发（以及预算）的现实时，其实际可行性就会崩溃。构建某物，展示进度，并使用这个成果来获得宝贵的技术和商业反馈以指导你的下一次迭代的想法是正确的。然而，每个硬件项目都是一个具有自己的目标、依赖关系、领先时间约束、需要创新的领域和风险的独特实体。每个项目都应该有其自己独特的原型制作和学习方法。

要真正拥抱敏捷硬件产品开发，团队必须摒弃一刀切的思维模式。相反，他们必须仔细审视项目需求，然后合作制定一个创造性的、学习性的和原型设计策略。重要的是要认识到，“原型”可以是任何可展示的输出，从初步的宣传册到泡沫模型（就像史蒂夫·乔布斯著名的iPod模型，它能“让你口袋里放1000首歌”），甚至包括部分或完全功能的原型。

神话#3：向待办事项列表添加故事，然后就开始

敏捷方法的一个内在优势在于它们启动项目的速度比传统瀑布式方法要快得多。实际上，对于敏捷硬件电子项目，我们已经看到从概念识别到开发启动的周期显著缩短。这个周期，在传统的分阶段方法下通常需要数月甚至数年的时间，现在通过敏捷方法被压缩到了几周甚至几天。当然，这一戏剧性的结果部分原因是我们如何定义“开发启动”。 在软件领域，这是直截了当的。敏捷大师倡导编写用户故事来定义软件功能，将它们优先排序到待办列表中，并启动一个冲刺。然而，在硬件领域，至少需要一些最初的规划来指导项目朝着正确的方向发展，这需要对架构、关键期望属性、约束以及其他因素有所了解。这种最初的努力似乎与敏捷原则“工作中的软件是进度的主要衡量标准”和“欢迎变更需求，即使是在开发后期”相冲突。 和解在于通过将普遍理解的敏捷策略适应到产品开发的前端来找到平衡。硬件的敏捷项目管理允许通过与项目的战略意图对齐并接受比传统方法更多的未知数来迅速启动。团队然后可以利用敏捷的迭代学习来定义最佳解决方案，同时保持对增强产品价值的战略变化持开放态度，同时保持在时间表和资源限制之内。

神话 #4: 将所有工作项定义为用户故事

许多敏捷开发大师强调的一个关键指导原则是，所有开发工作都应该定义为用户故事。继续的建议是，系统组件、接口、其他工程师等，都应该被视为“用户”。这个建议让大多数电子和硬件开发者感到困惑，难以遵守。

软件团队之所以如此轻松地采纳敏捷实践的一个主要原因是，用传统的需求文档和详细的用例文档来记录客户需求，这种做法非常浪费且对团队几乎没有增加任何价值。为什么不直接声明用户试图做什么，编写一个用户故事来记录功能，然后将其视为一个开发任务呢？这不仅是自我记录的，而且如果这些故事能够持续地被优先考虑并且与客户进行验证，我们就拥有了一个完美的闭环系统来响应变化并优化价值。太棒了！

直接将用户故事作为硬件开发的工作项，并将它们追溯到有价值的客户输出，通常是许多硬件团队在敏捷开发中的破碎点。定义硬件与定义软件就是不同的。传统的产品需求文档（PRDs）和功能规格不仅让硬件开发者感到安心，而且还提供了必要的细节，以分解并交付他们的工作。要求开发者编写如“作为一个处理单元，我需要电压调节以确保干净的输入……”这样的用户故事，违背了通过用户故事捕捉客户价值的目的，并增加了软件开发者急于用敏捷原则去除的非价值浪费。

正如软件敏捷开发的早期思想领袖Mike Cohn所定义的：“用户故事是从人的角度出发，对一个功能的简短、简单描述。”这里的关键词是“人”。硬件团队可以从编写用户故事中获得显著价值，但必须使用它们来捕捉人们的客户需求，而不是定义工作项。这些故事然后必须被翻译成产品属性和相关的工作项，以满足期望的结果，使用对硬件开发者有意义的技术。

神话 #5: 你必须拥有专职团队成员

Vitality Chicago 的 LinkedIn 调查显示，54% 的敏捷实践者表示，拥有一个专注的Scrum或敏捷团队（意味着团队成员的专注）是敏捷规则的一个重要部分。虽然在敏捷宣言中没有讨论到专门团队的问题，但敏捷大师们经常将其视为一条规则，很难说如果团队成员能100%专注于一个项目就不会有很多好处。这样就几乎没有借口不履行承诺，没有什么能分散成功的注意力，也不会有人说：“这个其他项目本周的优先级更高！”

然而，如果你曾在硬件开发环境中工作过，你就会知道拥有专职团队成员是许多组织难以承担的奢侈。硬件开发的本质是，架构师、主设计师和其他主题专家（SME）通常需要参与多个项目。一家公司可能有一个在需要时会被召唤的无线电频率专家，一个在关键时刻需要的布局专家等等。硬件开发团队仍然可以采用和利用敏捷方法，但拥有专职团队成员通常不是一个选项。因此，拥有一个支持敏捷的资源管理方法对于长期的敏捷成功至关重要。

#谬误 6: 敏捷就是其定义的角色、仪式、典礼和词汇的总和

在一家公司里，两个团队并肩工作：一个硬件团队采用传统的瀑布模型，而一个软件团队采用Scrum方法。一位硬件开发人员走过会议室时，听到软件开发人员围成一圈，正在说：“好的，欢迎来到我们的站立会议。在上一个冲刺中，我们在用户故事点估计和验收标准上遇到了困难。我们的Scrum主管分享了我们最新的燃尽图，并且促成了一个回顾会议来解决我们积压工作整理中的问题，以便我们可以提高速度。让我们用拳头到五指的方式来表达我们对变化的感受。”一系列的拳头和手指配置迅速升起。

尽管这位硬件开发人员感到好奇，但他不禁对这种奇怪的仪式和大量不熟悉的术语感到有些困惑，想知道这些敏捷方法如何可能转化到他的有形硬件开发世界中。“我是不是闯进了一个邪教?!”他自问。

通常，敏捷大师们深深沉浸在软件敏捷的语言和文化中，以至于他们认为硬件团队必须采用完全相同的仪式、角色、工具和语言，才能真正“成为敏捷”。讽刺的是，敏捷宣言的第一原则就是，“个体和互动高于流程和工具。”我认为我们可以在此基础上进一步声明，“个体和互动高于流程、工具、仪式和教条。” 虽然就语言、会议格式和特定活动达成一致，以建立敏捷心态和系统化的工作方式对于成功都至关重要，但采用Scrum或软件敏捷特有的具体仪式和词汇却不是。硬件团队必须审视敏捷元素、仪式和角色的目的和意图，确定每一个如何最好地满足他们的需求。

桥接敏捷与硬件的鸿沟

在您考虑敏捷方法是否适合您的硬件和电子开发工作时，那些出于好意的敏捷大师们传播的传统“智慧”往往在指导物理产品开发所需的更细腻、适应性方法方面不尽人意。在硬件中成功实施敏捷的路径涉及到灵活性、前期准备、迭代规划以及致力于在最短的时间内汇聚到尽可能最有价值的解决方案的认真方法的深思熟虑的融合。 

在我们三部曲系列的最后一部分中，我们将进一步探讨如何利用为电子硬件开发修改后的敏捷方法的优势，同时维护敏捷方法论的核心原则。你对深入探讨这个话题感兴趣吗？观看网络研讨会！