Gomes Andre Faria - Agile стр 22.

Шрифт
Фон

3.8

Conhecendo os Usuários através de Personas

Personas são perfis baseados nos clientes e usuários do produto. A criação de per-

sonas ajuda a identificar Perfis de Clientes e Usuários importantes para o sucesso

do produto e a melhorar o entendimento, a comunicação e a tomada de decisão do

time sobre os diferentes usuários, de forma a otimizar suas funcionalidades para o

perfil do usuário final, e garantir que as necessidades de diferentes perfis sejam bem atendidas pelo produto em desenvolvimento.

Veja uma exemplo de persona na figura 3.7:

53

3.8. Conhecendo os Usuários através de Personas

Casa do Código

Figura 3.7: Persona

54

Casa do Código

Capítulo 3. Foco em Valor para o Negócio

Modelo para Criação de Personas

Não há uma forma certa ou errada de se desenvolver personas, mas

essas são algumas características comuns que podem ajudar o time a

compreender um perfil de usuário. Você pode escolher algumas dessas

para começar a desenvolver as personas de seu produto:

Nome

Papel

Valores

Objetivos

Problemas

Necessidades

Desejos

Expectativas

Preferências

Padrões de Comportamento

Casos de Uso

Atividades

Depois de criadas as personas do produto, é interessante associá-las às histó-

rias de usuário, para que o time saiba quem é o usuário interessado na história a

ser desenvolvida. É possível fazer isso tornando a persona explicita na descrição da história:

Como um contador eu gostaria de buscar os últimos lançamentos...

Como um gerentes de contas eu gostaria de atualizar o saldo...

Como um consumidor eu gostaria de...

55

3.9. Melhorando a Previsibilidade com Estimativas

Casa do Código

3.9

Melhorando a Previsibilidade com Estimativas

A estimativa permite que a equipe meça a produtividade e saiba quanto tempo será

necessário para concluir o desenvolvimento das histórias do projeto, além de ajudar o cliente a entender qual o custo do desenvolvimento de cada história e qual é a

média de tempo que será necessário para que a funcionalidade seja desenvolvida e

entregue.

Estimativas são complexas e não são precisas. Uma série de fatores devem ser

levados em consideração, entre eles, a maturidade da equipe em relação ao projeto e às tecnologias aplicadas nele.

É comum que no início do projeto funcionalidades de complexidades semelhan-

tes levam mais tempo para serem implementadas do que no final do projeto. Isso

ocorre

porque a equipe ganha produtividade à medida que aprende mais sobre o ne-

gócio e sobre a tecnologia utilizada. Assumindo essa premissa, é possível concluir

que a estimava de uma determinada história pode mudar ao longo do tempo.

É importante que todos os membros da equipe participem do processo de esti-

mar. Quando um desenvolver estima uma história sozinho, ele o faz com base em

suas experiências pessoais. Quando a estimativa é realizada em equipe, o expertise envolvido é muito maior e as chances de obter um resultado mais adequado também.

Uma das medidas mais comuns de estimativa são horas. A equipe indica quan-

tas horas serão consumidas para que uma funcionalidade seja implementada. No

desenvolvimento ágil, é mais comum utilizar pontos para realizar estimativas.

Pontos podem ter significados diferentes de acordo com cada equipe ou projeto.

Uma das formas, como recomendado no método XP, é quantificar um ponto como

sendo um dia ideal de trabalho, ou seja, um dia totalmente dedicado a realizar uma

tarefa, sem interrupções. Dessa forma, dois pontos seriam dois dias e assim por

diante.

Outra forma, recomendada pelo método Scrum, é utilizar pontos relacionados

ao esforço, em vez de tempo. Dessa forma, toma-se uma funcionalidade simples

como referência, por exemplo, o desenvolvimento de uma tela de cadastro, e assume-

se que essa referência vale dois pontos. Ao estimar outra tarefa avalia-se em quantas vezes mais fácil ou mais difícil em relação à referência é a história atual.

Outra técnica para tentar absorver a incerteza e falta de precisão das estimativas

é a utilização de intervalos, como a sequência de Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 ou uma sequência simplificada 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Assim, utiliza-se apenas os valores dentro da sequência para representar o esforço necessário para a implementação da história.

56

Casa do Código

Capítulo 3. Foco em Valor para o Negócio

No Scrum, utiliza-se o Planning Poker, ou Poker de Planejamento. Nesta téc-

nica cada membro da equipe recebe um conjunto de cartas com os valores de uma

sequência, como as descritas anteriormente. Em seguida todas as histórias são analisadas separadamente, e cada membro da equipe coloca uma carta sobre a mesa com

o número de pontos que considera que a história consumirá.

Quando houver grandes diferenças, as pessoas que jogaram as cartas de maior e

menor valor explicam suas razões para escolher aquele valor e, então, com base nas

explicações, as cartas são jogadas novamente até que um consenso seja encontrado

e a estimativa seja definida.

Ваша оценка очень важна

0
Шрифт
Фон

Помогите Вашим друзьям узнать о библиотеке