Download - Gerenciamento Ágil de Projetos Com Scrum
Gerenciamento Ágil de Projetos com Scrum
Alunos: Douglas Souza, Erick Augusto, Izaias Xavier,Marcelo “Joshua”, Rodrigo Zilio, Talles Takagi,
Yuri Karan.
Slides baseados no Guia do Scrum de Ken Schwaber e Jeff Sutherland
Definição
➢ Problemas complexos e adaptativos.
➢ Produtos com mais alto valor possível.
➢ Não é:○ Processo ou uma técnica para construir produtos.
➢ O que realmente é:○ Framework dentro do qual pode-se empregar vários
processos ou técnicas.
➢ A eficácia é relativa○ Você pode melhorar as práticas.
Teoria Scrum
➢ Empirismo
➢ Aborgadem iterativa e incremental○ previsibilidade e controle de riscos.
Três pilares apóiam o controle do processo empírico:
➢ Transparência➢ Inspeção➢ Adaptação
Transparência
➢ Visibilidade de aspectos significativos do processo
➢ Padrão○ Mesmo entendimento do que está sendo visto
Inspeção
➢ Artefatos Scrum e o progresso○ Detectar variações
➢ Não muito frequente○ Não atrapalhar a execução de tarefas
➢ Inspetores especializados○ Mais benéfico
Adaptação
➢ Caso haja desvios○ Reajustar o processo ou o material sendo produzido
➢ Realizado o mais breve possível
Time Scrum
Composto por:
➢ Product Owner / Dono do produto➢ Time de Desenvolvimento➢ Scrum Master
➢ Auto-organizáveis○ Forma de completarem seu trabalho
➢ Multifuncionais○ Todas as competências necessárias
➢ Forma iterativa e incremental○ Realimentação○ Produto “Pronto” sempre disponível
Product Owner
➢ Maximizar valor do produto e do trabalho do Time de Desenvolvimento
Product Owner
➢ Gerenciar o Backlog do produto○ Pode delegar para o Time de Desenvolvimento○ Continua sendo o responsável
Product OwnerGerenciamento do Backlog do produto:➢ Clarificar os itens➢ Ordenar➢ Valor do trabalho➢ Torná-lo visível e transparente➢ Entendimento necessário dos itens
Product Owner
➢ É uma pessoa, não um comitê○ Pode representar um comitê no Backlog do Produto
Product Owner
➢ Alterações nas prioridades dos itens devem passar por ele
Time de Desenvolvimento
➢ Entregar versão usável no fim da Sprint➢ Auto-organizados➢ Multifuncionais
Time de Desenvolvimento
➢ Sem títulos➢ Responsabilidade ao time como um todo➢ Sem sub-times
Time de Desenvolvimento/Tamanho ➢ Pequeno o suficiente para manter ágil
➢ Grande o suficiente para completar tarefas em uma Sprint
Time de Desenvolvimento/Tamanho
➢ Pequenos DEMAIS:○ Menos que três integrantes○ Menos interação○ Menor ganho de produtividade○ Restrições de habilidade
Time de Desenvolvimento/Tamanho
➢ Grande DEMAIS :○ Mais que nove integrantes○ Muita coordenação é exigida○ Muita complexidade para um processo empírico
Scrum Master➢ Garantir que o Scrum seja entendido e
aplicado➢ Fora do time:
○ entender interações úteis➢ No time:
○ Maximizar o valor criado
Scrum Master/ Product Owner
➢ Técnicas para o gerenciamento efetivo do Backlog;
➢ Comunicar a visão, objetivo e itens do Backlog para o Time claramente;
Scrum Master/ Product Owner
➢ Ensinar o Time a criar itens de Backlog de forma clara e concisa;
➢ Compreender a longo-prazo o planejamento do Produto no ambiente empírico;
Scrum Master/ Product Owner
➢ Compreender e praticar a agilidade; e,
➢ Facilitar os eventos Scrum conforme exigidos ou necessários.
Scrum Master / Time de Desenvolvimento
➢ Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
➢ Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor;
Scrum Master / Time de Desenvolvimento
➢ Remover impedimentos para o progresso do Time de Desenvolvimento;
➢ Facilitar os eventos Scrum conforme exigidos ou necessários; e,
Scrum Master / Time de Desenvolvimento
➢ Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.
Scrum Master / Organização
➢ Liderando e treinando a organização na adoção do Scrum;
➢ Planejando implementações Scrum dentro da organização;
Scrum Master / Organização
➢ Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
➢ Causando mudanças que aumentam a produtividade do Time Scrum; e,
Scrum Master / Organização
➢ Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.
Eventos Scrum
➢ Criar rotina➢ Minimizar necessidade de outras reuniões➢ Time-boxed➢ Sprint
○ possui duração fixa➢ Outros eventos
○ podem acabar antes do limite
➢ Oportunidade para inspecionar e adaptar➢ Permitir transparência e inspeção criteriosa➢ Não é aconselhada a retirada de um dos
eventos○ Redução da transparência○ Perda de oportunidade para inspecionar e adaptar
Sprint
➢ É um time-boxed de um mês ou menos➢ É criado um “Pronto”
○ Versão potencialmente utilizável do produto○ Incremental
➢ Inicia imediatamente após a conclusão da Sprint anterior
Sprint
➢ São compostas por:○ Reunião de planejamento da Sprint○ Reuniões diárias○ Trabalho de desenvolvimento○ Revisão da Sprint○ Retrospectiva da Sprint
Sprint
➢ Durante a Sprint:○ Não são feitas mudanças que ponham em perigo o
objetivo da Sprint○ As metas de qualidade não diminuem○ Escopo pode ser clarificado e renegociado
■ Conforme o aprendizado
Sprint
➢ Cada Sprint pode ser considerada um projeto○ Temporários
■ Horizonte não maior que um mês.○ Entregam produtos
■ “Pronto”○ etc.
Sprint
➢ Cada Sprint possui:○ Definição do que é para ser construído○ Plano projetado e flexível○ O trabalho○ Resultado do produto
Sprint
➢ Quando o horizonte da Sprint é muito longo:○ a definição do que será construído pode mudar○ A complexidade pode aumentar○ O risco pode crescer
Sprint
➢ Permitem previsibilidade○ garante a inspeção e adaptação
➢ Limitam o risco ao custo de um mês corrido
Cancelamento da Sprint
➢ Product Owner possui a autoridade para isto○ Pode fazer sob influência
■ Partes interessadas,■ Time de Desenvolvimento e■ Scrum Master
Cancelamento da Sprint
➢ Objetivo da Sprint se tornou obsoleto○ Organização mudou de direção○ As condições do mercado ou das tecnologias
mudaram○ Não faz mais sentido dadas às circunstâncias
Cancelamento da Sprint
➢ Raramente faz sentido○ Devido a curta duração da Sprint
Cancelamento da Sprint
➢ Revisados○ Itens do Backlog do Produto completados○ “Pronto”
➢ Parte utilizável do trabalho, tipicamente é aceita pelo Product Owner
Cancelamento da Sprint
➢ Itens incompletos são reestimados e colocado de volta no Backlog do Produto.
➢ Trabalho feito deve ser frequentemente reestimado.
Cancelamento da Sprint
➢ Cancelamento de Sprints consome recursos○ Nova reunião de planejamento da Sprint (Nova
Sprint)
➢ Frequentemente são traumáticos para o time
Reunião de Planejamento da Sprint➢ Onde o trabalho a ser realizado na Sprint é
planejado➢ Criado com a colaboração de todo o Time
Scrum➢ Time-box com no máximo 8 horas para
Sprint de mês de duração
Reunião de Planejamento da Sprint➢ Scrum Master:
○ garante que evento ocorra○ garante que os participantes entendam seu propósito○ Mantem o time dentro dos limites do time-box
Reunião de Planejamento da Sprint
➢ Responde as seguintes questões:○ O que pode ser entregue?○ Como o trabalho será realizado?
➢ Com outras palavras:○ O que pode ser Pronto nesta Sprint?○ Como o trabalho escolhido será Pronto?
Objetivo ou meta da Sprint➢ Criado durante a reunião de planejamento
da Sprint➢ Pode ser satisfeito através da implementação
do Backlog da Sprint.➢ Faz o Time trabalhar em conjunto.
Objetivo ou meta da Sprint➢ Time deve manter o objetivo em mente.➢ Time implementa a funcionalidade e a
tecnologia.➢ Trabalho diferente do esperado
○ Time e Product Owner colaboram para negociar escopo do Backlog da Sprint.
Reunião diária
➢ Limite de 15 minutos (time-boxed)
➢ Sincronizar atividades
➢ Criar um plano para as próximas 24 horas.
Reunião diária➢ Inspecionar trabalho feito desde a última
Reunião.➢ Prever trabalho feito antes da próxima
Reunião.➢ Sempre no mesmo horário e local
Reunião diária● O que fiz ontem?● O que farei hoje?● Quais são os obstáculos?
As perguntas sempre se referem a meta do Time na Sprint.
Reunião Diária➢ Time inspeciona o progresso
○ Em direção ao objetivo da Sprint?○ Tende a completar o trabalho do Backlog da Sprint?
➢ Aumenta a probabilidade do Time atingir o objetivo da Sprint.
Reunião Diária➢ O Time é responsável pela condução da
Reunião.➢ Scrum Master para a Reunião Diária :
○ Assegura que ocorra.○ Ensina o Time a mantê-la dentro do time-
box de 15 min.○ Reforça que somente integrantes do Time
participam.
Reunião Diária➢ Melhoram comunicações.➢ Eliminam outras reuniões.➢ Identificam e removem impedimentos➢ Rápidas tomadas de decisão➢ Melhoram o nível de conhecimento do Time.➢ Reunião chave para inspeção e adaptação.
Revisão da Sprint➢ Executada no final da Sprint➢ Inspecionar o incremento➢ Adaptar o Backlog do Produto, se necessário.➢ Time e as partes interessadas colaboram
sobre o que foi feito na Sprint
Revisão da Sprint➢ Colaboração nas próximas coisas que podem
ser feitas○ otimizar valor.
➢ Reunião informal○ Não é reunião de status
➢ Apresentação do incremento○ Motivar e obter comentários○ Promover a colaboração
Revisão da Sprint➢ Time-boxed de 4 horas de duração
○ Sprint de um mês.➢ Scrum Master:
○ Garante que o evento ocorra○ Garante que os participantes entendam seu objetivo○ Ensina a todos a manter a reunião dentro dos
limites do Time-box.
Revisão da Sprint➢ Participantes:
○ Time Scrum○ Stakeholders chaves
■ Convidados pelo Product Owner➢ Product Owner:
○ Esclarece quais itens do Backlog foram “Prontos” e quais não foram “Prontos”
○ Discute o Backlog do Produto tal como está.○ Ele projeta as prováveis datas de conclusão
Revisão da Sprint➢ Time de Desenvolvimento:
○ Discute o que foi bem durante a Sprint○ Quais problema ocorreram○ Como os problemas foram resolvidos○ Demonstra o trabalho que está “Pronto”○ Responde as questões sobre o incremento.
Revisão da Sprint➢ O que fazer a seguir? (Próxima Sprint)
○ Entradas para a Reunião de Planejamento da próxima Sprint.
➢ Análisar○ Mudanças do mercado e do uso potencial do produto○ Coisa mais importante a se fazer a seguir○ Linha do tempo, orçamento, potenciais capacidades,
e mercado para a próxima versão esperada do produto
Revisão da Sprint➢ Resultado
○ Backlog do Produto revisado■ Define provável Backlog do Produto para a
próxima Sprint.○ Backlog do Produto pode ser ajustado
completamente■ Atender novas oportunidades
Retrospectiva da Sprint➢ Oportunidade para o Time Scrum
○ Inspecionar a sí próprio○ Criar um plano para melhorias
➢ Ocorre depois da Revisão da Sprint➢ Antes da reunião de planejamento da
próxima Sprint➢ Time-boxed de três horas
Retrospectiva da Sprint➢ Scrum Master garante
○ Garante que o evento ocorra ○ Garante que os participantes entendam seu
propósito.○ Ensina todos a mantê-lo dentro do time-box.○ Participa da reunião como um membro auxiliar do
time■ Devido a sua responsabilidade pelo processo
Scrum
Retrospectiva da Sprint➢ Propósito:
○ Inspecionar como a última Sprint foi■ Pessoas■ relacionamentos■ processos■ ferramentas
Retrospectiva da Sprint➢ Propósitos
○ Identificar e ordenar■ Itens que foram bem■ Potenciais melhorias
○ Criar plano para implementar melhorias
Retrospectiva da Sprint➢ Scrum Master
○ Encoraja o Time Scrum a melhorar■ Processo do framework do Scrum■ Processo de desenvolvimento■ Práticas para fazê-lo mais efetivo e agradável.
○ Time Scrum■ Planeja formas de aumentar a qualidade do
produto● Adaptando a definição de “Pronto” quando apropriado
Retrospectiva da Sprint● Ao final
○ Time Scrum deverá ter identificado melhorias■ Serão implementadas na próxima Sprint
● Adaptação à inspeção que o Time faz a sí próprio.
● Evento dedicado e focado na inspeção e adaptação○ Ainda assim, melhorias podem ser adotadas a
qualquer momento
Artefatos do Scrum
Artefatos do Scrum➢ Representam o trabalho ou o valor
○ Fornecimento de transparências○ Oportunidades de inspeção e adaptação
➢ Maximizar a transparência das informações chave○ Mesmo entendimento dos artefatos
Backlog do Produto/Artefatos➢ Lista ordenada
○ Tudo que deve ser necessário no produto➢ Origem única dos requisistos para qualquer
mudança a ser feita no produto.➢ Product Owner é responsável
○ Conteúdo○ Disponibilidade○ Ordenação
Backlog do Produto/Artefatos➢ Nunca está completo➢ Primeiros desenvolvimentos
○ Requisitos inicialmente conhecidos○ Melhor entendidos
➢ Evolui tanto quanto o produto e o ambiente➢ Backlog do Produto é dinâmico
○ Mudanças constantes➢ Existirá enquanto o produto também existir
Backlog do Produto➢ Lista todas as características, funções,
requisitos, melhorias e correções para as futuras versões.
➢ Itens do Backlog possuem atributos○ Descrição○ Ordem○ Estimativa○ Valor
Backlog do Produto➢ Backlog torna-se uma lista maior e mais
completa○ Produto é usado, ganha valor e mercado oferece
retorno➢ Backlog é um artefato vivo
○ Requisitos não param de mudar■ Requisitos de negócio■ Condições de mercado■ Tecnologia
Backlog do Produto➢ Múltiplos Times Scrum frequentemente
trabalham no mesmo produto➢ Utilizado para descrever o trabalho previsto➢ Um atributo do Backlog do Produto que
agrupe itens pode ser aplicado
Refinamento do Backlog do Produto➢ Ação de adicionar
○ Detalhes○ Estimativas○ Ordem
➢ Processo contínuo feito pelo Product Owner e o Time de Desenvolvimento
➢ Itens analisados e revisados
Refinamento do Backlog do Produto➢ Time de Desenvolvimento decide o “Pronto”➢ Consome menos de 10% da capacidade do
Time de Desenvolvimento➢ Podem ser atualizados a qualquer momento
pelo○ Product Owner○ A critério do Product Owner
Itens do Backlog➢ Itens de ordem mais alta
○ Devem ser mais claros e detalhados que os de ordem mais baixa
➢ Itens na próxima Sprint são mais refinados○ Estar “Prontos” dentro do time-boxed da Sprint
➢ Podem ser “Prontos” pelo Time de Desenvolvimento ○ Considerados “Preparados” para seleção no
Planejamento da Sprint
Estimativas do Backlog➢ Feito pelo Time de Desenvolvimento
○ Product Owner deve influenciar o Time■ Ajudando no entendimento■ Tomar decisões conflituosas de troca
➢ As pessoas que irão realizar o trabalho devem fazer a estimativa final
Monitorando o Progresso a Caminho do Objetivo➢ Em qualquer ponto do tempo
○ O total do trabalho restante para alcançar o objetivo pode ser somado
➢ Product Owner acompanha o trabalho restante a cada Reunião de Revisão da Sprint○ Compara com o valor de Revisão da Sprint anterior
■ Avaliar progresso pelo tempo estimado➢ Deve ser transparente para todas as partes
interessadas
Monitorando o Progresso a Caminho do Objetivo➢ Práticas de estimativas
○ Burndown○ Burnup○ Outras
➢ Não substituem a importância do empirismo➢ O futuro é desconhecido
○ Somente o que aconteceu pode ser usado para tomada de decisões futuras
Backlog da Sprint➢ É um conjunto de itens do Backlog do Produto
selecionados para a Sprint➢ Previsão do Time de Desenvolvimento
○ Determina as funcionalidades no próximo incremento○ Trabalho necessário para um incremento “Pronto”
➢ Torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint
Backlog da Sprint➢ É um plano com detalhes suficientes para
que as mudanças sejam entendidas na Reunião Diária
➢ Time de Desenvolvimento modifica○ Surge durante a Sprint
■ Quando o Time de Desenvolvimento trabalha seguindo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint
Backlog da Sprint➢ Acionado pelo Time de Desenvolvimento
○ Novo trabalho necessário➢ Atualizado
○ Conforme o trabalho é realizado ou completo○ Quando desnecessário, é removido
➢ Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint
➢ Backlog da Sprint é altamente visível
Monitorando o Progresso da Sprint➢ Em qualquer ponto do tempo
○ O total do trabalho restante dos itens do Backlog da Sprint pode ser somado
➢ Time de Desenvolvimento monitora o total do trabalho restante a cada Reunião Diária○ Probabilidade de alcançar o objetivo da Sprint
➢ Melhora a gerência do progresso da Sprint
Incremento➢ Soma de todos os itens do Backlog do
produto completos durante a Sprint➢ Valor dos incrementos das Sprints anteriores➢ Ao final da Sprint, um novo incremento deve
estar “Pronto”○ Condição de utilizável, independentemente do
Product Owner decidir liberá-lo ou não
Transparência do Artefato
Transparência do Artefato➢ Scrum invoca transparência➢ Decisões
○ Percepção do estado dos artefatos➢ Quanto mais transparente, mais sólidas
serão as decisões○ Artefatos pouco transparentes podem ser falhas,
valores podem diminuir e riscos podem aumentar.
Transparência do Artefato➢ Colaboração entre Scrum Master, Product
Owner, Time de Desenvolvimento e outras partes envolvidas
➢ Scrum Master deve aplicar técnica adequada➢ Scrum Master deve monitorar para manter
uma máxima transparência
Transparência do Artefato➢ Scrum Master deve lidar com o Time Scrum
e organizar o aumento da transparência dos artefatos
➢ Transparência não ocorre de uma dia para o outro○ Envolve aprendizagem, conhecimento e mudanças
Definição de “Pronto”➢ Todos devem entendem o significado de
“Pronto”➢ Para o Time Scrum é quando o trabalho esta
completo no incremento do produto➢ Cada Sprint deve entregar incrementos de
funcionalidades potencialmente utilizável que atenda a definição de “Pronto”
“Pronto”?➢ Se “Pronto” para um incremento não é uma
convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “Pronto” apropriada para o produto.
“Pronto”?➢ Cada incremento é adicionado aos
incrementos anteriores e testado, para garantir que os incrementos funcionam juntos
➢ Time Scrum maduro o “Pronto” pode ter critérios mais rigorosos de qualidade
Conclusão
Conclusão➢ Papéis, artefatos, eventos e regras Scrum são
imutáveis e embora seja possível implementar somente parte do Scrum, o resultado não é Scrum.
➢ Scrum existe somente na sua totalidade, funcionando como um container para outras técnicas, metodologias e práticas.