Histórias de Usuário - Especificação de Requisitos

Olá sejam bem-vindos ao canal engenharia de software com ênfase o ML Eu sou professor J Denis geds e eu já atuo na área de modelagem de software há vários anos eu tenho quatro vos publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos so modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema de especificação de requisitos dessa vez abordando histórias de usuário Então vamos iniciar nossa aula então na aula anterior eu comecei a falar sobre especificação de requisitos então nessa aula eu vou eh abordar

um tipo de de especificação de requisitos representado por histórias de usuário histórias de usuário não deixam de ser uma forma de especificação de requisitos ainda que simples eh muito esse esse tipo de especificação é muito popular dentro dos métodos ágeis Então vamos iniciar a nossa aula com uma pequena historinha do Gilbert ele vai falar sobre user histories ou histórias de usuário então o Dilbert é esse rapaz no canto esquerdo do quadrinho então aqui tá escrito Extreme programming porque foi na programação extrema no processo de desenvolvimento XP ou extreme programming que as histórias do usuário foram

criadas Então à direita tem uma parte interessada que apresenta uma lista de funcionalidades que ela deseja e o dber tá tá examinando essas essa lista e ele fala eu não posso te dar todas essas funcionalidades nessa primeira versão em inglês funcionalidades são normalmente representadas pela palavra features e ele acrescenta e cada funcionalidade precisa ter o que nós chamamos uma história de usuário e aí a parte interessada fala para ele ok aqui está uma história ou você me dá todas as minhas funcionalidades ou eu vou arruinar a sua vida então uma historinha para nós iniciarmos a

nossa aula bom então histórias de usuário são uma representação de requisitos funcionais uma representação simples mas com bastante conteúdo elas surgiram como eu falei no juntamente com processo de desenvolvimento XP ou extreme programming e portanto elas são usadas essencialmente métodos ágeis como o XP e o scrum Ah então os requisitos eles eram Originalmente e ainda são com muita frequência representados por cartões físicos pequenos cartões que continham uma frase e algumas poucas informações extras como por exemplo quem pediu Ah o nível de prioridade da história a estimativa para desenvolvê-lo possível possíveis testes Associados a ela esse

tipo de coisa então as histórias de usuário elas comprovadamente elas geram envolvimento do cliente porque as esses cartões eles criam um vínculo psicológico com as partes interessadas uma vez que elas passam a ter um comprometimento maior e conseguem pensar melhor sobre as suas necessidades então há um maior comprometimento o usuário as partes interessadas elas se envolvem mais na definição dos requisitos utilizando histórias usuários então isso ailia a as partes interessadas a especificarem as suas necessidades E priorizarem essas necessidades bom ah vamos falar um pouquinho sobre as estruturas mais comuns das histórias do usuário podem existir

outras estruturas essas duas são as mais comuns então normalmente uma história de usuário tem uma dessas duas estruturas a primeira como um a um determinado papel ou seja como um determinado tipo de usuário pode ser um gerente um v um um cliente um desenvolvedor esse tipo de coisa como um determinado papel eu quero atingir determinado objetivo de tal forma que ou para que eu atinja um determinado benefício obtenha um determinado benefício uma outra forma de escrever de histórias de usuário é representado aqui embaixo onde se começa a história com para atingir um determinado benefício como

um determinado papel devo poder atingir determinado objetivo devo poder realizar determinado objetivo bom Aqui nós temos alguns exemplos relacionados ao sistema de controle de encomendas Então como cliente quero acompanhar a situação da minha encomenda em tempo real para que eu possa saber onde ela está outra Como funcionário de Logística da filial queer as encomendas automaticamente no sistema de maneira a permitir a otimização das rotas e facilitar o carregamento e descarregamento como gerente de encomendas uma terceira história um terceiro exemplo como gerente de encomendas desejo gerar relatórios de desempenho de entrega para monitorar a eficiência das

entregas tanto das filiais quanto das das distribuidoras parceiras um quarto exemplo Como funcionário de Logística da distribuidora parceira quero atualizar a situação de entrega das encomendas no sistema em tempo real para garantir que o cliente e o sistema Central estejam atualizados e finalmente como cliente quero receber notificações de qualquer alteração na situação de entrega da minha encomenda para que eu possa ajustar meu planejamento caso ocorra um atraso ou entrega antecipada então alguns exemplos de histórias de usuário ah as histórias de usuário elas não deixam de ser também uma forma de converter E resumir cenários então

