Requisitos para recebimento de pedidos externos

• Prestações de serviço
• Requisições de mudança
• Incidentes

Prestações de serviço

Introdução

Serão descritos aqui os requisitos para prestações de serviço, separados por produtos. Os produtos denominados "Sistemas Web" agrupam os requisitos genéricos que são válidos para o grupo todo. Produtos com requisitos específicos serão descritos separadamente.

Qualquer PS que falhe em ter estes requisitos deve ser imediatamente devolvida e corrigida por parte do remetente.

Este documento contém um glossário. Consulte-o para conhecer as terminologias utilizadas (quando em itálico, constará no glossário).

Importante: Algumas prestações de serviço podem ter mais de um serviço solicitado ao mesmo tempo, desde que todos os requisitos mínimos de todos os serviços solicitados estejam adequados.

Toma-se como base para todos os produtos abaixo as seguintes regras:

• Título deve ser claro, conciso (deve ser fácil de localizar na lista de PS da equipe) e deve ser relacionado ao pedido em questão;
• Produto e Serviço preenchidos adequadamente (uma PS a respeito do Jenkins não pode ter ProGet selecionado);
  • Uma exceção a esta regra seria uma PS relacionada a múltiplos serviços, que pode ser marcada como "Outros";
• Prioridade deve estar marcado corretamente, para não prejudicar o andamento adequado dos trabalhos (Não serão aceitas PS "urgentes" ou de "alta prioridade" que não tem essa necessidade);
• Chamado, caso tenha, deve ser preenchido para entendimento do contexto;
• Situação deve ser preenchida como "Em análise";
• Descrição deve estar preenchida de maneira clara, detalhada e com o português correto, evitando textos dúbios que podem levar à execução de um serviço errado;

Abaixo constam algumas regras específicas para determinados produtos e serviços. Os exemplos mencionados podem ser usados como embasamento para casos que não constem neste documento.

DevOps

Bitbucket

• A descrição deve conter os seguintes dados:
  • Nome do repositório no formato de nome do projeto;
  • Qual o procedimento a ser feito e seu detalhamento. Por exemplo:
    • Criação de novo repositório com nome no formato adequado, indicando quem, além do PO, poderá aceitar PRs em master (caso tenha, o PO deve ter autorizado, seja por mensagem anexada como print ou por comentário/observação no encaminhamento da PS) e informando se precisará de job do Jenkins (neste caso, contendo também todos os requisitos de uma PS para criação de job)
    • Configuração de repositório com nome do repositório e qual o problema a ser resolvido;
    • Inclusão de responsável por aceitar PRs em master com nome completo da pessoa e autorização do PO, seja por mensagem anexada como print ou por comentário/observação no encaminhamento da PS);

Jenkins

• A descrição deve conter os seguintes dados:
  • Nome do job ou nome do sistema do job no formato de nome do projeto;
  • Qual o procedimento a ser feito e seu detalhamento. Por exemplo:
    • Criação de novo job com o repositório a qual se refere e Tipo de job, podendo ser projeto Web ou Biblioteca;
    • Verificação de erro de build com o link direto para o log com erro;
    • Manutenção de job, como troca de nome, troca de repositório, troca de JenkinsFile...
    • Criação de novo usuário com nome completo da pessoa e e-mail corporativo;

Importante: para casos de verificação de erro de build a PS deve, necessariamente, ter passado por um desenvolvedor responsável e o mesmo deve incluir na solicitação o que ele já verificou/fez, pois muitas vezes, o erro é de compilação.

ProGet

• A descrição deve conter os seguintes dados:
  • Nome da bilioteca no formato de nome do projeto
  • Qual o procedimento a ser feito e seu detalhamento. Por exemplo:
    • Investigação de erro ao baixar biblioteca com biblioteca a qual se refere e erro apresentado no Visual Studio;

Bibliotecas

• A descrição deve conter os seguintes dados:
  • Nome do sistema onde a biblioteca foi instalada no formato de nome do projeto;
  • Caso o serviço selecionado seja "Utilidades", é obrigatório informar o nome da biblioteca no formato de nome do projeto;
  • Qual o procedimento a ser feito e seu detalhamento. Por exemplo:
    • Adição de sistema no SistemaEnum com o nome do sistema a ser incluído;

Importante: para casos de verificação de erro em bibliotecas a PS deve, necessariamente, ter passado por um desenvolvedor responsável e o mesmo deve incluir na solicitação o que ele já verificou/fez, pois muitas vezes o erro é mau uso ou configuração incorreta.

Padronizações e procedimentos

Criação/alteração de documentação

• A descrição deve conter os seguintes dados:
  • Nome da documentação a ser criada ou alterada;
  • Razão de sua criação ou alteração, detalhando qual problema será resolvido;

Estudo de novo plugin

• A descrição deve conter os seguintes dados:
  • Se é um plugin front end ou back end;
  • Qual a necessidade de um novo plugin e qual problema será resolvido;
  • Opções de plugins que resolvam o problema do solicitante, para que a arquitetura possa estudar qual se encaixa melhor no ambiente Cebi e qual das opções é a preferencial para o requisitante e o porquê disso;

Design de aplicações

Suporte ao design

• A descrição deve conter os seguintes dados:
  • Tipo de aplicação (Projeto Web, Biblioteca, Aplicativo de celular... podendo ser mais de um)
  • Qual problema será resolvido pela nova aplicação;

