Quero ser ágil

Quero ser ágil

Como ser ágil quando sua empresa precisa de aprovações de um comitê para realizar um deploy em produção e isso só acontece uma vez por mês?

Antes vamos entender um pouco o que é ser ágil

No modelo de desenvolvimento de software tradicional tínhamos muitos problemas, principalmente no que diz respeito a ecoo do projeto, pois era necessário logo no primeiro momento fechar ˜todo˜ escopo o que implicaria no cliente tomar uma série de decisões como o que ele quer e o que ele não quer antes mesmo de ter tido qualquer experiência com aquilo que ia ser desenvolvido. 

Depois do cliente conseguir idealizar o que ele gostaria e o que ele não gostaria, etapas subsequentes vinham com outros profissionais envolvidos e uma nova etapa só começava quando a anterior terminava e todas essas etapas levavam muito tempo.

E por isso depois de muito tempo desenvolvendo o software quando o cliente recebia, em muitos casos ouvíamos que não era isso que queria ou que ele precisava. E pior ainda acontecia quando o cliente precisava por algum motivo parar o projeto no meio do caminho ele não teria nada pra receber, não teria nenhum valor   “agregado” para o seu negócio mesmo depois de ter desembolsada um valor para investimento.

Para suprir essas deficiências é que o modelo de desenvolvimento ágil foi tomando espaço onde conseguimos desenvolver aplicações que possuem um certo entendimento da necessidade do cliente mas não um entendimento total, a construção é feita em conjunto e em ciclos “pequeno”, onde o cliente a cada ciclo recebe uma funcionalidade do software ou parte dela que possa agregar valor ao seu negócio. Essa execução permite que a equipe de desenvolvimento tenha feedbacks mais rápidos do cliente sobre o que está sendo desenvolvido permitindo que a respostas a mudanças sejam realizadas sem muitos impactos ou até mesmo sem impactos.

Existem vários métodos de desenvolvimento ágil ,um deles é o Scrum. Que é considerado um conjunto de ideias de trabalho onde o conceito de time é muito mais importante que o o indivíduo em si. Os quais  podem tratar e resolver problemas complexos de forma produtiva e entregar produtos com o mais alto valor agregado. Por isso, as características principais do time ágil são: equipe pequena, multidisciplinar e autogerenciáveis. Simples de entender, mas difícil de dominar!

No Scrum, os ciclos pequenos são chamados de sprints. As sprints podem ser de uma semana a até quatro semanas. As atividades que são definidas dentro uma sprint levam em conta quais atividades tem mais importância para ao meu cliente se desenvolvida em determinado momento. Isso gera entregas contínuas e que agregam cada vez mais valor ao cliente.

É muito importante que o time além de fazer, pratique os valores que estão envolvido no desenvolvimento ágil::

  • CORAGEM para fazer as coisas certas e trabalhar em problemas difíceis
  • FOCO para se concentrar no trabalho da sprint e nos objetivos da equipe
  • SE COMPROMETER pessoalmente em alcançar as metas da equipe
  • RESPEITAR os membros da equipe para serem pessoas independentes e capazes
  • O TIME deve concordar em estar com a mente aberta aos desafios com a realização do trabalho a fim dos STAKHOLDERS confiar mais e mais no trabalho dos desenvolvedores

Depois de entender um pouco do Scrum, vamos entender o que é DevOps.

DevOps – junção das palavras “desenvolvimento” de software e “operação” de software. Como entregar um software funcionando que pode ser gerenciado, escalável, mantido e cuidado facilmente. Isso é algo que o mundo da entrega de software precisa desesperadamente.

O ato de executar, manter e operar um software não era algo que fazia parte da realidade de um desenvolvedor e a forma como desenvolvemos e operamos um software hoje mudou drasticamente desde os dias em que o modelo de desenvolvimento ágil foi criado. A entrega contínua necessita de uma implantação automatizada de entregas, principalmente no que diz respeito ao ambiente produção.

Porém em muitos casos os times ágeis voltaram-se para a área que se sentiam mais confortáveis como a criação, desenvolvimento e testes de softwares, deixando de lado a entrega, implantação efetivamente dita. O problema dessa abordagem é que, ao separar o trabalho de construção e de implantação, junto com as atividades de gerenciamento de infraestrutura, estamos basicamente fazendo com que “o problema seja de outra pessoa” no ponto de vista da equipe ágil, e mais uma vez, a “Operabilidade” desaparece.

Podemos atribuir  que uma grande parte da culpa desse descasamento entre as equipes é da própria Empresa, pois de um lado ela cobra quanto a estabilidade e gerenciamento das aplicações, e do outro lado ela cobra mais entregas com valor agregado. No entanto, a empresa não dá o suporte necessário nem para a infra, garantindo os equipamentos e máquinas necessários para a “operabilidade”, nem para o time de desenvolvimento ágil como por exemplo: disponibilizando todos os ambiente necessários  para que o time realize os todos os testes para garantir a qualidade da entrega.

Por isso, podemos entender que o DevOps é a colaboração entre o desenvolvimento e a equipe de operações é olhar a infra-estrutura como parte do desenvolvimento de software. É um movimento cultural e profissional, focado em aumentar a comunicação, a colaboração e a harmonia entre o time de desenvolvimento ágil e os times de operações de TI para fornecer entregas contínuas aos clientes, com menor custo e menor percentual de bugs, derrubando-se assim as barreiras existentes entre os times.

Entendemos então que os valores da cultura DevOps são:

  • ELIMINAR a competição entre equipes de infraestrutura e desenvolvedores
  • MELHORAR o planejamento do ambiente produtivo, resultando em projetos entregues dentro do prazo e sem estourar o orçamento estimado;
  • EFICÁCIA no monitoramento das aplicações desenvolvidas devido a integração e colaboração entre as equipes;
  • Maior ESTABILIDADE e DESEMPENHO das soluções entregues;

COMO INTEGRAR SCRUM e DEVOPS

Já pensou em que acontece com todas as informações utilizadas ao final de cada Sprint?

Sim, todas as informações geradas nos ˜post-its internos, rascunhos e outros canais manuais são descartadas e nem se sequer chegam ao conhecimento da outra equipe de TI, por exemplo a equipe de infra que lidaria com o projeto na fase de implantação.

Com a integração entre a equipe de desenvolvimento e a equipe de operações toda documentação é compartilhada e a rastreabilidade fica acessível a todo o time de TI.

Dessa forma facilitaria até na organização do Product Backlog, tornando-o mais eficiente no processo de hierarquização de ações no projeto.

Os negócios dos nossos clientes mudam o tempo todo e muito rapidamente e a área de TI deve responder a essas mudanças. Para lidar com esse cenário, é preciso muitas vezes que TI mude todo o fluxo operacional, algo que pode ser feito com DevOps e Scrum com excelência!

Com isso, acredito que podemos responder a pergunta feita no início  “Como ser ágil quando sua empresa precisa de aprovações de um comitê para realizar um deploy em produção e isso só acontece uma vez por mês?”

Através do trabalho em conjunto do Scrum e Devops a fim de prover a verdadeira transformação das empresas!

Para refletirmos!

Será que não se faz necessário ter um DevOps no time Scrum já que ele é multidisciplinar? Isso não reduziria ainda mais a distância e quebraria as barreiras das áreas?