Escolha uma Página

Desvendando FINOPS

Descubra como otimizar o orçamento de TI reduzindo custos da Nuvem

Por Luciano Osorio – Scrum Master da Zappts

FinOps é um modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI, para que os departamentos operacional e financeiro trabalhem juntos e com os mesmos objetivos.

FINOPS – Vantagens e Desafios da Nuvem

Vamos começar falando das vantagens da Nuvem.

Ela traz muita flexibilidade, é extremamente elástica quando é preciso aumentar ou diminuir a sua utilização.

Na Nuvem, é possível fazer diversos tipos de processamento e atividades diferentes dentro de um único ambiente, com a facilidade de um clique para contratar cada um desses serviços.

No entanto, a Nuvem traz algumas situações que precisam ser observadas e endereçadas, e eu vou explicar melhor sobre esses desafios a partir de agora.

Desafios da Nuvem

Tradicionalmente, o departamento de TI era responsável por definir quais os servidores seriam comprados, o armazenamento disponível e o poder de processo estaria disponível. Tudo isso era definido com antecedência dentro do planejamento financeiro anual da empresa.

Porém, com o advento da Nuvem algumas coisas mudaram e o programador passou a ter o poder de decisão sobre os recursos que precisa utilizar para poder fazer a inovação na qual está trabalhando.

Com isso, surge um problema: o departamento financeiro deixa de ter visão do que está sendo gasto com TI e isso pode trazer um problema de controle muito grande para a empresa.

A falta de controle de custos com TI pode gerar rombos enormes nos orçamentos, quando, por exemplo, a empresa possui uma aplicação que tem recursos e clientes, mas que custa muito mais caro se comparada ao retorno financeiro obtido com ela. 

Como evitar essa falta de controle?

Para evitar essa falta de controle de custos, um consórcio formado por grandes utilizadores da Nuvem propôs um modelo operacional que, quando aplicado, possibilita a retomada do controle financeiro sobre a infraestrutura estabelecendo uma linguagem comum entre os departamentos financeiro e de TI.

Assim foi criado o FinOps com o objetivo de:

  • Estabelecer o controle do que está sendo utilizado com recursos de TI;
  • Revelar quanto dinheiro está sendo gasto em infraestrutura;
  • Indicar quais departamentos e aplicações mais consomem os recursos e o orçamento de TI.

A partir da leitura desses indicadores, a empresa consegue provisionar adequadamente o budget para fazer as compras necessárias e limitar a infraestrutura daqueles pedaços da empresa que usam pouco a Nuvem.

A ideia do FinOps é simples: juntar as áreas de tecnologia e finanças para que ambas falem a mesma língua e estejam alinhadas nos mesmos objetivos.

As fases do FINOPS

O FinOps foi estruturado em três fases.

A primeira fase é a fase de informação, que vai dar visibilidade de quais são áreas da empresas que estão gastando mais, como esse dinheiro está sendo investido, quais recursos são de fato utilizados e quais podem ser trocados.

A área de informação vai gerar essa visibilidade para a área de negócios, o que possibilita uma tomada de decisão informada a respeito do que está acontecendo na Nuvem.

A segunda fase é a de otimização. 

Com base nas informações que foram coletadas, chega o momento de propor maneiras de otimizar o custo do serviço, de acordo com as finalidades para as quais a Nuvem está sendo utilizada.  

Após o processo de otimização, tem início a terceira fase do FinOps: a operação. 

Aqui, serão formalizados os custos dentro do planejamento financeiro da empresa, gerando budgets e reserva de dinheiro para a compra dos recursos de Nuvem que são necessários, com relatórios customizados que vão trazer informações do quanto está sendo utilizado de cada um dos serviços de Nuvem contratados. 

Quem está utilizando esses serviços? Quais são as aplicações que utilizam esses serviços? Quanto do serviço está sendo utilizado fisicamente?

Questões que podemos solucionar com assertividade a partir da utilização do FinOps como modelo operacional para a Nuvem.

Reduzindo custos da Nuvem com FINOPS

A partir de agora, você vai conhecer as ações estratégicas do modelo FinOps para reduzir custos da Nuvem, começando pelo tagging

FINOPS – Fase 1 – Informação

O tagging funciona da seguinte maneira: você vai dizer para cada um dos microsserviços que estão rodando na Nuvem qual é o departamento, aplicação e a área da empresa que está fazendo a utilização do serviço.

É possível utilizar diferentes combinações de informações para fazer o tagging, e quando ele estiver pronto, é preciso rodá-lo durante um tempo para capturar dados de consumo da Nuvem atribuídos a cada uma das grandes áreas dentro da empresa ou das aplicações que estão sendo utilizadas. 

Isso ajuda a segregar o custo e a direcioná-lo, bem como a fazer uma alocação de custo correta, a partir da identificação de quais áreas da empresa estão gastando mais do orçamento. 

Na sequência, vem a medição do quanto está sendo utilizado de cada um dos serviços. 

Neste ponto, existem duas situações possíveis: contratar um serviço e utilizá-lo por uma fração do tempo que ele estiver disponível ou contratar um serviço e gerar uma instância do mesmo, que ficará ativa por um tempo considerável e será utilizada pontualmente. 

Após algumas semanas fazendo essa medição, é possível gerar informação e prever o quanto será utilizado de um determinado recurso ao longo do tempo, o que vai ajudar muito na fase de operação, quando será estimado o orçamento.

Ainda na fase de informação, os reports serão fundamentais para levar toda informação coletada em diferentes formatos para os diferentes públicos: técnico, financeiro, gestão. 

Assim, é estruturada a cadeia de informação necessária para poder operar o FinOps.

FINOPS – Fase 2 – Otimização

É na fase de otimização que se trabalha toda a informação sobre os recursos da Nuvem que estão sendo utilizados, começando por considerar aqueles que estão acima ou abaixo do que a empresa realmente precisa: ou seja, os recursos super e subprovisionados. 

Os serviços em desuso podem ser removidos do plano de Nuvem, o que ajuda a reduzir o custo. 

Outra estratégia é trabalhar com a automação, utilizando robôs para o levantamento e derrubada dos serviços menos utilizados. Dessa forma, dá pra fazer o trigger dos serviços mais robustos quando for necessário.

Tendo a previsão do quanto será utilizado de cada serviço da Nuvem, é possível fazer a compra de instâncias reservadas com até três anos de antecedência, que pode custar até 43% mais barato do que uma instância sob demanda. 

Além de todas essas ações, o right sizing será um grande diferencial para o dimensionamento adequado do serviço para cada tipo de aplicação utilizada, assim como a comparação de preços, levando em consideração serviços semelhantes com custos diferentes. 

Está gostando do artigo? Aproveite e baixe o ebook com o passo a passo para a implementação do FINOPS. Conteúdo exclusivo e gratuito!

FINOPS – Fase 3 – Operação

Na fase de operação “levamos o negócio para dentro da Nuvem”, por meio de uma visão de negócio de longo prazo. Eu explico.

Nesse ponto do FinOps, traçamos objetivos de crescimento, melhorias na performance e definimos as quantidades de acessos no futuro.

Com os orçamentos definidos, é necessário fazer o alinhamento do custo da Nuvem com os objetivos para chegar a conclusão sobre o quanto já foi atingido e qual o ritmo de investimento adequado para alcançá-los totalmente. 

É imprescindível ter governança nessa fase, por meio de relatórios periódicos do consumo do budget que foi reservado para a Nuvem, indicando o crescimento de uso da aplicação e o retorno que isso tá trazendo para o negócio.

Importante: aumentar o custo da Nuvem não significa, necessariamente, a existência de um problema. 

Vamos pensar na utilização de um serviço online, por exemplo, o Uber. 

Quando foi lançado, o Uber tinha pouca densidade de utilização. Com o tempo, o negócio foi ganhando escalabilidade, muitas pessoas começaram a consumir o serviço, e portanto, muitos mais recursos da Nuvem foram necessários para suprir a demanda.

Ou seja, o aumento do custo da Nuvem, em si, não é necessariamente um problema, porém, é preciso ter algum tipo de indicador que mostre o custo da Nuvem por usuário e esse valor tem que ser constante ou um valor que caia ao longo do tempo, a menos que se esteja implementando uma nova tecnologia ou funcionalidade, que apresentará oscilação no custo.

E concluindo a fase de operação, as melhorias devem ser constantes, considerando tudo o que mencionei até aqui, como por exemplo, melhorias na maneira como as aplicações estão sendo construídas e no tagging.

Aplicações que não estão sendo tagueadas, deixam de gerar visibilidade de como o custo está sendo consumido. Assim, uma “fatia” do custo da Nuvem deixa de ficar clara para a tomada de decisão e departamentos envolvidos (TI e financeiro).

Então, é muito importante acompanhar periodicamente os diversos indicadores que serão criados no momento de visibilidade e investir em melhorias da performance desses indicadores. 

FINOPS – Case Nubank 

O Nubank, fundado em 2013, é o maior banco digital independente do mundo, com mais de 20 milhões de clientes em todo o Brasil.

Quando iniciou a jornada de FinOps, não tinha visibilidade alguma do quanto estava gastando na Nuvem, com uma tendência de explodir os custos de nos próximos meses de utilização. Então, o Nubank adotou uma estratégia.

Primeiro, o banco passou pela fase de visibilidade e estabeleceu um indicador muito importante: o de custo da Nuvem por cliente. 

Esse índice considera uma massa de clientes para dividir o custo da Nuvem.

Dessa forma, o Nubank conseguiu monitorar, ao longo do tempo, como o custo da Nuvem estava crescendo para cada “x” quantidade de clientes que eles obtinham a mais, e também, conseguiram ter uma visibilidade  de qual seria a tendência para os próximos meses.

Objetivo: o Nubank estabeleceu uma estratégia de tagging muito agressiva para que nos próximos três meses após aplicar a estratégia, atingissem, no máximo, 10% das aplicações sem tagging, e isso era cobrado fortemente de todas as equipes. 

Naquele tempo, o Nubank tinha aproximadamente 90 serviços online, 50 squads trabalhando com a criação e a atualização de serviços. 

Os custos estavam crescendo de uma maneira descontrolada, e sem visibilidade, o banco não tinha uma estratégia definida, com uma demora extremamente grande entre um deploy de uma parte nova da aplicação e o outro. 

Três anos depois de aplicar a estratégia de FinOps, o Nubank manteve e até conseguiu reduzir o custo da Nuvem por cliente, mesmo com o aumento da quantidade de serviços ativos para mais de 250, com mais de 50 squads em operação.

Como resultado, o Nubank passou a trabalhar com custos da Nuvem previsíveis, por meio de uma visibilidade muito boa de como o banco vai crescer os serviços da Nuvem utilizados, seguindo como principais estratégias do modelo FinOps o tagging, a compra de instâncias reservadas e o right sizing

Assim, o Nubank se tornou um case de FinOps bem aplicado, chegando a fazer mais de 50 deploys de correções ou novas funcionalidades por dia de uma maneira praticamente instantânea, sem dores e sem ter saldos consideráveis no custo da Nuvem. 

Conclusão

Este artigo tem o objetivo de apresentar o conceito de FinOps, o modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI. 

O controle dos recursos utilizados e a identificação dos departamentos que mais consomem os serviços da Nuvem são diferenciais estratégicos, voltados para a redução de custos em um cenário de trabalho conjunto entre TI e financeiro.

Se você ficou com alguma dúvida ou se precisa de ajuda para a implementação do FinOps na sua empresa, entre em contato clicando aqui!

E antes de me despedir, vou deixar um vídeo com mais informações sobre gestão de custos da Nuvem e FinOps. Abraço e até o próximo artigo!  👋👋👋

https://www.youtube.com/watch?v=mJjeDENeqTE&t=1133s

Management 3.0

Felicidade no trabalho com Management 3.0 — Como isso está funcionando para mim?

Por Luciano Osorio – Scrum Master da Zappts

Sou Luciano, Scrum Master na Zappts, e já trabalhei em muitas empresas (desde gigantes até empresas menores), e também já trabalhei para muitos clientes em diferentes áreas de negócios (saúde, serviços bancários, varejo, setor automotivo, etc).

Comecei como programador e ao longo de  10 anos mudei gradualmente para funções de liderança e gestão. Inicialmente, fui treinado nas práticas tradicionais de gerenciamento e depois fui para o Agile. 

