Pular para conteúdo

Execução - Abordagem Ágil

Construção e Entrega

Ciclo de Iterações

O Ciclo de Interações tem por objetivo demonstrar como são distribuídas as macro atividades. Também é possível verificar que o cliente está no centro do processo, fazendo com que as necessidades dele seja o principal ponto a ser observado, com isso, podemos ter entregas mais assertivas e riscos de retrabalho minimizados.

  • Cliente: Responsável em trazer as necessidades do negócio.

  • Time de desenvolvimento: Responsáveis em transformar as necessidades do cliente em realidade, fazendo com que a tecnologia seja empenhada como ferramenta de transformação.

  • Gerência: Responsável em gerir os contratos e diretrizes acordadas com o cliente. Cria um ambiente saudável para que os membros do time de desenvolvimento tenham oportunidade de focar nas necessidades do cliente.

Ciclo de interações

Definições

Glossário

  • História de Usuário: Documento de negócio que constam todas as definições relacionadas a uma determinada funcionalidade e/ou escopo para atender ao sistema e informações que proporcionam o entendimento do que precisa ser desenvolvido. Trata-se do documento mais importante para o projeto, pois a partir dele será realizado todo o entendimento, planejamento para compor uma entrega de valor e incremento do produto;

  • Bug: Falha identificada em ambiente de desenvolvimento;

  • Erro: Falha não identificada em desenvolvimento que passou para o ambiente de homologação;

  • Defeito: Falha não identificada em homologação que passou para o ambiente de produção;

  • Melhoria: Tipo de manutenção. É realizado para aprimorar o software ao longo do tempo. Envolve a incorporação de novas funcionalidades, aperfeiçoamento na usabilidade ou desempenho;

  • Atividade Técnica: Resultado da implementação de soluções rápidas e momentâneas no contexto de desenvolvimento de produtos, sem considerar (ou escolher) a forma mais adequada a longo prazo;

  • Débito Técnico: Atividade de ajuste técnico e que pode ou não trazer resultado prático para o usuário final, como refatoração de código, melhoria de performance, análise técnica, itens relacionados à zeladoria de software, etc.;

  • Card: “Um ponto ou assunto que não está resolvido e está sob discussão ou sobre o qual existem pontos de vistas opostos ou desacordos” (PMI, Guia PMBOK, 3ª ed.). Na prática, considera-se um card como algo a ser resolvido. Dentro do contexto do Processo de Desenvolvimento Almaviva Solutions, os cards são gerenciados através de quadros de tarefas ou Cards Lists, e podem englobar tanto Histórias de Usuários quanto Bugs, Erros, Defeitos, Melhorias ou Atividades Técnicas.

  • Feature: Pode ser relacionado a uma característica do sistema ou uma funcionalidade. Este é considerado grande para atuação dentro do próximo ciclo de desenvolvimento ou entrega, pois normalmente é composto por mais de uma História de Usuário;

  • Épico: Épico é caracterizado como itens que compõem mais de uma Feature e consequentemente várias Histórias de Usuário. Também é considerado grande para atuação dentro de um ciclo de desenvolvimento ou entrega, pois normalmente é composto por mais de uma Feature e várias Histórias de Usuário.

  • Classe: Classes de Serviço são categorias que ajudam a priorizar e gerenciar o trabalho com base em suas característica e urgência.

Board

O Board é uma ferramenta que auxilia no controle das atividades (cards) solicitados pelo cliente, trazendo visibilidade de status de cada tarefa (backlog, em desenvolvimento, concluída, etc.). Também ajuda a identificar os responsáveis, a complexidade e o grau de complexidade para cada uma das atividades nele presente. No board, cada demanda/solcitação é representado por um card, e é composto por colunas onde cada uma representa um estado:

  • Open: Estado inicial. Nesta etapa, os cards fazem parte do backlog do produto e podem possuir uma ideia simples e inicial do desenvolvimento de uma atividade, sem que haja muito detalhamento da demanda solicitada;

  • Refinamento: Estado em que os cards se encontram em processos de levantamentos de mais informações. Neste ponto, os cards ainda possuem estado de rascunho e não estão prontos e disponíveis para implementação;

  • Pronto para desenvolver: Estado em que os cards já possuem todas as informações de regras de negócio e se encontram disponíveis para serem executados nos próximos ciclos de desenvolvimento;

  • A fazer: Neste estado, os cards já estão liberados para implementação e relacionadas ao ciclo de desenvolvimento corrente e estão aguardando a disponibilização dos Desenvolvedores para iniciar sua execução;

  • Fazendo: Estado em que os cards já estão em plena implementação e aguardando serem disponibilizadas para merge para que possam ser testados;

  • Aguardando Merge: Estado em que a entrega já foi validada e aprovada nas etapas anteriores, estando pronta para ser integrada (Merge) a branch definida no repositório. Aguarda apenas a finalização técnica do merge pelos responsáveis. Após a execução do Merge Request, o deploy é realizado e o card fica disponível para a realização de testes;

  • Revisando Merge: Estado em que a implementação foi concluída e um Merge Request (MR) foi aberto para revisão por pares. Nesta etapa, o código é analisado quanto à qualidade, aderência às boas práticas e impactos técnicos. Após a aprovação do MR, a solicitação segue para a etapa seguinte (Aguardando Testes em Desenvolvimento), possibilitando a realização do deploy e a liberação do card para testes;

  • Aguardando Testes em Desenvolvimento: Neste estado, os cards já estão disponíveis para testes aguardando a disponibilidade do analista de testes para seu início;

  • Testando em Desenvolvimento: Estado em que os cards já se encontram em plena atividade de testes no ambiente de Desenvolvimento;

  • Aguardando Deploy em Homologação: Nesta fase, os cards já foram desenvolvidos e testados aguardando somente a implantação no ambiente de Homologação;

  • Aguardando Testes em Homologação: Neste estado, os cards já estão disponíveis para testes no ambiente de Homologação aguardando a disponibilidade do analista de testes para seu início;

  • Testando em Homologação: Estado em que os cards já se encontram em plena atividade de testes no ambiente de Homologação;

  • Aguardando Deploy em Produção: Nesta fase, os cards já foram testados no ambiente de Desenvolvimento e Homologação e se encontram aguardando somente a implantação no ambiente de Produção;

  • Closed: Aqui encerra-se o ciclo dos cards, tendo sua disponibilização no ambiente de Produção.

Desenho do processo

Desenho geral do processo a qual constam os papéis envolvidos, assim como etapas e integrações realizadas

