Meta Smart

Meta Smart

Todos nós temos objetivos, tanto no campo pessoal quanto no profissional, mas para que esses objetivos se tornem concretos precisamos de metas! 

Hoje vou falar sobre uma ferramenta que irá ajudá-lo a conseguir criar um planejamento baseado em estimativas reais, essa ferramenta se chama SMART e com ela, você será capaz de criar metas inteligentes, especificas, mensuráveis e alcançáveis. Então vamos tirar suas metas do papel e colocar em prática utilizando a ferramenta smart 

A palavra smart vem do inglês e significa inteligente, cada letra significa uma etapa no processo de criação da meta   

S –  Specifc (Especifico)  

M – Mensurable (Mensurável)  

A –  Achievable (Alcançável)  

R –  Relevant (Relevante)  

T – Time (Tempo)  

Específico  

A meta precisa ser bem especificada, não pode abrir margem para interpretações erradas, ela deve representar exatamente o que está buscando.  

Mensurável  

É o que tem que ser feito em termos quantitativos:  

Quanto mede?  

Quanto custa?   

Quanto pesa?      

Tudo que pode ser medido pode ser alcançável, esse item é responsável em nos ajudar no acompanhamento de nossa evolução com base em dados numéricos.  

Alcançável  

Atingir resultado é o que todos queremos, mas precisamos criar metas que condizem com nossa realidade.    

Relevante  

As metas precisam ser relevantes, precisam impactar positivamente, seja no profissional ou na vida pessoal.  

Tempo  

Quando?  

Definir data é importante, afinal é isso que queremos não é mesmo? sem uma data definida, certamente a meta ficará para um segundo plano, procrastinação em ação e ficaremos presos a encontrar um momento certo, mas a verdade é que não existe um momento certo para começar.  

Exemplo  

Definindo o objetivo: Comprar uma casa  

Após definido o objetivo, o próximo passo é aplicar a ferramenta smart, seguindo com o primeiro item “Especifico” precisamos detalhar melhor como vai ser essa casa, algumas das perguntas que poderiam ser feitas aqui são, a casa vai ter quantos quartos, quantos banheiros?, vai ter sala de estar?, vai ter garagem? Com quantas vagas? vai ter alguma área de lazer ou sala de jogos? a casa vai estar localizada em um determinado bairro de determinada cidade?, qual a cor dessa casa?, a ideia aqui é detalhar o máximo possível.  

No segundo passo, para o item “Mensurável”, para este objetivo estamos falando de valor financeiro, então quanto dinheiro precisamos ter para comprar este imóvel?   

Partindo para o terceiro item, “Alcançável”, depois de especificar e mensurar o valor que vamos precisar ter para comprar o imóvel, precisamos avaliar se está no nosso alcance e para isso podemos olhar para nossa situação atual e perguntar, temos condições de comprar este imóvel? E se não tiver todo o dinheiro disponível, temos por exemplo 80%? e os outros 20%? vamos precisar fazer um empréstimo bancário, mas e depois? Será que vamos conseguir cobrir esse empréstimo? essas são algumas situações que nós poderíamos nos questionar em relação ao item alcançável.  

Para o próximo item “Relevante”, precisamos encontrar algo que nos de força para lutar pelo nosso objetivo, o nosso combustível, é daqui que vamos encontrar a motivação para continuar, podemos pensar o seguinte:  

Oque nos motiva comprar este imóvel? seria para ter uma vida melhor, ou dar uma vida melhor para nossa família? Ou talvez realizar um sonho de ter uma casa própria e sair do aluguel?   

 Para o último e não menos importante item da meta smart, temos que definir uma data, dia mês e hora para o acontecimento, que dia vamos estar com as chaves em mãos para entrar nesta nova casa?  

Muitas vezes metas podem ser simplesmente uma mudança de hábito, uma atividade física até uma meta organizacional, é importante criar um planejamento, definir uma data para conclusão e utilizar métricas para acompanhamento, isso é a meta smart, por hoje é isso, espero que tenham gostado, até mais!

