Histórias de Usuário - BI¶

Histórias de Usuário para projetos de Business Intelligence (BI) e Data Warehouse (DW)

As histórias de usuário tem um formato específico, concebido para ajudar o autor a ser descritivo e ajudar ao leitor (desenvolvedor) na tomada de ações.

Este é o template de identificação de História de Usuário a ser utilizado:

Como [personagem], eu necessito [fazer algo] para que eu possa [ter um benefício]

Onde:
[Personagem]: substantivo que descreve o usuário
[fazer algo]: representa alguma ação que o usuário assume que deseja realizar
[para ter um benefício]: representa uma declaração de “por que” o personagem assumiu que deseja realizar o que foi descrito como necessidade. Uma justificativa.

Como escrever¶

Histórias de Usuário devem focar no valor de negócio. Geralmente, as histórias devem responder à pergunta "Que valor está sendo agregado para o cliente desta solução?". No caso de soluções de BI/DW, as histórias devem ajudar a identificar respostas negociais, ou que decisão de negócio deverá suportar.

Por exemplo:
"Como analista financeiro, preciso saber o lucro líquido por cliente e por períodos de tempo, de maneira a identificar tendências de aumento ou redução do lucro"

As histórias de usuário bem escritas possuem as seguintes características:

• Arquiteturalmente completas: a funcionalidade deve obedecer à arquitetura ponta a ponta; não pode ser não-funcional ou um protótipo;
• Aptas para produção: a funcionalidade pode ser totalmente testada e estar habilitada para deploy em produção.

Histórias de usuário em projetos de BI/DW¶

Exemplos:

Relacionadas com a descoberta de dados (Data Discovery)
“Como analista de suprimentos, quero analisar os dados de vendas das novas lojas, por período quinzenal, para que eu consiga identificar padrões nos pedidos de reposição de estoque”

Relacionadas com a transformação de dados
“Como gerente de vendas, quero um ranking baseado nas taxas de cancelamento de clientes para que eu faça ofertas de retenção apropriadas aos 10 primeiros clientes do ranking”

Relacionada com a validação de dados
“Como responsável pela área de empréstimos do departamento financeiro, quero enviar notificações por e-mail quando ocorrerem aprovações de empréstimos para clientes que estejam com cadastro incorretamente preenchido, para que eu possa monitorar esses clientes e mitigar fatores de risco”

Relacionada com a apresentação e visualização de dados
“Como consultor de viagens, quero saber se existe uma correlação entre a idade dos clientes e as ofertas compradas, para que eu possa planejar campanhas de marketing mais efetivas”

Critérios de aceitação¶

Critérios de aceitação em histórias de usuário focadas em dados

História de usuário:
"Como um gerente de call center, quero conhecer o percentual de chamados atendidos por cada representante de vendas da empresa"

Critérios de aceitação:

• O cálculo deve ser mensal e o gráfico deve exibir 0 por cento enquanto o processo de cálculo não estiver finalizado.
• Os resultados devem conferir com cálculos manuais baseados nos 2 sistemas transacionais existentes, contemplando o período dos últimos 12 meses.
• O gráfico de pizza deve primeiramente exibir os percentuais agrupados por gerentes de Call Center e, depois, permitir o drill down para cada representante de vendas.

Diferenças entre pronto e aceito

Pronto
Aplica-se a todas as histórias

• Todos os testes unitários e de regressão executados e documentados.
• Histórias validadas com relaçao aos padrões de desenvolvimento e desempenho.
• Documentações atualizadas.

Aceito
Aplica-se a histórias individualmente. Exemplos:

• Verificado que a venda de um produto somente é finalizada quando:
  • produto foi despachado e
  • produto foi recebido pelo cliente e
  • serviços complementares foram concluídos
• Verificado que permite o registro de 16 pedidos específicos com várias combinações de produtos
• Verificado que o total vendido no 4o trimestre confere com os resultados do sistema financeiro

Cuidado com os épicos¶

Épicos podem ser escritos da mesma forma que histórias de usuário, porém contêm mais complexidades e, por isso, devem ser decompostos em histórias de usuário mais simples. Usuários normalmente pensam em termos de épicos.

Por exemplo:
"Como analista financeiro, preciso entender nosso custo de serviço por cliente com relação a sua lucratividade, e preciso analisar clientes por cidade, estado e região e avaliar suas tendências, possibilitando identificar oportunidades para redução de custos ou aumento dos lucros"

Esta é uma boa descrição de um requisito de BI, mas não é uma boa história de usuário porque é muito complexa para caber numa iteração simples.

Cuidado com as "anti-histórias"¶

As anti-histórias são escritas no formato de histórias, mas não atendem às suas características.

Por exemplo:
"Como gerente, preciso de um relatório sumarizado de fornecedores"
"Como gerente, preciso obter dados dos fornecedores no banco de dados FornecDB"
"Como analista financeiro, quero saber se o modelo de dados xpto irá contemplar corretamente todos os dados que preciso para construir uma grande variedade de análises sobre vendas e lucros"

São histórias de usuário mal escritas porque não focam no valor de negócio. São, na verdade, histórias de arquitetura disfarçadas. Os usuários não devem se preocupar com modelos, bases de dados e arquitetura e, sim, com soluções para a sua área de negócio.

Requisitos¶

Histórias de usuário não são, por si só, requisitos. Elas representam requisitos. São "promessas para conversação sobre os requisitos". Esta conversação é a colaboração entre desenvolvedores e usuários para estabelecer um entendimento compartilhado sobre o que é desejado. A conversação produz:

• Uma descrição da história;
• Anotações ou rascunhos que detalham ou esclarecem o que se quer;
• Testes de aceitação que ajudam a identificar quando a história está pronta.

REFERÊNCIAS¶

[1] AMBLER, Scott. Disciplined Agile Data Warehousing. Disponível em: http://www.agiledata.org/essays/disciplinedAgileDW.html Acesso em 5 fev 2018.

[2] AMBLER, Scott. The Disciplined Agile (DA) Framework. User Stories For Data Warehouse/Business Intelligence: A Disciplined Agile Approach. Disponível em: http://www.disciplinedagiledelivery.com/user-stories-for-data-warehousebusiness-intelligence-a-disciplined-agile-approach/ Acesso em 5 fev 2018.

[3] COLLIER, Ken. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Chapter 4. User Stories for BI Systems. Disponível em: https://books.google.com.br/books?id=YMR3HynGQjUC&pg=PA85&lpg=PA85&dq=COLLIER,+Ken.+Agile+Analytics+chapter+4+user+stories&source=bl&ots=f_Y_20ouK-&sig=lvwXSyhERNTh4z5wrdSyBTUxF2s&hl=pt-BR&sa=X&ved=0ahUKEwiGofConZHZAhUKuFMKHaD9BSgQ6AEISTAC#v=onepage&q=COLLIER%2C%20Ken.%20Agile%20Analytics%20chapter%204%20user%20stories&f=false Acesso em 5 fev 2018.

[4] HANIF, Irfan. User Stories in Agile Business Intelligence. How to define stories in a sprint. Disponível em: https://www.scrumalliance.org/community/articles/2016/april/user-stories-in-agile-business-intelligence Acesso em 5 fev 2018.

[5] WINTERBOER, Lynn. Acceptance Criteria for Data-Focused User Stories. Disponível em:
https://agile2017.sched.com/event/ATWz/acceptance-criteria-for-data-focused-user-stories-lynn-winterboer?iframe=no&w=100%&sidebar=yes&bg=no Acesso em 5 fev 2018.