产品需求是否应反映供应商的API功能和限制？

Question

我有一个关于Scrum产品负责人和Scrum工程师/架构师的责任的问题。

据说，在Scrum中，产品需求(PRD)指定“什么”，而不是“如何”。换言之，珠三角不应规定(或关注)实施细节。

我们正在构建一个非常依赖于与供应商API交互的应用程序。有人说，我们不想把我们的应用程序和供应商的API紧密结合起来，因此产品需求不应该反映供应商的API功能和限制。更具体地说，在没有供应商的API文档的情况下，PO需要编写产品需求。

这是对Scrum方法的正确解释吗？这种方法的优点和缺点是什么？

Answer 1

如果产品需求是在完全没有任何第三方API的情况下编写的，那么很可能结果会非常复杂(即，值很多点)，甚至不可能实现。这两个故事都不是好故事。PO编写的东西可能是最终目标，但是开发团队(通过产品待办事项整理)可以回来告诉PO重写故事，或者根据他们正在使用的API的知识，删除/更改一些需求。

或者(或者另外)，如果有很多这样的故事，也许是时候编写一个故事，将您要使用的供应商产品更改为支持PO想要的所有功能的产品。当然，这有一个相关的成本(时间和金钱)，并将由PO决定在哪里优先处理它的积压。

Answer 2

Scrum的回答是肯定的，产品要求应该在没有任何自愿审查的情况下表达。事实上，这可能是非常有限的，我已经看到，在决策过程中甚至没有提到一些选项，因为它们被暗示在没有被质疑的情况下是不可行的。

我们也赞成合作，而不是合同谈判，意思是，如果新的事实到来，我们可以相互协商，并作出必要的改变。

我喜欢使用从Kepner决策分析中借用的过程，这是关于必须拥有和应该拥有的明确性。你可以读到它，这里。

现在，并不是没有听说20%的需求驱动了80%的成本。这很可能会在估计时出现。作为一名scrum高手，我发现与PO一起回顾这一点并讨论潜在的替代方案是很有用的。我也有两种反应，有时昂贵的需求是交付品的核心部分，有时它会返回到待办事项中。

Answer 3

需求应该存在，以提供利益。另一方面，满足要求会产生成本。如果满足需求的成本大于收益，那么应该有人考虑放弃需求。

产品负责人可能被告知需求的好处(或者能够从涉众那里了解)。scrum大师在某个时候会发现满足需求的成本，希望是在估计的时候，如果开发人员发现他或她不能在估计的时间框架内提交一个故事的话，情况会更糟。

产品所有者不应该对他们的需求进行自我审查。同样，开发团队不应该盲目地实现需求，而不考虑成本。如果通常有良好的沟通，那么团队将对需求的好处有一定的了解，并可以警告实现成本是否比效益高。或者，产品所有者可以指定需求的可接受实现成本是多少。例如，“我预计一个开发人员的成本将少于8个工作日，如果没有明显的增加，那么我就不想要它了”。