Especificação Por Exemplo como ela é – Parte 02

outubro 18, 2016 12:00 pm Publicado por Deixe um comentário

Na primeira parte desta série, falamos sobre o que é a Especificação Por Exemplo (e também sobre o que ela não é). Descobrimos que ela é um conjunto de boas práticas para ajudar a construir o produto certo. Neste artigo e no próximo, vamos falar um pouco sobre cada uma dessas práticas.

Derivar o escopo a partir do objetivo

Como falamos no primeiro artigo, nem sempre o que o cliente pede é realmente o que ele precisa (lembram do exemplo do carro x bicicleta?). Derivar o escopo a partir dos objetivos ajuda a descobrir o que o cliente realmente precisa e dá liberdade para que o time de desenvolvimento possa sugerir a melhor forma de fazer isso (mais simples de implementar, mais rápida e até mais barata).

Nosso foco, então, deve ser entender qual o problema que o cliente quer resolver, ou a meta que ele quer atingir, e a partir daí o time todo colabora para chegar ao design da solução.

objetivos de negócio > derivar o escopo > criar as histórias

Nesse ponto, é de extrema importância entender alguns pontos:

  • quem precisa?
  • de quê?
  • para qual finalidade?

Assim, fica mais fácil de descobrir qual o produto que realmente vai resolver o problema do cliente.

Especificar colaborativamente

Colaboração sem dúvidas é uma das palavras mais importantes nesse contexto. Para alcançar o sucesso, é importante que todas as pessoas envolvidas colaborem. Assim, o entendimento é uniforme e um conhecimento compartilhado é construído.

A Documentação Viva, da qual falamos no artigo anterior, é um exemplo do que deve ser especificado colaborativamente. QAs, Devs, POs, UXs e todos os envolvidos devem elaborá-la em conjunto criando especificações que são fáceis de entender (para os mais diversos papéis) e testes simples de manter.

Alguns exemplos de como especificar colaborativamente:

  • Grandes Workshops: time, stalkeholders e todas as pessoas com conhecimento de negócio elaboram juntas exemplos para ilustrar a funcionalidade. Pode-se usar a cerimônia de refinamento para isso.
  • Pequenos Workshops (3 amigos): geralmente QA, PO e UX, ou QA, BA (Business Analyst), DEV (ou a configuração que fizer sentido para seu time) colaboram para criar os exemplos. O QA contribui muito na hora de pensar nos cenários (tanto positivos quanto negativos) para as funcionalidades.
  • Escrita em par: QA e UX, QA e PO, QA e DEV, BA e DEV (ou a configuração que fizer sentido para seu time) escrevem em par as especificações.
  • Desenvolvedores revisam as especificações: quando o time não tem um QA, por exemplo, e o PO ou o BA escrevem as especificações, o time de desenvolvimento pode revisar para garantir que não existem dúvidas sobre o que deve ser implementado.

O importante é que exista algum nível de colaboração. :)

Ilustrar com exemplos

Seres humanos compreendem melhor com exemplos práticos. Isso ajuda a evitar a ambiguidade e comunica com precisão.

É importante utilizar exemplos concretos do negócio e pensar nos outputs esperados.

Além disso, os exemplos ajudam a gerar discussão e eliminar as dúvidas.

Exemplificando:

Funcionalidade: Entrega Grátis

1 – Oferecida para clientes VIP, uma vez que eles comprem um certo número de livros;

2 – Não é oferecida para clientes comuns nem para clientes VIPs que comprem qualquer coisa diferente de livros;

3 – O número mínimo de livros para a entrega grátis é 5;

Exemplos:

especificacao

Algumas características de bons exemplos:

  • devem ser precisos: ajuda a evitar ambiguidade, deve informar claramente o contexto e como o sistema deveria se comportar em cada caso;
  • devem ser completos: é importante combinar diferentes inputs e pensar nos resultados esperados, além de experimentar com dados;
  • devem ser realísticos: pensar sempre em situações reais do usuário (cuidado com informações sigilosas);
  • fáceis de entender: todos os envolvidos devem ler os exemplos e entender sem muita dificuldade. Pode-se usar de abstrações – por exemplo, usar “carro” como exemplo em vez de ficar descrevendo exaustivamente as características do mesmo: carro com 4 rodas, 2 portas etc., a menos que essas características influenciem no resultado final.

Também pode-se usar exemplos para requisitos não funcionais.

Performance: “o sistema precisa importar X registros em Y minutos consumindo Z de cpus”.

UI: protótipos de telas são bons exemplos também.

Refinando as especificações

Nesse ponto, já temos muitos insumos sobre o que deve ser construído e qual o comportamento. Agora é hora de olhar pra todo esse conteúdo e refiná-lo.

Uma boa especificação vira um teste de aceitação; para isso, ela precisa ser:

  • precisa e testável (já falamos disso no ponto anterior)
  • não ser um script: os scripts dizem como algo deve ser testado (logar como Maria, navegar para home, pesquisar por “Teste de Software”, adicionar o primeiro resultado ao carrinho etc.). A especificação fala o que software deve fazer (primeiro resultado de “Teste de Software” pode ser adicionado ao carrinho).
  • estar descrevendo o negócio e não o design de tela: descreve qual a funcionalidade sem dizer como fazer isso. É importante evitar escrever especificações atreladas ao código (clico no botão “Fechar”). Pense primeiramente na jornada do usuário e não nos detalhes da tela.

Outro detalhe importante do refinamento é decidir o que vai ser coberto pelos testes de aceitação gerados a partir das especificações. Dê foco em ilustrar os aspectos mais importantes do negócio.

Pra encerrar a parte 2 da nossa série, outra dica essencial: para tudo o que falamos hoje, lembre-se de utilizar uma linguagem que represente o domínio do negócio e evite o tecniquês. No último artigo da série, vamos falar dos processos que faltam: automatizar as especificações, validar frequentemente e evoluir a documentação viva. Até lá!

Referências:

***

Artigo publicado originalmente em http://www.concretesolutions.com.br/2016/09/23/especificacao-por-exemplo-2/.

Mensagem do anunciante:

Experimente a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores e ganhe até R$ 100 em créditos!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *