规模化敏捷 LeSS(三):LeSS Huge 的秘密

2021-09-07 09:00:00
yanruiyu
转贴:
https://www.minjiekaifa.com/article/large-scale-scrum-huge-80331.html
147
摘要:8个以上的团队要如何实践敏捷呢?

上篇文章《 LeSS 团队实践指南》中讲到 LeSS 框架中的团队数量不要超过8个,但8个以上的团队要如何实践敏捷呢?


为了应对8个以上团队实践敏捷的情况,Bas 以及 Carig 还提出了 LeSS Huge:一个通过在多个小型 LeSS 框架堆叠的基础上扩展的规模化敏捷框架。

一、需求领域


LeSS Huge 按照产品中的客户需求,划分出不同的需求领域,每一需求领域由几个相应的功能团队组成。也就是说,需求领域是按比例放大的功能团队。


举一个例子来进一步说明需求领域:在一个小型的保险团队中,会有合同承保、合同修改以及索赔三个功能角色,LeSS Huge 中可以将一个大型保险团队分为合同承保、合同修改以及索赔三个需求领域,每一领域有几个相对应的功能团队。这里要注意的是,需求领域具有临时性,会根据产品的需求在整个生命周期内进行调整(不会在每一迭代中改变)。

二、产品负责人团队


首先需要解决一个产品负责人无法协调众多团队的问题。LeSS Huge 增加了产品负责人团队的概念:划分不同的需求领域,每一需求领域增加一名区域产品负责人,该区域产品负责人会对该需求区域的产品需求做出优先级决定。

由于需求区域大小不同,每个区域会包含不同数量的团队,团队太小会导致积压事项,团队太大则会导致区域产品负责人无法协调,因此一个合理的需求区域所包含的团队数量在4-10之间。

产品负责人团队由产品负责人主导,即产品负责人始终拥有最终决定权,且产品范围及产品发布时间仍由产品负责人决定。

三、区域产品待办列表


针对某一需求领域归纳整理出该领域的产品待办列表,这一事项由该区域产品负责人负责。相比产品待办列表而言,区域产品待办列表内包含的是更易于管理、颗粒度更细的项目。但如果区域产品待办列表与产品待办列表出现很大的差异的时候,就需要考虑重新整理产品待办列表了。

四、一个产品级 Sprint


同 LeSS 框架一样,LeSS Huge 框架中所有团队都处于一个 Sprint 之下,又以交付一个集成的整体产品增量结束。

其次,无论是 Sprint 计划会议2、Sprint 评审会议还是 Sprint 回顾会议,都可以以一个需求领域为单位来组织会议活动。为了对齐计划与进度,区域产品负责人要经常与产品负责人同步,从而及时发现团队方向是否出现了偏差,团队是否处理的是最有价值的项目等。

五、由点到面的 LeSS Huge 实践


由于团队规模庞大,实现一次性采用 LeSS Huge 框架会有很大的风险,因此,LeSS Huge 的实践应循序渐进地进行。

首先,应先完善一个需求领域,其次逐步扩大团队的工作范围以及完成的定义,与此同时,让其他团队做好转型的准备,逐步适应 LeSS Huge 框架,实现由点到面的规模化敏捷转型。规模化敏捷实践的转型往往需要很长时间,急功近利并不可取。

LeSS Huge 在 Scrum 以及 LeSS 的基础上,重新扩展了敏捷框架,降低了大型团队管理的复杂。其中,最重要的还是团队之间的协作性与互通性,而 LeSS 强调的更加灵活的团队便是要着重实现这一点。
联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105