Voltar
Primeiramente, é importante definirmos alguns conceitos, principalmente como funciona o processo de desenvolvimento de um sistema/software.
Se você alguma vez estudou um pouquinho mais sobre processos de desenvolvimento de software, já deve ter ouvido falar sobre SDLC (Software Development Life Cycle ou Ciclo de Vida de Desenvolvimento de Sistemas, em português). O SDLC é um modelo que descreve as fases do processo de desenvolvimento de software, bem como a ordem em que elas devem ser executadas.
Quando estamos falando sobre SDLC, estamos falando de algumas etapas que devemos seguir para desenvolver um software. Lembre-se, dependendo da literatura que você consultar ligeiras modificações podem ocorrer nessas fases, tanto em relação a nomenclatura como a adição de uma fase ou outra.
A primeira etapa é o Design. Não estamos falando do design da interface da aplicação, estamos falando sobre o design da arquitetura, levantamento de requisitos, como será essa aplicação e como ela irá funcionar, quais são as regras de negócio.
Após a etapa de Design, se inicia a etapa que mais gostamos, o desenvolvimento da aplicação, de uma forma geral. Develop.
Já a área o ciclo de Test, garante que o software realmente está funcional e minimiza a chance de bugs em produção. Lembrando que há diversas formas de se testar software. Nesse caso, essa área de teste normalmente testa o software manualmente e também com o uso de algumas ferramentas específicas para isso.
E o Deploy? Basicamente, Deploy significa colocar o projeto em produção. Com relação há anos anteriores (como exemplo, podemos citar o FTP), o processo de deploy mudou muito, porque nos dias de hoje, as aplicações são extremamente mais críticas. Com aplicações mais críticas o processo de deploy acaba sendo mais complexo. Também não podemos deixar de citar que dependendo do tipo de aplicação, temos diversos tipos de deploy.
A área de operação, necessariamente, vai garantir que tudo esteja funcionando. Se caiu, por que caiu? Quais são os logs? Como está o monitoramento? Como podemos melhorar?
E para finalizar, a área de suporte será responsável por assegurar a interface com o usuário final, independente de quem ele seja. Essa área de suporte garantirá que o software sempre esteja funcionando de forma apropriada e será incumbido de manter as outras áreas (testes, desenvolvimento) inteiramente sincronizadas, para garantir a satisfação do usuário final.
Por muitos anos as empresas e os profissionais foram se tornando extremamente especialistas em suas áreas. Nesse momento, começamos a entender que os profissionais que desenvolviam projetos maiores, começavam a ser alocados especificamente em alguns daqueles bloquinhos do software development life cycle. Havia os programadores especializados em suas linguagens, o arquiteto, o tester, o responsável pelas operações, etc…Então, em cada bloquinho daquele, acabamos tendo, no final das contas, diferentes tipos de profissionais especializados para garantir que aquela fase, que aquela etapa do desenvolvimento de software, acontecesse da melhor forma possível.
As responsabilidades de cada membro eram bem claras, ou seja, o desenvolvedor só desenvolvia de fato, o responsável pela produção somente se preocupava em “subir a aplicação”, depois que tudo estivesse perfeito, etc…
Com as responsabilidades claras, ou seja, cada um cuidando do seu setor, havia um baixo entendimento do negócio como um todo. O desenvolvedor não precisava saber das nuances do negócio, pois o setor de requisitos era o responsável por essa parte.
Os profissionais não possuíam um senso de “ownership”. Eles se portavam somente como os especialistas de suas funções (como se fossem donos somente daqueles bloquinhos do SDLC).
A comunicação entre as partes envolvidas era bastante falha, pois a integração entre os setores era baixa (cada um fazendo o “seu”). Se acontecesse alguma falha em um outro setor, como o de desenvolvimento por exemplo, não era problema do setor de testes.
Os profissionais deverão continuar sendo especialistas no que fazem, porém, deverão ao menos conhecer de uma forma mais generalista os outros fluxos.
Com equipes multidisciplinares responsáveis pela aplicação, as responsabilidades individuais continuam bem claras, porém, há um entendimento do negócio como um todo, pois agora não tratamos de uma parte específica do processo e sim da generalidade da aplicação. Consequentemente, entendendo do processo de forma geral, as equipes começam a mudar o seu modo de ver o produto, tornando-se verdadeiros donos da solução/aplicação. O processo de comunicação tem uma melhora expressiva, pois a equipe está totalmente integrada ao processo como um todo.
Como chegar em um modelo em que equipes altamente integradas e multidisciplinares consigam diminuir ruídos de comunicação, aumentar o senso de ownership e ainda participarem ativamente no processo completo de desenvolvimento?
Como fazer com que profissionais realizem o fluxo completo de entrega e suporte do início ao fim?
Para responder essas perguntas, falaremos um pouco sobre uma empresa bastante conhecida, a NETFLIX.
Em 17/05/2018, a NETFLIX publicou um artigo, de mais ou menos 10 minutos de leitura, explicando essa jornada, essa solução perseguida por eles. Transformar o processo de desenvolvimento, tornando-o mais simples e eficaz do ponto de vista técnico.
Full Cycle Developers at Netflix — Operate What You Build
https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249
Os desafios eram os mesmos de qualquer empresa de tecnologia, uma vez que também aplicavam o método tradicional do SDLC, porém, a partir de muitos testes eles começaram a tentar integrar esses profissionais para tentar eliminar, principalmente, os ruídos na comunicação conseguindo dessa forma, tornar os processos de desenvolvimento mais rápidos e efetivos.
Com a ajuda de profissionais SRT ( Site Reliability Engineering, são os responsáveis que verificam se tudo está funcionando), acabaram por agregar algumas etapas do SDLC.
Com essa mudança, observaram que era realmente possível resolver todos os problemas no fluxo de desenvolvimento, de forma integrada.
Várias medidas foram adotadas, como por exemplo: a alta coordenação com o time de desenvolvimento e Treinamento constante.
Porém, continuavam alguns problemas, como:
Em uma segunda tentativa de melhoria, ocorreram muitas novidades, sendo que agora, os Devs poderiam fazer o push. Essa tarefa não fica mais somente a cargo da equipe de Operações, aumentando a flexibilidade e diminuindo o tempo de entrega. Esses Devs também ficaram responsáveis por problemas de produção e suporte, assim que a solução era entregue, os DEV’s são responsáveis pelo suporte e possível correção de problemas. O Feedback melhorou, as equipes se falavam mais e com isso ocorreu uma maior integração entre as áreas de Dev e Ops.
mas… quando release se tornava mais complicado, a solicitação ia para área de Ops…
Conforme as solicitações de alterações tornavam-se mais complexas, os devs evitavam os releases, enviando, portanto, tudo para a área de Ops.
Nesse ponto, a área de Ops não sabia mais o que priorizar, pois havia uma grande demanda, e diante dessa demanda e dificuldades, nasceu a ideia do Full Cycle Development
O Full Cycle Development parte de 3 pilares principais:
O desenvolvedor será responsável pelos processos de desenvolvimento e operação, ou seja, totalmente responsável pelo o que foi desenvolvido.
Responsabilidades atribuídas para cada time de desenvolvimento. Um time de desenvolvimento é responsável por um software, por uma aplicação, por um microsserviço. Você pode perceber, como exemplo, as similaridades com o modelo do Spotify, como ele começa a criar os squads, que são equipes multidisciplinares responsáveis por determinada solução.
Cada time é responsável pelo Deployment, Gerenciamento de Performance, Bugs, Suporte a parceiros, etc; sendo que o uso de ferramentas apropriadas, automação, pipeline definido, métricas, monitoramento e insight tools é imprescindível.
A ideia principal é de que um Full Cycle Developer participe de todas as etapas do processo.
O Dev Full Cycle deve ter um grande “Sense of Ownership”, ou seja, “Este produto/solução é meu, eu irei dar conta do recado, custe o que custar”.
Estar disposto a olhar para o mundo dos negócios da corporação. Estar atento aos negócios da corporação, e dessa forma, ter condições de entregar produtos e soluções cada vez melhores.
Desenvolver é totalmente diferente de programar. Quando você desenvolve, está criando a solução como um todo. Quando está programando, está inserido somente no primeiro bloco do SDLC.
Software entregue é igual a Software no ar funcionando e sendo monitorado, pois, um software/solução que não esteja funcionando direito não deve ser entregue.
Entender da área de operação: O desenvolvedor deve estar totalmente alinhado com a área de DevOps. O Desenvolvedor deve conhecer, nem que seja o mínimo possível de Ops para trabalhar de maneira satisfatória.
Resumindo, um profissional Full Cycle deve entender e realizar a operação de um fluxo completo de desenvolvimento. Dos commits iniciais até a produção e monitoramento.
É um caminho muito longo para nós desenvolvedores chegarmos, mas hoje em dia, a curto prazo, já temos formas para conseguirmos trabalhar.
O ideal é começarmos a nos perguntar:
O que está sendo mais usado nos dias de hoje?
Quais são as ferramentas que mais utilizamos hoje em dia?
Quais são as ferramentas que a empresa que trabalhamos está utilizando?
O que devemos aprender?
Como devemos aprender e qual a ordem que devemos aprender?
Se conseguirmos organizar um mapa mental, começaremos a priorizar e organizar melhor os nossos estudos e, consequentemente, teremos o esperado sucesso nessa nova jornada.
Disponibilizamos um mapa, com exemplos desse processo, para ilustrar tudo o que foi dito até agora:
Quantas dessas etapas já conhecemos e/ou dominamos?
Se a sua resposta foi “Somente o básico” ou “Não conheço quase nada do que vi”, só temos uma forma de mudar essa situação: ESTUDANDO, BUSCANDO CONHECIMENTO e APLICANDO em nosso dia a dia.
É muito importante termos em mente que agora para desenvolvermos uma solução/aplicação, não basta sabermos apenas programar ou dominar uma linguagem de programação, devemos entender o processo como um todo e aplicar, efetivamente, tudo que aprendemos sobre todas as áreas.
E aí? Preparado para essa nova jornada?
Se você está pronto para dar o próximo passo e avançar na sua carreira, solicite contato clicando aqui e nós te ajudamos.