Uma arte chamada DevOps

Todas as vezes que sou perguntado sobre DevOps, logo vem na cabeça uma um enorme quebra-cabeças ou centenas de peças de lego, onde sempre procuro analisar todo cenário antes de sair montando as peças. Ao decorrer do projeto não tem como não se deslumbrar como a enorme vantagem que essa ferramenta pode nos proporcionar. É como construir uma ponte que após finalizado é simplesmente explicado e comprovada a agilidade e retorno de todo investimento. Sempre há onde melhorar e é isso que me motiva a continuar essa trilha. #GoDevOps

 

Como priorizar tarefas

Reflita se o que realmente está fazendo ou entregando terá maior valor agregado.

Nem sempre a maior entrega ou a mais demorada é a mais valiosa para a empresa.

DIFERENÇA ENTRE (CI) INTEGRAÇÃO CONTÍNUA E (CD) DISTRIBUIÇÃO CONTÍNUA

Atualmente muito se tem falado sobre Distribuição Contínua (Continuous Delivery – CD), por isso pode parecer um pouco antiquado ou ultrapassado falar sobre Integração Contínua (Continuous Integration – CI). No entanto muitas empresas estão tendo dificuldades ou não tiveram sucesso para implementar a CD. Isso deixa claro que existe um grande abismo que precisa ser superado sobre os aspectos fundamentais antes de se adotar a CD. A CI é a base fundamental cujos os princípios ainda não foram compreendidos ou implementadas com clareza, e portanto vale apena uma breve explicação.

Countinuous…

Integration é a forma mais rápida de se ter um feedback automatizado sobre cada mudança realizada no código.

Delivery é baseada no conceito anterior, porem o produto poderá ser promovido para o ambiente de produção a qualquer momento do seu ciclo de vida, bastando para isso ter o feedback esperado.

A premissa por traz da CD é que o software é sempre implementado constantemente entregue. Isso parece familiar para qualquer pessoa que conheça princípios ágeis. Uns dos primeiros manifesto ágil afirma:

“Nossa maior prioridade é satisfazer o cliente – sendo uma entrega parcial ou contínua”

Os pré-requisitos fundamentais para se realizar a CD são:

• Integração Contínua
• Gerenciamento de Configuração dos Ambientes
• Testes Automatizados

Integração Contínua

É o processo de execução do ciclo de vida do software, conhecido como BDT (Build – Deploy – Test). Esses processos são executado de forma automática e durante todo processo há uma constante comunicação entre os membros da equipe. Martin Fowler descreve o tema da seguinte forma:

“… Uma prática de desenvolvimento de software onde os membros de uma equipe possa integrar seu trabalho com frequência, havendo muitas integrações por dia. Cada integração é verificada por meio de uma compilação automatizada (incluindo testes) para detectar erros de integração tão rapidamente quanto possível. Muitas equipes acham que essa abordagem reduz significativamente os problemas de integração, permitindo outras equipes desenvolver software de forma coesa e mais rápida.”

CI fornece um quadro para detecção de erros de integração de software, permitindo que equipes desenvolvam software de forma unificada e mais rapidamente, sem sofrer com as terríveis integrações de códigos. A CI visa eliminar a incerteza dessa integração, incentivando os desenvolvedores a fazer check-in mais frequentemente. Ele não elimina a desafiadora atividade de mesclagem de código e a resolução de conflitos. Essa mesclagem de código e conflitos tende a diminuir com essas entregas de códigos mais constantes.

A figura abaixo ilustra o ciclo de integração utilizando ferramentas e um servidor de CI para implementar a prática.

O dia começa com o desenvolvedor pegando o código mais recente do servidor a partir de um repositório ou versionador.

