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

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:

     最多支持8个团队(每个团队八个成员)。最适合于每个团队的规模为8到10,且总共有8个或更少团队的并置团队。
  • LeSS Huge: 

    支持多达数千个人为单个产品做出贡献。它支持同一地点和多地点或多站点团队,但是建议每个Scrum团队都位于同一地点。

 

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开始之初,所有团队的所有成员都参加了Sprint Planning One。但是,随着sprint的成熟和对团队的了解的提高,只有每个团队的代表都可以参加Sprint Planning One活动。产品负责人和团队或每个团队的代表参加了这次会议,他们从产品积压中选择了将要用于下一个冲刺的项目。
  • Sprint计划 - Part II(每个团队分别完成)- 

    在团队(从Sprint计划一)选择项目之后,团队将举行自己的Sprint计划二会议。当团队之间存在强烈的相互依存关系时,这些团队将执行合并的Sprint计划二,以识别相互依存关系并弄清楚如何有效地处理它们。在会议结束时,团队将更加清晰地了解每个团队在该冲刺中要完成的工作,并且每个团队都将朝着各自的冲刺进行工作。

 

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

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

  • 拆分项目 (Splitting Items)

    可以分成单个冲刺的较小块
  • 详细说明 (Elaborating the Items)

     以及更详细的要求和验收标准详细信息,直到团队认为该项目已“完全”准备好为即将到来的冲刺而挑选
  • 估算工作量 (Estimating the effort)

     最终使完成的商品“完成”所需的商品

 

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

  • 总体产品待办事项列表细化- (Overall Backlog Refinement) 

    在这里,所有团队的代表以及产品负责人决定下一个冲刺的项目。该活动旨在对冲刺项目达成共识,并使团队能够全面了解团队成员之间的依存关系。然后,团队深入研究项目,并与产品负责人和主题专家一起阐明要求。
  • 团队级产品待办事项细化 (team level Product backlog refinement)- 

    在全面了解冲刺需求之后,团队可以考虑他们的特定积压,并在下一个冲刺中挑选出更多的物品。团队的所有成员,不仅是代表,都参加了此活动。这也确保了在整个产品积压细化练习中获得的理解被级联给所有成员。积压的任何更改都将通知产品所有者,例如项目拆分或新的估算。
  • 多团队产品待办事项细化 (Multi-team Product Backlog Refinement) - 

    在团队与其他团队相互依赖的情况下,LeSS建议进行多团队产品待办事项优化会议。在此会议期间,涉及的多个团队在同一房间(通常是大大厅)中进行精炼。团队进行“ Just Talk”交流,对他们的依存关系进行排序,并就如何解决这些项目达成共识,而对每个项目的干扰很小或没有中断。

 

冲刺回顾 (Sprint Rview):

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

冲刺回顾 (Sprint Retrospective):

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

 

References

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章