Organiza o desenvolvimento em Sprints
Duração: 1-4 semanas
Sprint finaliza mesmo com trabalho incompleto (timebox)
Equipe muti-funcional seleciona requisistos priorizados do cliente
Requisitos não mudam durante o sprint
Atualização diária do progresso do trabalho
Gráficos orientam sobre o trabalho restante
Ao final do sprint demonstra-se o que foi produzido
Revisão e feedback da Sprint com envolvidos
Enfatiza produto funcional ao final da sprint
Propõe: Inspecione e Adapte
Para acomodar o aprendizado, inovação e surpresas
Tome uma pequena porção do desenvolvimento
Inspecione o produto resultante
Inspecione a eficiencia das práticas correntes
Adapte o produto resultante e as práticas
Repita continuamente esse processo
Papeis do Scrum
Dono do produto (product owner)
Interage frequentemente com o time priorizando e recebendo entregas das iterações
Produto comercial
Responsável pelo lucro e prejuizos
Aplicação de uso interno
Responsável por escolher os itens de melhor benefícios e menor custo de cada sprint
Time (team)
Constroi o produto para o cliente
É multifuncional
Auto-organizado e gerenciado
Tamanho de 7 +- 2 pessoas
100% dedicado ao projeto
Times maiores são organizados em multiplos times
Alta produtividade decorrente de pouca mudança no time
Líder do Scrum (Scrum Master)
Objetivo de ajudar o time a aplicar o Scrum para obter valor ao negócio
Iniciando o Scrum
Dono do produto define a visão do produto
Gera lista de funcionalidades: backlog do produto
release backlog : subconjunto de funcionalidades para uma release
É continuamente atualizado
O time fornece estimativas de esforço para o dono do produto
Estimativa em pontos em vez de esforço de pessoas por semana
Cria base histórica
O dono do produto prioriza o backlog para maximizar o ROI ou reduzir riscos
Itens podem variar em tamanho e esforço
Item maiores são quebrados em menores
Itens menores são agrupados em maiores
Mito:evitar escrever especificação detalhada
Dono do produto e time decidem
Pode variar entre itens do backlog
Fazer só o necessário para ser entendido
Planejamento do Sprint
Dividido em duas reuniões
Planejamento Sprint Parte 1 (O que o dono do produto quer?)
Quem? Dono do Produto e Time (com ajuda do Líder do Scrum)
revisam itens de alta prioridada do backlog do produto
Discutem objetivos e contexto dos itens
Revisam a definição de "feito"
Codificação segundo padrões
Revisão de código
Implementação com test driven development
Testado 100% com automação
Integrado e documentado
Ao término o dono do produto é dispensado
Deve estar disponível (por telefone) na próxima parte do planejamento
Planejamento Sprint Parte 2 (Como implementar os itens)
Inicia-se com a estimativa de tempo disponível de cada membro para tarefas do Sprint
Varia de 4 a 6 horas por dia
Time decide o que implementar (prática chave)
Baseado nos itens de maior prioridade
São quebrados em tarefas
São registradas no backlog do Sprint
Até preencher o tempo disponível do time
Baseado na análise do time e não por imposição
O dono do produto sabe que os itens serão escolhidos do topo do backlog do produto
Gasta algumas horas
O time está tomando importantes decisões
Ao final da reunião se produz uma lista com todas tarefas, responsáveis e estimativas
Incentiva membros com múltiplas capacidades
Membros vão onde o trabalho está
Não significa que todos são generalistas
Trabalho em equipe e aprendizado um com outro
No planejamento da Sprint não é adequado se candidatar a todas atividades que sabe fazer melhor
Se candidatar a uma tarefa por vez
Quando assumir nova tarefa, escolher aquelas que tragam aprendizado
Talvez em par com especialista
Como as mudanças são tratadas?
Iniciado um Sprint, mudanças só ocorrem no próximo Sprint
Benefícios?
1. Mantém o foco do time em completar a entrega
2. Disciplina o dono do produto na priorização do backlog do produto
Ganhos para o dono do produto?
1. Certeza que a equipe finalizará o que por ele foi priorizado
2. Ele pode fazer qualquer tipo de mudança antes do início do Sprint
3. Ele está sempre a um Sprint ou menos de poder fazer as mudanças que desejar
Fim do estigma das mudanças
O que faz do dono do produto um entusiasta do Scrum
Se circunstâncias externas altera fortemante as prioridades?
Podendo causar perda do trabalho realizado...
O dono do produto ou o time aborta a Sprint
Uma nova reunião de planejamento da Sprint se inicia
Resultado: forte impacto no projeto
Serve para não incentivar essa atitude
Dia a dia do Scrum (Reunião diária 15 min)
Prática chave do Scrum
Oportunidade para o time relatar progressos e obstáculos
Não é status report para o gerente
Tempo para auto-organização do time
Cada membro relata 3 coisas
1. O que foi feito desde a última reunião
2. O que está planejado para finalizar até a próxima reunião
3. Impedimentos para progresso do trabalho
Não há discussões na reunião diária
Se necessária ocorre após a reunião
Participação não obrigatória
Não recomenda-se a participação do gerente
Dá o sentimento de monitoração
Inibe o relato de problemas
Mina a auto-gestão do time
Incentiva a micro-gestão
Se necessário, o gerente oferece ajuda após a reunião
Ajudar a remover os impedimentos para o progresso do trabalho
Atualização do Backlog do Sprint e do Gráfico Burndown
Backlog do Sprint
Cada membro atualiza diáriamente as estimativas de tempo necessário para completar a tarefa
Consolida-se o tempo necessário para completar as tarefas de todo o time
Gera-se o Gráfico Burndown
Exibe total de horas restantes para finalização do Sprint
Algumas vezes parece bom, outras não
É a realidade do desenvolvimento
Demonstra o progresso do time rumo ao objetivo
Mostra quanto trabalho falta fazer
Não mostra o que foi feito
Se o gráfico não converge para a finalização - tomar ações
Reduzir escopo
Melhorar a eficiencia
Geralmente desenhado com papel e caneta
Colado na parede no local de trabalho
Refinamento do Backlog do produto
Prática menos conhecida, mas de valor
5 a 10 % do Sprint para refinamento do backlog do produto
Análise detalhada de requisitos
Quebra de itens maiores em menores
Estimativas de novos itens
Como fazer?
Workshop próximo do final da Sprint
Participam o time e o dono do produto
Consome meio dia num Spint de duas semanas
Não aplica-se para itens do sprint corrente
Aplica-se para os dois próximos sprints
Benefícios?
Facilidade no planejamento do sprint
Time e dono do produto possuem clareza sobre os itens estimados
E se não for feito?
Dificuldade no planejamento da sprint
Muitas perguntas
Confusões
Novas descobertas
Finalização do Sprint
Principio Chave: Duração do Sprint nunca muda
É finalizado independente da conclusão das tarefas
O time sobrecarrega-se nos 1ºs sprints
Falha-se no cumprimento dos objetivos
O time então super-estima os próximos sprints
Termina o trabalho cedo demais
A partir do 3º ou 4º sprint as estimativas ficam adequadas
O time deve escolher e trabalhar sempre com a mesma duração de sprint
Ajuda a aprender sobre a capacidade de entrega
Ajuda o time a encontrar o ritimo - heartbeat
Revisão do Sprint
É uma atividade de inspeção e adaptação para o produto
Tempo do dono do produto saber:
Como está indo o produto
Como está indo a equipe
Tempo da equipe saber:
O que pensa o dono do produto
Como está indo o mercado
Elemento mais importante?
Conversa aprofundada entre o time e o dono do produto
Demonstração do produto
30 minutos para sua preparação
Qual o papel do lider do Scrum?
Demonstrar ao dono do produto que o time cumpriu a definição de "trabalho feito"
Dá visibilidade a qualidade do trabalho
Não permite a liberação de um produto sem qualidade
Quem participa?
Dono do produto
Membros do time
Lider Scrum
Clientes, envolvidos, gerentes e outros interessados
Retrospectiva do Sprint
É uma atividade de inspeção e adaptação para o processo
Principal mecanismo de melhorias
Descobrir o que funciona e o que não funciona
Combinar o que deve ser mudado
Quem participa?
Obrigatório: time e lider Scrum
Lider Scrum pode ser o facilitador
Pode-se utilizar um lider Scrum de outro projeto como facilitador
Opcional: dono do produto
Como organizar?
Quadro branco com duas colunas
O que funcionou bem?
O que pode ser melhorado?
Análise de causas
Acordo sobre mudanças necessárias
Marcar cada coluna com C,E, N
C:causado pelo Scrum
E: exposto pelo Scrum
N: não relacionado ao Scrum
Resultados esperados?
Diversos Cs na coluna "o que funcionou bem"
Diversos Es na coluna "o que pode ser melhorado"
Boa notícia?
O Scrum dá visibilidade às necessidades de melhoria
O Scrum é um catalizador para melhorias no processo
Atualização do Backlog de Release e Gráfico Burndown do Release
Responsabilidades do dono do produto
Refletir no Backlog do release e do produto as alterações necessárias
Responsabilidades do líder Scrum
Ajudar o dono do produto na elaboração do Gráfico Release Burndown
Gráfico semelhante ao Sprint Burndow
Possui requisitos em vez de tarefas
Iniciando o próximo Sprint
Ocorre após a revisão do sprint
O dono do produto atualiza o backlog do produto
Não há intervalo entre sprints
A retrospectiva ocorre em uma tarde
O planejamento da nova sprint inicia-se na manhã seguinte
Sprint de release
O que propõe a visão perfeita do Scrum?
Tudo está completamente pronto ao final de uma revisão de sprint
Devido a fraquezas das práticas nas empresas, isso não é possível
Demanda trabalho remanescente:
Teste de integração
Necessidade de "sprint de release"
Sinal de fraqueza
Planejamento do Release e Refinamento Inicial do Backlog do produto
Como o planejamento de um release de longo prazo pode ser feito?
Cenário 1: 1º release de um produto novo
Refinamento do Backlog do produto
Dono do produto e o time definem o backlog
Gasta alguns dias ou semana
analise requisitos e estimativas
Cenário 2: Um release para um produto existente
Não há necessidade de um planejamento de release para a próxima versão
O dono do produto e o time fazem o refinamento do backlog do produto a cada Sprint
Consome de 5 a 10% do sprint
Cenário 3: Release direcionado a data
Time realiza tantas sprints quanto possível no tempo
Cenário 4: Produtos que requerem determinadas funcionalidades para serem usáveis
O dono do produto pode optar por fazer releases intermediários
Visa demonstrar para o cliente os benefícios o mais cedo possível
Como não é possível antever tudo antecipadamente
Deve-se criar um plano que de direção ao release do produto
Declara-se os prós e contras (escopo x prazo)
O dono do produto opta por um tipo de release
Data
Time e dono do produto definem o que pode ser entregue nessa data
Preço Fixo/Data Fixa/Escopo Fixo
Necessidade de um contrato
Colocar um buffer em um desses parametros para acomodar mudanças
Foco em aplicação ou produtos
Mudança de centrado em projeto para modelo de desenvolvimento contínuo de produto
Não existe um projeto com começo, meio, fim
Não existem um gerente tradicional
Existe apenas um dono do produto
E um time auto-gerido
Que trabalham em Sprints de 2 a 4 semanas
Desafios comuns
Dono do produto não conhece o mercado, as funcionalidades ou estimativas de valor ao negócio
O time não está capacitado para estimativas de esforço para o desenvolvimento
Tentação de mudar o Scrum e não as práticas do time
Acreditar que uma prática é desencorajada porque o Scrum não a requer
Scrum não resolve os problemas do desenvolvimento
Mas os torna visíveis e prove um framework para solução
Scrum é difícil, mas é bem melhor do que a abordagem tradiconal
Resultados do Scrum (comparado com a abordagem previa)
Produtividade: 68% melhor ou muito melhor
Moral do time: 52% melhor ou muito melhor
Colaboração: 81% melhor ou muito melhor
Produtividade: 36% de ganho
Continuaria utilizando o Scrum: 85%
