levantamento Ágil de requisitos
DESCRIPTION
Materia disponibilizado no treinamento de Levantamento Ágil de Requisitos de SoftwareTRANSCRIPT
Levantamento Ágil de Requisitos
Apresentações
Professor Turma Disciplina
2
A Turma
1. Quem é você?
2. Onde trabalha?
3. Por que está fazendo este curso?
A DisciplinaO que é? O que não é?
Não é uma disciplina que vai te ensinar uma receita de bolo para fazer levantamento de requisitos;
Não é uma disciplina que vai dar um conjunto de modelo de artefatos para você usar como referência para fazer levantamento de requisitos
É uma disciplina que vai dar questionar a forma como hoje fazemos identificação de requisitos
É uma disciplina que trata a priorização como conceito-chave para o bom andamento do desenvolvimento
Bibliografia
Dúvidas?
? ?? ?
? ?? ?
?
? ? ?
Aula 01Conceitos Iniciais
Palavras-chave O que são Requisitos? O que é Agilidade Ruídos em
Levantamento de Requisitos
Gráfico de Funcionalidades
Processo Incremental e Iterativo
Levantamento
Ágil
Requisitos
Palavras-Chave
LevantamentoPalavras-Chave
1. Acto de levantar ou de levantar-se.2. Revolta; rebelião.3. Acto de levantar um cerco.4. Elevação.5. Aumento; acréscimo.6. [Topografia] Desenho da planta de um terreno, da carta de uma região, etc., depois de feitas as necessárias medições.7. Listagem ou recolha de informações.
Palavras-Chave
1. Que se move com facilidade e presteza.2. [Figurado] Vivo.
Atentem para as seguintes palavras:- Simplicidade;- Objetividade;- Priorização;- Adaptabilidade;
Ágil
Palavras-Chave
1. Coisa necessária e indispensável.2. Condição indispensável; exigência.3. Requerido; requisitado.
Requisitos
vs
Na minha visão, um software bem desenvolvido é...
+ =
Funcionalidades
7% 13%
16%
19%
45%
Média de uso de funcionalidades de sistemas
SempreFre-quente-menteÀs vezesRaramenteNunca
Standish Group, 2002
PROBLEMA:
“Nós temos a tendência de NÃO tratar o cliente de
software como um cliente que gasta dinheiro.”
R$ 500.000,00Quinhentos mil reais
vs
R$ 500.000,00R$ 500.000,00
O Cliente é responsável, mas como dizer isso a ele?
Nível de Ruídos em Projetos
Simples
Complicado
Anarquia
Complexo
Perto da certeza
Longe da certeza
Tecnologia
Perto deAcordo
Longe deacordoR
eq
ueri
men
tos
Fonte: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
“Software Requirements is
a Communication
problem.”Mike CohnUser Stories Applied
“Those who want the new software must communicate with those who will build the
new software.”
O valor dos requisitos é RELATIVO
Contexto é importante
Escolha um cenário...
+
+
=
=
?
?
O Cliente é tratado como Cliente!
Desenvolvimento Incremental e IterativoPensando um pouco...
PLANEJAMENTOPOR FASE
Requisitos
POR QUE NÃO...ITERAÇÕES?
Iteração 1 Iteração 2 Iteração N
...
Especific.Desenvol
vTestes Produção
Isso não é do jeito que eu
queria !!!
ENTREGA 1 ENTREGA 2
Mas... por quê mesmo precisamos investir em processos?
Ter mais produtividade?Aumentar a probabilidade
de sucesso nos projetos?Padronização de tarefas
frequentes?“Garantir” a qualidade do
software?
Jim HighsmithAgile Consultant
“Quality is personal”
Café Fracovs
Café Forte
Martin Fowler
"Para muitas pessoas, o surgimento das metodologias ágeis é uma
reação às metodologias de engenharia burocráticas. Entretanto, estas "novas"
metodologias visam ser uma forma útil entre ter nenhum processo e
muito processo, fornecendo processo suficiente para obter um
retorno satisfatório."
Conceitos Iniciais
Visão de Produto Evolução Processo Cognitivo
de aprendizado
Visão de ProdutoDefine 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 CanvasUsado 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ócioCriado 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.
Alianças de negócios que contemplam os outros aspectos do modelo de negócio
Principais Parceiros
Atividades necessárias para
executar o Modelo de Negócio
Principais Atividades
Recursos necessários para criar valor para o
cliente
Principais Recursos
Proposições a serem atendidas.
Que necessidades, do público-alvo a que
se destina meu negócio, precisam
ser atendidas?
Proposição de Valor Ligação entre a empresa e seus
clientes
Relac. com Cliente
Meio pelo qual uma empresa fornece
produtos e serviços
Canais
O Público-alvo para os produtos e serviços de
uma empresa
Segmentos de Clientes
A forma como a empresa ganha dinheiro através de uma variedade de fluxos de receita.
Fluxos de Receita
Consequência monetária dos meios utilizados no modelo de
negócio. (Despesas)
Estrutura de Custos
12
3
4
5
6
78
9
Desenhe um modelo de Negócio para um produto de Software utilizando o Business Model Canvas
(30 min)
O Que é isso?
A visão no ajuda a seguir um caminho
E se fosse assim?
O que você entende por...Evolução?
Nova fase em que entra uma ideia, um sistema, uma ciência, etc.
Desenvolvimento ou transformação gradual e progressiva (operada nas ideias, etc.).
Aprender com o Tempo
Processo Cognitivo?Capacidade de aprender e evoluir levando em
consideração a atenção, percepção, memória, raciocínio, imaginação, pensamento, discurso...
A comunicação é um dos maiores facilitadores no
processo de aprendizagem e evolução.
“Software Requirements is
a Communication
problem.”Mike CohnUser Stories Applied
“Those who want the new software must communicate with those who will build the
new software.”
Como facilitar a comunicação?Que tal aplicando/privilegiando o
uso de atividades cognitivas, ou seja, fazer com que as pessoas aprendam através da observação, percepção e comunicação?
No que se refere ao desenvolvimento de software, a criação/definição de papéis antes da identificação das funcionalidades é uma grande ajuda;
ExemploCompra de Tickets para a Copa 2014
Defina uma visão para um sistema de compra de Tickets para a copa de 2014. Obs: Lembre-se que a visão é uma frase que
sinalize o objetivo macro a que o sistema pretende alcançar. Qual o problema? O que pretende-se fazer? Quem Será beneficiado?
Que papéis você consegue identificar?Que requisitos poderiam ser identificados
para tal sistema?
15 min
Como descrever uma VisãoPara (cliente alvo)
Que (declaração da necessidade ou oportunidade)
O [nome do produto] é um [estratégia do produto]
Que (benefícios, boa razão para comprar)
Diferentemente (outras opções de produto)
Nosso produto (diferenças-chave)
User Stories O que é uma User
Story Estrutura de uma
User Story Escrevento User
Stories Estórias devem ser
INVEST Personas Epicos, Temas Release Planning
Mike CohnAuthorized
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.
Regards,Mike
Ron Jeffries(2001)
Criou o conceito dos 3 C’s
CCC
ard
onversation
onfirmation
O que é uma User Story?Descreve um requisito que é valioso para
um usuário ou comprador de um sistema de software;
Estórias levam em consideração 3 aspectos:Uma descrição escrita da estória para servir
como lembrete da funcionalidade;Conversações sobre as estórias para confirmar
os detalhes escritos na descrição;Testes que podem ser usados para determinar
quando uma estória está completa;
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 pagarusando meu cartão de crédito para poderparcelar 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
Pagamento via Cartão de Crédito
Critérios de Aceitação- Teste com MC, Visa e Amex válidos deve passar- Compra com outros cartões válidos não pode passar- Compra com cartões expirados não deve passar- Teste com CEP inválido deve bloquear pgto- Teste com CEP inválido deve bloquear pgto
Verso
Converta as funcionalidades que foram encontradas no sistema de compra de tickets para a Copa de 2014 em User Stories usando a seguinte regra:
15 min
Como um <PAPEL>
eu posso/gostaria/devo <FUNÇÃO>
para <VALOR DE NEGÓCIO>
ExemploCompra de Tickets para a Copa 2014
Estórias devem ser...
INVEST
ndepent
egociablealuablestimable
mall
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
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;
I ndepent
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:
N egociable
O cliente pode efetuar pagamento com cartão de crédito
Nota: Aceitar VISA, MarterCard e America Express
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:
V aluable
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
É 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 estimadaO 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;
E stimable
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 ...
S mall
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”
T estable
TEMAS E
ÉPICOS
Épico
Épico
Backlog
Gerenciamento de Emails
Gerenciamento de Contatos
Estórias com uma estimativa (Story Points) altaEx: Estórias com um tamanho 21, 34, ...
TEMA
Épico vs Tema
Épico
História
História História
História História História
História História História
TemaHistória História História
História História História História História
Estórias mal escritas!Quais os sintomas para saber se
uma estória:É pequena demaisÉ InterdependenteÉ GoldplatingPossui muitos detalhesDifícil de ser priorizada
Estória Pequena demaisSintoma:
Necessidade frequente de revisar as estimativas
Discussão:Esse problema ocorre quando uma história
influencia nas estimativas caso a ordem de implementação seja alterada
Estória InterdependenteSintoma:
Dificuldade de planejar as iterações devido às dependências entre as estórias
Discussão:Acontece quando uma estória que deve entrar
na próxima iteração precisa de uma outra estória que, por sua vez, precisa de uma terceira e que, por sua vez...
Estória pequenas demais ou mal “quebradas” fazem com que esse tipo de problema venha a ocorrer
Estórias GoldplatingSintoma:
Desenvolvedores adicionam funcionalidades que não foram planejadas e acabam implementando mais que o necessário
Discussão:Goldplating referem-se a funcionalidades
adicionais e desnecessáriasRazões
Desenvolvedores querem agradar o cliente Desenvolvedores querem fugir da pressão da iteração e
fazer outras atividades Desenvolvedores gostam de “colocar sua marca” no
projeto
Estória muito detalhadaSintoma:
Gasta-se muito mais tempo escrevendo os detalhes da estória que falando sobre ela
Discussão:Uma das vantagens em se utilizar cartões para
escrever estórias é que eles são limitados;Colocar muitos detalhes em uma história indica
que a documentação está sobrepondo a comunicação;
“Se você ficar sem espaço em um cartão, use um cartão menor” (Tom Poppendieck)
Estória difícil de ser priorizadaSintoma:
O cliente sente muita dificuldade de priorizar diversas estórias
Discussão:A primeira coisa a considerar é o tamanho das
estórias. Se elas são muito grandes, é muito difícil priorizá-las;
O seu valor de negócio não está claro.
Personas
Perfis de usuário(User Roles)Por que é importante definir diferentes perfis
de usuário?Você acha que, para um mesmo perfil de
usuário (ex: Professor, em um sistema acadêmico) temos características diferentes?
Cite alguns exemplos de aplicações com uma vasta gama de usuários;
Passos para criação de Perfis de UsuárioFazer um brainstorm para identificar o
conjunto de perfis iniciaisOrganizar o conjunto de perfis inicial;Consolidar os perfis;Refinar os perfis;
Atores
Cadastrar Clientes
Ator Iteração Caso de Uso
PersonasA 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.
Mapeamento de User Stories
Definindo o Backbone
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
BENEFÍCIOS OU SERVIÇOS OFERECIDOS
FUNCIONALIDADES DO SOFTWARE
DETALHAMENTO DAS
FUNCIONALIDADES
BACKBONE
ESQUELETO DA APLICAÇÃO
O MAPABackbone:
Lista de atividades essenciais que dão suporte à aplicação
Benefícios do produtoEsqueleto
É 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
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
T E M P O
IMPO
RTÂ
NC
IA
MAIS IMPORTANTES OU ESSENCIAIS
MENOS IMPORTANTES OU DESCARTÁVEIS
Mapeamento de User Stories
Site para procura e
oferta de empregos
Mapeamento de User StoriesHome PageHot jobs ads
Job hunting tips
Post ResumeResume data fields
Employer Entrance
Account Info
Search JobsSearch fields
Review Applicants
List of applicants
Post JobsJob description
fields
Resume ViewAll resume data
Job ResultsList of matching
jobs
Job DetailsAll job information
Que estórias podem ser identificadas?
Estórias identificadas para o site de empregos
Uma pessoa pode publicar seu currículoUm empregador pode publicar vagas de
trabalhoUm empregador pode revisar currículos
submetidosUma pessoa pode procurar por empregosUma pessoa pode visualizar resultados de
empregos de uma pesquisaUma pessoa pode visualizar detalhes sobre
empregos específicos
É interessante criar protótipos de baixa fidelidade para ajudar a entender as necessidades do usuário
Algumas perguntas que podem ser feitas para ajudar a identificar estórias “escondidas”:O que o usuário gostaria fazer em seguida?Que erros o usuário poderia cometer aqui?O que poderia confundir o usuário neste momento?Que informações adicionais seriam interessantes
para o usuário?Pense em perfis de usuário e Personas enquanto
faz estas perguntas
Mapeamento de User StoriesDicas
Priorização Dinâmica do Backlog Técnica MoSCoW Técnica Kano
A
B
C
Pro
du
ct B
ackl
og
F
G
H
I
D
Sprint 1P
rio
rid
ade
Alta
Baixa
E
Estórias
Relembrando a Dinâmica do Product Backlog
A priorizaçãoComo objetivo de lançar uma
release do produto, o cliente precisa priorizar as estorias;
Existe uma técnica descrita no DSDM (Dynamic Systems Development Method) que pode ser usada para facilitar o processo de priorizacão;
Esta técnica pode ser encontrada no livro Business Focused Development;
Esta técnica recebe o nome de MoSCow;
Priorização
MoSCoWMust Have
(Deve ter)
Funcionalidades fundamentais
para o sistema. Sem estas
funcionalidades o sistema não
tem valor para o cliente
Should Have(Deveria ter)
Funcionalidades importantes, mas existem alternativas a
curto prazo para elas
Could Have(Poderia ter)
Funcionalidades que podem ser “deixadas de lado” caso o
tempo do projeto esteja muito escasso
Won’t have(Não terá)
Funcionalidades que não serão feitas ou não
serão entregues na release planejada
# Item BV %BV Size ROI %ROI
1 F1 1000 20% 13 76,92 7%
2 F2 500 10% 8 62,50 6%
3 F3 600 12% 5 120,00 11%
4 F4 400 8% 21 19,05 2%
5 F5 800 16% 3 266,67 24%
6 F6 500 10% 5 100,00 9%
7 F7 900 18% 5 180,00 16%
8 F8 300 6% 1 300,00 27%
TOTAL 5000 61
Ruído em Projetos
Priorização KANOÉ uma das técnicas de priorização mais utilizadasRealizar perguntas direcionadas para um grupos
de usuários Você deve realizar uma pergunta funcional:
Como você se sentirá se o requisito estiver presente no produto?
Você deve realizar uma pergunta disfuncional:Como você se sentirá se o requisito NÃO estiver
presente no produto?Feito isso, você deve combinar as respostas e
colher as informações
Kano: ExemploTermômetro de temperatura em uma cerveja
em lataPergunta Funcional: Como você se sentirá
ao ver um termômetro de temperatura na latinha de cerveja?
Pergunta Disfuncional : Como você se sentirá em não ver um termômetro de temperatura na latinha de cerveja?
Kano: Exemplo
Legenda: A – Atrativos; D – Devem ser feitos; N – Não deve ser feitos;Q – Quanto mais melhor; I – Indiferente; ? – Questionável, o requisito ainda não está claro)
Kano: ExemploPergunta Funcional: Como você se sentirá ao ver um
termômetro de temperatura na latinha de cerveja?( ) Me Agradaria
( ) Quero que tenha
( ) Tanto faz
( ) Não Gostaria
Pergunta Disfuncional: Como você se sentirá a NÃO ver um termômetro de temperatura na latinha de cerveja?( ) Me Agradaria, desejo
( ) Quero que tenha, espero imagino
( ) Tanto faz, posso conviver sem isso
( ) Não Gostaria
XX
Kano: ResultadoApós efetuar o questionário a um grupo de 20 usuários, você
deve checar a resposta funcional e não funcional de cada um deles e chegar a um valor da tabela.
No exemplo anterior: Pergunta Funcional: Como você se
sentirá ao ver um termômetro de temperatura na latinha de cerveja? (Resposta: Me agradaria)
Pergunta Disfuncional: Como você se sentirá a NÂO ver um termômetro de temperatura na latinha de cerveja? (Resposta: Tanto faz)
Dessa forma, para este usuário, o valor obtido com o cruzamento da informações foi Atrativo (A)
Prototipação Sketch Mapas
Mentais
Métodos e Ferramentas de Engenharia
Bibliografia
95
ProtótipoDo latim, \proto\ ORIGINAL\ e \tipo\ MODELO.
Um tipo, forma ou exemplar original que serve como base ou padrão para futuros estágios de um projeto ou simplesmente: um exemplar inicial que comunica uma idéia.
Prototipação Processo iterativo, para a criação de protótipos que serve para rapidamente testar conceitos, produtos e negócios e trazer respostas a uma pergunta.
Dica...
Quanto mais cedo erramos, mais cedo
temos sucesso
Comunicação Visual
Visão Imagem
A comunicação visual é rápida, eficiente e simples.
Como fazer issoSketch (esboço)Protótipo
Técnica: SKETCH (esboço)
Sketch – características
Barato
Rápido
Direto
Pouco Detalhado Livre
Descartável
Sugestivo
Como nascem algumas aplicações...
Ferramentas para Sketch
Ferramentas para Sketch
Mapeamento de User StoriesHome PageHot jobs ads
Job hunting tips
Post ResumeResume data fields
Employer Entrance
Account Info
Search JobsSearch fields
Review Applicants
List of applicants
Post JobsJob description
fields
Resume ViewAll resume data
Job ResultsList of matching
jobs
Job DetailsAll job information
Que estórias podem ser identificadas?
Técnica: Mapa mentalDiagrama usado para
representar palavras, ideias, tarefas e outros itens ligados e dispostos ao redor de uma
palavra ou ideia central.
Mapa Mental
Mapas mentais são bons para...Visualizar ideiasRelacionamentos entre elementosBrainstorming, IdeaçãoTomar decisões a partir de anotações
Quebrar problemas em pedaçosOrganizar a mente
Fonte: Paolo Passeri – Técnicas de Prototipação
Dicas Melhores
práticas
Melhores Práticas1. Stakeholders actively participate2. Adopt inclusive models3. Model storm details just in time (JIT)4. Treat requirements like a prioritized stack5. Prefer executable requirements over static
documentation6. Your goal is to implement requirements, not
document them7. Recognize that you have a wide range of stakeholders8. Smaller is better9. Question traceability10. Explain the techniques11. Adopt stakeholder terminology12. Keep it fun13. Obtain management support14. Turn stakeholders into developers
