As Sete Dimensões para o desenvolvimento ágil de produtos

Um dos grandes desafios para qualquer Agilista é garantir que todas as demandas vindas por parte dos stakeholders sejam absorvidas pelo Scrum Team de forma clara, simples e objetiva, reduzindo o máximo possível a necessidade de consultas recorrentes, afinal muitos fatores influenciam o desenvolvimento do produto e usar um framework como das Sete Dimensões de um Produto, pode auxiliar nessa demanda.

O framework foi originado do Agile Product Coach e Presidente da EBG Consulting, Ellen Gottesdiener, para simplificar o planejamento de desenvolvimento de produtos, sugerindo sete pontos principais a serem verificados sempre que houvesse a necessidade de melhorar um produto, seja com a inclusão de uma nova funcionalidade ou a alteração/atualização de uma existente.

Neste artigo, descreverei todos os pontos desenvolvidos por Ellen unido com algumas observações e dicas úteis que absorvi aplicando tal técnica em diversos projetos, como também algumas adaptações para otimizar o framework e atender aos cenários de constante evolução de um produto ou serviço.

Users

São os usuários que irão interagir com o produto ou funcionalidade. Os exemplos podem variar entre clientes internos, colaboradores, fornecedores até outros sistemas e interfaces de integração.

Interface

Trata-se de como o produto/serviço se conecta com o usuário. Podendo assumir a forma de uma página na web, uma função mobile, um endpoint de API, dentre outros. Mas, cuidado para não confundir este ponto com o Ambiente, o qual abordaremos mais à frente, neste artigo.

Actio

Aqui descrevemos o que de fato aquele produto ou funcionalidade fará, retratando como seu produto oferecerá benefícios e novos recursos para seus usuários.

Toda ação deve ser descrita por meio de um verbo, de forma simples e objetiva, evitando que outras ações sejam misturadas em um contexto que deveria ser mais restrito.

Por exemplo: CADASTRAR um novo cliente, GERAR faturamento, INICIAR folha de pagamento, entre outros.

Data

A dimensão Data refere-se as informações que deverão ser imputadas no produto/funcionalidade, bem como dados que deverão ser retornadas como resposta para o usuário.

Nessa etapa, você pode descrever mensagens/informações úteis que podem ser aproveitas pelo usuário como hints, banners, alertas, mensagens de erro, como por exemplo:

• Dados de entrada: nome completo, razão social, CPF, CEP, endereço, ou outras informações de contato;
• Dados de saída: saldo da conta corrente, data de faturamento, conta a ser debitada, e assim por diante.

Control

Aqui descreveremos todas as regras que o desenvolvedor deve seguir para um determinado produto ou funcionalidade, impondo restrições e delimitando as fronteiras específicas para a interação dos usuários.

Descreva esses controles com o máximo de detalhes possível, certificando-se de incluir todas as regulamentações relevantes. Por exemplo, ao validar se o CPF informado é válido ou se já está cadastrado. Caso positivo, informar uma mensagem de CPF inválido ou já cadastrado [colocar a referência descrita nos dados], validar se a conta corrente informada corresponde ao CPF do titular ou dependente. Caso não corresponda, informar uma mensagem de erro [colocar a referência descrita nos dados].

Environment

Corresponde aos requisitos técnicos e de infraestruturas necessários para execução do produto/funcionalidade. Quando o produto está sendo concebido ou atualizado, informamos requisitos não-funcionais como a arquitetura a ser utilizada no software, ambientes de publicação, rotinas e janelas de release, entre outros.

Já no caso da atualização ou criação de uma nova funcionalidade, devemos descrever onde essa deverá ser publicada, podendo ser a mudança apenas de uma página em um site inteiro ou apenas uma tela em um aplicativo.

Quality Attribute

Esse ponto, refere-se aos critérios e controles de qualidade necessários que o produto/funcionalidade deve atender para considerarmos sua implementação concluída. Toda regra de negócio deve ter seu correspondente critério de aceitação, ainda que um QA possa abranger mais de uma regra e vice-versa.

Por exemplo, os critérios e controles determinam que nenhum usuário pode ter o CPF duplicado ou incorreto no cadastro. Portanto, o software não pode suportar a entrada de mais de um CPF para um único cliente.

Ilustrando as sete dimensões com uma user story

Para garantir que seu Scrum Team entenda o que precisa ser feito, é de extrema importância que a user story seja simples e, ao mesmo tempo, contemple todos os pontos levantados anteriormente.

Abaixo, construí um exemplo de user story utilizando as sete dimensões, destacando como elas podem ser utilizadas e organizadas. O cenário hipotético que usaremos será de uma funcionalidade a ser adicionada num sistema bancário, em que será necessário cadastrar um dependente, permitindo ao mesmo o acesso a visualização do saldo em conta.

3 dicas para uma user story de sucesso

Para finalizar, deixei abaixo algumas dicas para que você obtenha user stories de sucesso e mais bem-sucedidas:

1) Durante o refinamento e a escrita da user stories, o time deve validar se todos os elementos da dimensão estão suficientemente descritos e claros;

2) Garanta que as user stories sejam concisas, descrevendo uma tarefa por vez. Caso precise de muitos detalhes, o ideal é que a user stories seja dividida em duas ou mais. Lembre-se que ainda será necessário quebrar as atividades que a implementarão durante a Sprint Planning;

3) Uma boa maneira de extrair informações relativas às sete dimensões do produto e das partes interessadas, é preenchendo um formulário com perguntas como: “Quem utilizará a funcionalidade?” (users), “O que o utilizador fará com ela?” (interface), dentre outros, para ajudar a direcionar e prover o descritivo de suas necessidades reais.

Espero que este artigo possa ajudar você a descobrir uma maneira simples e eficiente de descrever o que o seu time precisa para estabelecer os primeiros requisitos e funcionalidades de seu produto e/ou mantê-lo em constante evolução.

Como tudo no Ágil, este framework é simples de entender, mas pode ser difícil de manusear. Por isso, pratique e adapte as setes dimensões à sua própria realidade, tendo em mente que quanto mais próximo das premissas expostas aqui, maior serão seus ganhos e menor os possíveis problemas gerados pela má utilização da técnica.