Visão geral do processo e dos procedimentos de desenvolvimento

Este documento fornecerá uma visão geral dos Processos e Procedimentos de Desenvolvimento da Leading2Lean. Este processo descreve as responsabilidades, políticas e procedimentos a serem seguidos pela Leading2Lean ao fazer alterações no serviço de produção e na infraestrutura. Todos os funcionários são obrigados a seguir esta política.

A Equipe de Tecnologia da Leading2Lean tem a tarefa de fornecer uma infraestrutura de TI estável e confiável para nossos clientes. O objetivo do Processo de Desenvolvimento é minimizar as interrupções de serviço em nosso ambiente de data center e promover a disponibilidade e a integridade do sistema. O Diretor Técnico (CTO) é responsável por manter e atualizar o Processo e os Procedimentos de Desenvolvimento conforme necessário. Este processo é ainda regido por controles organizacionais definidos como parte do nosso programa de conformidade AICPA SOC 2 Tipo 2. Esses controles são auditados anualmente por nosso auditor externo.

O processo de desenvolvimento começa com um desenvolvedor analisando o ticket, coordenando com colegas sobre arquitetura e design, escrevendo código, recebendo feedback da equipe de QA e, finalmente, liberando o software para os clientes. 

Escopo

Este documento define o ciclo de vida das solicitações de funcionalidades e dos erros. Ele também descreve os processos e procedimentos usados para garantir que testes e validações adequados ocorram para cada versão. Este documento não descreve o Processo de Gerenciamento de Mudanças conforme definido em nossa Visão geral da Política de Controle de Mudanças.

Definições

Backlog: Uma coleção de erros e funcionalidades cujo desenvolvimento ainda não foi iniciado. O Backlog é onde residem todos os tickets de menor prioridade. 

Erro: Uma funcionalidade que não está funcionando conforme deveria. Os erros podem variar de não graves a extremamente graves. A lista de Erros é onde residem todos os erros de menor prioridade. Os tickets são colocados na lista de Erros durante a reunião de Triagem. Os tickets são atribuídos aos membros da equipe de desenvolvimento a partir da lista de Erros.

Funcionalidade ou Aprimoramento: Comportamento que ainda não foi desenvolvido para o software. Isso pode ser uma modificação de uma funcionalidade existente ou a criação de uma nova funcionalidade.

Projeto ou Épico: Uma coleção de Erros e Funcionalidades. Os projetos são gerenciados no Roadmap. 

Roadmap: Uma coleção de Projetos. O Roadmap é o quadro de planejamento para projetos maiores. O Roadmap orienta o desenvolvimento de novas funcionalidades, grandes e pequenas. 

Triagem: Coleta de novos tickets. A lista de Triagem é onde todos os novos tickets são criados. A equipe de Triagem então colocará os tickets na lista de Erros, no Roadmap ou no Backlog.

Visão geral

Há 3 fases principais para cada ticket de desenvolvimento: 1. Planejamento, 2. Desenvolvimento e 3. Testes de garantia da Qualidade. Cada fase será discutida abaixo.

Planejamento

Utilizamos uma abordagem de triagem multidisciplinar para o processo de planejamento. Nossas equipes de Suporte, Desenvolvimento e Qualidade reúnem-se regularmente para uma Reunião de Triagem para avaliar novos problemas, solicitações de funcionalidades e aprimoramentos. Com base na gravidade, esses problemas podem desencadear um ciclo de resposta escalonada de interrupção/correção para restaurar o serviço em caso de itens de alta prioridade ou representar uma degradação no serviço. Caso contrário, recebem uma prioridade inicial e são encaminhados à nossa Equipe de Produto para planejamento, priorização e agendamento adicionais.

As funcionalidades normalmente são planejadas com a contribuição de um pequeno número de pessoas.  Isso pode incluir membros da Equipe de Produto, especialistas no assunto, clientes etc. Esse processo é conduzido pela nossa equipe de gerenciamento de produtos.

A maioria das solicitações de funcionalidades será discutida durante a reunião de Planejamento do Roadmap. Durante essa reunião, projetos e solicitações de funcionalidades escalonadas serão discutidos. Os projetos serão priorizados em relação a outros projetos, e as solicitações de funcionalidades serão analisadas e movidas para o backlog. As solicitações de funcionalidades podem ser vinculadas a um projeto no roadmap.

