功能需求不足是否敏捷？

如今，每个人都希望变得敏捷。在与我合作的每个团队中，敏捷的形式都不同。有些事情很常见-例如日常站立或计划，但其他部分则有很大差异。

在我目前的团队中，有一个细节令我感到困扰。缺乏功能要求。不仅没有书面形式的期望，而且在任务中模糊地定义了需要完成的工作。

该项目的目标是使用新技术重写旧系统。旧系统也没有任何合理的文档。当然，最新的不存在。企业主对需求的描述是-让我们在新实现中以与旧实现相同的方式进行。似乎合理，但事实并非如此。旧系统是一种意大利面条式代码，从中提取业务需求非常昂贵。看来情况对计划产生了负面影响。当然，在新的实现中容易出错和出错（省略一些细节）。

因此，我在想-在重写旧系统的情况下，没有业务需求真的很敏捷吗？

缺乏功能需求是否敏捷，这都是灾难的根源。当您不知道该系统如何工作时，您将无法重建该系统。

您需要告诉业务所有者您不知道旧系统如何工作。

最好的选择是与业务所有者或一些有经验的用户一起工作，以了解正在运行的业务流程，并开发自己的验收测试。如果您可以与某些最终用户一起使用，则可能会获得有关旧系统如何工作的更多反馈。

否则，您需要在非生产环境中进行一些探索性测试，以收集自己的需求。很多时候企业主说“使它像旧的一样工作”时，他们受到时间的限制，无法像企业主那样帮助您。您需要一些经验丰富的用户的专业知识，或者您需要进行大量的手动测试才能了解旧系统的工作原理。

通知企业所有者，缺乏需求和对旧系统的了解将极大地增加重建时间，大约是原来的三倍甚至更多。面对时间表和成本增加的问题，企业主将为您提供更快地收集需求所需的专业知识，或者决定此时进行重写在经济上不可行。

您将获得以下之一：

• 正确的要求和更快的开发周期
• 是时候收集需求并重建软件了
• 一个不会在您的职业生涯中成为黑标的新项目

敏捷不会改变对功能需求的需求，但通常会改变您收集需求的方式。非敏捷方法是让某人经过一个漫长的过程，然后为您提供某种包含系统所有要求的文档。

收集需求的敏捷方法是共同努力，为系统的一小部分增量指定需求，构建它，然后获取反馈并进行下一个增量。在您遇到使业务负责人无法启动流程的情况下，我首先可能要花半天的时间探索您下一步要使用的旧系统的一部分，并生成有关需求的问题列表。

然后与您的企业主坐下，向他们提问。有些问题对他们来说很容易回答，有些问题使您通过查看代码更容易回答，而有些问题则很难以任何一种方式回答。将困难的问题分成越来越小的部分，直到您可以回答为止。

目的是使您的问题得到足够多的回答，以便构建内容，获取反馈并重新启动该过程。请记住，您所做的更改越小，反馈周期越短，如果您做错了什么，那么事关重大。

捕获需求是任何（成功的）软件项目的重要组成部分。但是写需求规范不是。

• 以文档为中心的方法最终可能像一场“中国窃窃私语”游戏：主题专家提出要求，分析师写下要求，开发人员尝试编写符合分析师描述的内容，最终用户感到困惑，因为软件没有解决他们的问题。

  敏捷技术建议开发人员应直接从主题专家（通常是最终用户）那里收集需求。有多种技术可以做到这一点，例如，与SME讨论示例场景。开发人员擅长发现极端情况，并要求SME阐明该软件在该极端情况下的行为。

• 敏捷团队可能不会先收集所有需求（因此会冒很大的误解），而可能会从一小部分需求开始，构建原型，然后使用该需求收集反馈以进行下一次迭代。

• 随着对需求的理解随着时间的推移而变化，静态的需求规格说明将过时。如何预防？

  通过将需求表达为可运行的测试。事实证明，“可读规范”和“可运行测试”不是排他性的概念，但最终可以成为一个文档。例如，BDD空间之外的Cucumber和其他想法在这里可能会很有帮助。

在您重写旧系统的情况下，原始系统可能是需求的重要来源。但是哪些方面是相关的？它的利基功能是否还在使用？为了兼容，必须重新实现哪些错误？与最终用户交谈通常没有解决方法。

拥有工作系统对于测试新软件也很有帮助，但这与任何敏捷问题无关。

请注意，截止日期迫在眉睫的固定范围，固定时间的项目是敏捷的对立面。正常的敏捷方法是选择一小部分功能，然后首先交付，然后进行迭代。最重要的事情首先完成，次要的事情之后（或永远不会）完成。如果一切都很重要并且必须尽快完成，那么什么都不重要，项目就不可能交付任何东西。

在您的情况下，缺乏需求不是敏捷功能，而是组织功能障碍的平均情况。如果您希望项目成功，那么您将需要找到一种方法来消除这种功能障碍。例如，敦促业务所有者不要编写完整的需求文档，而应尝试召开会议，在会议上解释最重要功能的需求。您可以查看旧系统以了解详细信息。然后实现该功能并进行迭代。

这是我们的方法。我们与业主交谈。我们与经理们进行了交谈。我们与从事这项工作的用户进行了交谈。我们坐在用户的桌子旁看着（问问题）时发现的东西非常有用。经理知道我们应该与哪些用户坐下来。

我们发现系统的某些部分确实运行良好，并且我们可以轻松编写足够的要求来开始设计，编码和测试用例等等，但是其他部分则存在一些麻烦的解决方法，这些都是地板上的用户在使用，经理和业主不知道的。对于旧系统的这些部分，我们回过头来讨论了工作流和流程，然后确定了较小的任务，从而将它们分解为敏捷方法所需的单元。

因此，尽管敏捷可以快速启动系统的某些部分，但其他部分则需要更多的思考和文档记录才能开始。

在敏捷框架中收集需求，没有人提到用户故事？用户故事本质上是软件应具备的功能的高级定义。通常，来自企业或最终用户的任何反馈或请求都可以写为用户故事。...您可以将接受标准视为支持用户故事的功能要求。

这个问题暗示了敏捷运动出了什么问题。问这个问题的人没有错；我一直陷入这个陷阱，因为多年的企业生活训练了我。

我正在谈论的陷阱是，认为有一种规定的正确的敏捷方法可以做事情。这可能是因为人们认为敏捷存在。你不能做敏捷任何比你更可以做到务实。

没有“功能规格”之类的东西听起来令人担忧，但事实并非如此。您需要多少细节开始？安全性和性能是显而易见的，并且一直贯穿始终。否则，它是期权定价引擎还是时钟应用程序？

是否会持续发布，讨论，学习，追溯和更改软件？你是构建软洁具或硬件？

在瀑布式过程中工作的开发人员通常直到下一个阶段才参与其中，这是一个问题。早些时候或从一开始就让他们参与其中意味着他们对不清楚，不确定和半生不熟的事物不屑一顾，这似乎使长期的开发人员感到不安，而事实上，他们的工作之一是问一些问题，例如“什么是我们要构建的东西的功能需求？”

确定计划中的漏洞并不是要发现故障，而只是软件开发。

因此，我喜欢盖伊的答案。