Executando verificação de segurança...
1

[PERGUNTA] Toda o papo sobre DevOps é verdade? É/foi realmente uma revolução como alguns autores sugerem? Qual é a sua experiência com isso?

Olá!

Então, estou estudando programação há cerca de 2 anos e, no início deste novo ano, comecei meus estudos para descobrir o porquê de falarem tanto sobre Agile, DevOps, Scrum, CI/CD etc.

Terminei recentemente de ler The Project Phoenix e, embora os autores tenham me convencido de que a cultura DevOps é realmente uma melhoria que pode levar a lucros maiores para o negócio e uma vida melhor para todos os envolvidos, não posso deixar de ter algumas suspeitas quando alguém apresenta uma ideia ou conceito como algum tipo de solução garantida.

Também assisti a várias palestras “canônicas” (John Allspaw e Paul Hammond, Martin Fowler, Jez Humble) e todos parecem ter certeza de que descobriram qual é a melhor maneira de desenvolver e entregar software. E, novamente, eles também fizeram um ótimo trabalho em me convencer disso.

Sendo assim , o que me incomoda é quão poucos contrapontos encontrei. Parece que todo mundo que tem algo a dizer sobre tudo isso, só tem coisas boas a dizer. Então, gostaria de saber das pessoas que trabalham na indústria, qual é a sua experiência com DevOps e Agile? Isso é real ou está mais próximo de uma idealização acadêmica? Você já passou por algo parecido com o que acontece no The Phoenix Project, onde a adoção de uma cultura DevOps literalmente salva uma empresa?

Uma situação que eu estou bem curioso para saber se aconteceu com alguém é se você trabalha em um lugar que tentou implementar algum tipo de metodologia Agile, mas que resultou apenas em colocar um grande quadro branco em algum lugar e usar o software X em vez de Y (aliás , adoraria saber quais os softwares envolvidos, se for o caso), enquanto todo o resto do ciclo de vida de desenvolvimento de software ainda é o mesmo das últimas décadas. Isso aconteceu com alguém?

Por fim, agradeço a todos que responderem a isso. Preciso muito de informações reais de pessoas reais que trabalham na indústria. Livros e palestras de grandes nomes só podem levá-lo até certo ponto, principalmente quando são de outro país. Sugestões de leituras e afins que aborde essas minhas perguntas são mais do que bem-vindas.

Obrigado

Carregando publicação patrocinada...
2

Trabalho como DevOps Engineer fazem 4 anos. Passei por algumas empresas durante esse tempo e tive experiências diversas com relação a sua pergunta.

Então, gostaria de saber das pessoas que trabalham na indústria, qual é a sua experiência com DevOps e Agile? Isso é real ou está mais próximo de uma idealização acadêmica

Em minha experiencia os benefícios são reais sim, porém estão longe de serem como a idealização acadêmica. Qualquer metodologia, processo sempre vai depender do fator HUMANO.

O que quero dizer com isso é, na teoria você pode ter a solução para diversos problemas com metodologias como DevOps e Agile, porém se as pessoas de empresa não estiverem no mesmo "mindset" sobre isso, de pouco adianta.

Falando especificamente sobre DevOps, a ideia é que isso seja uma cultura onde existe uma aproximação entre os times responsáveis pela infraestrutura e pelo desenvolvimento a fim de reduzir o gap de responsabilidade de coisas como build, deploy, etc...

O que acaba acontecendo é exatamente o que o @blopes mencionou:

Sobre DevOps, as iniciativas que vi sempre tentam instituir um "departamento DevOps", e não há uma aproximação real entre devs e ops

Esse "Departamento DevOps" é composto por profissionais responsáveis por cuidar da parte de infraestrutura, mas que (idealmente) também tenha conhecimento na área de desenvolvimento. O objetivo de um time desses, na minha opinião, é tentar entender as dificuldades e desafios sendo enfrentados pelo time de desenvolvimento e ajudá-los a encontrar soluções, seja propondo o uso de novos serviços da Cloud, criando automações que vão reduzir o tempo de algum processo como build e deploy, etc..

Já trabalhei em empresas onde eu fazia parte de um time centralizado de DevOps, mas que cada membro do time trabalhava dentro de uma Squad de devs afim de tentar aproximar a realidade do "Dev" com o "Ops". O sucesso desse tipo de método, na minha opinião, depende altamente na qualidade de relacionamento interpessoal entre Devs e Ops (mais uma vez, fator HUMANO).

Algumas squads estavam felizes, e sempre procuravam o time de DevOps quando tinham algum problema, ou queriam arquitetar um novo projeto. Outras squads não gostavam do time de DevOps e viam eles sempre como um impecílio, e evitavam ter que se comunicar além do mínimo necessário.