por exemplo aqui nós temos um cenário um usuário percebe que acentuou incorretamente uma palavra em todo seu documento Então usa o processador de texto para procurar de substituir todas as ocorrências daquela palavra pela palavra correta traduzindo esse cenário numa história do usuário nós poderemos escrever como usuário quero procurar e substituir todas as ocorrências de uma palavra por outra de forma a corrigir um erro de digitação recorrente então o usuário é o papel o texto em azul procurar substituir todas as ocorrências de uma palavra por outra é o objetivo e corrigir um erro de digitação recorrente

é o benefício bom quem faz as história do usuário como eu falei anteriormente Quem deve fazer a história do usuário Quem deve escrever a história do usuário são as partes interessadas os desenvolvedores e talvez outros membros da equipe eles devem auxiliar devem ensinar e auxiliar as partes interessadas a escrever histórias Claras e seguindo o formato correto Por que as partes interessadas devem escrever as histórias porque isso permite que elas raciocinem melhor sobre a funcionalidade que elas desejam cria um vínculo psicológico com o quartão a no momento que elas o escrevem elas se sentem mais responsáveis

com relação a esse cartão consegue pensar mais se sentem mais obrigadas a formar conceitos vagos em conceitos Concretos e além disso o cartão passa a ser uma representação física do curso de desenvolvimento daquela história daquela funcionalidade Aqui nós temos um exemplo de cartão de história do usuário que foi tirado do livro do Scott w angler aliás ambler como estudante eu quero comprar uma um passe de estacionamento forma que eu possa dirigir até a escola e Aqui nós temos algumas outras informações a prioridade era must passou a ser should aqui nós percebemos que nós estamos utilizando

a técnica de priorização Moscou que já foi ensinada em outros vídeos e foi estimada essa história do usuário foi estimada em quatro pontos de história Ah então o cartão na frente ele costuma possuir Ah o identificador único daquela história o texto da história propriamente dita a prioridade que foi atribuída à história pelo cliente ou pela parte interessada e o custo ou estimativa que foi eh estabelecido pela equipe de desenvolvimento para conseguir concluir aquela história já atrás do cartão podem haver outras informações como por exemplo conversas associadas descrições adicionais requisitos Associados a elas à história ainda

testes que podem ser feitos sobre aquela história estabelecendo critérios de aceitação Ah qual é o comportamento esperado no caso de erros coisas desse tipo e também outras informações opcionais mas que podem ser bastante úteis como estabelecer quem é o dono da história ou seja quem pediu a história e o seu contato e a data que a história foi criada o que isso permite isso permite rastreabilidade para trás isso permite determinar quem pediu quando pediu e eventualmente por foi pedido o porque eu consigo determinar eh na parte da frente do cartão no benefício que se espera

isso permite eh cobrar responsabilidades uma vez que eu sei quem pediu eu vou atrás essa pessoa e pergunto por que tu pediu essa história se essa história ainda está válida e eu consigo determinar o porquê dela ter sido ã solicitada ã Aqui nós temos uma representando as características de uma boa história de usuário que é representado pela sigla Invest Invest representa as seis características de uma história de usuário ou seja uma história de usuário precisa ser independente negociável valiosa estimável pequena e testável vamos falar um pouquinho sobre cada uma dessas características então com relação a

independência toda a história precisa ser independente das demais então ela deve ser ela isso permite que ela seja desenvolvida e testada de maneira isolada e evita que ela dependa de outras histórias seja que outras histórias sejam concluídas e isso e que e essa dependência pode atrasar o trabalho o desenvolvimento da história propriamente dita Ah uma história ela tem que ser negociável ou seja ela pode sofrer modificação em termos de prioridade em termos de objetivo em termos n n formas de de de negociação ela pode ser diminuída por exemplo então uma boa história de usuário ela

pode ser Ela deve ser aberta a discussões e É pode ser e e deve permitir que ela possa ser refinada essas discussões Elas costumam ocorrer entre o product aer ou seja o representante das partes interessadas E a equipe de desenvolvimento eh o producer normalmente Pode ser um executivo ou um usuário chave que tem conhecimento sobre o domínio do problema é ele que estabelece a o produto de backlog ou seja o conjunto de funcionalidades que ã fazem parte deverão ser eh atendidas pelo sistema também é ele que dá a Palavra Final sobre o Sprint backlog ou

