BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

产品负责人与团队该如何协作?

| 作者 Ben Linders 关注 27 他的粉丝 ,译者 张龙 关注 14 他的粉丝 发布于 2013年2月4日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

近日,由Henrik Kniberg撰写的博文agile product ownership in a nutshell从产品负责人的角度高度总结了敏捷软件开发。Henrik称其为“将一天的产品负责人课程压缩为15分钟的精彩介绍”。他建议大家观看一个关于敏捷产品所有权的视频,该视频提供了相应的脚本。下面介绍了该视频所涵盖的内容。

在Scrum中,利益相关者需要将使用用户故事表述的东西放在队列中。这个队列叫做产品订单,由产品负责人负责:

产品负责人决定将什么放进去,什么拿出来。产品负责人还会决定顺序——什么东西需要现在构建,什么可以放在后面进行?这个工作不好做,需要与团队和利益相关者协作完成。

产品负责人需要与团队协作来管理产品订单:

这些问题我一直在谈——估算故事的价值与大小、优先级、划分——所有这些通常叫做“订单梳理”。Pat会在每个周三的11:00到12:00召开订单梳理会。整个团队都会参加,有时一些利益相关者也会参加。会议议程会不断变化,有时关注点放在估算上,有时放在故事的划分上,有时还会为故事编写验收标准。

对于软件产品的开发来说,每个Scrum角色都会有自己的关注点:

各个Scrum角色之间应该保持健康的关系。产品负责人关注构建正确的东西。团队关注正确地构建东西。Scrum Master或是敏捷教练关注缩短反馈回路。

产品负责人应该与团队协作来平衡质量与进度:

如果团队积累了技术债务(没有编写测试、没有持续改进架构),那么团队的速率将会随着时间的推移变得越来越慢,故事燃尽曲线将会变平。这使得预测变得几乎不可能。因此,团队要负责保持可持续的节奏,产品负责人不应该对其施加压力导致其走捷径。

拥有多个团队的大型项目会有一个以上的产品负责人。产品负责人之间的协作是非常必要的:

但在多团队的情况下,产品负责人还有一个额外的重要职责——彼此交流!我们应该组织团队与订单以最小化依赖。但总还是会有一些依赖!因此,产品负责人之间应该进行某种同步,这样才能按照顺序构建,避免局部优化。

Mountain Goat Software在learning scrum – the product owner中介绍了产品负责人这一角色。产品负责人知道应该构建什么,并向Scrum团队表明这一点。团队会与产品负责人通力协作来确定在一个Sprint中应该开发多少内容。

产品负责人不能这么说“我们还有4个Sprint,因此你们必须在这个Sprint中完成1/4的产品订单”。产品负责人的工作是通过清晰、鼓舞人心的目标来激励团队。团队成员最清楚他们自身的能力,因此在任何一个Sprint中,他们都会从产品订单中选择可以交付的用户故事。

此外,产品负责人还会与团队就如何管理需求变更这一问题达成一致:

Scrum团队会承诺完成从产品订单中所选择的用户故事,作为回报,产品负责人也会承诺不在Sprint中抛出新的需求。需求可以变更(变更也是受鼓励的),但只能在Sprint之外变更。

Faisal Mahmood在博文should the product owner attend daily scrum, product owner and team engagement中讨论了产品负责人该如何与敏捷团队在会议中协作。Faisal解释了产品负责人为何要参加Sprint计划、Sprint评审与回顾会议中:

产品负责人会向团队描述产品订单条目(用户故事或是需求)。他与团队一起工作,确保大家对产品订单条目(或是用户故事等)范围的理解是一致的。产品负责人必须要参加Sprint计划会议,否则团队可能会选择低价值或是压根就没有价值的条目。这会导致浪费、混淆或是错失机会的状况发生。

Sprint评审是产品负责人接受或拒绝工作的最后机会。Scrum团队(产品负责人、团队与Scrum Master)与利益相关者会在Sprint评审中就产品方向、市场或是竞争状况中的变化进行讨论。该讨论会产生更新的产品订单。因此,我们说产品负责人必须得参与Sprint评审会议。

