Métodos Ágeis

Jerry Medeiros

Introdução às Metodologias Ágeis De Desenvolvimento

Minha avó me convidou para

visitá-la e almoçar o salpicão que eu

adoro nesse sábado às 13h

• Ela irá acordar às 8h; • Banho até as 8h30min; • Café da manhã até as 9h; • Consulta médica às 10h; • Supermercado às 11h; • Voltará para a casa às 12h;• Almoço pronto às 13h.

O que ela deve fazer?

•O ônibus atrasar?•O médico atrasar?• Não tiver os ingredientes no

supermercado ?

E se...

MAS

E se...

Meu netinho, você se importa de eu fazer uma sopinha de legumes em vez do salpicão ?

E se...

Meu netinho, você se importa de eu fazer uma sopinha de legumes em vez do salpicão ?

Objetivos Principais

Reencontrar minha vovó

Matar a fome

Escopo Variável

•Sempre há um escopo

•Teoricamente não será alterado durante o projeto, porque existe um contrato

•Existe uma ilusão de previsibilidade

O cliente acredita que:

•O escopo é previsível;•O prazo é previsível;•O custo é previsível;

A equipe acredita que sabe:

•O que tem que fazer;•Em quanto tempo fará;•Quanto vai ganhar;•Quais recursos vai precisar.

Então não há problema !!

Tranquilo ?

Só que.....

“O Cliente sabe o que quer desde o início do projeto.

Só que.....

“A equipe consegue estimar o tempo exato necessário para a produção.

O escopo não é fixo

•Variáveis do Projeto

•Prazo•Escopo•Custo•Qualidade

Priorização do Escopo

Princípio de Pareto se aplica:

20% das funcionalidades geram 80% do valor

Funcionalidades nunca ou raramente utilizadas

64%

64% de desperdício de tempo e dinheiro

Resultado

• Projetos que falha;• A maioria das funcionalidades nunca será usada pelo usuário;• Nos projetos com sucesso, apenas 42% dasfuncionalidades previstas no início estavam no produto final;

Como é feito

Como é feito

Como é feito

O Cliente precisa de Resultado

Sempre entregar valor

Entender as Necessidades

Mudança de Paradigma

Como Mudar essa situação ?

Manifesto Ágil

Em 2001, dezessete especialistas em processos de desenvolvimento de software estabeleceram princípios comuns compartilhados por diferentes métodos e criaram o Manifesto Ágil.

Como Mudar essa situação ?

Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software fazendo‐o nós mesmos e ajudando outros a fazê‐lo. Através desse trabalho, passamos a valorizar:

Valores

Indivíduos e Interações

Ferramentas e Processos

Valores

Software Funcionando

Documentação Abrangente

Valores

Colaboração com Cliente

Negociação de contratos

Valores

Responder a mudanças

Seguir um plano

Princípios

“Nossa maior prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor

Princípios

“Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças para que o cliente possa tirar vantagens competitivas

Princípios

“Entregar software funcionando com frequência, na escala de semanas ou meses, com preferência aos períodos mais curtos

Princípios

“Pessoas relacionadas a negócio e desenvolvimento devem trabalhar em conjunto e diariamente, durante todo o curso do projeto

Princípios

“Construir projetos ao redor de indivíduos motivados dando a eles o ambiente necessário, e confiar que farão seu trabalho

Princípios

“O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara

Princípios

“Contínua atenção à excelência técnica e bom design aumenta a agilidade

Princípios

“Simplicidade: A arte de maximizar a quantidade de trabalho que não precisou ser feito - KISS

Princípios

“Software funcional é a medida primária de progresso

Princípios

“Em intervalos regulares, o time reflete como ficar mais efetivo, então, ajustam e otimizam seu comportamento

Princípios

“As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis

Envolvimento e Comprometimento

Características de Um Time Ágil

Comprometimento

Coragem

Confiança

Respeito

Comunicação

Feedback

Motivação

Transparência

Responsabilidade

Interdisciplinaridade

Sem hierarquia formal

Adaptabilidade

Auto-organização

Auto-gerência

É um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita frequência.

Scrum

“

Em Rugby, Scrum é um time de oito integrantes que trabalham em conjunto para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e o time inteiro focando num único objetivo.

Scrum

Backlog• Lista de todas as funcionalidades desejadas

• É gerada incrementalmente– Começa pelo básico, o extra aparece com o tempo

• Pode conter– Tarefas diretas, casos de uso e histórias

• A lista é priorizada pelo dono do projeto– Cliente, depto de marketing, ...

O Backlog Inicial• Deve conter características que agreguem algum

valor de negócio ao produto

• Novos requisitos aparecem quando o cliente vê o produto

• A arquitetura do sistema surge enquanto o projeto surge e é refatorado

Equipes• Sem nível hierárquico nem papéis

– Mas com várias especialidades

• Estão todos no mesmo barco

• Geralmente equipes pequenas (até 10)– Existem casos com equipes maiores (800 !)– Usa-se também Scrum hierárquico

• Comunicação é essencial– Encontro Scrum diário

Sprint• Unidades básicas de tempo (até 30 dias)

• Começa com um encontro Sprint– Tarefas do Backlog são priorizadas– A equipe seleciona tarefas que podem ser completadas

durante o próximo Sprint– As mesmas podem ser quebradas para o Backlog do

Sprint– Cada tarefa recebe um responsável na equipe– Não há mudança nas tarefas durante o Sprint

Daily Scrum• Pequenos encontros diários da equipe

– geralmente pela manhã– galinhas e porcos (só os porcos falam)– todos os porcos devem participar

• Questões que aparecem devem ser resolvidas durante o dia e não na reunião

• Os encontros iniciais são geralmente mais longos

Daily Scrum• Questões que devem ser respondidas por cada porco:

– 1) O quê você fez ontem?– 2) O quê você vai fazer hoje?– 3) Quais os problemas encontrados?

• Ajuda a manter as promessas

• Evita: Como um projeto atrasa um ano?– Um dia por vez ...– Qualquer deslize pode ser corrigido de imediato

Local do Encontro• Sempre o mesmo

local e hora• Pode ser o local de

desenvolvimento• Pessoas sentadas ao

redor de uma mesa• A sala já deve estar

arrumada antes• Punições

(atrasos/faltas)

• Todos devem participar

• Galinhas ficam na periferia

• Pode ser em pé• Sala bem equipada,

quadro branco, etc.

Revisão do Sprint• No final de cada Sprint é feita uma reunião com

todos os interessados

• Geralmente– Na forma de demonstração– Informal (preparação rápida, sem projetor,..)– Deve ser o resultado natural de um Sprint

• O projeto é comparado com os objetivos iniciais do Sprint

Scrum Master • Faz com que a equipe viva os valores e práticas de

Scrum

• Protege a equipe de:– Riscos e interferências externos– Excesso de otimismo

• Resolve os problemas que aparecerem– logísticos– de conhecimento/habilidade

Scrum Master• Mantém o Backlog do Sprint

– Tarefas completadas– Identifica eventuais problemas

• Mantém um gráfico de “quanto falta”

0

10

20

30

40

50

60

70

80

90

100

horas

Exemplo real

Scrum de Forma Gráfica

Dúvidas?