Agilidade com Scrum e eXtreme Programming

Luiz Fernando Ramos Costa

Coordenadoria de Serviços e Sistemas de Rede

DTIC – IF-SC – (48) 3877-9051

luiz.costa@ifsc.edu.br

www.fernandocosta.com.br

www.twitter.com/fernandocosta

Facilitador

Scrum

eXtreme Programming

Agenda

Fernando CostaFormado em Redes de ComputadoresPós-graduando em Eng. de SoftwareCertificado LPIC-1, NCLA, DCTSOrientador do SENAC TI

Analista de TI na Reitoria do IFSC

Paradoxo de Cobb

We 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 Ágil

Processos e ferramentas

Indivíduos e interações

ao invés

de

Seguir um planoResposta à mudanças

www.agilemanifesto.org

Documentação abrangente

Software que funciona

Negociação de contrato

Colaboração do cliente

Princípios do Manifesto Ágil

1 - 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 Ágil

4 - 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 Ágil

7 - 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 Ágil

10 - 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

Ken Schwaber

@kschwaber

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 (ou team)

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 Carrinho de compras

3 Cadastro do cliente

4 Boleto bancário

5 Cartão de crédito

Planning Poker

Vamos estimar os itens de Backlog?

Quem?

Product Owner

Scrum Master

Equipe

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

1 Catálogo de produtos

3

2 Carrinho de compras

5

3 Cadastro do cliente

2

4 Boleto bancário

4 BB e CEF (sem usar

pagseguro)

5 Cartão de crédito

3 Visa e MasterCard

Importância

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

Vídeo dos produtos

Cadastro de clientes

Controle de estoque

Cartão de crédito

Fotos dos produtos

Registro do pedido e entrega

Carrinho de compras

Regras de promoções

Must

(tem que ter)

Should

(deveria ter)

Could

(poderia ter)

Want

(interessante)

Catálogo de produtos

Boleto bancário

Vídeo dos produtos

Cadastro de clientes

Controle de estoque

Cartão de crédito

Fotos dos produtos

Registro do pedido e entrega

Carrinho de compras

Regras de promoções

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

1 Catálogo de produtos

1 3

2 Carrinho de compras

1 5

3 Cadastro do cliente

1 2

4 Boleto bancário

2 4 BB e CEF (sem usar

pagseguro)

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 da 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

Planejamento da Sprint

ID – 1

Catálogo de produtos

ID – 1.1

Administrador de produtos

1 hr

ID – 1.3

Front-end da loja

3 hr

ID – 1.2

Busca fonética

1 hr

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 da Sprint

Informal Todos participam Hora do feedback Resultados do Sprint

Comunicação eficaz:(bala / bombom)

Retrospectiva da 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! :)

eXtreme Programming

Kent Beck@kentbeck

Você está fazendo assim?

Comunicação

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

Falhas:

a) Não entregam o acordado

b) Estouram o orçamento

c) Estouram o 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 “

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

porBarry

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

Valores do XP

RespeitoRespeito

Comunicação

Comunicação

Feedback

Feedback

Coragem

Coragem

Simplicidade

Simplicidade

Valores do XP

Simplicidade

Faça sempre da maneira mais simples e que vá funcionar

Comunicação

Dentro do time, entre o cliente e a equipe...

Feedback

Testes de aceitação, presença do cliente

Coragem

Para fazer refactoring, para jogar fora o código e refazer tudo no dia seguinte

Respeito

Trabalho em equipe

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 do XP

Testes de Aceitação

Releases Curtas

Planning Game

Cliente Presente

Integração Contínua

Passo Sustentável

Metáfora

Posse Coletiva Coding

Standard

Design Simples

RefactoringProgramação

em pares

Test-Driven Development

Adaptado de xprogramming.com

Cliente presente e envolvido

• Responsabilidade do projeto:– Equipe– Cliente

• Comprometimento

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 conhecimento

1. O que fiz desde a última reunião?

2. O que farei até a próxima reunião?

3. Existe algum obstáculo?

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

Desenv. Orientado por 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

Equipe nivelada

Papéis

Tracker

Programador

Goal Donnor

Gold Owner

Coach

Manager

Analista de Testes

Dúvidas?

Luiz Fernando Ramos Costa

Coordenadoria de Serviços e Sistemas de Rede

DTIC – IF-SC – (48) 3877-9051

luiz.costa@ifsc.edu.br

www.fernandocosta.com.br

www.twitter.com/fernandocosta

Agradecimento:

Vinícius Manhães Teles

Improve It www.innovit.com.br