Agilidade: SCRUM e XP

Facilitador

Contexto de projetosValores ágeisPrincípios ágeisScrum

Agenda SCRUM:

Fernando Costaformado em Redes de ComputadoresSócio da 3LJ Tecnologia – www.3lj.com.br

Paradoxo de CobbWe know why projects fail, we know

how to prevent their failure – so why do they still fail?

Martin Cobb

Treasury Board of Canada Secretariat

Nós sabemos porque os projetos falham, sabemos como previnir – Porque eles continuam falhando?

Reflexão do Caranguejo Todos os caranguejos

ficam amarrados a um barbante que fica solto.

Não é preciso amarrar pois todos querem fugir mas cada um que ir para um lado diferente.

Ficam no mesmo lugar

Valores do Manifesto ÁgilProcessos e ferramentasIndivíduos e interações

ao invés de

Seguir um planoResposta à mudanças

www.agilemanifesto.org - 2001

Documentação abrangenteSoftware que funciona

Negociação de contratoColaboração do cliente

Princípios do Manifesto Ágil1 - O principal compromisso é com a satisfação

do cliente, por meio da entrega mais rápida e contínua de produto com valor

2 - Receba bem as mudanças de requisitos(mesmo em estágios tardios do projeto). Processos ágeis devem admitir mudanças que trazem vantagens competitivas ao cliente

3 - Libere produto frequentemente (de 2 a 4 semanas), dando preferência para uma escala de tempo curta

Princípios do Manifesto Ágil4 - Mantenha pessoas ligadas ao negócio (cliente) e

desenvolvedores trabalhandos juntos a maior parte do tempo do projeto

5 - Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado

6 - O método mais eficiente e efetivo para repassar a informação entre a equipe é pela comunicação face a face

Princípios do Manifesto Ágil7 - Produto funcionando é a principal medida

de progresso de um projeto

8 - Processos ágeis promovem o desenvolvimento sustentado. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente

9 - Atenção contínua para excelência técnica e bom projeto (planejamento) aprimoram a agilidade

Princípios do Manifesto Ágil10 - Simplicidade é essencial e deve ser

assumida em todos os aspectos do projeto

11 - As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas

12 - Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento

SCRUM

Em resumo...

Imagem disponível em: www.mountangoatsoftware.com/scrum

Cliente (ou Product Owner) Quem é o nosso cliente? Funcionalidades do

produto Decide as datas e

conteúdo Rentabilidade (ROI) Ajusta e prioriza

funcionalidades e prioridades

Aceita o rejeita resultados

Scrum Master Remove obstáculos Não tem autoridade Produtividade da equipe Conduz eventos Escudo da equipe

Equipe 5 a 9 pessoas Multi-funcional Auto-organizável Sugere funcionalidades

do produto

Product Backlog Lista de funcionalidades desejadas no projeto Os itens que compõe a lista são chamados de

histórias ou itens de backlog Todos podem incluir histórias Somente o Product Owner pode priorizá-las Product Owner pode priorizar novamente no

início de cada Sprint

Nosso Product BacklogID Nome Importância Estimativa Observação

1 Catálogo de produtos

2 Cesta de compras

3 Cadastro do cliente

4 Boleto bancário

5 Cartão de crédito

Planning Poker Vamos estimar os itens de Backlog?

Nosso Product BacklogID Nome Importância Estimativa Observação

1 Catálogo de produtos

3

2 Cesta de compras

5

3 Cadastro do cliente

2

4 Boleto bancário 4

5 Cartão de crédito

3

Qual a importância dos itens de backlog para o Product Owner?

Must(tem que

ter)

Should(deveria ter)

Could(poderia ter)

Want(interessante)

Catálogo de produtos

Boleto bancário

Videos dos produtos

Cadastro de clientes

Controle de estoque

Cesta de compras

Registro do Pedido e entrega

Cartão de crédito

Fotos dos produtos

Regras de promoção

Nosso Product BacklogID Nome Importância Estimativa Observação

1 Catálogo de produtos

1 3

2 Cesta de compras

1 5

3 Cadastro do cliente

1 2

4 Boleto bancário 2 4 BB e CEF

5 Cartão de crédito

3 3 Visa e Mastercard

Sprint

Deve ter um objetivo Período de 2 a 4 semanas Nenhuma mudança no sprint Processo baseado em uma série de iterações Produto é desenvolvido no sprint

Product Burnup Chart

Planejamento do Sprint Cliente, ScrumMaster e Equipe Cliente seleciona itens do Product backlog O Sprint backlog

− Tarefas identificadas e estimadas (1 a 16 horas)

− De forma colaborativa (por todos)− Equipe compromete-se a concluir as tarefas

ID - 1Catálogo de produtos

ID – 1.1Administrador dos

Produtos10 horas

Planejamento do Sprint

ID – 1.2 Busca fonética de

produtos2 horas

ID – 1.3Front-end da Loja

15 horas

Scrum diário Tempo de 15 minutos Todos em pé Não é para a solução de problemas

− Todos são convidados− Apenas a Equipe, ScrumMaster e Product Owner

podem falar Sincronização do conhecimento Atualização do burnup chart1. O que fiz desde a última reunião?2. O que farei até a próxima reunião?3. Existe algum obstáculo?

Gerenciando o Sprint backlog Cada membro da equipe escolhe a tarefa

que fará− Trabalhos nunca são atribuídos

Atualização diária da estimativa do trabalho restante

Equipe pode adicionar, apagar ou mudar tarefas (não itens de backlog)

Scrum board

Revisão do Sprint Informal Todos participam Hora do feedback Resultados do Sprint

Comunicação eficaz:(bala / bombom)

