levantamento Ágil de requisitos

Disciplina

Levantamento Ágil de Requisitos

Prof. Msc. Paulo Furtadopaulofurtado.ti@gmail.com

@paulofurtadoti

2013

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

Obrigado!

Prof. Paulo Furtadopaulofurtado.ti@gmail.com

@paulofurtadoti