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/
Uma prática de UX utilizando o Whatsapp

Uma prática de UX utilizando o Whatsapp

Existem várias práticas que podem identificar as necessidades, desejos e limitações de usuários durante todo o projeto, mas o grande desafio é utilizar essas práticas de uma forma que o usuário seja colocado no centro e conseguir a profundidade necessária para chegar à empatia sem levar dois anos de pesquisa para isso. É aí que o Whatsapp entra. Nesse artigo vou mostrar como essa ferramenta comum, que todo mundo usa, pode ser utilizada como instrumento de pesquisa.

Para a criação de personas é necessário traçar um perfil de uma amostragem grande de usuários. Mas como conhecer esses usuários? Indo a campo e conhecendo o dia a dia deles, porém é complicado chegar a um desconhecido e fazer várias perguntas sobre ele, até coisas pessoais que ele jamais contaria para um desconhecido.

Então o plano é:
Encontrar pessoas com perfis do público alvo desejado e abordá-los de forma convincente e empática, a fim de que participem da pesquisa voluntariamente, compartilhando tudo sobre suas rotinas diárias durante uma semana pelo whatsapp, em troca receberão um prêmio.

Para executar esse plano de ação, é necessário definir alguns itens:

1- Hipóteses e objetivos: Definir o objetivo da coleta de informações sobre os usuários para a criação de personas e montar uma estratégia de abordagem, considerando a possibilidades dos usuários aceitarem ou não fazerem parte da pesquisa.

2 – Referência de materiais e contextualização: Definir o material que será dado aos voluntários de acordo com o contexto e objetivo da pesquisa.

3 – Segmentação: Quem são, onde e como encontrar as pessoas com perfis do público alvo desejado?

4 – Formato do Kit: Definição do tipo de kit que será dado aos voluntários para apoio e instruções durante a pesquisa.

5 – Roteiro – Pré-diário: Escrever um roteiro detalhado com todas as regras da pesquisa para os voluntários.

6 – Roteiro – Whatsapp: Escrever um roteiro explicativo sobre frequências e assunto das conversas pelo whatsapp durante uma semana.

7 – Pontos para retornar – Pesquisados: Marcar uma data, horário e local para a formalização do fim da pesquisa e entrega dos prêmios.

8 – Definição do prêmio: Definir o tipo de prêmio que será dado de acordo com a verba disponibilizada.

9 – Termo de adesão da pesquisa contínua: Criar um termo com todas as regra de adesão e cancelamento da pesquisa.

10 – Autorização de uso de imagem: Criar um documento onde autoriza o pesquisador a utilizar informações e imagens dos voluntários.

Após a definição do plano de ação, o próximo passo é sair às ruas.

Ao encontrar pessoas com perfis do público alvo desejado, o pesquisador deve apresentar-se e explicar sobre a pesquisa. Se a pessoa aceitar a ser voluntário, é só formalizar o acordo:

Obrigada por aceitar compartilhar sua rotina do dia a dia conosco. A partir de agora, você é nosso voluntário e iremos conversar pelo whatsapp durante uma semana.

O pesquisador pega o numero do whatsapp da pessoa e dá a ele o kit com o roteiro do diário de Whatsapp, o termo de adesão, autorização de imagem e em seguida explica algumas regras da pesquisa:

Você precisa conversar comigo todos os dias pelo whatsapp, se cumprir com esse roteiro corretamente durante uma semana, ao final receberá o prêmio (Exemplo: 100 reais), porém se falhar com o roteiro, interromperemos a pesquisa e consequentemente você não receberá o prêmio. Daqui uma semana nos encontramos nesse mesmo lugar e nesse mesmo horário para finalizarmos a pesquisa e fazer a entrega do prêmio.

Após isso, o pesquisador deve conversar com esses voluntários durante uma semana para conhecer suas rotinas, como se fosse um diário.

Depois de uma semana, para finalizar, o pesquisador deve encontrar-se com os voluntários nos locais combinados, agradecer suas participações e dar o prêmio de cada um, conforme o combinado. Esses prêmios não precisam ser exatamente os 100 reais, mas qualquer coisa que estimule eles a ajudarem na pesquisa e ao mesmo tempo se encaixe no orçamento disponibilizado para o pesquisador.

Assim é possível utilizar uma prática de UX com uma ferramenta comum, utilizada por todos e obter informações reais, de pessoas com rotinas reais e ser muito mais preciso ao criar uma solução digital para o problema desse público.

Núbia Araújo

Núbia Araújo

UX/UI na Tegra

RxJs — Uma nova maneira de tratar assincronia

RxJs — Uma nova maneira de tratar assincronia

