00:00:01
Olá, eu sou Caroline
00:00:03
e na lição de hoje vamos falar das histórias de usuário.
00:00:06
O objetivo dessa lição é explicar
00:00:08
o que são as histórias de usuário,
00:00:11
mostrar a forma de uso,
00:00:14
mostrar formas distintas de avaliar
00:00:16
a qualidade delas
00:00:17
e suas vantagens e desvantagens.
00:00:20
O que são as histórias de usuário?
00:00:23
As histórias de usuário são representações
00:00:25
de requisitos ou funcionalidades
00:00:28
que os clientes solicitam para atender os objetivos
00:00:30
de negócio.
00:00:32
Geralmente são escritas em uma ou duas frases
00:00:35
usando uma linguagem comum do usuário.
00:00:37
As histórias de usuário são usadas em
00:00:39
metodologias ágeis de desenvolvimento para
00:00:42
especificação de requisitos.
00:00:45
Acompanhada de debates com os usuários
00:00:47
e os testes de validação.
00:00:50
Normalmente, as histórias dos usuários
00:00:53
devem ser escritas em um cartão
00:00:55
por limitar a quantidade de escrita
00:00:57
que pode ser colocada nele,
00:00:59
forçando o cliente a produzir um texto claro
00:01:01
e objetivo.
00:01:03
No entanto, muitas empresas utilizam
00:01:05
modelos pré-concebidos para escrever estes.
00:01:09
As histórias do usuário têm que ser escritas
00:01:12
de forma que respondam 3 questões
00:01:14
relacionadas com as necessidades dos clientes.
00:01:16
Estas são:
00:01:18
Quem é beneficiado?
00:01:21
Usuário/ator que é beneficiado pela história de usuário.
00:01:25
O que se deseja?
00:01:27
A descrição da necessidade.
00:01:30
E qual é o benefício?
00:01:32
O valor de negócio que a história proporciona.
00:01:36
Uma equipe da Connextra desenvolveu em 2001 o
00:01:39
modelo tradicional de escrita de uma história de usuário.
00:01:43
O formato é o seguinte:
00:01:45
Como papel eu quero algo
00:01:47
para me beneficiar
00:01:49
Por exemplo,
00:01:50
Como um operador do hotel,
00:01:53
eu quero estabelecer taxas ótimas para
00:01:55
os quartos do meu hotel
00:01:57
para maximizar meus ingressos.
00:02:01
Como vice-presidente de marketing e vendas,
00:02:04
eu quero rever o desempenho histórico de vendas
00:02:07
para identificar regiões geográficas
00:02:10
e produtos de melhor desempenho.
00:02:13
Outros exemplos são:
00:02:15
Como cliente, eu quero consultar o catálogo
00:02:18
para poder encontrar o produto que desejo comprar.
00:02:23
Como cliente, quero que o produto seja acompanhado
00:02:26
com o valor de desconto para compra à vista
00:02:29
para que eu tenha a visibilidade da diferença
00:02:31
monetária do produto à vista ou à prazo.
00:02:35
Como cliente, quero que os produtos selecionados para
00:02:38
compra fiquem armazenados como um carrinho
00:02:41
de compras para que eu possa visualizar
00:02:43
todos os meus produtos e o preço total.
00:02:47
Existem várias maneiras de avaliar a qualidade
00:02:51
das histórias do usuário.
00:02:52
Para esta apresentação,
00:02:53
vamos falar de duas maneiras.
00:02:57
A primeira, é a fórmula dos três Cs.
00:03:00
Foi proposta por Ron Jeffries em 2001
00:03:03
e diz que uma história de usuário
00:03:05
cumpre bem o seu papel
00:03:07
quando atende às 3 características C
00:03:09
que são:
00:03:12
O primeiro C é cartão.
00:03:14
As histórias são tradicionalmente escritas
00:03:16
em cartões.
00:03:18
A ideia é que elas sejam suficientemente
00:03:20
pequenas para não exceder o tamanho de um cartão.
00:03:25
O segundo C é conversação.
00:03:27
Que é a discussão que o cliente
00:03:29
e o time de desenvolvimento
00:03:31
tem em torno das histórias para dar um
00:03:33
entendimento comum da funcionalidade a ser entregue.
00:03:38
E o terceiro C é Confirmação.
00:03:41
É confirmar que a aplicação sendo desenvolvida
00:03:44
está de acordo com o que o cliente espera ter em
00:03:46
produção no futuro.
00:03:48
São os testes que verificam as histórias.
00:03:51
A segunda maneira de avaliar a qualidade
00:03:54
é por meio do critério INVEST.
00:03:57
Foi criado em 2003 por Bill Wake
00:04:00
como lembrete das características que uma boa história
00:04:02
com qualidade deve ter.
00:04:05
Uma boa história de usuário deve
00:04:06
deve cumprir com 6 atributos, que são:
00:04:11
Independente. A história do usuário deve ser
00:04:14
auto-suficiente, de uma forma que não há
00:04:17
nenhuma dependência inerente
00:04:19
em outra história do usuário.
00:04:22
Negociável. As histórias de usuário, até que elas sejam
00:04:26
partes de uma iteração, podem sempre ser alteradas
00:04:29
e reescritas.
00:04:32
Valiosa. Uma história de usuário deve entregar
00:04:35
valor para o usuário final.
00:04:39
Estimável. Você deve sempre ser capaz
00:04:42
de estimar o tamanho de uma história de usuário.
00:04:46
Pequena. Histórias de usuários não devem ser tão
00:04:50
grandes a ponto de se tornar impossível de planejar
00:04:52
ou priorizar com um certo nível de certeza.
00:04:56
E testável. A história de usuário ou a sua descrição
00:05:00
relacionada deve fornecer as informações necessárias
00:05:04
para tornar o teste de desenvolvimento possível.
00:05:08
Outro conceito importante para saber quando se fala
00:05:11
sobre história de usuário é o conceito de Épicos.
00:05:15
Épicos são histórias de usuário que são grandes
00:05:19
demais para implementar em uma só iteração.
00:05:21
Portanto, você vai precisar dividir em histórias
00:05:24
de usuários menores
00:05:26
Por exemplo, temos a história de usuário:
00:05:29
O usuário pode pesquisar vagas de emprego.
00:05:33
Mas essa história pode se dividir em histórias menores.
00:05:37
O usuário pode pesquisar vagas de emprego por
00:05:40
localização, faixa salarial, título de vaga,
00:05:44
nome da empresa e data na qual a vaga foi publicada.
00:05:50
O usuário pode visualizar informações de cada vaga
00:05:53
que foram encontradas pela pesquisa.
00:05:56
O usuário pode visualizar informações
00:05:59
detalhadas sobre a empresa que publicou a vaga.
00:06:03
Para uma história de usuário ser executada
00:06:05
em uma iteração, ela deve ser primeiro
00:06:08
pequena o suficiente para que possa ser
00:06:11
concluída dentro da iteração.
00:06:13
Para isso ser possível, precisamos dividir uma história
00:06:16
grande em partes menores,
00:06:18
mas ainda preservando a propriedade que cada história
00:06:21
deve ter.
00:06:23
Isto é o que se conhece como Splitting.
00:06:29
Dentro das vantagens das histórias de usuário,
00:06:31
nós temos:
00:06:33
Criar histórias de usuário é fácil.
00:06:35
Histórias de usuário são rápidas e fáceis de escrever.
00:06:39
Os clientes com nenhuma experiência em
00:06:41
desenvolvimento de software podem escrevê-las
00:06:43
facilmente para comunicar seus objetivos.
00:06:47
Não é investido muito tempo ou dinheiro
00:06:49
para escrevê-las. Portanto, se elas forem alteradas
00:06:52
ou nunca usadas, a equipe não perdeu muito tempo
00:06:55
no seu desenvolvimento.
00:06:58
Elas são escritas pelos usuários.
00:07:01
As histórias de usuário são idealmente
00:07:03
descritas pelo usuário,
00:07:04
o cliente, na maioria dos casos.
00:07:07
Isso permite que a equipe de desenvolvimento
00:07:10
possa passar um tempo com o usuário
00:07:12
e entender melhor a funcionalidade que eles querem.
00:07:15
Se um cliente não se sente confortável ao escrever as
00:07:18
histórias de usuário, a equipe de desenvolvimento
00:07:21
pode intervir e ajudá-los
00:07:23
permitindo uma melhor compreensão do que
00:07:25
o produto final tem que realizar.
00:07:29
Priorização. O cliente é capaz de priorizar
00:07:32
em suas histórias de usuários formuladas
00:07:35
quais das ideias são mais importantes
00:07:37
para o desenvolvedor.
00:07:39
E as tarefas podem ser divididas em elementos
00:07:41
para uma melhor estimativa.
00:07:44
Por outra parte, as histórias de usuário não são uma
00:07:47
documentação detalhada.
00:07:49
Mas também não é este seu objetivo.
00:07:51
Histórias de usuário tem que servir como um ponteiro
00:07:54
para o que será a especificação de requisitos.
00:07:59
É um desafio documentar os requisitos não funcionais
00:08:02
como histórias de usuário.
00:08:04
Quando se faz uso das histórias de usuário para
00:08:06
redatar requisitos não funcionais,
00:08:09
a história vai ficar ambígua
00:08:11
ou incompleta.
00:08:12
Porque o principal objetivo é a documentação
00:08:14
de requisitos funcionais.
00:08:17
E podem não ser adequadas para ambientes
00:08:19
muito burocráticos ou quando
00:08:21
o nível de documentação é imposto pelo cliente.
00:08:25
Por exemplo, quando o cliente tem regras ou leis que o
00:08:28
obrigam a seguir certos passos para
00:08:30
documentação de requisitos.
00:08:34
Como visto, as histórias de usuários são requisitos
00:08:36
escritos em uma ou duas frases usando uma
00:08:40
linguagem comum do usuário.
00:08:42
Geralmente devem ser escritas em um cartão.
00:08:45
No entanto, muitas empresas utilizam
00:08:47
modelos pré-concebidos para escrever estes.
00:08:50
O formato mais comum de uma história de usuário
00:08:53
tem que responder às três perguntas
00:08:56
quem é o ator, o que ele quer e para quê que ele quer isso.
00:09:01
Uma boa história de usuário tem que seguir
00:09:04
critérios de qualidade.
00:09:06
Seja, por exemplo, a fórmula dos 3 Cs
00:09:08
ou o critério INVEST.
00:09:11
Por último, elas não são uma série altamente
00:09:13
documentada de requisitos,
00:09:15
mas sim um lembrete para colaborar
00:09:17
sobre o tema da história de usuário,
00:09:19
quando se define a especificação de requisitos.
00:09:22
Quero agora convidá-lo a realizar os exercícios
00:09:24
de fixação dos assuntos aqui discutidos.
00:09:28
E que também interaja com nossa equipe de tutores
00:09:30
no fórum de discussão deste tópico.
00:09:33
Seja para tirar dúvidas ou obter informações sobre o tema.
00:09:36
Estamos sempre à disposição para te ajudar.
00:09:38
Muito obrigada e bons estudos!
