[BETA] Processo: Análise de complexidade

• Considerações Gerais
• Revisões Conjuntas

Considerações Gerais

Tópicos considerados

Durante o processo de análise para definir a complexidade de um caso, alguns pontos devem ser levados em consideração:

Tipo de alteração

1. Alteração apenas "adicional"
   A alteração feita no caso é considerada uma implementação adicional quando não é alterado nenhum processo já existente, apenas acrescentada uma nova condição para um processo que já existe ser executado.
2. Alteração adicional com ressalvas
   Uma alteração é considerada adicional com ressalvas quando, é adicionada uma condição para a execução de um processo já existente, entretanto, esse processo necessita de adaptações para a condição adicionada.
3. Implementação de um processo
   Uma alteração onde existe a implementação de um processo antes não existente, é uma alteração de implementação.

Categorias de Complexidade:

Baixa (1)

• Alteração de relatórios;
• Alterações meramente visuais;
• Categorias de erros de baixa complexidade:
  • "Field not found";
  • "Index out of bound";
  • "Focar em campo invisível";
  • "Erros de estado da query";
• Modificações nos eventos mais comuns dos componentes:
  • OnExit;
  • OnClick;
  • OnEnter;
  • OnDlgClick;
  • OnChange;

Média (2)

• Cláusulas extensas com inúmeros JOIN, funções de agregações, etc;
• Criação de campos e tabelas;
• Métodos/Funções de Rotinas Comuns;
• Criação/Implementação de relatórios;
• Modificações nos eventos dos componentes:
  • OnKeyDown;
  • OnKeyPress;
  • OnKeyUp;

Alta (3)

• Eventos de componentes do tipo TFDQuery;
• Eventos de componentes não citados na complexidade anterior;
• Rotinas de transmissão (específica por módulo: SPED, eSocial, notas em geral);
• Rotinas de Integração entre sistemas;

 

Estabelecer prazo "máximo" antes de marcar pessoas do nível de complexidade "pedindo" revisão

 

Revisões Conjuntas

Definição

Para maior assertividade nas revisões feitas, as revisões feitas dessa maneira, são realizadas por dois desenvolvedores conjuntamente. Onde contará com um desenvolvedor "especialista" do sistema (Dev 1), ou seja, que trabalha ou trabalhou na manutenção do sistema em questão e que possui conhecimento intermediário/avançado das rotinas alteradas que serão revisadas. A revisão também será composta por outro desenvolvedor (Dev 2), que não conhece propriamente os processos alterados do sistema e que será auxiliado/guiado pelo Dev 1.

Como funciona

A revisão conjunta visa incentivar e proporcionar o intercâmbio de conhecimento entre o Dev 1 e o Dev 2 do caso, para que isso seja efetivo, é necessário que o Dev 2 vivencie toda a rotina do processo em questão no caso e que consiga reproduzir a situação relatada no caso com o auxílio do Dev 1.