About Thinking Innovation
Workshop de
Requisitos Ágeis
Paulo Furtado
2014

Dinâmica (30 min)
About Thinking Innovation

Onde tudo começou
100%
Média
de
uso
de
funcionalidades
de
sistemas
80%
7%
60%
Falhou
40%
Desafiado
13%
16%
Sucesso
2000
2002
2004
2007
2009
20%
0%
45%
19%
About Thinking Innovation

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
About Thinking Innovation

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.
About Thinking Innovation

Antes de começar
Conceitos
Iniciais
About Thinking Innovation

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?
About Thinking Innovation

O que é Análise de Requisitos?
Análise ou levantamento
de requisitos é a ação de
identificar necessidades
de usuários/clientes.
About Thinking Innovation

ATENÇÃO!!!
Análise ou levantamento
de requisitos não é
documentar e/ou
especificar requisitos, mas
identificar o que realmente
são os requisitos.
About Thinking Innovation

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.”
About Thinking Innovation

1º passo
Foco no
Usuário/Cliente
About Thinking Innovation

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

Problema pior…
“O cliente, muitas vezes,
também não percebe que
está gastando dinheiro”
About Thinking Innovation

O Cliente é responsável, mas
como dizer isso a ele?
R$ 500.000,00
Quinhentos mil reais
About Thinking Innovation

Lição #1
Um Team Guider
valoriza o dinheiro
gasto para fazer um
software
About Thinking Innovation

O valor dos requisitos é RELATIVO
Contexto é importante
About Thinking Innovation

Lição #2
Um Team Guider o
conhece o contexto
do produto
About Thinking Innovation

O Requisito fácil e simples pode ser
ESSENCIAL.
About Thinking Innovation

Lição #3
Um Team Guider
sabe a diferença
entre um par de
brincos e uma
escova de dentes
About Thinking Innovation

Quality is personal!
Jim
Highsmith
Agile
Consultant
About Thinking Innovation

Lição #4
Um Team Guider
define, para o seu
time, o conceito de
qualidade
About Thinking Innovation

Escolha um cenário...
O Time
O PO
+
+
?
=
?
=
About Thinking Innovation

Lição #5
Um Team Guider
sabe onde quer
chegar
About Thinking Innovation

Delegando poderes
About Thinking Innovation

Lição #6
Um Team Guider
deve ter poderes de
decisão e isso deve
ficar claro para
TODOS
About Thinking Innovation

O Cliente é tratado como Cliente!
About Thinking Innovation

Lição #7
Um Team Guider
faz TEST DRIVE o
tempo inteiro.
About Thinking Innovation

Pergunta:
E qual a diferença
entre um Team
Guider e um
Owner ?
About Thinking Innovation

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

Administrando Expectativas
Fonte: Software Requirement 3 (Karl Wiegers, Joy Beatty)
About Thinking Innovation

Interseção de Responsabilidades
Pessoas de
Negócio
Equipe de
Desenvolv.
Facilitadores
About Thinking Innovation

Definindo uma
visão
About Thinking Innovation

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;
About Thinking Innovation

About Thinking Innovation

About Thinking Innovation

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.
About Thinking Innovation

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.
About Thinking Innovation

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
About Thinking Innovation

Software: O Filme
About Thinking Innovation

ard
onversation
onfirmation
About Thinking Innovation

Requisitos Abstratos e Concretos
Abstrato
Concreto
Verbo
Substantivo
About Thinking Innovation

Estrutura de uma User Story
Como um <PAPEL>
eu posso/gostaria/devo <FUNÇÃO>
para <VALOR DE NEGÓCIO>
About Thinking Innovation

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
About Thinking Innovation

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
About Thinking Innovation

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;
About Thinking Innovation

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
About Thinking Innovation

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
About Thinking Innovation

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;
About Thinking Innovation

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 ...
About Thinking Innovation

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”
About Thinking Innovation

About Thinking Innovation

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
About Thinking Innovation

Mapeamento de
estórias
About Thinking Innovation

About Thinking Innovation
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
About Thinking Innovation
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)

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
About Thinking Innovation

TEMPO
IMPORTÂNCIA
MAIS IMPORTANTES OU ESSENCIAIS
MENOS IMPORTANTES OU DESCARTÁVEIS
About Thinking Innovation
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)

Business Value,
Story Point e
ROI
About Thinking Innovation

#
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%
About Thinking Innovation

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)
About Thinking Innovation

Personas
About Thinking Innovation

Atores
Cadastrar
Clientes
Ator
Iteração
Caso de Uso
About Thinking Innovation

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;
About Thinking Innovation

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.
About Thinking Innovation

Contato
Paulo Furtado
paulofurtado.ti@gmail.com
@paulofurtadoti
www.aboutti.com.br
About Thinking Innovation

OBRIGADO!
About Thinking Innovation