Padrões de Análise

1 - Título da Tarefa (Jira)

• Quando incluir uma nova tarefa:

  • O título deve ser descrito resumidamente com o objetivo geral da tarefa

  • Deve iniciar sempre com as expressões abaixo, conforme o tipo da tarefa:

    • Bug: Iniciar com “Ajustar…”

    • Melhoria: Iniciar com “Implementar…”

    • Legislação: Iniciar com “Legislação - Implementar…”

  • Deve finalizar sempre indicando em qual produto será feita a implementação (CRM Web, CRM Mobile…)

  • Ex: Implementar campo “tabela de preço” no pedido do CRM Web

• Quando for realizada a quebra de uma solicitação em várias tarefas, deverá ser utilizado um número de referência indicando a sequência de desenvolvimento e quantidade total.

  • Ex: Supondo que uma tarefa seja quebrada em 3 tarefas, ficaria no seguinte formato:

    • (1/3) Implementar configurações de visita no CRM Mobile

    • (2/3) Implementar listagem de visitas no CRM Mobile

    • (3/3) Implementar cadastro de visitas no CRM Mobile

• Quando realizado a quebra e existir relação entre as tarefas, deverá ser criado um “Epic”, e as tarefas devem ser vinculadas a ele.

2 - Tarefa de Melhoria/Legislação

2.1 - Layout padrão de Análise

2.2 - “Rotina”

• Deverá conter o “Caminho”, “Descrição” da rotina alvo quando existir.

  • O “Caminho” deve conter o nome completo para acesso da rotina.

  • A “Descrição” deverá conter uma explicação sobre o seu funcionamento.

    • Colocar links de documentações e manuais quando houver

    • Se é uma rotina nova, na “Descrição” deve descrever as rotinas que estão co-relacionadas

    • Se necessário, descrever as parametrizações necessárias para uso da rotina descrita no contexto da tarefa, podendo ser adicionado imagens de exemplo.

2.3 - “Motivo/Finalidade”

• Deverá escrever a necessidade do cliente com a implementação, no formato de texto corrido, destacando a persona que irá utilizar o durante o processo.

• Quando o motivo da alteração ainda não ficar claro, poderá ser utilizado recursos adicionais como por exemplo: imagem, vídeo, tabela, ou fluxograma.

• Sempre que houver uma legislação que demanda a alteração ou ajuste no sistema, obrigatoriamente deve-se constar qual é a legislação ou normativa, bem como destacar no documento oficial anexado o texto/tópico que trata da mesma.

2.4 - “Especificação”

• O detalhamento dos requisitos deverá ser feito utilizando Critérios e Lista de requisitos.

  • Critério:

    • Seu propósito é agrupar todos os requisitos relacionados à mesma função.

    • Começa contando do número 1 (Critério 1, Critério 2, Critério 3…)

  • Lista de requisitos:

    • Seu propósito é descrever, em formato de lista com indentação, os campos e regras que devem ser implementados.

• Cada critério deve ser identificado por meio de um número sequencial.

• Quando houver algum protótipo relacionado ao critério, o mesmo deverá estar posicionado após a descrição dos requisitos. Nesse deve estar sinalizado os campos descritos na lista de requisitos.

Correto: 3 - ESPECIFICAÇÃO Critério 1: Implementar dados da visita Implementar agrupador “Dados da Visita” Implementar campo “Deslocamento à” (1) Opções: “Associado”, “Não Associado” e “Prospect” Por padrão deve vir selecionado “Associado” Ao trocar a opção selecionada, deve limpar os demais campos já preenchidos Implementar campo “Cliente” (2) Por padrão o campo deve iniciar vazio Somente exibir o campo cliente se Deslocamento a for “Associado” ou “Não Associado” Campo deve ser do tipo busca Implementar validação de cliente obrigatório Ao clicar em salvar, sem informar, o cliente deve exibir a mensagem: ”Selecione um cliente para salvar a visita.” Ao clicar em buscar deve abrir a tela “Consulta de cliente” (Ver critério 3) Implementar campo “Endereço” (3) …. A imagem abaixo demonstra os requisitos descritos Open Critério 2: Implementar seção talhões Implementar agrupador “Dados do Talhão” … Critério 3: Implementar tela de busca de clientes Ao clicar na lupa do campo Cliente (Critério 1) deve abrir essa tela ….

2.5 - “Banco de Dados”

• Deve conter o banco de dados preferencialmente configurado, quando se tratar de uma rotina complexa para configurar.

3 - Tarefa de Inconsistência/Bug

3.1 - Layout padrão de Análise

3.2 - Informações de Ticket

• Quando a tarefa se trata de uma demanda de cliente, deve obrigatoriamente conter informações de ticket do movidesk, antes de iniciar o item “1- ROTINA”

3.3 - “Rotina”

• Deverá conter o “Caminho”, “Descrição” da rotina alvo quando existir.

  • O “Caminho” deve conter o nome completo para acesso da rotina.

  • A “Descrição” deverá conter uma explicação sobre o seu funcionamento.

    • Colocar links de documentações e manuais quando houver

    • Se é uma rotina nova, na “Descrição” deve descrever as rotinas que estão co-relacionadas

    • Se necessário, descrever as parametrizações necessárias para uso da rotina descrita no contexto da tarefa, podendo ser adicionado imagens de exemplo.

3.4 - “Motivo/Finalidade”

• Deverá ser a descrição do problema que ocorre ou a necessidade de alteração, buscar deixar claro qual a dor do cliente que originou a demanda.

• Deverá conter imagens ou vídeos demonstrando todo o processo realizado até chegar na inconsistência.

• Quando gerar log, esse também deve constar na tarefa

• Deve obrigatoriamente conter um banco de dados onde o problema ocorre.

• Sempre que houver uma legislação que demanda a alteração ou ajuste no sistema, obrigatoriamente deve-se constar qual é a legislação ou normativa, bem como destacar no documento oficial anexado o texto/tópico que trata da mesma.

3.5 - “Informações para teste”

• Deverá conter o passo a passo necessário para realizar a simulação do caso, incluindo quais configurações e informações detalhadas são necessárias.

• Os detalhamentos deverão ser feitos em tópicos que sigam uma ordem lógica para teste.

3.6 - “Banco de dados”

• Deverá obrigatoriamente conter um banco de dados onde o problema simulado nos vídeos e imagens esteja ocorrendo.