我认为产品负责人是 Scrum 在软件界遇到的最糟糕的事情。
这是个很坏的主意！
——Mary Poppendieck
Mary Poppendieck 认为，产品负责人的角色是从事工作的人和需要工作完成的人之间的代理，这会导致软件工程过程中的延迟、误解和膨胀。Poppendieck 撰写了很多软件精益（Lean in Software）方面的书籍，她在 7 月 15 日的一场题为“培养精益思维模式”的演讲中提出了这一观点，她在演讲中讨论了精益思维模式是如何有效地对变化做出快速反应的。
Mike Cohn，”用户故事“的作者和敏捷宣言的签署者，在 6 月 11 日转发了他关于同一主题的文章。他写道“是时候取消Scrum的产品负责人角色了”，并问道“团队应该协作共同做出技术决策，那么为什么不一起做产品决策呢?”
Cohn 和 Poppendieck 似乎一致认为，我们应该将产品决策的责任作为一项共同责任重新分配给软件工程团队，就像测试和架构已经做的那样，这是提高我们构建软件和更快响应变化能力的首选方法。
Cohn 说，这将要求开发人员“超越把自己当成程序猿的思维“。Poppendieck 认为这是回到了最初的工程思维模式，她说软件在上世纪 90 年代失去了这种思维模式。尽管对根本原因和潜在解决方案的分析差异很大，但其他许多人也对产品负责人的角色提出了类似的担忧。
在“伟大的产品负责人的挑战”（The Great Product Owner Challenge）中，Nigel Thurlow 辩称，产品所有权并未被打破；这是一个组织如何执行这个角色，以及组织惰性如何阻止它做出的必要的改变。
讨论过此问题的其他评论员的精选标题包括：
大多数文章都介绍了如何培养优秀的产品负责人，但也揭示了许多人在试图很好地利用这个角色方面遇到的困难。
Scrum 创始人 Jeff Sutherland 在推特上发表的一篇研究文章，在文章中，作者还强调了一些组织为了适应传统结构而破坏敏捷，从而角色被扭曲的趋势，为什么我们无法扩展：
总而言之，文献中出现了一个新兴的主题，即 Scrum 大师、产品负责人和团队角色的原始平衡正在被调整、整合，甚至可能被破坏，以适应从瀑布式过渡过来的组织的需求……
总结一下各文章的各个方面，我们可以看到，随着敏捷的扩展和使用成为一种规范，可能不再明显需要一个产品负责人的角色了，该角色也显然不适合这种情况。在过去的 10 年里，InfoQ 已经涵盖了这个复杂角色的许多方面，包括：基于 Henrik Kniberg 思想的团队协作；产品负责人的模式和产品负责人的扩展；讨论的广度和深度在继续扩大。所有的组织设计都涉及到复杂的环境和复杂的人际互动。产品负责人角色的好坏显然取决于很多因素，包括团队的成熟度、组织的成熟度、组织的类型、组织的复杂性以及产品负责人本身。
原文链接：
https://www.infoq.com/news/2020/09/product-owner-good-bad-complex/
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论