O Guia do Scrum

Transcrição

O Guia do Scrum

O Guia do Scrum
O Guia definitivo para o Scrum
As regras do jogo
Julho 2011
Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland
Traduzido para o Português por José Eduardo Deboni (eduardodeboni.com)
Conteúdo
Propósito do Guia do Scrum ........................................................................................................................ 3
Visão Geral do Scrum ................................................................................................................................... 3
Framework Scrum ........................................................................................................................................ 3
A Teoria do Scrum ........................................................................................................................................ 3
Transparência .............................................................................................................................................. 3
Inspeção ....................................................................................................................................................... 4
Adaptação .................................................................................................................................................... 4
Scrum ........................................................................................................................................................... 4
A Equipe de Scrum ....................................................................................................................................... 4
O Dono do produto ...................................................................................................................................... 5
A equipe de desenvolvimento ..................................................................................................................... 5
O Tamanho da Equipe de Desenvolvimento ................................................................................................ 6
O Scrum Master ........................................................................................................................................... 6
Os serviços do Scrum Master para o Dono do Produto ............................................................................... 6
Os serviços do Scrum Master para a Equipe de Desenvolvimento .............................................................. 6
Os serviços do Scrum Master para a Organização ....................................................................................... 7
Eventos do Scrum ........................................................................................................................................ 7
O Sprint ........................................................................................................................................................ 7
Cancelando um Sprint. ................................................................................................................................. 8
Reunião de Planejamento do Sprint ............................................................................................................ 8
Parte 1: O que será Pronto neste Sprint? .................................................................................................... 9
Parte 2: Como o trabalho escolhido será Pronto? ....................................................................................... 9
Objetivo do Sprint ........................................................................................................................................ 9
Scrum Diário............................................................................................................................................... 10
Revisão do Sprint ....................................................................................................................................... 10
A Retrospectiva do Sprint. ......................................................................................................................... 11
Backlog do produto .................................................................................................................................... 12
Monitorando o Progresso na direção de um Objetivo .............................................................................. 13
Backlog do Sprint ....................................................................................................................................... 13
Monitoramento do Progresso do Sprint .................................................................................................... 14
Incremento ................................................................................................................................................ 14
Definição do “Pronto” ................................................................................................................................ 14
Conclusão ................................................................................................................................................... 15
Agradecimentos ......................................................................................................................................... 16
© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos
Pag. 2
Propósito do Guia do Scrum
Scrum é um framework para desenvolver e manter produtos complexos. Este Guia contém a definição
do Scrum. Esta definição consiste em papeis, eventos, artefatos do Scrum e as regras que mantém
tudo integrado. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum, o Guia do Scrum é escrito e
oferecido por eles. Juntos, eles apoiam o Guia do Scrum.
Visão Geral do Scrum
Scrum (subs masc.): Um framework dentro do qual as pessoas podem resolver problemas adaptativos
complexos, enquanto, produtivamente e criativamente entregam produtos com o mais alto valor
possível. O Scrum é:



Leve
De entendimento simples
Extremamente difícil de ter o domínio
O Scrum é um framework de processo quem tem sido usado para gerenciar o desenvolvimento de
produtos complexos desde o início dos anos 90. Scrum não é um processo ou técnica para construir
produtos, é mais um framework dentro do qual se pode empregar processos e técnicas variadas. O
Scrum torna clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos,
para que você possa melhorá-las.
Framework Scrum
O framework Scrum consiste nas equipes do Scrum, papéis, eventos, artefatos e regras associados.
Cada componente do framework serve a um propósito específico e é essencial para o sucesso e uso do
Scrum.
Estratégias específicas para uso do framework Scrum variam e são descritas em outros documentos.
As regras do Scrum integram os eventos, papéis e artefatos, governando as relações e interações entre
eles. As regras do Scrum são descritas ao longo do corpo deste documento.
A Teoria do Scrum
O Scrum está baseado nas teorias empíricas de controle de processo. O empirismo afirma que o
conhecimento vem da experiência e tomar decisões baseados no que se conhece. O Scrum aplica uma
abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
Três pilares sustentam a implementação de um controle de processo empírico: transparência,
inspeção e adaptação.
Transparência
Aspectos significativos do processo devem estar visíveis para os responsáveis pelos resultados.
Transparência requer que aqueles aspectos sejam definidos por um padrão comum para que os
observadores compartilhem um entendimento comum do que está sendo visto.
Pag. 3
Por exemplo:


