BDD na prática – Parte 5 – Utilizando Personas (?!)
Olá pessoal. Tudo certo!?
Nesse post, mostro a relação entre Personas e BDD.
Se você está chegando agora, talvez queira ler outros posts relacionados com BDD aqui no blog.
Personas?!
Como já mencionei em um post anterior (Você conhece Mort, Elvis e Einstein?!),
Uma persona é um personagem “realista” pensado para representar um segmento dos usuários “target” de um software ou web seite. Cada persona é um arquétipo que serve como um substituto para um grupo inteiro de pessoas reais.
Personas servem como um resumo para resultados de pesquisa sobre padrões e comportamentos de usuários de forma que um time de desenvolvimento possa tomar decisões baseadas nessas personas (e não nos anseios do próprio time).
No lugar de cada desenvolvedor perguntar a si mesmo sobre uma feature, pode perguntar, por exemplo, “O que João (uma persona) pensaria disso aqui”.
Obviamente, é raro uma ferramenta ter apenas um tipo de usuário. Então, tipicamente, são sempre pensadas três ou quatro personas que representam todos os usuários.
Esse conceito é aplicado com frequência no projeto da UX. Foi amplamente utilizado, por exemplo, no desenvolvimento do Windows Phone 7 como descrevi, também, em um post anterior (Já é hora de você conhecer [as personas] Anna e Miles).
Relação com BDD
BDD descreve funcionalidades do sistema. Para isso, utiliza “cenários de uso”.
Cenários de uso, necessariamente, refletem ações de um usuário. Na minha compreensão, todos os usuários de um sistema devem ser “representados” por uma Persona. Logo, deveríamos utilizar Personas na descrição de um cenário de uso. Veja um exemplo:
Neste exemplo, Anna é uma persona definida em conjunto com o time de marketing, que descreve com qualidade um “perfil de usuário” do software. Cenários de uso descritos dessa forma, apoiados em uma descrição qualificada da persona ajudam o time de desenvolvimento a entender “melhor” o cenário de uso.
A utilização de Personas também ajuda na construção de bases de dados de desenvolvimento que se “aproximam mais” de ambientes de produção.
Era isso.
O que você acha?!
Pingback: FluentCodeMetrics – Parte 4 – TypeFilters « Elemar DEV