案例研究是否是一种有效的方法，让效率为中心的团队成员愿意用一些效率来换取质量？

Question

• 首先，这并不意味着效率和质量是相互冲突的。只是有些方法对它们的排序不同。
• 其次，这不是一个你是否同意Scrum实践的问题。

Scrum的一个明确目标是创建高质量的可交付产品增量。这并不排除可以有效地进行，但效率不是重点。

大多数程序员希望既提供高质量的产品，又能提高效率。Scrum要求将产品待办事项添加到优先列表顶部的sprint待办事项列表中.通常会引起程序员的抵制，例如：

“但是，如果我们将这另外两项添加到优先级列表的后面，再加上这个sprint，就会更有效。”

在与产品负责人一起工作时，Scrum可能会对产品待办事项的优先级产生不同的影响。这样的问题可以在下一次产品积压改进会话中解决。

撇开这些问题不说，个案研究(其他团队对Scrum的有效使用)是否是摇摆不情愿的团队成员的有效方式？(特别是在效率问题上)或者，还有比个案研究更好的东西吗？

Answer 1

撇开这些问题不说，个案研究(其他团队对Scrum的有效使用)是否是摇摆不情愿的团队成员的有效方式？(特别是在效率问题上)或者，还有比个案研究更好的东西吗？

案例研究真的很难替代一般的经验，即使人们阅读了它们，也不会有太大的区别。

你的问题是别有用心的。Scrum团队只在将需要处理的项目放入待办事项方面进行前瞻性思考。他们也在"Sprint“模式下进行前瞻性思考，在那里他们正在规划项目的整体、高水平的设计和环境建设。就是这样。

其他一切都应该是scrum团队的短期目标，完成下一次冲刺以获得产品负责人的认可。

如果您的团队成员正在考虑稍后的返工，那么在Sprint计划期间将其作为一个关注事项提出是正确的，但是将其引入sprint的决定完全取决于产品负责人。当产品负责人认为这是一个问题时，返工只是一个问题，但是他/她应该意识到她承诺团队的技术含义。

那你该怎么说服团队？

你需要让团队中的每一个人都记住同样的目标。报告潜在的技术问题和风险，当你没有足够的信息时，你的情绪会激增，但最终，当你投入到一个故事中时，你的感觉应该留在门口，你应该去做，而不管它会受到什么影响。团队只需要弄清楚要为此花费多少精力，以及在分配的短跑时间方面是否现实。

如果开发人员担心必须编写一堆稍后会丢弃的代码，那么他们就不会对齐.

。

目标是现在就快速交付业务价值，而不是阻止未来的返工。这与他们和他们对重构和未来工作量的担忧无关，而是通过强调最小可行产品的重要性和快速交付业务价值，让他们放弃这些目标。

Answer 2

还有更好的东西。它被称为“权威”。产品负责人决定什么是先做的，什么是后的。

然而，开发人员希望与产品所有者沟通，一些事情可能会更有效地做这样或那样的方式。

尽管如此，权威仍然是产品所有者，根据开发人员的输入，产品所有者必须决定是坚持自己的计划还是稍微修改一下计划。

专业的开发人员会通知产品所有者可能的优化，而不是因为“他相信”而拒绝做某事的人。