Professional Documents
Culture Documents
Agilidade
http://www.dicio.com.br/agilidade/
Adaptado de http://pt.wikipedia.org/wiki/Agilidade
@ribeirord
Rapidez Agilidade
de
@ribeirord
@ribeirord
In
@ribeirord
DINMICA
@ribeirord
O software implementado
@ribeirord
@ribeirord
@ribeirord
@ribeirord
While the process must always accommodate changes, the elaboration phase
ensure that the architecture, requirements and plans are stable enough, and the
risks are sufficiently mitigated, so you can predictably determine the cost and
schedule for the completion of the development. Conceptually, his level of fidelity
would correspond to the level necessary for na organization to commit to a fixedprice construction phase
Embora o processo deve sempre acomodar as mudanas, a fase de elaborao deve
garantir que a arquitetura, os requisitos e os planos sejam estveis o suficiente e
que os riscos foram
suficientemente mitigados, para que voc
possa previsivelmente determinar o custo e o cronograma para a concluso do
desenvolvimento. Conceitualmente, o seu nvel de fidelidade que corresponderia ao
nvel necessrio para uma organizao se comprometer com uma fase de
construo a preo fixo.
Lean IT
Lean IT definition:
definition: Lean IT engages people, using a framework of Lean
@ribeirord
Lean IT
e tem um
Lean IT
Tipos de Desperdcios:
Mura:
Mura desperdcio por tentar prever possveis necessidades futuras. Evitar a
mura significa reduzir ao mximo o inventrio, isto , as partes paradas no
meio do processo, isto , comeando ou no terminando.
Muri:
Muri desperdcios que podem ser evitados por planejamento. Nessa categoria
enquadra-se o excesso de burocracia ou de complexidade nem processo de
produo.
Muda:
Muda desperdcios do dia a dia, criados por uma cultura anterior de trabalho.
Superproduo
Transporte desnecessrio
Inventrio
Locomoo
Defeitos
Super processamento
Espera
10
@ribeirord
Lean IT
Expected
Demand
Mass
Production
Economies of
scale
11
@ribeirord
Lean IT
On demand
Production
Adaptation
Customer
Requirements
KanBan
Linha de Produo = sequncia de passos para produzir algo
A fazer
Inventrio 1
Inventrio 2
Inventrio 3
Produto
12
@ribeirord
KanBan
A fazer
Inventrio 1
Inventrio 2
Inventrio 3
Produto
1
8
9
10
No Kanban representamos o sistema pull de produo, h um limite de
inventrio claramente definido. Assim peas s so produzidas quando de fato
h demanda e gasta-se menos em peas que no sero utilizadas ou em
estoque de inventrio.
@ribeirord
KanBan
dispositivos fsicos
sinais de demanda downstream processes
regula a demanda em um pull system
limita de trabalho em progresso (wip)
controle visual
auto direo
13
@ribeirord
Systems Thinking
Aps reduzir a mura, temos uma melhor viso de nossa
linha de produo ( trabalhos redundantes,...)
Quantas vezes no vimos consagrados processos de produo de
software atrapalhando uma equipe em vez de ajud-la ? Todas as
fases do seu processo so realmente necessrias para o sucesso
final ?
Work Cells
14
@ribeirord
Kaisen
O Manifesto gil
Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs deste
trabalho, passamos a valorizar:
Indivduos e interao entre eles mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais
os itens esquerda.
15
@ribeirord
Princpios geis
Princpios geis
16
@ribeirord
Vantagens da Agilidade
Feedback rpido
Motivao da equipe
SCRUM
Waterfall and Spiral methodologies set the context and deliverable definition at the
start of a project. Scrum and iterative methodologies initially plan the context and
broad deliverable definition, and then envolve the deliverable during the project based
on the environment. Scrum acknowledges that the underlying development processes
are incompletely defined and uses control mechanisms to improve flexibility.
17
@ribeirord
SCRUM
The primary difference between the defined (waterfall, spiral and iterative) and
empirical (SCRUM) approach is that the Scrum approach assumes that the analysis,
design, and development process in the sprint phase are unpredictable. A control
mechanism is used to manage the unpredictablity and control the risk. Flexibility,
responsiveness, and reliability are the results.
A principal diferena entre processos definidos (waterfall, spiral and iterative) e a
abordagem emprica (SCRUM) que a abordagem Scrum assume que a anlise,
concepo, desenvolvimento e processo dentro da fase de sprint so
imprevisveis. Um mecanismo de controle usado para gerenciar o falta de
previsibilidade e controlar o risco. Flexibilidade, agilidade e confiabilidade so os
resultados.
SCRUM
Scrum: A framework within which people can address complex adaptative problems,
while productively and creatively delivering products of the highest possible value(...)
Scrum makes clear the relative efficacy of your product management and development
practices so that can improve .
18
@ribeirord
SCRUM
Inspeo
Adaptao
19
@ribeirord
SCRUM
Resumindo tudo isso...
isso...
SCRUM
Personagens
20
@ribeirord
SCRUM Personagens
O Product Owner
O Product Owner, ou dono do produto, o responsvel por
maximizar o valor do produto e do trabalho da equipe de
Desenvolvimento. Como isso feito pode variar amplamente
atravs das organizaes, Times Scrum e indivduos.
O Product Owner pode fazer o trabalho acima, ou delegar para a
Equipe de Desenvolvimento faz-lo. No entanto, o Product Owner
continua sendo o responsvel pelos trabalhos.
SCRUM Personagens
21
@ribeirord
SCRUM Personagens
SCRUM Personagens
Product Owner
Fase
Atividade
PRE-GAME
GAME
POST-GAME
22
@ribeirord
SCRUM Personagens
SCRUM Personagens
Equipe
de Desenvolvimento
23
@ribeirord
SCRUM Personagens
SCRUM Personagens
24
@ribeirord
SCRUM Personagens
O Scrum Master
SCRUM Personagens
25
@ribeirord
SCRUM Personagens
SCRUM Personagens
26
@ribeirord
SCRUM Personagens
O Time Scrum
O Time Scrum composto pelo Product Owner,
Owner a Equipe de
Desenvolvimento e o Scrum Master.
Master
Times Scrum so auto-organizveis e multifuncionais. Equipes
auto-organizveis escolhem qual a melhor forma para
completarem seu trabalho, em vez de serem dirigidos por outros
de fora da equipe.
Equipes multifuncionais possuem todas as competncias
necessrias para completar o trabalho sem depender de outros
que no fazem parte da equipe.
SCRUM Personagens
O Time Scrum
O modelo de equipe no Scrum projetado para aperfeioar a
flexibilidade, criatividade e produtividade.
Times Scrum entregam produtos de forma iterativa e incremental,
maximizando as oportunidades de realimentao.
Entregas incrementais de produto Pronto garantem que uma
verso potencialmente funcional do produto do trabalho esteja
sempre disponvel.
27
@ribeirord
SCRUM
Resumindo tudo isso...
isso...
SCRUM
viso
28
@ribeirord
SCRUM Viso
viso
Viso uma clara imagem que gera uma atrao emocional entre
pessoas e produto ( quando se fala a viso quem escuta deve ser capaz
de imaginar como ser o produto)
SCRUM Viso
viso
29
@ribeirord
SCRUM Viso
viso
Elevator Statement
Para
<cliente/pblicocliente/pblico-alvo> que <necessidade do
cliente/pblicocliente/pblico-alvo ou oportunidade> , o <nome do
produto> um <categoria do produto> que <principal
benefcio ou razo para comprar o produto>.
Diferentemente do <principal competidor ou alternativa>
nosso produto <principal diferenciao> .
http://www.flyingsolo.com.au/marketing/business-marketing/preparing-your-elevatorstatement
SCRUM Viso
Elevator Statement
viso
Praticando...
30
@ribeirord
SCRUM Viso
viso
Nome do Produto
Grficos
Trs ou quatro pontos chave (benefcios)
para vender o produto
Principais features no verso
Principais requisitos operacionais
http://www.agile-ux.com/2011/03/04/a-day-in-life-of-an-agileux-practitionervision/
SCRUM Viso
Product Vision Box
viso
Praticando...
31
@ribeirord
SCRUM Viso
viso
SCRUM Viso
Product Road Map
viso
Praticando...
32
@ribeirord
SCRUM Viso
viso
Formalizao da Viso
SCRUM Viso
Project Data Sheet
viso
Praticando...
33
@ribeirord
Analista: Transforma
em linguagem tcnica
Dev:
Linguagem tcnica vira
cdigos
Cliente:
Linguagem de Negcio
Dev:
Linguagem tcnica vira
cdigos
34
@ribeirord
CARTO
CONVERSAS
CONFIRMAO
Independente
Negocivel
Valiosa para usurios e clientes
Estimvel
Small(pequena)
Testvel
35
@ribeirord
QUEM ?
O QUE ?
POR QUE ?
36
@ribeirord
Pagamento de Boleto:
Para que eu consiga comprar produtos nessa loja
Como comprador que no tem carto de crdito
Quero que o sistema de suporte a pagamento em boleto
37
@ribeirord
EPIC
STORY
STORY
STORY
STORY
STORY
STORY
TEMA
STORY
STORY
STORY
STORY
38
@ribeirord
SCRUM
O corao do Scrum a Sprint,
Sprint um time-box de
um ms ou menos, durante o qual um Pronto,
verso incremental potencialmente utilizvel do
produto, criado.
Sprints tem duraes coerentes em todo o
esforo de desenvolvimento. Uma nova Sprint
inicia imediatamente aps a concluso da Sprint
anterior.
SCRUM
Durante a Sprint:
39
@ribeirord
Apresentao da Histria
O P.O. apresenta a viso de negcio dos itens mais prioritrios do Product Backlog aos
desenvolvedores. (Ex: History Cases or Use Cases)
Dvidas do Negcio
Opcional
O Product Owner deve sair da sala, caso permanea ele no deve emitir opinies para o
prximo passo
O qu...
Sprint Backlog
Definio de Metas
Como...
O qu...
40
@ribeirord
SCRUM Review
A Reviso da Sprint executada no final da Sprint para inspecionar o
incremento e adaptar o Backlog do Produto se necessrio.
Durante a reunio de Reviso da Sprint o Time Scrum e as partes
interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e
em qualquer mudana no Backlog do Produto durante a Sprint, os
participantes colaboram nas prximas coisas que precisam ser prontas.
Esta uma reunio informal, e a apresentao do incremento destina-se a
motivar e obter comentrios e promover a colaborao.
41
@ribeirord
SCRUM Review
A Reunio de Reviso inclui os seguintes elementos:
SCRUM Review
O resultado da Reunio de Reviso da Sprint um Backlog do Produto
revisado que define o provvel Backlog do Produto para a prxima Sprint.
O Backlog do Produto pode tambm ser ajustado completamente para
atender novas oportunidades.
Dicas:
O sucesso do Review baseado na meta do Sprint
Garantir que cliente, mas principalmente usurio aprove o produto
Apresentar o produto sem influenciar o usurio
Usurio deve dar feedback do uso
NO ! Se codifica no Review
Caso encontre BUGs, eles e novas ideias voltam para o Backlog
42
@ribeirord
SCRUM Retrospective
Esta uma reunio tem um time-boxed de 3.75% do Sprint.
o momento de reflexo e exposio de problemas de um time e,
portanto , o momento no qual se melhora o processo, evidencia-se e
resolve-se problemas que afligem a equipe.
O propsito da Retrospectiva da Sprint :
Inspecionar como a ltima Sprint foi em relao as pessoas,
relaes, processos e ferramentas;
Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias; e,
Criar um plano para implementar melhorias no modo que o Time
Scrum faz seu trabalho;
SCRUM Retrospective
O Scrum Master encouraja o Time Scrum a melhorar, dentro do processo
do framework do Scrum, o processo de desenvolvimento e as prticas para
faz-lo mais efetivo e agradvel para a prxima Sprint.
Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de
aumentar a qualidade do produto, adaptando a definio de Pronto
quando apropriado.
Ao final da Retrospectiva da Sprint, o Time Scrum dever ter identificado
melhorias que sero implementadas na prxima Sprint.
A implementao destas melhorias na prxima Sprint a forma de
adaptao inspeo que o Time Scrum faz a si prprio.
A Retrospectiva da Sprint fornece um evento dedicado e focado na
inspeo e adaptao, no entanto, as melhorias podem ser adotadas a
qualquer momento.
43
@ribeirord
SCRUM Retrospective
Existem diversas formas de trabalhar na retrospectiva, uma das mais
adotadas no Brasil funciona da seguinte forma:
Cada membro da caneta ganha caneta e post-it;
Cada um, sem olhar opinies ou conversar com outros membros do
time , escreve os pontos positivos e negativos do Sprint;
Um membro da equipe agrupa os post-its com opinies parecidas e
narra o que foi descrito. Normalmente os problemas mais srios
aparecero mais vezes;
A equipe discute como resolver os problemas apontados j para o
prximo Sprint. Evitar problemas recorrentes
Anota-se as solues discutidas e as mantem visveis durante o Sprint,
como lembrete
SCRUM Retrospective
44
@ribeirord
SCRUM
SCRUM
45
@ribeirord
SCRUM
SCRUM
Escopo
Tamanho do time
Disponibilidade do cliente
Conhecimento do time sobre agilidade
Conhecimento do time sobre a tecnologia
Times novos
...
46
@ribeirord
SCRUM
Dica:
Quanto maior o tempo de feedback pior ser... O lean
possui um conceito de Fail Fast que afirma que
quanto mais rpido falhar, melhor para a mudana de
estratgia.
Release
Iterao
Dia
47
@ribeirord
Determinar
Condies de
Satisfao
Estimar
Velocidade
Estimar os
Itens do
Backlog
Selecionar
Itens e data do
Release
Priorizar
Estrias
Tamanho
(27 pontos)
Clculo
(9 pontos
por sprint)
Durao
(3 sprints)
48
@ribeirord
Clculo
(9 pontos
por sprint)
Durao
(3 sprints)
Resultado
Sprint 1
Sprint 2
Sprint 3
Fonte: http://www.mountaingoatsoftware.com/scrum/release-burndown
49
@ribeirord
Fonte: http://www.scrumalliance.org/articles/39-glossary-of-scrumterms#1116
eXtreme Programming
Os Valores em XP so conceitos no tangveis que
acredita-se fazer uma grande diferena na qualidade
final do produto e na motivao dos times. Eles so:
Comunicao
Feedback
Coragem
Simplicidade
50
@ribeirord
eXtreme Programming
Valores:
Comunicao
DIRETA
EFICAZ
ESCLARECEDORA
eXtreme Programming
Valores:
Feedback
51
@ribeirord
eXtreme Programming
Valores:
Coragem
eXtreme Programming
Valores:
Simplicidade
52
@ribeirord
eXtreme Programming
Valores:
Valores:
Propriedade Coletiva do Cdigo
Programao Pareada
Testes Automatizados e test first
Test Driven Design (TDD)
Integrao contnua e Deploy Contnuo
Refatorao Constante
eXtreme Programming
Valores:
Valores:
Propriedade Coletiva do Cdigo
53
@ribeirord
eXtreme Programming
Valores:
Valores:
Programao Pareada (pair
(pair programming)
programming)
eXtreme Programming
Valores:
Valores:
Programao Pareada (pair
(pair programming)
programming)
54
@ribeirord
eXtreme Programming
Valores:
Valores:
Testes Automatizados e test first
eXtreme Programming
Valores:
Valores:
Testes Automatizados e test first
Permitir refatorao : podemos refatorar o cdigo com mais segurana. Podemos alterar
o cdigo e verificar automaticamente se o software continua funcionando.
Documentar:
Documentar: Os testes devem ter nomes que explicam quais funcionalidades eles testam,
assim ao executar o cdigo, o desenvolvedor sabe quais funcionalidades
foram
implementadas e qual o comportamento esperado pelo cdigo.
55
@ribeirord
eXtreme Programming
Valores:
Test Driven Design (TDD)
Refatora
@ribeirord
eXtreme Programming
56
@ribeirord
eXtreme Programming
Valores:
Valores:
Integrao contnua e Deploy Contnuo
eXtreme Programming
Valores:
Valores:
Refatorao Constante
57
@ribeirord
eXtreme Programming
Refatorao Constante
eXtreme Programming
Refatorao Constante
58
@ribeirord
59
@ribeirord
BUG DESCOBERTO !
No existe Coringa no Black Jack
http://junit.sourceforge.net/doc/testinfected/testing.htm
60
@ribeirord
.
.
.
.
Critrios de Teste
52 cartas no Baralho.
13 Cartas de Cada Naipe.
No pode existir carta Coringa.
Uma carta de Cada Tipo
Critrios de Teste
52 cartas no Baralho.
13 Cartas de Cada Naipe.
No pode existir carta Coringa.
Uma carta de Cada Tipo
61
@ribeirord
Critrios de Teste
52 cartas no Baralho. OK
13 Cartas de Cada Naipe.
No pode existir carta Coringa.
Uma carta de Cada Tipo
Critrios de Teste
52 cartas no Baralho. OK
13 Cartas de Cada Naipe. OK
No pode existir carta Coringa.
Uma carta de Cada Tipo
62
@ribeirord
Critrios de Teste
52 cartas no Baralho. OK
13 Cartas de Cada Naipe. OK
No pode existir carta Coringa. OK
Uma carta de Cada Tipo
Critrios de Teste
52 cartas no Baralho. OK
13 Cartas de Cada Naipe. OK
No pode existir carta Coringa. OK
Uma carta de Cada Tipo OK
63
@ribeirord
Planning Poker
A ideia principal por traz do Planning Poker permitir que todos
membros do time de desenvolvimento que esto comprometidos
implementao do Sprint participem colocando a sua viso
complexidade para que juntos possam chegar a um indicador
complexidade comum para o time.
os
na
de
de
1/2
13
20
40
100
64
@ribeirord
Planning Poker
Cada participante do time que estiver comprometido recebe um conjunto
de cartas sendo cada uma com o nmero de complexidade.
O grupe se rene geralmente na reunio Sprint Planning e esclarece as
histrias com o PO (Product Owner) para depois estimar uma a uma.
Seguindo a ordem de sequencia das s histrias j priorizadas pelo PO.
Ento o time conta at trs e cada um apresenta uma das cartas ao
mesmo tempo. Esse um momento importante, pois nenhum membro
pode influenciar o outro na hora de mostrar as cartas.
Planning Poker
Aps apresentada as cartas confere-se os nmeros das mesmas para ver
se deu tudo igual ou ocorreu divergncias. Em caso de divergncia cada
membro pode argumentar o que o levou a pensar diferente dos demais e
nesse momento pode usar os argumentos que justifique aquele item ser
mais complexo ou mais simples.
Com o tempo voc vai observar opinies do tipo Eu j implementei uma
rotina parecida em um projeto anterior que trazem a tona o grande valor
dessa tcnica que justamente fazer as pessoas serem ouvidas.
Aps a apresentao dos argumentos cada pessoa que ficou na dvida
pode propor uma nova votao e mudar o seu voto para mais ou para
menos conforme o novo entendimento da questo. Por isso um item que
estava complexo pode ser finalizado com mais simples ou vice-versa
prevalecendo o entendimento do time sobre a questo.
65
@ribeirord
Leitura Complementar
66