Nossas metodologias

O Ágil

E a disciplina que estuda um conjunto de comportamentos, processos, práticas e ferramentas utilizados para a criação de produtos (geralmente de, mas não limitados a, software) e sua subsequente disponibilização para os usuários finais. As metodologias e frameworks que fazem parte do conceito de desenvolvimento ágil  providenciam uma estrutura conceitual para conduzir projetos de engenharia de software.

Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente cara a cara, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores técnicos e gerentes.

Métodos ágeis também enfatizam o software funcional como uma medida primária de progresso. Combinado com a comunicação cara-a-cara, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos, mas reduzindo o tempo de produção de documentação mais útil.

Valores ágeis de desenvolvimento de software

Segundo a página Agile Manifest - Manifesto ágil os valores relacionados ao Desenvolvimento ágil de software são:

• Indivíduos e iterações mais que processos e ferramentas;
• Software funcional mais que documentação abrangente;
• Colaboração do cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano

Ou seja, o item à esquerda sempre tem maior importância do que o item à direita

Princípios ágeis de desenvolvimento de software

Os princípios do desenvolvimento ágil valorizam

• Garantir a satisfação do consumidor entregando rapidamente e continuamente software funcionais;
• Até mesmo mudanças tardias de escopo no projeto são bem-vindas para garantir a vantagem competitiva do cliente;
• Software funcionais são entregues frequentemente (semanas, ao invés de meses);
• Cooperação diária entre pessoas que entendem do 'negócio' e desenvolvedores;
• Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
• A maneira mais eficiente e efetiva de transmitir informações é conversar cara a cara;
• Software funcionais são a principal medida de progresso do projeto;
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes para manter um ritmo constante indefinidamente.
• Design do software deve prezar pela excelência técnica;
• Simplicidade é essencial;
• As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
• Em intervalos regulares, a equipe reflete sobre como para tornar-se mais eficaz, então sintoniza e ajusta seu comportamento apropriadamente.

Práticas Ágeis de Desenvolvimento de Software

O desenvolvimento de software ágil é apoiado por várias práticas concretas, abrangendo áreas como requisitos, design, modelagem, codificação, teste, planejamento, gerenciamento de risco, processo, qualidade, etc. Algumas práticas notáveis ​​de desenvolvimento ágil de software incluem: ^[13]

Pratica
Desenvolvimento orientado a testes de aceitação (ATDD)	Kent Beck
Modelagem ágil	Scott Ambler
Teste ágil
Backlogs (produto e Sprint)	Ken Schwaber
Desenvolvimento Orientado por Comportamento (BDD)	Dan North , Liz Keogh
Integração Contínua (CI)	Grady Booch
Equipe multifuncional
Design dirigido por domínio (DDD)	Eric Evans
Desenvolvimento Iterativo e Incremental (IID)
Plataformas de desenvolvimento de baixo código
Programação par	Kent Beck
Pôquer planejando	James Grenning, Mike Cohn
Refatoração
Retrospectivo
Eventos Scrum (planejamento de sprint, scrum diário, revisão de sprint e retrospectiva)
Especificação por exemplo
Modelagem orientada por história	Albert Zündorf
Desenvolvimento orientado a testes (TDD)	Kent Beck
Timeboxing
História do usuário	Alistair Cockburn
Rastreamento de velocidade

Integração Continua

Feature branches são uma ótima maneira de organizar suas features , mas seu uso de forma exagerada, por equipes muito grandes e/ou com metodologias e mentalidades não-ágeis podem induzir ao surgimento de muitas (feature) branches que podem acabar sendo esquecidas quando se muda as prioridades e também favorece o surgimento dos famosos integrations hell.

O Git veio para resolver o problema de branches, mas como tecnicamente também é muito fácil criá-las as pessoas tendem a fazer muitas branches. Isso é hilário.

— George Dinwiddie 

