嵌入式软件开发的敏捷实践

Question

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

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

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

Answer 1

我不得不反对。我已经做到了，大约10年前，我共同创立了一家专注于嵌入式的敏捷教练公司（我们不再是一家公司，但the website is still up拥有一些有用的资源）。我最近帮助另一家公司为他们的嵌入式项目采用了敏捷，并且它对他们非常有用。

敏捷实践，例如短迭代，结对编程以及与客户的频繁通信，对于嵌入式软件来说更加重要，因为存在更多的利害关系，因为嵌入式系统通常更难/更昂贵在现场，因为它们经常用于任务关键型应用程序。

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

最后，客户关心的是功能和计划，而不是代码。嵌入式不会改变这一点。炫耀到目前为止你所拥有的东西以及你打算做什么，可以确保你正在按照自己的意愿行事。

Answer 2

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

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

顺便问一下，您在“嵌入式​​软件编程特定问题”中究竟考虑了什么？我没有非嵌入式软件开发经验，也看不出它有什么不同。

Answer 3

在我看来，敏捷在许多应用程序中的价值并不明显。

许多应用程序（包括嵌入式应用程序）通常包括基于标准的协议或技术。您下载或购买规范，实施规范，随时测试，然后就完成了。我每天站起来会怎么做，嗯，今天我读了标准的第1到第9页，明天我打算阅读第10到17页和第34页。基于标准的开发如何从敏捷中受益？快速响应不断变化的客户意见，嗯，没有。标准不是每天都在变化。

如果敏捷软件真的意味着＆＃34;培训＆＃34;然后配对编程适合。正如上面所指出的那样，除非你能够承受的工程师数量增加一倍，否则你的工程师可能会拥有不同的特定技能。在一个拥有许多重复技能重叠的工程师的大型组织中，您可以有效地配对工程师。在一个较小的组织中，它是如何工作的？除非它实际上是配对训练，那么好吧。听起来很昂贵。

通常需要大量的基础设施才能托管或部署最少量的首次通过功能。我如何为嵌入式飞行控制器或汽车发动机控制器进行测试驱动开发？需要多年的努力才能使基础设施到位以进行测试。我当然不希望我的其他设计师和工程师闲置等待测试基础设施，以便他们可以做TDD。我需要标准驱动的开发，同时等待许多部分聚集在一起。