• Depois há a atividade de desenvolvimento (guiado por testes unitários e automatizados, de preferência).
• O desenvolvedor está pronto para submeter o código para o repositório e precisa informar sua alteração.
• É realizada a atualização dos códigos em seu local de trabalho com o repositório (uma vez que outros desenvolvedores podem ter atualizado o código fonte).
• Se necessário é realizado o merge do código e todo conflito deverá ser solucionado.
• Gera-se o build localmente para se certificar que todos os testes passaram e nenhuma outra alteração possa ter influenciado na sua.
• É realizado o commit no repositório.
• O servidor de CI identifica que houve uma alteração no código do repositório e qualquer alteração desencadeia o ciclo de construção e testes automaticamente. Todos os membros são comunicados sobre o resultado de forma automatizada. Uma compilação é interrompida caso encontrado algum erro ou falha nos testes, e essa falha deve ser corrigida o mais rápido possível, tornando-se prioridade para que a construção do software volte a funcionar.

Por onde começar?

A partir da descrição sobre o ciclo de integração, são necessárias a adoção de certas práticas para fazer o CI eficaz.

Fonte única de repositório

Todos os arquivos necessários para construção do software (código fonte, scripts de banco de dados, referências de bibliotecas e arquivos de propriedades) precisam ser controlados por algum tipo de sistema de controle de versão, pois é a partir desse repositório que o servidor de CI monitora as alterações realizadas para acionar o BDT.

Por mais evidente que essa restrição possa parecer, algumas empresas não conseguiram atingir esse estágio de maturidade.

Construção automatizada

Mesmo com o controle de versão centralizado em algum lugar, muitas empresas ainda dependem de processos manuais para a criação de artefatos de software, que envolvem a coordenação entre silos organizacionais e membros de equipes. A premissa de CI, é que o processo de compilação deverá ser inicializado automaticamente (sem intervenção humana) ou somente com um simples clique do mouse.

Testes automatizados

Embora o teste automatizado não seja um pré-requisito, ele desempenha um papel fundamental no fornecimento de feedback confiável para a equipe, de que os componentes do software não estão somente integrados mas também funcionando corretamente.

Dica: Não deixe que o teste automatizado impeça no avanço de CI, mas não espere muito tempo para implementar e integrar, pois assim você poderá aproveitar todos os benefícios da prática.

Algumas “melhores práticas” aplicadas

• Commits frequentes
• Não permitir que uma compilação “quebre” quando realizado check-in
• Caso a build falhe, a solução deverá ser imediata e com prioridade máxima
• Construção de uma build não deverá ultrapassar 30 minutos (tempo ideal 10-15min). Quanto mais breve for o ciclo, melhor
• Separe teste unitário do teste de integração, assim você saberá o tempo exato de cada processo da construção do software
• Desenvolva projetos para recriar o banco de dados quando criada uma nova definição de build
• Construir, implementar e testar tipos de plataformas de produção
• Fornecer a capacidade de QA (quality assurance) para implantar builds em ambientes de produção

Quais são alguns equívocos?

CI é o mesmo que Builds noturnas ou diárias

Não é verdade. Uma build noturna ou diária é responsável por criar artefatos para consumo externo, ou seja, testes funcionais, QA ou revisão do produto.

Não utilizamos metodologia ágil, então não podemos utilizar CI?

Embora o termo “integração contínua” tenha sido introduzido por Extreme Programming (metodologia XP), o conceito da integração foi criado antes mesmo do XP. Na verdade, a CI é uma das menos controversas das práticas defendidas no XP e seus princípios são relevantes na adoção ou não da metodologia ágil.

Frequentes publicações “quebradas”

A aprovação do CI não significa necessariamente que a cada build completa (sem indicação de erros) deverá ser realizado um deploy em ambiente de produção. Uma boa implementação de CI deve fornecer a capacidade de tal forma que o QA ou outros membros da equipe possa implantar ou fazer o deploy quantos ambientes forem necessários, antes mesmo de ir para ambiente de produção.

Conclusão

O maior benefício do CI é a redução do risco na entrega final do projeto, pois a integração entre construção do software, automação de testes e implantação em ambientes são constantes, permitindo a qualquer momento a realização de entregas parciais para validação do cliente.

10 CITAÇÕES ÁGEIS DE MENTES BRILHANTES PELO MUNDO

