User Story (histórias de usuários) fazem parte de uma abordagem ágil que ajuda a mudar o foco de escrever sobre requisitos para falar sobre eles. Cada história ágil do usuário inclui uma ou duas frases escritas e, mais importante, desencadeia uma série de conversas sobre os recursos e funcionalidades que a história do usuário representa.
As histórias do usuário são uma maneira de descrever a funcionalidade desejada dos itens de lista de pendências do produto. Histórias de usuários de alta prioridade tendem a ser mais detalhadas; histórias de usuários de baixa prioridade tendem a ser menos detalhadas.
As equipes adicionam detalhes à medida que as histórias aumentam em prioridade, criando critérios de aceitação ou dividindo grandes histórias em pedaços menores ( ou ambos ).
O que é uma User Story?
Uma história de usuário é uma descrição curta e simples de um recurso contado da perspectiva da pessoa que deseja o novo recurso, geralmente um usuário ou cliente do sistema. As histórias do usuário geralmente seguem um modelo simples:
Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.
Historicamente, as histórias dos usuários eram deliberadamente mantidas informais, escritas em cartões de índice ou notas adesivas, armazenadas em uma caixa de sapatos e dispostas em paredes ou mesas para facilitar o planejamento e a discussão.
Sua impermanência facilitou rasgá-los, jogá-los fora e substituí-los por novas histórias, à medida que se aprendeu mais sobre o produto que está sendo desenvolvido.
Atualmente, as histórias dos usuários podem ser facilmente armazenadas em um problema de Jira ou no quadro de Trello.
Não deixe que o fato de uma história de usuário existir em uma ferramenta o torne menos disposto a descartar histórias quando elas não forem mais necessárias!
As histórias de usuários são projetadas para mudar fortemente o foco, da escrita de recursos para a discussão deles. De fato, essas discussões são mais importantes do que qualquer texto escrito.
O que é uma boa User Story?
As histórias ágeis dos usuários são compostas por três aspectos que Ron Jeffries nomeou em 2001 com a maravilhosa aliteração de cartão, conversa e confirmação:
- Cartão: Descrição escrita da história, usada para planejamento e como lembrete
- Conversa: Conversas sobre a história que servem para detalhar os detalhes da história
- Confirmação: Testes que transmitem e documentam detalhes que podem ser usados para determinar quando uma história está concluída.
As histórias de usuários têm muitas vantagens, mas o mais importante pode ser que toda história de usuário seja um espaço reservado para uma conversa futura.
Como escrever uma história de usuário
Escrever boas histórias de usuários no Scrum requer uma compreensão do modelo básico de história do usuário, um foco no usuário ou cliente e uma imagem clara da funcionalidade desejada.
Modelo de história do usuário
Ao escrever uma história de usuário, lembre-se de que as histórias de usuário seguem um modelo padrão:
Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.
Exemplos de histórias de usuários
Uma das melhores maneiras de aprender a escrever uma história de usuário em ágil é ver exemplos. Abaixo está um exemplo de história ou duas de usuário. Estes são alguns exemplos reais de histórias de usuários que descrevem a funcionalidade desejada em uma versão inicial do site da Scrum Alliance.
- Como membro do site, posso preencher um aplicativo para me tornar um instrutor certificado de scrum para poder ensinar e certificar outros Scrum Masters ( PSM ) e Product Owners ( PSPO ).
- Como treinador, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma, para que os possíveis participantes possam encontrar meus cursos.
- Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para poder acessar as coisas que me lembro do passado ou que outras pessoas mencionam para mim.
- Como visitante do site, posso ver uma lista de todos os próximos cursos de certificação “ ” e posso paginar por eles se houver muito, para que eu possa escolher o melhor curso para mim.
Observe que você não vê nenhuma história de usuário: “Como proprietário do produto, quero uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário / cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.
Quem escreve histórias de usuários?
Quem escreve histórias de usuários? Qualquer pessoa pode escrever histórias de usuários.
O proprietário do produto escreve histórias de usuários?
É responsabilidade do proprietário do produto garantir a existência de um acúmulo de histórias ágeis de usuários, mas isso não significa que o proprietário do produto seja quem as escreve. Ao longo de um bom projeto ágil, você deve esperar ter histórias de usuários escritas por cada membro da equipe.
Observe também que quem escreve uma história de usuário é muito menos importante do que quem está envolvido nas discussões.
Quando as histórias dos usuários são escritas?
As histórias dos usuários são escritas em todo o projeto ágil. Normalmente, um workshop de redação de histórias é realizado perto do início do projeto ágil.
Todos na equipe participam com o objetivo de criar um backlog do produto que descreva completamente a funcionalidade a ser adicionada ao longo do projeto ou um ciclo de lançamento de três a seis meses dentro dele.
Algumas dessas histórias ágeis de usuários serão, sem dúvida, épicas. Mais tarde, as épicas serão decompostas em histórias menores que se encaixam mais rapidamente em uma única iteração.
Além disso, novas histórias podem ser escritas e adicionadas ao backlog do produto a qualquer momento e por qualquer pessoa.
Você pode mostrar outros exemplos de user history?
Como um exemplo mais genérico de escrever histórias de usuários no Scrum, essas são algumas histórias típicas de usuários para um site de postagem e pesquisa de empregos:
- Um usuário pode postar seu currículo no site.
- Um usuário pode procurar empregos.
- Uma empresa pode postar novas vagas.
- Um usuário pode limitar quem pode ver seu currículo.
Como os detalhes são adicionados às user historys?
Os detalhes podem ser adicionados às histórias do usuário de duas maneiras:
- Dividindo uma história de usuário em várias histórias menores de usuário.
- Adicionando condições de satisfação: Critérios de aceitação ( ).
Quando uma história relativamente grande é dividida em várias histórias de usuários ágeis menores, é natural supor que os detalhes foram adicionados. Afinal, mais foi escrito.
As condições de satisfação são simplesmente um teste de aceitação de alto nível que será verdadeiro após a conclusão da história ágil do usuário. Considere o seguinte como outro exemplo ágil da história do usuário:
Como vice-presidente de marketing, quero selecionar uma temporada de férias a ser usada ao revisar o desempenho de campanhas publicitárias anteriores, para que eu possa identificar as lucrativas.
Detalhes podem ser adicionados a esse exemplo de história do usuário adicionando as seguintes condições de satisfação:
- Certifique-se de que funcione com as principais férias de varejo: Natal, Páscoa, Dia do Presidente, Dia das Mães, Dia dos Pais, Dia do Trabalho, Dia de Ano Novo.
- Suporte a feriados que abrangem dois anos civis ( nenhum intervalo três ).
- As estações de férias podem ser definidas de um feriado para o próximo (, como Ação de Graças ao Natal ).
- As estações de férias podem ser definidas para vários dias antes do feriado.
As user history substituem um documento de requisitos?
Projetos ágeis, especialmente os Scrum, use um backlog do produto, que é uma lista priorizada da funcionalidade a ser desenvolvida em um produto ou serviço. Embora produto itens de lista de pendências pode ser o que a equipe deseja, as histórias dos usuários surgiram como a melhor e mais popular forma de itens de lista de pendências de produtos.
Enquanto um atraso do produto pode ser considerado um substituto para o documento de requisitos de um projeto tradicional, é importante lembrar que a parte escrita de uma história de usuário ágil ( “ Como usuário, Eu quero … ” ) está incompleto até que as discussões sobre essa história ocorram.
Muitas vezes, é melhor pensar na parte escrita como um ponteiro para o requisito real. As histórias do usuário podem apontar para um diagrama que descreve um fluxo de trabalho, uma planilha mostrando como executar um cálculo ou qualquer outro artefato que o proprietário ou a equipe do produto deseje.
Vantagens do “ Como, quero, para, ”
“Como um , Eu quero, Para que que .” Embora eu considere a cláusula opcional, eu realmente gosto desse modelo. Em uma conferência, alguém me perguntou o porquê. Como recebo essa pergunta com bastante frequência, quero dar três razões pelas quais aqui:
Razão 1
Algo significativo e estou tentado a dizer que mágico acontece quando os requisitos são colocados na primeira pessoa. Obviamente, dizendo “Como tal e tal, eu quero …”, você pode ver como a mente da pessoa se move instantaneamente para imaginar que ela é uma pessoa assim. Quanto à mágica, Paul McCartney foi entrevistado e perguntado sobre por que as músicas dos Beatles eram tão incrivelmente populares. Uma de suas respostas foi que suas músicas foram as primeiras a usar muitos pronomes.
She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. Seu argumento era que isso ajudava as pessoas a se identificarem mais de perto com as músicas.
Você pode ler mais sobre o Uso de pronomes pelos Beatles neste artigo.
Razão 2
Ter uma estrutura nas histórias realmente ajuda o proprietário do produto a priorizar. Se o backlog do produto for uma mistura de coisas como:
- Entrega de exceção fixa
- Deixe os usuários fazerem reservas
- Os usuários querem ver fotos
- Mostrar opções de tamanho do quarto
… e assim por diante, o proprietário do produto precisa trabalhar mais para entender qual é o recurso, quem se beneficia e qual é o valor dele.
Razão 3
Ouvi um argumento de que escrever histórias com esse modelo suprime o conteúdo informativo da história, porque há muito texto comum. Se você achar isso verdade, corrija-o na maneira como apresenta a história. Vi atrasos no Word que apresentam o texto comum em texto acinzentado com as partes exclusivas em preto.
Criei backlogs de produtos no Excel que usam títulos de colunas para filtrar o texto comum.
Olhe aqui e verá o que quero dizer:
Sério, dê uma olhada na tabela acima antes de continuar … Eu vou esperar … Por favor, olhe para ela antes de ler mais.
OK, aqui está como eu aposto que você leu a planilha
Aposto que, ao ler a maioria das linhas que você adicionou no texto “Como um …”, “Eu quero …” e “para que então…”, possivelmente até olhando para o cabeçalho enquanto você lê em cada linha. Eu experimentei perguntando às pessoas, e é isso que a maioria das pessoas faz.
Se esse texto é desnecessário, por que mentalmente expressamos as palavras para nós mesmos ou até olhamos para o cabeçalho enquanto lemos a linha? Talvez não seja tão não essencial, afinal.
Por enquanto, e provavelmente por muito tempo, continuarei com o modelo “Como um …”, “Eu quero …” e “para que então…” por esses e outros motivos.
Por que o modelo de história de usuário de três partes funciona tão bem
Não há modelo mágico que deva ser usado para histórias de usuários. Eles podem ser escritos de várias maneiras. Mas a maneira mais popular de escrever histórias de usuários é com este modelo:
Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.
Esse modelo se originou com a treinadora ágil Rachel Davies em uma empresa inglesa, Connextra, no início dos anos 2000. Desde então, tornou-se um padrão reconhecido para expressar histórias de usuários.
Os três elementos do modelo padrão
Descrevi as três partes do modelo padrão de várias maneiras ao longo dos anos. No Livro Histórias de usuários aplicadas de Mike Cohn, ele descreve os três elementos desta maneira:
- Como um papel ( ), quero uma função ( ) para que ( valor comercial ).
Mais tarde, ele mudou para que ao se referir aos três elementos como papel, objetivo e razão. Por fim, decidiu apenas se referir a eles de maneira muito mais simples como quem, o quê e por quê. Os três elementos do endereço do modelo de história do usuário padrão:
- Quem quer a funcionalidade
- O que eles querem
- Por que eles querem
Vejamos cada uma dessas partes do modelo de história do usuário.
Quem: o primeiro elemento do modelo de história do usuário
Os usuários de um produto ou sistema típico geralmente podem ser categorizados. Como exemplo, estou digitando isso no Google Docs agora. Eu poderia ser considerado um usuário casual de Docs.
Não uso a maioria de seus recursos. Nunca cliquei no menu Complementos para ver o que há lá. Não faço muita formatação sofisticada porque a maior parte do que escrevo é movida para o meu site e é formatada lá. Então, vamos me chamar de Usuário casual.
Outros que usam esses recursos podem ser chamados Usuários de energia.
Normalmente, envio meus rascunhos de blog para um editor. E assim, Editor poderia ser outra função ao identificar os vários tipos diferentes de usuários do Google Docs.
Essas funções de usuário formam a primeira parte do modelo padrão de história do usuário. Portanto, alguém que desenvolve um processador de texto pode ter uma história de usuário de “ Como um usuário de energia, Eu quero um corretor ortográfico … ”
O que: o segundo elemento do modelo de história do usuário
A segunda parte do modelo padrão indica o que é desejado ou necessário. Isso é comumente declarado como “ eu quero …. ” De fato, durante anos minhas apresentações em conferências e outros treinamentos sobre histórias de usuários tiveram um slide dizendo “ Eu quero … ”
Acabei percebendo que isso era impreciso. Às vezes, a funcionalidade descrita não é algo que a função do usuário deseja. Por exemplo:
- Como membro, sou obrigado a inserir uma senha forte….
Nenhum usuário ( normal ) quer para inserir uma senha com muitos caracteres, três símbolos especiais, sem caracteres repetidos e pelo menos algumas letras maiúsculas. Na melhor das hipóteses, entendemos por que é necessário, mas pessoalmente prefiro que o sistema saiba magicamente que sou eu e deixe-me entrar.
Então, hoje em dia eu não incluo mais quer ao mostrar o modelo em cursos ou apresentações. Em vez de sempre ser eu quer, às vezes sou eu necessário, forçado, precisa ou mais.
Por que: o terceiro elemento do modelo de história do usuário
A parte final do modelo padrão é porque o usuário deseja que a funcionalidade seja descrita na história do usuário. Isso é fornecido após o para que parte do modelo. Por exemplo, uma versão totalmente expressa da história anterior do verificador ortográfico pode ser “ Como usuário de energia, quero um verificador ortográfico para não precisar me preocupar com erros ortográficos. ”
O para que a cláusula de uma história é importante porque entender por que um usuário deseja o que é descrito no o que parte da história ajuda a equipe a decidir qual a melhor forma de implementar a funcionalidade.
Como exemplo, não procure mais do que a nossa história de corretor ortográfico. Suponha que tenha sido fornecido a uma equipe sem uma cláusula simples: Como usuário de energia, quero um corretor ortográfico. Isso provavelmente levaria uma equipe a desenvolver o que eram todos os verificadores ortográficos iniciais: As ferramentas posteriores são executadas em um documento após a escrita.
Mas nosso usuário de energia não deseja um passo extra depois de terminar de escrever um documento. Em vez disso, o usuário de energia quer o que parece mais padrão hoje: correção em tempo real dos erros à medida que são cometidos. O que o usuário realmente deseja é dado pela cláusula: o usuário não quer se preocupar com erros de ortografia.
A cláusula ‘para que’ deve ser opcional?
Quando apresento histórias de usuários durante cursos presenciais, Muitas vezes me pedem para justificar minha visão aparentemente contraditória de que a cláusula é a parte mais importante de uma história, mas não deve ser obrigatória.
Não considero obrigatório porque, às vezes, simplesmente não agrega valor. Considere uma história sobre o login: Como membro, sou obrigado a fazer login.
Que cláusula você pode adicionar a essa história que agrega valor ou esclarece a intenção da história? Alguma dessas coisas realmente ajuda ou são apenas texto supérfluo adicionado para cumprir um modelo:
- Como membro, sou obrigado a fazer login para que somente eu possa acessar meus dados pessoais.
- Como membro, sou obrigado a fazer login para que outras pessoas não possam acessar meus dados pessoais, a menos que eu tenha fornecido minhas credenciais.
- Como membro, sou obrigado a fazer login para que o sistema saiba que sou eu.
- Como membro, sou obrigado a fazer login para que os hackers sejam mantidos de fora.
Enquanto eu não considero o para que cláusula obrigatória, eu escrevo quase o tempo todo. Revisei um atraso recente que escrevi e 62 de 64 histórias ( 97% ) tiveram cláusulas para que. Um pequeno número de ocasiões me impede de considerá-lo obrigatório.
Pontos fortes do modelo de história de usuário de três partes
Então, o que há de tão bom nesse modelo que ele resistiu ao teste do tempo? Afinal, uma prática introduzida no início dos anos 2000 e crescendo em aceitação tantos anos depois deve ter algo a seu favor. Eu acho que existem quatro pontos fortes principais no modelo.
Abrange três dos cinco Ws
Comecei a universidade como especialista em jornalismo. Acho que romantizei filmes cheios de repórteres de jornais que mastigam charutos e filmes como Ás no buraco, cidadão Kane, aconteceu uma noite, e Todos os homens do presidente. Os jornalistas são treinados para que qualquer artigo de jornal precise responder cinco perguntas que começam com um W:
- Quem? (Who?)
- O que? (What?)
- Quando? (When?)
- Onde? (Where?)
- Por quê? (Why?)
As histórias dos usuários abordam três dos cinco – Quem, O quê e Por quê. Ao discutir os requisitos do produto ou sistema, parece razoável deixar Quando e Onde, pois as respostas geralmente seriam “ agora ” e “ no produto. ”
Os elementos são apresentados na ordem certa
Eu acho que os elementos – quem, o quê e por quê – são apresentados na ordem certa. Pense em qualquer história – não em uma história de usuário, mas em um filme, um romance ou uma anedota ou piada que você deseja contar a um amigo. A coisa mais importante nessa história é quase sempre quem está fazendo isso. Chamamos essa pessoa de protagonista.
Quando assistimos a um filme, precisamos nos preocupar com o protagonista antes de nos preocuparmos com a trama. Eu não me importo de um jeito ou de outro com a Estrela da Morte sendo explodida até me ver um pouco em Luke, Han ou Leia e posso relacionar para eles.
Só depois que eu sei quem, eu me preocupo com o que e porque. O modelo padrão de história do usuário os coloca nessa ordem.
A história é contada a partir de uma perspectiva de primeira pessoa
Nós gostamos de histórias sobre nós mesmos. ( Bem, a menos que sejamos adolescentes e nossos pais estejam contando histórias sobre as coisas não tão fofas que fizemos quando éramos bebês. ) A próxima melhor coisa para uma história sobre mim é uma história sobre você.
O menos interessante é uma história sobre o cara do outro lado da cidade que eu nunca conheci.
Histórias sobre eu e você e nós e ela e ele são interessantes.
Os Beatles sabiam disso. Eles deliberadamente colocaram o maior número possível de pronomes pessoais em seus títulos de músicas. E se eles não conseguissem encaixar um pronome pessoal no título da música, colocariam o máximo que pudessem nas letras da música.
O primeiro álbum britânico dos Beatles ’ teve pronomes em 8 dos 14 títulos de músicas ( 57% ). Nos 19 minutos e 30 segundos dessas oito músicas, os Beatles usavam 325 pronomes pessoais, um pronome a cada 3,6 segundos.
Isso funcionou tão bem que seu segundo álbum teve pronomes em 64% dos títulos. Os Beatles então aumentaram para 79% em seu terceiro álbum.
Em entrevista à revista Billboard, o Beatle Paul McCartney disse que isso era muito deliberado: “ Todas as nossas primeiras músicas continham ‘eu’ ou ‘você.’ Fomos completamente diretos e sem vergonha para os fãs: Me ame, por favor, por favor, eu quero segurar sua mão.”
O modelo padrão de história do usuário começa com eu, o mais pessoal dos pronomes pessoais. Não tenho base para essa afirmação – não sou neurologista -, mas juro que algo acontece quando temos uma história de usuário que começa com eu.
Nos relacionamos com essa história mais de perto do que se o mesmo fosse escrito como um tradicional O sistema deve… declaração.
Paul McCartney e John Lennon sabiam disso e o usavam para impulsionar suas carreiras. As equipes ágeis fazem o mesmo ao usar o modelo de história de usuário em três partes.
Nossas partes interessadas são imediatamente confortáveis preenchendo
Os espaços em branco Antes das histórias dos usuários aparecerem, adorei usar casos. Ou tentei amar casos de uso. Eu realmente os amava. Mas nunca consegui convencer as partes interessadas com quem trabalhei para amá-las tanto quanto eu.
Eles estavam muito longe de como as partes interessadas pensavam sobre seu trabalho. As partes interessadas não pensam em atores secundários, pré-condições ou pós condições. E assim, os casos de uso nunca funcionaram tão bem na prática quanto eu pensava que deveriam.
Eu nunca tive esse problema com histórias de usuários. Posso realizar um workshop de redação de histórias com as partes interessadas simplesmente escrevendo Como um _____, Eu ______ para que _______ em um quadro branco e dizendo a eles que nos reunimos para preencher os espaços em branco o máximo que pudermos.
As partes interessadas entendem. É uma maneira natural de falar por eles.
Outros modelos para expressar histórias foram propostos, e alguns têm vantagens, mas a maioria são maneiras menos naturais de falar. Por exemplo, o desenvolvimento orientado a comportamentos é uma ótima maneira de expressar testes ou especificar por exemplo. Martin Fowler descreve sua sintaxe dada quando e depois como “ um estilo de representação de testes. ” E é fantástico para escrever especificações de teste mas não é tão bom para se comunicar com os clientes.
Em parte, isso ocorre porque seu modelo é menos natural. Falo desde os 2 ou 3 anos. Não sei se já iniciei uma frase com dado. Definitivamente nunca usei dado, quando e então nessa ordem em uma frase. Eu disse sem conta “ eu quero isto de modo que aquilo.”
Desvantagens do modelo de user story de três partes
Há duas desvantagens no modelo padrão de história do usuário que merecem destaque.
Muitas histórias são escritas apenas como “ Como usuário … ”
Com demasiada frequência, os membros da equipe têm o hábito de iniciar cada história de usuário com “ Como usuário…” Às vezes, esse é o resultado de um pensamento preguiçoso e os escritores de histórias precisam entender melhor os usuários do produto antes de escrever tantas histórias “ como usuário … ”.
Mas outras vezes, pode indicar um sistema não adequado para histórias de usuários. Isso acontece porque muitas pessoas associam ser ágil com a escrita de histórias de usuários. Para ser ágil, eles raciocinam, você precisa escrever histórias de usuários, mesmo quando não há usuários.
Eu trabalhei em um sistema de rastreamento de conformidade financeira. A grande maioria do que o sistema fez nunca seria vista ou relatada. Se um problema de conformidade fosse descoberto, no entanto, os relatórios seriam gerados e os indivíduos seriam notificados. Esse sistema se beneficiou de histórias de usuários para esse pequeno subconjunto da funcionalidade geral do produto. Mas as histórias dos usuários eram inadequadas para o resto do sistema.
Em casos como esses, as equipes precisam usar maneiras alternativas de expressar o que o produto precisa fazer. A sintaxe usada por histórias de trabalho ou desenvolvimento orientado a recursos recursos podem ser melhores escolhas.
O modelo é muito frequentemente seguido de maneira eslava
Por todos os meios, o senso comum precisa ser um princípio norteador para equipes ágeis. Ao expressar algo no modelo de história do usuário padrão, não faz sentido, não use esse modelo. Escreva de outra maneira, incluindo muito possivelmente apenas texto de forma livre.
Hoje cedo, escrevi um item de lista de pendências do produto “ Altere como os lembretes de reprodução de webinar são enviados no último dia da maneira como discutimos na ligação de sexta-feira. ”
Como um item de lista de pendências do produto, isso é péssimo. Não é uma história de usuário. Não é BDD ou mesmo uma história de trabalho. É horrível. E se não for corrigido em breve, ninguém se lembrará do bug que foi discutido em uma ligação esquecida.
Mas eu sabia que a equipe iria consertar isso em breve e, portanto, o que escrevi foi bom o suficiente. A última coisa que eu preciso seria de um Scrum Master insistindo em escrevê-lo para seguir um modelo criado na virada do milênio, não importa o quão bem esse modelo funcione para a maioria dos itens de lista de pendências do produto.
Vantagens das histórias de usuários sobre requisitos e casos de uso
A programação extrema ( XP ) introduziu a prática de expressar requisitos na forma de histórias de usuários. A história do usuário é uma breve descrição da funcionalidade – contada da perspectiva de um usuário – que é valiosa para um usuário do software ou para o cliente do software, e normalmente assume a forma de um Modelo de 3 partes.
A caso de uso, por outro lado, é uma descrição generalizada de um conjunto de interações entre o sistema e um ou mais atores, onde um ator é um usuário ou outro sistema. Os casos de uso podem ser escritos em texto não estruturado ou em conformidade com um modelo estruturado.
Requisitos são tipicamente uma lista de instruções “ O sistema deve … ”, como:
- O sistema deve permitir que uma empresa pague por um anúncio de emprego com cartão de crédito.
- O sistema deve aceitar cartões Visa, MasterCard e American Express.
- O sistema cobrará o cartão de crédito antes que o anúncio de emprego seja colocado no site.
- O sistema deve fornecer ao usuário um número de confirmação exclusivo.
Histórias de usuários normalmente (mas nem sempre e não em todos os casos) são a melhor escolha para equipes que usam Scrum porque oferecem várias vantagens em casos de uso, requisitos e outras opções.
Benefícios das histórias de usuários
As histórias de usuários exibem algumas das mesmas características dos casos de uso ou declarações de requisitos tradicionais, mas são as maneiras pelas quais elas são diferentes que dão tantas vantagens às histórias de usuários.
User Story Benefício 1: Exigem conversas
Talvez o benefício mais importante das histórias dos usuários no desenvolvimento ágil de produtos seja que, diferentemente dos requisitos ou casos de uso, as histórias dos usuários não devem se sustentar por si mesmas.
Em vez disso, cada história de usuário é um espaço reservado para uma conversa futura com a equipe de desenvolvimento.
O texto de alto nível armazenado em um cartão de índice, problema de Jira, célula de planilha ou nota adesiva pode ser a manifestação mais visível de uma história de usuário, mas não é a mais importante.
A parte mais importante de qualquer história de usuário é que um entendimento compartilhado do que é necessário é elaborado em uma conversa futura.
User Story Benefício 2: São verbais, muito mais precisas
As histórias dos usuários enfatizam a comunicação verbal, para que sejam mais precisas. O idioma escrito geralmente é muito impreciso e não há garantia de que um cliente e desenvolvedor interpretem uma declaração da mesma maneira.
Agimos como se as palavras escritas fossem precisas, mas geralmente não são. Por exemplo, no almoço recentemente, li isso no meu menu: “ Entrada: vem com uma escolha de sopa ou salada e pão. ”
Essa não deveria ter sido uma frase difícil de entender, mas foi. Qual deles você escolhe?
- Sopa ou ( salada e pão )
- ( Sopa ou salada ) e pão
Compare as palavras escritas nesse menu com a garçonete ’ palavras faladas: “ Você gostaria de sopa ou salada? ” Melhor ainda, ela removeu toda a ambiguidade colocando uma cesta de pão na mesa antes de fazer meu pedido.
User Story Benefício 3: Têm estimativas e priorização fáceis
Uma terceira vantagem de escrever histórias de usuários é que elas recebem estimativas que tornam a priorização e o planejamento mais tranquilos. Cada história de usuário pode receber uma estimativa do esforço necessário para desenvolvê-lo; os casos de uso, por outro lado, são geralmente grandes demais para receber estimativas úteis.
Da mesma forma, quando você considera as milhares ou dezenas de milhares de instruções em uma especificação de requisitos de software ( e os relacionamentos entre elas ) para um produto típico, é fácil ver a dificuldade inerente em priorizá-los.
Se os requisitos não puderem ser priorizados além do alto, médio e baixo comuns, eles não serão adequados para um processo de desenvolvimento altamente iterativo e incremental que fornecerá software de trabalho a cada duas a quatro semanas.
User Story Benefício 4: Incentive as equipes a adiar detalhes
Uma quarta vantagem é que as histórias dos usuários incentivam a equipe a adiar detalhes da coleta.
Uma história inicial épica – de nível ( “ Um recrutador pode postar uma nova vaga ” ) pode ser escrita, estimada e colocada no backlog do produto. Mais tarde, ele pode ser substituído por várias histórias menores, mais detalhadas, com DoR, DoD e Critérios de aceitação que é quando se torna importante ter esses detalhes.
Essa técnica torna as histórias dos usuários perfeitas para projetos com restrição de tempo – Uma equipe pode escrever rapidamente algumas dezenas de histórias de usuários para dar uma sensação geral pelo sistema. Eles podem mergulhar nos detalhes de algumas histórias e começar a codificar muito mais cedo do que uma equipe que se sente compelida a concluir uma especificação de requisitos funcionais.
User Story Benefício 5: Oferecer um entendimento geral do produto
A quinta vantagem é um pouco mais sutil. As listas de requisitos que um analista de negócios pode apresentar não dão ao leitor o mesmo entendimento geral de um produto que as histórias de usuários fazem.
É muito difícil ler uma lista de requisitos sem considerar automaticamente as soluções em sua cabeça enquanto você lê.
Por exemplo, considere os seguintes requisitos, adaptados dos de Alan Cooper The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity 1ª Edição.
- O produto deve ter um motor a gasolina.
- O produto deve ter quatro rodas.
- O produto deve ter um pneu de borracha montado em cada roda.
- O produto deve ter um volante.
- O produto deve ter uma carroceria de aço.
A essa altura, suponho que imagens de um automóvel estejam flutuando em torno de sua cabeça. Obviamente, um automóvel atende a todos os requisitos listados acima. O da sua cabeça pode ser um conversível vermelho brilhante, enquanto eu posso imaginar uma picape azul. Presumivelmente, as diferenças entre o seu conversível e a minha picape são cobertas por declarações de requisitos adicionais.
Mas suponha que, em vez de escrever uma especificação de requisitos de estilo IEEE 830 –, as histórias foram escritas da perspectiva do usuário.
- Como proprietário de casa, quero algo que facilite e agilize a cortar a grama.
- Como proprietário de casa, quero uma maneira de cortar a grama, onde possa me sentar, em vez de me levantar.
Ao olhar para as metas, temos uma visão completamente diferente do produto: o cliente realmente quer um cortador de grama, não um automóvel!
Histórias descrevem os objetivos de um usuário. Ao focar nos objetivos do usuário para o novo produto, em vez de uma lista de atributos do novo produto, podemos criar uma solução melhor para as necessidades do usuário.
User Story Benefício 6: Sugerem um custo
Um benefício final das histórias do usuário sobre as especificações de requisitos é que o custo de cada requisito não seja visível até que todos os requisitos sejam escritos.
O cenário típico é que um ou mais analistas passam dois ou três meses ( geralmente mais ) escrevendo um documento de requisitos demorado. Este documento é entregue aos programadores, que informam aos analistas ( que transmitem a mensagem ao cliente ) que o projeto levará 24 meses, em vez dos seis meses que eles esperavam.
Nesse caso, perdeu-se tempo escrevendo os três quartos do documento que a equipe não terá tempo para desenvolver e mais tempo será desperdiçado como desenvolvedores, analistas, e iterar o cliente sobre qual funcionalidade pode ser desenvolvida a tempo.
Na boa prática de histórias de usuários, um estimativa está associada a cada história. O cliente / proprietário do produto conhece a velocidade da equipe e o custo relativo de cada história, e pode decidir rapidamente se o produto que eles desejam pode ser entregue no tempo que eles tiverem.
Kent Beck me disse uma vez que essa diferença era como se registrar para presentes de casamento. Quando você se registra, não vê o custo de cada item. Você apenas faz uma lista de desejos de tudo o que deseja.
As listas de desejos cegas podem funcionar para casamentos, mas não funcionam para o desenvolvimento de produtos. Quando um cliente, proprietário do produto ou parte interessada coloca um item em sua lista de desejos do projeto, ele precisa saber seu custo.
Requisitos não funcionais como histórias de usuários
Um desafio comum com a escrita histórias de usuários é como lidar com os requisitos não funcionais de um produto. Esses são requisitos que não tratam de funcionalidade específica ( “Como usuário de um processador de texto, quero inserir uma tabela no meu documento”. ), mas são mais sobre um atributo ou característica do sistema.
Os exemplos incluem confiabilidade, disponibilidade, portabilidade, escalabilidade, usabilidade, manutenção.
Como você pode ver nessa lista de exemplos, os requisitos não funcionais são frequentemente referidos como “-ilidade.” Obviamente, nem todos os requisitos não funcionais terminam em “-ilidade.” Também temos segurança, desempenho, robustez e assim por diante.
Pensando na idade das trevas, lembro-me de quando li pela primeira vez sobre “requisitos não funcionais.” O termo me deu um nó. Se não é funcional, por que me preocupo com isso? Tenho certeza de que o autor desse livro esclareceu isso para mim uma página mais tarde, mas o termo sempre me pareceu estranho.
Prefiro pensar em requisitos não funcionais como “restrições” que colocamos no sistema.
Quando o proprietário do produto diz: “este sistema deve ter um desempenho adequado com 100.000 usuários simultâneos”, o proprietário do produto está colocando uma restrição no equipe.
O proprietário do produto está efetivamente dizendo: “Desenvolva este software da maneira que desejar, desde que alcance 100.000 usuários simultâneos.”
Cada restrição que colocamos em um sistema restringe um pouco as opções de design; chamar essas “restrições” em vez de “requisitos não funcionais” nos ajuda a lembrar disso. Felizmente, restrições / requisitos não funcionais podem ser facilmente expressos como histórias de usuários:
- Como cliente, quero poder executar seu produto em todas as versões do Windows a partir do Windows 95.
- Como CTO, quero que o sistema use nosso banco de dados de pedidos existente em vez de criar um novo, para que não tenhamos mais um banco de dados para manter.
- Como usuário, quero que o site esteja disponível 99.999% do tempo em que tento acessá-lo, para não ficar frustrado e encontrar outro site para usar.
- Como alguém que fala um idioma latino, talvez eu queira executar seu software algum dia.
- Como usuário, quero que as instruções de direção sejam os melhores 90% do tempo e razoáveis 99% do tempo.
Como você pode ver nesses exemplos de histórias de usuários, eu pude facilmente ficar com o “Como um , Eu quero , de modo que ” modelo de história do usuário, que eu prefiro para a maioria das histórias de usuários. Faço isso por algumas razões, mas quero comentar mais sobre apenas uma delas aqui.
Considere o exemplo do CTO que restringe a equipe a usar o banco de dados de pedidos existente. ( Esta era a situação real; a equipe estava considerando um banco de dados de segundos pedidos que seria sincronizado à noite. O CTO ouviu isso e disse: “Não!” )
Se escrevêssemos esse requisito da mesma forma: “Deve usar o banco de dados de pedidos existente,” seria inteiramente possível que, alguns meses depois, não nos lembrássemos por que deveríamos ser restringidos dessa maneira. Perguntaríamos ao proprietário do produto se ela se importava se usássemos um banco de dados secundário e ela diria que não tinha objeções. E cometeríamos um erro de usar um.
Incorporar a pessoa que quer algo pode ser muito útil. Mas, tome cuidado para não ficar obcecado com esse modelo. É apenas uma ferramenta de pensamento.
Tentar colocar uma restrição no modelo de história de usuário em três partes é um bom exercício, pois ajuda a entender quem quer o quê e por quê. Se você terminar com uma instrução confusa, largue o modelo. Você pode achar que o modelo de história de trabalho funciona melhor para o seu contexto. Ou você pode achar que os modelos não funcionam. Se você não conseguir encontrar uma maneira de expressar a restrição, basta escrever a restrição da maneira que parecer natural.
Valores
