por
Arllen Lira*
As atuais práticas aliadas aos processos de desenvolvimento,
manutenção e entrega de software, como o MPS BR (Melhoria de Processos do
Software Brasileiro), o CMMI (Capability Maturity Model Integration) e a ITIL
(Information Technology Infrastructure Library) chegaram a uma alta maturidade
nos últimos anos, porém, observou-se que o engessamento destas práticas nos
departamentos e times envolvidos no fluxo de concepção, validação e entrega de
um produto de software criavam espaços vazios de espera em todo o processo ao
separar desenvolvimento, Quality Assurance e operações de TI.
Em contrapartida, a mentalidade DevOps, originada da indústria
moderna através do Lean Manufacturing, onera diretamente alguns tipos de
desperdícios que se devem ser evitados para reduzir custos e aumentar o retorno
sobre o investimento, pois propõe um maior fluxo e sinergia entre as partes
envolvidas, sempre com o foco para agregar cada vez mais valor e ganho de
velocidade no produto de um software desenvolvido.
Diversas comparações podem ser feitas entre a utilização do modelo
tradicional e as melhorias obtidas ao se adotar a metodologia DevOps no
processo de desenvolvimento. O primeiro entrega uma grande versão acabada de um
produto de software ao invés de pequenas entregas granulares e rápidas e que
podem responder facilmente aos impactos das mudanças, como prima a metodologia
DevOps. Outro ponto do modelo tradicional é gerar a espera ocupada de um
recurso até a finalização da tarefa de outro, como no caso do time de Quality
Assurance, que fica em espera até que o time de desenvolvedores termine toda a
implementação.
Para compararmos melhor os dois modelos, tradicional versus
DevOps, vale listar os setes desperdícios que o modelo tradicional gera e que a
mentalidade DevOps originada do Lean Manufacturing prevê que devem ser
evitados.
1) Superprodução : um release muito grande, com muitas
funcionalidades pode causar grande impacto na gestão de configuração, gestão de
qualidade e garantia do pós-entrega. O risco de um problema ser resolvido
levando-se mais tempo é maior e o esforço para mitiga-lo também.
2) Tempo de espera: entregas muito extensas geram mais tempo de
espera. O recurso fica esperando o outro finalizar sua tarefa para iniciar a
sua (espera ocupada).
3) Transporte: muitas funcionalidades novas sendo transportadas
para o ambiente de produção do sistema aumenta a entropia do mesmo para
absorver a mudança.
4) Excesso de processamento: para a saída para um grande release,
o time faz o mesmo processo várias vezes para diferentes artefatos, de
diferentes funcionalidades ou melhorias da mesma entrega.
5) Inventário: trazendo especificamente para a indústria de TI, o
inventário mais afetado é o de material em processo WIP (Work In Progress), que
são materiais, e, ou, componentes que já estão em fase de transformação para um
produto acabado. É comum, por exemplo, ver um kanban cheio de itens em WIP em
um release extenso. Isso aloca todos os recursos e gera um gargalo no
desenvolvimento, fazendo com que as outras partes envolvidas na parte
subsequente do processo fiquem em espera por muito tempo.
6) Movimento: imaginem várias funcionalidades em desenvolvimento
movimentando-se de uma raia pra outra do processo e, algumas vezes, voltando do
Quality Assurance para correções e ajustes. Dependendo do número de
implementações, isso pode gerar um ambiente caótico na mesma entrega para o
time todo.
7) Defeitos: Com uma entrega muito volumosa, aumentará também o
possível número de defeitos que podem ser gerados após o lançamento e, cada
defeito que avança em um projeto de software é dez vezes mais custoso para ser
corrigido em outra etapa.
Para sanar os problemas levantados ao utilizar-se do modelo
tradicional, a metodologia DevOps foca no Agile System Administration com
pequenas entregas, timebox curto e constante no ciclo desenvolvimento, além de
cerimônias regulares entre os envolvidos e trabalho incremental com ciclos
iterativos.
Nesta metodologia, a máxima integração e comunicação entre os
setores que fazem parte dos processos envolvidos no desenvolvimento e entrega
de um produto de software podem ser alcançado com maestria através da automação
de processos envolvidos.
Lembrem-se que a metodologia DevOps não é uma cartilha de regras
que devem obrigatoriamente ser seguidas. Trata-se de um guarda-chuva de
soluções em que o gestor e o time podem utilizar-se e incluí-las gradualmente
em seus projetos a fim de obterem a máxima sinergia, velocidade e qualidade
entre os times e os departamentos envolvidos na entrega de um produto de
software.
*Arllen Lira é analista de sistemas da GFT Brasil, companhia de Tecnologia da Informação especializada no setor financeiro