规模化敏捷LeSS 与LeSS Huge框架规则(Large Scale Scrum)

优普丰敏捷咨询2007年首开Scrum认证培训，为上百家企业提供敏捷教练顾问辅导落地和转型，注重数字化工程 ... LeSS规则是LeSS框架的定义，分为LeSS和巨型LeSS两种规模。

规模化敏捷LeSS与LeSSHuge框架规则(LargeScaleScrum)首页学习资源规模化敏捷LeSS与LeSSHuge框架规则(LargeScaleScrum) 敏捷宣言与敏捷原则中文版2016年9月8日生态系统因果图系统思考CasualLoopDiagram-狼图腾节选2016年9月15日 69 LeSS规则是LeSS框架的定义，分为LeSS和巨型LeSS两种规模。

这些是我们认为导入LeSS必须做到的事情。

目录1LeSS框架规则1.1LeSS结构1.2LeSS产品1.3LeSSSprint2LeSS巨型框架规则2.1LeSS巨型结构2.2LeSS巨型产品2.3LeSS巨型Sprint3LeSS介绍视频4LeSSFrameworkRules4.1LeSSStructure4.2LeSSProduct4.3LeSSSprint5LeSSHugeFrameworkRules5.1LeSSHugeStructure5.2LeSSHugeProduct5.3LeSSHugeSprint LeSS框架规则 LeSS框架规则应用于2-“8”个团队的产品。

LeSS结构 用团队作为基本模块来构建组织 每个团队是：1）自管理的、2）跨职能的、3）同在一地的、4）长期的 多数团队都是以客户为中心的特性团队 ScrumMaster负责一个运转良好的LeSS导入。

他们关注于团队、产品所有人、组织和开发实践。

一个ScrumMaster不只关注一个团队，而是整个组织系统。

ScrumMaster是一份专职和全职工作 一个ScrumMaster可以服务1－3个团队 在LeSS里，管理者是可选的，但是如果管理者还存在的话他们的角色可能会改变。

他们的焦点从管理日常产品工作转向改进产品开发系统的价值交付能力 管理者的角色是通过实践“开展现场调查”、鼓励停下来修正，以及“试验高于遵循”来改进产品开发系统 对产品组从一开始就建立完整的LeSS结构，这个对LeSS导入至关重要 对超越产品组的更大组织，采用“开展现场调查”来演进地导入LeSS，从而创建一个以试验和改进为常态的组织 LeSS产品 对整个可以交付的产品有一个产品所有人和一个产品待办列表 产品所有人不应该独自工作于产品待办列表的梳理；他通过让多个团队直接和客户／用户以及干系人工作来获得支持 所有的优先级排序都通过产品所有人，但是澄清尽量由团队和客户／用户以及干系人直接进行 产品的定义应该是在实际的前提下尽量广并且以终端用户／客户为导向。

随着时间的推移，产品的定义可能会扩大。

我们倾向于更广的定义 对整个产品有一个所有团队一致的完成的定义 每个团队可以扩展共同的定义以形成自己团队的更为严格的完成的定义 完美的目标是通过改进完成的定义达到每个Sprint都产出可交付的产品（或者更为频繁） LeSSSprint 有一个产品层面的Sprint，而不是每个团队有不同的Sprint。

每个团队同时开始和结束一个Sprint。

每个Sprint产出一个集成的完整产品 Sprint计划由两部分组成：Sprint计划第一部分是所有团队共同做，而Sprint计划第二部分通常由各团队分别做。

对那些相关性强的条目在一个共享空间内做多团队的Sprint计划第二部分 Sprint计划第一部分由产品所有人和团队代表参加。

他们一起试探性地选择每个团队将在下一个Sprint工作的条目。

团队会去识别一起合作的机会，并澄清最终的问题 每个团队有自己的Sprint待办列表 Sprint计划第二部分是让团队决定怎么做选了的条目。

这通常涉及设计并产生他们的Sprint待办列表 每个团队有自己的每日站会 跨团队协调由团队决定。

倾向于分布式和非正式协调而非集中式协调。

强调实时交流和非正式的网络，采用代码交流、跨团队会议、组件导师、旅行者、侦察员和开放空间 产品待办列表梳理由每个团队对自己可能接下来要做的条目进行。

举行多团队和／或者整体的产品待办列表梳理来增加共享的理解，并当有紧密关联的条目或者有需要更广范围进行输入和学习时发现协调机会加以利用 有一个产品的Sprint评审；对所有团队都是共同的。

