logo标签列表

使用迭代式敏捷开发方法如SCRUM时，如何避免等待需求的情况？

agilescrumrequirementsuser-stories
7
我们在目前的工作中尝试实行敏捷开发，大部分情况下我们都成功了。主要问题似乎是项目上的开发人员总是在等待迭代开始时的需求，并在结束时匆忙完成任务。提供需求的业务分析师总是不停地工作以完成需求。
编辑：额外信息： 我们正在定制一个COTS应用程序供内部使用。我们的“用户故事”仅包括特定迭代中将要定制的应用程序部分以及我们将与其内部集成的系统。与不同系统的集成通常运作良好，因为我们可以立即开始处理。但“自定义x屏幕”是主要的问题区域，因为开发人员无法从中得到任何信息。在我们真正能够做任何事情之前，我们必须等到从业务分析师那里得到需求。
编辑：更多见解/困惑： 我想知道问题的一部分是否在于正在定制的屏幕已经存在，因为这是一个被大量定制的COTS产品。有人建议用户故事应该是“制作一个执行X操作的屏幕”。但这已经完成了。也许对于这些需求没有好的用户故事方式……也许需要一个全新的问题。
10个回答
9
不要等待，基于你拥有的最小需求建立一个原型，并尽快从产品负责人那里获得反馈。往往他们也不知道自己想要什么 - 如果你能展示一些具体的东西作为起点，你更有可能得到有用的反馈。此外，一旦你对真实需求有了更好的理解，你可能已经从开发原型中获得了很多见解。
4
如果我理解你的情况正确，那么业务分析师可能是滞后的。你可以尝试两件事情。
1.尝试小规模迭代或更小的需求块。无论哪种方式，业务分析师的工作应该更加简明扼要和可管理。
2.花时间重新整理或修复错误。这应该给业务分析师一些时间来超前发展。
但如果问题在于业务分析师需要看到“野外”中的先前需求才能制定更多需求，那么你就有了更大的问题。 :)
我开始怀疑我们的用户故事是否存在问题，因为它们可能过于模糊或者提前设定。 - Alex Argo
3
在之前的职位上，我们通过要求业务客户提前一周或更长时间来管理这个问题。当然，这与敏捷开发的某些严格解释不符，但它使事情变得更加容易。我们将测试和业务与开发相隔一两周，因此当开发人员在迭代2上工作时，测试正在处理IT1的内容，而业务则在IT3上。优先考虑活动开发，因此有时候如果一个故事特别灵活（即业务需要花费大量时间在迭代中修订事物），它可能会崩溃，但总体效果很好。
更新以回应提问者的更新：
在我看来，这些并不能作为独立的故事存在，也许业务分析团队需要重新评估他们如何编写故事。我的意思是，你不能真正用“自定义X屏幕”来“讲故事”。理论上，一个故事应该是这样的：“当用户转到X屏幕时，他们应该能够修改（并保存）floozit”。
嗯...问题是屏幕已经存在...所以更改的内容大致是“将这个字段移动到这里”或“这个字段需要像XXXXXXXX一样计算，而不是现在的方式”。我们得到的需求文档基本上是一个要为屏幕更改这些内容的大列表。 - Alex Argo
有趣。我的第一反应是为什么不将每个项目都变成故事，即使是非常简单的故事。如果这不可行或只是浪费时间，我会采纳其他人所说的，要求业务分析人员在流程早期就把这些列表准备好。 - JoshReedSchramm
那就是问题所在。业务分析员正在积压大量的需求文档。这在每个迭代回顾会议上都被提出来了。我们要求他们尽早完成，但他们一直在不停地工作。 - Alex Argo
顺便说一下...你的名字似乎有点熟悉。我想我已经确定了你是Ben Lee的朋友，我在2007年曾经和他一起工作过一段时间。 - Alex Argo
你是100%正确的，他是我的一位老大学室友。 - JoshReedSchramm
2

看起来BA可能没有及时地为您提供冲刺的用户故事。

根据您的说法，我认为没有冲刺计划会议。

考虑到Scrum的一个重要原则是开发团队负责每个冲刺的工作内容，听起来这不太敏捷！（-:

除了有短暂的冲刺之外。

我们的业务负责人和Scrum Master列出了我们在冲刺期间要做的事情清单，然后分配谁来完成。在我们的计划会议上，我们通常只是提供估算，因此它们没有太大用处。我们曾经在冲刺计划中自愿承担任务...但现在不再这样做了。 - Alex Argo
1

好的，有几个建议可能会有所帮助： - 在SCRUM流程中，有产品所有者概念，这代表了客户。因此，您可以邀请PLM或客户的主要联系人参加您的SCRUM会议。这将使您的客户参与到您的流程中，并让他们与您共同实现目标。 - 向客户提供每周版本可能会有所帮助。因此，每周发布的基本想法是向客户展示“进展”。因此，如果几周没有进展，这应该引起“为什么”的问题，然后您应该能够解释这是因为缺乏需求明确化的原因。

希望这些建议对您有所帮助。

1

"用户故事"是一个代表未来会话的占位符，所以要去面对客户并询问他们；如果这是BA的工作，就点燃火苗吧 ;-)

1

你的用户故事不完整。'自定义X屏幕'只是一个任务，它没有描述任何要求或完成标准。用户故事应该像这样：'允许Nancy查看库存中物品的相关采购订单'。然后在你的冲刺期间将其分解为任务，以便你可以处理。

一旦业务分析师开发出可行的用户故事，然后将其添加到产品待办列表中，对其进行优先排序，并计划顶部待办列表项的冲刺。业务分析师应独立于你的冲刺开发用户故事并将其添加到待办列表中，因此不会阻塞你。在冲刺期间，任务完成后，用户故事不会改变。发布后，客户提供反馈，这些反馈作为更多的用户故事添加到产品待办列表中。

0
正如上文所述，通常在每个迭代的开始阶段，您应该优先考虑现有的待办事项并选择一些故事来完成当前迭代。如果开发人员没有足够的用户故事可用，您应该将他们转移到另一个项目，并让产品负责人有时间创建一个足够大（以供团队使用）的待办事项列表。
0

我看到了几种处理这个问题的方法：

选项1，根据SCRUM的规定，你应该有一个产品负责人来管理你的产品待办事项列表，其中应该包含软件功能请求。如果该功能包含一些模糊的东西，比如“自定义屏幕X”，并且你决定将其添加到你的冲刺中，那么冲刺任务应该是具体的、分解的任务，我会说其中一个任务必须是“为屏幕X定义需求”。

在每日SCRUM期间，当你询问每个团队成员的三个问题时，负责该屏幕修改任务的开发人员会说：“我被BA阻塞了，正在等待需求。”，你的Scrum Master会尽力推动它的进展。

选项2，在我看来，只有当项目定义得足够清晰，可以进行至少一些有生产力的工作时，才将其放入产品待办事项列表。我们都知道需求会变化，但关键是你应该有足够的起点。

0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接