Uma linguagem comum para se referir ao processo, deve ser compartilhada por todos os
participantes,
Uma definição comum de “Pronto1” deve ser compartilhada por aqueles que desempenham o
trabalho e aqueles que dão o aceite do produto do trabalho.
Inspeção
Os usuários do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso com
objetivo de detectar variações não desejadas. Esta inspeção não deve ser tão frequente, que a
inspeção fique no caminho do trabalho. As Inspeções são mais benéficas quando desempenhadas por
inspetores habilidosos [diligentes] no local do trabalho.
Adaptação
Se um inspetor determina que um ou mais aspectos do processo desviar para longe de limites
aceitáveis, e que o resultado do produto não é aceitável, o processo ou o material que está sendo
processado deve ser ajustado. Um ajuste deve ser feito tão logo quanto possível para minimizar os
desvios futuros.
O Scrum prescreve quatro oportunidades formais para inspeção e adaptação, como descritas na seção
de Eventos do Scrum deste documento:




Reunião de Planejamento do Sprint
Scrum Diário
Reunião de Revisão do Sprint
Retrospectiva do Sprint
Scrum
O Scrum é um framework estruturado para suportar o desenvolvimento de produtos complexos. O
Scrum é formado pelas Equipes de Scrum e os papéis, eventos, artefatos e regras associadas. Cada
componente no framework serve para um propósito específico e é essencial para o uso e sucesso do
Scrum.
As regras do Scrum integram os eventos, papeis e artefatos, governando as relações e interações entre
eles. As regras do Scrum são descritas ao longo do corpo deste documento.
A Equipe de Scrum
A Equipe de Scrum é formada do Dono do Produto, da Equipe de Desenvolvimento e do ScrumMaster.
As Equipes de Scrum são auto organizadas e trans-funcionais. Equipes auto organizadas escolhem a
melhor forma de realizar seu trabalho, ao contrário de serem dirigidas por outros de fora da equipe.
Equipes trans-funcionais tem todas as competências necessárias para realizar o trabalho sem a
dependência de outras que não fazem parte da equipe. A equipe modelo no Scrum é projetada para
aperfeiçoar a flexibilidade, criatividade e produtividade.
1
Veja a definição na página 15.
Pag. 4
As equipes do Scrum produzem iterativamente e incrementalmente, aproveitando ao máximo as
oportunidades para realimentação. Entregas incrementais de produtos “Prontos” garantem que uma
versão potencialmente útil do produto esteja sempre disponível.
O Dono do produto
O Dono do produto2 é responsável por maximizar o valor do produto e do trabalho da equipe de
desenvolvimento. Como isso é feito pode variar amplamente entre organizações, equipes de Scrum e
indivíduos.
O Dono do produto é a única pessoa responsável por gerenciar o Backlog do produto. O
gerenciamento do Backlog do produto inclui:




Expressar com clareza os itens do Backlog do produto;
Ordenar os itens do Backlog do produto para melhor alcançar os objetivos e missões;
Garantir o valor do trabalho desempenhado pela equipe de desenvolvimento;
Garantir que o Backlog do produto seja visível, transparente e claro para todos, e mostre no que
a equipe do Scrum irá trabalhar em seguida;
Garantir que a equipe de desenvolvimento entenda os itens do Backlog do produto no nível
necessário.

O Dono do produto pode fazer o trabalho acima, ou deixar que a equipe de projeto o faça. Entretanto,
o Dono do produto é o responsável por ele.
O Dono do produto é uma pessoa, e não um comitê. O Dono do produto pode representar os desejos
de um comitê no backlog do produto, mas aqueles que quiserem mudar um item do backlog do
produto devem convencer o Dono do produto.
Para o Dono do produto ter sucesso, toda a organização deve respeitar a sua decisão. As decisões do
Dono do produto estão visíveis no conteúdo e na organização do backlog do produto. Ninguém está
autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos e
a equipe de desenvolvimento não está autorizada a agir sobre o que outras pessoas disserem.
A equipe de desenvolvimento
A equipe de desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma
versão usável que potencialmente incrementa o produto “Pronto” no final de cada Sprint. Somente
membros da equipe de desenvolvimento criam o incremento.
As equipes de desenvolvimento são estruturadas e autorizadasligei pela organização para organizar e
gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e efetividade global. As
equipes de desenvolvimento têm as seguintes características:

Elas são auto organizadas. Ninguém (nem mesmo o Scrum Master) diz para a equipe de
projetos como transformar o Backlog de produto em incrementos de funcionalidades
potencialmente utilizáveis;
2
Nota do Tradutor: O termo em inglês é Product Owner e foi traduzido aqui como Dono do Produto, em letra
maiúscula, para indicar que é um papel representado no processo do Scrum e não aquele que seria o
proprietário do produto de software.
Pag. 5




