Uma Imersão Prática

em
Método Ágil

1
Por Que
Métodos Ágeis?
2
1950 1970
Computação

3
1970 1990
Engenharia de Software

4
1990
Ágil

5
1950 1970 1990
Caos Ordem Complexidade

6
Complexidade

7
 Complexo Complicado
Explorar Perceber
Perceber Analisar
Responder Responder

Práticas Emergentes Boas Práticas

Desordem

Caótico Simples
Perceber
Agir Categorizar
Perceber Responder
Responder

Práticas Originais Melhores Práticas

8
Scrum – O Que É

9
“Um framework com o qual as
pessoas podem resolver
problemas complexos e
adaptáveis, enquanto entregam
produtos de forma produtiva e
criativa e com o maior valor
possível.”
— ScrumAlliance.org

10
“ Um framework é um construto
fundamental que define
pressupostos, conceitos, valores
e práticas, e que inclui
orientações para a execução
propriamente dita.
”
— Benjamin L. Tomhave

11
“
A metodologia é um construto
orientado que define práticas,
procedimentos e regras para a
aplicação ou a execução de uma
tarefa ou função específica.
”
— Benjamin L. Tomhave

12
Práticas Regras

Papéis Artefatos

13
 Transparência

Inspeção
Scrum

Adaptação
14
Manifesto Ágil

15
Indivíduos e processos e
mais que
interação entre eles ferramentas
16
Software (produto) documentação
mais que
em funcionamento abrangente
17
Colaboração com negociação
o cliente mais que de contratos
18
Responder a seguir
mais que
mudanças um plano
19
Nossa maior prioridade é satisfazer o cliente,
através da entrega adiantada e contínua de
software de valor.
Aceitar mudanças de requisitos, mesmo no
fim do desenvolvimento. Processos á geis se
adequam a mudanças, para que o cliente
possa tirar vantagens competitivas.
Entregar software funcionando com
freqü encia, na escala de semanas até meses,
com preferê ncia aos períodos mais curtos.
Pessoas relacionadas à negó cios e
desenvolvedores devem trabalhar em
conjunto e diá riamente, durante todo o curso
do projeto.
Construir projetos ao redor de indivíduos
motivados. Dando a eles o ambiente e suporte
necessá rio, e confiar que farã o seu trabalho.
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.
Software funcional é a medida primá ria de
progresso.
Processos á geis promovem um ambiente
sustentável. Os patrocinadores,
desenvolvedores e usuá rios, devem ser
capazes de manter indefinidamente, passos
constantes.
Contínua atençã o à excelência té cnica e bom
design, aumenta a agilidade.
Simplicidade: a arte de maximizar a
quantidade de trabalho que nã o precisou ser
feito.
As melhores arquiteturas, requisitos e designs
emergem de times auto-organizáveis.
Em intervalos regulares, o time reflete em
como ficar mais efetivo, entã o, se ajustam e
otimizam seu comportamento de acordo.
20
Papéis de Scrum

21
Product Owner

22
Scrum Master

23
Development Team Members

24
Gerente de Projeto
em Scrum?
25
Fluxo de Scrum

26
 Planning
Meeting

Product Sprint
Backlog Backlog

Sprint
Retrospective
Daily Daily
Meeting Meeting

Execução
Sprint
Review
Daily Daily
Meeting Meeting
Incremento
potencialmente
entregável
27
Visão

28
Uma visão é uma clara
imagem que gera uma
atração emocional entre
pessoas e produto.

29
Elevator Statement

30
Para [cliente/público-alvo]
que [necessidade do cliente/público ou
oportunidade],
o [nome do produto]
é um [categoria do produto]
que [principal benefício ou razão para comprar o
produto].
Diferentemente [do principal competidor ou
alternativa]
nosso produto [principal diferenciação].

31
32
Product Vision Box

33
Remember the Future
34
35
Project Data Sheet

36
Product Backlog

37
Alta Prioridade

Cada Sprint implementa os requisitos de prioridade

mais alta

Cada novo requisito é priorizado

e inserido no Product Backlog
pelo Product Owner a qualquer
momento

Requisitos podem ser repriorizados pelo Product

Owner a qualquer momento

Requisitos podem ser removidos

pelo Product Owner a qualquer
momento

Baixa Prioridade
38
User Stories

39
“
...representar os requisitos do cliente,
mais que documentá-los.
” — Rachel Davis
Chair of Agile Alliance

40
Os três C’s de User Story

Card (cartão)
Conversation (conversação)
Confirmation (confirmation)

41
I ndependent
Negotiable
V aluable
E stimatable
Small
Testable
42
Como um [Perfil]
eu posso/gostaria/devo [Funcionalidade]
para [Valor ao negócio]

43
Técnicas de Elaboração
de User Stories

• Entrevistas
• Questionários
• Observação
• Story-Writing Workshops

44
Evite Perguntas Fechadas
Você quer a nossa nova versão do produto
rodando em um browser?

Você quer a nossa nova versão do produto

rodando em um browser, mesmo sabendo
que isto vai reduzir a performance, terá
uma interface mais pobre e diminuirá a
sua interatividade com o sistema?

45
Utilize Perguntas Abertas

O que você acha de nossa próxima versão

do produto rodar em um browser? Quais
as vantagens que você visualiza?

46
Testes de Aceitação
Uma das melhores formas de se expressar os
detalhes discutidos

O Product Owner é quem deve escrever os

Testes de Aceitação, e o deve fazê-lo antes da
codificação.

Teste DEVEM fazer parte do processo e devem

ser automatizados sempre que possível

47
Temas e Épicos
Story
Story Story
Épico Story Story
Story

Tema
Story Story Story

Story Story Story

Story Story Story

48
Técnicas de Priorização

Moscow
Utilizado para chegar a um acordo entre stakeholders
sobre a importância dada na entrega de cada
história.

Theme Screening
Composta apenas por opiniões de experts baseadas
em comparações realizadas com um tema
importante.

49
MoSCoW
Must
requisito que deve ser satisfeito para que a solução seja
considerada um sucesso
Should
representa um item de alta prioridade que deveria ser includo
na solução se possível
Could
descreve um requisito considerado desejável mas não
necessário
Won’t
representa um requisito que os stakeholders concordaram que
não será implementado em um determinado release, mas pode
ser considerado no futuro

50
Theme Screening
Temas
A B C D E F
Base

Importa para os clientes atuais + + - 0 - + 0

Colabora para o atingimento das metas do quarter + - 0 0 0 0 0

Elimina problemas antigos dos usuários + 0 0 0 + - +

Ajuda nas tomadas de decisões do board 0 0 0 0 + 0 +

Net Score 3 0 -1 0 1 0 2

Rank 1 4 5 4 3 4 2

51
Release Planning

52
O Que É Release Planning

53
Minimum Viable Product

54
Release Planning Meeting

55
Estrutura da Reunião
Selecionar um
tamanho de
sprint

Determinar Selecionar User

Estimar as User Estimar
condições de Stories e data do
Stories velocidade
satisfação Release

Priorizar User
Stories

56
O Release Plan
Sprint 1 Sprint 2 Sprint 3 Sprint 4 ~ 7

57
Técnicas de Estimativa

58
Planning Poker

59
60 / 60