Adotar a metodologia ágil pode ser uma tarefa muito difícil. Práticas ágeis são na sua maioria aprendido e experimentado, não é algo que você pode facilmente pegar de um livro ou artigo. Mas se você está em busca de valiosas citações ágeis para inspirar você e sua equipe, aqui estão 10 das mentes mais brilhantes do mundo.

1) “Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.” – Albert Einstein.

Como as organizações ágeis, equipes e membros da equipe, temos de questionar constantemente o que poderia ser melhor, a fim de melhorar continuamente.

2) “Perfection is not attainable, but if we chase perfection we can catch excellence.” -Vince Lombardi.

A perfeição é algo inatingível, mas se perseguir a perfeição podemos alcançar a excelência. Ser ágil é concentrar-se em fornecer a melhor coisa em um período de tempo definido.

3) “Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not. ” – Dr. Seuss.

Práticas ágeis é se concentrar e ter foco em atingir objetos com o time, e não atingir metas individualmente.

4) “Service to others is the rent you pay for your room here on earth.” – Muhammad Ali.

Serviço de liderança e altruísmo são princípios fundamentais da metodologia ágil. Estes são os preços a serem pagos para fazer parte de uma equipe ágil.

5) “You simply have to put one foot in front of the other and keep going. Put blinders on and plow right ahead. ” – George Lucas.

Ágil é fazer ao contrário ao ser paralisado pelo excesso de planejamento. Na metodologia ágil você precisa somente dos requisitos mínimos necessários para começar a trabalhar.

6) “It does not matter how slowly you go as long as you do not stop.” – Confucius.

Um princípio fundamental de ágil é estar trabalhando em um ritmo constante, que por sua vez permite que você entregar a um ritmo constante, em vez de trabalhar esporadicamente e entregar nada.

7) “We may encounter many defeats but we must not be defeated.” – Maya Angelou.

Você vai inevitavelmente passar por inúmeros desafios ao longo de sua carreia ágil, a chave é aprender com estes desafios e superá-los através reuniões diárias e retrospectivas.

8) “Intelligence is the ability to adapt to change.” – Stephen Hawking.

Ágil acima de tudo é adaptação à mudança. O time ágil deve estar pronto e preparado para se adaptar a qualquer mudança de requisitos.

9) “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.” – Thomas A. Edison.

Ser ágil como na vida. Haverá contratempos, mas a natureza iterativa do ágil faz com que seja fácil de fazer uma retrospectiva e aprender com os nossos erros, em seguida, passar para o próximo sprint e fazer melhor.

10) ”If you can dream it, you can do it.” – Walt Disney.

Nunca devemos esquecer que ágil foi formada para encontrar uma maneira de desenvolver softwares melhor e conquistar mais facilmente os nossos sonhos.

CONVENCENDO SUA EMPRESA A SE TORNAR ÁGIL

 

Mesmo com o passar do tempo muitas empresas continuam seus trabalhos e projetos utilizando práticas e metodologias ultrapassadas, onde pessoas passam muito tempo projetando e documentando as funcionalidades do sistema, criando alta dependência entre processos e pessoas.

Muitas empresas acreditam que ser ágil é o mesmo que ser informal, e isso não é verdade. Ser ágil dentre outras características, é ser formal apenas nos momentos nos quais a formalidade é necessária, não afetando o andamento do projeto.

A grande preocupação das empresas é o número de horas extras geradas em cada projeto. A realização de horas extras é um indicador de atraso no andamento do projeto. O grau de assertividade de um planejamento de 120 dias certamente é menor que um de 15 dias.

Metodologias ágeis estabelecem entregas semanais, quinzenais ou mensais, facilitando muito o planejamento e soluções de impeditivos no decorrer do projeto.

Outro grande problema enfrentado utilizando metodologias não ágeis é a entrega única, apenas no final do projeto.  Em alguns casos o pior acontece, ou seja, o “não aceite” do produto por parte de cliente. Esse cenário sem dúvida é um dos
mais críticos para um projeto pois tempo, dinheiro, expectativa e confiabilidade foram perdidas.

Entregas frequentes visa à construção de software simples, e conforme os requisitos surgem, há atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo requisitos de muito valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente, e a probabilidade de o software final estar de acordo com os requisitos do cliente.