Uma forma de contornar isso é usar a integração contínua, que parte do pressuposto que uma branch não deve ficar viva por muito tempo e nem ser muito extensa, ou seja, estamos sempre quebrando nossa tarefa em tarefas menores que podem ser entregues em partes menores e portanto nosso tempo trabalhando em uma branch que não é integrada com a base principal de código é menor.

Com a integração contínua estamos sempre pegando as novidades da branch principal e colocando em nossa branch a fim de diminuir os impactos de um eventual conflito e também temos como objetivo ter branches menores que vão ser integradas mais rapidamente de volta a nossa branch principal.

TLDR: Integração Contínua é quando continuamente integramos o código de nossa master com nossas feature branches e vice-versa.

Entrega Continua

É muito comum, principalmente em empresas mais antigas e engessadas que a entrega do software seja um marco. Muitas empresas até tem uma “equipe de implantação” que fica dias no cliente para se certificar que nada dará errado (ou corrigir todos os problemas que com certeza irão aparecer).

A entrega contínua vem para derrubar esse conceito de que implantar um software deve ser algo custoso, quando falamos em entregar um software continuamente, precisamos de ferramentas e uma arquitetura que permita uma rápida entrega e em caso de falhas em uma entrega, uma rápida recuperação, um rápido revert.

Como partimos do pressuposto que a entrega é contínua e pode ser feita a qualquer momento, todo código da sua master deve estar sempre pronto para ir para produção, a entrega contínua nos diz que não devemos ter grandes marcos de versões, entregas planejadas ou datas alocadas especificamente para equipes de testes testar as versões antes destas irem para produção.

A entrega contínua nos diz que todo commit na branch principal pode ir para produção, mesmo que ele de fato não vá, uma versão para ele vai (ou pode) ser gerada facilmente.

TLDR: Entrega Contínua é quando todo código da master está pronto para ir para produção e o processo de deploy/rollback é simples o suficiente para que seja possível colocar uma versão nova em produção sempre que desejarmos.

Além da entrega contínua

Com a evolução da integração contínua e entrega contínua um conceito interessante que surge é a diferenciação de “código pronto para produção” de “tarefa completa”.

Ou seja, assumimos que mesmo que a tarefa não esteja pronta o seu código está sempre pronto para entrar em produção, seja desativando sua execução através de configurações de usuário, variáveis de ambiente ou simplesmente não exibindo o link de acesso no menu.

Todo código pode e (deve) ser pronto para ir para produção, mesmo que a tarefa que ele implementa não esteja completa.

Assim, prezando sempre pela automação dos testes e facilidade de deploy/rollback assumimos que todo commit é um código potencialmente entregável.

Implantação Contínua 

O que impede a entrega contínua de sempre ir para produção é a nossa vontade e o apertar de um botão.

Quando o nível de automação de testes e de ferramentas de deploy/rollback estão maduras o suficiente o próximo passo é a automatização do deploy. Um novo conceito então é introduzido onde ao invés de “todo código pode ir para produção”, com a ajuda dessas ferramentas “todo código vai para produção”. Assim todo e qualquer commit feito na base principal de código será automaticamente testado, se todos os testes e controles automáticos de qualidade estiverem OK, automaticamente uma nova versão da aplicação é enviada para os servidores de produção.

Com a nova versão em produção temos um novo controle, de estabilidade do sistema, se o sistema se apresentar instável, a versão anterior é automaticamente restaurada e um aviso é disparado para a equipe.

Assim, chegamos na tão falada implantação contínuo e que muitas vezes é citado (erroneamente) como integração contínua.

Ou seja, a grande diferença da entrega contínua é que ao gerarmos a versão de produção, dependemos de um processo manual (ou semi-automático como um clique em um botão) para nosso código ir para produção, na implantação contínua temos as mesmas versões sendo geradas, mas temos a certeza de que estas versões automaticamente serão enviadas para nosso servidor de produção.

TLDR: Deploy contínuo indica que todo código commitado na branch principal automagicamente estará disponível em produção.

Scrum

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.