LeSS 快速入门

背景来源

从单个Scrum团队，到多个Scrum团队之间如何协作共同开发产品；LeSS是其中的一种框架方法，它努力不改变Scrum的部分，依然是3个角色，3个工件，5个会议。

主要的大规模敏捷框架如下
1. SAFe
2. LeSS
3. Scrum of Scrums
4. DAD
5. NEXUS

过程

Sprint的过程

Review和回顾

术语

两个层级
1. LeSS：8个Scrum是上线
2. LeSS Huge：多个团队
转型一般从小的Less到Less Huge

原则

1. 仍然是Scrum： 讨论的是在大规模团队中如何运用Scrum
2. 透明：以团队为单位的透明（信息透明、对DoD - 完成理解的一致性）
3. 以少为多：尽可能不增加角色，从而不减弱团队的责任感；不增加工件，从而不增加团队的距离；不增加流程，这样团队成员不用去学太多新的东西。
4. 关注整个产品：大家跑的是一个产品，多个团队的节奏是一致的，一个产品负责人
5. 以用户为中心：以客户的价值为中心
6. 向完美持续改进
7. 精益思想
8. 系统思维：需要关注体系化的提升，整体的提升
9. 经验过程控制：结合具体的场景调整过程
10. 排队论：尽可能不打断进行中的sprint

成员角色

同Scrum类似。
1. 整个团队仍然是1个大PO
2. 特性团队（全栈团队）
3. Scrum Master

工作文档

同Scrum类似。
1. 仍然是一个待办事项列表
2. 一个产品
3. 统一的sprint节奏

基于Scrum的补充

1. 计划会议：由于有跨团队，所有计划会议分两部分。一部分是产品经理和所有团队（有团队代表）的成员一起开的，决定单个团队的Backlog；第二部分和单个Scrum是类似的
2. 站会：有其他团队小伙伴参与到团队内部
3. 产品Backlog的更新，需要拉上所有团队代表
4. 评审会：尽可能有跨团队成员参与
5. 整体回顾会：多出的部分，大家一起讨论与回顾改进
6. 组件团队 -> 特性团队（类似于前后端和全栈）

注意点

1. 经理角色的转变：
   1. 做什么理想情况下主要由PO来去决定
   2. 团队管理理想情况下变成团队自治
   3. 更多专注于团队本身的能力建设；给团队的改进做支持
2. 一般情况下一个Scrum Master负责1~3个团队
3. 完成的定义一定要统一
4. 之前组件团队之间的依赖关注产出而不是价值，而特性团队关注价值（同样也需要更多的付出）

LeSS Huge

由于团队更加庞大，需要处理更多的人和事物

结构

1. 需要按领域划分，团队按需求领域划分，分组为Requirement Area
2. 每个Requirement Area有一个PO
3. 一个Area大概是4~8个团队

产品

1. 有一个主PO
2. 一个product backlog；area porudct backlog从属于主product backlog

Sprint

1. 目标仍然是同步sprint，团队之间，尤其是PO之间需要频繁的同步

参考

Large Scale Scrum (LeSS)
Introduction to LeSS