如何通过用户故事为技术选择提供指导？

Question

我是一个正在向Scrum过渡的固件工程师团队的项目经理，我将以产品负责人的角色支持团队。我们刚刚完成了Scrum培训，并开始了一个月的培训，这将是非常宝贵的。从技术背景出发，我已经看到了将我的观点从解决方案领域转移到关注业务价值的挑战。对我来说，想“如何”解决一个问题是很有诱惑力的。但我喜欢用户故事的概念，并定义功能的垂直切片，为客户提供价值，并让团队决定“如何”。

如果这是一个天真的问题，请原谅我，但是作为PO，我如何通过用户故事提供特定技术方向的指导呢？我担心的是，在某些情况下，如果没有指导，团队可能会在关键技术决策上走错路。

作为一个简单的例子，我可能有一个用户故事：

作为一名临床医生，我希望这个设备能够记录病人的治疗信息，这样我就可以确定病人的治疗是否有效。

现在说时间到市场是至关重要的，我想支付一个现成的文件系统堆栈，以节省时间，什么传达给团队？他们可能会从零开始编写自己的堆栈。

这类指导是否通过以下方式提供：

1. 在短跑计划和积压清理过程中的对话？但如果是这样的话，我作为PO是否有资格建议如何解决一个问题。
2. 接受标准？我真的不喜欢这样，我有一个不好的感觉，使接受标准如此规定性，他们规定如何解决一个问题。
3. 约束？

提前谢谢。我可以(也会)问我们的Scrum教练，但我不能在周一之前这么做，这个问题一直困扰着我:)

Answer 1

是否有一位架构师/技术主管是你可以与之交谈的团队的一员？

最终，我认为技术所有权在于交付团队。作为PO，您可以通过您的验收标准提供指导，而不是围绕“如何”来制定您的AC，而是讨论“为什么”以及您的假设堆栈将解决哪些问题(也许还有一些替代方案可以满足您的AC)。

您总是可以向团队提供技术指导，但我会非常小心，让团队选择哪些最适合他们(这包括架构师/技术主管)。如果有技术上的问题，我会把这些纳入你们的验收标准。敏捷/ Scrum的一个关键原则是，团队在获得授权并有权做出影响他们的决策时，工作最好。我肯定认识到有必要指导方向(特别是当你认为球队做了一个错误的长期技术选择的时候)，但是如果球队不同意并且形成了阻力，那就需要付出代价。如果团队同意，那就太好了--记住PO角色的界限，小心“规则的例外”变成“期望”。

另外，和你的Scrum Master交谈，他/她应该是这类事情的资源。

希望这能帮上忙，我很快就把它记下来了。

Answer 2

我的经验是拥有一位技术带头人，通过对话和/或技术文档(在你的名单上排名第一)来提供这个方向。该人还将能够提供关键决定所需的技术指导。他们将能够建议/监测/加强最佳做法。这通常不是PO(产品负责人)，因为它需要有一个不同的观点。

我不喜欢接受标准/约束方法太正式(这也需要时间和精力)。当然，敏捷的全部意义不是专注于创建正式的过程，而是传递故事，并为此编写代码。

Answer 3

您无法通过用户故事来指导技术选择；它们是有意对技术决策不可知的。这就是要点--它们只涉及功能，而不是实现。

技术决策应该基于团队已经知道的、他们想知道的、可以获得的专门知识、已经存在的、与现有系统最简单的接口等等。

无论是谁负责发展，都应该指导这方面的工作，接受任何知道任何事情的人的意见。