Aqui no Mobindustry, operamos com uma abordagem Ágil. Isso significa que usamos componentes ágeis como histórias de usuário e critérios de aceitação. Equipes e organizações de alto desempenho têm esses componentes em seus backlogs de produtos, e eles sabem como criá-los e usá-los de forma eficaz.
Se o seu backlog do produto não tiver histórias de utilizador e critérios de aceitação — ou se não estiver claramente definido — corre o risco de as suas expectativas não convergirem com a realidade., As histórias do Usuário e os critérios de aceitação são responsáveis por representar como o usuário final vai usar seu aplicativo e como sua equipe de desenvolvimento deve executar cada tarefa de desenvolvimento. Quando começamos a trabalhar em um novo produto, Nossa equipe colabora com o cliente para definir histórias de usuário.
Uma história de usuário é uma descrição curta e simples de um recurso de produto a partir da perspectiva de uma pessoa que quer usar esse recurso. Histórias de usuário são usadas para definir o backlog do produto em um fluxo de trabalho de desenvolvimento ágil.,
o backlog do produto é essencialmente uma coleção de histórias de usuários que informa a especificação funcional e o desenvolvimento de recursos para um determinado produto ou serviço. As histórias do Usuário consistem em três partes: uma persona do Usuário para a qual a história está sendo escrita, uma descrição do recurso que o usuário requer, e uma explicação da necessidade que o recurso satisfaz.
veja como escrever uma história de usuário:
Como (usuário) eu quero um (recurso) para que eu possa (satisfazer uma necessidade).
Let’s take a look how a user story might look., Tomaremos a Airbnb como exemplo. Vamos imaginar como uma típica história de usuário pode olhar para um produto como Airbnb.
” Como usuário, eu quero procurar um destino para que eu possa reservar alojamento em uma cidade estrangeira.”
definição de critérios de aceitação
Agora, precisamos ter certeza de que as histórias do usuário são completadas corretamente e acomodar as exigências do cliente.
critérios de aceitação são as condições que um produto de software deve satisfazer para ser aceito por um usuário, cliente, ou, no caso de funcionalidade de nível de sistema, o sistema consumidor.,
os critérios de aceitação são um conjunto de afirmações, cada uma com um resultado claro de aprovação / falha, que podem ser medidas e especificar requisitos funcionais e não-funcionais.
Writing acceptance criteria is important not only for establishing what the client expects of the product but for the development process. Naturalmente, pessoas diferentes vêem o mesmo problema de ângulos diferentes. Critérios de aceitação bem definidos fornecem uma visão uniforme da funcionalidade que você pretende implementar.,
qualquer pessoa deve ser capaz de caminhar até uma placa de Scrum, pegar um item de backlog de Produto, ler os critérios de aceitação, e claramente ver tudo o que precisa ser completado para que esse item em particular seja movido para a coluna feita. Os critérios de aceitação indicam o que deve ser feito para que uma determinada parte de um produto seja acabada.
desenvolvimento de aplicações móveis e Web
está a planear expandir o seu negócio online? Vamos traduzir as suas ideias em soluções inteligentes e poderosas.
por que precisamos de critérios de aceitação?,
- definindo limites. Os critérios de aceitação ajudam a equipe de desenvolvimento a definir os limites de uma história de usuário. Eles servem como uma forma de confirmação de que o aplicativo está funcionando como esperado, o que significa que a história do usuário está completa.a chegar a um consenso. Os critérios de aceitação permitem que a equipe de desenvolvimento esteja na mesma página que o cliente. Eles informam a equipe de desenvolvimento sobre exatamente quais condições devem ser cumpridas e garantem que o cliente sabe o que esperar da aplicação.simplificar os ensaios de aceitação., Os critérios de aceitação são a base do teste de aceitação de história do Usuário. Cada critério de Aceitação deve ser testado de forma independente e ter cenários claros de sucesso ou fracasso.Planeamento e estimativa. Os critérios de aceitação permitem que você distribua histórias de usuários através de tarefas para que eles sejam devidamente avaliados e agendados.descrição de cenários negativos. Os critérios de aceitação podem exigir que o sistema identifique uma senha fraca e impeça o utilizador de continuar, por exemplo., Introduzir um formato de senha incorreto é um exemplo de um cenário negativo no qual um usuário entra dados incorretos ou se comporta inesperadamente. Os critérios de aceitação identificam esses cenários e explicam como o sistema deve responder a eles.
deseja escrever requisitos não funcionais e funcionais para o seu projecto de software? Neste artigo, fornecemos-lhe exemplos e melhores práticas de requisitos funcionais e não funcionais
quem escreve critérios de aceitação?,
escrever critérios de aceitação ajuda a estabelecer um entendimento comum entre o proprietário do produto e a equipe de desenvolvimento no que diz respeito à solução do problema do cliente ou a criação de capacidades do produto. Uma vez que os critérios de aceitação se relacionam com o cliente e a equipe, eles devem ser escritos pelo cliente ou por um membro da equipe.
na Mobindustry, nossos analistas de negócios escrevem todos os critérios de aceitação para histórias de usuários. Os analistas de negócios entendem as necessidades do cliente e o que os desenvolvedores precisam saber para atender aos requisitos do projeto.,
os critérios de aceitação são documentados e confirmados antes do início do projeto, uma vez que a equipe e o cliente precisam chegar a acordo sobre quais resultados irão atender aos requisitos do cliente.
desenvolvimento de aplicações móveis e Web
está a planear expandir o seu negócio online? Vamos traduzir as suas ideias em soluções inteligentes e poderosas.
exemplos de histórias de utilizadores com critérios de aceitação
Agora que tem uma compreensão clara do que são as histórias de utilizadores e os critérios de aceitação, vejamos alguns exemplos.,
exemplo 1
História do utilizador: como utilizador, quero poder registar-me no serviço para que possa começar a fazer compras online.
critérios de aceitação:
- Os utilizadores só podem apresentar um formulário preenchendo todos os campos necessários.
- o e-mail que o utilizador fornece não deve ser fornecido por um serviço de E-mail gratuito.as observações do mesmo período de inquérito só podem ser apresentadas três vezes no prazo de 30 minutos.
- Os utilizadores recebem e-mails de notificação após o registo com sucesso.,
Exemplo 2
história de Utilizador: como utilizador, sou capaz de aceder a uma notificação no meu dispositivo imediatamente após a sua recepção.critérios de aceitação:
- Swiping/tapping uma notificação leva o utilizador directamente para a mensagem.
- Ver mostra conversação-se a nova mensagem foi uma resposta, então é mostrada acima do original.a contagem de mensagens é actualizada.
- uma mensagem é marcada lida depois de ser exibida.
7 dicas sobre a escrita bons critérios de aceitação
os critérios de aceitação não são fáceis de escrever., Apesar do formato simples, escrever o texto é um desafio. Aqui estão sete dicas para ajudá-lo a evitar erros comuns ao escrever critérios de aceitação ou para rever critérios escritos por um membro de sua equipe.
- Document criteria before the development process starts. Desta forma, a equipe é mais provável de pegar todas as necessidades do cliente com antecedência. Inicialmente, é o suficiente para definir critérios para um pequeno número de histórias de usuários para completar backlogs para duas sprints. Os critérios de aceitação documentados são então usados pelos desenvolvedores para planejar o processo técnico.,não torne os critérios de aceitação demasiado estreitos. Critérios de aceitação que são muito específicos deixam aos desenvolvedores pouco espaço para manobrar. Para evitar isso, lembre-se que os critérios de aceitação devem ser uma expressão de intenção, não uma decisão final. Além disso, os critérios de aceitação estreitos podem não ter em conta todas as acções dos utilizadores.mantenha os seus critérios alcançáveis. Critérios de aceitação eficazes definem uma quantidade mínima razoável de funcionalidade que você pode fornecer. Mas se você continuar descrevendo todos os pequenos detalhes, Há um risco de que sua equipe vai ficar preso em centenas de pequenas tarefas.,evitar critérios de aceitação demasiado amplos. Critérios de aceitação amplos tornam uma história de usuário vaga. Critérios de aceitação eficazes devem delinear o escopo do trabalho para que os desenvolvedores possam planejar adequadamente e estimar seus esforços.evite detalhes técnicos. Os critérios de aceitação devem ser escritos em linguagem clara. Seus stakeholders e gerentes podem não ter meios técnicos, então usando linguagem simples tornará os critérios compreensíveis para todos.
- alcançar consenso., O mesmo problema pode ser resolvido de diferentes maneiras pelos membros da equipe e partes interessadas, dependendo de seus pontos de vista. Certifique-se de comunicar os seus critérios de aceitação às partes interessadas e aos membros da equipa e chegar a um acordo mútuo. critérios de aceitação testáveis para escrita. Isso dará aos testadores a oportunidade de garantir que todos os requisitos são atendidos e permitirá que os desenvolvedores saibam se a história do usuário está completa.,
Saiba como descobrir se o seu terceirização contratante é de confiança
Como escrever critérios de aceitação
Aqui estão cinco regras gerais que irão ajudar você a resolver problemas com a formulação de critérios de aceitação. Estas regras irão permitir-lhe poupar tempo valioso e estabelecer um entendimento entre o proprietário do produto e a equipa de desenvolvimento.
Regra #1: Evitar “não”
“não” significa “em nenhum caso” e, portanto, nenhuma quantidade de tempo será suficiente para verificar a conformidade com tal condição., Se você reescrever o requisito sem usar “não”, ele será mais claro e, mais importante, verificável.
exemplo:
História do utilizador
não: como utilizador, não quero ter de introduzir a minha senha sempre que aceder à minha conta.
Do: como usuário, eu quero que minha senha seja lembrada e automaticamente preenchida para que eu possa acessar Minha Conta sem re-inserir minha senha.
critérios de aceitação
não: o sistema não pode falhar.
Do: o sistema deve ter uma disponibilidade não inferior a 90%.,
exceção
você pode usar ” não “em critérios de aceitação para introduzir uma objeção lógica, como” o formulário de login não deve ser vermelho.”Na maioria dos casos, isto será aplicável a requisitos não funcionais. Neste exemplo, formulamos uma restrição que pode ser facilmente verificada se o intervalo de tons de vermelho estiver claramente definido (por exemplo, especificado no formato RGB).,
Aprender como otimizar a experiência do cliente com um aplicativo móvel
a Regra #2: Use a voz ativa
de voz Ativa é quando o sujeito de uma frase é o executor da ação. Se a entidade responsável pela execução da ação não estiver claramente indicada, não será claro quem ou o que deve executar a ação, e será mais difícil para você verificar se um requisito é cumprido.,
exemplo:
história de usuário
não: como um cliente on-line, eu quero que os filtros sejam aplicados para que eu possa encontrar o que eu quero.
Do: como um usuário, eu quero aplicar filtros de pesquisa para que eu possa encontrar itens.não: a identidade do cliente deve ser confirmada. (Não é claro quem ou o que é responsável por confirmar a identidade do cliente.)
Do: O sistema de contabilização deve confirmar a identidade do cliente. (Note – se que as definições dos Termos “Accounting_System” e “Customer_Indentity” devem ser acrescentadas ao glossário.,)
desenvolvimento de aplicações móveis e Web
está a planear expandir o seu negócio online? Vamos traduzir as suas ideias em soluções inteligentes e poderosas.
Regra #3: evitar o uso de pronomes (especialmente os indefinidos)
Use substantivos em vez de pronomes quando se refere a itens referenciados em outros requisitos. Os pronomes devem ser evitados porque podem introduzir ambiguidade.,isto é especialmente importante quando os critérios de aceitação são armazenados em ferramentas de gestão de requisitos (como Jira) como declarações separadas que não são necessariamente organizadas. Use sempre substantivos em vez de pronomes e você vai evitar este problema.
exemplo:
história de usuário
não: como membro do site, Eu quero compartilhar informações sobre mim mesmo para que outros possam vê-lo.
Do: como um membro do site, Eu quero adicionar uma descrição do perfil para que outros possam aprender sobre mim.
critérios de aceitação
não: o controlador deve enviar ao condutor o itinerário do dia., Deve ser entregue pelo menos 8 horas antes do turno.
Do: O controlador deve enviar o Driver_Itinerary para o Driver pelo menos 8 horas antes do Driver_Shift.
como gerir equipas remotas, melhores práticas. Mobindustry compartilha sua experiência como uma empresa de terceirização
Regra #4: Evite conjunções
as Conjunções são palavras e frases tais como “e”, “ou”, “mas” e “, bem como” que combinar frases simples em complexas., A sua utilização em requisitos é geralmente um sinal de que um requisito pode ser dividido em vários requisitos separados.
exemplo:
história de usuário
não: como um designer de IU, eu quero criar e ver um problema para que eu saiba o que testar.
Do: como um designer UI, eu quero criar um problema para que eu saiba o que testar. / Como um designer UI, eu quero ver um problema para que eu sei o que testar.
critérios de aceitação
não: o utilizador deve ser de confiança ou não.
Do: O sistema Security_System deve categorizar cada usuário como confiável ou não.,
Exception
” And,” “or,” and ” not ” can be used to describe logical conditions and add qualifiers.
desenvolvimento de aplicações móveis e Web
está a planear expandir o seu negócio online? Vamos traduzir as suas ideias em soluções inteligentes e poderosas.
Regra #5: evitar absolutos inatingíveis
um absoluto (como a disponibilidade de 100%) é inatingível. Pense em Como verificar o indicador: será possível provar que o nível de disponibilidade do sistema é exatamente 100%?, E mesmo que tal sistema pudesse ser criado, você pode pagá-lo?
evite as palavras “todos”, “sempre ” e” nunca”, já que verificar tais requisitos absolutos exigirá um número infinito de testes.
exemplo:
História do utilizador
não: como viajante, quero saber a minha localização exacta actualizada em tempo real para que não me perca. (“Tempo Real” pode ser interpretado de maneiras diferentes. Por exemplo, pode ser visto como um absoluto (a ausência de qualquer atraso), que não pode ser alcançado e que não é verificável.,)
Do: Como viajante, eu quero saber minha localização precisa, atualizada a cada segundo, para que eu não me perca.
critérios de aceitação
não: o sistema deve ter 100% de disponibilidade. (100% é um valor absoluto que não pode ser alcançado e não pode ser verificado.)
Do: o sistema deve ter uma disponibilidade de pelo menos 98%.
resumo rápido dos critérios de aceitação
esperamos que este artigo tenha lançado luz sobre o mundo dos critérios de aceitação e histórias de usuários., Aqui estão os principais takeaways:
- critérios de aceitação são as condições que um produto de software deve satisfazer para ser aceito por um usuário, cliente, ou no caso da funcionalidade de nível de sistema, o sistema consumidor.os critérios de aceitação devem ser documentados e completados antes do início de um projecto, uma vez que a equipa e o cliente devem chegar a acordo sobre os resultados que irão satisfazer os requisitos do cliente.lembre-se que os critérios de aceitação devem ser uma expressão de intenção e não uma decisão final.
- critérios de aceitação eficazes definem uma quantidade mínima razoável de funcionalidade.,os critérios de boa aceitação devem delinear o escopo do trabalho para que os desenvolvedores possam planejar e estimar adequadamente seus esforços.os critérios de aceitação devem ser escritos em linguagem simples. certifique-se de comunicar os seus critérios de aceitação às partes interessadas e aos membros da equipa e chegar a um acordo mútuo.
- Ao escrever critérios de aceitação, evite usar” não”, conjunções, e absolutos inatingíveis. Formule frases usando voz ativa.,
Se você quiser criar critérios de aceitação e histórias de usuário para o seu aplicativo móvel ou se você tiver alguma dúvida sobre este tópico, entre em contato com a Mobindustry para uma consulta gratuita.
desenvolvimento de aplicações móveis e Web
está a planear expandir o seu negócio online? Vamos traduzir as suas ideias em soluções inteligentes e poderosas.