A cooperação e a iteração constante entre cliente e equipe de desenvolvimento também são um dos pontos fortes nos processos de desenvolvimento baseados em metodologia ágil.

Outra característica muito importante do método ágil é a realização de rápidas reuniões diárias, onde são expostas de maneira pontual quais são as tarefas a serem executadas no próximo dia, o que estão fazendo ou se existe algum
impeditivo que possa causar algum impacto ou atraso no projeto.

Uma equipe ágil é formada por integrantes que possuem conhecimentos distintos, e todos trabalham com somente um propósito. Essa equipe é chamada de Multidisciplinar.

Um time multidisciplinar detém todo conhecimento do projeto em andamento, sabendo administrar o tempo e execução dos procedimentos para conclusão do processo. O time é auto gerenciável, dispensando qualquer tipo de gerente ou líder. Esse time não deverá sofrer nenhum tipo de influência externa, seja na execução, atribuições das tarefas, ou mesmo na manutenção do time.

Um dos grandes equívocos na execução de projetos é a concentração de esforço em um único indivíduo, mesmo que a produção seja um esforço coletivo.

Muitas empresas acabam cometendo esse equívoco involuntariamente, quando oferecem bônus por desempenho ou promoções por produtividade.
Em um artigo intitulado “The New New Product Development Game” [“O NOVO JOGO PARA O DESENVOLVIMENTO DE NOVOS PRODUTOS”], que descreveria que se tornou o SCRUM, os professores TAKEUCHI E NONAKA (Takeuchi, 1986) descreveram as características das equipes que viram nas melhores empresas do mundo:

1) Transcendência:  elas têm um senso de propósito além do comum. O objetivo percebido por todos permite que eles transformem o ordinário em extraordinário. De uma forma bastante verdadeira, a decisão de não estar na média, mas ser grandioso, muda o modo como eles se enxergam e o que são capazes de fazer.
2) Autonomia:  as equipes se auto organizam e se auto gerenciam; têm o poder de tomar as próprias decisões sobre como fazer o próprio trabalho e têm o poder de fazer com que tais decisões sejam acatadas.
3) Interfuncionalidade:  as equipes possuem todas as habilidades necessárias para concluir o projeto: planejamento, projeção, produção e distribuição. E tais habilidades alimentam e reforçam umas às outras. “Quando todos os membros da equipe se concentram em uma sala, a informação de alguém se torna sua, mesmo sem você percebe r. Então, você começa a pensar o que é melhor fazer primeiro e o que é melhor fazer depois pelo grupo como todo, e não apenas de acordo com o que é melhor para você”.
Um dos testes para saber se a equipe está no caminho certo é quando pergunta, digamos, para um engenheiro de rede: “Em que equipe você está? ”. Se a pessoa responder mencionando o produto em que estão trabalhando (automação ou integração, por exemplo) em vez de sua especialidade (ou seja, engenharia de rede), ela assente em aprovação. Quando um especialista se identifica mais com a sua especialidade do que com o produto que está desenvolvendo, então sabe-se que ainda tem trabalho a fazer.
Recomenda-se que um time ágil tenha no máximo sete integrantes, podendo haver variações de duas para mais ou para menos.  Quanto se tem mais integrantes na equipe, a velocidade costuma cair, ou se já, a equipe se torna mais lenta.

 

Um conceito chamado “Lei de Brooks”, [DE FRED BROOKS, O MÍTICO HOMEM-MÊS – 1975] diz que “acrescentar mais gente em um projeto de software atrasado resulta em um atraso ainda maior”. O atraso de um projeto não corresponde na velocidade do time e sim como o time está sendo gerenciado e de que forma estão trabalhando.

Uma das técnicas, ou teorias aplicadas em métodos ágeis, prega basicamente que podemos atingir 80% dos resultados esperados focando em apenas 20% das tarefas. Essa explanação parece muito simplista, mas quando aplicada à realidade de uma empresa que utiliza o desenvolvimento ágil, faz todo sentido.
Ao  invés  de  gastarmos  uma  grande  parte  do  tempo  fazendo  planejamentos enormes, criando artefatos gigantescos sem necessidade, vamos direto ao foco, no que realmente é importante, gerando resultados esperados com muito menos
esforço e desperdiço de tempo e dinheiro.

