您如何处理嵌入式系统中Scrum的非功能性工作？

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

前四个冲刺是：

• 获取RTOS和运行
• 创建编写网络和串行驱动程序的任务
• 编写按钮，通讯等中断例程
• 编写主要的数据库类和方法
• 编写串行调试菜单

这些任务大多数都不适合用户案例。实际上，进入整个系统的唯一接口是内置在sprint 3中的串行调试菜单，因此在sprint的末尾没有任何内容可以说明。甚至串行菜单也只供内部使用，而不是最终用户。尽管如此，我仍然想通过Scrum跟踪和管理这些开发活动。

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

其次，您如何处理发布和测试？对我们来说，这是真正的痛苦，因为测试人员没有硬件调试器，因此我们必须构建代码的闪存版本，并将其刻录到开发板上进行测试。测试人员在技术上不如开发人员那么敏锐，并且通常需要大量支持才能使它们在早期阶段正常工作（重置板子，连接串行通信等），甚至理解输出。

最后，关于完成的定义，只有在所有故事完成之前，冲刺才能完成。在测试人员验证之前，所有故事都是不完整的。无法避免“浪费”开发人员的时间给测试人员。换句话说，如果冲刺中的最后三个用户故事需要五天的时间进行测试，则必须在冲刺结束前五天对它们进行编码和单元测试。开发人员应该做什么？停止工作？

我正在开玩笑，但尝试遵守规则确实是一个问题。现在，我可以遵循规则了，但是我遇到的问题是，如果在测试之前无法将所有工作标记为已完成，它将使我的所有燃尽指标变糟。

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

您正在不兼容恕我直言的产品上使用方法。

用大多数人定义敏捷的方式，所有工作都可以根据优先级的变化，可重新排序或可替换的方式进行协商。

大多数人定义瀑布的方式是，从一开始的大量架构工作开始就按顺序安排工作。

您上面列出的任务对我来说似乎是非常瀑布。它们必须处于一定顺序，并且不能协商。

我并不是说您必须遵守任何人对任何流程的看法，但是至少对于这些任务，您似乎对我而言不是敏捷项目。试图将其折磨成敏捷过程，充其量是最好的选择。

如果项目的其余部分非常适合敏捷，那么我不会太担心初始设置是否合适，但是您提到RTOS和开发板的事实使我怀疑整个事情在其他方面会更好就像瀑布（一长串不可移动的依赖关系）。

好的，所以我对构建嵌入式系统一无所知，但是据我所知，没有任何东西会使Scrum不适合这种开发。担心没有真正面向用户的功能很容易陷入困境，因此很难与拥有用户一起编写“用户故事”。除了用户故事不是Scrum的真正组成部分以外-它们通常与Scrum一起使用-但实际上只是作为一种工具。

Scrum的一部分是提供完整功能的想法，这些功能经过全面测试，并可能在每个Sprint的实时环境中实现。当您从头开始进行任何类型的项目时，可以在Sprint 1中交付的任何功能的实际价值都非常小。这是因为每件微小的事情都需要大量的基础设施才能使其正常运行。但关键是您只需要构建足够的基础结构即可使每个功能正常工作。然后在添加更多功能时进行构建。

这样做的想法是，您不必花费数月的时间来构建无法从系统外部检测到的基础架构。为什么？因为直到您构建出实际可以完成的工作，您才不知道基础架构到底是什么。在构建系统的实际功能时，您会学到这些。如果您在一开始就构建基础架构，那么您在对系统的了解最少的时候就在构建它。

如果您沉迷于编写用户故事，那么请记住，用户不必是人。因此，您可以这样写：“作为CMOS中断处理程序，当磁通电子压缩机发出无源旁路欠压信号时，我需要能够检测到单栈堆栈调制标志的状态”。绝对不要写“作为开发人员...”的用户故事。

您在非常特定的区域中使用Scrum，并且在每个步骤中都违反了假定的过程。您的问题可能应该是：是否存在另一种更适合我的环境的敏捷方法？简而言之，如果您的环境不允许，很难帮助您更好地完成Scrum。我在您的描述中看到的问题：

• 没有可被视为基础结构任务的可证明任务。如果您需要几个冲刺来完成某些不被视为业务价值的事情，那么您的用户故事可能定义不正确。如果您需要构建工具或其他任何东西才能交付业务价值，则可以将产品分为两个部分/版本-构建工具和构建业务价值。在这种情况下，由于为开发人员创建了工具，因此您的用户故事“作为开发人员...”将完全有效。

  这里的问题是如何与客户进行沟通，因为他/她在第一版中的参与为零。如果客户没有任何商业价值，他们如何参与？产品负责人如何定义业务优先级？

  我认为这里的主要问题是，这不适合Scrum。Scrum尝试首先交付最重要的业务功能，但是您需要两个月才能交付第一个。Scrum和整个敏捷都接受了变更-如果在交付第一个功能后客户要求进行一些变更并返回到您所有初始冲刺中，该怎么办？

• 测试。另一个失败是因为Scrum中的团队被视为一组跨职能成员。这意味着每个人都进行开发和测试，因此在您的最后一点（或至少不超过五天）中没有描述任何情况。这并不意味着不能有单独的QA来进行一些更复杂的测试，但是团队必须提供已经过测试/验证的功能。在您的情况下，实际上看起来Scrum不是您所需要的。您需要单独处理的开发和测试以及在它们之间传递功能。