async é algo que já é parte do cotidiano de um programador JS, como ele é uma linguagem assíncrona muitos já se acostumaram com essa maneira de programar, o nosso querido EcmaScript já oferece alguns recursos para tratar isso como, Promises, Generators e o Async/Await. Porém hoje quero falar de uma nova maneira, o Reactive X, especificamente a implementação para JS.

Primeiro é importante falar sobre a Programação Reativa, que é uma maneira declarativa de tratar Data Streams. Mas o que isso quer dizer ? Vamos abstrair um pouco mais esse conceito, pense em um canal do YouTube, esse canal publica videos e existem inscritos que querem obter esse conteúdo então ao se inscrever em um canal o inscrito irá receber esse conteúdo até que uma das 2 coisas aconteçam, o canal pare de publicar videos ou o inscrito remover essa inscrição. Resumindo o canal do YouTube é um Data Stream nesse exemplo, e a programação reativa basicamente é uma maneira de lidar com todo esse fluxo de inscritos e emissão de conteúdo.

Falando um pouco mais agora sobre como o Reactive X nos auxilia a implementar a programação reativa, ele combina dois patterns que estão no GoF o Iterator e o Observer com alguns conceitos de programação funcional. Ele usa o Observer Pattern para obter dados ou eventos e além disso oferece vários operadores que permitem que você componha os streams de uma maneira declarativa.

Observable é o mais usado dos recursos do RxJs, ele representa uma coleção de dados ou eventos futuros, para tratarmos os dados emitidos por ele temos o Observer, onde definimos o que iremos fazer quando vier o próximo dado, quando der algum erro e quando acabar o stream. Além disso temos a Subscription que representa a execução do Observable e é utilizada para cancelar o mesmo, já que ele é como uma função e só será executado quando tiver um subscribe e não ao definir apenas o código.

O Reactive X oferece mais um recurso que é o Subject, ele é a junção de um Observable com um Observer. Ele emite o mesmo conteúdo para todos os inscritos, com ele você consegue controlar quando emitir o próximo conteúdo e assim que for emitido todos os seus subscribers irão recebe-lo. Possui vários tipos como o ReplaySubjectBehaviorSubject e o AsyncSubject.

You can build your app as one big observable… but please don’t

Essa frase foi dita pelo Ben Lesh, que é o principal mantenedor no RxJs e engenheiro no Google, e basicamente quer dizer que temos que sempre tomar cuidado para não usar esses recursos de uma maneira exagerada, temos que sempre lembrar que outros pessoas irão ler o nosso código, e elas tem que entender ele para poder dar suporte, porque ao trabalhar com eventos pode ficar um pouco confuso principalmente no começo, ler o código e entender como o stream está definido.

Então a minha dica final é comece a usar ele, porque só conseguimos entender realmente esses conceitos usando eles, combinando diferentes eventos, tratando diferentes cenários. É muito legal ver a evolução do seu código com o tempo, conforme você vai aprendendo a utilizar melhor os operadores o seu código vai melhorando, então treine, tente re-fatorar os seus códigos depois de um tempo e tente ensinar para outras pessoas também porque assim você aprende mais ainda!

Basicamente é isso que tenho pra hoje, até a próxima !

Boas práticas para mensagens de erro

Boas práticas para mensagens de erro

Quando o assunto é desenvolvimento de aplicações digitais, muitas vezes pensamos de maneira negativa no tratamento de erros, uma vez que, projetamos nossos sistemas para evitar os erros, certo? Pois bem, pensar em como tratar os erros e exibi-los de maneira amigável para nossos usuários é tão crucial quanto evitá-los. E acredite, por mais clichê que pareça, isso faz toda a diferença.

Para iniciarmos o assunto, proponho trocarmos o termo “mensagem de erro” para “mensagem de exceção”. Quando falamos em mensagens de erro, a aplicação foi projetada para ser usada de uma única maneira e o usuário desvia desse caminho feliz. No entanto, se pensarmos na abordagem do design resiliente, projetamos a aplicação dando a flexibilidade para que o usuário resolva problemas e explore as informações como desejar, e frente a situações inesperadas, orientá-lo para que sozinho resolva os problemas encontrados.

Partindo disso, darei algumas dicas de como pensar na experiência do usuário na hora de tratar os erros, escrevendo boas mensagens de exceção.

Exibição

O primeiro passo é pensar na maneira como exibi-la. A mensagem de exceção deve ser, sobretudo, diferente do conteúdo principal da página. Existem dois tipos principais de mensagens: a de página inteira e a em linha.

A mensagem de exceção em linha permite que o usuário interaja com o conteúdo principal da página e possa corrigir a condição de erro. É recomendável utilizá-la sempre que a exceção possa ser recuperada facilmente pelo usuário, como no caso do login inválido no Mailchimp.

Exemplo de mensagem em linha

Perceba que a mensagem ganha um destaque especial ao mesmo tempo em que os campos do formulário ficam disponíveis na tela, basta o usuário corrigir o username para prosseguir.