Desenho do processo

Detalhe do processo

Detalhamento dos Papéis, Entradas, Etapas e Saídas envolvidos no processo. Para melhor entendimento do processo, é necessária a leitura integral de cada um desses tópicos.

Open

Início da demanda a ser desenvolvida no projeto. Esse processo é composto por subatividades que detalham o levantamento de insumos, o alinhamento com o cliente e a definição de suas priorizações.

Open

Levantar novas demandas

Open2

O levantamento de novas demandas deve ocorrer junto ao cliente através de reuniões entre ele e o Analista de negócio / requisitos para que possam ser direcionadas ao time de desenvolvimento assim que documentadas e priorizadas.

  • Cliente;
  • Analista de negócio / requisitos.
  • Agendamento de reunião com cliente para captação de novas demandas.

  • Captar novas demandas: O Analista de negócio / requisitos deverá se reunir com o cliente para fazer entendimento de seu negócio e também dos itens solicitados por ele;

  • Analisar solicitações: Após a realização da reunião com o cliente, o Analista de negócio / requisitos responsável pelo produto, irá analisar todos os itens levantados e verificar se os insumos coletados na reunião realizada foram o suficientes para entendimento de negócio;

  • Alinhar informações e tirar dúvidas com o cliente: Caso ocorra de os insumos levantados na primeira reunião não tenham sido o suficiente, será necessário que o cliente levante mais informações para uma elaboração de negócios mais aderente. O Analista de negócio / requisitos deve se reunir com o cliente quantas vezes forem necessárias para que todas as dúvidas sejam sanadas e que os insumos levantados atendam a um mínimo de informações para que as demandas possam ser atendidas;

  • Criar prévias de cards: Assim que as demandas forem claramente levantadas, o Analista de negócio / requisitos pode criar um esboço dos cards para priorização e atendimento posterior. Neste caso, os cards devem ser registrados com o estado "Open" no board.

  • Reuniões de alinhamento e entendimento de negócio;
  • Prévias de cards registrados com estado "Open" no board (opcional).

Registrar demandas / Definir backlog de produto

Open3

O registro das demandas deve ocorrer nas ferramentas de controle do projeto para fins de documentação, priorização, visibilidade de evolução e conclusão, além da gravação de logs e manutenção de seus históricos, possibilitando um processo de auditoria. Esta ferramenta de controle pode ser fornecida pelo cliente ou utilizada a ferramenta (GitLab) disponível pela Almaviva Solutions.

A definição de backlog do produto ocorre a partir do registro dos cards na ferramenta de controle.

  • Analista de negócio / requisitos.
  • Reuniões de alinhamento e entendimento de negócio;
  • Prévias de um ou mais cards (opcional).

  • Registrar cards: O registro dos cards deve ser feito respeitando os templates para cada caso e devem conter todas as informações necessárias para o atendimento da demanda. Os cards devem ser registrados com o estado "Open" no board. Os templates usados para registro dos cards devem seguir este padrão:

    • Histórias de Usuários: Histórias de Usuário, Melhorias ou Atividades Técnicas;
    • Bugs / Erros / Defeitos: Falhas identificadas nos ambientes de desenvolvimento, homologação ou produção;

  • Atualizar labels do card: O Analista de negócio / requisitos deverá atualizar as labels do card inserindo o tipo de card, identficada por "HISTÓRIA DE USUÁRIO", "BUG ou Erro ou Defeito" ou "ATIVIDADE TÉCNICA";

  • Ajustar prévias de cards: As prévias dos cards criados na etapa anterior podem ser ajustadas e colocadas dentro dos padrões, de acordo com os templates listados acima e a qualquer momento até, no máximo, a etapa de planejamento;

  • Definir e revisar backlog de produto: Com a criação e manutenção dos cards na ferramenta de controle, a lista de cards criados se transforma, automaticamente, no backlog de produto. Este backlog deve ser revisado sempre que houver mudança na priorização ou nas demandas ainda não atendidas dos itens do cliente já registrados.

    Nota: O card deve ser criado com o estado igual a "Open" no board.
    Labels: As principais labels utilizadas nesta etapa do processo são: HISTÓRIA DE USUÁRIO, BUG / Erro / Defeito e ATIVIDADE TÉCNICA;
    Templates: História de usuário ou Bug / Erro / Defeito;

    Consultar: Guia para refinamento de backlog

  • Cards registrados com estado "Open" no board;
  • Backlog do produto.

Priorizar atividades

Open5

Os itens do backlog do produto devem ser priorizados para que possam ser atendidos. Esta priorização deve ocorrer junto ao cliente e os itens prioritários devem ser desenvolvidos nas próximas demandas atendidas.

  • Analista de negócio / requisitos;
  • Cliente.
  • Cards registrados com estado "Open" no board;
  • Backlog do produto.

  • Priorizar atividades: O Analista de negócio / requisitos deve se reunir com o cliente periodicamente para definirem as prioridades dentre as atividades novas ou já registradas. Os itens alinhados entre as partes devem ser revisitados e ajustados no controle de cards, permitindo a visibilidade quanto à ordem as quais serão atendidas;

  • Formalizar priorização: O Analista de negócio / requisitos poderá, opcionalmente, elaborar uma ata de reunião ou relatório para formalizar por e-mail junto aos participantes.

  • Manter registro das solicitações: O Analista de negócio / requisitos deverá manter registro da comunicação com o cliente sobre as solicitações (captação de demandas ou priorizações) relacionando diretamente a data da solicitação no card ou através de atas ou relatórios.

    Nota: Os cards priorizados devem ter seus estados alterados para "Refinamento" no board.

  • Backlog do produto com itens priorizados;
  • Itens disponibilizados no estado "Refinamento" no board;
  • Ata de reunião com o cliente (opcional).

Refinamento

Etapa que a equipe necessita refinar as informações recebidas do cliente com o time de desenvolvimento.

Refinar demandas

Refinamento

Procedimento realizado com os Desenvolvedores e Analista de negócio / requisito para entendimento do escopo de desenvolvimento de um determinado item. Tem por objetivo trazer clareza para o desenvolvimento e, com isso, diminuir os riscos de alteração de escopo devido a falta de entendimento ou insumos.

  • Analista de negócio / requisitos;
  • Gerente do projeto;
  • Desenvolvedores.
  • Critérios de Definição de Pronto (DOR);
  • Backlog do produto com itens priorizados;
  • Itens disponibilizados no estado "Refinamento" no board.

  • Repriorizar itens: O time deve identificar itens que pareciam bons mas se tornaram irrelevantes, assim como os itens que eram menos prioritários mas que acabaram, por qualquer fator, ganhando mais importância e que devessem ser atendidos mais rapidamente;

  • Detalhar cards: O time deve melhorar a clareza e evitar mal-entendidos, definindo atores, adicionando regras de negócio e detalhes como preparação da implementação, acréscimo de critérios de aceite, referências, exemplos, etc. Devem ser considerados os critérios de Definição do Pronto (DOR) adotados no projeto.

