Agile Requirements Workshop

About Thinking Innovation

Workshop de
Requisitos Ágeis
Paulo Furtado
2014

Dinâmica (30 min)


Onde tudo começou
100%

Média
de
uso
de
funcionalidades

de
sistemas

80%

7%

60%

Falhou

40%

Desaﬁado

13%

16%

Sucesso

2000

2002

2004

2007

2009

20%

0%

45%

19%


O Manifesto Ágil – Valores
“Estamos descobrindo melhores maneiras de desenvolver software, fazendo
software e ajudando outros a fazê-lo. Através deste trabalho passamos a
valorizar:

Indivíduos e interações

Processos e ferramentas

Software que funciona

Documentação abrangente

Colaboração do cliente
Resposta à mudanças

mais
que

Negociação de contrato
Seguir um plano

Isto é, embora haja valor nos itens do lado direito, nós
valorizamos mais os do lado esquerdo.”
Fonte: http://www.agilemanifesto.org

12 princípios do Manifesto Ágil
1. 

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

2. 

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

3. 

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

4. 

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto
e diariamente, durante todo o curso do projeto

5. 

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

6. 

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.

7. 

Software funcional é a medida primária de progresso

8. 

Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente,
passos constantes

9. 

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

10. 

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito.

11. 

As melhores arquiteturas, requisitos e designs emergem de times autoorganizáveis.

12. 

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

Antes de começar

Conceitos
Iniciais

O que é um requisito?
Segundo o dicionário:
1.  Coisa necessária e indispensável.
2.  Condição indispensável; exigência.
3.  Requerido; requisitado.

Pergunta
Tudo que um usuário/cliente nos
pede é indispensável?


O que é Análise de Requisitos?

Análise ou levantamento
de requisitos é a ação de
identificar necessidades
de usuários/clientes.


ATENÇÃO!!!

Análise ou levantamento
de requisitos não é
documentar e/ou
especificar requisitos, mas
identificar o que realmente
são os requisitos.

O que significa “ser ágil”?
•  Segundo James Shore & Shane Warden
“A resposta é mais complicada do que se
pode pensar. O Desenvolvimento ágil não é
um processo específico que pode ser seguido.
Nenhuma equipe pratica o método Ágil.”
“O desenvolvimento ágil é uma

filosofia.

É

uma maneira de pensar sobre
desenvolvimento de software. Isso pode ser
visto no Manifesto Ágil.”


1º passo

Foco no
Usuário/Cliente


Problema

“Nós temos a tendência de
NÃO tratar o cliente de
software como uma pessoa
que gasta dinheiro.”


Problema pior…

“O cliente, muitas vezes,
também não percebe que
está gastando dinheiro”


O Cliente é responsável, mas
como dizer isso a ele?

R$ 500.000,00
Quinhentos mil reais


Lição #1

Um Team Guider
valoriza o dinheiro
gasto para fazer um
software

O valor dos requisitos é RELATIVO

Contexto é importante

Lição #2

Um Team Guider o
conhece o contexto
do produto


O Requisito fácil e simples pode ser
ESSENCIAL.


Lição #3

Um Team Guider
sabe a diferença
entre um par de
brincos e uma
escova de dentes

Quality is personal!

Jim
Highsmith

Agile
Consultant


Lição #4

Um Team Guider
define, para o seu
time, o conceito de
qualidade

Escolha um cenário...
O Time

O PO

+
+

?
=
?
=


Lição #5

Um Team Guider
sabe onde quer
chegar


Delegando poderes


Lição #6

Um Team Guider
deve ter poderes de
decisão e isso deve
ficar claro para
TODOS

O Cliente é tratado como Cliente!


Lição #7

Um Team Guider
faz TEST DRIVE o
tempo inteiro.


Pergunta:

E qual a diferença
entre um Team
Guider e um
Owner ?

Resposta:
Um Product Owner banca o
produto e, eventualmente,
guia o time
Um Team Guider guia o time
e, eventualmente, banca o
produto.

Administrando Expectativas

Fonte: Software Requirement 3 (Karl Wiegers, Joy Beatty)

Interseção de Responsabilidades

Pessoas de
Negócio

Equipe de
Desenvolv.

Facilitadores

Definindo uma
visão


Visão de Produto
•  Define as fronteiras do projeto deixando
bem claro o objetivo macro do produto a
ser desenvolvido;

•  Tem o objetivo de estabelecer um
acordo inicial entre os participantes
do projeto sobre as funcionalidades
que devem ser implementadas;
•  Ela ajuda a guiar as mudanças que
vão ocorrer no projeto para identificar
se existem grandes distorções em
relação ao que foi acordado
inicialmente;