Engenharia do Caos

Engenharia do Caos

Engenharia do Caos
 
Engenharia do Caos significa realizar experimentos em sistemas distribuídos para construir confiança na capacidade do sistema e resistir a condições turbulentas em produção.
 
Em engenharia de software, cada vez mais ouve-se falar em micro serviços. Como desenvolvedores, conseguimos rapidamente adotar práticas para aumentar a flexibilidade de desenvolvimento e velocidade de implantação de sistemas. Com isso, surgiu uma questão: o quanto podemos confiar nesses sistemas complexos que colocamos em produção?
 
Mesmo quando todos os serviços de um sistema distribuído estão funcionando corretamente, as interações entre tais serviços podem causar resultados imprevisíveis. Circunstâncias não previstas, mesmo que compostas por eventos raros do mundo real, podem afetar sistemas em produção, possivelmente os deixando em um estado caótico.
 
Precisamos identificar as fraquezas antes que elas se manifestem em comportamentos inesperados no sistema. Problemas sistemáticos podem se manifestar de diversas formas, entre elas:
  • Comportamento inadequado quando um dos serviços encontra-se indisponível;
  • Múltiplas tentativas de conexão repetidas, normalmente causadas por Timeout mal-configurados;
  • Sistema fora do ar quando um tráfego muito grande de informações é recebido;
  • Falhas em cascata quando um único ponto sofre problemas;
  • Entre outros.
 
Devemos atacar essas fraquezas proativamente antes que elas afetem os usuários em produção. Precisamos de uma maneira de gerenciar o caos inerente nesses sistemas, conseguir tirar vantagem da flexibilidade e velocidade de desenvolvimento, e ter confiança em nossos sistemas em produção por mais complexos que eles sejam.
 
Uma abordagem prática consegue atacar o caos em sistemas distribuídos em escala e construir confiança na capacidade desses sistemas em resistir a condições realistas. Podemos aprender como é o comportamento do sistema a partir de observações em um ambiente controlado. Isso é chamado Engenharia do Caos.
 
Aplicação na Prática
 
Para atacar a incerteza gerada por sistemas distribuídos em escala, a Engenharia do Caos pode ser pensada como uma forma de facilitar os experimentos para descobrir fraquezas sistêmicas. Esses experimentos seguem quatro passos:
1. Inicia-se definindo um ‘estado estável’ como uma das medidas para indicar comportamento normal;
2. Cria-se a hipótese de que esse ‘estado estável’ se manterá tanto no grupo de controle e no grupo experimental;
3. Introduz-se variáveis que refletem eventos do mundo real como serviços fora do ar, discos rígidos quebrados, problemas em conexão de rede, etc;
4. Tentar averiguar a hipótese analisando as diferenças no estado estável entre o grupo de controle e o grupo experimental.
Quanto mais difícil for quebrar o estado estável, mais confiança temos no comportamento do sistema. Se uma fraqueza é descoberta, é necessário desenvolver melhorias antes que esse comportamento se manifeste no sistema em larga escala.
 
Conclusão
 
A Engenharia do Caos é uma prática poderosa que já está mudando a forma como software é desenvolvido nas operações de maior escala no mundo. Enquanto outras práticas ajudam a ter mais velocidade e flexibilidade, a Engenharia do Caos especificamente ataca a incerteza sistêmicas em sistemas distribuídos. Os Princípios do Caos ajudam a ter confiança em inovar rapidamente em larga escala e poder fornecer aos clientes a experiência de alta qualidade que eles merecem.
 
Quanto mais escalável é a aplicação que estamos desenvolvendo, maior a responsabilidade em manter essa aplicação estável independentemente de condições externas que possam eventualmente afetá-la. No mundo real, nem todo sistema é um Spotify ou Netflix, então tais práticas podem ser executadas conforme a complexidade e disponibilidade esperada do sistema. Para se ter uma aplicação realmente considerada resiliente, a Engenharia do Caos pode ser uma excelente técnica.
 
Referências:
Principles of Chaos Engineering – https://principlesofchaos.org/
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?