整理Backlog的困惑

最新推荐文章于 2021-10-27 12:00:41 发布

kenneth_h_liu

最新推荐文章于 2021-10-27 12:00:41 发布

阅读量394

点赞数

本文链接：https://blog.csdn.net/kenneth_h_liu/article/details/98861741

版权

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

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

我们希望：

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

640?wx_fmt=png

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

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

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

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

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

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

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

关于作者