seja quais funcionalidades eh serão desenvolvidas em um determinado Sprint Ah ele faz parte da equipe o produto faz parte da equipe mas ele não é um desenvolvedor ele é um usuário com conhecimento e ou a autoridade para ã estabelecer as funcionalidades do sistema e tratar com as outras partes interessadas então uma boa história de usuário ela deve ser aberta a discussões deve ser possível refin e essas discussões e refinamentos ocorrem entre o produto de aer E a equipe de desenvolvimento ela não pode se tornar um um requisito rígido ela tem que ser aberta à mudanças

isso permite que a história possa ser adaptada no momento que houverem mudanças de necessidad surgirem novas ideias esse tipo de coisa uma história ela precisa ser valiosa isso significa que ela precisa agregar valor aos usuários finais e ou ao cliente o que justificaria o esforço de seu desenvolvimento então a equipe ela se concentra em tarefas que impactam positivamente o produto e a experiência do usuário ainda uma boa história ela é estimável eu preciso ser capaz de determinar quantos pontos de história aquela história eh vai eh necessitar quanto ponto quantos post histórias serão necessários necessários para

implementar aquela história então para isso a história precisa ser Clara e detalhada para que possa ser feita essa Estimativa de esforço se eu não consigo estimar quanto tempo eu vou levar para desenvolver uma história então Então essa história ela pode ser uma história Épica pode ser uma história grande demais ou uma história vaga demais que Possivelmente precisará ser dividida ou melhor refinada uma história de usuário ela deve ser pequena ou seja ela precisa ser eh suficientemente pequena para que possa ser concluída dentro de um ciclo de interação em um Sprint por exemplo se estiver se

estivermos utilizando scrum então isso impede que a história ela ocupe várias iterações e aumenta a a capacidade de entregar valor continuamente Finalmente uma boa história de usuário ela precisa ser testável então cada história deve ter seus critérios de aceitação Claros O que permite que a equipe determine se a funcionalidade realmente atende ao objetivo ao qual ela se destina inava e isso aumenta a confiabilidade e qualidade do sistema a aumenta a satisfação do cliente e permite validar o que foi implementado garantir que realmente aquela história ela atende o que foi solicitado O Que Foi estabelecido falar

rapidamente sobre histórias épicas histórias épicas são histórias grandes demais que H muitas vezes precisam ser divididas em histórias menores então Aqui nós temos o exemplo temos uma história para um sistema de reserva de viagens Então como um comprador eu quero poder planejar minhas férias para me divertir com a família bom Aqui nós temos alguns problemas com essa história eh Quanto tempo se demora para implementar essa funcionalidade é muito difícil estabelecer isso porque a história tá Ampla demais planejar minhas férias é algo muito amplo quantas tarefas estão envolvidas nisso é difícil saber isso é realmente um

requisito de sistema essa é uma história Épica na verdade ela precisa ser dividida em histórias menores ela não satisfaz a o requisito investe ou seja ela não tem as características de uma boa história de usuário então eh falar um pouquinho sobre Estimativa de histórias as histórias elas precisam ser estimadas em Pontos de história ou his points ah pela equipe de desenvolvimento se isso não é possível então a história ela apresenta problemas ela pode ser uma história Épica ou ainda falta informações sobre ela ela precisa ser melhor detalhada Possivelmente melhor refinada talvez dividida em histórias menores

então Eh um ponto de história é uma medida eh de estimativa mas ela essa medida ela não é vamos dizer assim H totalmente estabelecida ela não é rígida é uma medida bastante flexível e essa medida ela varia de instituição para instituição de equipe para equipe ou de projeto para projeto então um ponto de história pode ser equivalente a um dia ideal de trabalho de um desenvolvedor ou ao custo de uma pequena história que serve como base como referência ou o que não é recomendado uma hora de trabalho por exemplo ah depois que as histórias elas

foram estimadas então elas devem ser priorizadas pelas partes interessadas então aqui pode se aplicar técnicas de priorização como por exemplo a técnica mosc que já foi ensinada em uma outra aula e nós concluímos essa breve introdução sobre histórias do usuário eu espero que vocês tenham achado essa aula útil eso que vocês tenham gostado desse vídeo Se vocês gostaram desse vídeo eu peço que vocês curtam esse vídeo compartilh com quem possa ter interesse nesse assunto e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas