对于软件产品的开发来说,每个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评审的方式也将变得难以改进。