确保足够的干系人能够参加并贡献有效检验和适应所需要的信息。

每个团队有自己的Sprint回顾 在团队各自的回顾之后举行一个整体的回顾来讨论跨团队和系统性的问题，并创建改进试验。

这个会议由产品所有人、ScrumMaster们、团队代表和管理者（如果有的话）参加。

LeSS巨型框架规则 LeSS巨型框架应用于“8”个以上团队的产品。

避免在小型产品组上应用LeSS巨型框架，因为这会带来更多的开销和局部优化。

如果没有特别指出，所有LeSS规则都应用于LeSS巨型框架。

每个需求领域就象一个基本的LeSS框架。

LeSS巨型结构 从客户角度强相关的客户需求会以需求领域分组 每个团队专攻一个需求领域。

团队会长期固定于某个领域，但是当其它领域的价值变得更高时，团队也可能改变其工作的需求领域 每个需求领域有一个领域产品所有人 每个需求领域有“4-8”个团队。

避免超出这个范围 LeSS巨型的导入，包括其结构变化，是以演进增量式的方式发生的 每天都记得：LeSS巨型的导入会需要很多个月或者年、很多的耐心、还有一些幽默感 LeSS巨型产品 每个需求领域有一个领域产品所有人 有一个整体的产品所有人来负责产品层面的优先级排序和决定哪些团队工作在哪个领域。

他和领域产品所有人紧密地工作在一起 领域产品所有人对他们的团队来说就是产品所有人 有一份产品待办列表；里面的每个条目只属于一个需求领域 每个需求领域有一份领域产品待办列表。

这个列表概念上来说是整个产品待办列表更细粒度的视角 LeSS巨型Sprint 有一个产品层面的Sprint，而不是针对需求领域有不同的Sprint。

这样每个Sprint会带来一个集成的整体产品 产品所有人和领域产品所有人会频繁同步。

在Sprint计划前他们确保团队都工作在最有价值的条目上。

在Sprint评审后，他们在产品层面做出适应。

