Saiba qual a melhor forma de montar seu time DevOps

Na versão européia do evento DevOps Enterprise Summit, que este ano ocorreu em Londres, uma palestra do Matthew Skelton me chamou atenção. A palestra, intitulada “How and Why to Design Your Teams for Modern Software Development“, fala sobre como montar os times de Dev e Ops para permitir a construção de softwares com mais qualidade e com menos atrito entre as áreas.

Skelton e seu time de consultoria, motivados pela lei de Conway e de outros estudiosos das organizações, realizaram pesquisas de eficiência, eficácia e efetividade de diversas formas de se estruturar um time misto das duas principais áreas.

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

— Mel Conway, 1968

Os resultado dessas pesquisas estão compiladas no site DevOps Topologies, criado pelo próprio palestrante, onde são apresentadas diversas organizações de times de Desenvolvimento e Operações (Infraestrutura). São citados arquétipos negativos clássicos, chamados de anti-types, e os arquétipos que mais têm chance de trazer resultados positivos.

Dentro do que foi falado e mostrado, o que eu mais concordo é que a organização dos times ela é mutável no decorrer do projeto. Onde há uma fase de Colaboração, onde o time deve estar muito mais unido (inclusive fisicamente); após isso uma fase de Estabilização, onde os protocolos de comunicações (contratos, APIs…) já estão definidos e em fase de experimentação; e uma fase final de Uso, onde as APIs definidas são suficientes e pode haver um distanciamento entre as equipes, sem nenhuma perda sensí­vel de produtividade.

É neste modelo que acredito, pois há um alinhamento de expectativa e entrega entre as áreas. Esse alinhamento é fruto de uma comunicação clara entre envolvidos, realizada no momento correto. A partir da descobertas da fase de Colaboração foi possí­vel estabelecer as APIs e desenhos de pipeline, que permitiram o desacoplamento dos times (mesmo fisicamente) sem perda de qualidade.

E você? Quais suas experiências com diferentes setups de times ágeis?

DevOps – Colaboração entre Desenvolvimento e Infraestrutura

Recentemente, no mundo de TI está surgindo um movimento que prega uma maior integração para colaboração entre as as diversas áreas envolvidas no processo de criação e disponibilização de software dentro das empresas. Esse movimento é conhecido como DevOps e os principais nomes envolvidos são Gene Kim, John Allspaw, Paul Hammond, Andrew Shafer, John Willin e Eric Ries.

DevOps é uma amálgama do termo Desenvolvimento (Development, em inglês) com Operações de TI (IT Operations), mas não engloba somente essas disciplinas. No processo integral de criação/desenvolvimento de software temos também as disciplinas de QA (Quality Assurance) e Segurança da Informação. Estas também são parte importante do conceito de DevOps.

Uma questão importante quando se está idealizando (e disponibilizando) uma nova aplicação e/ou serviço é o tempo que todo esse processo leva até atingir um ní­vel de maturidade capaz de chegar ao mercado. O DevOps tenta reduzir o tempo dessas “entregas” para  rapidamente avaliar os resultados e propor ajustes nos desenhos da solução, baseando-se no conceito de MVP (Minimum Viable Product) do modelo Lean.

devops02

E por que não considerar somente o modelo Lean ao invés do DevOps? A resposta é simples: DevOps também se preocupa com uma entrega com qualidade, que deve ser atestada através dos testes de QA e uma entrega de infraestrutura fortemente automatizada, com criação e disponibilização de servidores, sejam eles fí­sicos, virtuais ou na nuvem, como parte integrante do deploy da aplicação.

Em próximos posts falarei mais sobre DevOps e como ele pode reduzir o grande gap de tempo e qualidade entre a área de negócios, onde as necessidades são criadas, e os clientes, onde o valor é entregue.