“Mudar ou morrer. Ficar preso ao mundo antigo de fazer as coisas, de mandar ou controlar e manter uma previsibilidade rígida resultará apenas no fracasso. Nesse meio tempo, a concorrência que estiver disposta a mudar deixará você comendo poeira”.  [SCRUM – A ARTE DE FAZER O TRABALHO NA METADE DO TEMPO – JEFF SUTHERLAND, POS. 449] (SUTHERLAND, 2014)

Referências
SOARES, M. D. (2001). Comparação entre Metodologias Ágeis e Tradicionais para o
Desenvolvimento de Software.
SUTHERLAND, J. (2014). Scrum – A Arte de fazer o trabalho na metade do tempo. LEYA BRASIL.
Takeuchi, H. a. (1986). The New New Product Development Game.

DOCUMENTAÇÃO EM PROJETOS

Documentação em Projetos

Nesse primeiro post irei abordar um assunto cada vez mais discutido em projeto Ágil, a necessidade de se documentar não só os requisitos do sistema, mas também o código fonte. Por mais claro e limpo que o código esteja, há a necessidade de se documentar, seja ela através dos “Sumary” (Code Clean – Robert C. Martin). Cada um tem um ponto de vista quando se trata de Documentação em projetos utilizando metodologia ágil, e não há certo ou errado pois as necessidades variam de projetos para projetos.

Descreverei abaixo algumas dicas para escrever documentação de projeto.

Criar ou escrever documentos só para se ter em um projeto é uma coisa, mas para criar documentação de alta qualidade, e que gere valor para o negócio é outra. Documentação de alta qualidade deve garantir absolutamente tudo que é necessário para o projeto de forma clara e sucinta.

Para ter essa documentação deve ser respeitado os seguintes passos:

Simplicidade

Certifique-se de que você mantenha sua documentação tão simples quanto possível, garantindo que você excluiu qualquer informação desnecessária. Crie os documentos utilizando termos claros e simples, limitando o uso de quaisquer abreviações ou termos que os outros não podem compreender. Isso irá garantir que os documentos são fáceis e rápidos de ler.

Foco

Concentre-se no tópico real quando você criar o documento. Pense cuidadosamente sobre o conteúdo que você vai adicionar ao documento. Liste seus temas. Nunca saia fora do tópico, pois isso pode confundir o leitor completamente.

Estrutura

Todos os seus documentos devem ter uma estrutura clara, incluindo uma tabela bem definida de Conteúdo. Você pode querer incluir em seu documento o uso de tabelas para melhorar a legibilidade, incluindo diagramas para explicar o conteúdo ainda mais, use negrito, itálico e sublinhado a deixar certas áreas, tais como títulos a se destacar e ao definir um número ou grupo de itens associados.

A História

Faça os seus documentos como se fosse uma história que você estivesse dizendo. Isto irá melhorar a legibilidade e garantir que você tenha um leitor cativado. Comece com uma introdução e informe ao leitor sobre o que é o documento. Em seguida, adicione o conteúdo ou o corpo principal e certifique-se que você feche o documento com um resumo ou conclusão.

Fluxo

Faça seu documento de tal forma que flui do parágrafo a parágrafo, e de tópico a tópico. Isso irá garantir que o leitor nunca precise parar de trabalhar para buscar informações em outras fontes.

Quantidade de informação

Fornecer ao leitor a quantidade certa de informações. Mantenha-o simples e curto, mas garantindo que ele é sobre o tema, informativo e útil. Nunca tente ou abordar temas ou tópicos não relacionados sobre o assunto, pois isso pode criar uma documentação longa e cansativa, gastando horas desnecessária na escrita e leitura do documento.

Inspiração

Ter domínio sobre o que está escrevendo e acima de tudo gostar do que está fazendo. Isso irá garantir que se crie uma documentação clara, inspirando ao desenvolvedor a criar o software utilizando as informações que você irá fornecer.