Sistemas Web da Arquitetura

Este tópico é válido para os seguintes sistemas: Administração; Analytics; Analytics Designer; Gerador de códigos; Login Identity Server; Login OpenIddict; Cadastro de pessoas Cebi (novo cadastro de pessoas); Usuários;

• O serviço deve estar selecionado adequadamente, por exemplo:
  • Analytics -> Cadastro de consultas: referente à área de cadastro de consultas;
  • Usuários -> Permissões de usuários: referente à rotina de atribuição de permissões;
  • Serão aceitas PSs com a opção "Outros serviços" em caso de mútiplas áreas afetadas ou incerteza sobre qual a área correta;
• A descrição deve conter os seguintes dados:
  • Qual procedimento a ser feito e seu detalhamento. Por exemplo:
    • Suporte a funcionamento do sistema com detalhamento da dúvida/necessidade, com evidências e motivo da solicitação se possível;

Requisições fora do escopo da equipe

Analytics

• Não serão aceitas requisições para desenvolver ou resolver erros de consulta.

Glossário

• Formato de nome do projeto/job: Significa estar no formato de nomenclatura utilizado pelos desenvolvedores, como o projeto web "Cebi.Usuarios" ou a biblioteca "Cebi.Util.Domain". Isso é necessário pois o nome informal do projeto pode ser diferente de seu nome real, por exemplo, Cebi.Atendimento é conhecido também como Gerenciamento de Serviços;

Requisições de mudança

Serão descritos aqui os requisitos para requisições de mudanças, separados por produtos. Os produtos denominados "Sistemas Web" agrupam os requisitos genéricos que são válidos para o grupo todo. Produtos com requisitos específicos serão descritos separadamente.

Qualquer RM que falhe em ter estes requisitos deve ser imediatamente devolvida e corrigida por parte do remetente.

Este documento contém um glossário. Consulte-o para conhecer as terminologias utilizadas (quando em itálido, constará no glossário).

Toma-se como base para todos os produtos abaixo as seguintes regras:

• Título deve ser claro, conciso (deve ser fácil de localizar na lista de RM da equipe) e deve ser relacionado ao pedido em questão;
• Empresa deve ser selecionada de acordo com as normas da Cebi;
• Produto e Serviço preenchidos adequadamente (uma RM a respeito do Administração não pode ter Analytics selecionado);
• Situação deve ser preenchida como "Em análise";
• Chamado, caso tenha, deve ser preenchido para entendimento do contexto;
• Prioridade deve estar marcado corretamente, para não prejudicar o andamento adequado dos trabalhos (Não serão aceitas RM "urgentes" ou de "alta prioridade" que não tem essa necessidade);
• Deadline deve estar vazia (a arquitetura deve fazer parte da definição);
• Descrição deve estar preenchida de maneira clara, detalhada e com o português correto, evitando textos dúbios que podem levar à execução de um serviço errado;
  • Deve explicar qual problema será resolvido e/ou a razão da mudança;
  • Deve conter detalhamento da solicitação, em termos de o que está sendo solicitado, como deve ser feito, de qual forma e o resultado desejado;

Incidentes

Introdução

Serão descritos aqui os requisitos para incidentes, separados por produtos. Os produtos denominados "Sistemas Web" agrupam os requisitos genéricos que são válidos para o grupo todo. Produtos com requisitos específicos serão descritos separadamente.

Qualquer IC que falhe em ter estes requisitos deve ser imediatamente devolvido e corrigido por parte do remetente.

Este documento contém um glossário. Consulte-o para conhecer as terminologias utilizadas (quando em itálico, constará no glossário).

Toma-se como base para todos os produtos abaixo as seguintes regras:

• Título deve ser claro, conciso (deve ser fácil de localizar na lista de PS da equipe) e deve ser relacionado ao pedido em questão;
• Chamado, caso tenha, deve ser preenchido para entendimento do contexto;
• Produto e Serviço preenchidos adequadamente (um IC a respeito do Administração não pode ter Usuários selecionado);
  • Uma exceção a esta regra seria um IC relacionada a múltiplos serviços, que pode ser marcado como "Outros";
• Situação deve ser preenchida como "Em análise";
• Prioridade deve estar marcado corretamente, para não prejudicar o andamento adequado dos trabalhos (Não serão aceitas PS "urgentes" ou de "alta prioridade" que não tem essa necessidade);
• Problema, caso tenha, deve ser preenchido para entendimento do contexto;
• Descrição deve estar preenchida de maneira clara, detalhada e com o português correto, evitando textos dúbios que podem levar ao entendimento errado do incidente;
  • Deve conter os seguintes dados:
  • Descrição do problema identificado;
  • Evidências do problema, com prints e arquivos pertinentes sempre que possível;
  • Passo a passo para reproduzir o problema;
    • Serão aceitos ICs sem passo a passo para reproduzir apenas quando o problema for intermitente. Qualquer outro tipo de problema deveria ser reproduzível;

Abaixo constam algumas regras específicas para determinados produtos e serviços. Os exemplos mencionados podem ser usados como embasamento para casos que não constem neste documento.

Bibliotecas

• Deve, necessariamente, ter passado por um desenvolvedor que deve ter verificado as configurações, depurado o programa em que a biblioteca está instalado. Muitos dos problemas são má configuração ou mau uso. Deve conter uma detalhada descrição do que o desenvolvedor verificou;