Equipes de desenvolvimento são trans funcionais, com todas as habilidades necessárias para
criar o incremento do produto.
O Scrum não reconhece perfis dos membros da equipe de desenvolvimento além de
Desenvolvedor, independente do trabalho que está sendo realizado pela pessoa, não há
exceções a essa regra;
Individualmente os membros da equipe de desenvolvimento podem ter habilidades
especializadas e áreas de especialização, mas pertencem e respondem à equipe de
desenvolvimento como um todo; e,
Equipes de desenvolvimento não possuem sub-equipes dedicadas a domínios particulares do
conhecimento, como teste ou análise de negócio.
O Tamanho da Equipe de Desenvolvimento
O tamanho ótimo de uma equipe de desenvolvimento é suficientemente pequeno que se mantenha
ágil, e grande o suficiente para completar uma parcela representativa do trabalho. Menos do que três
membros em uma equipe de desenvolvimento diminui a interação e resulta em ganhos menores de
produtividade. Equipes pequenas podem encontrar limitações nas habilidades necessárias para um
Sprint, e como consequência não conseguindo entregar um incremento potencialmente utilizável.
Tendo mais do que nove membros se requer muita coordenação. Equipes de desenvolvimento grandes
geram muita complexidade para um processo empírico gerenciar. Os papeis de Dono do produto e o
Scrum Master não são incluídos nesta contagem a não ser que eles também executem o trabalho do
Sprint Backlog.
O Scrum Master
O Scrum Master é responsável para garantir que o Scrum seja entendido e aplicado. Os Scrum Masters
fazem isso garantindo que as equipes de Scrum obedeçam à teoria, práticas e regras do Scrum. O
Scrum Master é um líder-facilitador para a equipe do Scrum.
O Scrum Master ajuda aqueles de fora da equipe do Scrum entender quais são as interações com a
equipe do Scrum que são benéficas e quais não são. O Scrum Master ajudar todos a mudar suas
interações para maximizar o valor criado pela equipe de Scrum.
Os serviços do Scrum Master para o Dono do Produto
O Scrum Master serve ao Dono do produto de várias formas, incluindo:






Encontrar técnicas para o gerenciamento efetivo do Backlog do produto,
Comunicar claramente a visão, objetivos e os itens do Backlog do Produto para a Equipe de
Desenvolvimento,
Ensinar a Equipe de Desenvolvimento como criar itens do Backlog do produto claros e concisos,
Entender o planejamento de longo prazo do produto em um ambiente empírico,
Entender e praticar a agilidade,
Facilitar os eventos do Scrum quando solicitado ou necessário.
Os serviços do Scrum Master para a Equipe de Desenvolvimento
O Scrum Master serve a Equipe de Desenvolvimento de várias formas, incluindo:
Pag. 6





Orientar a Equipe de Desenvolvimento na sua auto organização e trans-funcionalidade,
Ensinar ou liderar a Equipe de Desenvolvimento para criar um produto de alto valor,
Remover impedimentos para o progresso da equipe de desenvolvimento,
Facilitar os eventos do Scrum quando solicitado ou necessário,
Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda não é
amplamente adotado e compreendido.
Os serviços do Scrum Master para a Organização
O Scrum Master serve a organização de várias formas, incluindo:





Liderar e Orientar a organização na adoção do Scrum,
Planejar as implementações do Scrum dentro da organização,
Ajudar empregados e stakeholders a entender e implantar o Scrum e o desenvolvimento
empírico de produtos,
Provocar mudanças que aumentem a produtividade na Equipe de Scrum,
Trabalhar com outros Scrum Masters para aumentar a efetividade da aplicação do Scrum na
organização.
Eventos do Scrum
Eventos prescritos são usados no Scrum para criar uma rotina e para minimizar a necessidade de
encontros não definidos no Scrum. O Scrum usa eventos time-boxed3, onde cada evento tem uma
duração máxima. Isso garante uma quantidade apropriada de tempo gasto em planejamento sem
permitir perdas no processo de planejamento.
Além da própria Sprint, que é um container para outros eventos, cada evento no Scrum é uma
oportunidade para inspecionar e adaptar algo. Estes eventos são projetados especificamente para
permitir uma transparência crítica e inspeção. Não incluir qualquer destes eventos é reduzir a
transparência e perder a oportunidade para inspecionar e adaptar.
O Sprint
O coração do Scrum é o Sprint, um time-box de um mês ou menos durante o qual uma versão
potencialmente utilizável de um incremento do produto é criada. Sprints tem durações consistentes ao
longo do esforço de desenvolvimento. Um novo Sprint começa imediatamente depois da conclusão do
Sprint anterior.
Sprints consistem em uma reunião de planejamento do Sprint, Scrums Diários, o trabalho de
desenvolvimento, a reunião de revisão do Sprint e a Retrospectiva do Sprint.
Durante o Sprint:

Nenhuma mudança deve ser feita que afete o objetivo do Sprint,
3
N.T. Time-boxed foi deixado em inglês por que reflete mais precisamente o conceito do Sprint no Scrum de ter
um prazo fixo (intervalo de tempo fixo).
Pag. 7


