scrum - desenvolvendo software e entregando valor

ScrumDesenvolvendo software e entregando valor

sábado, 1 de junho de 2013

• Problemas

• Agile

• Papéis no Scrum

• Processo Scrum

• Atenção

• Resultados

Agenda


Problemascom o método tradicional de desenvolver software


TradicionalDesenvolvimento em fases Antecipação de resultadosLevantamento total dos requisitos


Requisitos pouco clarosMedo de ir para a próxima fase

Paralisia da análise


Mudanças de RequisitosMudanças ficam cada vez mais caras

Clientes não consegues o que querem


Projetos LongosSomente 32% dos projetos são entregues com sucesso*

Projetos longos adiam a receita

* Fonte: Standish Groupsábado, 1 de junho de 2013

TestesNão “sobra” tempo para testes

A garantia da qualidade é negociadaIntegração tardia = Falha no final


Desperdício de TempoSomente 52% de funcionalidades implementadas*64% dessas funcionalidades são raramente usadas*


Visibilidade pobre% de tarefas inúteis realizadas*

Média superada 43%*


AgileSoftware

Development


Projetos Caóticos

Projetos Ágeis

Projetos Estruturados


Manifesto Ágil

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e

ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar :

Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Princípios Ágeis

✓ Satisfação do cliente

✓Mudanças são bem-vindas

✓ Entregar frequentemente

✓ Trabalhar como um time

✓Motivar a equipe

✓Comunicação face a face

✓Medir o trabalho

✓Manter a cadência

✓ Buscar a qualidade

✓Manter a simplicidade

✓ Engajar

✓ Refletir regularmente


Adoção do Agile


Scrum


Os Mentores

Ken Schwaber Jeff Sutherland

Mike Cohn


Objetivo do Scrum

Gerenciar a complexidade, imprevisibilidade e mudanças através da visibilidade, Inspeção e Adaptação


Papéis no Scrum


Product OwnerÉ o dono do projeto, representa o cliente.


Product OwnerDefine as funcionalidades de acordo com a visão.Prioriza as funcionalidades.Organiza as releases.Fornece feedback.Aceita ou rejeita os resultados.sábado, 1 de junho de 2013

TimeDeve ser pequeno, multifuncional e auto-organizado.


TimeDefine as tarefas.Estima o esforço.Desenvolve o produto.Garante a qualidade.Evolui o processo.sábado, 1 de junho de 2013

Scrum MasterLíder servidor, protetor do time e responsável pelo processo.


Scrum MasterRemove impedimentos.Previne interrupções.Facilitador para o Time.Garante o funcionamento do processo.Gerencia o gerenciamento.sábado, 1 de junho de 2013

Porcos e Galinhas


Processo Scrum


Product BacklogExpressa valor e adia decisões


Product Backlog

Criado pelo Product Owner.Requisitos de alto nível.Expressa o valor para o negócio.Incompleto, imperfeito.Espera por mudanças e desenvolvimento.Visão limitada do futuro.sábado, 1 de junho de 2013

Product Backlog

Priorizado pelo valor e risco.Contém User Stories bem escritas.Inclui as estimativas por pontos.Deve ser público e de fácil acesso.


User StoryEu como <usuário>, quero <funcionalidade> para que <benefício>.

Eu como bibliotecário, quero um sistema de busca para que seja possível encontrar livros facilmente.


Sprint

Timeboxed, funcionalidades congeladas, escopo variável, resultado entregável.


Sprint Planning

Capacidade do TimeProduct Backlog

NegócioTecnologiaObjetivo


Comunicação frente-a-frente.Pequenos passos reversíveis.Perspectivas do Usuário.

Sprint Planning


Sprint Planning - Parte 1Planejamento no nível estratégico.Priorizar e selecionar as funcionalidades.Discutir os critérios de aceitação.Alinhar o entendimento.Tempo: 1 hora por semana de Sprint.

Presença obrigatória:

PO, SM, Time.


Sprint Planning - Parte 2Planejamento no nível tático.Define os itens do Sprint Backlog.Estmativa dos itens do Sprint Backlog.Uso da Velocidade.Tempo: 1 hora por semana de Sprint.

Presença obrigatória: SM, Time.


Sprint BacklogQuebrando em tarefas técnicas os itens de negócio.


Sprint Backlog

Criado pelo time.O time organiza e aloca as tarefas.Nada é adicionado por outras pessoas.


Daily Scrum


Daily ScrumComprometimento e responsabilidade.Dizer o que esta fazendo e fazer o que está dizendo.Todo mundo é convidado a participar.Tempo: Até 15 minutos todos os dias.


Daily ScrumO que você fez desde o último daily meeting?O que você fará até o próximo daily meeting?Está com algum impedimento?Somente o Time fala.Não é para resolver problemas.

Tempo: Até 15 minutos todos os dias.


Task Board

Tarefas completas

Sprint Backlog

Tarefas em andamento

Gráfico de Burndown


Definição de ProntoEvite a síndrome dos 90%

Codificado, comentado, checked-in, integrado, revisado, com testes unitários, implantado em ambiente de testes, aceito pelos critérios de

aceitação e documentado.

Pronto!


Sprint Burndown


Sprint Review

Satisfazer o POObter feedback


Informal, sem slides.Todos do Time participam.Qualquer um pode ser convidado.

Sprint Review


Necessário preparação.Todas as funcionalidades devem ser mostradas.Os resultados podem ser aceitos ou rejeitados.Tempo: 2 horas para cada semana de Sprint.

Sprint Review


Sprint Retrospective

Melhorando o Processo


Reflexão sobre o processo e produto.Todos do Time participam.Não é necessário a participação do Product Owner.



O que precisamos começar a fazer?O que precisamos parar de fazer?O que precisamos continuar fazendo?



Release Planning


Planejar funcionalidades em Sprints e Releases.Releases dependem dos Sprints concluídos com sucesso.

Release Planning


Cancelar Sprint


Me dê um motivo lógico para

cancelarmos a Sprint!


Cancelar Sprint

• Somente em casos extremos.

• Time cancela: A meta da Sprint ficou inalcançável.

• Product Owner cancela: A prioridade mudou.

• Dar visibilidade ao problema.


SprintEntrega constante de valor para o

negócio.

Inspeção e Adaptação


SprintOrientado pelo Product Owner

Pequenos passosAs mudanças são bem-vindasOs Times são multifuncionais

Inclui design e testesMantém uma cadência na entregaCompartilha o comprometimento

Busca a alta qualidadeObtém feedback“Falha rápido”


ResultadosEfeitos do Scrum


Gerenciar a incertezaPequenos projetos, riscos menores


Escopo flexívelAceita mudanças em intervalos fixos


Entregas rápidasEntrega de valor em pequenos incrementos


Alta qualidadeTestes acontecem continuamente


Elimina o desperdícioNada é especificado, nada é construído


Aumenta a visibilidadeTodos os problemas são visíveis


Mais divertido, Times Felizes


Pré-Condições

✓ Empoderamento

✓Disciplina

✓Coragem

✓ Energia

✓ Paixão

✓Acompanhamento

✓ Times Estáveis

✓ Time Multifuncional

✓Colaboração

✓Cliente Disponível


Atenção!Scrum não é uma prática de engenharia

Parece simples, mas é dificilNão é bala de prata

É incompletoLeva tempo


[email protected]: @sergiomonteiro

Sérgio Monteiro


mailto:[email protected]

mailto:[email protected]

scrum - desenvolvendo software e entregando valor

Technology