Obs.: Ver Política de Definição de Pronto e Feito.

  • Redimensionar itens: O time deve decidir por dividir itens grandes em itens menores para que sejam mais focados e gerenciáveis e mais fáceis de serem dimensionados;

  • Identificar riscos: O time deve identificar riscos e obstáculos para itens próximos à implementação para que possa traçar a estratégia de implementação que seja mais eficiente.

  • Inspecionar e avaliar implementação: Nesta etapa, o desenvolvedor deverá inspecionar o código-fonte e todo o ambiente que será modificado pela implementação do novo card para que possa trazer clareza sobre os ajustes a serem feitos e tentar minimizar possíveis surpresas no decorrer de seu desenvolvimento;

  • Estimar complexidade / tamanho / esforço: O time pode, neste momento, estimar a complexidade/tamanho/esforço para cada atividade planejada e que será desenvolvida na sequência. Nesta etapa, o time poderá usar as técnicas de T-Shirt Sizing (tamanhos como PP, P, M, G, GG), Planning Poker (Story Points) ou SFP (Simple Function Points) e o resultado deve ser registrado em cada card. Não há necessidade de se especificar a complexidade ainda nesta etapa, podendo caber somente à etapa Planejar ciclo de desenvolvimento.

    A Diretriz: Guia de Revisão de Estimativas, presente no processo, deve ser consultada;

  • Atualizar estado do card: O card estando completamente documentado, onde não haja nenhum tipo de dúvida sobre seu desenvolvimento ou planejamento de testes, deve ter seu estado alterado para "Pronto para desenvolver".

    Nota: Os cards que tiverem todas as dúvidas de negócio sanadas devem ter seus estados alterados para "Pronto para desenvolver" no board.

  • Seleção de itens refinados do backlog do produto;
  • Itens disponibilizados no estado "Pronto para desenvolver" no board.

Pronto para desenvolver

Etapa que a equipe necessita planejar com o time de desenvolvimento as demandas refinadas a partir das informações levantadas pelo cliente.

Planejar ciclo de desenvolvimento

Pronto para desenvolver

Procedimento ou cerimônia realizado com os Desenvolvedores, Analista de negócio / requisito e cliente para definir o escopo de um ciclo de desenvolvimento. Nessa etapa do processo a História de Usuário ou item para desenvolvimento deverá estar de fácil entendimento para o time. Caso ainda existam dúvidas, poderá ser utilizado o timebox da cerimônia para abordar os pontos necessários.

  • Cliente;
  • Analista de negócio / requisitos;
  • Gerente do projeto;
  • Desenvolvedores e Analistas de testes.
  • Guia para planejamento do ciclo de desenvolvimento;
  • Critérios de Definição de Pronto (DOR);
  • Seleção de itens refinados do backlog do produto;
  • Itens disponibilizados no estado "Refinamento" ou "Pronto para desenvolver" no board;
  • Documento de Arquitetura.

  • Definir objetivo do ciclo de desenvolvimento: O time deve definir qual é o objetivo daquele ciclo de desenvolvimento, qual o propósito e o incremento que deverá resultar dela. O Contrato Social do projeto deve definir se aceitará aprovações parciais para entregas do ciclo e quais os critérios considerados para este resultado de entregas;

  • Definir escopo de trabalho: O time deve definir quais os cards serão desenvolvidas naquele ciclo de desenvolvimento. Para isto, o time deve, assim como fez na cerimônia de refinamento, detalhar, repriorizar e redimensionar os itens, caso necessário, a ponto de não permanecer mais nenhuma dúvida que impeça seu desenvolvimento. Neste ponto, cada card deve ter seu estado alterado para "A fazer" no board. Devem ser considerados os critérios de Definição do Pronto (DOR) adotados no projeto.

    Obs.: Ver Política de Definição de Pronto e Feito.

  • Incluir cards transbordados no ciclo de desenvolvimento: O Analista de negócio / requisitos poderá incluir cards transbordados de outros ciclos para o atual. Para isto, deverá referenciar o novo ciclo (milestone) no lugar do anterior no card. Apesar da alteração para referência do novo milestone, a nomenclatura do card indicando o ciclo anterior deve permanecer inalterado;

  • Rejeitar cards incompletos: O time pode rejeitar cards que estejam incompletos e que inviabilizem seu desenvolvimento. No caso de cards que sejam prioritários e que possuam necessidade de atendimento dentro do ciclo, o Analista de negócio / requisitos deve tratar todas as dúvidas ainda existentes dentro desta etapa de planejamento, para que possam ser disponibilizadas para implementação;

  • Estimar/refinar complexidade/tamanho/esforço: O time deve estimar a complexidade/tamanho/esforço para cada atividade planejada e que será desenvolvida na sequência. Caso a estimativa tenha ocorrido na etapa anterior, sendo registrada de maneira superficial, este é o momento para refinar a estimativa. Para isto, o time poderá usar as técnicas de T-Shirt Sizing (tamanhos como PP, P, M, G, GG), Planning Poker (Story Points) ou SFP (Simple Function Points) e o resultado deve ser registrado em cada card.

    A Diretriz: Guia de Revisão de Estimativas, presente no processo, deve ser consultada;

  • Registrar ciclo de desenvolvimento na ferramenta de controle: O Analista de negócio / requisitos deve efetuar a abertura do ciclo de desenvolvimento na ferramenta de controle e relacionar todos os cards que serão tratados nele. No caso do GitLab, esse processo deve ocorrer com a criação de um novo milestone para acompanhamento, relacionando todas os cards pertencentes àquele ciclo com o novo milestone. Este ciclo deve possuir a definição de prazo para encerramento. Ao abrir o registro no milestone, deve-de usar o template para Plano de Implantação e preencher as sessões Objetivos do Ciclo de Desenvolvimento e Implantação. As demais sessões serão preenchidas durante o ciclo do desenvolvimento;

  • Atualizar título do card: Neste momento, o Analista de negócio / requisitos deve atualizar o título do card para que seja registrada no formato "CL*XXX - Título no infinitivo*", onde XXX representa o número do ciclo de desenvolvimento. Exemplo: "CL18 - Cadastrar item de compra". O número do ciclo de desenvolvimento título do card deve se manter inalterado, mesmo em situações em que haja transbordo do item para novo ciclo de desenvolvimento;

  • Formalizar o ciclo de desenvolvimento com o cliente: O Analista de negócio / requisitos deverá formalizar junto ao cliente os itens a serem implementados e objetivos do ciclo de desenvolvimento.

    Nota: Os cards devem ter seus estados alterados para "A fazer" no board.
    Template: Plano de implantação.

  • Backlog do ciclo contendo itens refinados e prontos para desenvolvimento;
  • Pontuação considerando complexidade/tamanho/esforço do item;
  • Itens disponibilizados no estado "A fazer" no board;
  • Ciclo de desenvolvimento registrado na ferramenta de controle.

