这是另一个试图弄清楚Scrum如何/应该在现实生活中工作的问题。这是我遇到的典型场景：
注意：下面不使用术语“产品所有者”。这是因为真正的“产品负责人” - 本案例中的产品经理 - 并未作出最终决定。当他决定应用程序如何与数据库交互时，数据库主管对许多事情有最终决定权。质量保证对于事物应该如何看待/工作有自己的想法 - 他们的想法被作为错误输入并且通常预期（由每个人）被视为这样。
我的理解（根据我们如何教授scrum）是开发人员有责任充实页面的要求。在我们的环境中，如上所述，这为开发人员带来了令人沮丧的体验，同时也为开发人员浪费了大量时间，同时等待获得所有权力，以便就需求达成统一的决策。< / p>
有时需要花费数小时才能确定2小时任务的要求！与1个人一起获得足够的时间是很困难的 - 对于3个人来说更难！
我知道这是反scrum，但在我看来，产品经理，数据库主管和QA团队应该在规划会议之前召开会议，并详细说明要添加到sprint的任务的详细信息。 （开发人员很少有任何考虑的输入，当我们在会议中尝试这样做时，可能需要一整天 - 而不是开玩笑 - 来挖掘积压中所有项目的所有细节。）
有没人处理过这件事？有什么建议？我不想啰嗦太久，所以如果你需要更多的细节，请告诉我。
谢谢！
答案 0 :(得分：8)
那是因为真正的“产品 所有者“ - 此产品经理 案例 - 没有进入决赛 决定。
这正是你的问题。 Scrum说
产品负责人不是一个人，它 是一个角色。每个人都可以成为产品 所有者。
如果您的产品经理无法做出这些决定，那么他不是产品所有者恕我直言。在这种情况下，找到可以做出这些决定的人，因为这是真正的产品所有者。
作为开发人员（scrum中的“团队”角色），我只需要了解产品所有者对此功能的期望。他是主人，他向我解释了页面应该是什么样子，我将按照他的描述制作。数据库主管不是产品所有者。质量保证不是产品所有者。我按照产品所有者想要的那样制作了页面，如果DB主管或QA有问题，他们应该与产品所有者交谈。或者实际上产品所有者应该提前与他们交谈。
另外，为什么没有DB领导和QA参加sprint计划会议，如果他们也以某种方式为产品所有者服务？在那种情况下，当产品经理说A，B和C. DB领导可能说他需要D和E而B不应该在那里时，他们可以立即喊出“异议”。质量保证可以说，他们认为E令人困惑。只要在冲刺后最终不得不批准我的实施的人甚至不同意他们想要的东西，我根本不会触及这件事。
答案 1 :(得分：2)
我注意到的一些事情......
1）您提到开发人员提取用户故事
在规划期间，它应该被分解为任务。
2）你提到需要一整天时间来解决问题。
Sprint计划可以需要一整天。你最好一次性花费这些时间，并获得足够的信息，以便在正确的方向上前进，而不是花费这么多时间来重复。
答案 2 :(得分：2)
一些建议：
上下文：“X用户需要页面执行Y”缺少上下文。我喜欢框架“作为一个X，我想做Y，所以我可以Z”。它略有不同，但Z部分增加了用户试图完成的内容。
验收标准：您没有提及验收标准。故事应包括一个接受标准列表，以指明故事何时完成。我喜欢短语“给定X，当Y，然后Z”（例如“给定”X用户登录并且银行余额为正， 时他导航到在Y页面上，然后他在他的余额旁边看到一个笑脸“。通常，会有一个这些验收标准的清单。
我认为你会发现产品经理在被迫定义验收标准时，会更好地了解他/她想要用这个故事完成什么，并且可以更详细地传达它。旁白：我还发现测试人员可以查看可测试性问题的验收标准。
什么与如何：听起来你在 需要完成的迭代过程中仍然在争吵。 INVEST *故事标准中的可转让性概念更倾向于如何故事的实施。在将故事添加到迭代之前，应该已经定义了什么。
*投资 - 独立，面议，有价值，可估计，小巧，可测试
答案 3 :(得分：1)
我的建议是让PO成为任务的所有者，以决定什么是预期的行为。这可能意味着要经历十几个或更多奇怪的情况，其中系统正在构建以允许Y在Z关闭或W没有及时响应等情况下也必须做某事。
虽然开发人员的工作可能是充实细节，但这只是向适当的人提出问题。对于PO来说，“哦，我很抱歉，我现在确实想要D和E”，因为这个过程的一部分是处理不断变化的要求，因此关键在于结果而不是101步这样做是为了让产品的新版本在冲刺结束时做好准备。
另一种选择是拥有一个团队领导或团队经理，如果在一家大公司中，应该与项目分开的开发人员经理可以成为你可以说的地方的资源，“我想做D但是需要更多细节，似乎无法安排与PO会面，“并希望这个人有更好的运气。
答案 4 :(得分：1)
问题不在于“Scrum与现实世界的冲突”。问题是“尽管存在其他问题，我希望Scrum能提供好的东西。”
问题的根本原因是有人不想等待利益相关者。其他一切都是这个问题的解决方法。让开发人员尽早开始讲述一个不完整的故事会导致开发人员，DBA和QA之间的不愉快舞蹈。早起就是 - 好吧 - 没有帮助。
如果你有一个稳定，一致的用户故事，那么DBA和QA就无法发号施令。如果你有详细信息，你可以胜过他们的输入。您不能责怪您当前的流程（或一般的Scrum），因为您没有来自利益相关方的可靠用户故事。
有时需要花费数小时才能确定2小时任务的要求！与1个人一起获得足够的时间是很困难的 - 对于3个人来说更难！
你觉得这听起来很糟糕。 2天的谈话，以确定要求，然后进行两个小时的技术工作是一个很好的比例。这表明，关心和思考。这表明你正在做正确的事情。
小心实施旨在让开发人员忙碌的制作任务，这样他就不会开始用剪刀跑。
如果需要好几天才能弄清楚这个故事，那么，我能说什么呢？这需要几天时间。花几天时间。这就是它需要的。
不要骂开发人员，因为他们没有编码。第一个开始编码失败。
<强>解决方案
当PO无法想象一个由软件赋予权力的未来国家时，你需要将一个人引入一个技术远见卓识的过程中。有时他们称这个角色为“业务分析师”。一些商业分析师是壁橱设计师和建筑师。解雇他们。一些业务分析师可以帮助PO明确一种新工作方式的愿景，并由新软件赋予权力。奖励他们。
答案 5 :(得分：1)
听起来你混淆了Scrum和XP的Planning Game。当然，您可以根据组织的需要调整方法，但即使是作为XP规划游戏，我认为它也不为人知。
规划游戏或Sprint规划的基本前提是开发人员或“猪”（包括DB Lead和QA）放弃了向利益相关者或“鸡”指定产品的“什么”和“何时”的权利“ （产品经理）。因此，那些能够事先指明“什么”会面讨论细节或优先事项的人当然不是“反Scrum”。
作为I answered here，详细信息在Sprint积压中填写。这可能是用户故事的形式，但Sprint Backlog在设计和任务中削减更多。
答案 6 :(得分：0)
您可能不需要在计划会议之前就所有事情进行会面，但只有在发现冲突时才需要。与所有利益相关者进行快速会谈并做出每个人都可以达成一致的决定可能是最容易的。
仅仅因为你的scrum，并不意味着你之后不应该有更小的目标会议。
答案 7 :(得分：0)
开发人员的责任是确保他完全理解他在givrn任务中需要做什么。 如果某些要求不清楚，您必须要求澄清，直到开发人员和他的同事/经理都完全明白需要做什么。
您应该提出诸如“我们将如何定义此任务的成功执行”或“客户将如何期望这样做”等问题等等。
开发人员应确保在迭代计划会议结束之前完全了解他在下一个周期中需要做什么。如果某些要求仍然不清楚，应该在SCRUM会议上解决，因为这会妨碍您实现目标。
答案 8 :(得分：0)
产品经理写了这样一个故事“X用户需要一个页面来做Y”。
在sprint计划会议上，故事被添加到sprint backlog中。
一些可怜的开发人员抓住（或被分配）这个故事。
开发人员向产品经理询问“您希望页面是什么样的”。
产品经理（如果有的话）说，“嗯，好吧，它需要收集A，B和C.”
开发人员开始研究它应该是什么样的最佳猜测。
我现在要停下来，因为我感到沮丧。这不敏捷，这太荒谬了：
这应该是一种敏捷方法？称之为敏捷不会如此 - 这完全取决于方法的原理，而不是术语。难怪这个过程失败了！
答案 9 :(得分：0)
我还没有完成scrum（虽然我已经研究过它并且喜欢它）但是在我看来，如果用户故事真的像你所指出的那样，那么PM就没有做好自己的工作。关于完成一天的实际情况：召开一次与所有3个派对的会议并一起散列，而不是试图成为中间人。
答案 10 :(得分：0)
答案 11 :(得分：0)
我的团队一直面临着这个问题。我们获得了非常广泛的用户故事，并被要求在2周的迭代中提供其中的几个。我们花了一个星期与我们的PO（我们跨网站工作）交谈，充实了一个用户故事的细节（如果幸运的话，我们可以做两个），并编写我们自己的用户故事，以便可以编写功能/验收测试他们。然后我们开始估计每一个的复杂性，并承诺我们可以在剩余的一周内实际希望完成多少。
总是将一个广泛的用户故事分解为至少6或7个更精细的用户故事。这让我们抓住了更广泛的用户故事的复杂程度，通过反复这样做，我们希望与我们的PO沟通，他们需要为我们提供更精细的用户故事，但到目前为止我们还没有取得多大成功。
As S.Lott said in his answer，如果您的用户故事不明确或过于高级，您必须扮演业务分析师的角色，以弥合PO和开发团队之间的差距。
答案 12 :(得分：0)
我知道这是反诈骗，
我建议你（和你的队友）不要过分关注“Scrum”，“反Scrum”，“XP”等等。
您是软件创建者，因此，我鼓励您相信自己是最好的人和专业人士来创建您需要创建的软件，无论是关于敏捷（或任何其他方法）的书籍或顾问
但在我看来，产品经理，数据库主管和质量保证团队应该在规划会议之前召开会议，并确定要添加到sprint中的任务的详细信息
同意你的意见。
这就是我成功完成的许多（敏捷）团队。这种做法有助于更好地了解要完成的工作，并估计复杂性。这不是关于在几周内编写规范文档，而是要在功能和技术方面更好地了解故事背后的内容。维基页面（或类似工具）通常需要收集此类信息。
当我们在会议中尝试这样做时，可能需要一整天 - 而不是开个玩笑 - 来排除积压中所有项目的所有细节。
是的，可能需要花费大量时间来散列所有细节，这在大多数情况下都是不必要的。这是在获取信息和获取太多信息之间的平衡问题。填充维基页面（屏幕大小）通常就足够了。获取此信息的时间可能在10分钟到2小时之间。
如果这需要更多时间，这可能是因为故事很大和/或不确定，你可能想考虑如何分割它。
希望得到这个帮助。