Retrospectiva do Sprint Feita após cada Sprint Periodicamente observe pontos

positivos e negativos Tipicamente de 15 a 30 minutos Todos participam

Inicia, Pára, Continua A equipe discute o que gostaria de:

Iniciar a fazerIniciar a fazer

Parar de fazerParar de fazer

Continuar fazendoContinuar fazendoEsta é uma das várias maneiras de se conduzir

uma retrospectiva do

Sprint

Agora vocês explicam!!!

Resumo: Gerenciamento ágilTópico CaracterísticasObjetivo principal Orientado ao produto e centrado nas pessoasTipo do projeto Projetos com mudanças constantes e que necessitam de respostas

rápidasTamanho Mais efetivo em projeto pequenos(5 a 9 pessoas)Gerente do projeto Papel de facilitador ou coordenadorEquipe do projeto Atuação colaborativa em todas as atividades do projetoCliente Essencial. Deve ser parte integrante da equipe do projetoPlanejamento Curto e com a participação de todos os envolvidos na elaboração

do planejamentoArquitetura Aplicação de design simples. Evolui junto com o projeto e

baseia-se na refatoraçãoModelo de desenvolvimento

Iterativo e Incremental

Comunicação Informal

Tópico Características

Dúvidas?Fernando Costa

fernando@3lj.com.brwww.fernandocosta.com.br

www.3lj.com.br www.innovit.com.br

Patrocínio: Agradecimento:

Desenvolvimento tradicional

Valores

Princípios

Práticas

Agenda do XP

Fazer software é dureza

Boa notícia

Cases de sucesso:Google

Microsoft

Philips

FAB (BR)

Oi Paggo

Má notícia• Seus colegas não vão

acreditar

• O seu chefe não vai aceitar

• O chefe do seu chefe não pode nem pensar

Não é assim que se faz software

Principais falhas:

a) Não entregam o acordado

b) Orçamento

c) Prazo

d) Todas alternativas

Utilização de funcionalidades

Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group

64% de desperdício

Podem gerar algumas horas extras para a equipe

Cliente paga por lixo

Utilização de funcionalidades

Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group

20% muito útil Geram pelo menos 80% do valor do

produto

20%? desconhecido no início do projeto

“XP é a arte de maximizar a quantidade de software que

você não vai fazer “Vinícius Manhães Teles

Análise

Pai(cliente): 1 dia de projetoMãe(desenv.): 9 meses de projeto

Análise

Cliente: “Não era nada disso que eu queria...”

Mentalidade

Cascata

Custo da Mudança por Barry Bohem

Problemas e mudanças

Patente do VELCRO:

em 1941 por Georges de Mestral

Meio digital Fluidez Maleabilidade Invisibilidade Complexibilidade (elementos distintos) Baixo custo de manufatura Rapidez evolução

Nova mentalidade• Chef• Escritor

eXtreme Programming

RespeitoRespeito

Valores do XP

Comunicação

Comunicação

Simplicidade

Simplicidade

Feedback

Feedback

Coragem

Coragem

Uma pergunta

“Como você programaria se tivesse tempo suficiente?”

Kent Beck

Possíveis respostas Mais testes?

Mais projeto e arquitetura?

Menos pessoas?

Mais qualidade?

Programando ao Extremo− Testar toda hora!!

− Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa!

− Integrar a maior quantidade de vezes possível!

− Iterações realmente curtas!

Práticas

Integração Contínua Ritmo

Sustentável

Metáfora

Código Coletivo Coding

Standard

Design Simples

RefactoringProgramação

em pares

Test-Driven Development

Testes de Aceitação

Releases Curtas

Planning Game

Cliente Presente

Adaptado de xprogramming.com

Jogo do Planejamento

Reunião semanal onde todos participam

Escopo reavaliado

Cliente prioriza e seleciona as histórias que serão desenvolvidas

Ao fim da semana o cliente recebe produto funcionando

Reunião em pé 10/15 minutos Todos em pé Não é para a solução de problemas

− Todo mundo é convidado− Apenas a Equipe pode falar

Sincronização do conhecimento1. O que fiz desde a última reunião?2. O que farei até a próxima reunião?3. Existe algum obstáculo?

Cliente presente e envolvido• Responsabilidade do

projeto:– Equipe– Cliente

• Comprometimento

Ritmo sustentável

Semana de 40 horas (8hr/dia)

Sem hora extra: Baixa produtividade Código de má qualidade Aumento de BUGs

Programação em par

Forneça suporte e ferramentas

Experimente, você vai se surpreender

Alterne os pares para não ficar cansativo e nivelar o time

Respeite a individualidade das pessoas

Código Padronizado

Código Coletivo Inibe ilhas de

conhecimento

Padrão de codificação

Membro da equipe pode ter férias

Direito de ficar doente

Integração Contínua

Divergências aparecem antes de virar um problema

“Isso funcionava na minha máquina”

Projeto Simples

Faça o essencial

Tudo pode mudar

Refatoração “Time que está ganhando não se mexe” –

FALSO Ex.: Empresas estáveis quebram se não

mudarem Melhoria contínua

Desenvolvimento Orientado

a Testes (TDD)

Início é um pouco demorado

Primeiro o teste, depois a funcionalidade para passar no teste

Testes automatizados: Unitários, Interface e Aceitação

RETORNO: Salvação no FIM do projeto

Releases curtos

Papéis

Tracker

Programador

Goal Donnor

Gold OwnerAnalista de Testes

Coach

Manager

Equipe nivelada

Dúvidas?

Fernando Costafernando@3lj.com.brwww.fernandocosta.com.br

3LJ Tecnologiawww.3lj.com.br

Agradecimento:Vinícius Manhães TelesImprove It