Desenvolvimento

Após a conclusão do processo de planejamento, esse trabalho é atribuído à equipe de Desenvolvimento. A equipe de Desenvolvimento possui seu próprio conjunto de ambientes de desenvolvimento que é um espelho do nosso ambiente de produção. Essa é uma parte essencial do nosso programa de Qualidade. Em cada etapa do nosso ciclo de vida de desenvolvimento (Desenvolvimento, QA, Staging e Produção), mantemos uma infraestrutura separada para garantir que qualquer trabalho concluído seja devidamente testado e verificado antes de entrar em nosso ambiente de produção.

Empregamos um conjunto completo de ferramentas de desenvolvimento padrão do setor, projetadas para controle de versão, testes automatizados, análise estática de código e limpeza do código. Essas ferramentas fornecem feedback antecipado e frequente ao desenvolvedor para garantir a melhor qualidade de código possível. Elas também ajudam a manter a separação adequada dos branches de desenvolvimento para evitar contaminação cruzada entre desenvolvedores que trabalham em diferentes projetos, tarefas e elementos da base de código. Essas ferramentas fornecem um método padronizado para revisões de código por pares e processos de aprovação, garantindo que qualquer código pronto para os Testes de Garantia de Qualidade tenha passado por todas as verificações automatizadas de teste e validação.

Nossos desenvolvedores se comunicam diretamente com a equipe de suporte, a equipe de produto ou outros desenvolvedores quando surgem perguntas sobre como implementar um ticket. Todas as alterações na UI exigem aprovação da equipe de produto. Como as alterações na UI impactam os clientes e podem exigir treinamento, trabalhamos com os clientes, o suporte e a equipe de produto para garantir que sejam tomados os devidos cuidados ao projetar quaisquer alterações na UI, minimizando o impacto sobre os clientes. Todas as alterações na UI também são revisadas pela nossa equipe de suporte durante a fase de Testes de Garantia de Qualidade para validar a existência da funcionalidade adequada e garantir que os clientes recebam as notificações e o treinamento apropriados.

Os desenvolvedores são obrigados a executar com sucesso nosso conjunto de testes automatizados em quaisquer alterações, como parte de seus procedimentos operacionais normais. Assim que o ticket passa por esses testes automatizados, ele está pronto para ser revisado por alguém que não seja o desenvolvedor. Esse evento permite que os principais membros da equipe saibam que é hora de fornecer feedback, além de indicar que o ticket está se aproximando do lançamento.

Todo o código é revisado por pares por outro desenvolvedor antes de ser encaminhado à equipe de QA. Isso ajuda a garantir que mais de uma pessoa conheça e entenda o que está sendo alterado e por quê. O objetivo de uma revisão de código deve ser refletir sobre o objetivo geral das alterações, revisar o código em busca de erros simples, verificar se há ineficiências no código, pedir esclarecimentos quando algo não parecer correto e tentar manter a consistência com os padrões de codificação e as melhores práticas. Às vezes, o desenvolvedor original refatorará o código devido ao feedback recebido durante a fase de testes. Se isso resultar em uma quantidade significativa de alterações no código, será realizada uma revisão adicional. Quando o consenso da revisão de código é registrado e documentado, o código está pronto para ser lançado para a equipe de QA

Testes de Garantia de Qualidade

Assim que o conjunto de testes automatizados for concluído com sucesso e sem erros, e a revisão de código tiver sido concluída com sucesso, a equipe de QA poderá iniciar o processo de Testes de Garantia de Qualidade.

As duas principais atividades envolvidas no processo de testes são a execução de scripts de teste automatizados e os testes manuais. A L2L possui um conjunto de casos de teste de UI e de unidade que são executados a partir da linha de comando. Também há um processo de linting que é executado no código para verificar erros básicos de programação. Todos os desenvolvedores devem executar tanto o conjunto de testes quanto o processo de linting antes de enviar seu código para revisão. A equipe de QA faz sua própria revisão dos resultados do conjunto de testes automatizados após implantar o código no ambiente de testes de QA. Isso garante que tenhamos um ambiente de testes limpo para avaliar a capacidade da atualização do código de funcionar conforme projetado e de acordo com nosso padrão de qualidade.

A equipe de QA coordenará os testes manuais do código para garantir qualidade adicional. O feedback da equipe de QA será incluído no chamado de desenvolvimento. Muitas vezes, o código precisará ser refatorado e atualizado antes que a QA dê sua aprovação. A QA indicará que o código está pronto para ser mesclado aprovando a solicitação de pull. A QA mesclará o código na base de código principal assim que tudo tiver sido aprovado. Isso garante que os desenvolvedores não possam mesclar código em nossa base de código principal e ignorar o processo de QA.

Durante a fase de Testes de Garantia da Qualidade, a equipe de QA também utilizará membros da equipe de suporte e o cliente para realizar testes de aceitação do usuário. Esses testes são vitais para garantir que as alterações no código sejam utilizáveis, atendam às necessidades dos clientes e estejam em conformidade com quaisquer regulamentações e requisitos do setor.

Processo de Controle de Alterações e Implantação em Produção

Para garantir que quaisquer alterações em nosso ambiente de produção sigam um processo padrão, implementamos um Processo de Gerenciamento de Alterações conforme definido em nossa Visão geral da Política de Controle de Alterações. Isso garante que tenhamos os controles e equilíbrios adequados na organização para assegurar a qualidade, a segurança e a disponibilidade do ambiente de produção. Para obter mais informações sobre esse processo, consulte o link acima.

É importante observar que, como parte do processo de controle de alterações, a L2L utiliza um script de implantação automatizado para liberar software do repositório de código para os servidores dos clientes. Em nenhum momento os funcionários atualizam manualmente o ambiente de produção. Esse sistema automatizado cria uma trilha de auditoria para cada nova versão/implantação e verifica se as aprovações adequadas estão em vigor. Depois que isso é concluído, os scripts de versão terão permissão para atualizar os servidores de produção. Esse script automatizado também fornece uma notificação interna da empresa sobre as implantações. Quando a implantação é concluída, esse sistema automatizado também executa "testes de fumaça" para validar se a implantação foi bem-sucedida e se o ambiente de produção está operando corretamente.

Reunião de Retrospectiva

Caso o código lançado faça ressurgir um problema antigo ou faça o sistema emitir um alerta, será realizada uma reunião retrospectiva, também conhecida como post-mortem. O objetivo da reunião será reunir os fatos relacionados ao lançamento do código problemático, discutir maneiras de evitar que eventos semelhantes aconteçam no futuro, atribuir tarefas relacionadas à prevenção de eventos futuros e educar a equipe sobre o incidente. Essas reuniões devem ocorrer dentro de 36 horas após o evento e devem envolver o maior número possível de desenvolvedores e membros da equipe de garantia da Qualidade para fins de análise da causa raiz e Treinamento. 

Notificação ao cliente

As Notificações aos clientes podem ocorrer várias vezes durante esse processo. Os clientes são frequentemente consultados durante as fases de planejamento, desenvolvimento e QA, bem como após o lançamento do código. O cliente será notificado das seguintes formas:

• Contato pessoal / Reuniões agendadas. Clientes envolvidos em projetos específicos de desenvolvimento podem ser convidados a participar de reuniões regulares de atualização para revisar planos, designs e o status do projeto.
• E-mail pessoal aos clientes. Todos os tickets de suporte originados serão atualizados informando ao cliente que a alteração foi lançada nos servidores de Produção, e o ticket será encerrado. Se um ticket de suporte não tiver sido criado, um representante de suporte poderá entrar em contato diretamente com o cliente. Se apenas um cliente tiver sido afetado por uma alteração, outras formas de notificação poderão não ser utilizadas.
• Registro de alterações. Todas as alterações que impactarem os clientes conterão um registro de alterações. Isso inclui correções de erros, atualizações menores e solicitações de funcionalidades. Quando uma alteração afetar apenas um cliente e o impacto for pequeno, e se um cliente tiver sido contatado diretamente, um registro de alterações poderá não ser adicionado. Os clientes podem acessar o registro de alterações no menu Suporte do Aplicativo.
• E-mail em massa. Um e-mail será enviado a todos os Administradores para todas as alterações grandes no aplicativo. E-mails em massa são usados principalmente para anúncios de produtos e grandes aprimoramentos da interface do usuário, mas podem ser usados em outros cenários.
• Notificações no aplicativo podem ser usadas para alterações impactantes.