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 efetuar alterações no serviço de produção e na infraestrutura. Todos os funcionários são obrigados a seguir esta política.

A Equipa de Tecnologia da Leading2Lean tem a tarefa de fornecer uma infraestrutura de TI estável e fiável aos nossos clientes. O objetivo do Processo de Desenvolvimento é minimizar as interrupções do serviço no nosso ambiente de centro de dados 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 controlos organizacionais definidos como parte do nosso programa de conformidade AICPA SOC 2 Tipo 2. Estes controlos são auditados anualmente pelo nosso auditor externo.

O processo de desenvolvimento começa com um programador a rever o pedido, a coordenar com os colegas relativamente à arquitetura e ao design, a escrever código, a receber feedback da equipa de QA e, finalmente, a lançar o software para os clientes. 

Âmbito

Este documento define o ciclo de vida dos pedidos de funcionalidades e dos erros. Descreve também os processos e procedimentos utilizados para garantir que são realizados testes e validações adequados para cada lançamento. Este documento não descreve o Processo de Gestão de Alterações, conforme definido na nossa Visão geral da política de controlo de alterações.

Definições

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

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

Funcionalidade ou Melhoria: Comportamento que ainda não foi desenvolvido para o software. Pode tratar-se de uma modificação de uma funcionalidade existente ou da criação de uma nova funcionalidade.

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

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

Triagem: Recolha de novos tickets. A lista de Triagem é onde todos os novos tickets são criados. A equipa de Triagem irá então colocar os tickets na lista Bugs, no Roadmap ou no Backlog.

Visão geral

Existem 3 fases principais em cada ticket de desenvolvimento: 1. Planeamento, 2. Desenvolvimento e 3. Testes de Garantia de Qualidade. Cada fase será discutida abaixo.

Planeamento

Utilizamos uma abordagem de triagem multidisciplinar para o processo de planeamento. As nossas equipas de Suporte, Desenvolvimento e Qualidade reúnem-se regularmente numa Reunião de Triagem para avaliar novos problemas, pedidos de funcionalidades e melhorias. Com base na gravidade, estes problemas podem desencadear um ciclo de resposta escalado de interrupção/correção para restaurar o serviço no caso de itens de alta prioridade ou representar uma degradação do serviço. Caso contrário, recebem uma prioridade inicial e são encaminhados para a nossa Equipa de Produto para planeamento, priorização e agendamento adicionais.

As funcionalidades são normalmente planeadas com o contributo de um pequeno número de pessoas.  Isto pode incluir membros da Equipa de Produto, especialistas no assunto, clientes, etc. Este processo é orientado pela nossa equipa de gestão de produto.

A maioria dos pedidos de funcionalidades será discutida durante a reunião de Planeamento do Roadmap. Durante esta reunião, serão discutidos projetos e pedidos de funcionalidades escalados. Os projetos serão priorizados em relação a outros projetos, e os pedidos de funcionalidades serão analisados e movidos para o backlog. Os pedidos de funcionalidades podem ser associados a um projeto no roadmap.

Desenvolvimento

Assim que o processo de planeamento estiver concluído, este trabalho é atribuído à equipa de Desenvolvimento. A Equipa de Desenvolvimento dispõe do seu próprio conjunto de ambientes de desenvolvimento, que é um espelho do nosso ambiente de produção. Esta é uma parte essencial do nosso programa de qualidade. Em cada etapa do nosso ciclo de vida de desenvolvimento (Desenvolvimento, QA, Staging, & Produção), mantemos uma infraestrutura separada para garantir que qualquer trabalho concluído seja devidamente testado e verificado antes de entrar no nosso ambiente de produção.

Utilizamos um conjunto completo de ferramentas de desenvolvimento padrão da indústria, concebidas para controlo de versões, testes automatizados, análise estática de código e limpeza do código. Estas ferramentas fornecem feedback antecipado e frequente ao programador, para garantir a melhor qualidade de código possível. Também ajudam a manter uma separação adequada entre os ramos de desenvolvimento, de modo a evitar a contaminação cruzada entre programadores que trabalham em diferentes projetos, tarefas e elementos da base de código. Estas ferramentas fornecem um método padronizado para revisões de código entre pares e processos de aprovação, garantindo que qualquer código pronto para os Testes de Garantia de Qualidade passou por todas as verificações automatizadas de teste e validação.

Os nossos programadores comunicam diretamente com a equipa de suporte, a equipa de produto ou outros programadores quando surgem questões sobre a forma de implementar um ticket. Todas as alterações à IU requerem a aprovação da equipa de produto. Uma vez que as alterações à IU têm impacto nos clientes e podem exigir formação, trabalhamos com os clientes, o suporte e a equipa de produto para garantir o devido cuidado na conceção de quaisquer alterações à IU, minimizando o impacto nos clientes. Todas as alterações à IU são também revistas pela nossa equipa de suporte durante a fase de Testes de Garantia de Qualidade, para validar a existência da funcionalidade adequada e garantir que os clientes recebem as notificações e a formação adequadas.

É obrigatório que os programadores executem com sucesso o nosso conjunto de testes automatizados relativamente a quaisquer alterações, como parte dos seus procedimentos operacionais normais. Assim que o ticket passa nestes testes automatizados, está pronto para ser revisto por alguém que não seja o programador. Este evento permite que os principais membros da equipa saibam que é altura de fornecer feedback, indicando também que o ticket está mais próximo da publicação.

Todo o código é revisto por outro programador antes de ser enviado para a equipa de QA. Isto ajuda a garantir que mais do que uma pessoa sabe e compreende o que está a ser alterado e porquê. O objetivo de uma revisão de código deve ser refletir sobre o objetivo geral das alterações, rever o código em busca de erros simples, analisar o código quanto a ineficiências, pedir esclarecimentos quando algo não parece correto e tentar manter a consistência com os padrões de codificação e as melhores práticas. Por vezes, o programador original refatora o código devido ao feedback recebido durante a fase de testes. Se isto resultar numa quantidade significativa de alterações ao código, é realizada uma revisão adicional. Quando o consenso da revisão de código é registado e documentado, o código está pronto para ser lançado para a equipa de QA

Testes de Garantia de Qualidade

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

As duas atividades principais envolvidas no processo de testes são a execução de scripts de testes automatizados e os testes manuais. A L2L dispõe de um conjunto de casos de testes de UI e unitários que são executados a partir da linha de comandos. Existe também um processo de linting que é executado sobre o código para verificar erros básicos de programação. Todos os programadores devem executar tanto o conjunto de testes como o processo de linting antes de submeter o código para revisão. A equipa de QA realiza a sua própria revisão dos resultados do conjunto de testes automatizados após a implementação do código no ambiente de testes de QA. Isto garante que temos um ambiente de testes limpo para avaliar a capacidade da atualização do código de funcionar conforme concebido e de acordo com o nosso padrão de qualidade.

A equipa de QA irá coordenar os testes manuais do código para garantir uma qualidade adicional. O feedback da equipa de QA será incluído no ticket de desenvolvimento. Frequentemente, será necessário refatorar e atualizar o código antes de a QA dar a sua aprovação. A QA indicará que o código está pronto para ser integrado ao aprovar o pull request. A QA irá integrar o código na base de código principal assim que tudo tiver sido aprovado. Isto garante que os programadores não podem integrar código na nossa base de código principal e contornar o processo de QA.

Durante a fase de Testes de Garantia da Qualidade, a equipa de QA também utilizará membros da equipa de suporte e o cliente para realizar testes de aceitação do utilizador. Estes testes são fundamentais para garantir que as alterações ao código são utilizáveis, satisfazem as necessidades dos clientes e estão em conformidade com quaisquer regulamentos e requisitos do setor.

Processo de Controlo de Alterações e Implementação em Produção

Para garantir que quaisquer alterações ao nosso ambiente de produção seguem um processo normalizado, implementámos um Processo de Gestão de Alterações conforme definido na nossa Visão geral da Política de Controlo de Alterações. Isto garante que temos os controlos 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 este processo, consulte a ligação acima.

É importante notar que, como parte do processo de controlo de alterações, a L2L utiliza um script de implementação automatizado para disponibilizar software do repositório de código nos servidores dos clientes. Em nenhum momento os funcionários atualizam manualmente o ambiente de produção. Este sistema automatizado cria um registo de auditoria para cada nova versão/implementação e verifica se as aprovações adequadas estão disponíveis. Quando isto estiver concluído, os scripts de versão poderão atualizar os servidores de produção. Este script automatizado também fornece uma notificação interna da empresa sobre as implementações. Quando a implementação estiver concluída, este sistema automatizado também executa "testes de fumo" para validar se a implementação foi bem-sucedida e se o ambiente de produção está a funcionar corretamente.

Reunião de Retrospectiva

No caso de o código lançado fazer ressurgir um problema antigo ou levar o sistema a emitir um alerta, será realizada uma reunião retrospetiva, também conhecida como post-mortem. O objetivo da reunião será reunir os factos relacionados com o lançamento do código problemático, discutir formas de prevenir a ocorrência de eventos semelhantes no futuro, atribuir tarefas relacionadas com a prevenção de eventos futuros e formar a equipa sobre o incidente. Estas reuniões devem ocorrer no prazo de 36 horas após o evento e devem envolver o maior número possível de programadores e membros da equipa de garantia da qualidade, para efeitos de análise da causa principal e formação. 

Notificação do cliente

As notificações aos clientes podem ocorrer várias vezes durante este processo. Os clientes são frequentemente consultados durante as fases de planeamento, desenvolvimento e garantia da qualidade, bem como após o lançamento do código. O cliente será notificado através dos seguintes métodos:

• Contacto pessoal / Reuniões agendadas. Os clientes envolvidos em projetos de desenvolvimento específicos podem ser convidados a participar em reuniões regulares de atualização para rever planos, designs e o estado do projeto.
• Email pessoal para os clientes. Todos os pedidos de suporte originais serão atualizados, informando o cliente de que a alteração foi lançada nos servidores de produção, e o pedido será encerrado. Se não tiver sido criado um pedido de suporte, um representante do suporte poderá contactar diretamente o cliente. Se apenas um cliente tiver sido afetado por uma alteração, poderão não ser utilizados outros métodos de notificação.
• Registo de alterações. Todas as alterações que afetam os clientes incluirão um registo de alterações. Isto inclui correções de erros, atualizações menores e pedidos de funcionalidades. Quando uma alteração afetar apenas um cliente e o impacto for reduzido, e se um cliente tiver sido contactado diretamente, poderá não ser adicionado um registo de alterações. Os clientes podem aceder ao registo de alterações a partir do menu Suporte na aplicação.
• Email em massa. Será enviado um email a todos os Administradores relativamente a todas as alterações significativas à aplicação. Os emails em massa são utilizados principalmente para anúncios de produtos e grandes melhorias da interface do utilizador, mas podem ser utilizados noutros cenários.
• Notificações na aplicação podem ser utilizadas para alterações com impacto.