CMMI e ITIL versus DevOps

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