Esta é a história de como consegui encontrar felicidade no meu trabalho como gestor, como isso se espalhou e como está fazendo com que meus times entreguem excelentes produtos. 

Acordando

Existem muitas teorias, livros e ferramentas de gestão por aí. Mas é raro encontrar uma que jogue na sua cara que o problema da gestão é provavelmente o mais óbvio: o gestor! Em outras palavras, é tudo sobre você.

Cruel? Talvez. Verdade? Com certeza! Ao menos no meu caso. Por que? Como gestor, fui treinado para esperar o pior das pessoas, para controlar tudo em detalhe e lidar com pessoas como se elas fossem máquinas. 

Se alguém precisa melhorar em algum aspecto de seu trabalho, basta mover uma alavanca (reclamar sobre algum comportamento, a minha versão de fornecer feedback), e voilá: a mudança está feita! O comportamento ruim desaparece e então… bem… eu aprendi da pior forma que isso não é verdade.

Eu estava perdido em um mundo de gráficos, projetos, relatórios, micro-gestão, times de baixo desempenho, grandes despesas, falta de propósito e muitos outros sinais de que não estava fazendo realmente um bom trabalho.

Como isso era possível? Eu sabia as práticas (CMMI, ITIL, e outros acrônimos, sem mencionar o Agile). Eu conhecia as métricas, as ferramentas … Então, o que poderia estar errado? Bem … Tudo em minha mente.

Levei alguns anos para descobrir e aceitar isso. Um projeto não é somente formado por práticas, métricas e ferramentas. Sim, é claro que tudo isso ajuda, mas um projeto envolve pessoas trabalhando com um propósito.

Volto para a definição de projeto do PMI (Project Management Institute):

Um projeto é um esforço temporário empreendido para criar um produto único, serviço ou resultado.

Em outras palavras, um projeto existe para preencher um objetivo ou propósito, e um produto, serviço ou resultado são necessariamente criados por pessoas, que estão alinhadas com esse propósito. E aqui é onde a mágica acontece!

Eu recebi um treinamento de Management 3.0 cedo demais, para ser honesto, e como eu estava começando minha experiência como gestor naquela época, não sabia, e nem poderia prever como isso iria impactar minha carreira no futuro. Então, eu guardei isso na prateleira do meu cérebro rotulada “para, talvez, ser usado no futuro”.

O futuro tornou-se o presente e após descobrir os problemas mencionados antes, fiz minha retrospectiva profissional e lembrei daquele treinamento. Olhando para as práticas do Management 3.0 mais cuidadosamente, comecei a perguntar …

O que posso fazer para ter um propósito no meu trabalho? Como eu posso comunicar esse propósito? Com posso fazer meu time ficar contagiado por esse propósito?

Tudo fez sentido quando eu li:

“Gerencie o sistema, não as pessoas”.

Para que as pessoas se sintam envolvidas, comprem a proposta e acreditem nela, todo o ambiente onde elas estão inseridas deve transpirar seu propósito. E eu não estou falando de poster na parede, camisetas com frases de efeito, etc. Estou falando sobre valores.

Agindo

Quais foram os passos que eu dei? Vou ilustrar cada um deles com os mais inspiradores e divertidos vídeos de Jurgen Appelo (exceto o segundo, que peguei do site Management 3.0).

Conheça as pessoas: Personal Maps

Feedback: Me ajudou a ficar mais próximo do time, entender quais são suas histórias, como eles acabaram trabalhando comigo e quais são os interesses que temos em comum. Me ajudou muito a iniciar conversas e criar relacionamentos.

Entenda o que as pessoas mais valorizam: Moving Motivators

Feedback: Deixou claro como abordar cada pessoa do time para discutir sobre os desafios a solucionar e como o papel de cada um se encaixa nesses desafios. O exercício em si foi usado como um ponto de partida para reuniões 1 a 1 que resultaram em objetivos a serem alcançados nos próximos períodos.

Celebre o que foi realizado: Celebration Grids

Feedback: Dá uma visibilidade clara durante as retrospectivas do que foi realizado (grandes ou pequenas coisas), e quais práticas levaram a esses resultados. Também me ajudou a responder às perguntas das retrospectivas (o que devo manter, alterar ou parar?) e criar planos de ação realistas para as próximas interações.

Estimule o reconhecimento: Kudos Box

Feedback: No meu caso, a Kudos Wall criou a oportunidade para pessoas se agradecerem pela ajuda, ensinamentos e suportes recebidos durante a última iteração. É incrível como pequenas coisas que você faz podem ter um valor enorme para alguém do time. 

Seja transparente: Happiness Door

Feedback: Criou a oportunidade de fornecer e receber feedback rápido sobre o trabalho diário e medir a felicidade do time. Junto às ações rápidas para mudar o que está deixando-os infelizes, criou um ambiente de confiança onde os membros do time sentem que podem levar assuntos mais sérios e desafiadores para serem tratados, e que às vezes, afetam suas vidas pessoais.

Forneça feedback honesto: Feedback Wraps

Feedback: Uma maneira muito estruturada, fácil e eficaz de dar feedback. Não nos permite dar feedback mecânico sem valor. É uma forma muito estruturada de abrir seus sentimentos sobre algo, apoiando-se em evidências e exemplos do que você espera como solução. Portanto, a outra pessoa terá bastante material para assimilar o feedback e executar as ações necessárias. 

As práticas acima criaram um ambiente onde existe confiança e as pessoas estão trabalhando com propósito e felizes. E quando o time está feliz, ele está comprometido com a qualidade, prazos, custos, e assim, entrega um produto melhor e que melhora o tempo todo.

Mantenha a ação…

Minha jornada Management 3.0 não acabou. Será que vai acabar?

Existem práticas que eu ainda não tentei, e pelos excelentes resultados a partir daquelas que mencionei anteriormente, mal posso esperar para começá-las. 

Portanto, aqui estão as práticas da minha lista “Vamos fazer isso”:

  1. OKRs – Objetivos e principais resultados (esta será a próxima)
  2. Delegation Poker
  3. Exploration Days
  4. Merit Money (Estou muito animado com esta prática!)

Todo o conjunto de práticas está relacionado aqui. Faça uma tentativa, veja como o trabalho pode ser divertido e traga felicidade para você também!

Gostou de aprender sobre Management 3.0?

Continue acompanhando o blog da Zappts para saber mais sobre gestão de times e aproveite também nossos conteúdos sobre Scrum, Transformação Digital e muitos outros temas!

Confira também as oportunidades de trabalho na Zappts e venha fazer parte do nosso time! https://www.zappts.com/trabalhe-conosco/

Eu fico por aqui. Até o próximo artigo!

Z-Flow – a solução Zappts de Git Workflow

Integração contínua, flexibilidade e limpeza de histórico eficiente: conheça o Z-Flow e avance na produtividade com seu time de desenvolvimento!

Por Thauany Moedano – Cloud Architect e Back-End Software Developer da Zappts

O assunto de hoje aqui no blog é Git Workflow e eu vou te apresentar um pouco da solução Z-Flow, desenvolvida pela Zappts. Vamos nessa?

Bom, quando falamos sobre o trabalho em equipe de um time de desenvolvimento, não podemos deixar de citar o uso de uma ferramenta de versionamento. 

O nosso amigo git é provavelmente um dos primeiros sistemas de versionamento de código que todo desenvolvedor tem contato quando começa a trabalhar em time, e apesar do git ser poderosíssimo e muito útil, muito ainda se discute a respeito de como utilizá-lo. 

Portanto, se você tem essa dúvida, continue lendo este artigo que eu vou compartilhar com você algumas informações importantes sobre o assunto!

Git Workflow

Qual é a melhor forma de trabalhar com git? Como organizo as branches?

Desses questionamentos surgiram os workflows e é a partir deles que podemos encontrar as respostas que tanto procuramos. 

Um workflow é um framework para a organização de branches

O workflow dita como devem ser organizadas e nomeadas as branches e quais movimentações devem ser feitas até a entrega do produto final. 

Existem diversos modelos conhecidos e você provavelmente já deve ter esbarrado em algum deles. 

Mas, com tantos frameworks já disponíveis e conhecidos, por que criar um novo workflow?

Primeiro, é importante destacar que os modelos mais antigos não levam em consideração nosso cenário atual de integração e entrega contínua (aquelas palavras famosas: CI/CD). 

E os modelos mais novos, como o “Github Flow” ou o “Feature Branch Workflow?

De fato, eles realmente são ótimos para CI/CD (inclusive nos baseamos em alguns conceitos básicos do Github Flow). Porém, eles apresentam uma branch master e homolog (ou release em alguns projetos) muito poluídas, e às vezes, com dezenas ou centenas de milhares de commits, o que impossibilita qualquer expert de entender qual foi a sequência de entregas realizadas.

Essa enormidade de commits passam a não servir para nada (a não ser para confundir), além de tornar muito complexo o processo de rollback (para quem nunca passou por isso, nem queira saber como é ter que fazer git revert e revert de revert para conseguir colocar as coisas em ordem novamente).

Aqui na Zappts já nos deparamos muito com essa situação em projetos próprios e também de clientes. Por isso, pensamos em uma nova forma de organizar a forma de como entregar funcionalidade para produção.

Z-Flow – A solução Zappts de Git Workflow

Vamos lá: tudo o que fazemos quando trabalhamos em desenvolvimento de software está focado em entregas com qualidade, certo?

Com base nessa premissa, nós criamos um modelo de workflow que deixasse nossa branch de desenvolvimento com todos os commits feitos pelos desenvolvedores (eles são importantes ali), e nossa branch de produção com o histórico de entregas e não de commits de desenvolvimento, permitindo também a administração de deploys por entregas específicas e não de um todo.

Assim surgiu o Z-Flow!

O que preciso saber para extrair o máximo deste artigo?

Para que esteja na mesma página que nós e acompanhe as dores que passamos antes de decidirmos pensar no Z-Flow, seria importante que você conhecesse de:

  • Git: que já tenha trabalhado em algum projeto que usa git como sistema de versionamento de código. Se já passou pelas dores de gerenciar um git com muitos desenvolvedores, projeto grande, código que “sumiu do nada” da sua branch, melhor ainda.
  • GitFlow: parte da premissa que todas as feature branches partem de Dev. Ou seja, Dev precisa estar estável com todas as features que serão publicadas para homologação e posteriormente produção.
  • GithubFlow: parte da premissa que todas as feature branches partem de Master e que todas as feature branches podem ser mergeadas em master separadamente. Normalmente, em projetos maiores, existem branches intermediárias (todas provenientes da master), que recebem individualmente a feature branch.
  • Delivery Contínuo (CI/CD): usando os commits das branches como source para executar uma pipeline de publicação automática. Quando um commit é submetido (pushed) para uma branch, automaticamente um script é executado, que publica esse novo código para um determinado ambiente.

Atenção: se você trabalha com desenvolvimento de softwares, venha fazer parte do nosso time! Confira as vagas e mande seu currículo hoje mesmo! 😀

Apresentando o Z-Flow

Como dito anteriormente, se você implementar o Z-Flow no seu projeto, terá uma branch de produção MUITO limpa, constando apenas o histórico de entregas e seguindo a cronologia de entrega de cada feature, além de uma branch de desenvolvimento que tenha todos os históricos de commits feitos por todos desenvolvedores.

Branches principais

O Z-Flow possui quatro branches principais:

  • master
  • develop
  • qa
  • homolog

A master é a branch de produção e sempre representa uma versão estável do nosso software. 

Quanto à develop, é nessa branch que as novas features vão se acumulando e o time de desenvolvimento têm visão de quais features já foram implementadas por outros desenvolvedores. 

Por conta da branch de develop ser atualizada recorrentemente, é a branch mais suscetível a instabilidades. 

Agora, vamos apresentar duas novas branches que talvez você ainda não conheça: a qa e a homolog.

A branch de qa é dedicada ao time de qualidade. É nela que os testes por parte do time de qualidade são executados. 

A branch de qa é mais estável que a branch de develop, uma vez que os desenvolvedores devem garantir a estabilidade da sua feature antes de repassá-la para a fase de testes.

p.s: a branch qa é recomendada, mas não é obrigatória para que o Z-Flow funcione da forma como idealizamos. Se você tem um time ou projeto pequeno, talvez essa branch possa ser dispensada.

