功能所有权是一种良好的实践吗？

Question

最近在我的公司里，有人建议一个开发人员应该把精力集中在一个特性上(而且只有一个)。这意味着，将开发人员排除在常规团队常规之外，将其释放出其他一些职责(会议等)，这个人将是该特性的“唯一”负责人，技术上是明智的。

为了记录在案，我们在SAFe中使用SCRUM，并且我们为每个团队的全职开发人员在两个团队(Android和iOS)之间共享QA和产品所有者。

虽然我同意这会在短期内提高生产力，但我有一种感觉(我想我是在大学里学到的)，这是一种糟糕的做法，原因有很多：

• 代码评审失去了价值。
• 最小知识共享。
• 风险增量
• 失去团队灵活性。

我说得对吗，还是说这完全不是一种糟糕的做法？

Answer 1

在我20年的经验中，最好让代码所有权在设计人员之间轮换，或者至少有一对所有者。单一功能所有权存在以下问题，您提到了其中几个问题：

• 它倾向于鸽子洞设计师，并限制他们的成长机会。
• 它把所有的鸡蛋放在一个篮子里，所以如果有人被公共汽车撞到或者退出，那么知识就会有一个洞。
• 单个人可能看不到代码中的问题，如果没有对等所有者，代码评审的效率就会低得多。
• 如果每个人都在使用自己的样式来处理代码，那么很难保持代码的一致性和可读性--虽然这可以通过样式指南来解决，但微妙之处可能会慢慢出现，特别是当人们依赖默认行为时，使用约定而不是配置。
• 如果开发人员拥有代码，就会倾向于对代码进行保护和防御，从而抑制代码的演变--如果有几个人拥有代码，这种趋势就会减少。

Answer 2

特性所有权是不可避免的，做得好可能是一件好事。它帮助建立掌握，并允许自主性-两个公认的参与支柱。它清楚地表明谁对该代码负有责任，并在委托、沟通和其他方面提供帮助。

但你不是在说这个。你说的是组建一个由一个人组成的新团队--把这个人从其他代码中剔除掉。那可不太好。这限制了他们的事业。它增加了项目/公司的风险。它会伤害科拉达里。

因此，一些节制可能是为了让这个想法远离坏的想法。