DEMANDA

novo lider de N1

fase 1: imersão de duas semanas na wise

apresentado aos principais sistemas suportados

acompanhou o processo da demanda após entrada na fila do N2

primeiro contato com o qualitor

contato com a equipe de N2 [analistas-devs-testadores]

fase 2: introdução e acompanhamento

reconhecimento da equipe

estudo dos chamados encaminhados para N2 atualmente

levantamento de duvidas sistêmicas recorrentes

levantamento de sugestões de melhoria junto a equipe

manter dialogo direto com o N2

participação nas reuniões de analise/dev/teste - organizar agenda

e-mails de comite/analise/teste

fase 3: capacitação de equipe

capacitação interno wise

trilhas de analise

repasses pontuais sobre determinados sistemas e funcionalidades

aprofundamento nos relatórios do qualitor

descritivos para encerramento de chamados

fase 4: melhorias previstas

padrão de pré-analise

verificar chamados suspensos

qualidade da entrada da demanda

alinhamentos semanais - organizar agenda

criação de base de conhecimento baseada nos chamados e duvidas recorrentes

GPT

controle da qualidade das pré-análises

metricas

Tempo médio de resposta

Tempo médio de resolução

Taxa de resolução no primeiro contato

Nível de satisfação do cliente

Número de chamados abertos

Taxa de escalonamento: Essa métrica mede a porcentagem de demandas que precisam ser escalonados para níveis superiores de suporte devido à complexidade ou falta de recursos da equipe de nível 1. Uma taxa de escalonamento alta pode indicar a necessidade de melhorar a capacitação da equipe.

Taxa de reabertura

analise de demandas mais estruturadas [melhorias/novas funcionalidade/correções que necessitam de detalhamento]

toda analise passa por aprovação do solicitante ou analista responsável

analise de incidentes e requisições

desenvolvimento de correções e melhorias

tipos de testes aplicados:
FUNCIONAL
REGRESSÃO
INTEGRADO
UNITÁRIO
EXPLORATORIO

todo teste é documentado

todos os testes passam por homologação do solicitante e/ou analista

organização e alinhamento de demandaXversão no ambiente de homologação [SVN e OCP]

preparo das versões a serem aplicadas em produção

historico de versionamento sempre atualizado no card da demanda

comitê de mudanças

toda demanda no N2 passa pelo azure

historico da demanda: da analise até a implantação em produção

controle de versionamento

ETAPAS:
pré-analise – N1
análise de requisitos - N2
desenvolvimento
testes
homologação
aplica em produção
encerramento

O branch master é o branch principal, a HEAD do projeto, nele há somente versões que estão em produção.

O branch develop possui todo código já entregue e as últimas de desenvolvimento para a próxima versão. Quando o código do branch develop é considerado estável e pronto para ser implantado, todas as alterações devem ser mescladas de volta para o branch master

QA

HOMOLOGAÇÃO

FEATURE

Branches de melhorias
Deve ser criado a partir de: DEVELOP

Deve ser mesclado de volta para: DEVELOP

Nomenclatura: REQ-00000 / INC-00000

Criando um branch de melhoria: Ao iniciar o desenvolvimento de uma funcionalidade, crie um branch a partir do branch develop

Finalizando um branch de melhoria: Uma vez concluído o desenvolvimento no branch, ele deve ser incorporado de volta no branch develop através de um pull request.

HOTFIX

Branches de correções
Deve ser criado a partir de: master

Deve ser mesclado de volta para: develop e master

Nomenclatura: qa-hotfix

Criando um branch de correção: Branches de correção são criados a partir do branch master. Por exemplo, digamos que a versão corrente é a 1.2.0 e está causando problemas devido a um erro grave em produção. Porém as mudanças no branch develop não estão estáveis ainda. Precisamos criar um branch de correção e começar a corrigir o problema.

Não esqueça de aumentar a versão após criar o branch.
Em seguida corrigir o bug e comitar em um ou mais commits.


Finalizando um branch de correção: Quando finalizados as correções, o branch deve ser mesclado devolta com o branch master, mas também deve ser mesclado com o branch develop, para que as correções sejam incluídas na próxima versão também. O processo é similar ao do branch de lançamento.

Primeiro atualize o master e crie uma tag.

Em seguida inclua a correção no branch develop.

A única excessão a esse processo é quando existe um branch de lançamento, neste caso as alterações devem ser mescladas nele, ao invés de no branch develop. As alterações mescladas no branch de lançamento refletirão no banch develop também, quando forem finalizadas. Se o branch develop precisar da correção imediatamente e não puder esperar a finalização do branch de lançamento você pode mesclar com ele também.

Finalmente, removemos o branch já mesclado.

Branches de melhorias são usados para desenvolver novas funcionalidades para o próximo lançamento. Em excência, um branch de melhoria existe apenas enquanto está em desenvolvimento, devendo ser mesclado ao branch develop, assumindo que entrará no próximo lançamento, ou descartado caso não seja útil ou seja um experimento.

Branches de melhorias são usados para desenvolver novas funcionalidades para o próximo lançamento. Em excência, um branch de melhoria existe apenas enquanto está em desenvolvimento, devendo ser mesclado ao branch develop, assumindo que entrará no próximo lançamento, ou descartado caso não seja útil ou seja um experimento.

Branches de correções são muito parecidos com branches de lançamentos em sua concepção, pois tem o mesmo objetivo de prepara uma versão para produção, embora não planejada. Eles surgem da necessidade de agir imediatamente em uma versão de produção já implantada. Quando um bug crítico ocorre em produção um branch de correção precisa ser criado a partir da tag correspondente.
A ideia é que o time que está trabalhando na próxima versão no branch develop possa continuar enquanto alguém prepara uma correção.

azure

lança horas