A Fazer

Etapa na qual as atividades priorizadas ficam disponíveis para que membros do time de desenvolvimento inicie as atividades.

Planejar ciclo de desenvolvimento

A Fazer

Um membro do time de desenvolvimento deverá selecionar uma atividade para que seja iniciado o trabalho a ser elaborado.

  • Desenvolvedores.
  • Ciclo de desenvolvimento criado com o escopo de atividades bem claros e criado no milestone do projeto;
  • Definição de responsáveis pelas tarefas a serem desenvolvidas.
  • Movimentação - Após ciclo e responsável definido, ao iniciar realizar a movimentação do card no board.
  • Itens disponíveis na coluna Fazendo.

Fazendo

Etapa na qual os cards planejados para no ciclo de desenvolvimento começam a serem desenvolvidos pelo time.

Codificar

Codificar

A codificação deve acontecer respeitando a priorização dos cards e deve ocorrer em paralelo ao planejamento de testes.

  • Desenvolvedores.
  • Itens refinados e prontos para desenvolvimento.

  • Analisar e implementar ambiente de trabalho: Os desenvolvedores devem analisar o ambiente de trabalho e efetuar ajustes necessários;

    Exemplos de ajustes: montagem de ambiente, estudos e entendimento do que será desenvolvido.

  • Analisar cards: O card deve conter todas as informações de negócio para que o desenvolvedor consiga prosseguir com a codificação. Se existir a necessidades de alinhamentos no decorrer do desenvolvimento, não significa que a entrega está comprometida;

  • Criar tarefa de implementação ou card separado: Para realizar as implementações, o time poderá optar por uma das duas opções a abaixo:

  • Opção 01: Criar tarefa dentro do card que será desenvolvido. Um card pode possuir mais do que uma tarefa de implementação, podendo direcionar cada uma delas para pessoas diferentes. Cada tarefa deve representar uma implementação e deve contemplar o conteúdo do template para o Plano de Implementação, e, também, possuir as seguintes informações:

    • Título da implementação:

      • O título deve ser curto e claro, com o número do ciclo precedido ao título;

    • Exemplos:

      • "CL18 - Cadastrar item de compra - Implementação"
      • "CL18 - Cadastrar item de compra - Serviço de cadastrar item";

    • Status:

      • A tarefa inicia com o estado "Open" (Obrigatório);

    • Responsável (Assignee):

      • Desenvolvedor responsável (Obrigatório);

    • Labels:

      • Adicionar a label "IMPLEMENTAÇÃO" (Obrigatório);
      • Outras labels que auxiliem na identificação ou gestão podem ser incluídas: "FRONTEND", "BACKEND", "BANCO DE DADOS" ou "MOBILE" (Obrigatório).

    • Datas:

      • Informar as datas de abertura e fechamento (Desejável);

    • Milestone:

      • Registrar o ciclo associada ao card principal e à execução da atividade (Obrigatório).

  • Opção 02: Criar um card na ferramenta de controle, vinculado ao card pai utilizando o linked itens ou blocked (HU) e realizar a implementação a partir deste card. O padrão de título, status, assignee (responsável), label, data, milestone e checklist deverá ser mantido. O que muda é o vinculo e o novo card que deverá respeitar as movimentações até a coluna Revisando Merge. Após a aprovação do merge, o card deverá ser fechado;

IMPORTANTE: A definição da utilização da opção 01 ou 02 deverá ser formalizada no Contrato Social para permitir a avaliação do processo.

  • Atualizar o card: O desenvolvedor deverá manter seu card sempre atualizado no board da ferramenta de controle. Sempre que uma tarefa for criada e associada a um responsável, este mesmo responsável deverá ser relacionado ao card que deu origem à tarefa;

  • Iniciar o desenvolvimento / criar branch de trabalho: Assim que a implementação for iniciada, uma nova branch de trabalho deverá ser criada, obrigatória, única e exclusivamente para o card que será desenvolvido. Cada card deverá conter sua própria branch de trabalho e não poderá se reutilizar branches para outros propósitos. A branch de trabalho deverá ser conforme a Política para Nomenclatura de Branches e deve respeitar, de acordo com o tipo e necessidade do card, as regras estabelecidas na Política de Gestão de Configuração, ambas disponíveis no processo.

    O desenvolvedor deverá atualizar o card para o estado "Fazendo" na ferramenta de controle;

  • Implementar aspectos de segurança de aplicações: O desenvolvedor deve implementar todos os aspectos relacionados a Segurança de Aplicações contidas nas Diretrizes de Segurança de Aplicações para Desenvolvimento e também para Arquitetura, disponibilizadas pelo MITH, caso necessário. O desenvolvedor superior técnico deverá validar a implementação destes itens no momento de avaliar e aprovar o Merge Request.

  • Solicitar revisão do Documento de Arquitetura: Sempre que houver necessidade de revisão ou atualização de arquitetura (inclusão ou atualização de novos produtos, serviços ou componentes; inclusão ou atualização de novas integrações entre sistemas; etc.) o desenvolvedor deverá comunicar e efetuar alinhamento com seu superior técnico ou arquiteto indicando a necessidade.

    O desenvolvedor superior técnico ou arquiteto deverá revisar e atualizar o Documento de Arquitetura, conforme consta na etapa de Iniciação do processo de desenvolvimento;

  • Código fonte disponibilizado em sua branch de trabalho;
  • Itens disponibilizados no estado "Aguardando Merge" no board;
  • Planos de implementação inseridos nos cards com estado "Aguardando Merge";
  • Revisão por pares (Merge Request) solicitado.