Business Model Canvas
•  Usado para realizar planejamento
estratégico e melhorar modelos de
negócio (novos ou não);
•  Mapa que contém 9 (nove) blocos para um
modelo de negócio
•  Criado por Alexander Osterwalder
Um Business Model é um mapa
dos principais itens que
constituem uma empresa. O
Mapa é um resumo dos pontos
chave de um plano de negócio.


8
Principais Parceiros
Alianças de negócios
que contemplam os
outros aspectos do
modelo de negócio

7

4

2

Relac. com Cliente

Principais Atividades
Atividades
necessárias para
executar o Modelo de
Negócio

6
Principais Recursos
Recursos
necessários para
criar valor para o
cliente

Proposição de Valor

Proposições a serem
atendidas.
Que necessidades,
do público-alvo a que
se destina meu
negócio, precisam
ser atendidas?

9

Ligação entre a
empresa e seus
clientes

3
Canais
Meio pelo qual uma
empresa fornece
produtos e serviços

Estrutura de Custos
Consequência monetária dos
meios utilizados no modelo de
negócio. (Despesas)

1
Segmentos de Clientes

O Públicoalvo para os
produtos e
serviços de
uma
empresa

Fluxos de Receita

5

A forma como a empresa
ganha dinheiro através de uma
variedade de fluxos de receita.


User Stories
Hi Paulo-I'm glad you've enjoyed those books. Many others teach classes based on those materials and
doing so is perfectly fine. Please note that I do own the copyright on the titles of those courses
so you'll need to call your classes something slightly different. Thank you for including
references to my work.
Good luck with your classes.

Mike Cohn

Regards,
Mike

Authorized


Software: O Filme


ard
onversation
onfirmation


Requisitos Abstratos e Concretos

Abstrato

Concreto

Verbo

Substantivo


Estrutura de uma User Story

Como um <PAPEL>
eu posso/gostaria/devo <FUNÇÃO>
para <VALOR DE NEGÓCIO>


Pagamento via Cartão de Crédito
Como um cliente, Eu gostaria de pagar
usando meu cartão de crédito para poder
parcelar minhas compras.
Observações:
- Aceitar Master Card, Visa e Amex
Restrições:
- Parcelar, no máximo, em 10x
- Cliente não pode estar no SPC


Estórias devem ser...

I ndepent
N egociable
V aluable
E stimable
S mall
T estable

Sempre que possível, preocupe-se em evitar criação
de dependências entre as estórias
Estórias são negociáveis. Elas não são contratos
requisitos que um software deve implementar.
As estórias devem ter um valor visível para quem está
comprando/pagando pelo produto
Os desenvolvedores devem ter condições suficientes
para estimar uma estória
Uma estória muito grande é difícil de estimar
complexa de desenvolver
As estórias devem ser testáveis


I

ndepent

•  Dependência entre estórias levam a problemas
na priorização e na estimativa;
•  Por exemplo: O cliente selecionou uma estória
de alta prioridade que tem uma outra estória
de baixa prioridade como dependente;
•  Outros exemplo:
–  Suponha que você tenha uma loja virtual e possui as
seguintes estórias no seu backlog:
1.  O cliente pode pagar usando cartão VISA;
2.  O cliente pode pagar usando cartão MasterCard;
3.  O cliente pode pagar usando cartão America Express;

–  Os desenvolvedores estimaram que a implementação
do primeiro cartão demoraria 3 dias;


N egociable
•  Cartões de estórias são descrições
pequenas da funcionalidade, bem como
alguns detalhes que precisam ser
negociados em conversa entre
desenvolvedores e cliente;
•  Exemplo:

O cliente pode efetuar pagamento com
cartão de crédito
Nota: Aceitar VISA, MarterCard e America Express


V aluable
•  Tenha em mente a diferença entre usuário
(alguém que usa o software) e comprador
(alguém que compra o software)
•  Muitos projetos possuem estórias que não são
valiosas para os usuários;
–  Ex: Toda a informação de configuração deve ser
lida de um servidor central;

•  Evite estórias que aparentam ter valor apenas
para os desenvolvedores:
Todos os erros e controle
de log devem ser tratados
por um conjunto comum
de classes

Todos os erros devem ser
apresentados aos
usuários de uma maneira
consistente

