LeSS 小型框架 vs 巨型框架 (Basic vs Huge)

时间:2023-01-11 07:58:27


​Scrum​​​: 大型企业规模化(​​LeSS框架​​)

​LeSS框架​​是scrum的放大版本,可帮助产品团队在大规模环境中实施Scrum。LeSS适用于在单个产品上一起工作的多个Scrum团队。LeSS提供了实验,指南,框架,原理和要素,以通过案例研究或从早期实施或不同环境中汲取的经验教训来帮助团队实施LeSS框架。它支持多团队以及(Mulit-Site)多站点敏捷开发。

符合Scrum惯例的LeSS框架提倡使用由单个产品负责人 (​​Product Owner​​​) 维护的单个产品待办事项列表 (​​Backlog​​​),常见的​​完成定义​​​(DOD)以及导致单个产品增加的同步迭代 (synchronized iterations)。产品负责人提供了优先的待办事项,并将其分发给跨职能 (​​Cross-functional​​​) 的​​Scrum团队​​。

LeSS通过将整个思维方式从如何执行流程转移(how to perform) 到为什么必须执行 (why the process must be performed) 流程,从而以简单的经验方法 (​​empiracal way​​) 来解决产品开发问题,从而帮助消除组织的复杂性,专注于意图 (intent) 而非单纯的实践 (practices)。它有助于实现所完成工作的价值,从而消除了传统方法中遵循的大多数不需要的过程和方法。该框架还自觉地避免引入其他角色,人工制品和文档,以避免复杂性,例如流程的数量,团队倾向于在开发中失去人类的触觉,这与敏捷的基本原理大相径庭。当流程轻松进行时,团队将能够专注于与所有利益相关者的互动和协作,从而实现有效的,基于价值的交付。

LeSS-框架

LeSS提倡两种类型的敏捷扩展:

LeSS Basic:

LeSS Huge: 

 

LeSS Basic

当产品的复杂性最小且涉及两到八个Scrum团队时,将使用LeSS Small Framework。除Scrum团队外,LeSS团队还包括一个负责所有Scrum团队的产品负责人和一个负责多达三个团队的Scrum Master。这些团队是跨职能的,在共享的代码环境中致力于创建完成的项目。产品负责人维护单个产品待办事项,并将优先处理的项目级联到Scrum团队,

LeSS Huge

当Scrum团队超过8个时,将采用LeSS Huge。本质上是将多个LeSS框架堆叠在一起。由于总体输出是单个产品,因此LeSS Huge还提倡单个产品积压,相同的冲刺持续时间以及所有团队致力于单个交付。

单个产品待办事项与各个区域产品负责人分为多个需求区域。需求区域是以客户为中心的类别。区域产品负责人又是各自需求领域的主题专家。区域产品负责人由产品负责人小组组成,将共同负责优先级划分,尽管范围和时间表仍将仅由产品负责人决定。产品负责人将功能分为特定需求区域,如区域积压,

LeSS中的事件

冲刺计划 (​​Sprint Planning​​):

在LeSS中,Sprint计划分为两个级别。Sprint计划一集中在Sprint中需要完成哪些项目,而Sprint计划二则在Scrum团队级别上进行,并着重于这些选定项目的交付方式。

  • Sprint Planning - Part I(所有团队共同使用)- 
  • Sprint计划 - Part II(每个团队分别完成)- 

 

产品待办事项列表细化 (​​Product Backlog Refinement​​):

通常,团队不迟于Sprint的中间,团队需要开始为下一个Sprint计划项目。这将涉及:

 

待办事项的提炼分为三个级别:

  • 总体产品待办事项列表细化- (Overall Backlog Refinement) 
  • 团队级产品待办事项细化 (team level Product backlog refinement)- 
  • 多团队产品待办事项细化 (Multi-team Product Backlog Refinement) - 

 

冲刺回顾 (​​Sprint Rview​​):

在LeSS中,Sprint审查是像“ Bazar”或Fair一样的盛大活动,每个团队都被分配一个站来展示他们在该Sprint方面的成就。参加者可以访问他们感兴趣的站点。利益相关者总结交易会的意见将有多个融合周期。

冲刺回顾 (​​Sprint Retrospective​​):

与Sprint计划一样,Sprint回顾展也分为两个阶段。在sprint结束时,团队会定期进行Sprint回顾,在该团队中,回顾过去的sprint的经验教训,并检查以及需要采取哪些措施才能更快,更好地交付。第二次回顾是在单个团队回顾之后进行的。通常,这是在下一个冲刺开始时进行的,

 

References