03-【规模化敏捷】Less huge与Less区别和联系

上一篇我们介绍了Less框架的基本结构，说明了Less与scrum的区别和联系，在第一篇中我们就有提到过，当团队规模超过8个时需要运用Less Huge框架进行管理，那这一节我们就通过对Less和Less huge的对比，介绍下Less Huge框架的基本属性。

角色

在less中我们已经强调过框架中希望只有一个产品负责人来统一规划和管理产品，那如果团队的规模已经超过8个，一个产品负责人似乎很难管理好如此大范围的产品方向和内容，所以在less huge中增加了APO（Area PO）的概念，也就是领域产品负责人，这里需要重申一下，虽然增加了领域产品负责人的角色，但是PO仍然是产品的拥有者，顾名思义，领域产品负责人是负责某一个领域的产品管理，他负责该领域的产品待办事项列表的管理工作，但是整体上依然要遵循PO的产品规划和要求，另一个角度来说，PO和APO组成了产品管理团队，通过这样的运作机制更好的管理超过8个团队的产品。

工件

既然增加了领域产品负责人的角色，那必然对工件产生影响，在产品待办事项列表中增加了领域属性，这里有一点需要大家关注，这里的描述是增加了领域属性而不是增加了领域的产品待办事项列表，这一点说明产品待办事项列表还是只有一份，只不过通过领域属性增加了领域的视图。这一点希望读者可以细细品味，理解这样设计的含义。

less huge的会议管理

首先需要说明的一点是，less huge与less 一样遵循共同的sprint交付共同的产品增量的基本原则，但是关于计划会议、评审会议和回顾会议less huge并没有强制要求一起进行，也就是说当有需要时不同领域的团队可以一起进行规划、评审和回顾，但是并没有强制的要求，因为less觉得这样的机制会增加复杂性，最简单的例子所以团队代表一起开计划会议会议室的协调都非常困难（而这一点与SAFe框架有明显的区别）。

为什么要用less huge

从上面的描述中我们知道less huge对角色和工件做了调整，但是为什么当团队的规模超过8个时就要做这样的变化呢，如果不进行调整又会带来什么问题？
1、产品待办事项列表复杂度增加 其实不难想象当团队的规模过大时，产品待办事项列表中的内容会非常对，依靠一个产品负责人进行规划和管理是非常耗时和低效的，所以需要由APO帮助产品负责人进行梳理和管理以满足快速迭代的目标；
2、团队规模过大当团队规模足够大时，产品负责人要对接多个团队，不同团队的个性化沟通需求，让产品负责人无法应对，也就需要AAPO代替产品负责人进行对接，同时APO可以更加专注于具体的领域，逐步产生你专业性继而提高工作效率；
3、团队响应迟缓当团队规模过大时，团队的响应速度毕竟会变得迟缓，这类似于组织架构的演变，如果是一个初创公司组织结构简单、扁平化，当团队发展越来越好规模逐渐变大时，自然就会演变出很多部门和团队，继而出现很多管理和辅助角色来推动组织活动，APO的产生也是一样的道理，不过less依然强调尽量简洁化，不希望因为APO的引入增加组织结构复杂性；

总结

所以通过这一段描述大家应该已经清楚，less huge可以理解为更多的less团队一起工作，每一个领域就是一个用less框架管理的团队，不同less团队之间通过PO和scrum master进行管理和协调。在less中我们说过，一个scrum master可以服务于1-3个团队，这就要求团队的成熟度相对较高，另外在less huge中为了确保不同领域之间的团队能够更好地学习和合作，建议scrum master负责的团队可以覆盖到不同的业务领域，这样能够更好地促进less huge机制的更好运作发挥scrum master的价值。通过最近几篇文章的介绍，读者应该能够感受到less的结构还是比较清晰的，那么除了上述的内容之外，less还有哪些内容需要大家关注呢？下一遍文章继续进行探讨！

标签：03,huge,Less,less,领域,产品,团队
来源： https://blog.51cto.com/13676635/2589440