Curso de Metodologias Ágeis

Da teoria à prática
 Sumário
• Introdução ao que é são as
metodologias ágeis;

• Conceitos importantes;

• O manifesto ágil e seus

princípios;

• Overview das principais

metodologias;

• Entrevistas e estudos de caso.

 Introdução

Veremos neste curso: o

conceito de metodologia ágil,
bem como suas principais
vertentes no mercado, para
que no final deste curso, você
saiba identificar a melhor forma
de realizar a gestão dos seus
projetos de criação de
produtos e gestão de
atividades.
 Introdução
▪ Existem várias metodologias ágeis no
mercado, neste curso você vai aprender
as mais utilizadas, suas diferenças e
como aplicar cada uma delas.

▪ Cada método ágil existente hoje carrega

consigo os valores e princípios
arraigados no manifesto ágil; métodos
como SCRUM, KANBAN e XP os trazem,
por isso são denominados ágeis.

▪ Primeiramente nós vamos entender o

que é Metodologia Ágil.
 Introdução

▪ As organizações, cada vez mais, buscam as

Metodologias Ágeis, sendo esta motivada pela
transformação digital.

▪ São práticas de gestão que focam a entrega de valor

ao cliente de forma otimizada, transparente e
colaborativa.

▪ Excelente solução para eliminar gaps nas entregas de

produtos complexos e potencializar as entregas,
Sprint 1 Sprint 2 Sprint 3 trazendo maior satisfação ao cliente.

▪ Ser ágil não significa entregar o projeto todo mais

rápido, mas entregar valor mais rápido ao cliente, em
função de as entregas serem parciais e incrementais,
isto é, as entregas são somadas e prontas para uso
até a entrega do produto todo.
Conceitos
 Conceitos

O que é um produto? Por que o Produto complexo?

desenvolvimento de um
produto importa para a
metodologia ágil?
O que é um produto?

Aquilo que é produzido para venda no mercado

No decorrer da história o desenvolvimento de

produtos passou por várias mudanças. Veio da
produção em massa, até chegar na
personalização em massa.
 O que é um produto?

Evolução das Indústrias Globais:

Emocionante e Assustadora
▪ Este aspecto tornou o desenvolvimento
de produtos complexo, pois o 1ª Revolução Industrial (~1784)
consumidor está cada vez mais
exigente, buscando personalização
para a sua necessidade própria.
2ª Revolução Industrial (~1870)
▪ Isso fez com que os produtos fossem
se tornando mais evoluídos e
impulsionou o avanço da tecnologia.
3ª Revolução Industrial (~1969)
▪ Estamos passando pela 4ª revolução
industrial, que está transformando as
indústrias e os produtos.
4ª Revolução Industrial (~????)
 A VIDA VAI MUDAR
COM O USO DE NOVAS TECNOLOGIAS

Nanotecnologia Impressão 3D Inteligência Artificial

AUMENTO EMPREENDEDORES
NOS NÍVEIS DE PODERÃO TER
RENDA NOVAS IDEIAS

Direção autônoma Internet das Coisas Robótica

Desafios da quarta revolução industrial

 Exemplo de um produto que se tornou complexo

Desafios da Revolução Industrial para a

produção de novos produtos com novas complexidades
 Atualmente a produção de smartphones se tornou natural para
as indústrias de aparelhos celulares. Mas um aparelho dobrável,
como ainda está em desenvolvimento, se tornou um exemplo
de um produto complexo

Desafios da Revolução Industrial para a

produção de novos produtos com novas complexidades
 Então o que é um produto complexo?

Trata-se de um produto sobre o qual as empresas ainda não

têm todas as respostas para criá-lo.

Desafios da Revolução Industrial para a

produção de novos produtos com novas complexidades
Então, qual a relação deste conceito com a metodologia ágil?

Desafios da Revolução Industrial para a

produção de novos produtos com novas complexidades
 A metodologia ágil e os produtos complexos

Podemos resolver:

O Ágil trata de resolver a Problemas complexos e adaptativos

De maneira produtiva e criativa

entrega de produtos complexos Entregar produtos com o mais alto valor ao negócio

maior

Pequeno número de Grande número de

variáveis e elevada variáveis e elevada
incerteza quanto ao incerteza quanto ao
resultado final resultado final

INCERTEZA
Matriz de
complexidade
de projetos
Pequeno número de Grande número de
variáveis e pouca variáveis e pouca
incerteza quanto ao incerteza quanto ao
resultado final resultado final