A mensagem de exceção de página inteira pode ser utilizada quando a condição de erro não é recuperável ou requer que o usuário execute alguma ação específica. Nesse caso, a mensagem deve ocupar mais ou menos a página inteira e os outros itens da tela devem ser escondidos para induzir o usuário a resolver a situação.

Exemplo de mensagem de tela inteira

No exemplo do Uber, quando o gps está desativado é necessário antes de mais nada, que o usuário o habilite, pois a ação principal da tela, que é pedir o carro, depende diretamente dessa ação.

Evite o uso de popups

Uma boa prática é evitar o uso de popups, pois as chances de o usuário ignorá-las sem ler o conteúdo são grandes. Além de que várias popups pulando a todo momento podem causar frustração.

Outro problema é que popups podem interromper o usuário no meio de uma determinada interação. Um exemplo, é o acesso a permissão da localização em aplicativos. Se ao acessar a tela o usuário não oferecer a permissão de acesso a localização, ao invés de exibir uma popup solicitando o acesso, podemos exibir uma mensagem no canto da tela solicitando a localização.

Popup de permissão de acesso a localização
Mensagem exibida quando a permissão de localização não foi concedida

Dessa maneira, informamos ao usuário de maneira clara que é necessário habilitar a localização e para qual finalidade ela é requerida, sem fazer o uso de popup.

Conteúdo

A comunicação com o usuário deve ser clara e objetiva, por isso, precisamos pensar com carinho no conteúdo que vamos exibir. Uma boa mensagem de exceção deve responder as seguintes perguntas:

O que aconteceu?

O que isso significa?

O que o usuário pode fazer sobre isso?

O que aconteceu?

A primeira pergunta é sem dúvida a mais difícil de ser respondida. Precisamos entender muito bem o que aconteceu e traduzir para a linguagem do usuário. Como explicar para alguém leigo em tecnologia a frase “Erro interno no servidor”? Não devemos utilizar termos técnicos e assumir que o usuário é o culpado pelo erro ocorrido.

Evitar iniciar as mensagens com palavras negativas é uma ótima maneira de ser um pouco menos agressivo e mais gentil com o usuário que está ali frente ao erro. Nesses casos, a dica de ouro é abusar da palavra do momento, a empatia.

O que isso significa?

Além de deixar claro para o usuário o que está acontecendo é importante explicar as consequências do problema. Digamos que a confiança do usuário nesse momento pode estar um pouco abalada, visto que acabou de receber um erro, por isso, é importante ser claro sobre a o que ocorreu. A frase “Podemos ter perdido seus dados devido a instabilidade na internet” é muito mais significativa do que simplesmente “Ocorreu um erro desconhecido”.

O que devo fazer?

Por fim, e não menos importante, é necessário direcionar o usuário sobre o que ele deve fazer frente ao erro, incluindo ações que possa executar para contornar a situação. Vamos evitar que nossos usuários fiquem com a sensação de “E agora, José?”. Ainda no exemplo do Uber, a ação “Ativar serviços de localização” ilustra bem como direcionar o usuário sobre o que fazer.

“Boas mensagens de erro dizem aos usuários o que deu errado — e possivelmente o porquê — fornecem uma ou mais soluções para corrigir o erro e oferecem um conjunto de botões que se relacionam diretamente à próxima ação que um usuário deve tomar.” — Rhonda Bracey

Símbolos e cores

Além das palavras, podemos reforçar as mensagens através de símbolos e cores, associando um estilo visual para cada tipo de mensagem. Vale ressaltar que é importante tomar cuidado com as cores, afinal, podemos ter usuários com deficiência de visão.

Exemplo de símbolos e cores para cada situação

O usuário lerá os símbolos como palavras, por isso, é importante usar símbolos e cores adequados para cada situação. A dica da vez é documentar esses estilos em um guia de estilos para que todos possam compartilhar e manter o padrão e consistência na aplicação.


Conclusão

A melhor mensagem de erro é aquela que não aparece. Mas, isso não elimina o fato de que podemos e devemos pensar no usuário até mesmo quando o assunto é tratamento de erros. Sempre que algo inesperado acontece, os usuários no geral, tendem a ficar inseguros sobre o que fazer e eles precisam de clareza e ajuda na aplicação, por isso precisamos ser legais e gentis com nossas palavras.

Pensar com um pouco mais de empatia, assumir que nosso usuário pode não ter conhecimento técnico e que ele não é responsável pelos erros, são os primeiros passos para tornarmos as mensagens de exceção mais humanas.

Até a próxima 🙂

Ana Gabriel

Ana Gabriel


Product Owner na Tegra
- Soluções Digitais, organizadora do Rails Girls Sorocaba, apaixonada em resolver problemas através da tecnologia, aprender e ensinar.

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?