Você já passou por algo parecido com o que acontece no The Phoenix Project, onde a adoção de uma cultura DevOps literalmente salva uma empresa?

Nunca passei por isso. Na realidade o que já vi é justamente o contrário... Algum executivo da emrpesa decide que a empresa vai adotar Agile ou DevOps, e tentar enfiar isso "goela a baixo" para o resto da empresa. Obviamente isso nunca funciona, e sempre acaba criando situações como mencionadas nas resposta do @blopes e da @duanyespindola

Os gerentes adoram colocar um grande Kanban bem visível e dizer para os chefes deles que "estamos usando SCRUM e metodologias ágeis" quando, na verdade, continuam não respeitando o escopo das sprints e "enfiando demandas urgentes" no meio, o tempo todo

Já vi falarem que estão usando SCRUM, mas não seguirem as partes mais importantes (SCRUM BUT...).

E já vi o oposto, ficarem tão fixados à algumas partes, que acabam ficando "escravos do método" e não obtém os benefícios possíveis.

Resumindo, acredito que essas metodologias tem sim o potencial de mudar drasticamente o caminho que uma empresa segue. O problema é que uma vez que elas viram Buzzwords, todo alto executivo começa a tentar forçar isso em sua empresa e acaba falhando uma vez que o fator humano entra em questão.

Metodologia e cultura são coisas que precisam ser cultivadas dentro de uma empresa. A mudança vai e tem que ocorrer gradativamente. Você tem que convencer as pessoas que existem benefícios reais, e assim elas vão começar a seguir isso instintivamente.

2

Sobre Agile, as experiências que tive não foram das melhores. Vejo que o pessoal não entendeu bem a ideia por trás dessas práticas.

Já vi falarem que estão usando SCRUM, mas não seguirem as partes mais importantes (SCRUM BUT...).

E já vi o oposto, ficarem tão fixados à algumas partes, que acabam ficando "escravos do método" e não obtém os benefícios possíveis.

Vejo que o pessoal de gestão se compromete com prazos impossíveis sem consultar os devs, e depois tentam obrigar os devs a entregar de qualquer jeito, sem prezar pela qualidade.

Isso gera retrabalho constante.

Sobre DevOps, as iniciativas que vi sempre tentam instituir um "departamento DevOps", e não há uma aproximação real entre devs e ops. Acredito que isso é o "normal" de acontecer no início. Com o tempo, melhora um pouco, mas não vira "uma Brastemp".

Há também uma grande resistência de devs à se adaptarem à nova rotina, pois pensam que tem que ser "outro departamento" que cuida das coisas operacionais.

Enfim, é o que eu tenho visto na prática.

1

Na parte de DevOps eu não tenho muito o que dizer... mas Agile! huahauaua

Lindo na teoria, talvez seja lindo na prática se você conseguir implementar.

Os gerentes adoram colocar um grande Kanban bem visível e dizer para os chefes deles que "estamos usando SCRUM e metodologias ágeis" quando, na verdade, continuam não respeitando o escopo das sprints e "enfiando demandas urgentes" no meio, o tempo todo ... acabando que cada ciclo você termina com um monte de coisas feitas mas nunca cumpre o escopo proposto.

Enfim... existem equipes, projetos, etc, que realmente seguem os princípios ageis. Mas nas grandes corporações isso é exceção e não regra.
Pra quem tá começando no mundo corporativo, 90% do trabalho vai ser fazer manutenção em sistema legado, lendo e tentando entender o que o fulano, que já saiu da empresa faz uns 10 anos, estava pensando naquela época.
Sem clean code, sem padrões, sem tecnologias cabulosas ... pura e simplesmente "fazer funcionar".

Daí, conforme você vai ganhando experiência acaba aparecendo oportunidades de projetos novos e, nessa hora, você tenta, na medida do possível trazer todas as boas práticas que você vem estudando.

De novo.. geralmente essas boas práticas não são bem assimiladas pelo resto do mundo (clientes) e como são eles quem ditam as regras.... você acaba com um MVP que é um sistema completo, acaba com um prazo que não te permite pesquisar as melhores alternativas, acaba fazendo o que já sabe que funciona e entrega codigo sem teste, sem documentação: "o mió que deu pra fazer na hora" e daí seu sistema vira o legado do próximo novato a ser contratado quando você sair da empresa! huehuehue

Mas não vou dizer que é sempre assim... conheço muita gente que está em projetos e equipes realmente organizados.

Basta um pouco de sorte!

Então, boa sorte e muito sucesso pra você!