产品所有者团队
为此，我们已经确定了敏捷产品所有者是我们在瀑布软件开发中的许多传统角色的抽象。产品所有者是产品经理，项目经理，商业分析师，设计师，其他业务利益相关者的整个列表。亚博vip9通道
我们探讨了这是一个很大的工作，与产品经理的角色非常不同。我们建议没有多少人有这种角色的技能宽度......或者可以做得很好的时间。
许多团队将为代理商插入业务分析师，试图为他们迫切需亚博vip9通道要的日常方向给予团队。这种方法的问题是，商业分析师或除了产品主人之外的任何其他角色，不是单身绞合颈部....亚博vip9通道..他们只是不拥有该产品。
代理可以给团队指明方向，但不负责在事情需要改变时做出关键决策。他们必须去问别人，而这个人通常是真正的产品负责人。将真正的产品负责人从团队中分离出来会减慢团队的速度，并且你将冒着构建错误产品的风险。
它鼓励太多的关注分离。我们真正需要的是一个共享问责制模型......一个人团队，每个人都作为团队的一部分工作......所有负责人都可以提供产品所有者的角色。
委员会对产品的所有权
简单的共享产品所有权而不是BA作为代理
现在，这只是BA略有修改作为代理模型。该团队可以使用产品所有者和BA作为单一可绞合颈部的BA。产品所有者是在那里阐明愿景和优先级...... BA每天与团队一起工作以翻译要求。产品所有者和BA之间存在伙伴关系，这两者都是团队的工作，以获得他们所需要的以及需要它的时候。
这是与BA作为代理模型的微妙但重要的差异。我们必须让产品所有者作为团队的全职成员运作......他们无法委派这个关键函数......但我们需要得到一些帮助。
想一想一分钟......什么是产品所有者在不直接与团队工作时做的事情？他们还与利益相关者合作，识别产品要求，优先考虑用户故事，并让用户可以由团队消费的用户故事。大多数scrum人士称之为修饰积压。
让我们考虑另一个问题……团队在接受一个故事进入sprint之前需要什么?他们需要业务需求的清晰表达，他们需要接受标准(完成的定义)，他们需要一个构建亚博vip9通道特性的基础架构。
所以会议？我们是否预计用户故事只是基于产品所有者在最后一次Sprint审查后学习的内容的一些临时意识流？绝对不。
显然，产品所有者正在努力领先于团队，确保他们正在建立一个坚定的理解基础......这种做法很了解......并且功能与利益相关者目标相一致。这与一个大的前端设计不一样......它是滚动的波......它是在高水平的抽象中完成的，从我们走到了更精确且更具体的抽象。
如果允许产品所有者思考和计划，为什么不是一群人是团队的一部分......负责让故事准备就准备好了？这就是我由产品所有者团队的意思。
在我们的共享产品所有权模型中引入更多角色。
如果我们可以忍受由产品所有者和BA组成的共同角色，我们可以扩展云以包括一些设计人士......甚至上帝禁止......项目经理？我们可以维护一个模型，每个人都带来他们的专业，以他们独特的方式与组织合作......并根据他们的专业领域为团队提供指导？我认同。
在实践中的一个扩展模型
在实践中看起来像是一个人的团队，每个人都有自己的个人职责，几乎就像团队中的小组委员会......每个都代表自己的特定观点......所有人都负责持续的积分梳理积压：
- 产品经理有责任与利益相关者合作以确定要求并确定优先级。
- 该项目经理保持了对整体目标的看法，并帮助管理资源，资本支出，外部依赖项和与团队的触摸点。亚傅体育app
- 业务分析亚博vip9通道师负责记录验收标准并记录用户故事周围的对话。他们还成为在冲刺期间澄清的要求的主要接触点。
- 设计师可能会准备一些屏幕截图、线框图等，以便让团队了解新功能的外观和感觉。
产品主椅子的过程，它们仍然是单身绞梭，但有一个支持人员帮助他们研究，文件和管理团队的投入。这些人在团队之外有职责，但剃刀侧重于为什么他们存在......为团队提供一个良好的修饰积压......满是准备被拉入冲刺的用户故事。每个人都可以在Sprint期间获得，并且所有人都是集体负责的，与团队一起提供冲刺。
亚博vip9通道业务需求进入过程中......可操作，可扩展的用户故事出来。整个团队负责完成。相当简单，呵呵？
产品所有权由PO、项目经理、BA和设计师共同组成的委员会负责。
所以......再一次，我们的产品所有者团队负责从更广泛的组织获取投入，使他们的知识和专业知识承担问题，并与团队中的其他人合作，为团队制作有形信息以定义上下文并提供协调。还记得我的最后一篇文章吗？这一切都回到了提供上下文和协调。
更多的开销？是的。鉴于任务的复杂性必要吗？是的。我们可以坚持单一的产品所有者，但在许多情况下，我认为我们将失败。
很多人可能会想到我让这个太复杂我明白这是一种风险。我在等待Kanban伙计们告诉我关于流动的......在团队和团队中有一个地方。我在等待某人的权衡，因为这支队伍团队不能共同负责......我听到你的声音，但没有共享问责制，我们都失败了。我理解所有这些论点，但我们需要答案。
我们甚至还没有开始讨论大规模的敏捷。我们还没有引入多个团队，更不用说必须以协调的方式运作的多个团队了。我们需要讨论组织、组织backlog和项目组合。这个结构对于单个团队来说可能太复杂了……但我们需要一个可伸缩的模型。这件事在好转之前还会变得更糟。
下一篇文章，我们将讨论我们的共享产品所有权方法如何适用于多个独立团队和多个相互依赖的团队。这才是真正有趣的地方。一如既往，谢谢收听。
评论（19）
bonniea
这听起来像是可以发生可能发生的事情，以适应一个大型和复杂的项目。它似乎拥有那些建立的假设，我可以想象其他团队以不同的方式处理规模。
我在这里没有看到的是如何确保产品所有者团队没有从开发团队中脱离，它不会花费它的所有时间梳理积压。此团队不仅负责向团队提供输入，而且还负责查看和对齐输出。滚动波很好，但他们需要在两端都有。
斯图尔特罗杰斯
迈克我喜欢团队的方法。只是有点关注角色以及如何理解他们根据您的帖子组织。您已描述过，别人描述了什么[喜欢您的照片更好：--)]在敏捷的背景之外，但在产品管理的背景下。
产品经理负责与市场交谈（客户，前景等），产品经理负责产品的成功。其他角色如产品所有者，业务分析师，项目经理和设计师正在支持产品经理的角色。亚博vip9通道
在Sprint /迭代的背景下，我同意产品所有者应该采取铅并确保（产品管理）团队准备好并为第1天。但是发布（许多Sprints）和产品的总体成功落到了产品经理。
我知道标题毫无意义，但它可能会对别人困惑。
Mike Cottmeyer
谢谢你的评论Bonniea。
几个想法。思想的第一件事是如何确保产品所有者不会从团队中脱离？在努力采用敏捷的球队本身就是猖獗的。我认为你用共享地点，共享问责制和共享重复的一些组合来解决它。没有人都没有成功，没有人能成功。您的问题可以在团队中的任何角色申请。
也就是说，如果您与产品所有者团队有正式安排，那么他们具有非常明确的角色和责任......他们可以自己工作并自我组织。对我来说这两个非谈判表现是：
1.积压必须在Sprint规划之前为团队做好准备
2.产品所有者团队是整个团队的一个子集。每个人都分享了交付的问责制。
这是一个问题，即许多团队采用敏捷斗争。激励计划通常奖励个人表现。我向个人推荐一些％，为团队，占组织的％。
Mike Cottmeyer
斯图尔特 -
我认为这里的角色标题对不同的人意味着不同的东西。
问题1 - 许多Agilists假设其产品管理员成为产品所有者。并不总是真的
问题2 - 产品所有者比产品管理器大得多。如Scrum所定义，产品管理器包含项目管理，业务分析和设计的方面......以及产品管理亚博vip9通道
问题3 -产品负责人或产品经理作为产品负责人对团队来说不够可用。敏捷需要产品负责人几乎即时的响应时间
问题4 - 如果产品经理委托（将产品所有者姓名为代理）（分析师或初级产品经理），则它们是单身绞合的颈部。他们无法实时做出决定。
我写这一系列文章的全部原因是，我完全理解敏捷中定义的产品负责人。我也完全理解传统项目中定义的产品经理。我们一直在定义理想……这很好，也许我们会把它作为最终目标……
我担心的是团队失败了，因为我们对复杂的企业还没有清楚的认识。双方都在说话，但我认为没有人在听。
我们需要一些不依赖于过冷的战略过夜，过夜......人们可以在今天围绕着他们的头脑并开始执行。
谢谢你的评论......你仍然计划本月在亚特兰大倒闭吗？
吉姆本森
“我的担忧是，团队失败，因为我们还没有这么清晰，尚未为复杂的企业提供清晰。双方都在说话，但我不认为任何人都在倾听。“
这是这个帖子的金色。
在没有得到上下文或理由的情况下，在敏捷中，有很多人在敏捷中追随。这导致僵硬和困惑的敏捷实现，然后在它不起作用时混淆。
这反过来又会导致人们说:“是的，我们尝试过敏捷，但它不奏效。”敏捷纯粹主义者会说“您做得不对。”
问题是他们既有错误，他们都是对的。
杰夫•安德森
您的方法似乎是合理和缩放敏捷的方法，如任何......
我认为这都是常识，当项目变得更大时，没有人可以胜任所有的工作。
我还将包括您的“委员会”中的测试人员/ QA，这些资源可以提供纪律和结构往往缺乏......亚傅体育app
Laura Brandau.
辉煌的帖子。在定义敏捷产品所有者角色时，铺设了很多地面。直到我们通过模型工作，如您所提出的基于团队的问责制，我们不会看到敏捷开发过程所带来的所有福利，因为我们不会真正建立正确的东西。
我自己是产品所有者团队的一部分，非常与此模型对齐。作为业亚博vip9通道务分析师，我负责线程范围和验收标准。我促进了与多个业务利益相关者的讨论，帮助战斗决策，最后审查了我们的冲刺计划会议亚博vip9通道前的“单身颈部”验收标准。产品所有者负责优先顺序和最终决策。我确实承认，一段时间有延迟......我可能会从一个开发人员那里得到一个问题，即没有她的意见，我无法回答。但是，替代方案首先要定义故事，因此在我们目前的情况下我们更好。
最好的，
劳拉
http://www.bridging-the-gap.com.
Mike Cottmeyer
太棒了劳拉，很高兴听到其他人把这种东西付诸实践，这是有意义的。
凯文布伦南
我承认，我发现这种比较让我很迷惑。当然，据我所知，没有一个明确的来源描述产品负责人的职责，这可能是问题的一部分。有几件事让我困惑。在某种程度上，我试图把这一点弄清楚，因为在从事BABOK工作几年之后，我已经非常接近这样的结论:PO是一个具有决策权力的BA。现在，我对文学学士的期望可能比你高，但这就是我问这些问题的原因。
该定义指出，“产品经理负责与利益相关者合作以确定要求并设定优先权”这意味着企业分析师不会做那些事情。亚博vip9通道我会认为那些技能是一个孩子的技能......实际上他们在IIBA的角色定义中明确或隐含地呼吁。Now, I grant that there’s a difference between a Product Manager and a BA, but I think it’s really a difference in subject matter, not skillset (a Product Manager understands the requirements of a market, while the BA understands the requirements of a organization).
抛出我的另一件事是项目经理部分。从我可以告诉scrum将几乎所有传统的项目经理责任分配给scrummaster和团队。再次，BA /产品经理应该能够理解和维护对象的关注，其他任务只是项目经理角色的一个小型子集。
就像我说的那样，我不确定这是因为我错过了关于Scrum Po角色的关键了解，或者是因为它是因为我对BA角色有不同的期望。如果是前者，我想更好地了解我错过的部分。;-)
SVILEN DOBREV.
G'day。
很好的想法。
过去2年我做了这件事 - 非常纠缠和复杂（90k Python？）但低资源项目，我是领导者（也是公司中唯一的方法中的一个），事情变得非常粗糙。亚傅体育app
我没跟着scrum，而是通过Cockburn的Crystal清晰，而是相同，产品所有者角色成为噩梦。是的，他们必须多多！它们是纯软件与静止应用/市场和组织之间的前线。
所以我结束的是：商业分析师/专家，专家用户亚博vip9通道，产品经理，项目经理，架构师，GUI设计器，（以及结束测试）。在两个人之间分享，我和一位我正在奔跑的女士，既有大量的其他职责......不可能！
有人可能会说，上面的这个或那个角色实际上生活在其他地方……是的，但50%/50%。如果u按字母分开，信息必须更频繁地在更多的头之间移动，这将减慢项目!可能必须有3个人，因为有3个主要的涉众方向:开发、组织、最终用户;所有这些都要记住现在和未来。
在我看来，这些东西通常都被低估了，被低估了，如果你想的话，被低估了。
无论方法论如何，这些角色都必须在那里，你不能把它们全部纳入一个人的任何大项目（注意：很大只是在所涉及的人们的意义上，但是描述的现实）......那头头将爆炸。
玩得开心
svil
Mike Cottmeyer
凯文，
我听到你对角色的理解......但是一个赋权的BA与产品所有者不一样。Scrimumer不是一个敏捷的项目经理。
我不知道你是否阅读了这一个导致的6个帖子......但是我的根本断言是我们的许多传统角色都被提高了产品所有者的作用。
组织……我与25左右这过去的一年半…所有的挣扎与产品所有者角色因为1)没有足够的定义和明确我们真正问的这个人,我们需要他们的技能和2。)通常太大一个人的工作。
正如我写的那样......这是我可以等同于产品所有者的传统角色的最佳类比：我是一个带有外部客户的公司...我已为外部客户端分配一个项目经理以自己交付...项目经理负责收集要求，并具有权威的决策能力，使客户快乐。他们拥有客户要求，通常作为BA，他们自己交付。如果他们项目不符合客户预期，他们会被解雇。
问题是......一般或软件开发中的任何地方都不存在。
我的0.02美元。谢谢你的评论。
Mike Cottmeyer
Svil,
谢谢你的评论。我非常认同你。
麦克风
凯文布伦南
麦克风，
我认为至少有部分不同的是，我对BA的期望比你所做的更多...或者我也许我试图鼓励对自己的期望更高。
来自Babok V2：
“亚博vip9通道业务分析是用于在利益相关者中作为联络的任务和技术集合，以了解组织的结构，政策和运营，并推荐使组织能够实现其目标的解决方案。
亚博vip9通道业务分析涉及了解组织如何旨在实现其目的。它包括组织目标的定义，这些目标如何连接到特定目标，确定业务必须承担这些目标和目标的行动方案，并定义该组织内外的各种组织单位和利益相关者如何互动亚博vip9通道。
亚博vip9通道业务分析师必须综合由与业务交互的大量人员提供的信息，如客户、员工、IT专业人员和高管。”
我不确定，这正是你认为作为产品所有者的想法，但它看起来并不疯狂。
Erik Van Eekelen.
麦克风，
有趣的职位和意见。
我公司目前有9个Scrum团队为4-8人，宝宝角色绝对是一个人的工作太多了。所以这就是为什么我们在你描述的方式中有助于补助宝宝。
但是，如果您将其保留，如果BA实际上是在团队（猪或鸡）的内部或外部，则尚不清楚，因为他在其他用户故事中工作而不是团队。
这就是为什么我们已经同意的原因 - 由于分析师的拇指 - 50％的时间在为此Sprint工作的时间：回答开发人员的问题并在系统规范上工作（完成定义）。
另一半的时间花在帮助订单上，这些待办事项很可能会进入下一个sprint。
这似乎有效，但它尚未结束任何事情，我们刚刚完成了我们的第二次冲刺。
>>>
凯文，
正如我所看到的那样，BA角色和PO角色之间的主要区别在于，BA从客观的角度来看，特别是在桥接它和业务之间。亚博vip9通道
如果BA也有作为客户（PO）的角色，请呼叫镜头，S（他）不再是桥梁，而是代表商务代表。亚博vip9通道这会导致与它沟通时更摩擦，而不是我认为的好主意。
伊利克
马修卡纳纳
有趣的职位和我相信委派任务，而不是最终责任是可能解决纯粹宝角太大而无法处理的事实。
除了这个内部产品所有者团队（在处理大埔内心的面对职责的内部）之外，还可以争议组织设立另一委员会，以协助这些委员会在外部的外部。
我相信PO应该非常接近Scrum团队，因此PO可以通过建立一个PO外部团队来处理市场研究，产品定位，市场趋势，客户反馈，从而获得更多帮助处理外部职责。回应销售战略和其他利益攸关方管理。我们称之为产品董事会。
该委员会可以由其他部门的成员组成，如营销，销售，高级管理层，他们与外部世界不断接触。
通过向额外的论坛提供PO，并将这些不同的利益相关者通过产品举行讨论问题，我们可以确保PO对这些领域以及产品的所有方面负责，同时获得收集信息，处理和解决利益相关者冲突并分析市场形势更好。
鲍勃伊伯曼
我很高兴看到对宝团队的讨论，特别是认识到Scrum框架中描述的PO角色，其中呼吁超级英雄，其中很少有愿望甚至更少。
但是我不想要一个不包括交付团队代表(比如高级开发人员、架构师等)的PO团队。
I’ve found that conceiving of user features and stories without involving technical staff in discussions leads to: the appearance of late-breaking tech debt (on an urgency basis), stories designed for function rather than for reducing technical risk, and even poorly conceived solutions (for lack of the engineering point of view).
你的想法？
另外......没有一些团队协议，宝球队不会很好地运作。如果不是领导者，他们需要一个辅导员。这是罕愿发挥这个角色的罕见宝，Scrum Master是下一个可能的候选人。但是Scrum大师希望深入了解故事的概念吗？
想法？