我们尝试在目前的工作中进行敏捷开发，并且在很大程度上成功了。主要的问题似乎是项目的开发人员总是在冲刺开始时就等待需求，并急于在结束时放弃一切。交付需求的业务分析师始终在不停地工作以完成需求。

编辑：添加信息：
我们正在定制COTS应用程序以供内部使用。我们的"用户故事"仅包括我们将在特定的sprint中自定义应用程序的哪一部分，以及内部要与哪些系统集成。与不同系统的集成通常可以很好地进行，因为我们可以立即开始进行工作。 "自定义x屏幕"是主要的问题领域，因为开发人员无法对此做任何事情。我们必须等到从广管局获得要求后，才能真正做任何事情。

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

解决方案

不要等根据最低要求构建原型，并尽快从产品所有者那里获得反馈。如果我们可以向他们展示切实的内容作为起点，那么他们经常不知道他们到底想要什么，那么我们更有可能获得有用的反馈。而且，一旦我们对实际需求有了更好的了解，我们可能会从开发原型中获得很多见识。

在以前的职位上，我们通过要求业务客户提前一周左右来解决这一问题。当然，这与对敏捷的一些严格解释背道而驰，但它使事情变得如此简单。我们将使测试和业务都离开发工作一周或者两周，因此，当开发人员进行迭代2时，测试将对IT1产生的结果进行工作，而业务对IT3进行工作。始终将优先级放在积极的开发上，因此，如果故事特别灵活(有时，企业必须在迭代过程中花很多时间来修改内容)，有时它就无法解决，但总的来说效果很好。

更新以回应提问者更新

在我看来，那些人并没有真正独立于故事，也许BA团队需要重新评估他们如何编写故事。我的意思是我们无法通过自定义X屏幕实现"讲述故事"。从理论上讲，故事应类似于"当用户转到屏幕X时，他们应该能够修改(并保存)floozit"

听起来，BA可能没有及时向我们传递有关Sprint的用户案例。

我认为我们所说的没有sprint计划会议。

鉴于Scrum的一大宗旨是开发团队对每个sprint的工作承担责任，这听起来对我来说不太敏捷！ (-：

除了短距离冲刺之外。

如果我正确理解情况，那么学士学位就落伍了。我们可以尝试两种方法。

• 尝试较小的sprint或者较小的需求块。无论哪种方式，广管局的工作都应该更加简洁和可管理。
• 进行重做或者南瓜压榨。这应该给广管局一些时间来领先。

但是，如果问题在于广管局需要在提出更多要求之前先"了解"先前的要求，那么我们会遇到更大的问题。 :)

好吧，以下几点可能会有所帮助
在SCRUM流程中，有一个产品负责人的概念，该角色是猪角色，它代表客户。因此，我们可以邀请PLM或者客户的主要联系人参加SCRUM会议。这将使客户对流程有所帮助，并使他们与我们"一起"实现目标
对客户的每周构建可能会有所帮助。因此，每周下降的基本思想是向客户显示"进度"。因此，如果几个星期都没有进展，这将引发一个问题："为什么？"然后我们应该能够解释说这是由于需求最终确定的缺乏。

希望这可以帮助

"用户故事"是未来对话的占位符，因此请站在客户面前询问他们；如果那是广管局的工作，请开火;-)

用户故事不完整。 "自定义X屏幕"是一项任务，它没有描述任何要求或者完成条件。用户故事应类似于"允许Nancy查看库存中某个项目的相关采购订单"之类的内容。然后将其分解为可以进行冲刺的任务。

广管局开发出可行的用户案例后，将其添加到产品待办事项列表中，对其进行优先级排序，并为最重要的待办事项项目计划冲刺。广管局应该开发用户案例，并独立于冲刺添加到待办事项列表中，从而不会阻止我们。在sprint期间，任务已完成，并且用户故事没有更改。发布后，客户会提供反馈，这些反馈会随着更多的用户案例而进入产品积压。

我看到一些解决方法：

选项1，在SCRUM下，我们应该有一个产品所有者来管理产品积压，该积压应该包含对软件功能的请求。如果功能包含诸如"自定义屏幕X"之类的含糊不清的内容，并且我们决定将其添加到sprint中，则sprint任务应该是具体的，分解的任务，我要说的其中一项任务是"定义屏幕的要求X'。

在每日SCRUM期间，当我们向每个团队成员询问三个问题时，承担该屏幕mod任务的开发人员将说"我被阻止等待BA的要求。"，Scrum管理员会尽其所能让它前进。

我认为选项2是，只有在对项目进行足够好的定义以至少可以进行一些生产性工作之前，它们才进入产品积压。我们都知道需求会发生变化，但是重点是我们应该有足够的起点。

简单。

让自己思考超出Scrum严格的规则，然后回到精打细算的根源：
http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/
http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/
http://www.infoq.com/articles/hiranabe-lean-agile-kanban

相信我，一旦顺其自然，我们将永远不会回头。