Testar unidades

Testar unidades

Ao final da codificação, as atividades desenvolvidas devem ser testadas unitariamente pelo próprio desenvolvedor. Em seguida, é necessário submeter as alterações via merge request, garantindo que o código passe por uma revisão em pares (code review) antes da integração com a versão estável destinada aos testes. Essa prática assegura maior qualidade, padronização e rastreabilidade das entregas.

  • Analista de testes.
  • Itens desenvolvidos.

  • Testar componentes: Após finalizar a codificação o desenvolvedor deverá testar o código na própria máquina de desenvolvimento. Os testes podem ser: unitários, de componentes ou de integração;

  • Inspecionar código-fonte: O desenvolvedor deverá realizar inspeções no código com propósito de identificar alguma anomalia ou bug em seus testes. Caso encontre, deve fazer os ajustes antes de disponibilizar seu código-fonte para revisão em pares (Merge Request);

  • Evidenciar testes locais: O desenvolvedor deverá registrar as evidências dos testes realizados em seu ambiente local. Neste caso, deverá registrá-las (em imagens ou textos que indiquem a implementação local da demanda) nos cards, através das áreas de comentário de cada tarefa de implementação criada;

  • Disponibilizar código-fonte: O desenvolvedor deverá disponibilizar o código-fonte da implementação realizada na ferramenta de versionamento sempre que encerrar sua implementação, ajustes, testes unitários, de componentes ou de integração, a fim de manter uma cópia de segurança de seu trabalho. O incremento do código na ferramenta de versionamento deve respeitar as Políticas de Mensagens de Commit, disponível no MITH. Adicionalmente, recomenda-se que o desenvolvedor realize push diário na branch utilizada para desenvolvimento. Esta prática assegura que o código não seja perdido em caso de problemas no equipamento do desenvolvedor e promove a transparência no progresso do trabalho;

  • Atualizar estado da tarefa: Após o encerramento das atividades da tarefa de Implementação, o desenvolvedor deverá encerra-la atualizando seu estado para "Closed";

  • Solicitação de Merge Request e Revisão por Pares (Peer Review): O desenvolvedor deverá criar uma solicitação de merge (Merge Request) que ocorrerá dentro do próprio card, através do botão "Criar Solicitação de Mesclagem (ou Create Merge Request)", para que seu desenvolvimento seja integrado à versão estável do ambiente de desenvolvimento.

    Deverão ser informados os nomes das branchs de origem e de destino. Neste momento, o desenvolvedor também deverá solicitar a revisão por pares da implementação realizada, devendo incorporar em sua solicitação de merge request o template de Checklist de Verificação de Código-Fonte para que possa ser utilizado pelo revisor do código no momento da validação e aprovação do merge request. Finalizado o procedimento de solicitação, o desenvolvedor deverá atualizar o card para o estado "Revisando Merge" na ferramenta de controle.

Notas: Os cards devem ter seus estados alterados para "Fazendo" no board, assim que sua implementação iniciar.

Os cards devem ter seus estados alterados para "Revisando Merge", assim que sua implementação for finalizada e a revisão por pares for solicitada.

Labels: As principais labels utilizadas nesta etapa do processo são: FRONTEND, BACKEND, BANCO DE DADOS e MOBILE;

Templates: Plano de implementação e Checklist de verificação de código-fonte.

  • Testes unitários, de componentes ou de integração;
  • Itens disponibilizados no estado "Revisando Merge" no board;

Planejar testes

Planejar testes

O planejamento de testes deve ser realizado considerando a priorização dos cards e executado em paralelo à implementação dos itens do ciclo de desenvolvimento.

Esse planejamento deve ser antecipado à execução dos testes, permitindo que o tempo disponível seja aproveitado enquanto os desenvolvedores trabalham na implementação. Assim, a execução dos cenários planejados ocorrerá de maneira mais objetiva no final do ciclo, otimizando essa etapa.

  • Analista de teste.
  • Política para Registro de testes;
  • Backlog do ciclo contendo itens refinados e prontos para desenvolvimento;
  • Template: Tarefa de cenário de teste;
  • Template: Checklist de teste.

  • Criar planejamento de testes: Elaborar um plano de testes detalhado com os cards relacionados ao ciclo de desenvolvimento.

    • O analista deve:

      • Considerar os critérios de aceite;
      • Realizar alinhamento com o Analista de negócio / requisitos para esclarecer dúvidas de ambas as partes.

    • Os testes devem seguir as orientações definidas do documento Políticas para Registro de Testes.

    • O plano de teste é composto por um conjunto de cenários de teste.

  • Alinhar planejamento com os Analista de testes: O analista de teste deve revisar o planejamento de testes com os desenvolvedores par validar a sua aderência ao escopo.

  • Mapear cenários de testes: O analista de testes deve realizar a leitura completa do card para compreender o escopo e identificar os cenários necessários.

  • Criar tarefas para os cenários de teste: Os cenários identificados devem ser registrados como tarefas dentro do card que será testado, utilizando o formato BDD (Behavior Driven Development). Cada tarefa deve conter:

    • Título do cenário:

      • Ser curto, de fácil entendimento e deve ser precedido pelo título do card (obrigatório)

    • Exemplos:

      • "CL18 - Cadastrar item de compra - Cenário 1: Validar status da compra";
      • "CL18 - Cenário 1: Validar status da compra".

    • Status:

      • A tarefa de iniciar com o estado Open (obrigatório).

    • Responsável (assignee):

      • O analista de testes responsável pela tarefa (obrigatório).

    • Labels:

      • Adicionar a label "TESTES" (obrigatório);
      • Outras labels que auxiliem na identificação ou gestão podem ser incluídas.

    • Datas:

      • Informar as datas de abertura e fechamento (desejável).

    • Milestone:

      • Registrar o ciclo associado ao card principal e a execução da atividade (obrigatório).

    • Manter o card atualizado: O analista de testes deve atualizar continuamente o card no board da ferramenta de controle:

      • Sempre que uma tarefa for criada, associar a tarefa a um responsável;
      • Relacionar o responsável ao card principal que originou a tarefa.

Labels: A principal label utilizada nesta etapa do processo é: TESTES;

Templates: Cenário de teste - Vide Políticas para Registro de Testes.

  • Cenários de testes inseridos nos cards do ciclo de desenvolvimento.

Aguardando merge

Aguardando merge