menor maior
COMPLEXIDADE
 Produtos complexos

Um produto complexo é aquele que está com o mais alto

nível de incerteza e complexidade, isto é, não sabemos ainda
como desenvolver, porque não temos as respostas.

Por exemplo: uma ponte não é um produto complexo, pois

IMPORTANTE: complexidade
é diferente de dificuldade
qualquer empresa de engenharia atualmente sabe como
construir uma ponte. Para gerir as atividades não temos
incertezas e complexidade para o desenvolvimento do
produtos, os métodos tradicionais como o do PMBook (PMI)
não são os mais adequados.
Se a empresa quiser colocar um tipo de câmera, para
reconhecimento das placas dos carros que irão trafegar na
ponte, mas não tem o conhecimento para este produto, este
passa a ser um produto complexo, pois não se tem as
respostas para o seu desenvolvimento. Assim o método mais
adequado para gerar o desenvolvimento da câmera é o ágil,
por sua forma incremental de desenvolvimento, para
adaptação das entregas.
 Exemplos de produtos complexos

O Ágil foi inicialmente desenvolvido para gerenciar e desenvolver produtos.

#desenvolver:

#software #hardware #veículos autônomos #escolas

#governo #marketing #gerenciar a operação #produtos

da organização
Scrum - História

• Metodologias ágeis: desde a década de 90.

• Metodologia tradicional é falha (principalmente quando
aplicada a projetos complexos), lenta e imprevisível e que
não resulta em produtos que as pessoas querem ou estão
dispostas a pagar.
• As metodologias ágeis representam uma nova forma de
realizar as coisas baseada em sistemas evolucionários,
adaptativos e autocorretivos.
• Apresenta alta capacidade de lidar com questões
complexas e está sendo amplamente utilizado em produtos,
serviços e gerenciamento de empresa.
 Método Tradicional X Método Scrum

Características Tradicional Scrum

1. Estrutura Cascata Iterativo e Incremental

Planejamento abrangente no
Detalhado nas fases iniciais do
2. Planejamento início e planejamentos curtos a
projeto
cada iteração

Relatórios, documentação
3. Controle do Projeto excessiva, diagramas Gantt, Inspeção e adaptação
cronogramas, auditorias

4. Mudança Negativa e onerosa Esperada e positiva

5. Gerente do projeto Controle total do projeto Papel de facilitador

Complexos, com mudanças

Estáveis e com baixa
6. Tipo de projeto constantes e que necessitam
complexidade
de resposta rápida
 Estudo de Caso FBI – Projeto Sentinel

Primeira Parte: Projeto Virtual Case File

Resultados
▪ Investimento de US$ 170 milhões;
▪ Em 2005 nenhuma funcionalidade
havia sido entregue.
Contexto

▪ Falhas no sistema de informação do FBI;

▪ Relatórios preenchidos em papel não

▪
permitiam o cruzamento de informações;
Objetivo do projeto: modernizar e
Solução
automatizar o sistema de armazenamentos
de arquivos do FBI; ▪ Cancelamento do projeto.
▪ Método de gerenciamento: cascata
(waterfall);
▪ Início em 2001.
 Estudo de Caso FBI – Projeto Sentinel

Segunda Parte: Projeto Sentinela

(Cascata) Resultados
▪ Em 2010 apenas metade do
planejamento havia sido cumprido;
▪ Porém já haviam sido gastos US$ 401
milhões.
Contexto
▪ Foi contratada uma consultoria para realizar o
projeto;
▪ Novamente a metodologia tradicional em
cascata foi utilizada; Solução
▪ Início em 2005. ▪ Cancelar o contrato com a
consultoria;
▪ Internalizar o desenvolvimento.
 Estudo de Caso FBI – Projeto Sentinel

Terceira Parte: Projeto Sentinela (Scrum)

Resultados

Contexto
▪ Ao todo foram realizados 40 sprints em
▪ Os responsáveis pelo projeto afirmaram que 20 meses;
apenas uma nova abordagem permitiria a
entrega do projeto; ▪ Saving de 90%;
▪ Assim adotaram o Scrum; ▪ Projeto foi entregue em 07/2012.
▪ Sprints quinzenais;
▪ Previsão de 23 sprints e encerramento do
projeto no final de 2011;
▪ Início em 2010.
Manifesto
ágil
 Manifesto ágil

Gestão de Projetos de Manifesto

2001 Software Ágil

