Requisitos para recebimento de pedidos externos
Neste capítulo são descritos os requisitos mínimos para o recebimento de Prestações de Serviços, Requisições de Mudança e Incidentes originais de outras equipes para o desenvolvimento da arquitetura.
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;
- Qual procedimento a ser feito e seu detalhamento. Por exemplo:
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;