Jaap Schuttevaer fez um workshop sobre DevOps na conferência Agile Testing Day Netherlands 2015. O objetivo do workshop era para que as pessoas presentes experimentassem as abordagens Dev / Ops e DevOps. Como eles sentiam essas abordagens, qual era o impacto de DevOps e quais eram as vantagens e desvantagens.
Os presentes foram divididos em grupos, a tarefa dada para os grupos era transportar bolas de uma área para outra. A distância entre as áreas é de dois metros. Os usuários estão nas duas áreas, eles não podem caminhar com as bolas e não podem passá-las. Eles, portanto, precisam de uma ferramenta, uma solução que transfira as bolas.
Na primeira rodada, Schuttevaer apresenta a descrição do trabalho para as equipes e usuários utilizando uma abordagem Dev / Ops. Os membros usuários e de operações são enviados para outras salas, membros Dev (desenvolvedores, analistas e testadores) permanecem na sala. Cada equipe tinha um gerente de entrega que podia andar livremente entre as duas salas.
Os membros do desenvolvimento tinham uma caixa com materiais e uma user story para construir uma ferramenta para transportar as bolas.
Como usuário, preciso de um dispositivo para parar as bolas na zona final, para que possa transportar mais bolas por minuto para a zona de parada, porque quero que nossa equipe ganhe.
Enquanto isso, nas outras salas os usuários estavam pensando sobre a solução que eles precisavam. Por exemplo, alguns tentaram jogar as bolas e esperar que elas parassem na área de entrega e lá permanecessem.
O gerente de entrega andava entre os membros de desenvolvimento, usuários e de operações para verificar a solução desenvolvida. Quando viam a primeira solução eles solicitavam um manual de operação, já que os membros de operações precisariam de um para instalar a solução. Posteriormente um novo requisito foi adicionado: a solução não deveria ter uma interface de usuário. Os gerentes de entrega das equipes andaram bastante para comunicar aos desenvolvedores as necessidades dos usuários e de operações e verificar as soluções propostas pelos desenvolvedores.
Uma das equipes de desenvolvimento criou algo que pararia as bolas atiradas na área de destino. Outra equipe criou uma pista com bordas para guiar as bolas. Levantou-se a questão sobre o quão difícil seria instalar essas soluções. O que acabou sendo o caso quando os membros de operações tentaram fazer a instalação usando o manual. Enquanto isso, os usuários tinham que aguardá-las até que estivessem prontas, e os membros de desenvolvimento teriam que aguardar o feedback para ver se a solução havia funcionado ou não.
Para a segunda rodada, uma abordagem DevOps foi empregada. Todos agora estavam na mesma sala, analistas, desenvolvedores, testadores, gerente de entrega e operações. Rapidamente as equipes decidiram ir para a sala de operações para discutir e testar diferentes soluções. Desenvolvedores e testadores estavam juntos construindo uma solução, os usuários a utilizavam e davam feedback direto à equipe de DevOps.
Agora que desenvolvedores e operações estão trabalhando em conjunto com uma abordagem DevOps ficou claro como a solução deveria ser instalada. Nenhum manual era mais necessário já que os desenvolvedores podem ajudar na instalação.
Acabou que a solução desenvolvida na segunda rodada usando a abordagem DevOps foi melhor para as duas equipes e mais bolas foram transportadas quando eles a testaram.
Durante os esclarecimentos, Schuttevaer perguntou à platéia como tinha sido a experiência das abordagens Dev / Ops e DevOps. Algumas das conclusões foram que os gerentes de entrega quase não tinham o que fazer na abordagem DevOps e que as equipes DevOps tinham melhor coordenação permitindo que as pessoas conversem entre si e se ajudavam já que estavam na mesma sala. Na abordagem DevOps os desenvolvedores sabiam o que operações estava fazendo, o que os levavá a desenvolver uma solução melhor. Um participante disse que DevOps é uma maneira completamente diferente de organizar o trabalho, o que torna o resultado completamente diferente.
O InfoQ.com fez uma entrevista com Schuttevaer sobre o que DevOps pode trazer para as empresas, acabando com as barreiras entre Dev e Ops e pedimos conselhos para empresas que querem aplicar DevOps.
InfoQ.com: Na sua visão o que é DevOps e o que isso pode trazer para as empresas?
Schuttevaer:. DevOps é o nome do jogo de fundir desenvolvimento e operações.Quando as empresas adotam o Agile, implementando Scrum ou XP, o foco inicial é na vertente do Desenvolvimento de Produto. Um dos maiores desafios dessa fase é derrubar os muros entre os silos de conhecimento, formalizados por cargos como: analistas, programadores e testadores, e fazê-los trabalhar juntos.
Depois das primeiras batalhas para ter o Scrum funcionando, as equipes de desenvolvimento apreciaram a rapidez do ciclo de feedback e queriam incrementar isso ainda mais. Tipicamente as equipes de desenvolvimento querem publicar novas funcionalidades em Produção a cada sprint. Idéias como Entrega Contínua começam a surgir em suas mentes.
Então se torna aparente que na empresa existem alguns muros bem difíceis de se escalar. Muros que são grandes obstáculos para levar a produção uma nova versão de um produto. Esses muros se devem à separação entre os departamentos de desenvolvimento e do departamento de operações e manutenções.
InfoQ.com: Quais exemplos de barreiras existem entre Dev e Ops?
Schuttevaer:. Existem vários tipos de muros a serem derrubados. O primeiro tipo, e de fato a causa raiz para vários outros, é o muro organizacional. Empresas grandes tipicamente optam por ter uma distinção na organização de TI em departamentos que "mudam o produto" (Dev) e que "mantem o produto" (Ops). São vários os pontos negativos dessa decisão. Cada departamento é composto por gerentes e funcionários com uma mentalidade, responsabilidades e objetivos de desempenho bem específicos: Desenvolvedores ficarão focados em criar novas funcionalidades e Operações em manter a estabilidade.
Em muitos casos existe também uma separação física: o pessoal de desenvolvimento e de operações estão localizados em pisos diferentes ou até mesmo em prédios diferentes. E essa separação organizacional também resulta em uma atitude "nós e eles" - o hilário sistema no qual o departamento de desenvolvimento tenta jogar coisas "desenvolvidas" por cima do muro do departamento de operações, e o departamento de operações tenta se defender com uma enorme lista de "Critérios de Aceite de Produção" e checklists s serem preenchidos: "contratos precedem colaboração".
InfoQ.com: O que foi feito para acabar com as barreiras?
Schuttevaer:. O principal motivo para a existência desses muros é a separação organizacional do desenvolvimento e de operações em grupos desconectados. Para derrubar esse muro e para estabelecer cooperação transparente entre os profissionais de Dev e de Ops, a empresa precisa mudar. Isso não precisa (diretamente) ser uma mudança de hierarquia. Pode começar como uma mudança funcional. Então, comece por implementar DevOps por aumentar as equipes de Dev com gente de Ops.
E isso pode parecer fácil, mas vem com alguns bons desafios. Colocar pessoas em uma sala de equipe resolve o problema de separação física e a comunicação pode melhorar. Entretanto, é preciso superar algumas coisas mais básicas. Entenda que desenvolvedores tem pouca, ou quase nenhuma, experiência em tarefas, ferramental e responsabilidades que o pessoal de Operações tem. E vice-versa. Entendimento mútuo e colaboração não saem barato. É preciso ser estimulado e fomentado. E os "novos" membros da equipe de Operações não tem a mesma experiência de aprendizado Scrum que a equipe de desenvolvimento. E tenha cuidado porque a maioria das pessoas não aceita diretamente as mudanças.
InfoQ.com: Cite alguns conselhos para as empresas que querem aplicar DevOps?
Schuttevaer: Se quer aplicar o DevOps, existem vários conselhos a dar. A maioria se origina daquilo que eu já falei: reduza a distância física, leve em conta que mudanças levam tempo e vem acompanhadas de medo, lembra que o pessoal de operações não tem tanta experiência em trabalhar com uma mentalidade ágil como o pessoal de desenvolvimento já aprendeu.
Também aconselho empresas e equipes Scrum que querem implementar entrega contínua a manter em mente o primeiro princípio ágil: "Indivíduos e interações em detrimento a processos e ferramentas". Então, comece por fazer as equipes de Dev e Ops trabalharem bastante próximas, antes de se aventurar em processos e ferramental avançado de entrega contínua. E tenha em mente o objetivo final, porque DevOps resultará em maior vazão por sprint, feedback mais rápido e produtos de maior qualidade.