嵌入式项目中的敏捷需求收集

Question

我正在从事一个项目，在这个项目中，我们为一个基于Linux的设备开发了一个嵌入式应用程序，它处理来自不同传感器的数据，并将它们可视化给最终用户。我们尝试使用Scrum过程，但遇到了与我们和管理团队对需求工程的感知有关的不同困难。

基本上，Scrum推荐在产品负责人优先排序的待办事项中维护用户故事。Scrum假设在开始时没有“需求冻结”或描述项目的单一文档。当利益相关者认为他们有必要拥有一个“可发布”的软件版本时，用户故事可以添加“按需”。

另一方面，由于与硬件的紧密耦合，嵌入式系统需要对不同的系统特性进行预先的规范。

• HW / SW接口(例如主CPU和FPGA之间的共享内存)
• 数据格式，什么以及如何以什么频率存储？
• 硬实时需求，系统必须对某些事件作出多快的反应
• 与其他学科的互动，如。HW，光学，力学

在嵌入式系统中以轻量级(敏捷)的方式处理需求工程的最佳实践是什么(与汽车过程相反)？

Answer 1

Scrum不关心需求冻结与否。如果从积压中的100个从未改变过的故事开始，或者有更多的故事一直被添加/更改，Scrum同样工作得很好。Scrum应该是一个迭代过程，它需要一个与传统瀑布模型完全不同的思维方式。

从技术上讲，使用Scrum，您可以使用几个sprint，其中所有的用户故事都是为foo收集需求，为bar收集需求等等。不过，我确实建议不要这样做，因为当您对构建的内容了解最少时，它将花费大量的精力收集每一个需求。

我建议的是优先处理所有您知道需要的高级功能，然后以最高优先级开始，只收集单个功能的需求，然后开始实现它们，然后在您认为已经完成当前功能时才转向下一个功能。之所以这是一种更好的方法，是因为在最坏的情况下，它与另一种方法相同，但在大多数情况下，它将节省整个工作。如果您在使用此方法进行开发期间对最高优先级的特性进行了任何假设/早期的需求更改，则不会产生其他影响的需求的连锁反应，因为您还没有创建它们，相反，当您获得相关特性时，您已经知道了许多事情，因为系统的部分已经存在。

Answer 2

软件团队对硬件规格有任何影响吗？还是完全相反(硬件团队决定低水平的软件接口)？

在后一种情况下，HAL (硬件抽象层)人员必须与硬件团队一起编写低级别的软件界面；GUI团队可以按照自己的速度工作，可能使用Scrum或任何其他敏捷方法。

如果硬件和软件共同发展，它将是一个快速原型项目。重点是最大限度地提高学习率(将-工作和不会-工作)，保持成本控制(明智地使用它，非常清楚地知道，原型意味着大量的丢弃工作，并将加快，使它比典型的项目成本更高)。

在这个网站和其他地方，有很多关于快速原型的问答。

如果它是快速原型，它可能不会是scrum。它在精神上可能仍然是敏捷，但它可能不同于任何主流敏捷框架--因为主流敏捷框架主要面向纯软件、市场驱动的开发。

当然，你必须要“按计划应对变化”，因为硬件和软件共同进化的项目充满了“不会-工作”，所以它被强加在你身上。

scrum有所谓的“尖峰”，但是如果一个项目充满了尖峰，你通常不会称它为Scrum。而不是固定的时间盒冲刺，您将有里程碑，其中每个里程碑有一些可交付的，里程碑结束，只有当这些项目交付或有一些项目友好地取消了利益相关者。

Scrum管理软件可能仍然有效，站立会议总是有效的，等等。

Answer 3

虽然所提出的问题范围很广，但核心问题似乎是：

...Scrum假设没有“需求冻结”....embedded系统由于与硬件的紧密耦合，需要前期规范。

Scrum旨在产生高质量的可交付解决方案增量。例如，它的目的不是最小化返工或缩短生产最终产品的时间。您需要考虑这个优先级是否适合您的环境。