Sete desperdícios das metodologias tradicionais que o DevOps promete resolver

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 ser obrigatoriamente 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