我取得了巨大的成功，例如 快速的开发周期和持续的集成。

但是，由于嵌入式软件编程的特定问题，我认为结对编程或持续的客户沟通不太有用。

你怎么看？ 嵌入式软件开发中最有用的敏捷实践是什么？

我将不同意。我已经做到了，大约10年前，我与人共同创立了一家专注于嵌入式的敏捷教练公司(我们不再是一家公司，但该网站仍然拥有许多有用的资源)。我最近帮助另一家公司为他们的嵌入式项目采用了敏捷，并且对他们来说效果很好。

对于嵌入式软件而言，诸如短迭代，结对编程以及与客户频繁交流之类的敏捷实践显得尤为重要，因为这涉及的风险更大，这既是因为嵌入式系统通常在现场更难/更昂贵地进行更新，又是因为它们经常被使用。在关键任务应用中。

对于结对编程，如果您的公司只有一个人了解软件组件的第一件事，那就是巨大的风险，结对编程是进行廉价知识转移的一种好方法。两位开发人员都不必是代码那部分的专家。您可以拥有一个主要的，没有一个次要的。次要合作伙伴可以在程序结构，比较设计决策，确保适当的测试和文档编制等方面提供帮助。当然，每个开发人员有时都必须是主要的，而其他时候则必须是次要的，以使交叉培训有效。这也是使新开发人员加快产品开发速度的一种非常有效的方法。

最后，客户关心的是功能和计划，而不是代码。嵌入式不会改变这一点。炫耀您到目前为止拥有的东西以及下一步打算做什么，可确保您正在做应该做的事情。

嵌入式软件开发与普通软件开发没有什么不同，因此您可以使用发现有用的每种敏捷实践。

关于成对编程，我将其视为类固醇的代码审查。如果您的公司负担得起足够的软件工程师，我看不出为什么不能将其用于嵌入式软件开发的原因。

顺便说一句，在"嵌入式??软件编程的特定问题"下，您究竟考虑什么？我没有非嵌入式软件开发的经验，也看不出会有什么不同。

对我而言，敏捷在许多应用中的价值并不明显。

许多应用程序，包括嵌入式应用程序，通常都包含基于标准的协议或技术。您下载或购买该规范，实施该规范，进行测试，然后完成。我每天会站着做什么："嗯，今天我阅读标准的第1至9页，明天我打算阅读第10至17页"。基于标准的开发如何从敏捷中受益？快速响应不断变化的客户输入，嗯，没有。标准每天都不会改变。

如果敏捷软件确实意味着"培训"，那么就适合配对编程。如上所述，除非您负担得起工程师数量的两倍，否则工程师之间可能会有不同的特定技能。在大型组织中，许多工程师具有重叠的重复技能，也许您可??以有效地配对工程师。在较小的组织中，这是如何工作的？除非它实际上是配对训练，否则还可以。听起来很贵。

通常，仅主机或部署最少数量的首过功能就需要大量的基础结构。我应该如何测试嵌入式飞行控制器或汽车发动机控制器的驱动开发？仅为了使基础结构就绪就可以主持测试，就需要花费多年的精力。我当然不希望其余的设计师和工程师闲着闲逛，等待测试基础架构，以便他们能够进行TDD。我需要标准驱动的开发，同时还要等待许多组件。