Da Extreme Programming ao desenvolvimento moderno de produtos: como histórias curtas e centradas no usuário estimulam conversas, apoiam o aprendizado incremental, diferem dos requisitos tradicionais, podem ser divididas em fatias menores de valor e continuam sendo uma técnica opcional, e não uma exigência do Scrum.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o que são User Stories, de onde surgiram, como funciona o formato comum “Como..., quero..., para que...”, por que a conversa importa mais do que o modelo textual, como as User Stories diferem das especificações tradicionais de requisitos, como e por que histórias grandes são divididas, o que as torna pequenas o suficiente para favorecer feedback e por que o não exige User Stories.
Introdução: uma é pequena de propósito
Ideia central
O poder de uma não está em conter todos os requisitos. Seu poder está em conter informação suficiente para iniciar a conversa certa antes que decisões demais sejam tomadas.
O trabalho tradicional de requisitos frequentemente procurava reduzir a incerteza escrevendo mais. Analistas coletavam necessidades, transformavam-nas em especificações detalhadas, obtinham aprovações e entregavam os documentos às pessoas que implementariam a solução mais tarde. Essa abordagem pode ser apropriada em alguns contextos, mas, no desenvolvimento de produtos complexos, cria um problema recorrente: o documento se torna detalhado antes de a equipe ter aprendido o suficiente para saber se esses detalhes estão corretos.
As User Stories surgiram de uma filosofia diferente. A (), desenvolvida no fim da década de 1990 em torno de Kent Beck e do projeto Chrysler C3, valorizava colaboração frequente com o cliente, pequenas entregas, comunicação direta e design evolutivo. Kent Beck introduziu o termo como parte da para estimular uma abordagem mais informal e conversacional aos requisitos do que longas especificações.
Uma história era intencionalmente leve. Sua essência podia caber em um cartão de fichário. O cartão não tentava substituir a conversa entre quem compreendia a necessidade do usuário e quem compreendia como o produto poderia ser alterado. A curta declaração escrita funcionava como um lembrete de que uma conversa havia acontecido - e de que mais conversas aconteceriam à medida que a implementação se aproximasse.
Com o tempo, várias ideias complementares tornaram as User Stories mais fáceis de ensinar. Ron Jeffries descreveu os Três Cs: Card, Conversation e Confirmation. Em 2001, a empresa britânica Connextra popularizou a estrutura papel-funcionalidade-benefício, que mais tarde ficou conhecida como “As a..., I want..., so that...”. Em 2003, Bill Wake apresentou o mnemônico INVEST para características de histórias eficazes. O livro User Stories Applied, de Mike Cohn, publicado em 2004, ajudou a difundir amplamente a prática entre equipes de produto.
O risco é que o sucesso tenha feito a técnica parecer mais rígida do que realmente é. Muitas organizações passaram a tratar o modelo de frase como um formato obrigatório de requisitos. Criam centenas de histórias em ferramentas, acrescentam longos documentos de aceitação, atribuem pontos e entregam as histórias aos . O cartão vira uma especificação em miniatura e a conversa desaparece.
Isso é o oposto da intenção original. Uma é valiosa porque apoia entendimento compartilhado, , negociação e feedback. As palavras registradas no cartão não constituem o requisito inteiro.
Para candidatos à , há uma regra adicional que deve permanecer absolutamente clara: o não exige User Stories. O Scrum Guide utiliza Items (PBIs) e, de propósito, deixa aberta a forma como eles são representados. Uma é uma técnica complementar popular para expressar alguns PBIs, especialmente capacidades voltadas ao usuário, mas Teams podem utilizar outras formas sempre que elas produzirem maior transparência.
O que é uma ?
Uma é uma descrição curta de um comportamento ou capacidade desejada do produto, apresentada pela perspectiva de um usuário, cliente ou outro beneficiário relevante. Ela expressa o que alguém está tentando realizar e por que esse resultado importa.
A história é intencionalmente incompleta. Ela registra informação suficiente sobre a necessidade para apoiar ordenação, discussão e refinamento futuro, preservando espaço para descoberta colaborativa.
Martin Fowler descreve User Stories como partes de comportamento desejado usadas para dividir uma quantidade maior de funcionalidade em partes menores para planejamento. A Alliance enfatiza que uma história implementada deve contribuir para o valor do produto como um todo.
Isso torna uma diferente de uma tarefa. “Criar uma tabela no banco de dados” descreve trabalho que um Developer pode realizar. “Como correntista, quero ver meus pagamentos recentes para confirmar o que foi cobrado” descreve uma capacidade para o usuário. A tabela no banco pode fazer parte de como os implementam essa capacidade, mas não é necessariamente a história em si.
A distinção é útil porque usuários conseguem raciocinar sobre capacidades e resultados. Em geral, não conseguem priorizar tarefas técnicas internas com o mesmo significado.
Ideia central
Uma é uma descrição leve de comportamento desejado pela perspectiva de um usuário ou cliente. Ela funciona como lembrete e mecanismo de conversa - não como especificação completa.
Origem: da à prática dominante
As User Stories surgiram na comunidade de . Kent Beck introduziu o termo para incentivar um estilo mais conversacional e incremental de trabalho com requisitos. Na , as histórias funcionavam como unidades de planejamento que podiam ser ordenadas, discutidas, implementadas em iterações curtas e validadas com feedback frequente do cliente.
Esse contexto histórico é importante porque a técnica foi concebida para um sistema em que a colaboração era contínua. Remover a conversa e manter apenas o texto da história elimina grande parte do mecanismo original.
Em 2001, a Connextra, no Reino Unido, desenvolveu o formato papel-funcionalidade-motivo para redigir histórias. O formato é comumente atribuído à Rachel Davies e ficou conhecido como formato Connextra.
Por volta do mesmo período, Ron Jeffries descreveu as histórias por meio de Card, Conversation e Confirmation. Em 2003, Bill Wake publicou o mnemônico INVEST. Mike Cohn posteriormente popularizou as User Stories por meio de User Stories Applied e de amplo treinamento .
Origem e evolução das User Stories
Período
Fonte / comunidade
Contribuição
Fim dos anos 1990
Kent Beck /
As User Stories surgem como unidades leves e conversacionais para planejamento e desenvolvimento centrado no cliente.
2001
Connextra
A redação papel-funcionalidade-motivo se torna o conhecido estilo “Como..., quero..., para que...”.
Por volta de 2001
Ron Jeffries
Os Três Cs - Card, Conversation, Confirmation - explicam que o cartão é apenas uma parte da história.
2003
Bill Wake
INVEST oferece um mnemônico para características de boas histórias.
2004
Mike Cohn
User Stories Applied ajuda a popularizar a técnica entre equipes .
A estrutura comum: Como..., quero..., para que...
Formato comum de
Como [usuário ou papel], quero [necessidade ou capacidade], para que [benefício ou motivo].
A primeira parte identifica quem se beneficia. A segunda descreve o que essa pessoa deseja realizar. A terceira explica por que a capacidade importa. O trecho “para que” costuma ser o mais valioso porque revela o resultado por trás do comportamento solicitado.
Exemplo: “Como cliente de um banco, quero bloquear temporariamente meu cartão para proteger minha conta enquanto procuro um cartão que não sei onde deixei.”
O papel não precisa ser uma persona demográfica. Pode representar uma relação significativa com o produto: correntista, analista de fraude, administrador de estabelecimento comercial, agente de suporte, operador de sistema ou outro ator cujas necessidades sejam relevantes.
A parte “quero” deve, em geral, expressar uma capacidade ou necessidade, em vez de prescrever a implementação. “Quero um botão vermelho no canto superior direito usando o framework X” restringe a solução desnecessariamente, salvo quando esses detalhes são de fato obrigatórios.
A parte “para que” expõe a intenção. Quando os compreendem a intenção, podem encontrar uma solução mais simples ou mais valiosa do que a funcionalidade inicialmente solicitada.
O modelo é opcional. A Alliance o descreve como “rodinhas de treinamento”: útil para lembrar iniciantes de pensar em quem, o quê e por quê, mas não como uma lei. As equipes podem redigir histórias em outros formatos quando outra forma de expressão comunicar melhor a necessidade.
como mecanismo de conversa
O erro central na prática de User Stories é confundir o texto com a própria história. O cartão escrito é deliberadamente incompleto porque os detalhes mais importantes emergem por meio da conversa.
A conversa permite que diferentes especialidades interajam. Um pode explicar por que a capacidade importa. Um Developer pode revelar uma restrição técnica. Um designer pode questionar uma suposição sobre o fluxo do usuário. Um profissional de testes pode apresentar casos de borda. Um stakeholder ou usuário pode esclarecer um comportamento que não era evidente na frase curta.
Essa interação pode mudar a história. A equipe pode descobrir uma solução menor, um papel de usuário mais importante, um fluxo alternativo ou evidências de que a capacidade solicitada nem sequer é necessária.
Um documento detalhado de requisitos tende a sugerir que o raciocínio importante já terminou. Uma história comunica o oposto: há intenção suficiente para continuar aprendendo em conjunto.
Os Três Cs: Cartão, Conversa e Confirmação
Os Três Cs das User Stories
C
Significado
Cartão (Card)
Um breve lembrete escrito da capacidade ou necessidade. O cartão é intencionalmente pequeno demais para se tornar a especificação completa.
Conversa (Conversation)
A discussão colaborativa que desenvolve entendimento compartilhado sobre usuários, valor, opções, restrições e comportamento.
Confirmação (Confirmation)
Exemplos, testes, condições de aceitação ou outras evidências usadas para confirmar que o comportamento implementado satisfaz a necessidade compreendida.
Os Três Cs são úteis porque evitam foco excessivo no modelo de frase. Um cartão perfeitamente formatado, mas sem conversa, representa uma prática fraca. Uma frase curta e informal, sustentada por excelente conversa e confirmação clara, pode ser muito mais forte.
Confirmação não significa uma barreira de aceitação controlada pelo no . Significa haver exemplos ou testes compartilhados em quantidade suficiente para compreender se o comportamento desejado foi alcançado. A continua determinando se o trabalho faz parte do .
Lembre-se da sequência
O Cartão inicia a conversa. A Conversa cria entendimento. A Confirmação torna o comportamento esperado verificável.
User Stories versus requisitos tradicionais
Especificações tradicionais de requisitos costumam buscar registrar grande quantidade de detalhes antes da implementação. User Stories adiam deliberadamente boa parte desses detalhes até que o trabalho esteja mais próximo e a conversa possa ocorrer com conhecimento mais atual.
User Stories versus especificações tradicionais
Dimensão
Tendência da especificação tradicional
Tendência da
Objetivo principal
Descrever requisitos de forma abrangente.
Criar um ponto de partida para colaboração sobre valor para o usuário.
Momento do detalhamento
Frequentemente extenso logo no início.
Elaborado progressivamente mais perto da implementação.
Modelo de mudança
Mudanças podem exigir controle formal.
Mudanças são esperadas à medida que o entendimento melhora.
Comunicação
O documento costuma carregar grande parte da informação.
A conversa carrega grande parte da informação.
Unidade de escopo
Pode representar grandes partes do comportamento do sistema.
Em geral, pequena o suficiente para .
Liberdade de solução
Pode especificar tanto a necessidade quanto a solução.
Preferencialmente preserva espaço para negociar a solução.
Feedback
Frequentemente chega após implementação substancial.
Histórias pequenas favorecem implementação e feedback mais cedo.
Essa comparação não significa que documentos sejam ruins. Contratos, regulamentação, segurança, obrigações legais, arquitetura e conhecimento de longa duração podem exigir documentação. não proíbe documentação. A pergunta é se a documentação apoia a colaboração ou a substitui.
User Stories são mais eficazes quando o problema de produto permanece incerto e o aprendizado frequente é valioso. Em trabalho estável e altamente determinístico, outra representação pode ser mais clara.
INVEST: uma lista de verificação útil, não uma lei
Bill Wake apresentou INVEST em 2003 como um mnemônico para características que frequentemente tornam as User Stories mais fáceis de planejar, discutir, implementar e validar.
Características INVEST
Característica INVEST
Significado prático
Independent (Independente)
Prefira histórias que possam ser ordenadas e entregues com dependência limitada de outras histórias.
Negotiable (Negociável)
A história não é um contrato fixo; detalhes e solução podem evoluir por meio da conversa.
Valuable (Valiosa)
A conclusão deve importar para um usuário, cliente ou resultado do produto.
Estimable (Estimável)
A equipe compreende o suficiente para formar uma estimativa útil quando estimar for necessário.
Small (Pequena)
A história é pequena o suficiente para ser concluída rapidamente e apoiar feedback veloz.
Testable (Testável)
O comportamento esperado pode ser confirmado por exemplos, testes ou resultados observáveis.
INVEST não faz parte do e não constitui uma barreira obrigatória de qualidade para PBIs. É uma ferramenta de diagnóstico. Uma história pode não satisfazer uma característica por uma razão legítima e ainda ser útil.
A característica Negotiable é especialmente importante porque protege a intenção conversacional original. Se todos os detalhes forem fixados antes de os participarem, o item passa a se comportar mais como um contrato do que como uma história.
Histórias grandes versus histórias pequenas
Histórias grandes criam vários problemas ao mesmo tempo. São mais difíceis de compreender, estimar, encaixar em uma , testar e transformar em feedback rapidamente.
Uma história muito grande costuma ser chamada de na prática , embora o não defina o termo . A pergunta útil não é qual rótulo ela possui, mas se é pequena o suficiente para se tornar Done dentro de uma e, idealmente, pequena o suficiente para gerar feedback antes disso.
Histórias pequenas reduzem risco porque menos trabalho precisa ser concluído antes que o produto possa ser inspecionado. Elas também aumentam a flexibilidade do : opções menores e independentes podem ser reordenadas conforme o valor muda.
Entretanto, pequeno não significa trivial. Dividir uma capacidade relevante para o cliente em “histórias” de banco de dados, backend, frontend e testes pode reduzir o tamanho dos itens ao mesmo tempo que destrói o valor para o usuário. Essas partes são tarefas de implementação, não fatias verticais de valor.
Uma boa divisão preserva um resultado observável e significativo. Cada fatia deve fazer o produto avançar e criar coerência suficiente para que usuários, stakeholders ou a possam aprender com ela.
Pequena o suficiente
Uma história útil deve, em geral, ser pequena o suficiente para ser concluída dentro da iteração ou da equipe. Ser ainda menor é valioso quando preserva uma fatia observável de valor para o usuário ou para o produto.
Divisão de User Stories: reduza o escopo sem destruir o valor
Dividir uma significa transformar uma história grande em histórias menores, preservando valor significativo em cada fatia. A Alliance descreve o objetivo usual como tornar cada história pequena o suficiente para a iteração, mantendo valor de negócio mensurável.
Não existe um algoritmo universal de divisão porque os produtos são diferentes. As equipes devem perguntar quais dimensões do comportamento podem ser reduzidas sem perder um resultado coerente.
Dimensões para dividir User Stories
Dimensão de divisão
Exemplo de abordagem
Etapas do fluxo
Oferecer primeiro uma etapa significativa de um fluxo maior.
Caminho feliz versus exceções
Entregar o caminho de sucesso mais comum antes das condições de erro raras.
Regras de negócio
Implementar primeiro uma regra ou categoria importante e depois acrescentar as demais.
Operações
Começar com uma operação, como pesquisar ou visualizar, antes de acrescentar todas as ações possíveis.
Variação de dados
Dar suporte primeiro a um tipo de produto, país, tipo de conta ou fonte de dados.
Segmento de usuário
Entregar valor primeiro para um grupo de usuários de alta prioridade antes de ampliar a cobertura.
Interface / canal
Dar suporte primeiro a um canal quando essa fatia for útil de forma independente.
Desempenho / escala
Comprovar o comportamento valioso em escala limitada e depois expandir quando for seguro e apropriado.
A melhor divisão costuma ser vertical: um caminho fino por todas as camadas necessárias que produza um resultado coerente para o usuário. Divisões técnicas horizontais podem ser úteis como tarefas dos dentro do plano, mas normalmente não oferecem a mesma transparência de produto que histórias independentemente valiosas.
A também é uma técnica de aprendizado de produto. Uma primeira história menor pode testar se a ideia maior é valiosa antes que a organização financie todas as variações possíveis.
e Confirmação
Muitas equipes associam às User Stories. O não exige , mas eles podem ajudar a construir a parte de Confirmação dos Três Cs.
descrevem comportamentos ou condições específicos do item que ajudam a equipe a compreender o resultado pretendido. Podem ser exemplos, regras de negócio, cenários ou verificações concisas.
Eles não devem ser confundidos com a . são específicos de um PBI ou história. A é o estado recorrente de qualidade de todo o produto necessário para que o trabalho se torne parte do .
Uma história pode satisfazer todos os critérios funcionais de aceitação e ainda assim não cumprir a porque trabalho obrigatório de segurança, integração, desempenho, acessibilidade ou outra qualidade permanece incompleto.
User Stories e
Quando User Stories são usadas como Items, o é o espaço natural para sua evolução.
Uma história ampla pode ser decomposta, seu usuário e benefício podem ser esclarecidos, sua ordem pode mudar, os podem dimensioná-la e as conversas podem revelar soluções alternativas.
O Refinement não deve transformar toda história em uma especificação detalhada com meses de antecedência. Histórias próximas do topo do geralmente precisam de mais entendimento compartilhado do que histórias distantes.
O afirma que PBIs que podem se tornar Done pela em uma são considerados prontos para seleção no . Técnicas de podem ajudar a criar essa transparência, mas o não exige uma nem a lista INVEST.
Quem escreve User Stories?
Não existe regra do que atribua a autoria de User Stories a um único papel, pois o sequer prescreve User Stories.
O é accountable por criar e comunicar claramente Items, mas pode delegar esse trabalho. , analistas, designers, usuários, stakeholders e outros especialistas podem contribuir para a criação e o Refinement das histórias.
Uma história forte costuma surgir colaborativamente, em vez de ser escrita por uma pessoa e entregue a outra. Conhecimento de produto e conhecimento de entrega devem se encontrar antes da , e não apenas depois de a implementação já ter começado.
O continua accountable pela transparência e ordenação do . Colaboração não cria um comitê de escrita de histórias que vote em prioridades.
User Stories não são exigidas pelo
Este é o fato mais importante deste capítulo para a : o Scrum Guide não menciona User Stories como elemento obrigatório. O define Items e, de propósito, permite que seus atributos variem de acordo com o domínio do trabalho.
Um PBI pode ser representado como , caso de uso, hipótese, defeito, experimento, melhoria técnica, item de risco, narrativa, declaração de requisito ou outra forma que crie transparência suficiente para a .
Forçar todo PBI ao formato “Como usuário” pode gerar pseudo-histórias absurdas, como “Como banco de dados, quero um índice para que as consultas sejam mais rápidas”. O trabalho técnico subjacente pode ser valioso e pertencer ao , mas inventar um usuário humano falso não aumenta a transparência.
Uma madura escolhe a representação que melhor comunica a necessidade do produto. User Stories são uma ferramenta, não uma regra.
Âncora para a
O exige Items - não User Stories. User Stories são uma técnica complementar opcional.
Exemplo prático - dividindo uma de controle de cartão bancário
Imagine uma responsável por um produto de mobile banking. Um stakeholder propõe uma capacidade ampla: clientes deveriam poder gerenciar pelo aplicativo todos os controles de segurança de seus cartões físicos e virtuais.
Uma inicial é escrita: “Como portador de cartão, quero controlar as configurações de segurança do meu cartão para me proteger sem precisar ligar para o banco.” A história captura um objetivo valioso para o usuário, mas é grande demais. Ela inclui bloqueio temporário, cancelamento definitivo, controles por categoria de estabelecimento, uso internacional, limites de pagamento por aproximação, controles de cartão virtual, notificações e vários cenários de exceção.
Durante o Refinement, o explica que dados do suporte mostram um problema imediato importante: clientes ligam com frequência porque perderam temporariamente o cartão de vista e querem proteção sem cancelá-lo definitivamente.
A divide a história grande em uma primeira : “Como portador de cartão, quero bloquear e desbloquear temporariamente meu cartão para proteger minha conta enquanto procuro um cartão que não sei onde deixei.”
A conversa revela comportamentos importantes. O bloqueio deve se aplicar imediatamente a novas autorizações de compra. Pagamentos recorrentes existentes não precisam necessariamente ser afetados. O aplicativo deve explicar com clareza que um bloqueio temporário é diferente de comunicar que o cartão foi roubado.
Os identificam uma restrição técnica: a plataforma de autorização consegue bloquear e desbloquear, mas o aplicativo móvel atualmente mantém o estado do cartão em cache por alguns minutos. Um profissional de testes propõe cenários de confirmação para mudanças imediatas de estado e falhas de rede.
A equipe cria concisos e dimensiona o PBI. A história agora é pequena o suficiente para uma e preserva valor de ponta a ponta para o cliente.
O mantém outras histórias em posição inferior no : comunicar definitivamente um cartão roubado, controlar compras internacionais, ajustar configurações de aproximação e gerenciar cartões virtuais. Essas capacidades poderão ser refinadas depois, se as evidências ainda sustentarem seu valor.
A primeira história é implementada como um Done e lançada. Os dados de uso mostram forte adoção e redução significativa nas ligações para o suporte. O feedback dos clientes também revela que os usuários desejam desbloqueio automático agendado, uma ideia que não constava da lista original de funcionalidades.
Essa é a vantagem econômica de User Stories pequenas. A equipe não precisou implementar todo o conjunto de controles de segurança antes de aprender. Uma única fatia de valor gerou evidências que alteraram decisões futuras do .
Antipadrões comuns de User Stories
Antipadrões comuns de User Stories
Antipadrão
Por que enfraquece a técnica
Adoração ao modelo
A história é julgada por seguir “Como..., quero...” em vez de por criar entendimento e valor.
Mini-especificação
O cartão contém páginas de detalhes e substitui a conversa.
Handoff de requisitos
ou analista escreve histórias sozinho e as repassa aos .
Histórias por camada técnica
Banco de dados, API, frontend e testes são divididos em itens separados de pseudo-valor.
Papéis de usuário falsos
Trabalho técnico é forçado em frases artificiais como “Como banco de dados...”.
Histórias enormes
Uma história representa semanas ou meses de trabalho e posterga o feedback.
como valor
Tamanho estimado é confundido com valor para cliente ou produto.
=
Comportamento específico do item é confundido com qualidade recorrente do produto.
Todo PBI precisa ser história
A flexibilidade do é substituída por uma regra local de formatação.
Histórias escritas meses antes
A conversa detalhada é registrada cedo demais e fica desatualizada antes da implementação.
Armadilhas comuns da sobre User Stories
Armadilhas comuns da sobre User Stories
Armadilha
Interpretação correta
O exige User Stories no .
Falso. O exige Items e não prescreve seu formato.
Todo PBI deve usar “Como..., quero..., para que...”.
Falso. O modelo Connextra é opcional.
O deve escrever pessoalmente toda .
Falso. O trabalho de pode ser delegado; a accountability do permanece.
User Stories são artefatos .
Falso. Os artefatos oficiais são , e .
User Stories são .
Falso. Os compromissos são , e .
INVEST é uma regra do .
Falso. É uma lista de verificação complementar criada na comunidade /.
Uma é uma especificação completa de requisito.
Falso. Conversa e confirmação são partes essenciais da técnica.
determinam se o está Done.
Incompleto. podem confirmar o comportamento da história; a governa a qualidade do .
Todo trabalho técnico deve ser reescrito como .
Falso. PBIs podem utilizar qualquer representação útil.
Uma história grande deve ser dividida em tarefas técnicas, e cada tarefa deve ser chamada de história.
Geralmente é uma prática fraca. Prefira fatias verticais menores que preservem valor ou aprendizado significativo.
são obrigatórios quando User Stories são usadas.
Falso. Nem nem User Stories exigem .
Uma história selecionada para a é um compromisso absoluto de escopo.
Falso. PBIs selecionados são um forecast; o é o compromisso.
Estrutura de raciocínio para questões de na
Requisito do : a resposta torna User Stories obrigatórias de forma incorreta?
Flexibilidade dos PBIs: a mantém liberdade para representar Items da maneira que criar transparência útil?
Conversa: a história está sendo usada para viabilizar colaboração, em vez de substituí-la?
Valor para o usuário: a história expressa uma capacidade ou resultado significativo, e não apenas trabalho interno de implementação?
Tamanho: a história pode se tornar Done dentro de uma , preferencialmente com feedback rápido?
Divisão: histórias grandes são divididas em fatias verticais significativas, em vez de camadas técnicas?
: a accountability pelo é preservada, permitindo escrita colaborativa de histórias?
: os participam de esclarecimento, , opções técnicas e decomposição?
: as confirmações específicas do item permanecem distintas da ?
Técnicas opcionais: formato Connextra, Três Cs, INVEST, e são tratados como práticas complementares, e não como ?
Atalho para a prova
Se uma questão disser que o “exige” User Stories, , INVEST, ou o formato “Como/quero/para que”, desconfie. O exige Items transparentes - não uma técnica específica de histórias.
Conclusão: a conversa é o mecanismo de desenvolvimento de produto
User Stories se popularizaram porque resolvem um problema real: documentos de requisitos frequentemente tentavam preservar detalhes demais cedo demais, ao mesmo tempo que separavam as pessoas que entendiam a necessidade daquelas que construiriam a solução. As histórias substituíram parte desse handoff por lembretes leves e conversa direta.
Suas raízes na explicam a filosofia. Kent Beck introduziu histórias em um ambiente baseado em iterações curtas, , testes, e releases frequentes. Os Três Cs de Ron Jeffries posteriormente tornaram explícito o mecanismo: Card, Conversation, Confirmation. O Card isolado nunca foi concebido como a história inteira.
A conhecida estrutura “Como..., quero..., para que...” acrescenta disciplina ao lembrar as equipes de identificar beneficiário, capacidade e motivo. Ainda assim, o modelo é opcional. Uma frase natural que provoque uma conversa melhor pode ser mais útil do que uma história perfeitamente formatada, porém sem significado.
Boas User Stories também são pequenas o suficiente para favorecer aprendizado. Histórias grandes podem ser divididas por fluxos, regras, segmentos de usuários, cenários, operações ou outras dimensões, preservando uma significativa. Lotes pequenos reduzem risco e geram feedback mais cedo.
INVEST fornece uma lista útil: Independent, Negotiable, Valuable, Estimable, Small e Testable. Assim como o modelo de frase, porém, é orientação, e não uma regra do .
A distinção mais importante no é que User Stories não são obrigatórias. O define Items e deixa sua representação flexível porque produtos e domínios são diferentes. Uma hipótese, defeito, melhoria técnica, caso de uso, experimento, narrativa ou outro formato pode gerar mais transparência do que uma história.
Na minha avaliação, a qualidade de uma deve ser julgada menos pelo que está escrito na ferramenta e mais pelo que acontece ao redor dela. A equipe entendeu quem precisa de algo e por quê? As pessoas questionaram premissas? e profissionais de produto exploraram opções em conjunto? O trabalho ficou pequeno o suficiente para aprender rapidamente? O resultado pode ser confirmado? Se isso acontece, a técnica está funcionando. Caso contrário, adicionar mais campos ao cartão da história raramente resolverá o problema.
Principais aprendizados
User Stories surgiram na como unidades leves e conversacionais de comportamento desejado do produto.
Kent Beck introduziu o conceito de como parte da no fim da década de 1990.
O formato comum papel-funcionalidade-benefício surgiu na Connextra em 2001.
O modelo conhecido é: Como [papel], quero [capacidade], para que [benefício].
O modelo é opcional e não deve se transformar em ritual de formatação.
Os Três Cs de Ron Jeffries são Card, Conversation e Confirmation - Cartão, Conversa e Confirmação.
O Cartão é um lembrete; a Conversa cria entendimento compartilhado; a Confirmação torna o comportamento esperado observável.
User Stories diferem de especificações tradicionais por postergar detalhes deliberadamente e enfatizar colaboração.
O mnemônico INVEST, de Bill Wake, descreve qualidades úteis de histórias, mas não é uma regra do .
Histórias grandes devem, em geral, ser divididas em fatias menores que preservem valor ou aprendizado significativo.
Divisão vertical costuma ser mais útil do que dividir histórias em camadas técnicas.
são confirmações opcionais específicas do item e são diferentes da .
User Stories podem evoluir por meio do .
O não precisa escrever pessoalmente cada história; criação colaborativa costuma ser mais forte.
O não exige User Stories, , epics, personas, nem o modelo Connextra.
O exige Items, cuja representação pode variar de acordo com o domínio do produto.