LeSS介绍视频 TheLeSSRulesarethedefinitionoftheLeSSFramework.Theyarethingsweconsideramust.Why?Thisisexplainedinthe WhyLeSS? section. LeSSFrameworkRules TheLeSSframeworkappliestoproductswith2-“8”teams. LeSSStructure Structuretheorganizationusingrealteamsasthebasicorganizationalbuildingblock. Eachteamis(1)self-managing,(2)cross-functional,(3)co-located,and(4)long-lived. Themajorityoftheteamsarecustomer-focusedfeatureteams. ScrumMastersareresponsibleforawell-workingLeSSadoption.TheirfocusistowardstheTeams,ProductOwner,organization,anddevelopmentpractices.AScrumMasterdoesnotfocusonjustoneteambutontheoverallorganizationalsystem. AScrumMasterisadedicatedfull-timerole. OneScrumMastercanserve1-3teams. InLeSS,managersareoptional,butifmanagersdoexisttheirroleislikelytochange.Theirfocusshiftsfrommanagingtheday-to-dayproductworktoimprovingthevalue-deliveringcapabilityoftheproductdevelopmentsystem. Managers’roleistoimprovetheproductdevelopmentsystembypracticing GoSee,encouragingStop&Fix,and“experimentsoverconformance”. Fortheproductgroup,establishthecompleteLeSSstructure“atthestart”;thisisvitalforaLeSSadoption. Forthelargerorganizationbeyondtheproductgroup,adoptLeSSevolutionarilyusingGoandSeetocreateanorganizationwhereexperimentationandimprovementisthenorm. LeSSProduct ThereisoneProductOwnerandoneProductBacklogforthecompleteshippableproduct. TheProductOwnershouldn’tworkaloneonProductBacklogrefinement;heissupportedbythemultipleTeamsworkingdirectlywithcustomers/usersandotherstakeholders. AllprioritizationgoesthroughtheProductOwner,butclarificationisasmuchaspossibledirectlybetweentheTeamsandcustomer/usersandotherstakeholders. Thedefinitionofproductshouldbeasbroadandend-user/customercentricasispractical.Overtime,thedefinitionofproductmightexpand.Broaderdefinitionsarepreferred. OneDefinitionofDoneforthewholeproductcommonforallteams. EachteamcanhavetheirownstrongerDefinitionofDonebyexpandingthecommonone. TheperfectiongoalistoimprovetheDefinitionofDonesothatitresultsinashippableproducteachSprint(orevenmorefrequently). LeSSSprint Thereisoneproduct-levelSprint,notadifferentSprintforeachTeam.EachTeamstartsandendstheSprintatthesametime.EachSprintresultsinanintegratedwholeproduct. SprintPlanningconsistsoftwoparts:SprintPlanningOneiscommonforallteamswhileSprintPlanningTwoisusuallydoneseparatelyforeachteam.Domulti-teamSprintPlanningTwoinasharedspaceforcloselyrelateditems. SprintPlanningOneisattendedbytheProductOwnerandTeamsorTeamrepresentatives.TheytogethertentativelyselecttheitemsthateachteamwillworkonthatSprint.TheTeamsidentifyopportunitiestoworktogetherandfinalquestionsareclarified. EachTeamhastheirownSprintBacklog. SprintPlanningTwoisforTeamstodecidehowtheywilldotheselecteditems.ThisusuallyinvolvesdesignandthecreationoftheirSprintBacklogs. EachTeamhastheirownDailyScrum. Cross-teamcoordinationisdecidedbytheteams.Preferdecentralizedandinformalcoordinationovercentralizedcoordination.EmphasizeJustTalkandinformalnetworksviacommunicateincode,cross-teammeetings,componentmentors,travelers,scouts,andopenspaces. ProductBacklogRefinement(PBR)isdoneperteamfortheitemstheyarelikelygoingtodointhefuture.Domulti-teamand/oroverallPBRtoincreasesharedunderstandingandexploitingcoordinationopportunitieswhenhavingcloselyrelateditemsoraneedforbroaderinput/learning ThereisoneproductSprintReview;itiscommonforallteams.Ensurethatsuitablestakeholdersjointocontributetheinformationneededforeffectiveinspectionandadaptation. EachTeamhastheirownSprintRetrospective. AnOverallRetrospectiveisheldaftertheTeamRetrospectivestodiscusscross-teamandsystem-wideissues,andcreateimprovementexperiments.ThisisattendedbyProductOwner,ScrumMasters,Teamrepresentatives,andmanagers(ifany). LeSSHugeFrameworkRules LeSSHugeappliestoproductswith“8+”teams.AvoidapplyingLeSSHugeforsmallerproductgroupsasitwillresultinmoreoverheadandlocaloptimizations. AllLeSSrulesapplytoLeSSHuge,unlessotherwisestated.EachRequirementAreaactslikethebasicLeSSframework. LeSSHugeStructure CustomerrequirementsthatarestronglyrelatedfromacustomerperspectivearegroupedinRequirementAreas. EachTeamspecializesinoneRequirementArea.Teamsstayinoneareaforalongtime.Whenthereismorevalueinotherareas,teamsmightchangeRequirementArea EachRequirementAreahasoneAreaProductOwner. EachRequirementAreahasbetween“4-8”teams.Avoidviolatingthisrange. LeSSHugeadoptions,includingthestructuralchanges,aredonewithanevolutionaryincrementalapproach. Remembereachday:LeSSHugeadoptionstakemonthsoryears,infinitepatience,andsenseofhumor. LeSSHugeProduct EachRequirementAreahasoneAreaProductOwner. One(overall)ProductOwnerisresponsibleforproduct-wideprioritizationanddecidingwhichteamsworkinwhichArea.HeworkscloselywithAreaProductOwners. AreaProductOwnersactasProductOwnerstowardstheirteams. ThereisoneProductBacklog;everyiteminitbelongstoexactlyoneRequirementArea. ThereisoneAreaProductBacklogperRequirementArea.ThisbacklogisconceptuallyamoregranularviewontotheoneProductBacklog. LeSSHugeSprint Thereisoneproduct-levelSprint,notadifferentSprintforeachRequirementArea.Itendsinoneintegratedwholeproduct. TheProductOwnerandAreaProductOwnerssynchronizefrequently.BeforeSprintPlanningtheyensuretheTeamsworkonthemostvaluableitems.AftertheSprintReview,theyfurtherenableproduct-leveladaptations. admin 相关文章2022年4月15日unFIX中通过Forum打造柔性组织阅读全文2022年1月6日敏捷回顾最高指导原则-ScrumMaster引导工具箱阅读全文2021年11月23日一页纸需求的应对方法–五步法阅读全文 评论关闭了。

拨打免费咨询电话021-63809913