精华内容
下载资源
问答
  • less 敏捷
    2021-08-05 10:07:02

    上篇文章《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 强调的更加灵活的团队便是要着重实现这一点。

    往期文章列表:

    规模化敏捷LeSS(Large Scale Scrum)的诞生
    规模化敏捷LeSS(二):LeSS团队实践指南
    规模化敏捷 LeSS(三):LeSS Huge 的秘密

    更多相关内容
  • 正是由于其灵活性,Scrum 方法现已成为团队软件交付方法的首选,近期发布的15届敏捷状态报告也显示,66%的受访者及其所在的敏捷团队最常用 Scrum 方法。 但随着敏捷在团队中得到越发广泛的实践,越来越多的人意识到...

    Scrum 能够帮助一个5-9人的小团队以迭代增量的方式开发产品,在每一迭代结束时,交付潜在的可交付的产品增量。正是由于其灵活性,Scrum 方法现已成为团队软件交付方法的首选,近期发布的15届敏捷状态报告也显示,66%的受访者及其所在的敏捷团队最常用 Scrum 方法。

    但随着敏捷在团队中得到越发广泛的实践,越来越多的人意识到全组织规模化敏捷实践在当下带来的机遇。但当人们简单地将 Scrum 套用到多团队实践中的时候,又出现了各种各样的问题。为了解决大规模开发团队的敏捷应用问题,一款多团队的规模化敏捷框架 Large Scale Scrum(LeSS)应运而生。
    在这里插入图片描述

    在之前的文章中,介绍过 LeSS 的“诞生”,在此就不再赘述。在这篇文章中,我们会详细聊一下 LeSS 的具体实践:

    一、框架

    为了让框架更好地应用到多团队中去,Bia 和 Craig 两人决定要尽量避免向框架内添加角色、工件、流程等情况,防止因过多的定义而限制团队的经验实践。其中,他们还提出了“守、破、离”三个阶段:
    守:在守的阶段,要先打基础,这时候团队的行动是循规蹈矩的;
    破:在破的阶段,要善于打破规则,发现适合自己的情境;
    离:在离的阶段,要学会逐渐找到适合自己团队的方式。
    基于此,LeSS框架保留了Scrum的许多实践与想法,如产品负责人、开发团队、Scrum Master三角色,以及Sprint计划会议、每日站会、回顾会议等。尽管这些概念与Scrum中的实践相同,但侧重点会有所不同。

    1.产品负责人

    产品负责人有两个关键的职责:一个是对产品待办列表中的事项进行优先级排序,另一个是与团队合作澄清产品待办列表中的事项。
    在这里插入图片描述

    澄清产品待办列表中事项需要产品负责人在团队与用户/客户之间担任桥梁的作用,帮助团队与用户/客户直接对话,避免产生产品的需求理解分歧。

    2.团队

    团队的要求在前一篇文章有也有提到过,主要是自管理的、跨职能的、专注的、长期存在的,以及共处一地的。这将会让团队中的每位成员为实现团队的共同目标,决定自己如何去做。

    3.Scrum Master

    在LeSS框架中,Scrum Master需要作为一个全职角色来帮助团队解决过程中遇到的困难。一名Scrum Master最多可管理3个团队。

    二、Sprint

    LeSS中的Sprint是产品级的Sprint,这意味着,各个团队处在同一Sprint中,而在这一Sprint结束后,多个团队将交出一个集成的潜在可交付产品增量。这意味着,所有团队的Sprint计划会议、Sprint评审与回顾会议都是同时进行的。在具体的实施层面,LeSS又给出了一套应用流程:
    在这里插入图片描述

    1.产品待办列表细化会议

    产品待办列表细化会议(PBR)分为三层:

    1)整体PBR

    整体PBR是一个简短的整体产品待办列表细化会议,主要包括产品负责人以及所有团队成员。这一会议主要为团队分配要实施的事项。

    2)多团队PBR

    在LeSS中,多团队PBR通过专家、用户/客户、产品负责人、团队成员的共同参与,来推进Sprint,提高跨团队的适应性。多团队PBR一般只有两个团队。

    3)单团队PBR

    但团队PBR在LeSS中比较少见,一般会应用在巨大且模糊不清的项目背景下,需要先让一个团队清除迷雾,后续逐步加入其他团队的情况中。

    2.Sprint计划会议

    Sprint计划会议分为两部分:

    1)Sprint 计划会议1

    这一会议是所有团队的会议,会议将划分各个团队的具体工作事项。如果团队的数量较少,可以全体团队成员参与这一会议。如果有两个以上的团队,则需要每个团队派出一个团队代表(除Scrum Master外)参与会议。

    2)Sprint计划会议2

    这一会议是各团队内部的会议,团队在此会议上制定自己团队的Sprint计划。有时为了团队之间的分享与学习,两个或多个团队可能会在同一房间的不同区域举行自己团队的计划会议。
    在这里插入图片描述

    3.每日站会

    与Scrum中的每日站会不同的是,其他团队的成员可以加入该团队的每日站会,进行信息共享,更好地协调团队之间的合作。

    4.Sprint评审会议

    Sprint评审会议需要所有团队一起评审该Sprint交付的潜在可交付产品增量,应实现所有人就产品进行协作的机会。这里的所有人指的是除产品负责人之外,还包括团队成员、利益相关者等。

    5.Sprint回顾会议

    回顾会议最长持续45分钟,分为两种情况:其一是团队内部展开回顾会议,其二是产品负责人、Scrum Master、团队代表进行整体回顾,主要讨论跨团队的协作、系统问题。

    与Scrum一样,在一整套带有流程的框架下,LeSS提供了足够的具体实践,以及足够的灵活性以及扩展性,帮助大规模团队探索自己的敏捷之路。在此基础上,大规模团队可以调整团队实践,最终打造出真正适合自己的规模化敏捷实践。

    此外,还要注意的一点是,LeSS框架更适合于8个以下的团队数量,如果团队数量超过8个,就需要应用LeSS Huge框架。具体LeSS Huge框架是如何应用的呢?详见下一期。

    往期文章链接:

    规模化敏捷LeSS(Large Scale Scrum)的诞生
    规模化敏捷LeSS(二):LeSS团队实践指南

    展开全文
  • 大规模Scrum(Large-Scale Scrum,LeSS)是应用于共同开发统一产品的许多团队的Scrum。LeSS研究的是如何在大规模环境中,尽可能简单地应用Scrum的原则、规则、要素和目的。LeSS的核心仍然是采用Scrum,在尽量不增加...

    大规模Scrum(Large-Scale Scrum,LeSS)是应用于共同开发统一产品许多团队的Scrum。LeSS研究的是如何在大规模环境中,尽可能简单地应用Scrum的原则、规则、要素和目的。LeSS的核心仍然是采用Scrum,在尽量不增加角色的前提下,考虑在一个产品、一个产品待办列表、一个产品负责人下,多团队如何进行迭代。大规模Scrum包含两个框架,一个是小型LeSS(支持2~8个团队,8~81人),一个是巨型LeSS(支持8个以上团队)。

    LeSS十大原则

    LeSS的十大原则可以分成4类

    1.单一产品

    (1)聚焦完整产品(Whole Product Focus)——一个产品待办事项列表、一个产品负责人、一个可交付产品、一个迭代,无论是3个团队还是33个团队。

    (2)以客户为中心(Customer Centric)——识别付费客户眼中的价值和浪费,从他们的角度减少周期时间,增加与真实客户的反馈回路。每个人都了解他们今天的工作与付费客户的关系。

    2.按Scrum迭代

    (1)大规模Scrum仍是Scrum(Large-Scale Scrum is Scrum)——LeSS是纯粹的Scrum,Scrum有什么,LeSS就有什么。

    (2)透明度(Transparency)——基于客观的、有形的“完成”条目、短周期、协同工作、共同定义,以及对工作场所恐惧的消除等,使工作进展、风险、问题等变得更加透明。

    (3)经验过程控制(Empirical Process Control)——持续检查和调整产品、过程、行为、组织设计和实践。

    3.消除浪费持续改进

    (1)持续改进以求完美(Continuous Improvementtowards Perfection)——为“完美”目标做无尽的谦虚和激进的改进试验。

    (2)精益思想(Lean thinking)——精益思想屋的基础是管理者作为老师,来应用和教授精益思想及管理改进;支柱是尊重人和持续挑战现状来改进的心态;屋顶是精益思想的目标,即朝着“完美”目标前进。

    4.组织和运作设计

    (1)以少为多(More with Less)——更少的流程,团队会有更多的学习;更少的浪费和开销,团队可以产出更多的价值;更少的角色、工件、特定部门,团队会更自主、更负责任、具有远大目标,以及可以离客户更近。

    (2)排队论(Queue Theory)——在动态变化环境中,小批量规模、短队列及限制在制品,带来较短周期时间(快速交付价值),以及减少变异性。

    (3)系统思考(System Thinking)——观察、理解和优化整个系统而不是局部优化,并使用系统建模来探索系统的动态。避免将重点放在个人和单个团队的效率或生产力上。客户关心的是整体上从概念到盈利的周期时间,而不是单个步骤,局部优化一个部分并不一定能对整体产生积极影响。

    小型LeSS

    小型LeSS框架如图所示,与Scrum一致,针对多个小团队做了最小化的扩展。

    资料来源:https://less.works/zh-CN/less/framework/index.html

    1.小型LeSS的3个角色

    (1)只有一个产品负责人——所有的优先级排序都通过产品负责人但是澄清尽量由团队和客户/用户及利益相关者直接进行。这也正是为什么只有一个PO的原因。

    (2)2~8个特性团队,每个团队3~9人——每个团队是自管理的、跨职能的、在同一地点的、长期的。

    (3)每1~3个团队设置1个Scrum Master,共1~8个ScrumMaster。Scrum Master是一份专职和全职工作,不只关注一个团队,而是整个组织系统。

    注:LeSS包含的人员共8~81人。

    2.小型LeSS的3个工件

    (1)一个且只有一个产品待办列表;

    (2)每个团队有自己的迭代待办列表;

    (3)一个且只有一个潜在可发布产品增量。

    3.小型LeSS的事件

    (1)迭代(Sprint)——有一个产品层面的Sprint,而不是每个团队有不同的Sprint。每个团队同时开始和结束一个Sprint。每个Sprint产出一个集成的完整产品。

    (2)迭代计划会议(Sprint Planning)——小型LeSS计划会议与Scrum的迭代计划会议的目的,以及要解决的问题是一样的,也分为两个部分,只不过具体的形式有所变化来适应多团队的情况,如图所示。

    资料来源:https://less.works/zh-CN/less/framework/sprint-planning-one.html

    迭代计划会议第一部分(Sprint Planning 1,SP1)——由所有团队成员或者团队、产品负责人、Scrum Master参加,他们一起试探性地选择每个团队将在下一个Sprint工作的待办事项,以及定义各团队的迭代目标。团队会识别一起合作的机会,并澄清最终的问题。

    迭代计划会议第二部分(Sprint Planning 2,SP2)——由各团队并行地执行,来决定如何完成所选择的待办事项。对那些相关性强的条目,也经常采用在同一房间内进行多团队迭代计划会议,即并行地进行SP2。

    (3)每日站立会议(Daily Scrum)——每个团队有自己的每日站立会议。跨团队协调由团队决定。每日站立会议倾向于分布式和非正式协调而非集中式协调。

    (4)产品待办列表梳理会议(Product Backlog Refinement,PBR)——团队利用研讨会的机会与用户和利益相关者澄清后续要做的待办事项,包括拆分大的待办事项、澄清待办事项直到准备好可以迭代开发、采用相同的单位进行相对故事点估算等。LeSS产品待办列表梳理会议如图所示。

    资料来源:https://less.works/zh-CN/less/framework/product-backlog-refinement.html

    总体产品待办列表梳理(Overall Product Backlog Refinement)——决定将由哪个团队来做哪些待办事项,并做进一步的深度梳理。参加人员:团队代表或者所有团队成员、产品负责人、Scrum Master或者领域专家等。

    单团队产品待办列表梳理(Team-level Product Backlog Refinement)——和Scrum一样,参加人员为单团队所有成员、Scrum Master,没有PO,但是有用户、客户或者利益相关者等。

    多团队产品待办列表梳理(Multi-team Product Backlog Refinement)——两个或者多个团队的所有成员、ScrumMaster、用户、客户或者利益相关者一起梳理一组相关的待办事项。从每个团队抽取人员组成临时混合小组,在同一个房间的不同区域并行进行梳理,“30分钟”时间盒之后,每个区域留下一两个人,小组其他所有成员轮转到下一个区域进行梳理。留下来的人通常包括客户、用户或其他利益相关者。之后合起来分享见解和协调。

    (5)初始产品待办列表梳理会议(Initial Product Backlog Refinement,IPBR)——初始PBR针对一个产品仅做一次初始PBR。在第一次迭代之前,或者在第一次转型到Scrum的时候,进行初始PBR,来定义愿景、发现待办事项、拆分大的条目、澄清待办事项直到准备好可以迭代开发及完成的定义(DoD)。参加人员:产品负责人、Scrum Master、所有团队所有成员、客户、用户、领域专家等。

    (6)迭代评审会议(Sprint Review)——小型LeSS的迭代评审会议和Scrum一样,在迭代结束的时候对潜在可交付的产品增量进行评审。参加人员:产品负责人、Scrum Master、小Scrum团队所有成员、客户、用户、领域专家等。LeSS迭代评审会议如图所示。

    资料来源:https://less.works/zh-CN/less/framework/sprint-review.html

    可以采用迭代评审集市(Sprint Review Bazaar)方式。

    分散方式探索:各团队并行在同一个房间内不同区域分别演示潜在可交付的产品增量,和产品负责人、用户、客户及利益相关者讨论。

    聚合方式决定产品方向:全体人员对下一个迭代的方向,讨论变更和新的创意等。

    (7)回顾会议(Retrospective)——在迭代结束的时候对工作方式进行迭代回顾。首先每个团队都召开自己的团队回顾会议(Team Retrospective),与Scrum的迭代回顾会议一致。之后,进行全体回顾会议(Overall Retrospective),这个会议由产品负责人、所有的Scrum Master、各团队代表和管理者(如果有的话)参加。LeSS迭代回顾会议如图所示。

    巨型LeSS

    当开发一个产品所需要的人数超过8个团队时,就需要巨型LeSS框架。巨型LeSS包含了多个并行的小型LeSS。巨型LeSS全景图如图所示。

    资料来源:https://less.works/zh-CN/less/less-huge/index.html

    展开全文
  • 本文以多个维度不同视角向你呈现Scrum@Scale 、LeSS 和SAFe三个规模化敏捷框架的共性和各自的特点。

    引言

            本文以多个维度不同视角向你呈现Scrum@Scale 、LeSS 和SAFe三个规模化敏捷框架的共性和各自的特点。包括Scrum团队容器、沟通机制、沟通饱和度、适应性、系统思考、实施路线图、原则、角色、DevOps、Product Owner、实践者,11个维度可以分为三类受众。 Scrum团队容器、沟通机制、沟通饱和度是设计规模化敏捷框架的重要元素,这三个维度能为敏捷推动者设计框架提供参考。适应性、系统思考、实施路线图、原则四个维度企业决策者会比较关心。角色、DevOps、Product Owner、实践者属于框架的角色和认证的共性,对实施层面的朋友可能会有所帮助。

            本文作者孔兆祥,由Jim Wang审校,文章分为上中下三篇,本篇是《洞悉规模化敏捷框架》上篇。作者从自己的视角尽可能做到文章观点的中立和完整的剖析,如果你对本文和规模化敏捷有其他见解,欢迎留言与作者互动。

    1、规模化敏捷框架

    1.1

    Scrum@Scale

    图片

    (图1:Scrum@Scale框架的组件透视图)

            Scrum@Scale由Jeff Sutherland设计,也是Scrum框架的发明者。从框架的组件透视图看到,Scrum@Scale框架由一个Scrum Master Cycle和一个Product Owner Cycle的工作闭环流程组成,中间有Executive Action Team(EAT)和Executive Meta Scrum(EMS)两个组织,这两个组织是整个框架的核心。 框架看上去都很容易理解,那么它有什么独特之处呢?究竟它与其它框架有什么不一样?它背后的设计逻辑是怎样的?它的沟通机制是怎样的?

    1.2

      LeSS (Large Scale Scrum)

    图片

    (图2:LeSS框架的组件透视图)

            LeSS由Craig Larman和Bas Vodde共同设计,框架基于Scrum进行扩展,通过大大量的实践经验,糅合精益思想沉淀而成,支持企业以敏捷的方式进行大型产品研发,是一个轻量级的规模化敏捷框架。

    1.3 

    SAFe (Scaled Agile Framework)

    图片

    (图3:SAFe框架的组件透视图)

            SAFe的设计和主要方法论由Dean Leffingwell主导,是另一个流行的规模化敏捷框架,特点是将敏捷实践在企业中分层而治,从团队级(Team level)到项目群级(Program level)乃至投资组合级(Portfolio leve),糅合精益-敏捷知识体系。

    2、规模化敏捷框架的11个维度分析

    2.1

    Scrum团队容器(Scrum Team Container)

            在计算机领域对容器的解释是,容器是用来存储和组织其他对象的对象。 那么在规模化敏捷框架上下文中,Scrum团队容器(以下简称团队容器)是指在框架中用来容纳敏捷团队的一个对象,在规模化敏捷框架并没有清晰地定义出这个概念,但笔者认为它是存在的,它很显式地体现在框架的组织设计当中,在框架设计时是抽象的,在实践以组织架构形式实例化。所以可以这么认为,团队容器就是一个企业的组织架构。规模化敏捷的组织架构设计与传统组织有很大的区别,企业要扩大敏捷的范围,自然会涉及更大范围的的组织变革,所以每一个规模化框都会有组织变革措施,但企业组织变革往往是规模化敏捷最大的障碍,因为企业的组织架构就是它的中枢神经。组织变革的过程就像科幻片里的情节,人类研发并植入外星的基因,想创造出新的物种,目的都只有一个,就是为了更好地活下去。同样,在企业规模化敏捷上下文中,我们可以把企业组织看作一个系统,敏捷就是一种新型基因,当我们尝试植入这种基因时,组织自有的免疫系统开始可能会产生抵触,极端情况甚至是会产生抗体消灭新来基因,如果适应下来后,双方会很好地融合形成新的物种。

            清楚团队容器的设计逻辑能更好地帮助你在实践时设计出适合组织的价值生产单元,采用不同的设计逻辑会直接影响组织的沟通机制和沟通饱和度,这两个是组织设计的重要指标。组织设计是一门科学和艺术,如果可以掌握就可以设计自己的组织结构,提高组织适应性。倘若我们并不想去设计组织或者还不具备这种能力,那么了解现有框架设计者的逻辑也会有所帮助。所以笔者认为团队容器是一个十分重要的概念,无论你是规模化敏捷实践者或管理者都需要去了解。

    图片

    注:

    *本文默认读者已经对Scrum有一定的知识基础,所以不会对Scrum做额外的知识普及。

    2.1.1 Scrum@Scale Team Container

            Scrum@Scale的团队容器设计十分特别,也是它的核心,所以这节会以较大篇幅去分析。从下图可以看到,Scrum@Scale组织结构里Team的最小单元是一个Scrum团队,一个Scrum of Scrum(下称SoS)的最结构是小于等于5个Scrum团队,再上一层的SoSoS也是同样的规则,可以有多层的SoSoSoS…..,所以Scrum@Scale的这种网状组织结构是可以支持无限大团队。至于为什么它设计的单元是5呢?背后的设计逻辑稍后会再作分析。

            Scrum@Scale这种组织结构让人感觉和LeSS与SAFe都很不一样,后两者对于团队容器都有一个很清晰的容量限制,SAFe有ART的限制,LeSS也有Team的人数限制,后两者要突破限制就要添加新的Role和规则来平衡沟通的效率,本文的沟通饱和度一节会对这种设计进行详细分析。

    图片

    (图4:Scrum@Scale的组织设计进化透视图)

    图片

    (图5:Scrum@Scale会有不同的组织结构实现形式)

            Scrum@Scale框架是Scale-Free network的仿生设计,这种设计能更适应更快速的组织发展和功能开发响应,理论是基于无尺度网络模型,这种网络在实现中普遍的存在,如神经网络、社交网络、航空网络等。

    图片

    (图6:Scrum@Scale以Scale-Free network设计的实现)

    The Executive Action Team(EAT)组织内只有一个,有些组织可能叫精益/战略转型等类似的名称

    •     对组织中Scrum的质量负责;

    •     拥有组织转型战略;

    •     拥有转型代办清单和清除阻碍转型的所有障碍;

    •     消除由于范围,预算或公司政治权力而未在团队级别处理的障碍;

    •     执行转型战略或将其委托给专业部门(通常称为敏捷实践);

    •     测量并提高组织中Scrum的质量,以构建业务敏捷性的能力;

    •     敏捷践行小组(Agile Practice),十分重要,它是企业内推行敏捷的组织,Scrum Master会向这个小组汇报。Agile Practice成员也是EAT成员,负责推动敏捷实践,这样自上而下的推动,才能保证敏捷不只是以形式留存于基层。

    图片

    (图7:Scrum@Scale的Meta Scrum几种组织形式)

    MetaScrum

    这个组织要说明一下,是所有PO和利益相关者的容器,从SoS的Team层开始他就有,直到企业执行官层(EMS)都存在,这个组织在不同层次有不同的企业成员,重要的一点他们也是一个Scrum团队,职责如下:

    Executive MetaScrum(EMS)

    管理层成员(CPO、 CEO、CFO、CCPO)拥有组织愿景、识别价值流、设定组织优先级

    CCPO MetaScrum

    设置多个团队组(可以理解为所有的产品线)的优先级,产品澄清、识别价值流、跨团队协调。

    CPO MetaScrum

    设置多个团队的优先级、故事拆分、跨团队代办清单协调、对齐

    2.1.2 LeSS Team Container

    图片

    (图7:LeSS的团队容器)

            LeSS的团队容器十分特别,是由1个Product Owner、多个Scrum Master和Scrum Team组成,设计是通过系统思考的方式推理和优化出来的。LeSS只扩展Dev Team,整个组织的上限是50人(再大就会是LeSS Huge,本文不会展开)。LeSS建议Scrum Master全职同时支持两个团队,这样可以得到不同团队的视角,更好地提高团队的适应性。当然,如果Scrum Master的能力足够,可以支持更多的Scrum Team。

            另外,LeSS很强调产品的定义,组织的设计是为了更好的支持产品的迭代和适应性。而产品的定义又涉及投资组合、DoD(完成的定义)等因素,所以清晰的产品定义是团队容器的基础。

            Team Design vs. Coaching,可以看到花成本去设计好组织结构比教练团队,得到的回报会更高。

    图片

    ( 图8:Team Design比Coaching Team更重要)

    2.1.3 SAFe Team Container

    图片

    ( 图9:SAFe在TEAM层的团队结构)

           SAFe的团队容器在框架的TEAM层,容器里有多个Scrum团队和看板团队。SAFe的TEAM层会有多个Product Owner和Scrum Master,并没有强调和限制使用特定哪一种形式的团队,水平扩展多个多功能团队,直到到达上限150人(包括所有人)。SAFe以层级的设计思路,层间的沟通问题通过引入新的角色去解决。团队容器抽象为一列敏捷发布火车(Agile Release Train)ART,在框架的PROGRAM层,用火车来比喻十分形象,一列火车承载着所有团队成员和要交付的产品价值,这也是SAFe中最大的特色。SAFe在各层之间还有一个系统团队(System Team),它是一个共享的资源团队,如类似架构团队和设计团队等,在同层是用火车来承载,跨层是用System Team来承载。

    2.1.4 小结:

           通过对比我们可以看到三个框架的组织结构设计都有它的思路,Scrum@Scale以仿生Scale-Free架构设计理论依据,支持可无限扩展的组织。LeSS在小范围内达到极致,到达一定极限后扩展成Huge。SAFe在到达一定上限时扩展多个ART和RTE。三者都以Scrum作为团队基础单元,LeSS的结构更像是Scrum@Scale的其中一种实现。

           每个组织都有它自运转的生态和惯性,这个生态我们称它为系统,它的惯性我们称它为心智模式。系统的组织结构是它运作的核心,是管理者十分关注的一个维度。系统有它的心智模式,当我们要对系统进行变革的时候,它自然会产生抗体,所以变革的阻力就在于系统的惯性,然而我们实践者往往要做的是这个核心的变革工作。

           组织结构的设计逻辑直接影响实践者实施的难度,那么我们该如何选择框架为企业赋予敏捷的属性?作为一名敏捷教练如果理解了框架背后的逻辑和设计原理,那么我们就能更加容易做出正确的决策,在实施组织变革时的成功机会也会增加。    

    图片

           Scrum@Scale认为如果一个系统没有自生态的机制,那么当它发展到一定体积后就会慢下来,对于组织管理和设计者来说,也是有必要考虑的因素。LeSS发展到一定体积后要切换到Huge模式,SAFe的ART到达150人后也需要更多的RTE建立沟通机制,这种进化也必然要引入新的资源配套,倘若系统天然就支持和具备快速进化发展的机制和基因,就能减少系统在决策和申请资源时的消耗,Scrum@Scale以Scale-Free的架构设计就具有这种天然的基困。

    图片

    未完待续,下篇更精彩

    版权所有,欢迎转发分享。

    转载请私信联系

    展开全文
  • 从本文开始,分几篇文章简单分析一下规模化敏捷LeSS和SAFe的区别。 以下内容参考 1《大规模Scrum:大规模敏捷组织的设计》作者:克雷格·拉尔曼巴斯·沃代 2 https://www.scaledagileframework.com/#,和《SAFe...
  • LeSS就是大规模的Scrum,所有团队/每个领域的所有团队都采用相同节奏的敏捷实践,它沿用Scrum的迭代的概念。 SAFe整体也是Scrum实践的扩展,但是敏捷团队可以选用Scrum或看板方法。同一发布火车/价值流/投资组合的...
  • 这三种方法分别是Dean Leffingwell的Scaled Agile Framework(“SAFe”),Scott Ambler的纪律敏捷开发(DAD)和Craig Larman和Bas Vodde的大规模Scrum(LeSS)。在还没有搞清楚一个团队的敏捷转型时,对于在公司...
  • 什么是LeSS框架?Scrum / LeSS / LeSS Huge

    千次阅读 2019-12-02 14:09:10
    LeSS是一个轻量级的敏捷框架,用于将Scrum扩展到多个团队。从2005年开始,Bas Vodde和Craig Larman在大型项目中使用Scrum原则和规则后开发了LeSS框架。他们的目标是在不受Scrum约束的情况下成功开发大型项目。 LeSS...
  • 上篇说到规模化敏捷框架和从Scrum团队容器(Scrum Team)维度分析规模化敏捷框架。文章分为上中下三篇。... Scrum@Scale和LeSS并没有新增角色,他们都是Scrum的角色,LeSS对Product Owner的能力要求提到了一个...
  • 前面我们分享了《洞悉规模化敏捷框架》上篇和中篇,本篇是文章下篇,将继续从其他维度分析规模化敏捷框架。 点击链接阅读: 《洞悉规模化敏捷框架》上篇 《洞悉规模化敏捷框架》 中篇 正文 2.7 ...
  • Less 学习笔记(二)

    2018-11-17 11:51:30
    Less 语法 1. Less 中的注释 常规的 css 注释(/**/) 该种注释将会被编译,会出现在最终生成的 css 文件中(如果 Koala 的输出方式为 compress 该注释也不会被看到) // 注释 该种注释不会被编译,不会出现在最终...
  • LeSS框架的原则
  • 小型LeSS框架及小型LeSS的组织结构
  • 最近我申请到LeSS Friendly Scrum Trainer的资格,申请过程中,我的CSM课件需要Bas的评审。2018年11月Bas给了对我的CSM课件的反馈,毫不夸张地说Bas 几乎是Scan我课件的每一个单词和句子,他严谨的治学态度让我自愧...
  • 今天我们不谈理论,不谈框架(SAFe,LeSS),我想从一个实操的方面来剖析一些我们实际遇到的困难和一些应对策略。我们从以下4个方面来分析:产品规划多开发团队的协同集成与测试上线交付我们知道在传统瀑布模式下会...
  • 导语 敏捷团队由产品所有者...现在,许多组织和团队通过大规模Scrum(LeSS,Large Scale Scrum)之类的扩展敏捷过程框架有效地解决了企业中的Scrum扩展问题(规模化问题)。 什么是 LeSS(Large Scale Scrum)
  • Less 教程

    2021-08-04 05:31:24
    什么是LESSLESS是一个CSS预处理器,可以为网站启用可自定义,可管理和可重用的样式表。LESS是一种动态样式表语言,扩展了CSS的功能。LESS也是跨浏览器友好。CSS预处理器是一种脚本语言,可扩展CSS并将其编译为常规...
  • \关键结论\\大规模敏捷需要组织机构减少自身的复杂性。...\\\在Craig Larman和Bas Vodde所著的《More with LeSS》一书中,介绍了多团队合作生产一个产品时,如何采用Scrum来创建更加简单灵活的组...
  • 巨型LeSS框架
  • C#敏捷开发框架源码

    热门讨论 2015-11-17 08:31:23
    C#敏捷开发框架源码特点 1.基本多层抽象工厂模式架构设计, 2.支持Access、Sql Server、Oracle、Sqlite、MySql等多种常见数据库 3.动态生成系统菜单 4.动态反射打开Winform窗体 5.可扩展支持Remoting、Web Services...
  • 敏捷估算 演示视频 这是什么? “Agile Estimation 3.0”是基于 Steve Bockman 的 Team Estimation Game 的在线工具。 它是为敏捷团队设计的,他们估计他们为某些任务所做的努力。 我称之为 3.0,因为我相信这是下...
  • sacc less 区别

    2021-10-08 22:26:37
    sass和less主要区别在于实现方式:less是基于JavaScript的在客户端处理 所以安装的时候用npm,sass是基于ruby所以在服务器处理。 sass 与 less 的区别 : 1、sass与less的安装 :sass基于Ruby语言开发而成,因此...
  • Scrum计划扑克 使用的技术(2013年): node.js 套接字 Knockout.js 靴子 jQuery的 在本地运行: $ npm install $ node server.js 导航到
  • 认识less less初体验 less变量 变量插值 less选择器 less url less import less属性 Less 变量名称 延迟加载 less导入 less的命名空间和访问器 less拓展 拓展附加到选择器 拓展内部规则集 拓展嵌套...
  • 一、Less概述 Less官网网站 http://lesscss.cn/ https://less.bootcss.com/ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZrIXUheJ-1637595223146)(images/less_logo.png)] 什么是LESS?...
  • Less的简单运用

    2022-03-27 20:24:24
    Less简介: Less是CSS预处理器,它扩展了CSS的功能并且CSS预处理器是一种脚本语言,可扩展CSS并将其编译为常规CSS语法,以便可以通过Web浏览器读取。 它提供诸如变量,函数, mixins 和操作等功能,可以构建动态CSS...
  • Scrum简介如果你知道敏捷开发,Scrum你一定不会陌生。从上世纪 90 年代初开始,Scrum 框架在全球范围内已得到了广泛应用,有报告显示全世界范围内采用敏捷开发模式的公司里有68%以上使用Scrum框架。Scrum团队中包括...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,355
精华内容 1,342
关键字:

less 敏捷