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

我不得不反对。我已经做到了，大约10年前，我共同创立了一家专注于嵌入式的敏捷教练公司（我们不再是一家公司，但该网站仍有几个有用的资源）。我最近帮助另一家公司为他们的嵌入式项目采用了敏捷，并且它对他们非常有效。 对于嵌入式软件而言，短迭代，结对编程以及与客户的频繁通信等敏捷实践更为重要，因为存在更多的利害关系，因为嵌入式系统在现场更新通常更难/更昂贵，并且因为它们经常被使用在任务关键型应用程序中。 至于结对编程，如果你的公司只有一个人知道关于软件组件的第一件事，这是一个巨大的风险，结对编程是进行廉价知识转移的好方法。两位开发人员都不必成为该部分代码的专家。你可以有一个主要的，而次要的不是。次要合作伙伴能够提供有关程序结构的帮助，比较设计决策，确保正确的测试和文档等。当然，每个开发人员必须是有时和次要的主要时间，以使交叉有效。这也是让新开发人员加快产品速度的一种非常有效的方法。 最后，客户关心功能和计划，而不是代码。嵌入式不会改变这一点。展示你目前所拥有的东西以及你打算做什么，可以确保你正在努力实现自己的目标。     

嵌入式软件开发与普通软件开发没有什么不同，因此您可以使用您认为有用的每个敏捷实践。 关于结对编程，我将其视为类固醇的代码审查。如果您的公司能够负担得起足够的软件工程师，我看不出它不能用于嵌入式软件开发的原因。 顺便说一句，您在“嵌入式​​软件编程特定问题”中究竟考虑了什么？我没有非嵌入式软件开发的经验，我也看不出它有什么不同。     

对我来说，敏捷在许多应用程序中的价值并不明显。 包括嵌入式应用在内的许多应用通常包括基于标准的协议或技术。您下载或购买规范，实施规范，随时测试，然后就完成了。我每天站起来会怎么做，“嗯，今天我读了标准的第1到第9页，明天我打算阅读第10到17页”。基于标准的开发如何从敏捷中受益？快速响应不断变化的客户意见，嗯，没有。标准每天都不会改变。 如果敏捷软件真的意味着“训练”，那么配对编程就适合了。正如上面所指出的那样，除非你能够承受的工程师数量增加一倍，否则你的工程师可能会拥有不同的特定技能。在一个拥有许多重复技能重叠的工程师的大型组织中，您可以有效地配对工程师。在一个较小的组织中，它是如何工作的？除非它实际上是配对训练，那么好吧。虽然听起来很贵。 通常需要大量的基础设施来托管或部署最少量的首次通过功能。我如何为嵌入式飞行控制器或汽车发动机控制器进行测试驱动开发？需要多年的努力才能使基础设施到位以进行测试。我当然不希望我的其他设计师和工程师闲置等待测试基础设施，以便他们可以做TDD。我需要标准驱动的开发，同时等待许多部分聚集在一起。