A etapa "Aguardando Merge" tem como objetivo indicar que o desenvolvimento do código foi concluído e que está pronto para passar pela revisão necessária antes de ser integrado ao branch principal ou de destino. Essa etapa é crucial para organizar e monitorar o tempo entre a finalização do desenvolvimento e o início do processo de revisão.

  • Desenvolvedores: responsáveis por disponibilizar o código para revisão;
  • Revisores: Realizam a análise do código submetido no Merge Request (MR).

  • Para que um item seja movido para a etapa "Aguardando merge", é necessário:

    • O código-fonte deve estar disponível em sua branch de trabalho.
    • Todas as validações automáticas concluídas com sucesso, incluindo:
      • Testes unitários;
      • Integração contínua (CI);
      • Ferramentas de qualidade de código, como linters;
    • Os itens no board movidos para a etapa "Aguardando merge";
    • Os planos de implementação e detalhes técnicos registrados no card;
    • A solicitação de revisão por pares (merge request) criado.
  • Após a execução bem-sucedida dos testes unitários, o desenvolvedor deve mover o card correspondente para a coluna "Aguardado merge" no board;
  • Essa etapa permite visualizar o tempo necessário desde a disponibilização do merge request até o início da revisão, facilitando métricas de acompanhamento;
  • Notificar os revisores para da início à análise do código.
  • Itens disponíveis para revisão do merge request.

Revisando merge

Revisando merge

A revisão por pares ocorre após a implementação e é o momento em que o código fonte disponibilizado é analisado / revisado por outro membro desenvolvedor. Em complemento à revisão por pares, são executadas as ferramentas configuradas na esteira DevOps para que o código-fonte disponibilizado tenha a qualidade e segurança analisadas. Após esse processo, o código-fonte disponibilizado é integrado à versão estável do ambiente de desenvolvimento.

  • Desenvolvedores.
  • Itens disponibilizados no estado "Revisando Merge" no board;
  • Revisão por pares (Merge Request) solicitado;
  • Código fonte;
  • Ciclo registrado na ferramenta de controle;
  • Documento de Arquitetura.

  • Aprovar/reprovar Merge: O Desenvolvedor par do desenvolvimento deverá verificar o código-fonte disponibilizado pelo desenvolvedor e preencher o checklist de verificação de código-fonte para aprovar ou reprovar a implementação realizada. Em caso de reprovação, o Desenvolvedor par do desenvolvimento que fez a avaliação de sua requisição deverá comunicar ao desenvolvedor que efetuou a solicitação de que o código-fonte não foi aprovado e direcionar os ajustes que precisam ser feitos. Essa reprovação deve ser regitrada e detalhada no Merge Request;

  • Validar e implantar código-fonte através de esteira DevOps: Após a aprovação da revisão por pares feito pelo Desenvolvedor par do desenvolvimento (através da solicitação de Merge Request), a esteira de implantação irá realizar as validações conforme foi configurada, podendo apontar itens de correções ao desenvolvedor;

  • Corrigir problemas: O desenvolvedor que solicitou a revisão por pares (através da solicitação de Merge Request) deverá analisar e corrigir apontados na execução da esteira DevOps, caso tenha ocorrido algum problema na implantação;

  • Disponibilizar produto em desenvolvimento: Caso todo o código-fonte tenha sido aprovado, é incorporado à versão de desenvolvimento após a execução da esteira DevOps, e disponibilizado uma nova versão no ambiente de desenvolvimento.

Nota: Os cards devem ter seus estados alterados para "Aguardando testes em desenvolvimento" no board.

  • Checklist de verificação de código-fonte;
  • Produto disponibilizado no ambiente de desenvolvimento;
  • Itens disponibilizados no estado "Aguardando testes em desenvolvimento" no board.

Executar testes

Executar testes

A execução dos testes deve ocorrer após o planejamento e a implantação do card no ambiente de desenvolvimento. Bugs decorrentes de implementações correntes devem ser tratados no próprio ciclo de desenvolvimento, enquanto bugs pré-existentes devem ser tratados conforme o planejamento do ciclo.

Importante: As ações sugeridas na Política para Registro de Testes refletem boas práticas para garantir a qualidade. No entanto, algumas dessas ações podem depender da disponibilidade de pessoas e ferramentas par viabilizar suas execuções.

  • Analistas de testes;
  • Desenvolvedores;
  • Analista de negócio / requisitos. (opcional).

  • Validar da versão: O analista de testes verifica se a versão a ser testada está disponível no ambiente de desenvolvimento.

    • Testar produto em desenvolvimento:

      • Alterar o estado do card para "Testando em desenvolvimento";
      • Adicionar a label "TESTES" em todos os cenários de teste vinculados ao card;
      • Executar os cenários no ambiente de desenvolvimento.

  • Atualizar estado da tarefa de cenário de teste: Ao concluir e aprovar os cenários de teste no ambiente de desenvolvimento, atualizar o estado da tarefa para "Closed".

  • Caso o teste seja reprovado devido a falhas:

    • Manter a tarefa aberta.
    • Criar um novo card do tipo "Bug", associado ao card original (ver tópico “Tratar Bug / Erro / Defeito decorrente do desenvolvimento do card”).
    • Após a correção e aprovação do bug: - Encerrar a tarefa do bug e atualizá-la para "Closed". - Re-testar o card original, adicionar novas evidências e, se aprovado, atualizar o estado para "Closed".

    Seguir a Política para Registro de Teste para garantir o correto registro.

  • Evidenciar testes:

    • Durante a execução:
      • Atualizar os cenários mapeados de acordo com o andamento;
      • Disponibilizar evidências nos comentários de cada tarefa do card, indicando que o cenário foi executado.
    • Em casos de re-teste:
      • Inserir novas evidências nos comentários, mantendo o histórico.

  • Tratar BUG/ERRO/Defeito decorrente do desenvolvimento do card:

    • Classicar a falha conforme o ambiente:
      • Desenvolvimento: Bug;
      • Homologação: Erro;
      • Produção: Defeito.
    • Para falhas originadas no ciclo atual de desenvolvimento:
      • Criar um novo card do tipo "BUG";
      • Associar o novo card ao card original;
      • Priorizar o bug para correção no mesmo ciclo.
    • Ambos os cards (original e bug) devem ser re-testados somente após o tratamento da falha.

  • Solicitar implantação em homologação:

    • Após executar e aprovar todos os cenários de teste de uma demanda:
      • Garantir que não existam falhas bloqueadores;
      • Solicitar implantação no ambiente de homologação;
      • Alterar o estado do card para "Aguardando deploy em homologação".

  • Tratar falha pré-existente:

    • Identificar falhas que já estavam presentes no código antes da implementação atual;
    • Criar um novo card para a falha, classificando-a como: BUG, Erro ou Defeito;
    • Alterar o estado do novo card para "Open";
    • Detalhes adicionais estão disponíveis na Política para registro de teste.

    Nota: Os cards devem ter seus estados alterados para "Aguardando deploy em produção" no final do processo, no board;
    Labels: As principais labels utilizadas nesta etapa do processo são: TESTES, BUG, Erro, Defeito.
    Labels de Impacto: As principais labels de impacto utilizadas nesta etapa do processo são: Impacto: Baixo, Impacto: Moderado; Impacto: Alto;
    Labels de Causa da Falha: As principais labels de causa de falha utilizadas nesta etapa do processo são: CAUSA: Arquitetura; CAUSA: Requisito; CAUSA: Implementação; CAUSA: Ambiente.

  • Evidências de testes;
  • Itens disponibilizados no estado "Aguardando deploy em homologação" no board.

