Por que

os Projetos Fracassam?

32% Sucesso (no prazo, dentro do orçamento e

com escopo completo) .

44% Mudaram (atrasaram, estourou o

orçamento, e/ou reduziram escopo) .

24% Falharam (cancelados ou nunca usados).

Chaos Report 2009

Agilidade e

Scrum.

Essência, Valores

e Princípios

Ágeis.

Disciplina.

Comunicação.

Cultura.

Melhoria continua.

Adaptação.

Pessoas.

Colaboração.

Compromisso. Aprendizagem continua.

Simplicidade. Transparecia.

Valor.

Motivação.

Ambiente Sustentável.

Excelência.

Qualidade.

Satisfação.

Auto-organização.

Características das Equipes

Ágeis.

Comprometimento. Confiança. Comunicação. Motivação. Responsabilidade. Sem Hierarquia Formal. Auto Organização.

Coragem. Respeito. Feedback. Transparência. Interdisciplinares. Adaptação. Auto Gerenciamento.

? Por que Scrum?

Foco no ROI (retorno do investimento).

Cliente como aliado e no centro da iteração.

As mudanças como oportunidades.

Comprometimento (Time, cliente, organização).

Rápida resposta a mudanças.

Rápido feedback.

Eliminar desperdício.

Qualidade. (Done).

O que é Scrum?

Scrum

• Framework

• Metodologia

• Processo

Para

• Gerenciamento de Projetos

• Desenvolvimento Iterativo e Incremental

• Desenvolvimento Ágil de Software

Focado em

• Times Pequenos.

• Auto-Organizáveis.

• Fortes Visibilidade.

• Rápida Adaptação.

Fluxo do

Scrum.

Transparência

Tudo o que pode impactar no resultado do projeto deve estar:

Visível o tempo todo.

Para qualquer pessoa.

A qualquer momento.

De forma simples e rápida.

Sem qualquer tipo de restrição.

Inspeção

Tudo que pode impactar no resultado do projeto deve:

Ser inspecionado freqüentemente.

Ser de conhecimento de todos os envolvidos.

Ter a participação de forma direta ou indireta de todos os envolvidos.

Detectar variações inaceitáveis rapidamente.

Adaptação

Toda vez que uma variação prejudicial é identificada devemos:

Ajustar imediatamente.

Impedir que os efeitos do defeito prejudique as atividades futuras.

Evitar a famosa “bola de neve”.

Papeis

Eventos

Artefatos

Regras

o

Product Owner

Define as funcionalidades do produto.

Define as datas dos releases.

Responsável pelo retorno do investimento (ROI) do projeto.

Prioriza as funcionalidades de acordo com seu valor de negocio.

Ajusta o Product Backlog a cada Sprint, se necessário.

Dá o aceite final do Sprint

Scrum Master

Responsável pelo processo.

Garante que o time sempre esteja produtivo.

Facilita a cooperação entre todos os membros do time.

Protege o time de interrupções externas.

Remove impedimentos.

Responsável pelo cumprimento das regras do Scrum.

Time

Multidisciplinar.

Define as metas da Sprint e como será feito o trabalho.

Tem o direito de fazer o que estiver ao seu alcance para alcançar as metas da Sprint.

Auto-gerenciado.

Compostos de 5 a 9 membros.

Focados na meta.

Responsável pela solução dos conflitos.

Sprint Planning

Entendimento do Escopo.

Estimativas de complexidade, tempo ou esforço.

Definição da Sprint.

Planejamento dos trabalhos.

Quebra das estórias.

Reunião Diária.

O que foi feito desde a ultima reunião diária?

O que será feito hoje?

O que esta impedindo?

Revisão

da Sprint.

Demonstração das funcionalidades aos interessados.

Avaliação dos resultados.

Aceitação do Product Owner.

Retrospectiva da

Sprint.

Revisão e melhoria do processo.

O que foi bom?

O que não foi bom?

O que pode ser melhorado?

Como pode ser melhorado?

Sugestões.

Product Backlog

É uma lista de todos os requisitos ordenados pelo valor de negócio.

A prioridade de um item no Backlog pode mudar, requisitos podem ser adicionados ou removidos.

No inicio do projeto a lista não precisa estar completa.

A prioridade é atribuída pelo Product Owner.

Sprint Backlog

Lista de tarefas que o time irá trabalhar durante a Sprint.

É composta por itens do Product Backlog que foram priorizados pelo Product Owner.

A equipe deve estimar o número de horas, esforço ou story points para a conclusão de cada tarefa.

Cada membro da equipe tem a liberdade de escolher qual tarefa irá trabalhar e qualquer membro pode adicionar, alterar ou excluir tarefas.

Burndown Chart

É uma visão de como esta indo a execução da Sprint.

Mostra o trabalho que já foi realizado, o que foi e como anda a Sprint em relação ao tempo.

No eixo Y é representado pelo trabalho restante.

No eixo X é representado pelo tempo disponível para a realização do trabalho.

Regras de Planejamento

da Sprint

Aloca-se aproximadamente 5% do tempo da Sprint.

Product Owner deve preparar o Product Backlog antes da reunião.

A equipe é responsável por determinar quanto do P.B irá compor a Sprint Backlog.

A reunião é dividida em uma parte Estratégica e a outra Tática.

Na primeira parte o time cuida da questão “o que?”.

Na segunda parte o time trata da questão “como?”.

Regras da Reunião

Diária

Duração de 15 minutos.

Todos os dias nos mesmos horário e local.

Todos os membros.

A reunião começa no horário marcado.

Não perder o foco.

Somente uma pessoa fala por vez.

Galinhas do lado de fora do chiqueiro.

Regras da

Revisão

da

Sprint.

Tem duração de aproximadamente 4 horas.

A preparação da Review não deve demorar mais que 2 horas.

Review não é momento para testar itens.

É mantida informal.

Participam: S.M, P.O, Time, clientes, diretoria, interessados.

Deve ser apresentado apenas itens prontos.

O P.O deve participar obrigatoriamente.

Regras

da

Retrospectiva.

A regra fundamental é que ela sempre aconteça.

Realizada após a Review.

Duração aproximada de 3 horas.

Todos participam, P.O, S.M, Time.

Ser em uma sala fechada, confortável e sem interrupções.

Geralmente não é feita no local de trabalho.

Não seja ambicioso, e não queira melhorar tudo de uma vez, foque em algumas melhorias por Sprint.

Desvantagens.

A mudança da cultura da empresa.

O grupo deve ser do mesmo nível (e de nível alto), pois são poucas pessoas trabalhando.

O problema de entendimento entre o PO, cliente e o restante da equipe.

Sensação de informalidade.

Falta de planejamento do escopo (Cuidado com isso).

Projeto não documentado.

Scrum não é bala de prata e não é a melhor forma de gestão para todos os projetos.

Por ser parte do Ágil não quer disser que será entregue mais rápido e sim o que tem mais valor para o P.O.

Projetos com Scrum também falham!!!!!

Perguntas?

Obrigado.