“Uma nova abordagem” Grupo de 17 pessoas

AGILE

Scrum XP
FDD ASD
Kanban Lean
DSDM Crystal
 Manifesto ágil e seus pilares

Indivíduos e Interações Software em Colaboração com os Responder a

mais que processos e funcionamento clientes mais que mudanças mais
ferramentas mais que negociação de que seguir um
documentações contratos plano
abrangentes
 Os doze princípios do manifesto ágil

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

1 de software com valor agregado.

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis

2 se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses,

3 com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto

4 durante todo o projeto.

Construir projetos em torno de indivíduos motivados, dando-lhes o ambiente e o

5 suporte necessário, e confiando neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe
6 de desenvolvimento é através de conversa face a face.
 Os doze princípios do manifesto ágil

Software funcionando é a medida primária de progresso.

7
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
8 indefinidamente.

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

9
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
10 realizado é essencial.
11 As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então
refina e ajusta seu comportamento de acordo.
 Os princípios do Manifesto Ágil

1. Nossa prioridade é satisfazer o cliente com entrega

contínua e adiantada (de software) com valor
agregado
O que é na prática:

• As equipes de produto usam produtos mínimos viáveis e experimentação rápida para

testar hipóteses e validar ideias.

• Versões frequentes ajudam a alimentar um ciclo de feedback contínuo entre cliente

e produto.

• Enviado e pronto não são a mesma coisa. Em vez de liberar um produto “acabado”, as
iterações continuam a fazer melhorias incrementais no produto com base no
feedback do cliente e do mercado
 Os princípios do Manifesto Ágil

2. Aceitar mudanças mesmo no final do desenvolvimento.

Processos ágeis se adaptam para que os clientes possam ter
vantagens competitivas
O que é na prática:

• A equipe de projeto deve se esforçar para atingir metas estratégicas e bastante

dirigido às vontades e flutuações do mercado.

• O produto deve estar atento às mudanças do mercado. Quando algo muda, o seu
desenvolvimento deve ser flexível.

• Os desenvolvedores tem que ter um esquema de trabalho flexível. Eles também

devem entender o porquê das mudanças e se esforçar para atende-las.
 Os princípios do Manifesto Ágil

3. Entregar constantemente softwares funcionais, no prazo de

semanas ou meses, com preferência ao que for mais rápido.

O que é na prática:

• Os ciclos de desenvolvimento ágil, geralmente chamados de “sprints” ou “iterações”,

dividem as iniciativas de produtos em partes de 2 a 4 semanas.

• Outra alternativa popular aos sprints ágeis é a implantação contínua. Perde-se o

prazo final, mas sabe-se o que fazer. E o faz.
 Os princípios do Manifesto Ágil

4. Pessoas com visão do negócio e desenvolvedores devem

trabalhar lado a lado com interações diárias.

O que é na prática:

• As equipes multifuncionais de desenvolvimento de produtos ágeis incluem pessoas

envolvidas na utilização do que se desenvolve. Isso balanceia os contrapontos
técnicos e funcionais do produto.

• Reuniões diárias de atualização, ou stand-ups, são uma técnica que muitas

metodologias ágeis usam para colocar esse princípio em prática e manter todos
conectados.
 Os princípios do Manifesto Ágil

5. Execute o trabalho com indivíduos motivados. Forneça o

ambiente e o suporte necessário e confie nas pessoas para
entregar o trabalho.
O que é na prática:

• É necessário ter respeito pela equipe de desenvolvimento: não devemos falar “como”
eles devem trabalhar.

• A visão de propósito motiva a equipe de desenvolvimento.

• O contato rápido e diário com a gestão funcional elimina rapidamente barreiras e faz
com que as entregas sejam mais garantidas.
 Os princípios do Manifesto Ágil

6. A conversa “cara a cara” é a maneira mais eficaz e eficiente

de se transmitir informação dentro e para uma equipe.

O que é na prática:

• Reuniões de stand-up diárias

• Sessões colaborativas de preparação de pedidos em atraso

• Reuniões de planejamento da Sprint

• Demonstrações frequentes e presenciais

• Programação em pares
 Os princípios do Manifesto Ágil

7. Entregas (softwares) funcionando são a medida primária do

progresso

O que é na prática:

• Projetar e liberar “Recursos Mínimos Viáveis” para agilizar e ganhar feedback.

• Uma mentalidade de falha rápida significa avançar mesmo em tempos de incerteza.

