Refinando histórias de usuários
Refinar histórias de usuários é o processo de melhorar, dividir e esclarecer cada história de usuário. Os detalhes e a clareza de cada história de usuário devem ser revisados. A preparação do backlog é um termo que geralmente se refere ao processo de nível superior de priorização de histórias de usuários. Tanto o refinamento (esclarecimento) quanto a preparação (priorização) são passos importantes para alcançar requisitos de boa qualidade. O primeiro garante que o usuário obtenha o que deseja e o último lida com o sequenciamento para atender às necessidades do negócio e à eficiência da equipe de desenvolvimento. Neste artigo vamos focar aqui no refinamento das histórias de usuários, deixando a priorização para artigo separado.
Objetivo das histórias de usuários
O objetivo das histórias de usuários é comunicar, para garantir que as necessidades do usuário sejam expressas corretamente em uma linguagem que um desenvolvedor e testador possa compreender completa e consistentemente. As histórias de usuários precisam ser orientado ao usuário, simples, claro, inequívoco e consistente, com nada ausente. Ao refinar suas histórias, você eliminará muitos defeitos de requisitos que muitas vezes só são encontrados bem depois do início do trabalho de design e desenvolvimento. Refinar histórias de usuários com o ScopeMaster é normalmente 10 a 20 vezes mais rápido do que fazê-lo manualmente.
Histórias de usuários ou requisitos
Histórias de usuários e requisitos são a mesma coisa? Alguns puristas ágeis explicarão que as histórias de usuários são lembretes de conversas e, portanto, não são requisitos. Observamos, no entanto, que para a maioria das equipes, o histórias de usuários são tratadas como requisitos, e então fazemos o mesmo. Requisitos ou histórias de usuários são essencialmente uma expressão de capacidades que os usuários precisam do software, para garantir uma comunicação clara e consistente com a equipe. Observe que as histórias de usuário (ou requisitos) não incluem tarefas técnicas ou restrições de projeto. A seguir usaremos os termos requerimento e História do usuário intercambiavelmente.
Defeitos nas histórias de usuários são inevitáveis
Escrever requisitos ou histórias de usuários é igual a qualquer outro trabalho de conhecimento – cometemos erros à medida que avançamos. Mesmo se tivermos cuidado, erros acontecerão, são inevitáveis. Além disso, geralmente os escrevemos em inglês, que é uma língua incrivelmente sutil, onde cada palavra pode ser entendida de diferentes maneiras pelos leitores. Portanto, mesmo que pensemos que os escrevemos bem, é bastante provável que os leitores deles cheguem a uma compreensão ligeiramente diferente. Se dois leitores da história do usuário puderem chegar a um entendimento diferente – então você tem um defeito. Um defeito em uma história de usuário ou requisito levará à construção de software errado.
Custo de defeitos em histórias de usuários ou requisitos
Compreender o custo da qualidade é um tópico muito importante, pois pode nos ajudar a compreender por que a qualidade dos requisitos realmente importa. Um defeito de requisitos que não é resolvido antes do desenvolvimento levará a um bug. Esse é um fato inevitável. Muitos problemas de requisitos são detectados durante o desenvolvimento. Mas nem todos eles. Vamos considerar qual será o impacto se não encontrarmos e corrigirmos esse erro até mais tarde no ciclo de vida de desenvolvimento de software (SDLC). Se o erro for encontrado durante o desenvolvimento, talvez seja necessário interromper o desenvolvimento, verificar qual é o requisito correto, redesenhá-lo e reescrever o código. Isto leva tempo e irá perturbar e atrasar o progresso. Dependendo da natureza e da gravidade do defeito do requisito, isso pode levar a um grande retrabalho (design diferente, arquitetura diferente). Pode atrasar projetos e levar a aumentos significativos de custos.
Agora vamos considerar uma situação ainda mais grave, em que um defeito em um requisito não é percebido até que o código chegue à produção. Isto pode ter consequências ainda mais graves. O software pode estar fazendo a coisa errada e causando danos aos usuários ou à empresa. Isto pode ter um impacto catastrófico.
Custo de recuperação de defeitos em requisitos
Se um defeito causado por requisitos inadequados for encontrado na produção e for grave, existem duas categorias de custos: internos e externos.
Custos Internos
- O trabalho extra para alterar o software para funcionar corretamente
- O trabalho extra para alterar dados que foram tratados incorretamente devido à falha
- O custo de oportunidade de desviar a equipe para corrigir esse defeito em vez de realizar outro trabalho útil
Custos Externos
- Custo consequente para os usuários ou beneficiários do software, causado pelo bug
- Compensação aos usuários que sofreram esse bug
- Trabalho adicional da equipe não relacionada ao software para lidar com o incidente/impacto nos usuários até que o bug possa ser corrigido
- Danos à reputação de uma organização
Na maioria dos casos, as equipes de projeto de software subestimam o custo de requisitos inadequados. Se você quiser saber mais sobre esse assunto, recomendo este excelente livro “A Economia da Qualidade de Software”
Controle de qualidade automatizado de requisitos
O ScopeMaster leva o trabalho de garantia de qualidade de requisitos a um novo nível. O ScopeMaster ajuda a acelerar o trabalho de melhoria da qualidade dos requisitos e refinamento da história do usuário.
O ScopeMaster automatizará a descoberta e acelerará a correção de muitos defeitos de requisitos para ajudar a garantir que seus requisitos ou histórias de usuário sejam:
- Claro
- Conciso
- Consistente
- Completo
- Testável
- Considerável
- Exclusivo
- Orientado ao usuário
- Projete gratuitamente
O único atributo importante que o ScopeMaster não pode automatizar é detectar se você realmente precisa do requisito. Ele é valioso? Você terá que resolver isso sozinho, mas o ScopeMaster libera tanto do seu tempo que você terá a capacidade de considerar o valor real de cada requisito.
Aprender mais sobre refinamento automatizado do backlog
Quais são os bons requisitos?
Estabelecemos que requisitos inadequados são prejudiciais, dispendiosos, dispendiosos e, em alguns casos, até perigosos. Então, como podemos escrever bons requisitos? Como sabemos se temos bons requisitos? Como podemos detectar problemas nos requisitos? Existem alguns ingredientes universais para bons requisitos que descreveremos, que irão ajudá-lo:
Orientado ao usuário
Todos os requisitos devem ser expressos em termos das necessidades do usuário. Posteriormente, eles podem ser divididos em tarefas de desenvolvedor, mas uma versão do requisito deve primeiro ser expressa em relação à necessidade do usuário, para que possamos ter certeza de que o que for desenvolvido atenderá às necessidades do usuário.
Claro e inequívoco
Um requisito não deve ser facilmente mal compreendido pelos leitores. Esta é talvez a dimensão mais difícil de garantir. Isso significa que um requisito deve descrever claramente a funcionalidade que um usuário precisa executar. Dois leitores do mesmo requisito devem chegar ao mesmo entendimento geral sobre quais dados precisam ser tratados como parte do requisito.
Conciso
Os requisitos devem ser concisos. Um requisito não precisa ser prolixo nem usar uma linguagem florida e elegante.
Consistente
Um conjunto de requisitos deve usar termos consistentes para tipos de usuários, por exemplo administrador. Um conjunto de requisitos também deve usar termos consistentes de tipos de dados (tipos de objetos)
Completo
Um requisito deve ser completo por si só (descrever todas as etapas funcionais necessárias para aquela capacidade do usuário). Além disso, um conjunto de requisitos deve ser completo, descrevendo todas as funcionalidades necessárias para manter todos os dados dentro do sistema. Para isso, a análise CRUD é mais útil.
Considerável
Se um requisito do usuário não for funcionalmente considerável (ou seja, mensurável em pontos de função COSMIC), então é quase certo que falta qualidade se for um dos outros aspectos desta lista. É por isso que consideramos que a capacidade de dimensionar no CFP é um excelente teste de clareza e qualidade dos requisitos. N.º. as tarefas técnicas e os requisitos não funcionais não são dimensionáveis desta forma. As tarefas técnicas são geralmente dimensionadas em horas de pessoal. O dimensionamento não funcional é um problema não resolvido, embora existam algumas recomendações (em um artigo separado).
Testável
Os testadores devem ser capazes de determinar como testar se um requisito foi atendido. Portanto, o requisito deve ser escrito de forma que possa ser testado. Uma das melhores maneiras de garantir que esse requisito seja testável é garantir que ele descreva claramente a intenção funcional. (Para isso recomendamos o dimensionamento COSMIC)
Exclusivo
Não queremos que um conjunto de requisitos contenha conteúdo ou funcionalidade duplicados. (Este é talvez um dos problemas de qualidade de requisitos menos significativos.)
Sem design
As histórias de usuários não devem conter detalhes sobre como um recurso deve ser implementado. Uma história de usuário não é um espaço reservado para detalhes de design. Você pode dividir o trabalho para implementar histórias de usuários em tarefas técnicas, mas essas não são histórias de usuários.
De valor
Cada história de usuário deve agregar valor ao usuário ou às partes interessadas, caso contrário, não deverá ser construída. O valor deve ser expresso em termos que o usuário (não o desenvolvedor) reconheça.
Essa é a nossa lista recomendada de 10 atributos de boas histórias de usuários ou requisitos de software. Aplica-se em todas as situações. Alguns especialistas em requisitos argumentarão, com razão, que isso não vai suficientemente longe. É verdade que há certas situações em que os requisitos devem cumprir padrões ainda mais elevados do que os que descrevemos aqui. O que descrevemos é um conjunto de atributos que devem ser aplicados em todos os lugares, independentemente do tipo de software que você está desenvolvendo/montando/implantando.
Cuidado com o INVESTIMENTO!
INVEST é pneumônico cunhado pelos primeiros agilistas para fornecer algum tipo de lista de verificação para histórias de usuários. Ele significa:
- Eu sou independente (de todos os outros)
- “N” negociável (não é um contrato específico para recursos)
- "De valor
- “E” estimável (com uma boa aproximação)
- Shopping “S” (para caber em uma iteração)
- “T” estável (em princípio, mesmo que ainda não exista um teste)
Gostamos de listas de verificação, mas achamos que há muitas deficiências na lista INVEST para ser universalmente confiável para avaliar a qualidade dos requisitos e desaconselhamos seu uso.
Não garante que as histórias sejam orientadas para o usuário
Se o software não estiver fazendo algo útil para o usuário, ele não será útil. Se nossas histórias não forem orientadas para o usuário, então serão simples tarefas de trabalho. E é isso que tantas histórias de usuários acabam se tornando, tarefas e não expressões de funcionalidades ou capacidades reconhecíveis pelo usuário. Em suma, a sua expressão de feito provavelmente será pobre.
Falha em garantir consistência
Se você seguir apenas essas diretrizes, provavelmente acabará com requisitos que confundem nomes de usuários/pessoas e terão muitos termos diferentes para tipos de objetos.
Não consegue garantir tamanho considerável
Ao fazer referência a Estimável e não dimensionável, esta abordagem falha em garantir que cada história de usuário tenha tamanho (funcional). O tamanho funcional não é valioso apenas para o gerenciamento de projetos, mas também é um bom teste de qualidade dos requisitos. Um requisito considerável é um de boa qualidade.
Falha em garantir a ausência de design
Depender apenas do INVEST fará com que suas histórias de usuários fiquem confusas com tarefas (e “histórias de usuários técnicas”), o que distancia o trabalho do usuário e o valor para ele.
Usando o ScopeMaster
Dentro de uma hora após usar o ScopeMaster pela primeira vez, você encontrará e corrigirá defeitos de requisitos mais rápido do que nunca. Dependendo da qualidade dos requisitos originais, você poderá encontrar e corrigir até 200 defeitos por dia. Você consegue pensar em alguma outra atividade que seria tão produtiva para encontrar e corrigir defeitos?
Siga esses passos:
- Importe as histórias dos seus usuários (por meio de um arquivo CSV).
- Clique em “Analisar tudo” (talvez você tenha tempo para tomar um café).
- Explore os resultados da análise do ScopeMaster
- Comece com os ambíguos e reformule-os para torná-los histórias de usuários funcionais claras e orientadas para o usuário
- Use o dicionário de dados gerado automaticamente e o modelo de caso de uso para garantir uma nomenclatura de usuário consistente
- Use a análise CRUD para garantir uma nomenclatura consistente de objetos
- Examine o feedback de qualidade que o ScopeMaster fornece para melhorá-los ainda mais.
- Use a análise CRUD para garantir que o conjunto de requisitos esteja completo
