Regras do LeSS(Abril 2017)

(O que mudou desde a versão anterior)
As regras do LeSS são a definição do Framework LeSS. Elas são coisas que consideramos necessárias. Por que? Isso é explicado na seção Por que LeSS?.

Regras do Framework LeSS

O framework LeSS se aplica a produtos que possuem 2 a 8 times.

Estrutura do LeSS

Estruturar a orgenização usando times reais como o bloco mais básico de construção organizacional.
Cada time é (1) auto-gerenciado, (2) multifuncional, (3) colocalizada e (4) de longa duração.
A maioria dos times são times de funcionalidades, focados em clientes.
Scrum Masters são responsáveis por uma adoção bem-sucedida do LeSS. O seu foco é para os Times, Donos de Produtos, a organização e as práticas de desenvolvimento. Um Scrum Master não se concentra somente em um time, mas no sistema organizacional em geral.
Um Scrum Master é um papel dedicado em tempo integral.
Um Scrum Master pode atender de 1 a 3 times.
No LeSS, gerentes são opcionais, mas se estes gerentes de fato existirem, o seu papel provavelmente mudará. O seu foco muda de gerenciar o trabalho diário do produto para melhorar a capacidade de entrega de valor do sistema de desenvolvimento de produto.
O papel dos gerentes é melhorar o sistema de desenvolvimento do produto praticando Vá ver, encorajando o “Pare e conserte”, e “experimentos sobre conformidade”.
Para o grupo de produtos, estabelecer a estrutura completa do LeSS “no início”; isto é vital para a adoção do LeSS.
Para organizações maiores, além do grupo do produto, adote LeSS de forma evolutiva usando “Vá e veja” para criar uma organização onde experimentação e melhoria sejam a norma.

Produto LeSS

Há um Dono de Produto e um Backlog de Produto para o produto completo e utilizável.
O Dono de Produto não deveria trabalhar sozinho no refinamento do Backlog do Produto; ele é apoiado pelos múltiplos times, trabalhando diretamente com os clientes/usuários e outros stakeholders.
Toda priorização passa pelo Dono de produto, porém todo esclarecimento deve ser, o quanto for possível, realizado diretamente entre os times e clientes/usuários e outros stakeholders.
A definição de produto deve ser tão ampla e centrada no usuário final / cliente quanto possível. Com o tempo, a definição de produto pode se expandir. Definições mais amplas são preferidas.
Uma Definição de Pronto para todo o produto, comum para todos os times.
Cada time pode ter a sua própria Definição de Pronto mais forte, expandindo a definição comum.
O objetivo da perfeição é melhorar a Definição de Pronto de modo que resulte em um produto utilizável em cada Sprint (ou ainda mais frequente).

Sprint LeSS

Há uma Sprint a nível de produto, e não uma Sprint diferente para cada time. Cada time começa e termina a Sprint ao mesmo tempo. Cada resultado de Sprint é um produto completo e integrado.
O Planejamento da Sprint consiste em duas partes: a parte 1 do Planejamento da Sprint é comum para todos os times, enquanto a parte 2 do Planejamento da Sprint é normalmente realizada separadamente para cada time. Faça a parte do Planejamento da Sprint, para múltiplos times, em um espaço compartilhado para itens intimimamente relacionados.
A parte 1 do Planejamento da Sprint é frequentada pelo Dono do Produto e os times - ou representantes. Eles juntos tentam selecionar os itens nos quais cada time irá trabalhar na Sprint. Os times identificam oportunidades para trabalhar juntos e as questões finais são esclarecidas.
Cada time tem seu próprio Backlog da Sprint.
A parte 2 do Planejamento da Sprint é para os times decidirem como farão os itens selecionados. Geralmente envolve o design e a criação dos seus Backlogs da Sprint.
Cada time tem a sua própria Reunião Diária.
A coordenação entre times é decidida pelos times. Prefira a coordenação decentralizada e informal sobre a coordenação centralizada. Enfatize o “Apenas fale” e as redes informais através da comunicação em código, reuniões entre times, mentores de componentes, viajantes, olheiros e espaços abertos.
O Refinamento do Backlog do Produto (RBP) é realizado por time para os itens que eles provavelmente farão no futuro. Faça RBP geral e/ou com múltiplos times para aumentar a compreensão compartilhada e explorar oportunidades de coorndeação ao ter itens intimamente relacionaodos ou a necessidade de aprendizado / input mais amplos.
Há apenas uma Revisão da Sprint do Produto; é comum para todos os times. Garanta que stakeholders adequados se juntem para contribuir com as informações necessárias para uma inspeção e adaptação eficazes.
Cada time tem a sua própria Retrospectiva da Sprint.
Uma Retrospectiva Geral é realizada após a Retrospectiva dos times para discutir questões sistêmicas e entre times, e criar experiências de melhoria. É frequentada pelo Dono do Produto, Scrum Masters, representantes dos times e gerentes (se houver).

Regras do Framework LeSS Huge

LeSS Huge se aplica a produtos com mais de 8 times. Evite aplicar LeSS huge para grupos de produtos menores, pois isso resultará em mais sobrecarga e otimizações locais.

Todas as regras do LeSS se aplicam ao LeSS Huge, salvo indicações contrárias. Cada área de requisitos atua como a estrutura básica do Framework LeSS.

Estrutura do LeSS Huge

Requisitos de cliente que estão fortemente relacionados a partir de uma perspectiva de cliente são agrupados em Áreas de Requisitos.
*Cada time se especializa em uma Área de Requisitos. Times focam em uma área por um longo período de tempo. Quando há mais valor em outras áreas, times podem mudar de Áreas de Requisitos.
Cada Área de Requisitos possui um Dono de Produto de Área.
Cada Área de Requisitos possui entre 4 a 8 times. Evite violar este intervalo.
Adoções do LeSS Huge, incluindo as mudanças estruturais, são realizadas com uma abordagem incremental e evolutiva.
Lembre-se diariamente: adoções do LeSS Huge duram meses ou anos, paciência infinita e senso de humor.

Produto LeSS Huge

Cada Área de Requisitos possui um Dono de Produto de Área.
Um Dono de Produto (geral) é responsável pela priorização de todo o produto e decidir quais times trabalham em quais áreas. Ele(a) trabalha próximo(a) aos Donos de Produto das Áreas.
Donos de Produto de Áreas atuam como Donos de Produto em relação aos seus times.
Há apenas um Backlog do Produto; todo item nele inserido pertence a exatamente uma Área de Requisito.
Há apenas um Backlog de Produto de Área por Área de Requisito. Este backlog é, conceitualmente, uma visão mais granular do Backlog do Produto.

A Sprint do LeSS Huge

Há uma Sprint a nível de produto, não uma Sprint diferente para cada Área de Requisito. Ela termina em produto inteiro e integrado.
O Dono do Produto e os Donos de Produto de Áreas sincronizam-se frequentement. Antes de cada Planejamento de Sprint eles garantem com que os times trabalhem nos itens de maior valor. Após a Revisão da Sprint, eles também permitem adaptações a nível de produto.