• Envie o software com frequência: um produto útil agora é melhor do que um produto
perfeito mais tarde.
 Os princípios do Manifesto Ágil

8. Um processo ágil promove o desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de
manter um ritmo constante indefinidamente.

O que é na prática:

• Antes de cada sprint, é feita uma consideração cuidadosa da quantidade de trabalho que pode
ser comprometida. As equipes de desenvolvimento não prometem o que podem e o que não
podem entregar.

• Todos concordam com o que será feito durante um sprint. Uma vez iniciado o sprint, nenhuma
tarefa adicional deve ser adicionada, exceto em casos raros.

• Os gerentes de produto devem atuar como porteiros para reduzir o ruído de outras partes
interessadas.

• O pessoal do produto deve fornecer um feedback sem terrorismo psicológico.

 Os princípios do Manifesto Ágil

9. Contínua atenção à excelência técnica e ao design aumenta

a agilidade.

O que é na prática:

• A equipe deve estar ciente do que significa, tecnicamente, adicionar uma

funcionalidade. Desenvolvedores e pessoal de produtos precisam trabalhar juntos
para entender se e quando a “dívida técnica” é aceitável.

• Regularmente, o produto precisará alocar recursos de desenvolvimento. Esse

reestruturação deve ser um movimento contínuo.

• O desenvolvimento da equipe melhora o desempenho do processo.

 Os princípios do Manifesto Ágil

10. Simplicidade – É essencial a arte de saber o que NÃO fazer.

O que é na prática:

• As equipes precisam avaliar o que do produto vai ser incluído...

• A equipe pode avaliar melhor quando os gerentes comunicam claramente o que é a

estratégia do produto

• As sprints podem testar se a implementação de alguma funcionalidade vai demandar

o tanto de trabalho que se estima.
 Os princípios do Manifesto Ágil

11. As melhores arquiteturas, requerimentos e designs surgem

de times que se organizam com autonomia.

O que é na prática:

• As decisões são orientadas por produtores e desenvolvedores. Os patrocinadores

não devem dar direcionamentos técnicos aprofundados.

• Os times devem pesar interativamente o que será feito.

 Os princípios do Manifesto Ágil

12. Os times devem, constantemente, refletir sobre como se tornar mais

eficaz. Então, o time deve ajustar a conduta de acordo com suas
reflexões.

O que é na prática:

• A famosa “retrospectiva do sprint”!

• A experimentação e o teste não se limitam apenas ao produto. É necessário aprender

sobre como trabalhar

• Outra consideração a ser feita em relação a esse princípio ágil é que, para praticá-lo
efetivamente, você precisa criar uma cultura de confiança e transparência que
incentive a abertura e o compartilhamento frequente de feedback.
 Algumas metodologias ágeis

1 SCRUM
2 XP – Extreme Programming
3 Kanban
4 Crystal (Clear, Yellow, Orange)
5 DSDM
6 ...
SCRUM
 SCRUM: O que é?

Criaram o Scrum em 1990,

como um jeito mais rápido, confiável
e eficiente de desenvolver softwares
na indústria de TI.

Jeff Sutherland Ken Schwaber

To Be
Nova abordagem
As Is ▪ Inicialmente em TI
Projetos ▪ Mudança Radical de ▪ Passou a ser
pensamento utilizado no mundo
▪ Processo lento
▪ Sistema evolucionário dos negócios
▪ Projetos de Método ▪ Imprevisível
Cascata ▪ Adaptativo ▪ Projetos executados
▪ Entrega fora do por Sprints para dar
▪ Projetos Concluídos escopo esperado ▪ Autocorretivo impulso às entregas
por etapas ▪ Atrasos constantes ▪ Baseado no sistema ▪ O Time todo é
▪ Passo a passo até a ▪ Sensação de total Toyota de produção responsável pelas
entrega controle ▪ E no Ciclo OODA da entregas
Projeto Aviação de Combate-
Produto
▪ Lançamento após a ▪ Retorno imediato
conclusão de todas as EUA das sprints
etapas
▪ Não precisa esperar
a conclusão do
projeto
 SCRUM: Histórico

Aspecto 1 Um Time

▪ Auto organizado
▪ Engajado no objetivo
▪ Multifuncional
▪ Colaborativo
▪ Adaptáveis
 SCRUM: Histórico

Aspecto 2 Forma de jogar

▪ Constroem o jogo a cada
jogada
▪ Realizam eventos nas suas
jogadas Sprint 1 Sprint 2 Sprint 3

