整理Backlog的困惑

0
241

作者:刘华Kenneth

转自:https://mp.weixin.qq.com/s/lMVQW9hhTUydDDE9v1HStA

我们一直在探讨能否采纳《以社交活动的方式做计划-乐高公司的规模化敏捷》(对此文有兴趣的朋友请点击“阅读原文”)的方法。

目前,我们交付团队人员的分配依然主要以项目预算作为依据,但这样会陷入以项目为边界的局部优先级迷思,缺乏全局视角。同时,不同业务部门存在无序竞争有限的交付团队人员的情况,也有大量的在制品堆积,人都很忙,但价值却不明确。

我们希望:

  1. 每个月组织业务干系人形成“议会”对我们部门来自不同项目的所求需求进行排序;
  2. 根据交付团队人员的情况,限制在制品,确定本月应该交付哪些需求,实现全局的价值驱动交付;

然而要实现这个想法,首先要整理一个Backlog,方能组织业务干系人进行讨论和排序。这看似容易的事情却让我们卡了壳。

目前我们面对的项目类型有:

  • 有明确交付期限的大项目
  • 监管需求项目
  • 接入新客户和业务流程优化的小项目
  • 对现有系统的运维

这些项目需求来自不同的业务部门,总体上来说,按照项目的重要程度以及预算,我们的人员大部分都分配在那些大项目上,或者说,当我们问优先级时,总是被告知那些大项目的优先级最高,但这样的回答并没有解决问题,因为不时冒出的监管需求,接入新客户和业务流程优化的小项目也在争夺有限的资源,导致人员分配陷入无序状态,需要不断调剂人员安排。简单来说,以项目为粒度的优先级排序没有意义,除非优先级低的项目一律不做,但这并不会发生。这也会导致由于没有跨项目的全局视角,我们大部分人员因为项目切割,实际可能在做一些在当前全局看来价值并不是最高的交付,造成巨大的资源浪费。

那么我们希望用来排序的Backlog是以用户故事为粒度的。但是从JIRA把现有的用户故事拉出来就傻眼了。我们一共有上千来自不同项目的用户故事在Backlog中,这样的Backlog摆在业务干系人面前是没有意义的,迷失在细节中,也是无法排序的。

所以我们需要一个在用户故事到项目之间一个合适粒度的东西,业务能看懂,对全局意义明确,让业务干系人一眼就能确认这个是否应该在本月做,对交付团队又是可执行的。我也曾经考虑过Epic是不是一个选项,但是Epic的粒度还是太大,它必然包含必须的和增值的用户故事,而且这也要求不同团队Epic的粒度要统一,这又是一个难点。

目前,这对我来说还是一个没有答案的问题,欢迎大家留言给建议。

关于作者


  • 就职于世界500强银行,负责基金服务业务软件开发与交付
  • 敏捷、精益、DevOps专家
  • 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈
  • 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会等论坛发表主题演讲
  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书

- leansoftx.com -