E stimable
•  É importante que os desenvolvedores sintam-se aptos a
estimar a estória (pelo menos um “chute”)
•  Existem pelo menos 3 razões que levam uma estória a
não ser estimada
–  O time não conhece o domínio de negócio;
•  Uma conversa é necessária com o cliente para sanar dúvidas.
Vale salientar que não é preciso entrar em detalhes de
implementação, mas os desenvolvedores precisam ter uma
ideia do que vão fazer;

–  O time não conhece a tecnologia a ser utilizada;
•  Tarefas “spike” podem ser criadas para pesquisar a tecnologia;

–  A estória é muito grande para ser estimada;
•  Neste caso, é importante que a estória seja “quebrada” em
outras estórias até que os desenvolvedores se sintam à
vontade para dar um chute;


S mall
•  O tamanho da estória é muito importante, pois as
estórias podem atrapalhar um planejamento caso
sejam grande ou pequenas demais;
•  Um grande indício para saber se a estória está em
um tamanho razoável é observar o time, suas
capacidades e a tecnologia em uso;
•  Estórias grandes são muito difíceis de serem
priorizadas;
•  Uma dica é definir fronteiras nas estivativas. Por
exemplo: Se você usa Planning Poker, pode definir
que uma estória ½ é muito pequena e uma estória
acima de 13 é muito grande;

½ - 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 ...


T estable
•  Estórias devem ser escritas de forma que
possam ser testadas;
•  Se uma estória não pode ser testada, como os
desenvolvedores podem saber quando
terminaram?
•  É comum estórias que implementam requisitos
“não funcionais” sejam escritas de forma que
não podem ser testadas:
–  Ex: “O usuário não deve esperar muito para a tela
de cadastro aparecer”

•  O melhor seria escrevê-la assim:
–  “A tela de cadastro deve aparecer em menos de 2
segundos em 95% dos casos”

TEMA
Gerenciamento de Emails

Gerenciamento de Contatos

Épico
Épico

Estórias com uma estimativa (Story Points) alta
Ex: Estórias com um tamanho 21, 34, ...

Épico vs Tema

História
História

Épico

História

História

História

História

História

História

História

Tema
História
História

História

História

História
História

História

História


Mapeamento de
estórias

Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)

BENEFÍCIOS OU SERVIÇOS OFERECIDOS
BACKBONE
FUNCIONALIDADES APLICAÇÃO
ESQUELETO DA DO SOFTWARE

DETALHAMENTO
DAS
FUNCIONALIDADES


O MAPA
•  Backbone:
–  Lista de atividades essenciais que
dão suporte à aplicação
–  Benefícios do produto
•  Esqueleto
–  É o software em construção que
atende a um número mínimo de
tarefas necessárias para abranger a
todo o ciclo de atividades do
usuário

TEMPO

IMPORTÂNCIA

MAIS IMPORTANTES OU ESSENCIAIS

MENOS IMPORTANTES OU DESCARTÁVEIS

Business Value,
Story Point e
ROI

#

Item

BV

%BV

Size

1

F1

1000

20%

13

76,92

7%

2

F2

500

10%

8

62,50

6%

3

F3

600

12%

5

4

F4

400

8%

21

5

F5

800

16%

3

266,67 24%

6

F6

500

10%

5

100,00

7

F7

900

18%

5

180,00 16%

8

F8

300

6%

1

300,00 27%

TOTAL

5000

61

ROI

%ROI

120,00 11%
19,05

2%

9%


Linha de corte do Backlog
A (13)
B (8)
C (5)
D (21)
E (3)
F (5)
G (5)
H (1)
I (3)
F (34)
F (21)
F (13)


Personas


Atores

Cadastrar

Clientes

Ator

Iteração

Caso de Uso


Personas
—  A criação de personas é uma

técnica utilizada para especificar
usuários com um determinado
perfil;
—  Esta técnicas personaliza o
software, fazendo com que pessoas
de perfis diferentes fiquem
satisfeitas com o produto;


Exemplo de Persona

Teovaldo é professor de História
com mais de 20 anos de
experiência. Sempre fez todas
as suas atividades de forma
manual e, apesar de não gostar
de computadores, fica fascinado
com a possibilidade de ganhar
tempo com tarefas
automatizadas por ferramentas
de software.


Contato

Paulo Furtado

paulofurtado.ti@gmail.com
@paulofurtadoti
www.aboutti.com.br


OBRIGADO!


Agile Requirements Workshop

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Agile Requirements Workshop

Semelhante a Agile Requirements Workshop (20)

Mais de Paulo Furtado

Mais de Paulo Furtado (6)

Último

Último (20)

Agile Requirements Workshop