Project management 嵌入式项目和敏捷——你可以/应该用硬件来实现这一点吗？

硬件设计团队可以通过什么方式使用迭代和一般敏捷实践来设计电路板

例如：

• 硬件团队是否应与项目团队整合
• 硬件组如何安排迭代工作？使用故事
• 由于PCB/电路板旋转的成本，敏捷团队是否可以先做一个部分功能板，然后继续添加新硬件以支持每个旋转的新功能
• 有没有办法让硬件与软件“持续集成”？每天

---

是的，敏捷适用于硬件公司（有点），它被认为是敏捷方法学的先驱（我想看板也是从那里来的）

我刚刚开始阅读关于scrum/agile和朋友的文章，所以我是从我的想法而不是从这里的经验中说的：

• 硬件组是否应与项目团队整合？
  看不出有什么理由不这样做。如果硬件ppl是开发的一部分，他们应该是项目团队的一部分
• 硬件组如何安排迭代工作？使用故事？
  故事只是任务的另一个名称，对吗？所以通常开发会分解为任务，我看不到硬件和软件开发之间的区别
• 由于PCB/电路板旋转的成本，敏捷团队是否可以先完成部分功能板，然后继续添加新硬件以支持每次旋转的新功能？
  您只需要将软件开发与硬件的发展同步。顺便说一下，在软件团队验证之后，hw任务应该移动到完成状态。伊姆霍
• 有没有办法让硬件与软件“持续集成”？每日？
  我认为集成应该是事件驱动的，类似于在软件世界中提交到存储库的东西应该触发集成/回归测试。每天在我看来似乎有点过分，除非你每天都能完成一些事情。如果没有其他功能模块完成，则没有理由运行测试

  ---

正如原问题中所提到的，在着手进行迭代硬件设计时，最大的问题之一是旋转的成本。 显然，成本将取决于硬件的性质（例如，电路板大小、电路板复杂度、组件成本、加载成本）-但是如果您有一个复杂的电路板，那么进行大量迭代的成本将是令人望而却步的

虽然可能会将硬件特定部分的设计细节留给以后的迭代，但很可能您必须从一开始就适应这些部分（例如，I/O分配、pcb不动产分配），这将再次使硬件迭代变得困难

在某种程度上，这取决于你所说的硬件。如果硬件团队负责开发所有驱动程序和硬件测试代码，那么情况就不同了。他们没有理由不能以迭代的方式向软件团队提供特性，这也意味着他们应该（必须？）成为项目团队的一员

同样，根据您正在开发的硬件类型以及软件将用于与之对话的接口，设计部分功能板可能会很有用。如果该电路板以允许调试和验证的方式公开所有接口，则该电路板将最为有利——这样，在真正的硬件出现之前，低级别例程至少可以进行部分测试。 但是，只有当完成真正的硬件所需的时间令人望而却步，并且开发版本所需的时间要少得多时，这才是值得的。否则，只需购买真正的硬件并节省成本

持续集成在原则上是一个很好的理想，但是实用性将由您正在开发的硬件类型决定。 如果您的硬件适合自动测试，那么这是一个很好的方法。关于如何实现这一点，请参见问题。

---

（顺便说一句，可编程逻辑，如FPGA，应始终持续集成）

而且大多数硬件都是迭代开发的。所谓的偶然迭代来自于试图实现完美的硬件，但没有成功，需要新的迭代

通过思考敏捷并采用众所周知的软件敏捷世界中的方法，我们可以计划并执行硬件迭代，利用我们将进行不止一次迭代的事实。这弥补了集成设计更有效的总体计划，其中完整的产品可以提前交付给客户，真正的客户反馈可以放在硬件设计的循环中

我同意成本效益比纯软件设计更具挑战性，需要更仔细地规划，但包括硬件在内的最先进的产品开发将从迭代增量开发中受益匪浅