在使用像SCRUM这样的迭代敏捷开发方法时，如何避免等待需求？

Question

我们试图在我目前的工作中进行敏捷开发，而且我们在很大程度上是成功的。主要的问题似乎是，项目的开发人员总是在sprint开始时等待需求，并急于在最后完成任务。交付需求的业务分析人员总是不停地工作，以完成需求。

编辑:附加信息：我们正在为我们的内部使用定制一个COTS应用程序。我们的“用户故事”只包括我们将在特定的sprint中自定义应用程序的哪个部分，以及我们将在内部集成哪些系统。与不同系统的集成通常运行得很好，因为我们可以马上开始处理这个问题。“customize屏幕”是主要的问题区域，因为开发人员无法从中做任何事情。我们必须等到从巴斯那里得到要求后才能真正做任何事情。

编辑:更多的洞察力/困惑：，我想知道问题的一部分是否在于正在定制的屏幕已经存在，因为这是一个正在大量定制的COTS产品。人们建议用户故事应该遵循“制作一个做X的屏幕”的思路。已经做好了。也许没有一种很好的方法来满足这些需求.也许这需要一个全新的问题。

Answer 1

别再等了。根据您所拥有的最低需求构建一个原型，并尽快从产品所有者那里得到反馈。通常情况下，他们不知道他们到底想要什么--如果你能向他们展示一些有形的东西作为起点，你就更有可能得到有用的反馈。此外，一旦您对实际需求有了更好的了解，您可能已经从开发您的原型中获得了很多洞察力。

Answer 2

如果我正确地理解了你的处境，那么落后的就是基础。有两件事你可以试试。

1. 尝试小的冲刺或较小的需求块。无论哪种方式，巴斯的工作都应该更加简洁，并且managable.
2. Take是对返工或bug压缩的一种交互。这应该让巴斯有时间走在曲线前面。

但是，如果问题是在提出更多需求之前，基本需求需要在“野性”中看到之前的需求，那么您就有了更大的问题。:)

Answer 3

在之前的一份工作中，我们要求我们的商业客户提前一周左右才能做到这一点。当然，这与一些对敏捷的严格解释不同，但它使事情变得如此简单。我们会让测试和业务都离开发工作一周或两周，所以当开发人员进行迭代时，2测试是针对IT1的测试，业务是在IT3上进行的。优先级总是放在积极的开发上，所以有时候如果一个故事特别灵活的话，它就会崩溃(也就是说，业务必须花费大量的时间来修改迭代过程中的事情)，但总的来说，它运行得很好。

更新以响应提问者更新

在我看来，这些人并不是真正独立于自己的故事，也许英国队需要重新评估他们是如何写故事的。我的意思是你不能用自定义X屏幕“讲述一个故事”。理论上讲，故事应该是“当用户进入X屏幕时，他们应该能够修改(并保存)洪水”。