接上一篇： 什么是LeSS：大规模Scrum——原则
图片来源：《大规模Scrum：大规模敏捷组织的设计》
LeSS框架中的元素与单团队Scrum大致相同：包含3个角色、3个工件、多个事件
3个角色：
（1）产品负责人：小型LeSS框架中有一个产品负责人（并且只有一个）
（2）Scrum Master：每1到3个特性团队有1个Scrum Master
（3）团队：小型LeSS框架中有2到8个团队。每个团队都是自管理的、跨职能的、同地点的、长期的。真正的跨功能和跨组件的全面型团队，他们在代码共享的环境中协同工作。大多数团队都是以客户为中心的特性团队。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
组件团队（component team）——符合以下情况的任何一个团队都属于组件团队：（1）专注于开发产品的某些部分而不是面向最终客户的功能；（2）专注于完成任务而不是交付产品增量。工作范围越小，专门化程度越高，组件团队的问题就越大。
特性团队（feature team）——任何以整体产品为焦点，参与以客户为中心的功能澄清，并测试这些功能的团队就是特性团队。特性团队的规模有大有小，团队可以被限制为仅实现他们需要的功能，也可以在产品定义足够宽广时，参与识别和解决客户的实际问题，并因此共同创建整个产品。
LeSS要求团体的主体是特性团队。
3个工件：
每个团队都有一个潜在的可交付产品增量、所有的团队共用一个产品待办事项列表、每个团队有一个单独的Sprint待办事项列表。
多个事件：
（1）迭代（Sprint）——有一个产品层面的Sprint，而不是每个团队有不同的Sprint。每个团队同时开始和结束一个Sprint。每个Sprint产出一个集成的完整产品。
（2）迭代计划会议（Sprint Planning）——LeSS计划会议与Scrum的迭代计划会议相似也分为两个部分。Sprint计划一由所有团队共同制定，而Sprint计划二通常由各个团队各自制定。多个团队可以在一个共享空间中为紧密相关的条目一起制定Sprint计划二。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
迭代计划会议第一部分（Sprint Planning 1，SP1）——由所有团队成员或者团队、产品负责人、Scrum Master参加，他们一起试探性地选择每个团队在该Sprint中要做的条目，以及定义各团队的迭代目标。团队识别一起协作的机会，并澄清最终的问题。
迭代计划会议第二部分（Sprint Planning 2，SP2）——Sprint计划二用于让团队决定他们将如何执行所选条目。这里通常会涉及设计和创建他们的Sprint待办事项列表。各团队并行地执行。对那些相关性强的条目，也经常采用在同一房间内进行多团队迭代计划会议，即并行地进行SP2。
（3）每日站立会议（Daily Scrum）——每个团队有自己的每日站立会议。跨团队协调由团队决定。
（4）产品待办列表梳理会议（Product Backlog Refinement，PBR）——
是指团队利用研讨会的机会与用户和利益相关者澄清后续要做的条目，分解大条目，并（重新）估算条目。（条目不会预先分配给特定团队）。有关的活动包括澄清和细化，分解，以及估算。它通常是在前面某个Sprint的中期。在每个Sprint都需要持续地进行PBR工作，以便为未来的Sprint做好准备。但建议团队在这方面花费不超过10%的Sprint时间。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
拥有2～3个团队的产品组通常只举行一次PBR会议，产品负责人、用户和所有团队的所有成员都要参加，并一起对所有条目进行深入梳理；对于拥有3个或更多个团队的产品组，PBR会议通常采用组合方式，先是总体PBR，接着是多团队PBR和单团队PBR。要避免单团队PBR，除非绝对确定哪些团队将实现哪些条目。
不同情形有着不同类型的PBR：
总体PBR——在多团队或单团队PBR之前举行的以产品为中心的整体PBR。总体PBR用于探索哪些团队可以改进哪些条目，并加强学习和协调。在总体PBR期间，让团队（而不是产品负责人）决定将哪些条目转移到多团队或单团队PBR。
多团队PBR——在该PBR中，有两个或多个团队的所有成员一起梳理一组条目，但尚未决定这些团队中的哪一个将实现哪个条目。
单团队PBR——一个团队的所有成员都在其中梳理最可能要由他们来实现的条目的PBR。这与Scrum中的情况相同。
初始PBR（IPBR）——在决定采用LeSS时，在产品生命周期初期仅举行一次的PBR。在初始PBR中，所有团队一起创建第一个产品待办事项列表，并提炼出足够的条目以开始第一个Sprint。参加人员：产品负责人、Scrum Master、所有团队所有成员、客户、用户、领域专家等。
（5）迭代评审与回顾会议（Sprint Review& Retrospective）
有一个产品级Sprint评审，是所有团队共同的。确保适当的利益相关者参加并贡献出有效检查与调整所需要的信息。
每个团队都有自己的Sprint回顾。
在团队各自回顾之后举行一次全体回顾，以讨论跨团队和全系统范围内的问题，并建立起改进试验。出席会议的人应包括产品负责人、ScrumMaster、团队代表和经理（如果有这样的角色）。
图片来源：《大规模Scrum：大规模敏捷组织的设计》
可以采用迭代评审集市（Sprint Review Bazaar）方式。
分散方式探索：各团队并行在同一个房间内不同区域分别演示潜在可交付的产品增量，和产品负责人、用户、客户及利益相关者讨论。
聚合方式决定产品方向：集市之后是全体讨论，全体人员对下一个迭代的方向，讨论变更和新的创意等。
全体回顾的一些提示：把全体回顾会放在下一个Sprint的早期举行，因为当前Sprint的最后一天要举行评审和团队回顾会议，人们可能会对当天那么多的会议感到厌倦或精疲力竭。至少包括两个主要步骤：（1）系统分析，（2）系统改进试验的设计。
小型LeSS的组织结构
图片来源：《大规模Scrum：大规模敏捷组织的设计》
LeSS组织倾向于遵循一种极其简单的结构。LeSS组织与大多数传统组织之间的首要区别是，其结构是稳定的，因为工作是围绕团队来组织的，而且技能不匹配会触发现有团队内部的学习和协调。
团队是指特性团队，每个团队都是跨职能、自管理的特性团队，包括一个Scrum Master。
这里的“产品组领导”指的是所有团队共同的那一个直线经理，可能不同的企业有不同的称呼。因为团队接管了大多数管理活动，所以只设置了一个直接经理来管理所有人。但一些规模较大LeSS组织会设置一些额外的团队直线经理结构。只要有可能就应避免额外的组织复杂性。
未完成部门——理想情况下，此类部门不应存在。但是，有时候团队还无法在每一个Sprint中创造出真正可交付的产品增量。这表明他们的“完成定义”与“潜在可交付”还不相等，由此产生的两者之间的区别被称作未完成工作。针对这些未完成工作，一个常见的“解决方案”是创建独立的团体来完成“未完成工作”，即未完成部门。
诸如测试、QA、架构或业务分析等未完成部门永远不应存在于小型LeSS框架组织中，而应该一开始就集成到特性团队。但是，我们经常看到在LeSS采用过程中仍然存在运营或产品未完成部门，存在的原因是这类部门通常需要跨越组织边界开展工作，不能集成到特性团队中。每个LeSS采用都有一个目标，即去除未完成部门。这需要多长时间呢？答案在很大程度上取决于组织提高自身能力的速度。
注意这里没有什么：
1）这里没有职能组织：如果让具有编程技能的团队成员向开发经理汇报，同时让具有测试技能的团队成员向QA（质量保证）经理汇报，则不会创建出优秀的团队。为什么？如果QA人员因为团队工作而忠诚于团队，又因为职能专门化而忠诚于QA经理，那么这两种忠诚之间就会出现忠诚度矛盾。
2）没有项目/计划组织或项目/计划管理办公室（PMO）：这些传统的部门在LeSS组织中将不复存在，因为其职责已经分布在特性团队和产品负责人中间。
3）没有诸如配置管理、持续集成支持或“质量和流程”等支持小组：LeSS组织倾向于通过扩大现有团队的责任来涵盖这类支持工作，而不是创建包含各种专门小组的更复杂的组织。专门的支持小组往往拥有自己的领域，这会导致他们变成一种瓶颈。
内容参考《大规模Scrum：大规模敏捷组织的设计》作者：克雷格·拉尔曼 巴斯·沃代
下一篇文章，我们介绍巨型LeSS框架。
