规模化敏捷 LeSS(三):LeSS Huge 的秘密
- 2021-08-03 11:02:17
- yanruiyu 原创
- 5213
上篇文章《 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 强调的更加灵活的团队便是要着重实现这一点。
文章分类
联系我们
- 联系人:阿道
- 联系方式: 17762006160
- 地址:青岛市黄岛区长江西路118号青铁广场18楼
投稿邀请
如果您有优秀的原创文章,欢迎添加联系人直接与我们联系,或通过下方邮箱发送投稿文章,一经采用,我们会付以一定的稿件报酬。
- 投稿邮箱: yanruiyu@easycorp.ltd
- 投稿标题:向 [敏捷开发] 网站投稿
- 稿件要求:与敏捷开发相关的任何内容
更多投稿相关请点击 更多进行了解~