Como a equipe de desenvolvimento pode entender melhor as necessidades de negócio do cliente?

/
0 Comments



Começo este artigo apresentando o manifesto para desenvolvimento ágil de software:
“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita valorizamos mais os itens à esquerda.”
Coloquei em negrito um ponto muito importante e que muitas vezes é esquecido ou mal interpretado. Há valor em todos os itens do lado direito (processos e ferramentas, documentação, negociação de contratos e um plano) e há mais valor nos itens do lado esquerdo. Importa muito mais as pessoas (clientes e equipe de desenvolvimento) e produtos entregue continuamente e operacional e, como tudo, haverá mudanças e precisamos aceitar este fato bem como nos adaptarmos a elas.

Com esta breve introdução iremos falar de uma ferramenta que auxilia na comunicação das pessoas e facilita o desenvolvimento de software para termos entregas contínuas. Falaremos das Histórias de usuários.

História de usuários é o nome dado a técnica de identificar e descrever requisitos que atendam as necessidades de negócio. Sendo assim, para escrever histórias é necessário estar na posição do cliente (preferencialmente o próprio cliente deve escrever) e pensar em ganhos para o seu negócio.

O manifesto ágil fala da interação entre cliente e equipe de desenvolvimento de software, as histórias de usuários efetivam esta interação. O cliente expõe para a equipe de desenvolvimento sua história, ele diz o que precisa e quais serão os ganhos para o seu negócio, da mesma forma apresenta como saberá que a história entregue lhe atenderá. Esta seção de conversa dará as informações necessárias para a equipe de desenvolvimento entender qual é o objetivo daquilo que eles irão fazer, dessa forma, poderão desempenhar um trabalho melhor.
Histórias de usuários é uma forma de facilitar a comunicação e entendimento do cliente e da equipe do projeto.

Para qualquer processo de comunicação ser eficiente é necessário que:
  • tenha uma linguagem comum entre todos os envolvidos
  • tenha simplicidade
  • seja objetivo
  • utilize-se de várias técnicas para melhorar a comunicação e o entendimento
  • dê preferência a comunicação face-a-face.

As histórias precisam de uma estrutura para se tornarem eficientes. Esta estrutura considera quem irá interagir com o produto (papeis, personas), que função será realizada (ações, rotinas) e ainda informa porque esta função precisa ser feita (efeito no negócio, efeito no produto). A estrutura pode ser representada da seguinte maneira:

Como um <papel/usuário> eu gostaria de <função> para <valor para o negócio>.

Veja o exemplo a seguir:
Como um cliente eu gostaria de pagar usando meu cartão de crédito para poder parcelar minhas compras.

Observações:
  • Aceitar MasterCard, Visa e Amex

Restrições:
  • Parcelar, no máximo, em 10x
  • Cliente não pode estar no SPC

As observações são regras de negócio que o cliente precisa que sejam cumpridas para a história funcionar agregando valor ao negócio. Já as restrições são limitações impostas pelo cliente.

Para identificar os papéis envolvidos no sistema faça o seguinte:
  1. Identifique os principais usuários
  2. Identifique os papéis desempenhados pelos principais usuários
  3. Organize, revise e consolide a lista de usuários e papéis.
O verso do cartão é utilizado para descrever como a história será aceita, são os critérios de aceitação. Quanto melhor discutido os critérios de aceitação mais informações haverá para o desenvolvimento das histórias.

Assim como as histórias, também há uma estrutura para escrita dos critérios de aceitação. Estes devem conter uma descrição do cenário atual (pre-condições), indicar uma ação e informar o comportamento esperado. Para mais detalhes leia BDD. Use a estrutura abaixo:

Dado que: pre-condição, descreve o cenário atual
Quando: indica o papel e a ação
Então: informa o resultado esperado

Critérios de aceitação (verso do cartão)

Cenário 1: Compra com MasterCard válido
  • Dado que o cartão utilizado é MasterCard
  • E está válido
  • Quando o cliente confirmar a compra
  • Então exibirá a mensagem “Compra realizada com sucesso”


Cenário 2: Compra com outros cartões válidos
  • Dado que o cartão é de outra bandeira
  • E está válido
  • Quando o cliente confirmar a comprar
  • Então exibirá a mensagem “Cartão não aceito”


Cenário 3: Compra com MasterCard expirado
  • Dado que o cartão é MasterCard
  • E está expirado
  • Quando o cliente confirmar a comprar
  • Então exibirá a mensagem “Compra não realizada, pois o cartão está expirado”
As histórias precisam ser muito específicas e objetivas, pois dessa forma facilitará o entendimento de todos os indivíduos. Pode acontecer no início que algumas histórias não fiquem claras o suficiente, isso pode ser devido a falta de objetividade e especificidade. Pode estar claro para o cliente, mas não totalmente para a equipe, são histórias grandes. Estas histórias devem ser subdivididas em histórias menores.

Uma maneira de auxiliar no entendimento das diversas histórias geradas é um agrupamento por similaridade, ou seja, podemos reunir as histórias que tratam de um mesmo Tema. Veja na imagem a seguir que as histórias estão agrupadas por cores que representam um mesmo tema:


Como o cliente torna conhecida suas necessidades?

Existem várias formas de coletar as histórias de usuários, e a mais valiosa é o Workshop de requisitos, encontro com a equipe de desenvolvimento em que o cliente apresenta suas histórias e o valor para o negócio. Outras técnicas que podem ser utilizadas são entrevistas com usuários, preenchimento de questionários e observação de campo.

E agora que sabemos o que o cliente quer, como criar as atividades de desenvolvimento?

Uma vez que as histórias dos usuários estão escritas e há o entendimento da equipe, agora é necessário criar as atividades de desenvolvimento.

A imagem a seguir, apresenta um modelo genérico de arquitetura dividido em cinco camadas. As atividades técnicas necessárias para implementar as histórias podem estar relacionadas em uma ou mais das camadas da arquitetura. A equipe precisa então discutir como transformar as histórias de usuários em atividades de desenvolvimento seguindo o modelo de arquitetura.


Boas práticas relacionadas com a escrita de histórias de usuários

No momento da escrita das histórias tenha em mente as seguintes informações para produzir histórias mais eficientes:
  • Histórias devem ser bem específicas
  • Defina os papeis dos usuários envolvidos
  • Defina personas para facilitar o entendimento das histórias
  • Escreva em voz ativa
  • Use os atributos INVEST
  • Use personas
  • Evite superlativos, tais como “melhor”, “mais”
  • Evite linguagens subjetivas, tais como “amigável”, “fácil de usar”, “econômico”
  • Evite frases comparativas, tais como “melhor que”
  • Evite frases com lacunas, tais como “se possível”, “conforme apropriado”.

Finalmente, a prática leva à perfeição. Quanto mais histórias você escrever e entregar mais domínio você terá para produzir histórias cada vez melhores.


Sobre o autor

Fladhimyr Castello

Você também pode gostar de

Nenhum comentário:

Assine para receber atualizações

Email*

Sobre mim

Fladhimyr Castello, PMP, CSM, gerente de projetos, coach, palestrante e professor. Desenvolvendo equipe para melhores resultados.

Saiba mais

Siga-me

Popular Posts

Arquivo

Formulário de contato

Nome

E-mail *

Mensagem *