如何增强Scrum Teams之间的协作(三)—— Product Owner Council(PO委员会)

  众所周知,Scrum Team里只有三种角色:Product Owner,Scrum Master,Team Members。因此谈到多个Scrum Team之间的协作时,CounterPart之间的协作问题就会顺理成章地浮现出来。本文先谈谈Product Owner之间的协作。

  如果在一个产品团队,不同Scrum Team的PO连对方最近的Sprint做了什么功能都不知道,那他们显然缺乏最基本的沟通,协作就更谈不上了。这个看上去很匪夷所思的现象,却真实的存在过。尤其是在一个分布式的团队里,也许更加常见。

 

  探寻解决的办法:Scrum是以Product backlog来驱动的,而PO就是这个backlog的拥有者。PO是一个站在客户及所有干系人(StakeHolder)的立场上做决策的人:要开发什么(What),什么时候开发(When,Prioritization)。一份backlog如果有多个“Owner”,而这些Owner又是平等关系时,往往不是个好主意,做决策时容易扯皮。那怎么办呢?两种做法:

  一,把产品按子产品、或者模块划分,自然而然Team也如此划分,然后各个PO各自拥有一份子产品的backlog,各自维护各自的,这样就容易出现上面提及的现象。除非子产品之间确实没有交集,那这种做法倒也不失为高效之举。

  二,对于一个各功能模块间互相有关联的大型产品,也许就需要另一个思路:一个产品只维护一个backlog,所有PO共享,但是通过成立一个“委员会”的方式,就是Product Owner Coucil。

 

  PO Coucil由一个核心PO作为Lead(委员长!),把其它PO,Customer,Stakeholder……都包含进来(也许还需要一个核心开发人员)。这个委员会完全可以使用轻量级的Scrum方法来运作:

  借鉴Scrum里的Plan meeting:审视Release Planning里要完成的Story。

  借鉴Scrum里的Sprint:超前于Developer的Sprint周期,维护一个Product backlog。比如把史诗拆分成Story;重新排序;决定下个Sprint中要开发的Story……

  借鉴Scrum里的Daily meeting:定期召开meeting来协调backlog。比如协调和同步Story开发情况、依赖情况;把Story从Team A转移到Team B……

  借鉴Scrum里的Retrospective meeting: 一个Release之后,举行回顾会议,看看在上个发布里,有什么是值得继续发扬的,有哪些失误,需要做哪些改进(包括backlog的维护;这个Coucil运作流程本身)……

 

  总结:多Scrum Team之间PO的协作方法,1,按子产品划分,一个子产品对于一个Team,一个PO,一份Product Backlog;2,如果子产品不够独立,则整个产品使用一份Product Backlog,所有PO紧紧围绕在以“委员长”为最高决策人的委员会周围,建设有XX特色的river crab社会……

你可能感兴趣的:(Scrum)