Implantar o produto em homologação

Implantar produto em homologação

Após a conclusão da etapa de testes no ambiente de desenvolvimento, os incrementos devem ser disponibilizados no ambiente de homologação para validação pelo Analista de negócio / requisitos. Em alguns times, o conceito de "pronto" considera a etapa de disponibilidade em homologação como parte do processo.

  • Analista de testes;
  • Desenvolvedores;
  • Analista de negócio / requisitos.
  • Itens disponibilizados no estado "Aguardando deploy em homologação" no board;
  • Casos de testes;
  • Política para registro de teste;
  • Template Erro.

  • Implantar produto em homologação:

    • Quando a versão estiver liberada para o deploy em homologação, o desenvolvedor deve:
      • Efetuar deploy da versão no ambiente de homologação;
      • Atualizar o card com a label "Aguardando deploy em homologação".

  • Preparar testes do produto em homologação:

    • O analista de testes deve:
      • Alterar o estado do card para "Testando em homologação":;
      • Confirmar que todos os cenários de testes já criados e executados no ambiente de desenvolvimento possuem a label "Testes"
        • Se algum cenário não possuir a label, esta deve ser adicionada;
    • Alterar o estado das tarefas de cenários de teste para "Open" e inicar sua execução no ambiente de homologação.

Observação: O processo de homogação deve garantir que os testes sejam realizados de forma criteriosa, validando os cenários previamente definidos e assegurando a qualidade antes da validação final pelo analista de negócio / requisitos.

  • Itens disponibilizados no ambiente de homologação;
  • Itens disponibilizados com a label "Aguardando testes em homologação" no board.

Revisar entregas

Revisar entregas

As validações finais no ambiente de homologação podem contar com a participação do cliente, dependendo do processo de trabalho acordado entre as partes.

Nesta etapa, a entrega é revisada, os testes são concluídos com sucesso e a implantação ocorre apenas após a validação.

A revisão da entrega é realizada de acordo com a periodicidade ou regras estabelecidas no Contrato Social do time.

Essa cerimônia tem como objetivo:

  • Apresentar os avanços do projeto para o Analista de negócio / requisitos e outros stakeholders.
  • Validar se os requisitos e critérios de aceite foram atendidos;
  • Coletar feedbacks sobre o trabalho realizado.
  • Cliente;
  • Stakeholders;
  • Analista de negócio / requisitos;
  • Gerente do projeto;
  • Desenvolvedores e Analistas de testes.

  • Atualizar estado da tarefa de cenários de teste em homologação:

    • Após a conclusão e aprovação dos cenários de teste no ambiente de homologação, o analista de teste deve:

      • Alterar o estado da tarefa para "Closed".

    • Caso o teste seja reprovado devido a falhas:

      • Manter a terefa aberta;

      • Criar um novo card do tipo Erro associado ao card original (ver tópico “Tratar Bug / Erro / Defeito decorrente do desenvolvimento do card”);

      • Após a correção do erro, encerrar o card de Erro como "Closed";

      • Re-testar o card original, adicionar evidências do novo teste e aprová-lo, caso não sejam identificadas falhas adicionais;

    • Seguir as orientações da Política para registro de testes para execução correta desta etapa.

  • Testar produto em homologação:

    • O analista de testes e o Analista de negócio / requisitos podem realizar teste no ambiente de homologação.

      • Considerações:
        • Utilizar os cenários previamente registrados ou criar novos, se necessário;
        • Realizar testes regressivos para garantir que funcionalidades existentes não foram impactadas;
        • Executar testes de aceite para validar o escopo de negócio;

    • Caso sejam identificadas falhas:

      • Seguir o processo descrito para o analista de testes na Política para registro de testes;

Importante: O analista que validar o ambiente de homologação não pode ser o mesmo que realizou os testes no ambiente de desenvolvimento.

  • Iniciar apresentação:

    • O Analista de negócio / requisitos inicia a reunião com a apresentação:
      • Do escopo do ciclo de desenvolvimento/incremento a ser homologado;
      • Das métricas obtidas durante o trabalho do time.

  • Apresentar resultados:

    • O time, ou um representante, apresenta sua contribuição no ciclo de desenvolvimento, que pode incluir:
      • Código desenvolvido;
      • Aplicação funcionando;
      • Documentos técnicos ou funcionais (como um spike)
    • Verificar se os critérios de Definição de feito (DOD) foram atendidos;
    • Consultar a Política de definição de pronto e feito para detalhes.

  • Tratar dúvidas:

    • Reservar um momento para responder a dúvidas do:
      • Time;
      • Analista de negócio / requisitos;
      • Stakeholders;
      • Cliente (se aplicável).

  • Analisar resultados:

    • O Analista de negócio / requisitos analisa os resultados do ciclo ou incremento, conforme as regras registradas no Contrato Social e indica o status do ciclo de desenvolvimento ou do incremento, com as seguintes possibilidades:

      • Aceito totalmente: todos os itens do ciclo foram aprovados;
      • Aceito parcialmente:
        • Situações opcionais, válida apenas se definida no Contrato Social do projeto;
        • Apenas os itens obrigatórios foram aceitos;
        • Se o contrato não prever entregas parciais, falhas em itens obrigatórios serão consideradas como não aceito;
      • Não aceito: Um ou mais itens obrigatórios foram reprovados.

    • Detalhar a análise e o aceite no Milestone (ciclo) avaliado pelo Analistade negócio / requisitos.

  • Solicitar implantação em produção:

    • Após a aprovação de todos os testes, o analista de teste deve solicitar o deploy da versão no ambiente de produção;
    • Atualizar o estado do card para "Aguardando deploy em produção."
  • Resultado (aceite total ou parcial ou não aceite) do ciclo de desenvolvimento.
  • Evidências de testes.
  • Itens disponibilizados no estado "Aguardando deploy em produção" no board.