A composição da equipe de desenvolvimento e a qualidade dos objetivos se mantêm
constantes,
O escopo pode ser esclarecido e renegociado entre o Dono do produto e a equipe de
desenvolvimento quando for aprendido mais.
Cada Sprint pode ser considerado um projeto com um horizonte que não pode ser maior do que um
mês. Como projetos, Sprints são usados para se conquistar algo. Cada Sprint possui uma definição do
que deve ser construído, um projeto e um plano flexível que vai guiar a construção o trabalho e o
produto resultante.
Sprints são limitados a um mês corrido. Quando o horizonte do Sprint é muito longe a definição do que
será construído pode mudar, complexidade pode aumentar e o risco pode se elevar. Sprints permitem
a previsibilidade garantindo inspeção e adaptação do progresso na direção de um objetivo pelo menos
a cada mês. Sprints também limitam o risco ao custo de um mês.
Cancelando um Sprint.
Um Sprint pode ser cancelado antes cde o seu prazo ter se esgotado. Somente o Dono do produto tem
a autoridade para cancelar o Sprint, apesar de que ele (ou ela) pode fazer isso sob a influência dos
stakeholders, da equipe de Desenvolvimento ou do Scrum máster.
Um Sprint será cancelado se o Objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se empresa
mudar a direção ou se as condições de mercado ou tecnologia mudarem. Em geral, um Sprint deve ser
cancelado se ele não fizer mais sentido às dadas circunstâncias. Mas, dada a curta duração do Sprint, o
cancelamento raramente faz sentido.
Quando um Sprint é cancelado,, qualquer dos itens do Backlog do Produto que estiver completado e
“Pronto” é revisado. Se uma parte do trabalho estiver potencialmente entregável, o Dono do produto
[tipicamente], o aceita. Todo o trabalho incompleto do Backlog do Produto são re-estimados e
colocados novamente no Backlog do Produto. O trabalho Pronto nele deprecia rapidamente e deve ser
constantemente re-estimado.
O cancelamento de Sprints consome recursos, desde que todos devem se reagrupar em outra reunião
de planejamento de Spring para iniciar outro Sprint. O cancelamento de Sprints é sempre traumático
para a Equipe de Scrum, e é muito incomum.
Reunião de Planejamento do Sprint
O trabalho a ser executado no Sprint é planejado na Reunião de Planejamento do Sprint. Este plano é
criado pelo trabalho colaborativo de toda a equipe do Scrum.
A reunião de planejamento do Sprint é fixa em oito horas para um Sprint de um mês. Para Sprints mais
curtos, o evento é proporcionalmente menor. Por exemplo, Sprints de duas semanas, tem Reunião de
Planejamento do Sprint de quatro horas.
A Reunião de Planejamento do Sprint é dividida em duas partes, cada uma tendo a metade do tempo
fixo, dedicado à reunião de planejamento do Sprint. As duas partes da Reunião de Planejamento do
Sprint respondem às seguintes questões, respectivamente:
Pag. 8


O que vai ser entregue como resultado do Incremento do próximo Sprint?
Como será realizado o trabalho necessário para entregar o Incremento?
Parte 1: O que será Pronto neste Sprint?
Nesta parte, a Equipe de Desenvolvimento trabalhar para prever a funcionalidade que será
desenvolvida durante o Sprint. O Dono do Produto apresenta os itens do Backlog do produto
ordenado para a Equipe de Desenvolvimento e toda a Equipe do Scrum colabora no entendimento do
trabalho do Sprint.
Como dado de entrada para a reunião temos o Backlog do Produto, o último Incremento do produto, a
capacidade projetada da Equipe de Desenvolvimento durante o Sprint e o desempenho passado da
Equipe de desenvolvimento. Somente a equipe de desenvolvimento pode avaliar o que poderá
conseguir fazer no próximo Sprint.
Depois da previsão da Equipe de Desenvolvimento dos itens do Backlog do Produto que serão
entregues por este Sprint, a equipe de Scrum produz o Objetivo do Sprint. O Objetivo do Sprint é um
objetivo que será atingido pelo Sprint por meio da implementação do Backlog do Produto, e oferece
uma orientação para a Equipe de desenvolvimento sobre a construção do Incremento.
Parte 2: Como o trabalho escolhido será Pronto?
Tendo selecionado o trabalho do Sprint, a equipe de desenvolvimento decide como ela irá transformar
esta funcionalidade em Incrementos “Prontos” durante o Sprint. Os itens selecionados do Backlog do
Produto para este Sprint somado ao plano para entregá-los é chamados de Backlog do Sprint.
A equipe de desenvolvimento usualmente inicia desenhando o sistema e o trabalho que precisa ser
convertido de um Backlog do produto ao incremento executável do produto. O trabalho pode variar de
tamanho, ou estimativa de esforço. Entretanto, o trabalho suficiente é planejado durante a Reunião de
Planejamento do Sprint pela Equipe de Desenvolvimento para prever o que ela acredita possa fazer no
Sprint seguinte. O Trabalho planejado para os primeiro dias é decomposto em unidades de um dia ou
menos até o final da reunião. A equipe de Desenvolvimento se auto organiza para realizar o trabalho
no Backlog do Sprint, tanto durante a Reunião de Planejamento do Sprint e quando for necessário ao
longo do Sprint.
O Dono do Produto pode estar presente durante a segunda parte da Reunião de Planejamento do
Sprint para esclarecer itens selecionados do Backlog do Produto e para ajudar a realizar os
compromissos. Se a Equipe de Desenvolvimento determina que tenha demasiado trabalho ou que tem
pouco trabalho, ela pode renegociar itens do Backlog do Sprint com o Dono do Produto. A Equipe de
Desenvolvimento pode também convidar outras pessoas para participar da reunião, oferecendo
aconselhamento técnico ou do domínio.
No final da reunião de planejamento do Sprint, a Equipe de Desenvolvimento deve estar apta a
explicar ao Dono do Produto e ao Scrum Master como pretende trabalhar como uma equipe auto
organizada para conseguir criar o Incremento desejado e atingir o Objetivo do Sprint.
Objetivo do Sprint
O objetivo do Sprint dá alguma flexibilidade à equipe de desenvolvimento sobre as funcionalidades a
serem implementadas no Sprint.
Pag. 9
Com o andamento do trabalho da Equipe de Desenvolvimento, ela mantém em mente o objetivo. De
modo a atender ao objetivo do Sprint, ela implementa a funcionalidade e a tecnologia. Se o trabalho
se torna diferente do que o que a Equipe de Desenvolvimento esperava, ela pode colaborar com o
Dono do produto para negociar o escopo do Backlog do Sprint dentro do Sprint.
O objetivo do Sprint pode ser um marco dentro do propósito maior no mapa do produto.
Scrum Diário
A Reunião do Scrum Diário é um evento com 15 minutos fixos para a Equipe de Desenvolvimento
sincronizar as atividades e criar um plano para as próximas 24 horas. Isso se faz inspecionando o
trabalho até o último Scrum Diário e prevendo o trabalho que pode ser Pronto antes do próximo.
O Scrum diário se dá no mesmo horário e lugar todo o dia para reduzir a complexidade. Durante o
encontro, cada membro da Equipe de Desenvolvimento esclarece:



O que tem conseguido realizar desde o último encontro?
O que vai ser Pronto até o próximo encontro?
Quais são os obstáculos que estão no seu caminho?
A Equipe de Desenvolvimento usa o Scrum Diário para avaliar o progresso na direção do Objetivo do
Sprint e para avaliar se o progresso tende para completar o trabalho no Backlog do Sprint. O Scrum
Diário aumenta a probabilidade da Equipe de Desenvolvimento atingir o Objetivo do Sprint. A Equipe
de Desenvolvimento em geral, se encontra imediatamente depois do Scrum Diário para replanejar o
restante do trabalho do Sprint. Todo dia, a Equipe de Desenvolvimento deve estar apta a explicar para
o Dono do Produto e para o Scrum Master como pretende trabalhar em conjunto, como uma equipe
auto organizada para atingir o objetivo e criar o incremento desejado no restante do Sprint.
O Scrum Master garante que a equipe de desenvolvimento tem o encontro, mas a Equipe de
Desenvolvimento é responsável por conduzir o Scrum Diário. O Scrum Master ensina a Equipe de
Desenvolvimento a manter o Scrum Diário dentro do limite de tempo de 15 minutos.
O Scrum Master aplica a regra que somente os membros da Equipe de Desenvolvimento participem do
Scrum Diário. O Scrum Diário não é uma reunião de status, e é voltada para as pessoas que
transformam os itens do Backlog em um Incremento.
Os Scrums Diários melhoram a comunicação, eliminam outras reuniões, identificam e removem os
impedimentos para o desenvolvimento, destacam e promovem uma tomada de decisão rápida, e
melhoram o nível do conhecimento do projeto da Equipe de Desenvolvimento. Esta é a reunião chave
para inspeção e adaptação.
Revisão do Sprint
A Reunião de Revisão do Sprint é executada no final do Sprint para inspecionar o Incremento e adaptar
ao Backlog do Produto se necessário. Durante a Revisão do Sprint, a Equipe de Scrum e stakeholders
colaboram sobre o que foi Pronto no Sprint. Baseado nisso e em qualquer mudança no Backlog do
Produto durante o Sprint, os presentes colaboram nas próximas coisas que precisam ser feitas. Está é
Pag. 10
uma reunião informal, e a apresentação do Incremento tem como intenção motivar uma
realimentação e incentivar a colaboração.
Esta é uma reunião de time-box de 4 horas para um Sprint de um mês. Proporcionalmente menos
tempo é alocado para Sprints mais curtos. Por exemplo, Sprints de duas semanas vão ter Revisões de
Sprint de duas horas.
A Revisão do Sprint inclui os seguintes elementos:





