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;


➢ 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;


➢ 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;


➢ Remover impedimentos para o progresso do Time de Desenvolvimento;

➢ Facilitar os eventos Scrum conforme exigidos ou necessários; e,


➢ 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;


➢ 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,


➢ 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


➢ 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


➢ Raramente faz sentido○ Devido a curta duração da Sprint


➢ Revisados○ Itens do Backlog do Produto completados○ “Pronto”

➢ Parte utilizável do trabalho, tipicamente é aceita pelo Product Owner


➢ Itens incompletos são reestimados e colocado de volta no Backlog do Produto.

➢ Trabalho feito deve ser frequentemente reestimado.


➢ 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.

Documents

Gerenciamento Ágil de Projetos Com Scrum