▪ Somam pontos a cada Sprint

▪ Aprimoram o Time no decorrer
do jogo
▪ Agregando valor às jogadas
em pontos O que o PMI
Fala sobre
um time?
 SCRUM: Componentes

Propósito específico

Difícil de
Papéis Eventos Artefatos Regras
dominar
 SCRUM

O Scrum é um framework para desenvolver, entregar e manter produtos complexos

Framework? Conjunto de
Grande número de
conceitos usado para variáveis e elevada
resolver um problema. incerteza quanto ao
resultado final

Papéis Eventos Artefatos Regras

Integrados no Scrum

Não há um processo, técnica ou método definitivo

 SCRUM

O Scrum é um framework para desenvolver, entregar e manter produtos complexos

SCRUM

LEAN
 SCRUM

O Scrum é um framework para desenvolver, entregar e manter produtos complexos

1990

Jeff Sutherland Ken Schwaber

Case SCRUM
 Case SCRUM

Implementação de SCRUM em uma empresa

de desenvolvimento de Software.

O que fazia a empresa:

• Desenvolvimento de produtos (não
projetos);
• Softwares para gestão de vendas e
financeira, gestão de condomínios, etc;
• 1000+ clientes.

Dificuldades:
• Má produtividade da equipe de dev (não
entregavam;
• Funcionalidades desconectadas com as
necessidades do cliente.
 Processo do Scrum

Back log do
Avaliação diária Daily Scrum
produto 24 horas

Backlog da 3.
Dev
Sprint
Sprint
Team Produto

(máximo 1 mês) lançado com

1.
incremento
Product
Owner 2.
Scrum
Planejamento
Master
da Sprint

Retrospectiva da
Melhoria da equipe
Sprint
 Papéis na empresa

Gerente de desenvolvimento
1. • Sabia o que precisava do
Product produto;
Owner • Definia o Backlog

Consultor FM2S
2. • O guardião do método;
• Ajudava a “quebrar” o backlog
Scrum (junto com o dev team)
Master

Programadores
• Executavam o plano;
3. • Avaliavam diariamente o que
Dev acontecia;
Team • Avaliavam o produto ao final da
sprint
 Backlog do produto

Desenvolvimento para um software

de gestão de condomínio
Planejamento da Sprint

Definir prioridades em cima do Backlog -> Gerar Backlog da Sprint

COM RESPONSÁVEIS

Tarefas Responsável Seg Ter Qua Qui Sex

Codificar a interface do Juan

relatório financeiro
Codificar a mudança na árvore Juan
dos relatórios
Testar a interface Juan e Carlos

Escrever a ajuda online Carlos

 Daily
2.
Scrum
Master
SCRUM Diário (Desenvolvimento)
O scrum diário é uma reunião de 15 minutos para o time sincronizar suas atividades e
criar um plano para as próximas 24 horas. Isto é feito por meio da avaliação do trabalho
realizado versus o planejado na última reunião. O scrum diário deve ocorrer sempre na
mesma hora e lugar todos os dias, para reduzir a complexidade. Durante a reunião, todo
desenvolvimento irá explicar:

• O que foi feito desde a última reunião?

• O que será feito até a próxima reunião?
• Quais os obstáculos estão no caminho?

O time de desenvolvimento utiliza o scrum diário para avaliar o progresso no caminho

da meta e a velocidade que cada tarefa pendente vai sendo executada. O time de
desenvolvimento frequentemente se encontra imediatamente após o scrum diário
para replanejar o resto do trabalho daquele Sprint.
 1. 2. 3. Retrospectiva
Product Scrum Dev
Owner Master Team

Duração de 4 horas.

O dono do produto:
• Identificando o que foi feito durante o Sprint;
• Discutindo o backlog do produto conforme ele é apresentado. Depois, projetando quando as
próximas funcionalidades serão entregues, de acordo com o progresso da equipe
A equipe de desenvolvimento:
• Discutindo o que foi bem durante o Sprint, quais problemas ocorreram e como eles foram
solucionados;
Demostrando as funcionalidades criadas e respondendo as questões feitas;

O grupo inteiro colabora sobre o que fazer no próximo Sprint, e assim, esta reunião já prepara
valiosos inputs para a reunião de planejamento mensal

Resultado: backlog de produto revisado. Isto define a lista das prováveis necessidades para o
próximo Sprint. Além deste input, o backlog do produto poderá ser ajudado para acomodar às
novas oportunidades levantadas.
 Case SCRUM

Implementação de SCRUM em uma empresa

de desenvolvimento de Software.

Resultados:
• Diminuição do tempo de desenvolvimento
dos incrementos de 4 meses para 3
semanas (em média);
• Melhor comunicação com o gerente;
• Melhores incrementos;
• Ganho de novos mercados e aumento de
15% do faturamento (como novos
produtos).
 Metodologia XP
(eXtreme Programming)
 Metodologia XP (eXtreme Programming) – Breve Histórico

Extreme Programming, ou simplesmente XP,

é uma das mais conhecidas metodologia de
desenvolvimento de software que segue os
princípios do Manifesto Ágil. Embora seu
marco de criação seja o ano de 1996, a junção
de princípios e boas práticas de programação
são frutos de um processo de evolução de
pelo menos uma década em que Kent
Beck e Ward Cunningham trabalharam na
Tektronixs, Inc.
 Metodologia XP (eXtreme Programming) – Breve Histórico

Em 1996, Kent Beck foi chamado na empresa Chrysler para analisar o

desempenho de projeto do C3 (Chrysler Comprehensive
Compensation System – Sistema de Compensação Abrangente da
Chrysler). O sistema era nada menos que o controle da folha de
pagamento de aproximadamente 86 mil funcionários e o objetivo do
projeto era unificar os quatro sistemas de software legado diferentes
que estavam sendo usados há vinte anos. Uma tarefa um tanto difícil,
mas de total importância para a Chrysler que aos poucos viu o projeto
se tornar um verdadeiro caos. Havia problema em todos os processos,
desde contratos irregulares a profissionais estressados e
desconfiados. Foram três dias até Beck analisar todo o projeto para
apresentar as seguintes opções para o CIO (Chief Information Officer)
da Chrysler:

1. deixar da forma que estava;

2. demitir todos os funcionários e cancelar o projeto e;
3. conceder uma semana de folga e começar o projeto do zero.

A Chrysler optou pela alternativa 3 e contratou Beck para ser

responsável pelo projeto
Metodologia XP (eXtreme Programming)

O Extreme Programming (XP) tem muitas

semelhanças com SCRUM em termos de
valores e modelo de desenvolvimento de
projetos, ou seja, como desenvolver projetos
que possam abraçar as incertezas de forma
mais seguras. No entanto, esses dois métodos
também são complementares, visto que
SCRUM funciona mais como um framework
gerencial. O XP desenvolve menos esses
aspectos e foca mais em práticas de
engenharia.
Metodologia XP (eXtreme Programming)

Baseado em quatro grandes valores:

▪ Comunicação
▪ Simplicidade
▪ Feedback
▪ Coragem
▪ Respeito
Princípios Básicos:
• Feedback Rápido
• Simplicidade
• Mudanças Incrementais
• Abraçar Mudanças
• Trabalho de Qualidade
Metodologia XP (eXtreme Programming)

O objetivo principal do XP é levar ao extremo um conjunto de

práticas que são ditas como boas na engenharia de software. Dentre
elas podemos citar o teste, visto que procurar defeitos é perda de
tempo, nós temos que constantemente testar. Mas o XP possui mais
práticas do que apenas testar, entre as práticas, o XP diz que:

▪ Já que testar é bom, que todos testem o tempo todo

▪ Já que revisão é bom, que se revise o tempo todo
▪ Se projetar é bom, então refatorar o tempo todo
▪ Se teste de integração é bom, então que se integre o tempo todo
▪ Se simplicidade é bom, desenvolva uma solução não apenas que
funcione, mas que seja a mais simples possível
▪ Se iterações curtas é bom, então mantenha-as realmente curtas
 Metodologia XP (eXtreme Programming) – Práticas

• Jogo de Planejamento: Reunião semanal entre desenvolvedores e

clientes. Ao final de cada semana, o cliente recebe novas
funcionalidades, completamente testadas e prontas para serem
colocadas em produção.
• Pequenos Lançamentos: Auxilia no processo de aceitação do
cliente. As versões chegam a ser ainda menores que as produzidas
por outras metodologias incrementais
• Metáfora: É preciso traduzir as palavras do cliente para o significado
que ele espera dentro do projeto.
• Simplicidade de Design: Simplicidade é um princípio do XP. Nem
sempre o mais fácil é a solução mais simples.
• Time Coeso: A equipe de desenvolvimento é formada pelo cliente
e pela equipe de desenvolvimento.
• Testes do Cliente: São testes construídos pelo cliente em conjunto
com analistas e testadores, visando a aceitação de um
determinado requisito do produto
• Ritmo Sustentável: Busca por um grande ritmo sustentável e
saudável pela equipe, para que a produtividade seja sustentável.
• Reuniões em Pé: Visando uma reunião rápida e com foco nos
assuntos da equipe.
Metodologia XP (eXtreme Programming) – Práticas

• Posse Coletiva: O dono do produto é o time, ou seja, é algo

compartilhado entre todos. Isso permite que ninguém precise de
permissões e força que todos conheçam sobre a totalidade do
produto.
• Trabalho em Pares: é o trabalho em dupla, como a programação
num único computador. Geralmente a dupla é criada com alguém
iniciante e a outra pessoa funcionando como um instrutor. Em
programação é apenas um computador, o novato é que fica à
frente fazendo a codificação, e o instrutor acompanha ajudando a
desenvolver suas habilidades. Dessa forma o programa sempre é
revisto por duas pessoas, evitando e diminuindo a possibilidade de
erros. Procura-se sempre a evolução da equipe e melhorando a
qualidade do produto gerado.
• Padrões: Como a equipe trabalha no mesmo produto, um software
por exemplo, é acertado regras e padrões para que todo trabalho
consiga ser coeso.
• Desenvolvimento Orientado a Testes: Sempre é pensado em testes
constante, para que seja possível identificar erros e providenciar
correções.
• Integração Contínua: Sempre que for lançado um incremento,
providenciar sua integração no produto principal o mais rápido
possível.
Kanban
 Kanban: história

Em 1953 a Toyota desenvolveu uma solução para esse

problema na linha de produção e gerenciamento de
estoque. Criou um grande painel e dividiu-o em três
A grandes grupos com as cores verde, amarelo e vermelho.
B Cada cor correspondia a um nível de atenção que os
responsáveis de cada setor deveriam ter em relação ao seu
C estoque. O número de peças prontas era representado por
D cartões, um para cada peça. Quando uma peça pronta saía
do estoque do setor, um cartão era retirado do painel,
revelando um sinal verde (que estava por trás do cartão). E
assim seguia, peça por peça, cartão por cartão. Até o
momento em que, ao retirar um cartão, o sinal revelado
seria amarelo. Isso significaria que o estoque estava
baixando e já estava em níveis de atenção. Seria o
momento propício de fazer novas cotações de preço e
renovar os itens de estoque.
 Kanban: o processo

Esse processo ficou conhecido como KANBAN, que na

tradução significa “cartão visual”. Atualmente é utilizado em
linhas de produção como montadoras de veículos. A técnica
foi aperfeiçoada, adicionando-se mais cores, em mais
A etapas. Porém, a essência do mecanismo continua a mesma:
evitar desperdício e ociosidade, mantendo a linha de
B produção harmoniosa e com ritmo.
C Para uma empresa, o Kanban pode facilitar os
D procedimentos internos, pois permite visualmente entender
como e de onde vêm o fluxo do processo, e seu destino.
Funciona melhor ainda se utilizado em concordância com
outras técnicas, como o fluxo SIPOC, que também analisa
processos internos, porém nomeando as entradas e
destinos de informações. O Kanban dá suporte ao just-in-
time, que utiliza a ideia de não produzir enquanto não
houver demanda, portanto previne os colapsos entre os
setores. Essa eficiência na produção auxilia no fluxo do
processo como um todo, fazendo a empresa não parar, não
ser rápida demais, nem muito lenta.
 Kanban: o processo

Inicialmente o Kanban era muito utilizado nas indústrias de

produção e empresas de logística, mas atualmente, fazendo
as adaptações necessárias, qualquer empresa pode utilizá-
lo. Atualmente é amplamente utilizado em empresas de
A softwares, agências de publicidade e até mesmo por
prestadores de serviço, pois é um método totalmente
B moldável ao tipo de negócio praticado. Deve-se ter o
cuidado de aplicar a técnica com o objetivo correto, que é
C eliminar desperdícios e ociosidades, refletindo em uma
D melhor administração financeira dos recursos.

Se sua empresa tem procedimentos, setores e

responsáveis, é bom pensar no Kanban para ajudar a
visualizar o processo na sua homogeneidade. Com certeza
serão detectados os gaps, as falhas de comunicação, os
acúmulos de atividades ou materiais, e ao final da aplicação
das melhorias, certamente o resultado será um melhor fluxo
das informações, além de possivelmente a economia
financeira. E lembre-se: o Kanban serve para todos. Basta
adaptá-lo ao tamanho do seu negócio.
A fazer Fazendo Feito

Kanban
 Algumas metodologias ágeis

1 SCRUM
2 XP – Extreme Programming
3 Kanban
4 Crystal (Clear, Yellow, Orange)
5 DSDM
6 ...
Estudos de caso
 Empresa do ramo de Saúde, líder de mercado

Prêmios Prêmios Prêmios

Inovação Agilidade Tecnologia Resultados
▪ Atraso de 6 meses
▪ Custo de 6500 horas
▪ Não foi entregue NADA
Problema: Time

Solução
▪ Chamar um Scrum Master
Dono do Scrum Equipe de
produto Master Desenvolvimento ▪ Cumprir o Scrum
 Empresa do ramo de Pagamento, líder de mercado

Prêmios Projetos Implantando

Inovação Tradicionais o ágil Resultados
▪ Atrasos
▪ Aumento nos Custos
▪ Mudanças de escopo no final o projeto
Problema: Cultura e Tipo Organização

▪ Contratos não preveem o Ágil

▪ Elevado números de documentos e mal escritos Solução
▪ Times não colaborativos
▪ Falta de transparência ▪ Não houve
▪ Times enormes ▪ Scrum não implantado
 Empresa do ramo bancário, líder de mercado

Prêmios Prêmios Modelo

Inovação Agilidade em ágil Resultados
▪ Atrasos
▪ Aumento nos Custos
▪ Mudanças de escopo no final o projeto
Problema: Cultura e modelo errados

▪ Projetos pequenos no ágil

▪ Muitos processos engessados
▪ Recurso de desenvolvimento escasso
▪ Falta de transparência
Solução
▪ Utilizar outras formas de
gerenciamento e projetos
 RH Ágil - Recrutamento & Seleção

Processo antes do Ágil - Esteira de contratação

Job Description ANS - Acordo de Processo seletivo Entrevistas e

RH senta com o gestor Nível de Serviço Interno ou externo: contratação
da área para fazer a Meta de teste e dinâmicas para Candidato ideal
descrição da vaga ou quantidade de seleção
validar o existente dias para fechar a
vaga
 RH Ágil - Recrutamento & Seleção

Processo depois do Ágil

Time

▪ Ideia do gestor x ideia do time;

▪ Inteligência coletiva;

▪ Competências Técnicas e Comportamentais

- Matriz É, NÃO É/ FAZ, NÃO FAZ;
 RH Ágil - Recrutamento & Seleção
Priorização
▪ Valor de negócio;
▪ Trabalhar em ciclos curtos;
▪ Objetivar melhoria contínua.
Ex. Vagas abertas:
▪ Analista de Marketing (aberta há 20 dias);
▪ Gerente de Relacionamento de Banco
(aberta há 2 dias).
Qual vaga deve ser preenchida primeiro?
O Analista de Marketing irá trabalhar
com outros 10 analistas em funções
similares, sendo possível cobrir a
falta deste profissional neste meio
tempo;
O Gerente de Relacionamento de
Banco gera sozinho mais de R$
400.000 / ano de lucro. Teremos
uma nova visão voltada para
métricas e informações e foco à
priorização daquilo que terá um
maior retorno para a organização.
 RH Ágil - Recrutamento & Seleção

Entrega contínua e visibilidade do processo

▪ Kanban;

▪ Medir e gerenciar fluxo, ciclos e gargalo;

▪ Saber o tempo médio do processo seletivo,

inclusive o tempo de aplicação de testes e
das entrevistas.
 RH Ágil - Recrutamento & Seleção

Excelência Técnica e Métrica

Standups Retrospectiva

▪ Atualizar a equipe sobre as ações e tarefas; ▪ Celebrar o sucesso;

▪ Pedido de ajuda com o surgimento de ▪ Identificar melhorias;

problemas;
▪ Identificar questões e ações para o
▪ Reuniões diárias. próximo ciclo.
 RH Ágil - Recrutamento & Seleção

Kanban Standups Retrospectiva Resultados

▪ Perfil do candidato será melhor
definido
▪ Time mais participativo
Diferenças no Ágil ▪ Tempo de contratação adaptável

Solução
▪ Uso das metodologias ágeis
Colaboração Mudanças e
da equipe adaptações ▪ Valores e princípios do Manifesto Ágil