我们是一个由3个开发人员组成的小组(其中2个是经验丰富的人员，但是对于这个特定的业务领域是新手)，他们开发功能复杂的产品。我们正在使用Scrum，并且在每个sprint的末尾都有一个演示。很明显，职能团队有很多想法，但这些想法与开发团队的沟通并不充分，因此演示提出的问题多于答案。

对于提高职能人员的输入质量，我们有什么建议吗？

进一步的信息：我认为问题的一部分是没有这样的规范或者用户案例。我个人认为他们需要写下某种要求，他们应该写下什么样的事情，并且考虑到敏捷过程的复杂性？

解决方案

回答

他们参加站立会议吗？

我们可以建议在每一个(或者一些)中都有一个代表，在冲刺结束之前要求他们提供输入

回答

有时，从人们那里获得输入的最简单方法是将其从人们那里挤出来。我的公司在一个项目上使用SCRUM，很快就发现人们在知道自己在做什么的时候往往会保持守旧。我们最终组织了每周一次的会议，要求团队成员展示在一周中学到的东西。它是强制的，但效果很好。

回答

我们是否尝试过与客户一起定义/制定验收测试？
使用诸如Fit之类的工具来进行这些测试将产生更好的规格，并迫使客户考虑真正需要什么。在此过程的最后，锦上添花的是即时文档可执行的规范。

当然，如果客户可用并且愿意接受这种方法。试试看！

如果不是这样(这似乎是最主要的原因，因为它工作量较少)，则每周进行一次日历Flash'em计划会议/电话会议，直到他们像金丝雀一样唱歌:) +1给Dana

回答

我是用例的忠实拥护者，他详细介绍了系统行为以响应用户操作。这些可能共同构成一组宽松的要求，并且在SCRUM环境中可以确定用例的优先级，这些用例将形成特定sprint的已实现功能。

例如，与职能团队联系后，我们将确定15个单独的用例。我们确定了用例的优先级，并决定计划5个冲刺。在每个sprint的最后，我们将演示并完成产品，以实现在sprint期间实施的用例，并注意反馈并修改用例。

回答

我们是否正在举行独立会议，并且已经烧毁了图表？我认为这两个领域将使我们受益匪浅。

回答

我了解我们所说的职能人员是产品所有者，对吗？

I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?

实际上，如果没有任何规范，我们可能也没有针对积压订单的接受测试。我们应该要求PO编写用户案例，我喜欢"作为一种类型的用户-我想要-一些目标-一些原因-"。形式。请记住，用户故事应独立于投资，可协商，对用户或者客户有价值，可评估，较小且可测试。必须将验收测试与故事一起编写，以便团队应该知道故事必须具备的能力，才能按部就班地完成工作。

请记住，随着产品的发展，期望采购员在看到有效产品时有想法。这不是一件坏事，实际上，这是我们可以通过敏捷获得的最好的东西之一。我们需要注意的是，这些想法必须包括在产品积压中，并且需要由PO对其进行优先排序。而且，如果有必要并会为客户增加价值，则应计划在下一个冲刺中构建该想法。

回答

我推荐《敏捷开发人员的实践》这本书，其中包含如何使Scrum团队成功的建议。它还提供了一些很好的技巧，说明如何使产品所有者/客户更多地参与进来，以及如何使整个过程顺利进行。值得金钱恕我直言。

回答

功能团队的成员应该是该团队的成员，并可以回答有关所添加功能的问题。

如果没有足够详细的说明，我们如何估算待办事项？

我们可以建立一个规则，即不能计划没有明确接受标准的待办事项项目。

最好让职能团队中的某个人担任产品负责人，以确定，选择并优先处理待办事项和/或者作为域专家。

另外，请确保职能团队和开发团队中的每个人都说相同的语言，以免造成误解；请参阅无所不在的语言。

跟踪功能团队最等待答案的时间，以及浪费时间开发不必要的功能或者重新制作现有功能，以使其符合要求。