O Dono do produto identifica que foi “Pronto” e o que não foi “Pronto”.
A Equipe de Desenvolvimento discute que foi bem durante o Sprint, quais problemas ocorreram
e como estes problemas foram resolvidos;
A Equipe de Desenvolvimento demonstra o trabalho que foi “Pronto” e responde as perguntas
sobre o incremento;
O Dono do Produto discute o Backlog do Produto. Ele projeta a data mais provável de término
baseado no progresso até o momento; e,
Todo o grupo colabora no que deve ser Pronto em seguida assim, a Revisão do Spring fornece
um entrada valiosa para as próximas reuniões de Planejamento do Sprint.
O resultado da revisão do Sprint é um Backlog do Produto revisado que define os prováveis itens do
Backlog do Produto para a próxima Sprint. O Backlog do produto pode ser ajustado como um todo
para atender novas oportunidades.
A Retrospectiva do Sprint.
A retrospectiva do Sprint é uma oportunidade para a Equipe do Scrum inspecionar-se a si mesma e
criar um plano de melhorias que deve ser valer durante o próximo Sprint.
A Retrospectiva do Sprint ocorre depois da Revisão do Sprint e antes da Próxima reunião de
planejamento do Sprint. Esta é uma reunião marcada para com um time-box de 3 horas para um mês
de Sprints. Proporcionalmente um tempo menor é alocado para Sprints menores.
O propósito da Retrospectiva do Sprint é:



