问哪种软件开发模型对高度依赖硬件团队的软件团队最有效？

EN

这实际上取决于您的硬件团队将如何交付有用的构件，您的软件团队可以使用这些构件进行开发，以及如何设置这些团队来相互通信。

通常，您会发现硬件团队将构建一个产品，并将其带到一个原型阶段进行测试，只有这样，软件团队才能从硬件团队获得任何类型的需求文档。不用说，这并不总是最好的方法，因为软件通常在开发过程中非常晚，而且您通常发现自己别无选择，只能使用基于瀑布的方法。从硬件团队的角度来看，如果他们突然需要改变一些东西，软件团队就不需要修改他们的软件了。当然，这里的问题是，您的普通硬件人员需要以这种方式开发产品，并且期望任何对他有利的东西都可以帮助软件团队。

作为另一种选择，如果您的硬件团队正在构建产品并在软件需求进行更新时进行更新，更好的是，如果软件团队在计划和模拟每个硬件功能的早期就涉及到软件团队，那么您就有机会让软件团队以更加敏捷的方式工作。当然，我指的是硬件团队是客户，并给软件团队列出了需要在软件中解决的问题。软件团队可以与他们的客户讨论每个需求的相对优先级，一旦硬件原型准备好，软件可能会以早期发布的形式出现，并且可以用来帮助测试硬件。如果需求发生变化，软件团队将有希望在软件运行过程中灵活地更改软件，并且能够在硬件设计交付原型之前向硬件团队提供早期反馈。软件团队在项目初期还可以直接访问客户，这意味着他们可以在等待硬件测试的同时，更好地了解他们需要模拟什么--以及如何做--。

现实地说，你不会找到一种理想的方法，这种方法是现成的，我可以保证，不管你选择采用哪种方法，或者开发哪种方法，你都会做很多调整。真正的问题是，您希望尝试使团队之间的同步更容易管理，并意味着您需要找到一种方法来尽早增加两个团队之间的联系和输入量，即使这样做看起来“浪费”或“违反直觉”。这在我目前工作的公司里是个大问题。我们的欧洲“家长”正在努力解决这个问题，而奥兹的团队似乎能够让事情运行得更顺利，这实际上是因为让软件团队更早地参与硬件开发的设计和仿真阶段。

我可能有偏见，在大型软硬件产品开发团队的硬件方面做了更多的工作。如果硬件架构或设计错误，则修改硬件的成本可能很高。通常，硬件设计中的错误是非常昂贵的，这意味着取消整个项目。修复芯片掩码错误的成本可能超过数十名工程师的年薪。因此，我认为软件团队在开发周期的第一个50%+中的主要目的是确保硬件团队不会失败。这可能意味着一开始就忘记了最终的应用程序代码及其设计，只是在硬件体系结构和性能模拟上工作，帮助硬件团队完成和验证其设计的工具，以及测试和练习最早的部分功能硬件原型的所有必要组件的代码。

期望敏捷，不仅是关于客户规范，还包括硬件平台中各种令人惊讶的怪癖/错误，在硬件平台上，软件解决方案对计划的影响可能远远小于硬件旋转。

敏捷的主要租户之一是“早期失败”。有了硬件，这再正确不过了。大规模生产硬件是非常昂贵的。此外，物理硬件不能像软件那样简单地“修补”。加剧这些问题的是，硬件团队在实践中往往比软件团队更少地面对客户，并且倾向于习惯于“大爆炸”的开发模式。

由于这些原因，如果不尽快发现硬件问题，通常情况下，订单的价格要比未能及早发现软件问题要贵得多。客户期望软件更新，如果他们必须处理硬件召回，他们可能会完全停止与您合作。

总之，在软件和硬件并行开发过程中，不考虑和提前准备硬件问题是开发模式面临的最大挑战。

你绝对必须预见失败。早点拿个原型。使用原型进行开发。希望这是个失败。从失败中吸取教训。冲洗一下。重复一遍。确保每个人都期望根据利益相关者的反馈修改/批改/重新设计硬件原型。