如果产品负责人不出席回顾会议,那么Scrum团队就很难改进计划Sprint、管理与更新产品订单、梳理产品订单的方式;此外,团队与产品负责人及利益相关者之间的交流方式,以及执行Sprint评审的方式也将变得难以改进。

Dean Leffingwell所创建的scaled agile framework可以在企业范围内应用精益与敏捷实践。它是这样描述产品负责人角色的:

产品负责人是团队中负责团队订单(即一般意义上的Scrum中的产品订单)并确定其优先级的成员。此外,产品负责人在质量上也有着一个重要的角色,他是团队中唯一一个有权向系统基线中“增加”新故事的人。对于向敏捷转型的大多数企业来说,这是个全新、至关重要的角色,通常需要全职参与才行(一般来说是每1到2个敏捷团队配有1个产品负责人)。

根据Dean所述,应用敏捷方法开发软件的企业必须得对多个产品经理、产品负责人与团队做出平衡:

从某种程度上来说,企业中成功的开发是一种数字游戏。如果没有在正确的角色上使用正确的人数,那么瓶颈将会严重限制速率。因此,产品经理、产品负责人与敏捷团队的数量必须要做到大致平衡,否则整个系统将会花费大量的时间在定义、澄清与接受上。

Marc Löffler在其博文5 reasons why a product owner team might be a good idea中谈到了产品负责人团队的好处。其中一个原因就是每个敏捷开发团队都应该有一个产品负责人:

曾经听过让Scrum Master来担任产品负责人的角色,那他要是不在了呢?这就是瞎搞!但真的就有人这么做,而且不止一个。这就是产品负责人团队存在的另一个原因。即便团队中有一两个成员不在(生病或是度假等) ,团队也依然能够继续。

Marc提到的另一个原因是产品负责人的团队协作可以改进订单的质量:

我知道并没有人规定只有产品负责人才能在订单中创建新的条目,但很多团队都觉得就该如此。产品负责人团队会迫使大家在一起工作。当然了,他们还需要与开发团队紧密协作,召开订单梳理会议,甚至是让开发者帮助维护订单等。产品负责人团队有助于培育团队的协作精神。

查看英文原文:How do Product Owners and Teams Collaborate?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

product backlog建议不要翻译为“产品订单” by 臧 秀涛

如题。backlog、sprint等词作为Scrum中的术语一般不翻译。这里的backlog也不是订单,有点像待做特性列表。

Re: product backlog建议不要翻译为“产品订单” by 龙 张

你好,像是product backlog在敏捷词汇中已经有大家约定俗成的译法,如果是再往前推若干年,这些词语可以不译,但现在这些词语的中译已经非常成熟,既然是中文,该译的就要译,不该译的就不能译。backlog从概念上理解就是待办事项,但反映在书面上,产品订单是一个非常普遍的译法。如果不清楚,可以参考维基百科:zh.wikipedia.org/zh/Scrum

Re: product backlog建议不要翻译为“产品订单” by 臧 秀涛

嗯,了解。但感觉这种译法好像词不达意。约定俗成就好。

Re: product backlog建议不要翻译为“产品订单” by 徐 毅

不知道维基百科上是谁在维护,但Product Backlog,我们在翻译相关书籍时一般都译作“产品列表”。因为Backlog是个中性词,就是“列表”一个。而“订单”,本身有“订”的意思在,但英文原文并无此意。希望能够考虑。至于Scrum的维基百科中文条目,我回头再联系人看看能否处理一下。

Re: product backlog建议不要翻译为“产品订单” by 龙 张

Hi,感谢回复,我现在也在翻译一本敏捷的书,其中书中出现的Product Backlog也都翻译成了‘产品订单’,出版社那边给出的词汇表也是这样,如果翻译成‘产品列表’其实我觉得倒是更加符合国人的习惯

Re: product backlog建议不要翻译为“产品订单” by 徐 毅

我也是一名译者,自己工作则是一名敏捷教练,希望能和你多多交流,不晓得你翻译的是哪本书啊?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT