5. Processo de Desenvolvimento
Nosso processo de desenvolvimento é projetado para maximizar a eficiência, qualidade e entrega contínua de valor aos nossos clientes. Adotamos princípios ágeis e práticas modernas de engenharia de software para alcançar esses objetivos.
5.1. Metodologia Ágil
Utilizamos o framework Scrum com algumas adaptações para atender às necessidades específicas de nossa empresa.
Elementos-chave do nosso processo Scrum:
- Sprints: Ciclos de desenvolvimento de 2 semanas.
- Daily Standup: Reuniões diárias de 15 minutos para sincronização da equipe.
- Sprint Planning: No início de cada sprint para definir o escopo do trabalho.
- Sprint Review: No final de cada sprint para demonstrar o trabalho concluído.
- Sprint Retrospective: Para refletir sobre o processo e identificar melhorias.
- Product Backlog: Lista priorizada de todas as funcionalidades desejadas do produto.
- Sprint Backlog: Lista de tarefas a serem completadas durante o sprint.
Papéis-chave:
- Product Owner: Responsável por definir e priorizar o backlog do produto.
- Scrum Master: Facilita o processo Scrum e remove impedimentos.
- Equipe de Desenvolvimento: Responsável por entregar o incremento do produto a cada sprint.
5.2. Planejamento e Estimativa de Sprints
O planejamento eficaz é crucial para o sucesso de cada sprint.
Processo de Planejamento:
-
Refinamento do Backlog:
- Realizado continuamente, com uma sessão dedicada antes do Sprint Planning.
- O Product Owner apresenta os itens de alta prioridade.
- A equipe discute, esclarece dúvidas e divide itens grandes em menores, se necessário.
-
Sprint Planning:
- Duração: Até 4 horas para um sprint de 2 semanas.
- O Product Owner apresenta o objetivo do sprint e os itens prioritários do backlog.
- A equipe seleciona os itens que acredita poder completar no sprint.
-
Estimativas:
- Utilizamos o método de Planning Poker com pontos de história.
- Escala de Fibonacci modificada: 1, 2, 3, 5, 8, 13, 20, 40, 100.
- Itens maiores que 13 pontos geralmente são divididos em tarefas menores.
-
Definição de Pronto (DoD - Definition of Done):
- Código revisado e aprovado
- Testes unitários e de integração passando
- Documentação atualizada
- Testado em ambiente de homologação
- Aprovado pelo Product Owner
5.3. Revisão de Código
A revisão de código é uma prática essencial para manter a qualidade do código e compartilhar conhecimento entre a equipe.
Processo de Revisão:
-
Criação do Pull Request (PR):
- O desenvolvedor cria um PR quando a feature está pronta para revisão.
- O título do PR deve seguir o padrão:
[Tipo]: Breve descrição da mudança. - A descrição do PR deve incluir:
- Resumo das mudanças
- Link para a tarefa relacionada
- Instruções de teste, se aplicável
-
Revisão:
- Pelo menos dois desenvolvedores devem revisar cada PR.
- Os revisores devem focar em:
- Lógica e correção do código
- Aderência aos padrões de codificação
- Potenciais problemas de segurança ou performance
- Cobertura de testes
-
Feedback e Iteração:
- Os revisores fornecem feedback construtivo através de comentários no PR.
- O autor do PR faz as alterações necessárias e responde aos comentários.
-
Aprovação:
- O PR é aprovado quando todos os revisores estão satisfeitos com as mudanças.
- Para mudanças que afetam a produção, a aprovação final do CTO é necessária.
-
Merge:
- Após a aprovação, o autor do PR pode fazer o merge na branch de destino.
5.4. Integração Contínua (CI)
Nossa prática de CI garante que as mudanças de código sejam regularmente integradas ao repositório principal e testadas automaticamente.
Processo de CI:
-
Triggers:
- Cada push para qualquer branch
- Criação ou atualização de Pull Requests
-
Etapas do Pipeline de CI:
- Checkout do código
- Instalação de dependências
- Linting (análise estática de código)
- Execução de testes unitários
- Execução de testes de integração
- Geração de relatórios de cobertura de código
-
Ferramentas:
- GitHub Actions ou GitLab CI (dependendo do repositório)
- Docker para garantir consistência entre ambientes
-
Políticas:
- O merge só é permitido se todos os testes passarem
- A cobertura de código deve ser mantida ou aumentada
5.5. Entrega Contínua (CD)
Nossa prática de CD automatiza o processo de entrega de software, permitindo que implantemos com confiança a qualquer momento.
Processo de CD:
-
Ambientes:
- Desenvolvimento: Para trabalho em andamento
- Homologação: Para testes de QA e aprovação do cliente
- Staging: Réplica do ambiente de produção para testes finais
- Produção: Ambiente live para usuários finais
-
Fluxo de Implantação:
- Desenvolvimento -> Homologação: Automático após CI passar
- Homologação -> Staging: Manual, após aprovação do QA
- Staging -> Produção: Manual, após aprovação final do CTO
-
Estratégias de Implantação:
- Blue-Green Deployment: Para minimizar downtime
- Canary Releases: Para lançamentos graduais de novas funcionalidades
-
Rollback:
- Plano de rollback automatizado para cada implantação
- Capacidade de reverter para a versão anterior em minutos
-
Monitoramento:
- Integração com ferramentas de APM (New Relic, Datadog)
- Alertas automáticos para anomalias pós-implantação
Observações Importantes:
- Toda hora extra deve ser previamente aprovada pelo líder técnico ou superior hierárquico.
- A sincronização entre ambientes (hom, staging, prod) é responsabilidade do líder técnico.
- Todas as implantações em produção requerem aprovação do CTO.
- Mantenha uma comunicação clara com todas as partes interessadas durante o processo de implantação.
- Documente todas as implantações, incluindo quaisquer problemas encontrados e suas resoluções.
Ao seguir este processo de desenvolvimento, garantimos uma entrega consistente e de alta qualidade, minimizando riscos e maximizando o valor entregue aos nossos clientes. Lembre-se, o processo está sempre aberto a melhorias, e encorajamos todos os membros da equipe a sugerir otimizações baseadas em suas experiências.
Ter. 02 de jul - 2024