我们是一个由3名开发人员组成的小团队（2名经验丰富，但对这个特定业务部门来说是新手）开发功能复杂的产品。我们正在使用Scrum并在每个sprint结束时进行演示。很明显，功能团队有很多想法，但这些想法并没有很好地传达给开发团队，演示提出的问题多于答案。
您是否有任何建议可以提高功能人员的投入质量？
更多信息：我认为部分问题在于没有 specs 或用户故事。就个人而言，我认为他们需要写下某些要求 - 他们应该写下什么样的事情以及敏捷过程中的复杂性？
答案 0 :(得分：2)
您是否尝试过与客户合作来定义/制定验收测试？ 使用Fit之类的东西来进行这些测试 - 会产生更好的规格，并迫使客户考虑真正需要的东西。在这个过程结束时，锦上添花的是即时文档可执行的规范。
当然，如果您的客户可以使用并且对这种方法持开放态度。试一试！
如果不是（而且这似乎占多数 - 因为它的工作量较少） - 日历闪存' - 每周安排会议/电话会议，直到他们像金丝雀一样唱歌:)给Dana +1。
答案 1 :(得分：1)
有时，从人们那里获取意见的最简单方法就是强迫它们离开。我的公司在一个项目中使用了SCRUM，很快发现当人们已经知道他们在做什么时，他们往往会保持自我。我们最终组织了每周一次的会议，要求团队成员展示本周学到的东西。它被迫，但它运作得很好。
答案 2 :(得分：1)
我非常相信用例，详细说明系统行为以响应用户操作。总的来说，这些可以形成一组松散的需求，并且在SCRUM环境中可以帮助您确定用例的优先级，这些用例将构成特定sprint实现的功能。
例如，在与您的职能团队交谈后，您确定了15个单独的用例。您优先使用用例，并决定计划5个冲刺。在每个sprint结束时，您将通过演示产品来完成sprint期间实施的用例，并注意反馈和修改用例。
答案 3 :(得分：1)
我知道你称之为功能人员的人是产品所有者，对吗？
我认为部分问题在于没有规格或用户故事。就个人而言，我认为他们需要写下某些要求 - 他们应该写下什么样的事情以及敏捷过程中的复杂性？
实际上，没有任何规格，你可能也没有对积压的验收测试。你应该让PO写下用户故事，我喜欢“作为一种类型的用户 - 我想 - 一些目标 - 所以 - 某些原因 - ”。形成。请记住，用户故事应为投资 - 我独立， N 可分析， V 可供用户或客户使用， E < / strong> stimable， S 商城和 T estable。必须将接受测试与故事一起编写，以便团队知道故事必须能够做什么才能完成。
请记住，随着产品的发展，预计PO会在看到工作产品时有想法。这不是一件坏事，实际上它是你通过敏捷可以获得的最好的东西之一。您需要注意的是，这些想法应该包含在产品积压中，并且需要由PO优先处理。并且，如果它是必要的并且将为客户增加价值，那么应该计划在下一个sprint中构建该想法。
答案 4 :(得分：1)
来自职能团队的人员应该成为团队的一员，并且可以回答有关您正在添加的功能的问题。
如果Backlog项目没有足够详细，您如何估算？
您可以建立一条规则，即无法规划没有明确验收标准的Backlog项目。
如果让职能团队中的某人充当产品负责人，确定，选择和推销Backlog项目和/或作为域名专家会更好。
此外，确保功能团队和开发团队中的每个人都使用相同的语言，以避免误解;见ubiquitous language。
跟踪大多数等待功能团队的答案的时间，以及浪费时间来开发不必要的功能或重新处理现有功能，以便它们符合要求。
答案 5 :(得分：0)
他们是否参加了站立会议？
您可以建议在每个（或部分）代表处找一位代表，在短跑结束前要求他们提供意见
答案 6 :(得分：0)
你在做单口会议吗？你有烧毁图表吗？我认为这两个方面对你有很大帮助。
答案 7 :(得分：0)
我推荐“Practices of an agile developer”这本书，它充满了关于如何让scrum团队成功的建议。它还提供了如何让产品所有者/客户更多参与以及如何使整个流程滚动的良好提示。值得恕我直言。
答案 8 :(得分：0)
我同意你需要某种要求（用户故事或其他）。
我可以给出的一条建议是与功能团队一起使用某种视觉辅助工具。当客户有很多想法时（正如您所说），他们通常也会看到一个功能的外观，当开发的产品不适合这种视觉理念时，它会产生很多疑虑，甚至如果它在功能上完成了工作。
在与客户讨论功能时，我尝试非常直观。在板上画草图，甚至口头描述什么样的东西。试图找到一个共同的视觉形象。然后，您可以拍摄草图的照片并将其用作文档的一部分。
另一个建议是让你的短跑尽可能短，这样你就可以进行更频繁的演示。但是你可能已经这样做了，因为你没有提到你当前的冲刺持续时间。