Inspecionar como foi o último Sprint no que diz respeito a pessoas, relações, processos e
ferramentas,
Identificar e ordenar os principais itens que foram bem e as potenciais melhorias,
Criar um plano para programar melhorias no modo de como a Equipe de Scrum trabalha.
O Scrum máster encoraja a Equipe de Scrum para melhorar, dentro do framework de processo do
Scrum, o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para o
próximo Sprint. Durante cada Retrospectiva do Sprint, a Equipe de Scrum planeja modos para
aumentar a qualidade do produto adaptando a definição de “pronto” quando apropriado.
No final da retrospectiva do Sprint, a equipe de Scrum deve identificar melhorias que serão aplicadas
no próximo Sprint. Implementar estas melhorias no próximo Sprint é adaptar a inspeção na própria
Pag. 11
Equipe do Scrum. Apesar de que melhorias podem ser adotadas a qualquer momento, a Retrospectiva
do Sprint oferece um evento dedicado focado na inspeção e adaptação.
Artefatos de Scrum
Os artefatos do Scrum representam o trabalho ou valor de várias formas que são úteis de oferecer
transparências e oportunidades para inspeção e adaptação. Os artefatos definidos no Scrum são
especialmente projetados para maximizar a transparência e a informação chave necessários para
garantir que as equipes do Scrum sejam bem sucedidas ao entregar o Incremento “Pronto”.
Backlog do produto
O Backlog do produto é uma lista ordenada de tudo o que pode ser necessário no produto e é a fonte
única dos requisitos para qualquer mudança a ser feita no produto. O Dono do Produto é responsável
para o Backlog do Produto, incluindo o seu conteúdo, disponibilidade e ordenação.
Um Backlog do produto nunca está completo. A versão inicial dele apenas descreve o que foi
conhecido no início e os requisitos mais bem conhecidos. O Backlog do produto evolui ao mesmo
tempo em que o produto e o ambiente no qual ele será usado evolui. O Backlog do Produto é
dinâmico; ele muda constantemente para identificar o que o produto precisa para ser útil, apropriado
e competitivo. Enquanto um produto existir, um Backlog do Produto deve existir.
O Backlog do Produto lista todas as funcionalidades, funções, requisitos, melhorias e consertos que
representam as mudanças a serem feitas no produto para as próximas versões. Os itens do Backlog do
Produto tem os atributos de descrição, ordem e estimativa.
O Backlog do produto é, geralmente, ordenado por valor, risco, prioridade e necessidade. Os itens
mais altos do Backlog do Produto determinam atividades de desenvolvimento mais imediatas. Quanto
mais alto a ordem do item, mais o item do Backlog do Produto deve ser considerado, e mais consenso
existe a respeito deste valor.
Itens do Backlog do produto de ordem mais alta devem ser mais claros e serem mais detalhados que
os de ordem inferior. Estimativas mais precisas são feitas com base na maior clareza e aumento de
detalhes; quanto mais baixa a ordem, menos detalhes. Os itens do Backlog do Produto que vão ocupar
a equipe de desenvolvimento no próximo Sprint são bem refinados, tendo sido decompostos para que
todos os itens possam ficar “Prontos” dentro dos limites do Time-box do Sprint. Os itens do Backlog do
Produto que podem ficar “Prontos” pela Equipe de Desenvolvimento dentro de um Sprint são
marcados como “disponíveis” ou “executáveis” para seleção na reunião de Planejamento do Sprint.
Enquanto um produto é usado, e ganha valor, e o mercado oferece uma realimentação, o Backlog do
Produto se torna uma lista longa e mais completa. Requisitos nunca param de mudar, assim o Backlog
do produto é um artefato vivo. Mudanças nos requisitos do negócio, condições de mercado ou
tecnologia podem provocar mudanças no Backlog do produto.
Múltiplas Equipes de Scrum frequentemente trabalham juntas no mesmo produto. Um Backlog do
Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog o Produto
que agrupa os itens é aplicado.
Pag. 12
A preparação do Backlog do produto é o ato de adicionar detalhes, estimativas e ordenar os itens no
Backlog do produto. Este é um processo contínuo no qual o Dono do Produto e a Equipe de
Desenvolvimento colaboram nos detalhes dos itens do Backlog do produto. Durante a preparação do
Backlog do Produto, os itens são analisados e revisados. Entretanto, eles podem ser atualizados a
qualquer momento pelo Dono do Produto ou escolha do Dono do Produto.
Preparação é uma atividade em tempo parcial durante um Spring entre o Dono do Produto e da
Equipe de Desenvolvimento. Frequentemente as equipes de Desenvolvimento devem preparar o
próprio domínio do conhecimento. Como e quando a preparação é feita é decidida pela Equipe do
Scrum. Preparação usualmente consome não mais do que 10% da capacidade da Equipe de
Desenvolvimento.
A equipe de desenvolvimento é responsável por todas as estimativas. O Dono do produto pode
influenciar a equipe ajudando a entender e selecionar os compromissos, mas as pessoas que vão
realizar o trabalho é quem deve fazer a estimativa final.
Monitorando o Progresso na direção de um Objetivo
Em qualquer momento no tempo, o trabalho total restante para se atingir um objetivo pode ser
sumarizado. O Dono do Produto acompanha o trabalho total restante pelo menos em cada Revisão do
Sprint. O Dono do Produto compara o total de trabalho faltante na revisão anterior do Sprint para
avaliar o progresso na direção de completar o trabalho projetado pelo tempo estimado para o
objetivo. Esta informação se torna transparente para todos os stakeholders.
O Scrum não consideram o tempo gasto no trabalho com os Itens do Backlog do produto. O trabalho
restante e as datas são as únicas variáveis de interesse.
Várias práticas como burndown, burnup e outras práticas de estimativa tem sido usadas para prever o
progresso. Elas tem se provado úteis. Entretanto, Elas não substituem a importância do empirismo. Em
ambientes complexos, o que vai acontecer é desconhecido. Somente o que aconteceu pode ser usado
para uma tomada de decisão do que vai vir.
Backlog do Sprint
O Backlog do Sprint é um conjunto de itens do Backlog do produto selecionados para o Sprint além de
um plano para obter o incremento do produto e atingir o objetivo do Sprint. O Backlog do Sprint é uma
previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do
trabalho necessário para entregar esta funcionalidade.
O Backlog do Sprint define o trabalho que a Equipe de Desenvolvimento irá desempenhar para
transformar os itens do Backlog do produto em Incrementos “Prontos”. O Backlog do Sprint torna
visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o
Objetivo do Sprint.
O Backlog do Sprint é um plano com detalhes suficiente que as mudanças em progresso sejam
entendidas no Scrum Diário. A Equipe de Desenvolvimento modifica o Backlog do Sprint ao longo do
Sprint, e o Backlog do Sprint surge durante o Sprint. Este surgimento ocorre quando a Equipe de
Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o
objetivo do Sprint.
Pag. 13
Se um novo trabalho for necessário, A Equipe de Desenvolvimento o adiciona ao Backlog do Sprint. Na
medida em que o trabalho é desempenhado e completado, a estimativa do trabalho restante é
atualizada. Quando elementos do plano se mostrarem desnecessários, eles são removidos. Somente a
Equipe de Desenvolvimento pode alterar o Backlog do Sprint durante o Sprint. O Backlog do Sprint é
uma figura em tempo real, altamente visível, do trabalho que a Equipe de Desenvolvimento planeja
atingir durante o Sprint, e pertence somente à Equipe de desenvolvimento.
Monitoramento do Progresso do Sprint
A qualquer instante do tempo de um Sprint, o trabalho total restante nos itens do Backlog do Sprint
pode ser sumarizado. A Equipe de desenvolvimento acompanha este total de trabalho restante pelo
menos todo Scrum Diário. A Equipe de Desenvolvimento acompanha estes totais diários e projeta a
que mais provavelmente vai alcançar o Objetivo do Sprint. Por rastrear o trabalho restante pelo Sprint,
a Equipe de Desenvolvimento pode gerenciar o seu progresso.
O Scrum não considera o tempo gasto nos itens do Backlog do Sprint. O trabalho restante e as datas
são as únicas variáveis de interesse.
Incremento
O incremento é a soma de todos os itens do Backlog do produto completados por um Sprint e por
todos os Sprints anteriores. No final de um Sprint, o novo Incremento deve estar “Pronto”, o que
significa que ele está em uma condição utilizável e atende à definição da Equipe do Scrum do “Pronto”.
Ele deve estar em uma condição utilizável independente da decisão do Dono do Produto decidir
realmente liberá-lo.
Definição do “Pronto”
Quando um item do Backlog do Produto ou um Incremento é descrito como “Pronto”, todos devem
entender o que “Pronto” significa. Apesar de que isso pode variar significativamente para cada Equipe
de Scrum, os membros devem ter um entendimento compartilhado do que significa que o trabalho
estar completo, para garantir transparência. Esta é a “definição de “Pronto”” para a equipe do Scrum e
é usado para avaliar quando o trabalho está completo no Incremento do Produto.
A mesma definição orienta a Equipe de Desenvolvimento em saber quantos itens do Backlog do
produto ela pode selecionar durante a Reunião de Planejamento do Sprint. O propósito de cada Sprint
é entregar Incrementos de funcionalidades potencialmente utilizáveis que atende à definição atual da
equipe de Desenvolvimento para “Pronto”.
A Equipe de Desenvolvimento entrega um Incremento da funcionalidade do Produto a cada Sprint.
Este Incremento é usável, assim o Dono do produto pode decidir liberá-lo imediatamente. Cada
Incremento é adicionável ao todos os Incrementos anteriores e por meio de testes, garantir que too o
incremento trabalha em conjunto.
Na medida de que a equipe de Scrum fica madura, se espera que a definição de “Pronto” expanda para
incluir critérios mais rigorosos de maior qualidade.
Pag. 14
Conclusão
O Scrum é livre e proposto neste guia. Os papeis, artefatos, eventos e regras do Scrum são imutáveis e
apesar de que implementação apenas de partes do Scrum é possível, o resultado não é um Scrum. O
Scrum existe somente na sua totalidade e funciona bem como um container para outras técnicas,
metodologias e práticas.
Pag. 15
Agradecimentos
Pessoas
Das milhares de pessoas que tem contribuído para o Scrum, nós gostaríamos de destacar aqueles que
foram essenciais nos seus primeiros anos. Inicialmente a Jeff Sutherland, trabalhando com Jeff
McKenna e Ken Schwaber, trabalhando com Mike Smith e Chris Martin. Muitos outros contribuiram
nos anos seguintes e sem a sua ajuda, o Scrum não seria refinado como é hoje. David Starr ofereceu
insights chave e habilidades editoriais na formulação desta versão do Guia do Scrum.
História
Ken Schwaber e Jeff Sutherland co-apresentaram inicialmente na conferencia OOPSLA em 1XXX. Esta
apresentação essencialmente documentou o aprendizado de Ken e Jeff nos anos que antecederam a
aplicação do Scrum. A história do Scrum já é considerada longa. Para honrar os primeiros lugares onde
ele foi tentado e refinado, nós reconhecemos a Individual, Inc., Fidelity Investments e IDX (hoje GE
Medical).
Pag. 16
Revisões
O Guia do Scrum de Julho de 2011 é diferente do seu predecessor, o Guia de Fevereiro de 2010. Em
particular, nós tentamos remover técnicas e boas práticas do núcleo do Scrum. Elas podem variar
baseado nas circunstâncias. Nós vamos começar um compêndio de boas práticas para prover um
pouco da nossa experiência recente.
O Guia do Scrum documenta o Scrum enquanto ele se desenvolve e se mantém por mais de vinte
anos por Jeff Sutherland e Ken Schwaber. Outras fontes provêm padrões, processos e visões sobre
como as práticas, facilitadores e ferramentas complementam o framework do Scrum. Isto aperfeiçoa a
produtividade, valor, criatividade e orgulho.
Notas emitidas cobrindo as seguintes diferenças entre este guia e a versão de 2010 serão publicadas
em outros lugares, incluindo discussões sobre:
1. Planejamento de Release.
2. Burndown do Release.
3. Backlog do Sprint.
4. Burndown do Product e Backlog do Sprint Backlog.
5. Compromisso agora é previsão.
6. Equipe (para Equipe de Desenvolvimento).
7. Porcos e Galinhas … o conto do Scrum.
8. Ordenados no lugar de priorizados.
Pag. 17

O Guia do Scrum

Transcrição

Documentos relacionados

Scrum para times – As cerimônias do Scrum

Resumo do mês de março

Série E3000 - Johnson Health Tech Brazil

Processos de Software: Conceitos Básicos - LES PUC-Rio

Demitir os clientes não

Marcelo Augusto Lima Painka

Reuniões Ágeis

Metodologia de Gestão à Vista Acessível para Deficiente Visual

Rules U-13, U-15, U-17 e U-19

BRUNO BORGES DA SILVA