嵌入式项目和敏捷——你可以/应该用硬件来实现这一点吗?[闭门]

我刚刚开始阅读有关scrum/agile和friends的文章,所以我在这里是从我的想法而不是从经验中说的:

• 硬件团队是否应与项目团队整合?
  看不出有什么理由不这样做。如果硬件ppl是开发的一部分,他们应该是项目团队的一部分。
• 硬件组如何安排迭代工作?使用故事?
  故事只是任务的另一个名称,对吗?所以通常开发会分解为任务,我看不到硬件和软件开发之间的区别。
• 由于PCB/电路板旋转的成本,敏捷团队是否可以先做一个部分功能板,然后继续添加新硬件以支持每个旋转的新功能?
  您只需要将软件开发与硬件的发展同步。顺便说一下,在软件团队验证之后,hw任务应该移动到完成状态。依我拙见
• 有没有办法让硬件与软件“持续集成”?每日的
  

是的,敏捷适用, TOYOTA 是一家硬件公司,它被认为是 LEAN 以及丰田的方式)敏捷方法学的先驱(我认为看板也来自那里)

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

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

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

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

但是,只有当完成真正的硬件所需的时间令人望而却步,并且开发版本所需的时间要少得多时,这才是值得的。否则,只需购买真正的硬件并节省成本。

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