如何采用敏捷方法开发固件/嵌入式系统软件？

我一直想知道如何在大型复杂的嵌入式系统软件（超过100位工程师）中应用敏捷方法。固件开发具有一些独特的特性，这些特性使敏捷开发变得困难（例如，直到开发周期的后期才提供硬件；一旦产品发布，就无法轻松更新固件；等等。）

这种开发的规范是详尽的文档和艰苦的同行评审。您无法获得简单的代码修复，例如重命名没有2-3个签名的变量。（我有点夸张，但这很典型。此外，很多人确实选择捷径，而项目经理甚至批准了捷径，尤其是在面临严格的市场期限的情况下。）

我想听听有关在固件开发项目中采用敏捷方法的任何技巧或指导。

我认为两种技术很关键：

• 为硬件开发一个完整的模拟器或测试环境，以便您可以像拥有真正的硬件一样来开发软件。不要在这里跳过或走捷径：开发一个好的模拟器会有所作为。

• 针对模拟器编写许多单元测试。

一旦这些事情顺利进行了，并且人们相信模拟器和单元测试将提供有关事物如何与硬件一起工作的准确概念，那么采用其他敏捷技术（较短的迭代，不懈的重构等）将变得更加容易。 。

可以将敏捷对涉及多个供应商的开发过程的影响与公司进行JIT时的影响进行比较。

为了交付JIT，公司的每个供应商都必须交付JIT。

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

同样，如果您希望根据敏捷方法开发复杂的产品，则链中的每个子组都应该能够以这种方式工作。

就“增量式”开发而言（也就是15年前的Tracer Bullets），这意味着“核心”将很快发布给驱动程序人员，并且基本的驱动程序可供集成商使用，并且GUI将可以同时开发一个按钮和一个编辑框。

困难的部分是说服来自扎实的前瞻性工程学科的硬件设计师加入我们的修补匠社会。

第二个最困难的部分是找到一种方法，以在需要提前3周订购硬件打印的世界中实现增量开发。我在考虑模拟器，fpga在这里。我不是硬件专家。

如果您愿意放弃增量硬件开发，则可以像在JIT链的边界上那样，预见一种缓冲机制，该机制可以使敏捷团队前进。

我们不要盲目：敏捷也必须处理繁重的流程！不要要求敏捷团队现在在下一个Sprint中将其Java代码库“重构”为Python。仅因为某些部分确实非常稳定，我们才能在它们之上跳动敏捷动作。

敏捷宣言：http : //agilemanifesto.org/

“流程和工具上的个人和交互”

• 满足更多。少推纸。

“通过综合文档工作软件”

• 原型和构建技术很早就经常出现峰值。

• 解决用户的实际问题，而不是继续建立对规格的挑剔遵守。这意味着进化的解决方案。我们必须重新构建它，因为我们再也无法构建它的想法是错误的。计划迭代。使之成为市场营销和推广策略的一部分。

“通过合同谈判进行客户合作”

• 超复杂的变更控制流程只是对客户说“不”的方式。

• 预先锁定所有需求，然后施加变更控制是另一种拒绝的方式。

• 如果您已经计划了多个发行版，则可以更轻松地将需求推迟到更高版本。一旦客户拥有带有嵌入式软件的设备，下一个版本的优先级就会改变。

“响应按照计划进行的转换”

• 尽管复杂的集成需要复杂的计划，但是总的“程序”（或项目序列）不能太早地具体化。

完全敏捷的方法（即Scrum）对于嵌入式系统可能没有意义。

但是，敏捷宣言提供了在不造成简单混乱的情况下允许进行更改的方法。

我对嵌入式系统中的Scrum的问题是，有许多任务要做，尤其是在早期阶段，这是无法证明的。我们从开发板开始，没有操作系统，没有显示器，没有串行通讯，等等。我们没有6个Sprint的显示器。

前四个冲刺是：启动并运行RTOS创建任务编写网络和串行驱动程序编写按钮，逗号等的中断例程编写主要的数据库类和方法编写串行调试菜单

这些任务大多数都不适合用户案例。实际上，整个系统的唯一接口是内置于sprint 3中的串行调试菜单，因此在sprint的末尾没有任何内容可以说明。甚至串行菜单也仅供内部使用，而不是最终用户使用。

当然，我们编写的每个类都具有关联的单元测试，并且我们使用单元测试框架来自动化所有测试的执行。

我们最终写了“用户故事”这样的短语，例如“作为开发人员...”，我不满意，但是在使用Target Process（www.targetprocess.com）时，没有积压的项目的概念，任务或琐事。

我很想听听其他人如何处理这些情况。