requisitos ageis paulofurtado_2014

About Thinking Innovation

Workshop de Requisitos Ágeis

Paulo Furtado 2014


Dinâmica (30 min)


Onde tudo começou

0%

20%

40%

60%

80%

100% 2000

2002

2004

2007

2009

Falhou

Desafiado

Sucesso

7% 13%

16%

19%

45%

Média de uso de funcionalidades de sistemas


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:

Processos e ferramentas Indivíduos e interações

Seguir um plano Resposta à mudanças

Documentação abrangente Software que funciona

Negociação de contrato Colaboração do cliente

mais que

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 auto-organizáveis.

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


Conceitos Iniciais

Antes de começar


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.”


Foco no Usuário/Cliente

1º passo


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”


R$ 500.000,00 Quinhentos mil reais

R$ 500.000,00 R$ 500.000,00

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


Um Team Guider valoriza o dinheiro gasto para fazer um

software

Lição #1


O valor dos requisitos é RELATIVO

Contexto é importante


Um Team Guider o conhece o contexto

do produto

Lição #2


O Requisito fácil e simples pode ser ESSENCIAL.


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

escova de dentes

Lição #3


Quality is personal! Jim Highsmith Agile Consultant


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

qualidade

Lição #4


Escolha um cenário...

+

+

=

=

? ?

O Time O PO


Um Team Guider sabe onde quer

chegar

Lição #5


Delegando poderes


Um Team Guider deve ter poderes de decisão e isso deve

ficar claro para TODOS

Lição #6


O Cliente é tratado como Cliente!


Um Team Guider faz TEST DRIVE o

tempo inteiro.

Lição #7


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

Owner?

Pergunta:


Um Product Owner banca o produto e, eventualmente,

guia o time

Um Team Guider guia o time e, eventualmente, banca o

produto.

Resposta:


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.


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

1 2

3

4

5

6

7 8

9


User Stories

Mike Cohn Authorized

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


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 N V E S T

ndepent egociable aluable stimable 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 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;

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

Épico

Épico

Gerenciamento de Emails

Gerenciamento de Contatos

Estórias com uma estimativa (Story Points) alta Ex: 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

Tema História História História

História História História História História


Mapeamento de estórias

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


T E M P O IM

PO

RT

ÂN

CIA

MAIS IMPORTANTES OU ESSENCIAIS

MENOS IMPORTANTES OU DESCARTÁVEIS


Business Value, Story Point e

ROI


# 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


Linha de corte do Backlog

A (13)

B (8)

C (5)

F (5)

G (5)

H (1)

I (3)

D (21)

E (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.


Paulo Furtado [email protected]

@paulofurtadoti

www.aboutti.com.br

Contato


OBRIGADO!

requisitos ageis paulofurtado_2014

Education