E por último, temos a branch de homolog, onde estão todas as features testadas pelo time de QA, mas que ainda precisam ser homologadas pelo time de negócio. Essa é a branch que entrega features para produção. 

Importante: em alguns casos específicos de projetos, é necessário incluir a branch Pré-Prod após homolog. Esse caso será tratado mais à frente.

Z-Flow – Transitando entre branches

Para que o desenvolvimento aconteça de maneira paralela e eficiente, usamos as branches secundárias. São elas:

  • feature branch
  • delivery branch

Lembrando que para cada feature desenvolvida teremos uma feature branch e uma delivery branch.

Para todas as transições entre branches, sejam elas principais ou secundárias, recomendamos que sejam seguidas as boas práticas de git, pelo menos usando ferramentas que suportam merge por Pull Request e designando usuários independentes para fazer code review a cada Pull Request.

Feature Branch

  • Deriva de: master
  • Recebe o conteúdo: dos comitts feitos pelos desenvolvedores da feature
  • Entrega seu conteúdo em: develop (–no–ff), qa (–no–ff)
  • Convenção: feature/*

A feature branch é onde o desenvolvedor vai incorporar as novas funcionalidades do sistema. 

Ela sempre deriva de master para garantir que estamos trabalhando em cima de uma versão estável de produção. 

Todas as implementações da feature devem ser feitas na feature branch, nunca diretamente na develop ou em alguma outra branch.

Uma vez que o desenvolvimento é finalizado, a feature deve ser entregue (mergeada) no modo no-fast-forward em develop para que o desenvolvedor possa fazer testes integrados a outras funcionalidades incorporadas pelos outros times. 

Após fazer todas as implementações e alterações na feature branch e garantir a estabilidade da feature em develop, o desenvolvedor pode mergear a feature branch como modo no-fast-forward na branch qa para iniciar a fase de testes. Portanto, o nosso fluxo fica assim:

  • git checkout master
  • git pull origin master
  • git checkout -b feature/minha-feature
  • **após implementar alterações (git commits):
  • git checkout develop
  • git pull origin develop
  • git merge –no-ff feature/minha-feature
  • git push origin develop
  • **quando a feature estiver pronta para fase de testes:
  • git checkout qa
  • git pull origin qa
  • git merge –no-ff feature/minha-feature
  • git push origin qa

Delivery branch

  • Deriva de: master
  • Recebe o conteúdo: da feature branch (–squash)
  • Entrega seu conteúdo em: homolog (–no-ff)
  • Convenção: delivery/*

Com o intuito de limpar o histórico de commits, a delivery branch serve para diminuir o histórico de commits de uma feature branch pronta para entrega. 

Entenda a delivery branch como sendo exatamente a feature branch, com o mínimo de commits possíveis, os commits referentes a cada “entrega” da feature.

Para chegarmos a esse objetivo, a delivery branch recebe a merge squash da sua feature branch equivalente após a aprovação da feature em QA.

Assim, a delivery branch fica com o mesmo conteúdo da feature branch (master + nova funcionalidade), mas apenas com um commit (o resultante do merge squash).

Segue o nosso fluxo:

  • git checkout master
  • git pull origin master
  • git checkout -b delivery/minha-feature
  • git merge –squash feature/minha-feature
  • git commit -m “delivery da feature minha-feature”

Homolog Branch

  • Deriva de: master
  • Recebe o conteúdo: da delivery branch (–no-ff)
  • Entrega seu conteúdo em: master (–no-ff)

A branch de homolog receberá todas as features que estão testadas e prontas para serem homologadas.

Para entregar o conteúdo de cada feature pronta a ser homologada para homolog, a delivery branch (referente à cada feature) será mergeada em homolog.

O merge aqui acontece no modo “no-ff” para que se crie um histórico de entrega da feature para homologação. Então, atenção: é a delivery branch que deve ser entregue para homologação.

p.s: a branch homolog fica apenas com os commits referentes a cada entrega de feature feita para homologação. Ao usar o Z-Flow, você tem na branch homolog um histórico limpo de todas as entregas de features para homologação!

  • git checkout homolog
  • git pull origin homolog
  • git merge –no-ff delivery/minha-feature
  • git push origin homolog

Master Branch

  • Recebe o conteúdo: da homolog (–no-ff)
  • Entrega seu conteúdo: para criação de novas feature branches e delivery branches

E quando as features são entregues na master?

Consideramos, para este flow, uma entrega para produção como sendo exatamente o que está homologado.

Dessa forma, quando chega o momento certo, a branch master precisa ser uma “cópia” da branch homolog.

Quando um conjunto de features está homologado , basta dar merge no modo “no-ff” de homolog para master para atualizá-la, tornando master  uma nova versão estável.

  • git checkout master
  • git pull origin master
  • git merge –no-ff homolog
  • git push origin master

Assim, podemos taggear a última versão estável cada vez que entregamos um conjunto de features.

p.s. 1: quando se fizer necessário ter uma branch “pré-prod”, siga os passos descritos aqui como ‘master’. Após pré-prod estar validado, siga novamente esses passos trocando “homolog” por “pré-prod”.


p.s 2: a branch master fica apenas com os commits referentes a cada entrega de feature feita para homologação. Ao usar o Z-Flow, você tem na branch master um histórico limpo de todas as entregas de features para homologação em conjunto de um histórico com todas as entregas feitas para produção.

Por que precisamos de uma delivery branch?

Mas, por que precisamos criar uma branch a mais se poderíamos simplesmente dar merge squash da feature diretamente em homolog?

Realmente, isso pode ser feito deixando o flow bem mais simples. Então, qual a razão da existência da delivery branch?

Nós da Zappts prezamos muito pelo code review e sempre é importante alguém aprovar o nosso código antes de submetermos para uma das branches principais.

Usando o merge squash, por conta da maneira que as ferramentas de code review usam git diff, fica bem difícil entender as diferenças entre um commit e outro.

Logo, o intuito de criar uma branch intermediária, somente para criar um merge squash (um commit único) da feature branch, é para não atrapalhar o code review entre as outras branches.

O processo fica um pouco mais trabalhoso, de fato, mas o esforço compensa: por um pequeno custo (5 comandos de git), se consegue um retorno enorme (imensurável em alguns projetos) de se ter uma branch homolog e master limpas, com poucos commits cronologicamente organizados na forma de entregas. 

Nós pagaríamos o dobro (ou mais) por esse resultado 🙂

Lidando com erros

Como tratar no Z-Flow quando nossa feature está com erros?

A regra é simples: erros encontrados localmente (feature) ou nas branches develop e qa são consertados na feature branch e entregues novamente em develop e qa.

Se o erro foi pego na branch homolog deve ser consertado na feature branch, replicado (squashed) para a delivery branch e entregue novamente em homolog.

Entende-se que a delivery branch vai ficar com alguns commits a mais (a primeira entrega e a segunda entrega com o erro corrigido). É exatamente o que se busca: um histórico limpo de entregas.

E quando encontramos um erro que já está em produção? Nesse caso, criamos uma branch específica para tratar o erro, chamada de hotfix

Hotfix Branch

  • Deriva de: master
  • Entrega o conteúdo em: delivery/hotfix (–squash) 
  • Convenção: hotfix/*

A branch de hotfix deve seguir o mesmo fluxo já apresentado na feature branch, mudando apenas a convenção de nomes. Nesse caso:

  • git checkout master
  • git pull origin master
  • git checkout -b hotfix/meu-hotfix
  • após implementar alterações (git commits):
  • git checkout develop
  • git pull origin develop
  • git merge –no-ff hotfix/meu-hotfix
  • git push origin develop
  • **após garantir estabilidade do hotfix:
  • git checkout qa
  • git pull origin qa
  • git merge –no-ff hotfix/meu-hotfix
  • git push origin qa

E da mesma forma que para uma feature branch existe uma delivery branch, para o hotfix também existe uma delivery hotfix branch.

Delivery Hotfix Branch

  • Deriva de: master
  • Recebe o conteúdo: da hotfix (–squash)
  • Entrega o conteúdo em: homolog (–no-ff)
  • Convenção: delivery/hotfix/*

E o fluxo também segue o mesmo de uma delivery branch, apenas alterando a convenção de nomes:

  • git checkout master
  • git pull origin master
  • git checkout -b delivery/hotfix/meu-hotfix
  • git merge –squash hotfix/meu-hotfix
  • git commit -m “delivery do hotfix meu-hotfix”
  • git push origin delivery/hotfix/meu-hotfix

Vale ressaltar que devido à urgência que o hotfix pode apresentar, é possível pular passos no Z-Flow e entregar diretamente um hotfix em qa ou criar diretamente uma delivery branch para entrega em homolog/master.

Integração Contínua e Deploy Contínuo

O Z-Flow garante integração contínua uma vez que as branches são incorporadas juntas em todas as branches principais.

Com o Z-Flow sempre se está testando features integradas umas às outras. Ao passar pela branch de qa, o Z-Flow garante que uma nova feature não quebra as demais já entregues em produção na branch master

Há casos que é necessário entregar features prontamente ou antes de um conjunto de funcionalidades. Nestes, alguns passos do Z-Flow podem ser pulados e a delivery  branch pode ser mergeada diretamente na master, uma vez que a delivery branch já deriva da master.

Isso garante que todas as delivery branches sempre contenham: master (ambiente de produção estável) + feature (nova funcionalidade).

Logo, o Z-Flow é um modelo flexível que permite tanto a entrega de um conjunto de features já integrados ou a divisão da entregas em pacotes separados. 

Branch de produção mais estável

Como a feature branch deve passar pelas branches de develop e qa (e é intensamente testada), dificilmente a branch de produção ficará instável.

Isso ocorre porque somente features que já contém master testadas e prontas são entregues em produção.

Ou seja, o cenário de master + nova implementação já é simulado e testado desde develop e qa.

Histórico mais limpo

Como a delivery delivery sempre é um squash de uma feature branch e ela é entregue em homolog e master, o Z-Flow garante que em branches finais o histórico de commits será muito mais limpo, considerando assim um histórico de entregas e não um histórico de desenvolvimento.

Utilizando as delivery branches, fica fácil entender a cronologia de entregas, uma vez que cada delivery branch geralmente é composta de dois commits (um commit da implementação e um commit do merge).

E já que você chegou até aqui com a gente, deve estar interessado em saber como o Z-Flow funciona na realidade, certo? Então, vamos lá!

Acompanhe na imagem abaixo um exemplo de como o histórico fica mais limpo e claro sobre as entregas nas branches homolog e master e como o histórico fica completo com todos os commits de desenvolvimento nas branches develop e qa, cumprindo os objetivos principais do Z-Flow.

Tem duas formas de analisar esta imagem:

1. Com foco nas branches: faça a análise apenas das branches, de cima para baixo, esquecendo as branches ao lado. Veja como fica o histórico de commits de uma única branch. Entenda o que aconteceu com a branch, evolutivamente. Lembre-se de olhar com uma visão de desenvolvedor para as branches de develop e qa e com a visão de negócio para as branches de homolog e master.

2. Com foco no fluxo: acompanhe o fluxo de merges. Quando o merge é do tipo no-ff, ele arrasta o histórico de commits da branch origem. Quando o merge é do tipo squash, ele resume todos os commits da branch em um único commit.

Conclusão

O Z-Flow é uma alternativa aos modelos de workflow. Ele traz flexibilidade e garante CI/CD ao mesmo tempo que limpa o histórico de commits, além de manter uma branch de produção estável.

E aí, pronto para colocar o Z-Flow no seu catálogo de workflows? Pronto para usar o Z-Flow no seu projeto ?

Se a sua empresa precisa de ajuda para estruturar processos de desenvolvimento, conte com a gente! Vamos acelerar seus resultados com soluções produtivas, como o Z-Flow. Fale agora mesmo com nossos especialistas 😀

E se você é desenvolvedor(a), olha só: que tal vir trabalhar na Zappts?

Aqui, você vai encontrar o MELHOR ambiente para desenvolver suas habilidades, expor ideias e aprender muita coisa legal.

Construímos um espaço incrível de trabalho e diversão, que respeita a diversidade e que dá condições para que todos possam deixar suas marca em nossa história!

Vem conferir as vagas, trabalhar e aprender com a gente 👉 https://zappts.com/trabalhe-conosco/

Até o próximo artigo 👋

Arquitetura Monolítica e Microsserviços

Entenda as diferenças entre Arquitetura Monolítica e Microsserviços por meio de análises comparativas, vantagens e desvantagens

Por William Penna, Full Stack Developer da Zappts

Arquitetura monolítica e microsserviços

O tema que trago neste artigo é visto como uma decisão muito importante nos dias de hoje ao arquitetar o desenvolvimento de um sistema.

O que a empresa deve utilizar: Arquitetura Monolítica ou Microsserviços? E se a empresa já possui um sistema monolítico, ela deve fragmentá-lo para microsserviços? 

Nos próximos tópicos, vou compartilhar com você algumas informações que são fundamentais para ajudar a entender sobre o assunto. Acompanhe!

Arquitetura Monolítica e Microsserviços

O que é Arquitetura Monolítica?

Usando uma linguagem não técnica, imagine que o Sistema Solar fosse um único planeta, não tendo vários objetos como os planetas, as estrelas e afins que existem em todo o sistema hoje. Isso seria um monolito. 

Arquitetura Monolítica é um sistema único, não dividido, que roda em um único processo, uma aplicação de software em que diferentes componentes estão ligados a um único programa dentro de uma única plataforma.

Como exemplo, imagine a criação de uma aplicação para uma loja de calçados, onde há os setores de administração, contabilidade e vendas. 

Todos os usuários utilizarão o mesmo sistema, e será preciso que ele esteja dividido em algumas partes, são elas:

  • Autenticação e perfis de usuários (administração, contabilidade, estoque, vendedor);
  • Gráficos para a administração com os dados diários da loja;
  • Compra de produtos;
  • Estoque;
  • Vendas.

Com a visão de um software, agora é a hora de imaginar que todos os itens citados acima estejam em um único projeto, tudo interligado, onde ao subir uma aplicação para o servidor, tudo será disponibilizado junto. 

Se é feita uma alteração no serviço de compras de produtos, todas as outras partes do projeto também terão que subir para o servidor junto com essa alteração.

Vantagens da Arquitetura Monolítica

  • Mais simples de desenvolver: a organização fica concentrada em um único sistema;
  • Simples de testar: é possível testar a aplicação de ponta a ponta em um único lugar;
  • Simples de fazer o deploy para o servidor: a alteração é simplesmente feita e pronto;
  • Simples de escalar: como é só uma aplicação, se for preciso adicionar mais itens, é simplesmente ir adicionando o que for necessário.

Desvantagens da Arquitetura Monolítica

  • Manutenção: a aplicação se torna cada vez maior de acordo com o seu tamanho, o código será cada vez mais difícil de entender e o desafio de fazer alterações rápidas e ter que subir para o servidor só cresce;
  • Alterações: para cada alteração feita, é necessário realizar um novo deploy de toda a aplicação;
  • Linha de código: uma linha de código que subiu errada pode quebrar todo o sistema e ele ficar totalmente inoperante;
  • Linguagens de programação: não há flexibilidade em linguagens de programação. Aquela que for escolhida no início do projeto terá que ser seguida, sempre. Se o desenvolvimento de uma nova funcionalidade exigir outra linguagem de programação, existem duas possibilidades: ou todo o código é alterado ou a arquitetura do sistema precisará ser trocada.

O que são Microsserviços?

Microsserviços é o nome dado a uma arquitetura que estrutura a aplicação criando uma coleção de serviços. 

Quando se fala nesse tipo de arquitetura, basicamente nós pegamos um monolito que seria criado e o dividimos em vários serviços separados e independentes um do outro. 

A ideia é separar os serviços para que cada um acesse uma camada do banco de dados ou somente um acesse algum serviço externo.

Vou usar o exemplo citado anteriormente para deixar o entendimento sobre Microsserviços um pouco mais claro, considerando a criação de uma aplicação para uma loja de calçados. 

Neste caso, a diferença é que cada parte da aplicação será um microsserviço. 

No exemplo abaixo, serão cinco:

  • Autenticação e perfis de usuários (administração, contabilidade, estoque, vendedor);
  • Gráficos para a administração com os dados diários da loja;
  • Compra de produtos;
  • Estoque;
  • Vendas.

Agora, a ideia é imaginar que tudo é separado, um serviço será independente do outro. 

Quando um deploy para o servidor for feito para ser disponibilizado o serviço, serão necessários ser feitos 5 deploys separados e que não tem relação nenhuma um com o outro. 

A ideia é que a divisão desses serviços seja feita de acordo com a arquitetura que está sendo projetada para uma nova aplicação ou para a reestruturação de uma já existente.

Como exemplo de organização, imagine que existam as tabelas de banco de dados relacionadas como produto, cliente e cliente_produto. 

A proposta é que somente o microsserviço de vendas acesse essas tabelas ou o conjunto relacional em que elas se encaixam. 

Se outro serviço que se encontra separado precisa acessar um determinado dado que esteja em uma dessas tabelas (o que acontece com frequência, porque o sistema como um todo é um só), o ideal é que ele se comunique com o microsserviço de vendas para buscar um dado ou salvar um produto por exemplo, fazendo com que tudo fique separado, entre aspas “independente” porque eles se conversam.

Vantagens dos Microsserviços

  • Altamente testável e manutenível: tudo é feito de forma separada e mais rápida;
  • Independência e agilidade: os deploys de cada microsserviço são totalmente independentes e mais rápidos;
  • Objetividade: a organização é feita de acordo com a organização do produto e do negócio;
  • Flexibilidade: é possível dividir em equipes para trabalhar de forma separada e totalmente independente em cada serviço.

É possível também criar cada microsserviço em uma linguagem de programação diferente.

Desvantagens dos Microsserviços

  • Quando a arquitetura do sistema é feita, a divisão dos serviços tem que ser feita com muita atenção e cuidado: isso pode fazer com que se leve um pouco mais de tempo para chegar na divisão perfeita, de forma que no futuro a aplicação não sejam vários sistemas monolíticos separados e com funções que até se repetem;
  • Há replicação de código de resposta ou de infraestrutura, por exemplo: o que existe de padrão em um serviço provavelmente existirá nos outros serviços também;
  • Complexidade no gerenciamento da aplicação: é um ponto a se tomar muito cuidado para que a organização sempre exista mesmo que novas features sejam implementadas no futuro.

Arquitetura Monolítica ou Microsserviços?

As vantagens em fragmentar o monolito

Neste ponto, as perguntas a serem feitas são: como está ou será o sistema monolítico? Ele está crescendo ou irá crescer muito? A manutenção está ficando ou poderá ser cada vez mais complicada? O deploy está cada vez mais demorado ou poderá ficar? Cada deploy que é feito rola um “frio na barriga” para realizar o processo?

Se a resposta para mais de uma das perguntas acima for “sim”, a ideia de fragmentar o monolito começa a fazer sentido. 

Uma aplicação monolítica não é arcaica e também não está ultrapassada. Ainda existem e existirão aplicações que são e serão criadas com a arquitetura monolítica, porque é o que faz sentido. 

Mas, quando a análise é feita, onde o sistema está ou será grande e robusto, a manutenção pode ser uma preocupação para não quebrar o sistema. 

Se os deploys estão demorando ou irão demorar (pelo tamanho da aplicação é possível prever) um tempo acima da média para um monolito e a equipe que desenvolve e/ou faz a manutenção no sistema sofre a cada nova feature ou manutenção, a fragmentação para a arquitetura de microsserviços começa a fazer sentido.

Com a fragmentação, todos os problemas e preocupações serão seguramente amortecidos e, dependendo da maturidade da equipe, totalmente resolvidos. 

Porém, algumas perguntas devem ser feitas antes da decisão ser tomada:

  • A maturidade do time responsável pela aplicação tem o nível desejado?
  • O custo/benefício vai valer a pena?

Colocando esses pontos em interrogação e a resposta sendo afirmativa, a fragmentação faz total sentido.

Conclusão: Arquitetura Monolítica e Microsserviços

Embora a Arquitetura de Microsserviços seja muito bem falada e muito bem avaliada nos dias de hoje, não significa que tudo tem que ser feito dessa maneira. 

A Arquitetura Monolítica foi, é e sempre será muito bem usada. Tudo depende da aplicação e das suas características, do time envolvido no projeto, do tempo disponível para o desenvolvimento e até onde esse trabalho pode chegar. 

Por isso, foram mostradas acima as vantagens e desvantagens de cada uma das arquiteturas, para ajudar na decisão e na escolha mais assertiva quando se está projetando ou refatorando uma aplicação.

Bom, espero que você tenha gostado deste artigo e possa utilizar essas informações sempre que precisar decidir entre Arquitetura Monolítica e Microsserviços.

Eu vou ficando por aqui, mas em breve eu volto com outra publicação no blog da Zappts

Até lá!

Scrum x Kanban. E o vencedor é…

Qual estrutura de processos implementar em um projeto? Leia o artigo e entenda mais sobre as metodologias Scrum e Kanban!

Por Luciano Osorio – Scrum Master da Zappts

scrum kanban

Recentemente, um cliente estava considerando seriamente adotar a metodologia Scrum, mas de uma forma bastante particular.

As prioridades mudariam o tempo todo, o time estaria parcialmente alocado com pessoas compartilhadas entre vários projetos e as sprints deveriam ter uma semana de duração.  

Ele me pediu para ajudar a fazer esse modelo funcionar.

De acordo com o cenário exposto, recomendei o método Kanban como sendo o mais adequado, porém, a sugestão não foi aceita de início. Então, continuei estudando as melhores possibilidades.

Um dos problemas enfrentados nos projetos deste cliente era a falta de visibilidade sobre quanto trabalho realmente estava sendo realizado e como ele poderia melhorar a execução dos processos.

Mantive a recomendação e sugeri testarmos o Kanban por algumas semanas.

Agora, você pode estar se perguntando: mas qual o motivo da insistência em relação ao Kanban?

Bem, vou explicar o porquê dessa recomendação e aproveitar para esclarecer sobre as principais diferenças entre Scrum e Kanban.

Continue a leitura para descobrir!

Scrum x Kanban: A diferença está no compromisso e no foco

Vamos começar entendendo a diferença entre Scrum e Kanban e quais critérios avaliar para uma escolha assertiva e eficaz.

Scrum

No Scrum, o time se compromete com o produto. Toda sprint tem um objetivo para ser cumprido, que leva o time um passo à frente na entrega do valor do produto.

O time estima o trabalho que será incluído numa sprint e se compromete em realizar aquele trabalho com a maior qualidade possível. Sem interrupções ou mudanças de prioridade.  

O foco no objetivo da sprint é a principal temática das reuniões diárias do time. Elas devem ser realizadas com os propósitos de identificar problemas que impedem o alcance do objetivo e propor soluções removê-los dos processos.  

Ao final de uma sprint, aquele trabalho com o qual o time se comprometeu é avaliado e aceito como incremento de valor ao produto.

O time segue com uma avaliação de como o trabalho foi realizado durante a sprint e planeja as ações para trabalhar melhor na próxima.

Para entender mais sobre o que é Scrum, indico a leitura deste artigo, disponível em nosso blog.

É um conteúdo bem completo e com boas referências para se aprofundar no assunto 😉

Kanban

No Kanban, o time se compromete com o fluxo, ou seja, com o ritmo em que o trabalho realizado passa pelos passos do processo.

É necessário identificar os fatores que influenciam o fluxo e trabalhar para melhorá-lo sempre. Assim, é possível garantir que o trabalho não fique represado enquanto aguarda por algum passo.  

É preciso entender o passo mais lento e alinhar o ritmo para que ele ocorra de maneira fluida, sem acúmulos.

Além disso, no Kanban os membros do time executam um trabalho de cada vez. Esse foco ajuda a melhorar muito a qualidade do trabalho realizado.  

Aqui, mudanças de prioridade podem ocorrer livremente, pois ao selecionar o próximo trabalho, cada membro do time sempre escolherá o que é mais prioritário em um dado momento.

E para o time? O que é melhor: Scrum ou Kanban?

A resposta vai depender do contexto.

Em ambos os casos (Scrum e Kanban), times multidisciplinares executam o trabalho.

A relação entre os membros dos times seguindo os valores ágeis é fundamental em ambos os casos, além de uma liderança que deixe claro o propósito que eles devem perseguir, motivando-os a entregar o seu melhor sempre.

No caso do Scrum, a estrutura do framework com time-boxes cria a noção de começo, meio e fim a cada sprint, o que produz a sensação de atingir um objetivo.

Já no Kanban, o fluxo é contínuo e por não haver time-boxes, cada melhoria de fluxo conquistada pelo time deve ser celebrada, mantendo o foco na melhoria contínua.

Foco na coisa certa, ter objetivos claramente traçados e alinhados aos valores do time é sempre o melhor, e isso pode ser atingido com Scrum e Kanban.

Mas e o controle?

Em ambos os modelos há controle.

Métricas específicas, como Sprint Burndown mostram o avanço dos times Scrum ao objetivo diariamente e métricas como “velocidade” ajudam na previsibilidade das entregas.

No Kanban, o Diagrama de Fluxo Acumulado (Cumulative Flow Diagram), mostra claramente quais são os passos do processo que aumentam o Lead Time e que, portanto, necessitam atenção.

A métrica de Eficiência do Fluxo mostra a relação entre o tempo gasto em passos que estão trazendo valor e aqueles que não o fazem, mas que são necessários para o controle do processo, como inspeções, backlogs, etc.

Portanto, novamente, desde que com o foco adequado, Scrum e Kanban oferecem métricas que ajudam no controle e previsibilidade dos processos.

Scrum x Kanban: E o vencedor é…

Agora que já expliquei um pouco sobre as diferenças entre Scrum e Kanban e como avaliar a opção mais adequada, chegou o momento de responder à questão título deste artigo:

Scrum ou Kanban: qual o melhor?

Bom, como pudemos ver, não há vencedor neste “duelo”. O que há é uma necessidade de alinhar a escolha com o contexto, comprometendo-se com o que faz mais sentido.

Se estamos lidando com um time de produto, com um propósito definido, um escopo de projeto que evolui, mas de maneira ordenada e com prioridades definidas, o Scrum é recomendável e pode ajudar muito na realização dos objetivos do produto.

Por outro lado, se estamos lidando com um time que trata de uma demanda variável, com prioridades que mudam o tempo todo e problemas para conseguir completar o trabalho iniciado (o que se encaixa na situação do cliente que citei, lembra?), o Kanban ajudará na criação de um fluxo que tem um ritmo previsível.

Espero que essas informações possam te ajudar a entender Scrum e Kanban. São métodos aplicados para simplificar processos, ter mais flexibilidade no atendimento das demandas, e claro, melhorar o desempenho e integração da equipe de trabalho.

Abraço e até o próximo artigo!

Desvendando o Serverless – Cloud Computing

O que você sabe sobre Serverless? Vem comigo que eu te conto tudo!

Por Thauany Moedano – Cloud Architect e Back-End Software Developer da Zappts

Serverless Cloud Computing

Neste artigo, eu vou te contar um pouco do surgimento do Serverless e como aplicá-lo da melhor forma. 

Antigamente, o modelo mais comum de arquitetura eram os monolitos. Em um monolito, todos os componentes da sua aplicação estão unidos em um único módulo.

Embora o deploy de uma aplicação monolítica seja muito simples e seja fácil evoluir os componentes como um todo, o monolito apresenta um único ponto de falha. Isso quer dizer que se qualquer falha ocorrer em sua aplicação, todo o sistema falha.

E assim surgiram os microsserviços!

Os microsserviços surgiram com o objetivo de quebrar a aplicação em várias partes pequenas e independentes. 

Então, se um componente falhar, tudo bem: nossa aplicação não cairá por completo, mas o custo de uma aplicação distribuída e resiliente se torna um problema conforme a aplicação escala. 

Quantas máquinas e quantos contêineres vou precisar gerenciar? 

E a nuvem veio

Com o advento da nuvem, hoje é possível fazer deploy de aplicações inteiras sem ser o dono de um único data center

Aplicações distribuídas se tornaram muito mais simples de se manter. Os principais benefícios de usar um provedor em nuvem são:

  • Pagar somente o que usar: quando seu sistema escala, é possível provisionar mais máquinas para atender a demanda. Quando as máquinas não são mais necessárias, basta deletá-las. Você só é cobrado pelo tempo de uso.
  • Não há necessidade de estimar a capacidade final da aplicação: com a nuvem, é possível escalar o ambiente à medida que a demanda cresce. Em outras palavras, não é necessário se preocupar se o setup atual atende à demanda, pois sempre é possível provisionar novos recursos.
  • Simplicidade na criação de recursos: e a melhor parte desses benefícios é que tudo pode ser feito com poucos cliques!

É por isso que muitos estão migrando suas aplicações para a nuvem.

Isso impulsionou a popularidade da Arquitetura de Microsserviços, mas a disseminação dessa arquitetura levou as equipes de desenvolvimento a um novo desafio: orquestrar e gerenciar uma infraestrutura distribuída, dividida em contêineres, pode ser tão complexo quanto se queira

Esses novos desafios podem acarretar em deploys longos e aumentar o custo operacional. 

Mas, e se não precisássemos nos preocupar com manutenção e gerenciamento de servidores? E se o desenvolvimento fosse completamente focado na criação da aplicação ao invés da infraestrutura? 

E assim nasceu o Serverless!

Serverless, que na tradução livre significa “ Sem Servidor “, é um modelo em nuvem onde a equipe de desenvolvimento não gerencia os servidores. 

O objetivo principal do conceito de Serverless é que sua equipe foque mais no desenvolvimento da aplicação do que na infraestrutura.

Mas, calma: como uma aplicação pode existir sem servidor?

O servidor está lá, mas é totalmente gerenciado pelo provedor de nuvem. 

Ao invés de pagar pelo provisionamento de recursos, o Serverless cobra somente o consumo computacional da sua aplicação, conforme ela é executada.

E como funciona o desenvolvimento pensando Serverless?

A aplicação é desenvolvida em um modelo de execução conhecido como Function As a Service (FaaS). 

Nesse modelo, pequenas funções são escritas e associadas a eventos. Quando um evento ocorre, a função é executada. 

Esses eventos podem, por exemplo, ser uma chamada de API, uma postagem em uma fila, um upload de uma imagem ou um registro de usuário e o custo é somente no consumo computacional da função quando é executada. 

Já entendemos que Serverless significa não se preocupar com infraestrutura. Mas quais outras vantagens esse modelo em nuvem pode nos trazer?

Vantagens do Serverless

E para entender mais sobre esse modelo, nada melhor que conhecer suas principais vantagens de usar a arquitetura Serverless, que são:

  •  Lançamento de uma aplicação com pouco custo e em tempo rápido: o timing de um negócio é extremamente importante para o sucesso do mesmo. Com Serverless, é possível lançar rapidamente no mercado aplicações funcionais com pouco gasto de recursos.
  • Menor complexidade: as aplicações costumam ser menos complexas, pois é o provedor cloud que gerencia a infraestrutura.
  • Alta disponibilidade: como todo o servidor é gerenciado pelo provedor de nuvem, a aplicação é altamente disponível sem um custo extra por isso.
  • Fácil integração com CI/CD: a computação “sem servidor” torna muito mais simples o deploy e a atualização da sua aplicação

Então, Serverless é nossa bala de prata?

Embora Serverless traga muitos benefícios, nem todo modelo de negócio se adequa à sua utilização. 

Existem cenários que precisamos ter, em algum nível, controle sobre a infraestrutura. Além disso, existem outros fatores que podem comprometer a opção por Serverless. São eles:

  • As funções tem um tempo pequeno para timeout (em torno de 15 minutos). Logo, aplicações com workloads grandes e contínuos não são indicadas para serem escritas em Serverless.
  • As soluções Serverless ainda são bem distintas entre os provedores de nuvem. Isso significa que se sua aplicação precisa ser mais independente de um provedor o possível, Serverless não é recomendado.
  • Troubleshooting pode ser complicado uma vez que não é possível reproduzir fielmente um ambiente Serverless localmente.

serverless sem servidor

Qual o preço de Serverless?

Muito se fala no custo operacional de uma aplicação Serverless, e na maioria dos casos, as aplicações sem servidor realmente apresentam custos menores do que aplicações tradicionais. 

Isso acontece porque em Serverless você paga pelo consumo do recurso em si e não pelo provisionamento da infraestrutura.

Entretanto, é importante sempre calcularmos o preço do consumo do recurso. 

Aplicações com uma demanda muito grande de utilização e com uma intensidade grande de requests por segundo podem se tornar mais caras utilizando Serverless do que provisionando máquinas virtuais para hospedar a aplicação. Veja alguns exemplos:

Serverless – Cenário 1: Sistema escolar

Considere um sistema escolar em que os alunos podem se matricular nas matérias e no fim do período consultar suas notas. 

Existem dois períodos de grande movimentação no site: o começo das aulas e o fim das aulas. 

Vamos imaginar a seguinte situação: o dono desse sistema escolheu como provedor de nuvem a AWS: ele optou por provisionar instâncias virtuais (também conhecidas como EC2).  Por sua vez, o arquiteto escolheu para a solução uma máquina do tipo m4.large, que é a indicada para a maioria das aplicações em produção (essa máquina gera por mês um custo aproximado de $ 72 dólares). 

Durante o período de matrícula (2 meses do ano) e o período de notas finais (2 meses do ano), o tráfego aumenta e é necessário provisionar uma máquina extra.

Em um ano, o custo total dessa aplicação seria de $ 1152 dólares, mas o arquiteto analisou que esse sistema ficará no ar por bastante tempo e fez a reserva de uma instância para um ano. 

Com apenas uma máquina rodando sob demanda por 4 meses, o custo diminuiu para $ 789 dólares. Considerável, mas ainda parece alto.

Se movermos a solução para uma aplicação Serverless, utilizando os serviços AWS Lambda e API Gateway, qual seria nossa economia? 

Suponha que durante no período em que a demanda é baixa aconteça por volta de 5 mil requisições por dia. Em oito meses de baixa demanda, seria gerada em torno de 1.200.000 requisições. 

Agora, considere que nos meses de matrícula e notas finais, o número de requisições salta para 100 mil por dia. Em quatro meses, teria acontecido em torno de 12 a 13 milhões de requisições. A soma total nos traz em torno de 14 milhões de requisições no ano. Isso não custaria mais do que $ 55 dólares. 

Impressionante, não? Mas calma, vamos ver um cenário em que Serverless poderia sair muito caro.

Serverless – Cenário 2: E-commerce

Para simplificar, vamos supor que um e-commerce esteja calculando o custo de uma operação especial de natal. 

Para atender a demanda, o arquiteto sugeriu provisionar cinco máquinas m4.large. Isso custaria para esse mês especial um total de $ 360 dólares.

Qual o custo usando as mesmas tecnologias Serverless do cenário anterior? 

Bem, com a correria de fim de ano, o site estará bem movimentado, gerando pelo menos 50 requisições por segundo. Apenas o custo do serviço de API Gateway geraria no mínimo um custo de $ 451 dólares. 

E vale lembrar que também estamos desconsiderando o custo do banco de dados, que em um banco de dados Serverless pode ter um custo por conexão mais elevado.

Isso nos mostra que Serverless não é indicado em cenários de grande carga de requisições, já que o custo de provisionar uma máquina será menor que o custo do consumo dos recursos.

Sobre custos da nuvem, aproveito para falar em FinOps, um modelo operacional que trabalha o gerenciamento eficiente de finanças, tornando mais assertivo o cálculo de gastos futuros em plataformas cloud como a AWS, Azure e Google Cloud. Baixe agora o ebook e saiba mais!

Como aplicar Serverless da melhor forma?

O ideal em uma arquitetura em nuvem é sempre aproveitar o melhor que cada modelo de negócio pode nos oferecer. 

Uma aplicação não precisa ser 100% Serverless se esse modelo não atender a todos os requisitos do seu produto.

Isso significa que Serverless pode ser um recurso estrategicamente inteligente quando utilizado em pontos chave da sua aplicação.  

Dessa forma, os melhores cenários para usar Serverless são:

  • Eventos stateless (para pequenas tarefas na sua aplicação) e assíncronos (cujo padrão de execução não pode ser previsto);
  • Pequenos processamentos/transformação de dados, desde que sejam concluídos em um curto espaço de tempo;
  • Aplicações Web simples, como portais e gerenciamento de conteúdo;
  • Backend de aplicações mobile cujo acesso é esporádico;
  • Gerenciamento de notificações , sistema de mensagens e chatbots.

E agora, pronto para usar Serverless?

Serverless deve ser visto como uma nova opção no catálogo de soluções ao desenvolver uma arquitetura em nuvem. 

Sempre em algum grau, é possível implementar conceitos de Serverless em sua aplicação, desde a criação de pequenos eventos para alterar o tamanho de uma imagem, até a criação de uma aplicação inteiramente sem servidor.

Aqui, contei um pouco da história do Serverless e dei alguns exemplos de como esse modelo da Cloud Computing pode ser útil para tocar processos mais simples e ágeis. 

Continue acompanhando os conteúdos do nosso blog. Temos artigos sobre UX, Scrum e muitos outros assuntos da área de tecnologia. 

Espero que tenha gostado desta publicação e até a próxima! 🙂

Scrum Case: GE aumentou em 1000% do ROI em Treinadores Scrum

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original Scrum Papers (páginas 45 a 47), escrito pelo Jeff Sutherland, Ph.D.

Em 2005, Jeff Sutherland (um dos criadores da Metodologia Scrum) trabalhou com Peter Deemer no Yahoo!. Eles quiseram apresentar o Scrum para seus gerentes.

Depois que a gerência decidiu utilizar o Scrum, uma análise da produtividade da implementação dele na IDX Systems (atual GE Healthcare) foi utilizada para calcular um ROI (return on investment – retorno sobre investimento) anual de 1000% em um período de três anos do uso do Scrum na Yahoo!.

Após dois anos da implementação em mais de 100 equipes, a taxa de retorno do Yahoo! para seu investimento em cada treinador Scrum interno foi de US$1,4 com base no treinamento de 10 equipes por ano. Isso equivale a cerca de 1000% de ROI.

Equipes treinadas por um treinador Scrum obtiveram de 3 a 4 vezes os ganhos de produtividade de equipes que não foram treinadas.

O Scrum foi adotado como ferramenta de Transformação Digital tanto no Yahoo! quanto na GE Healthcare.

O Aumento do ROI com o Scrum

A taxa interna de retorno sobre investimento em treinamento de Scrum é bastante alta. Ao fazerem a média de todas as suas equipes, muitas empresas dobraram a taxa de produção de software.

Recentemente, uma empresa de CMMI Nível 5 cortou os custos de projetos de software pela metade. Além disso, houve redução dos defeitos medidos em 40%. Mesmo com o corte de custos, a empresa manteve a conformidade com o nível 5 do CMMI para todos os projetos.

Até mesmo as melhores empresas mostram aumentos radicais de desempenho quando passam a utilizar Scrum e obtêm muito mais do que 1000% de taxa de retorno sobre o investimento em treinamento Scrum.

Este artigo aborda o retorno sobre investimento em treinamento de Scrum para grandes empresas. Essas empresas têm milhares de funcionários e centenas ou milhares de desenvolvedores.

Essas empresas estabeleceram, ao longo de muitos anos, processos pesados, burocráticos e cheios de falhas.

Embora pareça fácil gerar ganhos substanciais apenas eliminando as fontes mais óbvias de ineficiência, introduzir um processo radicalmente novo por toda a organização pode ser algo lento e doloroso.

O Scrum tem um processo contínuo e sistemático de melhoria de qualidade. Esse processo identifica e prioriza os impedimentos das operações no progresso da empresa.

IDX Systems (agora GE Healthcare): escalando o Scrum pela primeira vez

Durante o verão de 1996, a IDX Systems contratou Jeff Sutherland como vice-presidente de engenharia e desenvolvimento de produtos. A IDX tinha mais de 4 mil clientes e era uma das maiores empresas de software de saúde dos EUA. Eram centenas de desenvolvedores trabalhando em dezenas de produtos.

Aqui estava uma oportunidade para estender o Scrum ao desenvolvimento em grande escala.

A abordagem na IDX foi organizar todo o grupo de desenvolvimento em um conjunto interligado de Scrums.

Embora essa tenha sido a primeira grande equipe de desenvolvimento a tentar essa abordagem, a estratégia já foi executada muitas vezes e documentada por Ken Schwaber em “Scrum in the Enterprise”.

Cada parte da organização era baseada em equipes, incluindo a equipe de gestão. Nela haviam dois vice-presidentes, um arquiteto sênior e vários diretores. Scrums da linha de frente reuniam-se diariamente.

Um Scrum de Scrums, que incluía os líderes de cada equipe Scrum em uma linha de produtos, reunia-se semanalmente. O Scrum de gerenciamento se reunia mensalmente.

O principal aprendizado na IDX foi que o Scrum se adapta a qualquer tamanho.

Com dezenas de equipes em operação, o problema mais difícil era garantir a qualidade do processo Scrum em cada equipe. Toda a organização tinha que aprenderScrum ao mesmo tempo.

A IDX era grande o suficiente para trazer especialistas em produtividade para monitorar o rendimento de cada projeto.

Métricas de Escalabilidade

Enquanto a maioria das equipes conseguiu dobrar o número de Function Points (Pontos de Função) por mês com relação à média da indústria, algumas equipes entraram em um estado hiperprodutivo. Elas produziam quatro ou cinco vezes mais funcionalidades entregáveis do que a média da indústria. Essas equipes se tornaram estrelas na organização e exemplos a serem seguidos.

Uma das equipes mais produtivas da IDX foi a equipe do Web Framework. Ela criou uma infraestrutura de front end web para todos os produtos. A infraestrutura foi projetada para hospedar todos os aplicativos IDX, além de interoperar perfeitamente com aplicativos do usuário final ou de terceiros.

O Web Framework foi criado por uma equipe distribuída, com desenvolvedores em Boston, Seattle e Vermont, que se reuniam diariamente por videochamada.

A transparência geográfica deste modelo produziu equipes distribuídas de performance tão alta quanto a das equipes co-localizadas. Isso tornou-se a característica mais marcante de Scrums hiperprodutivos distribuídos/terceirizados das empresas Xebia na Holanda e Índia, e Exigen Services nos Estados Unidos e Rússia.

A qualidade do software de muitas das equipes de Scrum hiperprodutivas pode ser extraordinariamente alta.

O IDX Web Framework foi implementado pela primeira vez em 1997. Em 2007, foi selecionado como a principal tecnologia webpara os sistemas da GE Healthcare.

No entanto, muito poucas equipes de software IDX alcançaram o estado hiperprodutivo.

Em média, com base na análise de Function Points feita pela empresa de Capers Jones, a Software Productivity Research, a IDX só alcançou uma média de ganhos produtivos de 240%. O principal motivo disso foi a queda de produtividade causada pelo número excessivo de membros nas equipes Scrum, com até 15 pessoas.

Hoje é senso comum que essas equipes grandes causam perda significativa de produtividade e impossibilitam a escalabilidade linear.

A escalabilidade linear é uma das principais características das implementações Scrum bem executadas.

Resumo dos ganhos de produtividade na IDX

O orçamento da organização de desenvolvimento da IDX era de quase US$ 50 milhões por ano. Isso era suficiente para uma análise detalhada da produtividade basal antes do Scrum e dos ganhos de produtividade gerados por ele.

Uma empresa de consultoria independente foi contratada para fazer a análise de Function Points de todos os softwares IDX. Essa empresa chamava-se Software Productivity Research (SPR). Jeff Sutherland havia trabalhado com Capers Jones, o fundador da SPR, durante a criação do Scrum e queria comparar as metas de produtividade projetadas do Scrum com o seu desempenho real.

Alguns dos produtos IDX tinham mais de 12 mil Function Points. Isso era o equivalente a mais de um milhão de linhas de código Java ou C#. Os produtos menores tinham por volta de 5 mil a 6 mil Function Points.

Os aplicativos eram produtos financeiros e clínicos para operar hospitais e grupos médicos independentes em milhares de sites.

As plataformas de implementação variavam de Mumps a Cobol e Java, até as ferramentas e linguagens da Microsoft mais recentes disponíveis.

Function Points e Story Points

Function Points foram escolhidos como uma medida padrão da indústria, independente da linguagem e ambiente de desenvolvimento de software. Isso foi feito para garantir uma comparação realista da produtividade entre as tecnologias e equipes de desenvolvimento. Também havia garantia da comparabilidade com dados externos à indústria.

Especialistas externos foram contratados para calcular Function Points, a fim de fornecer dados qualificados para pesquisa.

Via de regra, os Function Points não são facilmente calculados pela equipe de desenvolvimento e não são recomendados como uma estratégia operacional.

Os Story Points (Pontos de História) surgiram como a melhor prática da indústria para medir a velocidade da equipe de Desenvolvimento Ágil. Eles são facilmente calculados e úteis para o planejamento do lançamento de um software.

Contudo, eles não são comparáveis entre equipes ou entre empresas. Portanto, não eram adequados para dados de pesquisa sobre a primeira implementação do Scrum em uma grande empresa.

Em cada lançamento de cada produto, o número de Function Points foi recalculado para refletir os novos recursos pelas consultas do Software Productivity Research.

O aumento nos Function Points foi dividido em meses por pessoa para as equipes de desenvolvimento sobrecarregadas. Isso inclui equipe de design, desenvolvimento, teste, administrativa e de gerenciamento.

A velocidade inicial de todas as equipes de desenvolvimento foi a média da indústria, em 2 a 3 Function Points por mês da equipe.

Algumas equipes aceleraram até alcançarem a hiperprodutividade usando o Scrum, atingindo de 5 a 10 vezes o desempenho médio da indústria. Essas equipes eram cerca de 10% da organização e alcançaram um aumento médio de produtividade de 666%.

Um pequeno número de equipes (menos de 5%) apresentou falhas por motivos pessoais ou tecnológicos.

Os Ganhos de cada Equipe

Ocasionalmente, uma equipe não era capaz de trabalhar em conjunto de forma eficaz e acabava sendo reorganizada ou desfeita, geralmente durante o primeiro Sprint.

Menos frequentemente, uma equipe de alto desempenho tinha assumido um risco calculado em novas tecnologias (sempre aprovadas pela gerência) e a falha técnica de algumas Sprints era antecipada (até mesmo incentivada) para ganhar uma liderança tecnológica no mercado.

Não houve falhas em grandes projetos, apenas falhas na entrega de software em Sprints isolados ou em uma curta série de Sprints. No caso de falhas da equipe, as equipes sempre foram refeitas. No caso de falhas tecnológicas, os esforços foram redobrados nos Sprints seguintes para superar os desafios de pesquisa e desenvolvimento.

Os 85% restantes das equipes atingiram uma velocidade média de 5 a 6 Function Points por mês de equipe, tendo um ganho médio de 100%. O ganho líquido de produtividade de todas as equipes combinadas foi de 240%.

Isso foi visto como uma falha em alcançar um desempenho de nível comparável ao da Toyota. Entretanto, foi um bom começo para a implementação do Scrum em toda a empresa. Recentemente, as equipes de desenvolvimento de tamanho comparável alcançaram consistentemente mais de 10 Vezes a Velocidade Média da Indústria.

Todas as Equipes de uma Organização Inteira Foram Hiperprodutivas, alcançando o objetivo original do Scrum.

Conclusão

É importante ressaltar que esses ganhos de produtividade foram alcançados em um ritmo sustentável. Houve maior retenção de funcionários e maior capacidade de contratar as melhores pessoas. Isso é devido ao ambiente de trabalho de alta qualidade fornecido para desenvolvedores pelo uso do Scrum.

As equipes hiperprodutivas sempre foram as equipes mais animadas, que amavam seus empregos e trabalhavam com grande sinergia, como uma equipe esportiva profissional.

A hiperprodutividade não é alcançada trabalhando mais arduamente, mas sim trabalhando com mais eficácia através de comunicação intensa, apoio mútuo e uma habilidade “sem esforço” que faz com que as coisas difíceis pareçam fáceis.

Pense em Michael Jordan subindo para um “shot” de basquete. A equipe trabalhou para que o jogo fosse propício para o “shot”, o que muitas vezes faz com que ele pareça tão suave e fácil que gera alegria tanto nos jogadores quanto nos espectadores.

Scrum Case: Como o FBI Desenvolveu em 1 ano um projeto que estava atrasado há 10 anos e com economia de 90% do investimento?

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto original Software em 30 dias, escrito por Ken Schwaber e Jeff Sutherland (criadores do Scrum).

Em 2003, o FBI decidiu digitalizar os arquivos de caso das suas investigações. Isso permitiria que os investigadores pudessem comparar rapidamente os casos e descobrir conexões entre eles.

O projeto para automatização dos processos de comparação foi chamado de Sentinel.

O Sentinel Antes do Scrum

Em março de 2006, o FBI iniciou o desenvolvimento do Sentinel. A projeção era de uma base de mais de 30 mil usuários finais. Dentre eles: agentes, analistas e funcionários administrativos do FBI. Estimativas originais foram de US$ 451 milhões para o desenvolvimento e implementação do Sentinel até dezembro de 2009.

De acordo com o plano original do FBI, o Sentinel deveria ser desenvolvido em quatro fases. O FBI contratou a empresa de segurança Lockheed Martin para o projeto. Essa empresa propôs usar a metodologia tradicional de desenvolvimento de software, chamada Cascata.

Em agosto de 2010, o FBI gastou US$ 405 milhões do orçamento de US$ 451 milhões do Sentinel. Entretanto, o FBI entregou funcionalidades para apenas duas das quatro fases do projeto.

Mesmo que essas entregas tenham melhorado o sistema de gestão dos casos do FBI, elas não geraram tanto valor quanto foi previsto. Devido ao excesso de custo e ao cronograma apertado, o FBI cancelou o Sentinel em julho de 2010, deixando-o incompleto.

Scrum e a Nova Abordagem de Projeto

O FBI decidiu retomar o projeto com uma nova metodologia. O intuito disso era ver se haveria melhora nos resultados. Essa nova metodologia chama-se Scrum.

Segundo o Relatório CHAOS do Standish Group, apenas 37% dos projetos de software são bem-sucedidos. Apenas 14% dos projetos tradicionais (Cascata) tiveram sucesso, em comparação com 42% dos projetos ágeis (Scrum).

Além das definições tradicionais de sucesso do Standish Group, esses projetos também permitiram uma maior capacidade de resposta às mudanças nas necessidades dos clientes, permitiram uma melhor mitigação de riscos e, por fim, forneceram software de melhor qualidade.

Em 2009, o FBI recrutou um novo diretor de informações (CIO) e diretor de tecnologia (CTO) com experiência no gerenciamento de organizações que construíram software usando Scrum.

Em 2010, o CTO decidiu mudar a abordagem do Sentinel. Isso simplificaria os processos de tomada de decisão e permitiria ao FBI entregar o Sentinel dentro do orçamento.

O FBI disse ao Inspetor Geral do Departamento de Justiça que acreditava ser capaz de completar o Sentinel com o orçamento remanescente e dentro de 12 meses.

Uma auditoria já havia concluído que o FBI precisaria de mais US$ 35 milhões e mais seis anos se tivesse continuado com a metodologia tradicional.

O FBI reduziu a equipe do Sentinel de 400 para 45 pessoas, 15 das quais eram programadoras. O CTO fez o projeto sozinho, com o objetivo de fornecer novas funcionalidades do Sentinel a cada 30 dias. Cada nova funcionalidade precisava atender a todos os requisitos finais.

A cada três meses, o FBI implementaria os recursos que haviam sido construídos nas três iterações precedentes em um piloto de campo.

O Sentinel Um Ano Depois

Em novembro de 2011, após um ano de recomeço do projeto com o Scrum, todas as fases do Sentinel foram concluídas.

O software foi implementado em um grupo piloto de escritórios do FBI. Os demais escritórios tiveram implementação até junho de 2012. O FBI concluiu o Sentinel por US$ 30 milhões em 12 meses, uma economia de mais de 90%.

Depois que o FBI mudou sua abordagem, adotando o Scrum como ferramenta de Transformação Digital, eles trabalharam com a mesma intensidade de antes, mas foram recompensados ​​com resultados muito superiores.

Se uma organização como o FBI pode fazer isso, por que a sua não pode?

Scrum Case: Companhia Aérea Reduz de 50% a 75% o tempo de entregas de novas funcionalidades

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original do Scrum Case Studies.

Em 2012, a liderança de uma companhia aérea internacional emitiu uma ordem para aumento de agilidade.

Essa empresa é grande e atende mais de 150 destinos ao redor do mundo.

A ordem foi emitida a fim de tornar a organização mais adaptável e capaz de reagir mais rapidamente a mudanças.

Para conseguir isso, uma equipe de desenvolvedores de TI focada em aplicativos móveis adotou o Scrum. Pouco tempo depois, mais equipes Scrumse formaram para aplicações web e mobile.

O Scrum foi adotado como ferramenta de Transformação Digital nessa companhia aérea.

As Equipes Scrum

Em janeiro de 2015, quatro equipes Scrum se formaram para trabalhar no aplicativo mobile de fidelidade dessa companhia aérea. Cada equipe específica focava em uma parte diferente do aplicativo: front end, back end, design e teste da experiência do usuário, incluindo um Product Owner.

As equipes estivam se dando bem com o Scrum. Porém, elas enfrentavam problemas de integração entre seus membros. Uma das causas disso eram todas as dependências que seus projetos sofriam. Além desse desafio, era necessário aumentar ainda mais a agilidade.

Lorenz Cheung, Treinador Scrum Profissional, Agile Coach e Scrum Master dessa companhia aérea, queria encontrar um meio para que essas quatro equipes diferentes criassem um trabalho integrado antes de aumentar a agilidade.

A Solução: o Framework Nexus

A fim de solucionar os desafios de integração, Lorenz Cheung adotou o Nexus. O Nexus é um framework para escalabilidade do Scrum criado por Ken Schwaber, co-criador do Scrum comum.

O Nexus é uma estrutura que repousa sobre várias equipes Scrum que estejam trabalhando juntas para construir um produto. Com base no Scrum, o Nexus foca em ajudar a superar as dependências entre as equipes e os problemas de integração.

O Nexus utiliza, além dos eventos do Scrum comum, suas versões próprias desses eventos. Um exemplo é o Nexus Sprint Planning. Ele também utiliza a Equipe de Integração do Nexus, que é responsável por garantir que pelo menos um Incremento Integrado seja produzido a cada Sprint.

Agora o Nexus é usado nessas quatro equipes Scrum, compostas por aproximadamente 40 pessoas, com um único Product Owner.

A Transição para o Nexus

Como eles tinham usado o Scrum com sucesso antes de adotar o Nexus, a transição não foi difícil.

Eles já tinham um único Product Owner para o produto inteiro, Sprint Planning compartilhado e Sprint Review compartilhada. Esse cenário abria caminho para uma progressão fácil e natural para o Nexus.

O Nexus se concentra na minimização e remoção de dependências entre as equipes. Ao mesmo tempo, ele permite a integração. Os quatro times Scrum podem trabalhar de forma independente porém interligada em um mesmo produto.

A cada Sprint, eles se concentram em um único incremento integrado, permitindo que eles entreguem softwares funcionais ao final de cada Sprint, satisfazendo a Definição de Pronto do Scrum.

Resultados

Ao usar o Nexus, essa companhia aérea conseguiu atender melhor às necessidades de seus clientes, liberando funcionalidades com maior frequência.

Por exemplo, as equipes de desenvolvimento puderam extrair feedback dos usuários da seção de pesquisa do aplicativo. Com isso, liberaram novos recursos em apenas duas semanas, retornando valor aos clientes.

Antes de aplicar o Nexus, as equipes Scrum estavam produzindo um incremento integrado a cada 8 semanas.

Agora, com o Nexus, cada equipe produz um novo incremento a cada 2 (75% de redução) ou 4 semanas (50% de redução), com o objetivo de entregar de forma mais consistente a cada duas semanas.

Previsões Futuras

Essa companhia aérea internacional começou com apenas um Nexus. No futuro, podem haver mais equipes de produto adotando o Nexus à medida que a empresa continua focando mais em Produto.

Lorenz Cheung implementou o Nexuspara produzir pelo menos um incremento integrado a cada Sprint. O objetivo era lançar produtos mais rapidamente e responder ao feedback dos clientes.

Ainda, o cenário ideal teria padronização Nexus em toda a empresa. Esse padrão seria feito com avaliações do nível de maturidade e de sucesso dos métodos ágeis em todas as equipes.

Scrum Case: Ganhos na Cobertura e Qualidade de Testes à Distância de 1 Clique em um Banco Europeu

 

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original do ValueGlide, escrito por John Coleman.

Um grande banco europeu tinha várias equipes por produto que queriam uma alternativa ao Scrum, ao Kanban, ou ao Lean Startup.

As equipes queriam um padrão para esses métodos. Daí surgiu o Nexus+, que é igual ao framework Nexus mas com acréscimo do papel de Architecture Owner. O Nexus+ foi adotado como ferramenta de Transformação Digital nesse banco.

Em uma instância do Nexus+ nesse banco, haviam 5 equipes em um Nexus. Quatro equipes eram Scrum e uma equipe era Kanban. Um dos outros Nexus tinha três equipes: uma Lean Startup, uma Scrum, e uma Kanban.

O Escopo

A meta para os primeiros 6 a 12 meses da mudança para o uso do Nexus foi a entrega mais rápida. Em paralelo ocorria a retirada gradual do híbrido de Cascata/Scrum usado antes. Isso promoveu uma boa agilidade, sustentável e com propósito. O DevOps era a maior prioridade, vindo o Lean Finances em segundo. O objetivo em cada caso foi poder, mais tarde, focar no cliente e na inovação.

As pontuações DICE do Boston Consulting Group para prontidão para mudança desse banco só seriam verdes/amarelas se a meta de 6 meses fosse diluída ou se o escopo da organização fosse limitado.

Os colaboradores do banco começaram a visar melhores tempos e taxas de entrega com o objetivo de atrair mais clientes na onda de 6 a 12 meses de acompanhamento posterior.

O escopo foi de US$25 milhões em gasto aproximado.

Transição para o Nexus+e suas Instâncias

O Nexus era utilizado para ter Sprint Reviews mais ou menos mensais em todo o portfólio. As previsões eram feitas com simulações probabilísticas Monte Carlo para identificar “planos incríveis”.

Também houve desenvolvimento da capacidade interna. Quando houvesse corte de custos, a organização poderia continuar sua jornada de agilidade sem perder o ritmo.

Em uma das suas instâncias, o Nexus+ foi implementado com equipes distribuídas. As responsabilidades e metodologias de cada uma eram:

  • Europa: infraestrutura (DevOps e automação de testes). Kanban com tempo estruturado de aprendizado.
  • Europa: desenvolvimento da aplicação. Scrum.
  • Índia: desenvolvimento de aplicação. Dois times Scrum.
  • Estados Unidos: desenvolvimento de aplicação. Scrum.

Papéis e Desafios do Nexus+

O Architecture Owner é um papel importante, pois é responsável pelo fluxo do back end. No caso desse banco, o back end envolvia a autorização de cartões de crédito e débito.

As 5 equipes implementaram automação de testes e lançamentos mensais. Anteriormente, os lançamentos eram irregulares e impulsionados pela execução do projeto. Isso reduzia a previsibilidade e causava problemas de sequenciamento.

Por exemplo, se um projeto tivesse um componente com entrega atrasada, os projetos relacionados a ele precisavam reconsiderar e refazer seus testes. Isso permitia por volta de 6 a 10 lançamentos por ano.

Isso tudo foi feito em tecnologia antiga. Por esse motivo, houve necessidade de recorrer a testes automatizados de ponta a ponta, ao invés do TDD(Test Driven Development – desenvolvimento guiado por testes).

Todas as transações com cartões passavam pela tecnologia antiga. As equipes estavam alterando-a a cada mês utilizando DevOps.

As equipes possuíam um Product Owner disciplinado, um Architecture Owner orientado à agilidade, Scrum Masters apropriados, Scrum apropriado, Kanban apropriado. Isso eliminou o híbrido Cascata/Scrum rapidamente.

Há sempre novos desafios. Soluções causam novos problemas. Por exemplo, um desses desafios nessa instância do Nexus+ era a sincronização entre a costa oeste dos EUA e a Índia.

Desdobramentos

Apesar de todas as mudanças, a pressão dos órgãos reguladores e da diretoria foi grande. Com isso, a gerência recuou para o que eles sabem planejar em páginas, em gráficos de Gantt, e marcos imutáveis para os 6 meses seguintes.

Os marcos eram atingidos pela alteração do conteúdo da entrega. Ironicamente, embora essa “equipe de equipes” tenha argumentado contra os marcos, suas medições eram incrivelmente boas, com gráficos de queima de marcos (Burndown Charts).

O controle financeiro insatisfatório tornou difícil argumentar o caso do Agile. A diretoria achava que, se tivessem rastreado o custo em relação aos entregáveis, teria sido mais fácil mostrar valor (ou a falta dele). Era difícil para eles medir o valor de um sistema que a maioria das pessoas simplesmente considerava natural.

A realocação da equipe dos EUA para a Costa Oeste causou uma queda maciça na produtividade. Isso agravou o desafio da diferença de fusos horários. As pessoas na Europa e na Índia tiveram que se esforçar para tentar fazer a equipe dos EUA se sentir mais conectada.

Ferramentas de Mudança

As ferramentas de DevOps (com exceção da automação de testes) foram interrompidas devido à falta de financiamento, mas ainda continuam, como atividade paralela e conforme a equipe percebe o valor nelas.

O primeiro estágio será fazer build automaticamente a partir do Git usando o Jenkins para dar push no código para a plataforma NonStop. Já que não há um cliente NonStop Git adequado, com o build sendo executado pelo Jenkins usando macros (de uma linguagem para scripts bem antiga, chamada TACL) já existentes.

O retrabalho de testes usando o VersaTest produziu um pacote de testes muito mais preciso, com melhor cobertura. Os testes agora são limpos e, embora não sejam automatizados, basta pressionar uma tecla para rodá-los.

No geral, o saldo foi positivo. Nos 6 meses seguintes, houve implementação de builds automáticas. As métricas utilizadas sobre o que realmente pode ser fornecido pelo desenvolvimento são decentes. As equipes na Índia tiveram bons resultados.

Conclusão

A paixão, foco e energia dessas pessoas foi o que moveu a equipe. O Nexus foi um trampolim para o LeSS. É necessário mais suporte para as Feature Teams e a Teoria Y é necessária para essa próxima etapa.

Convenientemente, quando a mudança estava chegando à diretoria, houve resistência. Os colaboradores já estão saindo de lá e indo para outras empresas. Empresas que não tenham resistência às metodologias ágeis.

Não há melhora se a diretoria não compreender isso.

Scrum of Scrums: Como Empresários estão tendo ganhos +40% na velocidade com Agile em projetos de finanças, governo, manufatura, educação…

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original publicado na Forbes, escrito por John Coleman.

Metodologias Ágeis fazem parte do cenário de TI há décadas. O Scrum, especificamente, surgiu nos anos 90.

Em vez de trabalhar isolados em uma bolha por meses e meses, os desenvolvedores são incentivados a trabalhar de perto com a empresa. Há liberação de iterações que melhoram continuamente.

Que lições os negócios voltados a outros setores podem aprender com a experiência que a TI já adquiriu com o Agile?

O que é Agile e Scrum of Scrums?

Ajay Budhraja é especialista em Agile e palestrante renomado. Ele possui décadas de experiência em posições de liderança em grandes empresas. Segundo ele, o Agile é altamente transferível.

Budhraja alertou que há equívocos tipicamente associados ao Agile. “Um deles é que o Agile resolverá todos os problemas em seus projetos”, diz ele. “O Agile oferece técnicas. Ele é como um mapa das linhas de metrô de uma cidade. Você ainda tem que analisar as informações que estão no mapa para entendê-lo e descobrir como chegar do ponto A ao ponto B. Além disso, o Agileainda precisa de documentação básica e muito planejamento.”

Desafios do Agile

Críticos do Agileafirmam que a metodologia não possui boa escalabilidade, e pode até mesmo retardar a entrega de soluções em uma era em que tudo tem que sair rapidamente.

Muitos desses problemas em potencial podem ser superados com uma forte colaboração entre as pessoas da empresa, explica Budhraja. “Alguns dos problemas que vejo são: identificar e monitorar inadequadamente as dependências entre as equipes; falta de planejamento, especialmente com equipes dispersas geograficamente; e foco insuficiente no gerenciamento de mudanças“, diz ele.

“Combinado com lançamentos rápidos e planejados, o Agile pode acelerar a entrega de soluções. Portanto, as equipes precisam trabalhar juntas para que isso aconteça.”

Outros Frameworks e Técnicas

Há também técnicas específicas que podem ajudar as práticas ágeis a escalar em uma parte maior da empresa. Budhraja recomenda o Scrum of Scrums, que “reúne muitas equipes nas quais representantes de cada equipe individual participam de reuniões do Scrum of Scrums.”

Outra técnica, SAFe, “é mais orientada para o processo e aborda isso em três frentes: equipe, programa e portfólio”.

Já a LeSS, ou Large-Scale Scrum (Scrum de Grande Escala), é uma maneira leve de escalar várias equipes.

A chave para garantir que a abordagem seja eficaz é trabalhar com equipes e com gerentes em toda a organização e balancear esse processo com base nas necessidades da organização.

O que é importante para construir uma organização Ágil?

Ele acrescenta que, com abordagens ágeis, as tarefas mudam. Por exemplo, no Scrum, com o Scrum Master facilitando os resultados do trabalho, outros que estavam realizando essas tarefas ficarão menos sobrecarregados.

“Com a entrega rápida, os trabalhos e as tarefas mudam, pois há um foco extremo no planejamento e na execução para entrega incremental.”

Resultados do Agile

Em última análise, as metodologias ágeis melhoraram a entrega de tecnologia nas organizações.

“Técnicas Agile são de entrega rápida e eu tenho liderado grandes projetos com tremendo sucesso nessas áreas”.

Em um projeto web e mobile que Budhraja conduziu usando Scrum, houve aumento de 40% na velocidade de entrega devido a ciclos mais rápidos. Nos projetos financeiros e governamentais, o aumento foi superior a 50%.

feedback dos clientes foi ótimo para esses projetos, já que o produto melhorou muito mais rapidamente.

O Programador pode ser o Scrum Master?

Por Luciano Osorio – Scrum Master da Zappts

Tradução Livre e Adaptada do texto Original publicado no Business 2 Community, escrito pela Stephanie Ockerman.

As pessoas que se perguntam se um desenvolvedor pode ser Scrum Master geralmente já estão desempenhando duas funções. Ou estão prevendo que é isso que vai acontecer com elas.

A resposta curta é: o Scrumnão tem regras contra o desempenho de dois ou mais papéis ao mesmo tempo. Cabe a cada um escolher o que é melhor dentro do contexto de sua organização e sua equipe.

A resposta mais longa envolve refletir se: você deve e você pode desempenhar esses dois papéis?

Contextualizando sua situação

Muitas vezes, essa situação surge do desejo de selecionar alguém de uma equipe de desenvolvimento já existente para ser o Scrum Master. As organizações geralmente não gostam de “adicionar funcionários”, a menos que tenham razões muito boas.

Não há nada inerentemente errado com essa abordagem. No entanto, é importante procurar alguém que possua as habilidades, características, conhecimentos e experiência desejados em um bom Scrum Master.

Para responder se você deve e se você pode, vamos explorar os 4 desafios mais comuns de quem é Scrum Master e Desenvolvedor simultaneamente.

Desafio 1: As responsabilidades do Scrum Master

Primeiro, vamos esclarecer as responsabilidades.

A equipe de desenvolvimento é responsável por criar pelo menos um Incremento de Produto funcional até o final de cada Sprint.

O Scrum Master é responsável por garantir que todos entendam e sigam o Scrum. Para isso, ele ajuda-os a cumprir com mais eficiência suas funções.

“Um Scrum Master atende o Product Owner, a Equipe de Desenvolvimento e a organização. Essa é uma gama ampla de responsabilidades. Se um Scrum Master é percebido pela equipe ou pela organização como apenas um “facilitador de eventos” ou “aplicador do Scrum”, o impacto da função e os benefícios da Agilidade nos negócios são diminuídos.”

Ensinar é mais do que uma simples lição. A facilitação é mais do que definir o tema e conduzir uma reunião. Saber qual abordagem adotar e quando servir melhor uma equipe é muito desafiador, mesmo para Scrum Masters experientes.

As equipes e organizações precisam reconhecer que, se essa pessoa não tiver experiência e habilidades como Scrum Master, ela precisará de suporte. Um treinamento, por exemplo. Isso exigirá tempo e comprometimento. E ainda, reduzirá o tempo gasto com desenvolvimento do produto, o que nos leva ao segundo desafio.

Desafio 2: Focar mais em fazer o trabalho

Muitas vezes, existe uma pressão na organização para “entregar mais”. Além disso, a vocação da pessoa pode ser mais alinhada com o desenvolvimento do produto do que com a liderança da equipe.

Quando qualquer uma dessas opções for verdadeira, será muito desafiador para essa pessoa ter comprometimento suficiente e dedicar mais tempo para se aprimorar como Scrum Master.

Mesmo que a pessoa escolhida tenha uma forte paixão pelo papel de Scrum Master, todos os demais precisarão respeitar isso e dar a essa pessoa o tempo e o apoio necessários.

Isso significa que a equipe de desenvolvimento provavelmente precisará adaptar sua forma de trabalho para enfrentar o próximo desafio.

Desafio 3: Planejamento de capacidade e habilidades escassas

É difícil saber exatamente quanto tempo é necessário para exercer a função dupla de líder-liderado. Também é difícil saber exatamente quanto tempo é necessário para criar um produto complexo que atenda à meta da Sprint e a uma alta qualidade e integridade.

Tanto a equipe de desenvolvimento quanto o Scrum Master estão fazendo um trabalho complexo!

Quando um membro da equipe de desenvolvimento também é o Scrum Master, o resto da equipe de desenvolvimento precisará ser mais flexível e menos dependente desse indivíduo para construir o produto. Isso geralmente requer uma redistribuição dos conhecimentos, habilidades e atividades de desenvolvimento, o que demanda tempo.

Por isso é importante discutir abertamente sobre as necessidades de cada membro e da equipe nas Sprint Retrospectives. O mesmo vale para as conversas do cotidiano.

Desafio 4: Confusão com autoridade, propriedade e auto-organização

Um Scrum Master que também é desenvolvedor precisa respeitar a responsabilidade e a autonomia compartilhadas pelos integrantes da equipe de desenvolvimento.

O Scrum Master é frequentemente visto como o “especialista” e como uma posição de autoridade. Mas é preciso lembrar que a autoridade e o conhecimento de um Scrum Master são especificamente sobre o uso efetivo do Scrum como ferramenta. Não é sobre a melhor forma de criar um incremento funcional ou sobre quanto trabalho deve ser realizado em um Sprint.

Neste cenário, um Scrum Master deve prestar atenção nas dinâmicas de equipe mais complexas.

Como membro da equipe de desenvolvimento, essa pessoa é líder e liderado ao mesmo tempo. Portanto, pode opinar sobre como o trabalho é feito ao mesmo tempo que é responsável pela qualidade e integridade desse trabalho. E, como Scrum Master, a pessoa deseja que toda a Equipe de Desenvolvimento se sinta responsável por criar o Incremento.

Além disso, os desenvolvedores devem entender que têm poderes para decidir qual a melhor forma de realizar o trabalho. Permitir e aumentar a auto-organização se torna ainda mais desafiador.

Conclusão

Então, afinal, você deve e você pode? Primeiro, tenha uma discussão aberta sobre esses desafios listados. Depois faça uma pergunta a si mesmo. Por que você deseja que um membro da Equipe de Desenvolvimento também seja o Scrum Master?

Existem algumas motivações, uma delas pode ser a economia de recursos, ou pode ser que uma das funções não seja vista com a mesma importância. Ambas motivações indicam problemas a serem resolvidos.

Se você descobriu outras razões que parecem válidas, talvez a combinação de papéis faça sentido no seu contexto e valha a pena tentar. Certifique-se de discutir com frequência como isso está funcionando para garantir que o desempenho no projeto não seja prejudicado.

E aí, o que achou do conteúdo? Deixe sua opinião nos comentários e compartilhe-o com sua rede!