Analisar e realizar entrega

Analisar e realizar entrega

Nesta etapa, a entrega é revisada e analisada. A implantação no ambiente de produção ocorre somente após a conclusão bem-sucedida de todos os testes no ambiente de homologação.

  • Analista de negócio / requisitos;
  • Gerente do projeto;
  • Desenvolvedores.
  • Produto disponibilizado no ambiente de homologação;
  • Itens disponibilizados no estado "Aguardando deploy em produção" no board.

  • Analisar a entrega:

    • O Analista de negócio / requisitos deve:
      • Avaliar os resultados apresentados;
      • Classificar o ciclo de desenvolvimento em uma das seguintes situações:
        • Aceito totalmente: todos os itens do ciclo foram aprovados;
        • Aceito parcialmente:
        • Situações opcional, válida apenas se definida no Contrato Social do projeto;
        • Apenas os itens obrigatórios foram aceitos;
        • Se o contrato não prever entregas parciais, falhas em itens obrigatórios serão consideradas como não aceito;
      • Não aceito: Um ou mais itens obrigatórios foram reprovados.

  • Implantar produto em produção:

    • Em caso de aceite total ou parcial, os Desenvolvedores devem:
      • Realizar deploy dos itens finalizados e aprovados no ambiente de produção;
      • Atualizar o estado dos cards implantados para "Closed".

  • Replanejar itens não aceitos no ciclo:

    • Em caso de não aceite, os cards não entregues devem:
      • Ser replanejados e transbordados para próximos ciclos;
      • Durante a reexecução, relacionar o novo ciclo de desenvolvimento ao Milestone do card;
      • Manter a estimativa registrada anteriormente.

  • Encerrar o ciclo de desenvolvimento:

    • O Analista de negócio / requisitos deve:
      • Formalizar o encerramento do ciclo de desenvolvimento;
      • Realizar registros pertinentes, independentemente do resultado do aceite (total, parcial ou não aceito).

  • Analisar desempenho do ciclo:

    • O time deve:
      • Comparar as métricas alcançadas no ciclo com as metas definidas no Contrato Social;
      • Verificar se a pontuação entregue e a velocidade alcançada estão de acordo com o esperado.

  • Analisar resultados das revisões em pares dos Merge Requests:

    • O objetivo desta análise é garantir a qualidade e eficiência do processo de revisão de código;

    • Considerações:

      • Verificar a quantidade de merge requests revisados e aprovados;
      • Identificar gargalos ou dificuldades no processo de revisão;
      • Avaliar a qualidade do código integrado;

    • Promover a melhoria contínua nas práticas de revisão, assegurando que as entregas atendam aos padrões de qualidade estabelecidos.

    Notas:

    • Os cards aceitos devem ter seus estados alterados para "Closed" no board;
    • Os cards não aceitos devem ter seus estados mantidos sem alteração no board.
  • Produto disponibilizado no ambiente de produção;
  • Itens aprovados disponibilizados no estado "Closed" no board;
  • Itens não aprovados mantidos no mesmo estado em que se encontram no board.

Analisar feedbacks

Analisar feedbacks

A cerimônia de revisão das operações tem como objetivo inspecionar o que foi desenvolvido no último ciclo de desenvolvimento, com foco nas interações entre indivíduos, processos, ferramentas e a definição de pronto, conforme melhores práticas. A periodicidade deve estar descrita no Contrato Social do time.

A Política Revisão das Operações deve ser consultada para assegurar que os objetivos e as etapas da cerimônia sejam devidamente atendidos.

Adicionalmente, é essencial adotar práticas para garantir a qualidade e eficiência do ciclo de desenvolvimento, como:

  • Monitoramento pós-deploy: Implementar ferramentas de alertas para identificar rapidamente problemas em produção.

  • Feedback contínuo: Coletar opiniões dos usuários finais e monitorar o desempenho da aplicação para direcionar melhorias futuras.

  • Gerente do projeto;
  • Analista de negócio / requisitos;
  • Desenvolvedores e Analistas de testes.

  • Quebrar gelo e introduzir cerimônia: O Gerente do projeto deverá, como facilitador, deve conduzir uma atividade de quebra de gelo ou introdução breve para criar um ambiente leve e acolhedor.

  • Inserir feedbacks:

    • Os Desenvolvedores e demais participantes devem:

      • Descrever feedbakcs positivos e/ou negativos sobre o último ciclo de desenvolvimento;

      • Lançar suas considerações em um tempo previamente definido para permitir que todos contribuam.

  • Discutir feedbacks levantados:

    • Cada integrante deve:

      • Ler seu feedback e explicar o motivo de levantá-lo para discussão;

      • Lembrar que o objetivo principal é a melhoria contínua do time e dos processos, evitando críticas pessoais ou improdutivas.

  • Registrar análise e planos de ação:

    • O Gerente do projeto deve:

      • Registrar feedbacks relevantes a melhoria do processo, como:

        • Plano de teste e checklist;

        • Documentação, implementação e etapas de testes;

        • Processos ou práticas que podem ser aprimorados;

    • Elaborar um plano de ação com base nos pontos discutidos, garantindo o acompanhamento de sua execução até a conclusão.

    • Considerar as saídas obrigatórias descritas na Política de Revisão das Operações.

  • Boas práticas complementares:

    • Monitoramento pós-deploy:

      • Monitorar o ambiente de produção para identificar problemas rapidamente;

      • Implementar dashboards e alertas que garantam a estabilidade do sistema;

    • Feedback contínuo:

      • Coletar opiniões dos usuários finais e monitorar o desempenho da aplicação;

      • Utilizar as informações obtidas para ajustes e melhorias futuras.

    Essas práticas, aliadas à colaboração entre equipes de desenvolvimento, QA e stakeholders, além da adoção de processos ágeis e automação, garantem um ciclo de desenvolvimento eficiente e de alta qualidade.

  • Conforme as saídas descritas na Política para Revisão das Operações;
  • Monitoramento Pós-Deploy;
  • Plano de Transição revisado / atualizado;
  • Registro da Retrospectiva no board.

Material de Suporte

Referências

Referências utilizadas para a elaboração deste processo: