Como montar um kanban eficiente?

Quando falamos em kanban, a primeira ideia que normalmente vem a cabeça é um quadro com várias colunas sequenciais. E se você também pensou isso, já sabe bem do que estou falando.

O quadro kanban, realmente é formado por colunas de um fluxo de trabalho, tem começo, meio e fim. Mas como já falei em um artigo sobre conceitos e origem do Kanban, a metodologia vai muito além disso.

No entanto, nesse artigo não vou abordar tanto os conceitos e princípios da metodologia. Quero focar mais no Downstream kanban, que basicamente é o quadro do time de desenvolvimento. Se você quiser saber como funciona esse conceito de separar o quadro da gestão e do time de desenvolvimento, dê uma lida no artigo sobre Upstream kanban.

Bem, já estamos alinhados, então bora para as dicas de como montar um kanban eficiente para o time de desenvolvimento.

Por onde devo começar a montar meu kanban?

O ponto de partida é mapear seu workflow completo. Ou seja, quais são as etapas pelas quais uma demanda passa, desde o momento que ela chega refinada para o time de desenvolvimento. Até o momento que ela é, efetivamente entregue para o cliente.

Destaquei a palavra refinada acima, pois devemos lembrar que para uma demanda chegar no board do time de desenvolvimento, ela precisa estar definida e refinada.

Depois de mapear todo o seu fluxo, crie as colunas do quadro. Lembre-se que as colunas devem representar o seu fluxo de trabalho atual e não aquele que você idealiza. Ficar adicionando passos a mais neste momento vai atrapalhar o time, a evolução é um próximo passo.

É importante também avaliar a necessidade de criar as colunas de espera, por exemplo: você cria a coluna “Em teste”, mas o ideal é ter uma “Aguardando teste” também. O Kanban nos ajuda muito a identificar GAPs, e algumas vezes a tarefa fica mais tempo na coluna de espera, do que na de ação. Isso precisa ser medido.

Lembre-se também de validar e simular todo o fluxo do quadro kanban com o time. É essencial que todos entendam o que cada coluna representa.

Qual o fluxo ideal para o meu kanban?

Quando se trata de Kanban, podemos adaptá-lo da melhor forma possível. Como já falei acima, ele é um processo evolucionário, devemos começar com o básico e evoluí-lo junto com o time.

Mas falando em template, temos passos que normalmente fazem parte do fluxo de trabalho de alguns de times de desenvolvimento.

Vou citar algumas dessas etapas abaixo, e se fizer sentido você pode incorporá-las ao quadro kanban do seu time.

Pronto para desenvolver

Coluna onde ficam todas as tarefas que estão prontas para o time iniciar o desenvolvimento. Se quiser dicas definir bem as atividades para o time, leia esse artigo aqui: Como escrever tarefas para o time de desenvolvimento?

Em desenvolvimento

Todas as atividades que estão sendo desenvolvidas pelo time. É importante que nenhum membro da equipe pode estar desenvolvendo duas tarefas ao mesmo tempo, então só pode haver uma tarefa no nome de cada pessoa, nessa coluna.

Em casos de urgência como bugs ou nova priorização de atividades, é necessário dar um destino para o card com no qual o desenvolvedor estava trabalhando antes.

Pronto para Revisão de código (Code Review)

Se dentro da sua empresa existe a cultura de Code Review entre os membros do time, é interessante manter essa coluna. Onde ficarão as atividades que estão aguardando o Code Review.

É importante avaliar a necessidade dessa coluna, se houver automatização entre o repositório do código e o canal de comunicação do time (Slack por exemplo). E a equipe já tenha a cultura de realizar o code review, talvez essa coluna não seja necessária, e você pode colocar apenas a próxima.

Em Revisão de Código

Toda atividade que for desenvolvida por um dev X, terá o código revisado por outro dev Y. Lembre-se que revisão de código precisa ser baseada em padrões e boas práticas escolhidos pelo time, e que isso não é o mesmo que o trabalho da fase de teste (QA).

Pronto para testar

Aqui vão ficar as atividades que estão prontas para serem testadas. Ou seja, se você tiver um ambiente de QA, a feature precisa estar disponível nesse ambiente para entrar nessa coluna. Normalmente existe um gargalo nessa coluna, se não houver um profissional de QA no time.

Por isso é importante manter o mapeamento dessa coluna.

Em teste

As atividades que estão sendo validadas. Enquanto o teste não for finalizado, a atividade continua aqui.

Pronta para homologação

Se o seu cliente participa do processo de validação, e isso vai depender do momento que o projeto está, essa fase é importante. Da mesma forma da pronto para teste, o card deve entrar aqui quando a atividade estiver disponível para o cliente homologar.

Lembre-se que o nome pronto para homologar é proposital, pois a demanda só estará pronta se o cliente tiver acesso ao ambiente e os dados necessários para teste. Como usuário e senha por exemplo, é básico mas as vezes esquecemos desses detalhes.

Em homologação

Aqui ficam os cards referentes as tarefas que o cliente está homologando. Se for possível utilizar um board que o cliente tenha acesso, será muito bom. Dar visibilidade do andamento do trabalho pra ele, é fundamental.

Pronto para publicar

As tarefas que foram aprovadas pelo cliente, e estão aguardando para serem publicadas no ambiente de produção. Se o seu time tiver um processo de deploy automático, não há necessidade de manter essa coluna.

Finalizado

Finalmente, acabou! Atividades finalizadas, tudo certo.

Bem, essa é uma estrutura sugerida para você montar seu downstream kanban. Mas com certeza cabe adaptações, é sempre necessário avaliar aquilo que faz sentido para o seu time.

Qualquer dúvida, deixe nos comentários.

Upstream kanban: o que é e como funciona?

Já ouviu falar de upstream kanban? Sabe como funciona?

Bem, nesse artigo vou dar uma breve explicação sobre o que é upstream kanban e como ele funciona? Confere ai.

O que é upstream kanban?

O upstream kanban, é o quadro com um workflow que precede o desenvolvimento. Normalmente utilizado pelo P.O., P.M. ou qualquer outro tipo de gestor de projeto.

Ele é formado pelas fases que antecedem o downstream kanban, que é o quadro utilizado pela equipe de desenvolvimento.

O upstream kanban é uma ótima opção, para garantir que a demanda chegará para o dev team, bem definida e refinada. As fases que o compõe são customizáveis de acordo com as necessidades do projeto e também formação da equipe.

Quais as etapas do upstream kanban?

Assim como no kanban de desenvolvimento, no upstream kanban você deve definir as etapas de acordo com o seu fluxo de trabalho. E também deve encará-lo como um processo evolucionário.

Ou seja, não adianta você colocar uma infinidade de etapas, se não houver tempo ou necessidade de executá-las. A ideia aqui é garantir uma demanda bem definida para o seu time, mas algo que seja possível de se realizar e tempo hábil. Afinal, não queremos criar gargalos, antes do desenvolvimento iniciar.

Entrada

Nessa fase são adicionadas as demandas que são puxadas do backlog do produto. Aqui também podem surgir demandas novas, que o cliente ou o próprio P.M. do produto acreditam ser necessárias, considerando o negócio e o momento do mercado.

Pré-refinamento

Nessa etapa, o gestor do projeto deverá ter um entendimento melhor da demanda. Sendo assim, o cliente é um papel fundamental aqui. Pode-se também envolver stackholders e até mesmo pessoas do dev team que tenham conhecimento do negócio.

Refinamento

Depois de entender o objetivo da demanda, está na hora do gestor do projeto definir os critérios de aceite que devem ser cumpridos para realização da demanda.

Além disso, ele pode também escrever os casos de teste para garantir a entrega. Nessa fase, são criados os chamados épicos.

Quebra

Após ter definido o que deverá ser desenvolvido e entregue pelo time. O gestor pode juntamente com a equipe de desenvolvimento, realizar a quebra dos épicos.

Eles devem ser divididos em atividades menores, para facilitar o desenvolvimento e entendimento do que precisa ser feito.

Neste artigo, Como escrever tarefas para o time de desenvolvimento?. Eu falo um pouco sobre a estrutura dos cards do board. Isso pode ajudar no entendimento do time.

Priorização

Depois de realizar todas essas etapas, chegou a hora de priorizar as atividades que precisam ser desenvolvidas.

Neste momento, o gestor deve considerar não só uma ordem lógica de tarefas que possuem dependência entre si. Mas também o que agrega mais valor para o negócio.

O que vem depois do upstream kanban?

Ao final do upstream kanban, começamos o fluxo do downstream kanban. Este último, é o board do desenvolvimento em si.

No artigo Kanban aplicado ao desenvolvimento de software, eu falo um pouco sobre os conceitos e como estruturar um kanban para o seu time.

Indo um pouco além…

Da mesma forma que monitoramos o dowstream, podemos também medir os resultados do upstream kanban. Então a pergunta que fica agora é Como medir os resultados do Kanban?

Devemos lembrar que o Kanban é um fraemework muito eficiente, e que pode auxiliar muito na identificação de gargalos no processo e o que precisa ser melhorado. Por isso, é uma ferramenta poderosa que pode ser utilizada em um processo de melhoria contínua.

Ficou com alguma dúvida? Deixe seu comentário.

Kanban X Scrum: qual devo utilizar no meu projeto?

Kanban X Scrum, qual o melhor para o meu projeto?

Se você gosta de gestão ágil, com certeza já caiu nessa questão. Mas afinal de contas, qual devo usar para gerenciar meu projeto? E qual deles vai se adequar melhor a realidade da minha equipe?

Bom, nesse artigo vamos ver algumas comparações entre os dois, para entender melhor as características de cada um. E no final, você poderá avaliar com mais clareza, qual deles é melhor para o seu projeto.

Kanban: Uma breve visão

O método Kanban, foi inspirado no sistema de produção Just In Time (no momento certo). A ideia é que as tarefas sejam executadas em etapas, e sob demanda. Para utilizar os recursos de forma inteligente, sem desperdício e mantendo o fluxo de trabalho em funcionamento constante.

A partir dessa ideia, foi concebido o método Kanban e seus princípios. Ele, se tornou uma ferramenta importante, e que pode ser utilizado não só como uma metodologia de desenvolvimento de software, mas também como um gerenciador do seu fluxo de trabalho.

O Kanban, assim como outras metodologias ágeis, é um processo evolucionário. Por isso, você pode começar com uma implementação simples e evoluir isso com o tempo.

Se tiver mais interesse em Kanban, dá uma olhada nesse artigo!

Scrum: Entendendo como funciona

O scrum é um framework ágil, que pode ajudar muito na organização do seu projeto e também da sua equipe. O nome scrum veio de uma famosa jogada de Rugby, onde basicamente o time todo se une para conseguir marcar o ponto.

Por esse motivo, o scrum não é apenas uma boa ferramenta para o seu projeto, ele pode ajudar também, a melhorar o processo para a equipe como um todo.

O scrum possui 3 pilares, transparência, inspeção e adaptação. Ele considera todo o time de desenvolvimento, stackholders e cliente, e com isso pode gerar um engajamento maior dos envolvidos no projeto.

Além disso, ele também é um processo evolucionário, que pode ser melhorado com o tempo e se adequar ao que sua equipe precisa.

Se você quer entender melhor sobre o Scrum, dá uma olhada nesse artigo!

Kanban X Scrum: Principais diferenças

Agora que já falamos resumidamente de cada um, vamos falar do Kanban X Scrum e entender as principais diferenças entre eles.

Kanban

Fluxo puxado: As atividades são adicionadas na “esteira de produção”, conforme a demanda do time.
Visualização do trabalho em andamento: O board auxilia muito o gestor do projeto, a ter uma ideia do status do projeto e por isso, na tomada de decisões também.
Terminar mais tarefas ao invés de começar novas: Por ter um fluxo puxado, no Kanban sempre prezamos em finalizar atividades em andamento.
Limitação de WIP (Work In Progress): Limitar a quantidade de trabalho em andamento no board, ajuda o time a focar mais na entrega. E limitar o WIP por coluna do board, ajuda a evitar GAPs nas fases do projeto.
Maior adaptabilidade em projetos de manutenção: Pelo trabalho ser passado ao time, com o princípio “on demand“, fica mais fácil encaixar demandas de última hora no fluxo. Como bugs por exemplo.

Scrum

Fluxo empurrado: Normalmente através do ritual de Planning Poker, o time define quantas atividade vai entregar no período da Sprint.
Papéis definidos: Apesar de ser uma framework adaptável, o scrum exige papéis que são fundamentais para ele funcionar.
Eventos determinados: O scrum possui eventos definidos, que podem ter sua cadência adequada as necessidades da equipe. E todos eles com um timebox recomendado.
Maior dificuldade com projetos de manutenção: Apesar de ser sim possível executar um projeto de manutenção com o scrum, ele é um pouco mais complicado. Isso devido ao controle de atividades da sprint, onde o time define previamente o que vai entregar. E quando surge um bug de última hora, é preciso encaixá-lo, podendo tirar uma tarefa que estava planejada.

Mas afinal, qual devo utilizar?

Isso tudo depende do que sue projeto precisa e de como seu time funciona. Eu recomendo utilizar scrum em projetos que estão começando, e depois o Kanban quando o projeto entrar em fase de manutenção. No entanto os dois funcionam nos dois cenários.

Kanban

Se você deseja metrificar suas entregas por exemplo e ter maior previsibilidade, o Kanban pode funcionar muito bem. Afinal você não vai se basear em estimativas, mas em um histórico do que o time já entregou.

Algumas métricas como Lead Time e Througput, são simples de controlar com o uso do Kanban e também fáceis de entender. Se quiser saber mais do assunto, leia esse artigo: Como medir os resultados do Kanban?

Scrum

Já o scrum é muito bom para ajudar a organizar a “casa”. Equipes que estão com dificuldades de priorizar suas atividades, e não tem muita regularidade nas reuniões de projeto, podem se beneficiar muito do uso scrum.

Fazer o planejamento do que será entregue, revisar o trabalho que foi feito. E fazer uma retrospectiva de como a equipe está trabalhando, são alguns dos eventos do scrum que podem ajudar nisso.

E claro, temos o melhor dos dois mundos o Scrumban, que reúne os rituais do scrum e modelo de gerenciamento do Kanban. É uma excelente forma de trabalho, que pode auxiliar você e seu time.

No artigo de Scrum no dia a dia, eu falo um pouco sobre o uso do Kanban em conjunto, e algumas outras dicas que podem ajudar na implementação do scrum.

Extras

Para finalizar, tem também esse vídeo onde falo um pouco sobre Kanban X Scrum.

Espero que tenham gostado do artigo e que ele possa auxiliar você e seu time no momento de fazer essa escolha. Se tiver alguma dúvida, deixe nos comentários. Até a próxima!

Como melhorar a gestão de projetos?

Como melhorar a gestão de projetos dentro da minha empresa?

Sempre que falamos de gestão de projetos esse e vários outros questionamentos surgem. A verdade é que na maioria das vezes as pessoas não acreditam muito que uma gestão de projetos bem feita possa ajudá-las no dia a dia. E por isso tendem a resistir e duvidar da maioria dos processos de gestão e planejamento.

E quando falamos em agilidade então? A maioria das pessoas já começa a apontar problemas e dificuldades, antes mesmo de começar a rodar o processo.

Mas hoje não vamos falar de agilidade, o foco é como melhorar a gestão de projetos. Independentemente da metodologia, framework ou processo de trabalho que você utilize em sua empresa.

Então vamos ao que interessa!

Como o uso de ferramentas pode melhorar a gestão de projetos?

É fato que utilizar ferramentas para monitorar e metrificar seus processos ajuda e muito na gestão. Mas devemos sempre lembrar que é uma relação de custo benefício. Ou seja, o tempo que você investe preenchendo dados e configurando suas ferramentas, deve proporcionar facilidade no dia a dia para tomada de decisão em tempo hábil, melhorias de processo e informações de qualidade.

No quesito de ferramentas, hoje em dia estamos muito bem servidos. Temos várias ferramentas de qualidade, e de graça no mercado. Como por exemplo:

Trello: É uma ferramenta bem versátil, e de fácil utilização. Além de ter vários “Power-ups” que se integram a uma infinidade de outras ferramentas. Porém hoje sua versão grátis limita a apenas um power-up por quadro.
Pipefy: Tão ou mais personalizável que o Trello, o pipefy traz um gama bem grande de templates prontos. Que vão muito além só do desenvolvimento de software, ele também tem quadros pre-definidos para marketing, RH e várias outras áreas.
Meister Task: Mais voltado para o gerenciamento de equipes de desenvolvimento, ele tem várias opções de personalização para os quadros. E até temporizador, caso queira contabilizar quanto tempo cada tarefa levou para ser desenvolvida.
Slack: É uma ótima ferramenta de comunicação, e que serve muito bem especialmente a times de desenvolvimento. Possibilita integração com vários aplicativos, tem webhooks e vários recursos nativos interessantes, como o remider por exemplo.

Além dessas existem várias outras, e o importante é encontrar aquela que se adeque melhor a realidade do seu dia a dia. Lembre-se que sempre que falamos em melhoria, devemos considerar um processo evolucionário, então comece pelo básico e evolua de acordo com suas necessidades.

Por que é importante ter um processo de gestão bem definido?

Quando falamos em processo, na maioria das vezes pensamos apenas em definir suas fases. Ficamos tão focados em montar o passo a passo do processo, que algumas vezes esquecemos da importância de definir bem o que cada fase representa e quais os critérios dela.

Principalmente em processo de desenvolvimento de software, que pode envolver profissionais de áreas com diferentes diferentes como por exemplo, desenvolvedores, profissionais de QA, devops, e até mesmo clientes. Nestes casos, é preciso ter bem claro o que cada fase representa, por isso devemos definir bem os critérios de entrada e saída de uma atividade em cada uma das fases do processo.

Quais fases devo definir para melhorar a gestão do projeto?

É claro que cada projeto tem seu próprio contexto, e suas dificuldades. Sendo assim, as fases mais importantes a serem definidas mudam de um projeto para o outro, mas no geral temos algumas que são essenciais para garantir a qualidade das entregas e fluidez do processo.

Pronto para ser desenvolvido

Quando uma atividade está realmente pronta para o time começar a trabalhar nela? Quais seus critérios de aceite? Precisa ter mockup anexado, caso de teste escrito? A história do usuário está clara? Enfim, são vários questionamentos, e cabe a equipe toda em conjunto, definir o que é necessário para considerar que uma atividade está pronta para ser desenvolvida.

Pode parecer que isso tudo é muito óbvio, mas como diz um amigo meu: “as vezes o óbvio precisa ser dito”. Afinal nada pior para atrasar um time, do que começar demandas que não estão bem definidas não é mesmo?

Pronto para ser testado

Se o time possui um profissional ou equipe de QA alocada no projeto, ou mesmo se faz testes cruzados entre os devs é muito importante definir isso.

Coisas como publicar a feature ou a correção do bug no ambiente de QA, gerar a versão de teste do aplicativo, atualizar o modelo de dados quando houver alteração. Enfim, pense em tudo que é necessário, e coloque como critério aqui.

Pronto para ser entregue

E finalmente, quando uma atividade está pronta para ser entregue? Ela está realmente utilizável e disponível nos canais de distribuição corretos para seu cliente acessá-la?

Esse pronto é no ambiente de produção, pois a equipe está trabalhando em um projeto de manutenção, ou o pronto é estar disponível em um ambiente de homologação?

Mais uma vez, pode parecer óbvio. No entanto, essa é a fase que mais gera confusão. E muitas vezes o time fica com a sensação de estar terminando várias atividades, enquanto o cliente está achando que o projeto está parado.

Outros pontos importantes no fluxo

É claro que além de definir as fases do processo, temos vários outros pontos importantes. Como comunicação clara e centralizada, tanto com o cliente quanto entre os membros da equipe.

Além disso, priorização de atividades que agregam mais valor para o projeto também é algo muito importante a se considerar no momento de definir no que o time vai trabalhar.

E um último ponto, escreva bem as atividades em que a equipe vai trabalhar. Se quiser saber um pouco mais sobre isso, dá uma olhada nesse artigo aqui: Como escrever tarefas para o time de desenvolvimento?

E o que mais pode ajudar a melhorar a gestão de projetos?

Bom, no começo eu disse que não ia falar de metodologias ágeis, mas não tem como fugir disso.

Porém não vou me alongar no assunto neste artigo. Vou deixar aqui link de dois outros artigos que escrevi, um sobre Scrum e outro sobre Kanban. Pra quem se interessar.

O uso de métodos ágeis ajuda e muito a melhorar a gestão de projetos!

É isso pessoal, por hoje ficamos por aqui. Qualquer dúvida, deixe nos comentários.

Até a próxima!

Como medir os resultados do Kanban?

Como medir os resultados do Kanban? Sempre que falamos da utilização da metodologia Kanban em projetos, essa é é uma das primeiras dúvidas que surgem.

Por ser uma metodologia menos prescritiva, onde o fluxo de demandas é “puxado” de acordo com a necessidade do time. Algumas pessoas acreditam que Kanban não trabalha com prazos. Mas não é bem assim que as coisas funcionam.

O Kanban possui várias recomendações, e uma metodologia muito efetiva se praticada da forma correta. Como já mencionei neste artigo sobre Kanban, não basta ter um board dividido em colunas, com alguns cards distribuídos, para realmente trabalhar com Kanban.

Além dos pontos citados no artigo que mencionei acima, o Kanban tem uma outra vantagem. Todos os resultados que metrificamos são baseados em histórico e não estimativas ou achismo, isso nos dá uma grande vantagem.

Mas chega de falar dos benefícios, vamos ao que interessa.

Como medir os resultados do Kanban?

O primeiro passo para conseguir medir os resultados, é ter um workflow bem definido. Ou seja, mapeie muito bem as fases do seu processo de desenvolvimento. Desde o momento em que a demanda é concebida, passando pelo desenvolvimento em si e chegando até a entrega efetiva para o cliente.

É claro que devemos sempre considerar que o Kanban é um processo evolutivo. Então não faça mais do que você precisa, comece com o básico. Primeiro criei o board com um processo básico, e depois vá adicionando as fases que fazem sentido.

Com o processo rodando bem, você deve evoluir para começar a medir os resultados. E ai é importante ter tudo bem detalhado. Uma dica é utilizar o esquema de colunas de espera e de ação, por exemplo uma coluna “Aguardando teste” e a seguinte seria “Em teste”. Assim você consegue medir o tempo em que a tarefa levou para ser testada, e o tempo em que ficou na fila de espera.

Na maioria das vezes, a tarefa leva mais tempo “esperando” do que sendo executada, ai você começa a identificar os gargalos no processo.

Medindo os resultados através do Throughput

A primeira métrica que vamos abordar é o throughput, e apesar do nome ser meio complicado, ela é bem simples de entender.

Basicamente ela mede a capacidade de entrega do seu time, em um ciclo de tempo. Ou seja, quantas tarefas ou histórias de usuário seu time consegue entregar dentro de uma semana?

Com isso você pode perceber a frequência das entregas e a “capacidade” do seu time. Se pensarmos em um cenário onde a equipe trabalha com histórias de usuário com tamanho e complexidade parecidos, é possível ter previsibilidade de quando uma feature será entregue.

Uma forma muito boa de se quebrar tarefas é utilizando a Matriz de complexidade e incerteza. Se você ainda não conhece, dá uma olhada nesse artigo Requisitos em equipes ágeis: Falando sobre complexidade e incerteza do Raphael Albino.

Nesse gráfico podemos observar que a equipe não está tendo uma tendência nas entregas. Seria um pouco difícil de dar previsibilidade para o cliente dessa forma.

Uma segunda coisa interessante deste gráfico é a categorização de atividades. Como pode-se observar existe uma separação entre “Story” e “Bugs”.

Categorizando atividades

Uma prática muito boa também para medir os resultados do Kanban, é sempre categorizar as atividades. Assim é possível perceber onde o esforço da equipe está sendo investido. Pois o time pode estar entregando 10 atividades por semana, mas se 8 forem bug, com certeza o cliente não vai estar enxergando muito valor nessas entregas. E nesse caso é necessário fazer um alinhamento de expectativas, e entender o motivo de tantos bugs.

Entendendo o Lead Time

Uma segunda métrica que pode ajudar bastante no entendimento do que está acontecendo no projeto, e na tomada de decisões é o Lead Time.

O Lead Time é bem simples também, ele contabiliza o tempo total para uma tarefa fica pronta. Desde o momento em que ela entrou na fila de desenvolvimento “To do”, até o momento em que ela é entregue e chega na coluna “Done”.

Como medir os resultados com Lead Time e Lead Time Breakdown

Além do Lead Time, existe o Lead Time Breakdown. Nele podemos visualizar o tempo total para tarefa ficar pronta, e ainda quanto tempo ela ficou em cada fase.

Por isso é importante termos a separação das colunas de espera e de ação. Imagine por exemplo que uma demanda ficou 15 dias na coluna “Ready to homolog”, aguardando a homologação do cliente. E depois apenas 2 dias na coluna “In Homolog”. Ou seja, seu cliente levou duas semanas para homologar um item que ele pode validar em apenas 2 dias.

Dei esse exemplo, pois isso já aconteceu em projetos que gerenciei. E foi através do gráfico de lead time breakdown que mostrei ao cliente, que os atrasos dos quais ele questionava, estavam sendo causados pela demora dele na fase do processo que dependia dele.

Este gráfico particularmente é um dos meus preferidos, é simples de entender e pode dar muitas informações. No eixo X temos os itens de trabalho, e no eixo Y os dias que levaram para serem feitos.

Além disso, podemos observar quanto tempo o item ficou em cada fase do processo. O número 0 nas colunas, significa que o item não ficou nenhum dia naquela fase.

Neste exemplo podemos observar que existe um GAP imenso na fase de deploy. Isso pode ser causado por falta de um processo bem definido de publicação, ou burocracia interna. O ideal seria um processo de deploy automático, mas sabemos que no dia a dia nem sempre é assim.

Sendo assim, seria o caso de acionar algum responsável na empresa que pudesse resolver isso, para agilizar a liberação de novas funcionalidades em produção.

Tem muito mais para medir os resultados do Kanban…

Essas métricas são apenas algumas das que podemos utilizar no nosso dia a dia. Mas se você nunca utilizou, sugiro que comece por elas. Garanto que irão ajudar muito, tanto no relacionamento com sua equipe, quanto no alinhamento de expectativas com o cliente.

Além dessas, temos também o Burn Down, muito utilizado com o Scrum. O Burn Up, CFD, gráfico de eficiência do fluxo e muitas outras métricas que podem ser utilizadas.

Se interessou pelo assunto? Então fique de olho no blog, que em breve sai post novo falando mais sobre métricas.

E caso tenha alguma dúvida, deixe nos comentários.

Até a próxima!

Scrum na prática: Entendendo o fluxo

Para dar continuidade em nossa trilha de como utilizar scrum na prática, neste segundo artigo vou falar sobre o fluxo do scrum.

Caso você ainda não tenha ouvido falar de scrum, ou não esteja familiarizado com os termos deste framework. Sugiro que leia o primeiro artigo da nossa trilha “Scrum na prática: Introdução“.

Bom, agora que já temos a introdução aos termos e conceitos, é hora de começar a entender o fluxo do scrum. Vamos lá?

Visão do produto

O primeiro passo para um time que vai utilizar o scrum na prática, começa um pouco antes dos tradicionais eventos que sempre ouvimos falar.

Antes de por o scrum pra rodar, é importante que o P.O., passe para o time uma visão clara do produto. Esse visão pode ser dada de uma forma macro, para que a equipe possa visualizar os seguintes pontos:

Qual o objetivo do produto que estamos construindo
O que queremos alcançar com este produto
Quais os objetivos de negócio envolvidos no nosso projeto
Quais são as expectativas do cliente com esse produto

Enfim, tudo que está relacionado a direção do produto em si. Desta forma, teremos uma equipe alinhada com os objetivos daquele projeto e fazendo parte da concepção do mesmo.

Montando a lista de funcionalidades

Depois de alinhar com o time os pontos citados acima, é hora do P.O. definir uma lista de funcionalidades para atingi-los. Ou seja, ele precisa definir quais as funcionalidades e recursos necessários que precisarão ser desenvolvidos para criar um produto alinhado com os objetivos do cliente.

Por ser uma missão um pouco complexa, o P.O. pode pedir auxílio para o S.M. e até mesmo para membros mais experientes do Dev Team no momento de definir essa lista.

Priorizando as funcionalidades

Após ter a lista completa de funcionalidades, o P.O. deve fazer a priorização delas. Ou seja, ele precisa definir a ordem em que todas as atividades serão desenvolvidas.

Além disso, é muito importante que o P.O. sempre leve em conta o valor agregado que cada recurso irá trazer para o produto. Dessa forma ele conseguirá juntamente com o Dev Team, desenvolver um projeto que entrega valor para o cliente frequentemente.

E com essa lista de funcionalidades definida e priorizada, temos o nosso primeiro artefato do scrum. O Product Backlog, será o pontapé inicial para a equipe começar a usar o scrum na prática.

Começando o scrum: Planejamento

Com o product backlog pronto, vamos começar nosso fluxo. Mas para falarmos deste fluxo, precisamos entender primeiro sobre o principal ciclo de trabalho do scrum, a sprint.

A sprint nada mais é do que o ciclo de trabalho onde o time desenvolve uma lista de funcionalidades pré-selecionadas. Normalmente com duração de duas a quatro semanas. É importante enfatizar também, que as sprints do projeto devem ter tamanho fixo, ou seja, se a sua primeira sprint durou duas semanas, esse ciclo de duas semanas deverá se repetir até a conclusão do projeto.

Com isso entendido, vamos continuar falando do fluxo. E aqui vamos entender o primeiro evento do scrum, o Sprint Planning.

No evento de sprint planning, o time se reuni e seleciona quais atividades do product backlog, irão formar o sprint backlog. Sempre respeitando a ordem de priorização da primeira lista, não se pode por exemplo pegar o primeiro e terceiro item do product backlog, deixando o segundo pra trás.

A ideia é planejar os itens que iremos conseguir entregar ao final da sprint. Claro, que é difícil tem essa previsão. Mas para isso podemos utilizar o Planning Poker. E com o tempo, a equipe vai entendendo melhor os pontos, e o que consegue fazer em cada sprint.

Além disso, o sprint planning não deve ser utilizado apenas para definir “o que será entregue”, mas também “o como isso será desenvolvido”. Então é importante que o time discuta tecnicamente sobre os itens, e sane com o P.O. as dúvidas relacionadas as regras de negócio. Por isso, o timebox recomendado para este evento, varia de 4 até 8 horas, dependendo do tamanho da equipe e duração da sprint a ser planejada.

Continuando com o Scrum: O Fluxo de trabalho

Após definirmos o nosso sprint backlog, é hora de começar a rodar nossa sprint. Então o dev team inicia o desenvolvimento das atividades efetivamente, de acordo com o que foi definido no sprint planning.

Durante esse ciclo, a equipe deve realizar diariamente a daily scrum, no horário combinado. Para que seja alinhado como está o andamento do projeto, devemos lembrar que inspeção e transparência são pilares do scrum.

Garantir que o evento da daily seja realizado todo dia, que a equipe participe ativamente e respeite o timebox máximo de 15 minutos, é papel do S.M. Isso é tão importante quanto remover os impendimentos que possam surgir no caminho, e está contemplado na atuação dele dentro do projeto.

Um pouco mais de Scrum: O fechamento do fluxo de trabalho

Ao terminarmos a sprint, entramos na fase final do fluxo de trabalho. A etapa onde iremos revisar e avaliar tudo que foi desenvolvido e praticado durante a sprint.

A primeira reunião de fechamento é a sprint review, que como já mencionei no artigo anterior serve para avaliarmos se os itens desenvolvidos na sprint, estão de acordo com o esperado. Nela o P.O. também pode dar manutenção no product backlog.

Depois da review, acontece a retrospectiva. Esta é a reunião aonde avaliamos como está nossa execução do processo, e como anda nossa prática do scrum. Como também já falei anteriormente, nesse espaço a equipe pode discutir sobre o que precisa parar de fazer, ou melhorar na próxima sprint.

Além disso, no final deve acontecer o incremento do produto. Devemos lembrar, que no scrum o time é sempre responsável por manter uma versão estável e utilizável do produto. Por isso a entrega deve agregar novos recursos funcionais, mas sem prejudicar o que já existe.

Concluindo o ciclo do scrum

Bom pessoal, esse é um resumo de como o fluxo do scrum funciona. E apesar de parecer muita coisa, o importante é entender os conceitos e começar a aplicá-los no dia a dia.

O próximo e último artigo dessa trilha fala sobre Scrum no dia a dia, e nele dou algumas dicas de como aplicá-lo. E também falo de ferramentas complementares, que podem auxiliar na utilização deste framework.

Scrum na prática: Introdução

Como utilizar o scrum na prática? E como aplicá-lo no dia a dia de forma efetiva?

Se você trabalha com gestão de projetos, ou desenvolvimento de software, com certeza já ouviu falar de Scrum. E provavelmente sobre alguns dos cases de sucesso famosos com sua aplicação, como no Spotify por exemplo.

Apesar de sempre vermos o scrum definido como “um framework simples para gerenciar projetos complexos”. A verdade é que ele é bastante prescritivo, e leva um tempo para a equipe se adequar a todas as suas práticas. Mas com certeza podemos alcançar bons resultados com ele.

Neste artigo vou falar dos conceitos deste framework. Este será o primeiro de uma trilha que irei escrever, que irá desde da teoria até o scrum na prática. Vamos lá?

PILARES

Transparência

Todo o time pode e deve ter acesso a todas as informações relacionadas ao projeto. A ideia é que a informação fique compartilhada, e assim, gestores, clientes e stakeholders possam acessá-la a qualquer momento.

Por isso é importante que a equipe defina quais ferramentas irá utilizar para se comunicar, e quais documentos irá gerar no decorrer do processo. Já que isso não é definido pelo Scrum, que deixa essa parte por conta do próprio time, para que faça da melhor forma.

Uma ferramenta que pode auxiliar nisso, originada de outra metodologia ágil é o quadro kanban. Que pode dar visualização de como estão todas as atividades do time.

Inspeção

Tanto o desenvolvimento das atividades, quanto a execução do próprio processo podem ser inspecionados a qualquer momento. A intenção da inspeção é que todos fiquem sempre alinhados sobre a situação do projeto. Mas essa inspeção, não deve ser excessiva a ponto de atrapalhar o desenvolvimento das atividades, ou de micro-gerenciar as pessoas.

Na parte do desenvolvimento a inspeção ocorre através de dois eventos, que são “Daily Scrum” e “Sprint Review”. Já o processo, pode ser inspecionado durante a “Sprint Retrospective”. Todos esses eventos, serão explicados mais abaixo.

Adaptação

O último pilar, garante que o processo do Scrum seja sempre adaptado quando necessário. O mesmo é válido para as diretrizes do produto, que como possui ciclos menores de interação com o cliente, também tem a possibilidade de ser adaptado com maior facilidade.

PAPÉIS

Product Owner (P.O.)

Responsável por direcionar o produto, é ele quem define quais as funcionalidades que serão desenvolvidas. E também faz a priorização delas para o time. Além disso, ele deve sempre deixar claro quais são os objetivos daquele projeto e passar a visão do produto para sua equipe.

Scrum Master (S.M.)

É o membro da equipe que deve dominar as práticas do Scrum. Conhecido como facilitador, ele sempre auxilia e garante que o time está executando o processo corretamente.

Dev Team

É quem propriamente desenvolve o produto, e tem o poder de decidir a melhor forma de fazer isso. No Scrum o time de desenvolvimento tem autonomia para escolher de qual maneira irá desenvolver suas tarefas, para atingir os objetivos do projeto. A equipe deve ser auto organizada e multifuncional.

EVENTOS

Sprint Planning

Nessa reunião, o dev team conversa sobre os itens do product backlog e seleciona o que entrará na sprint backlog. Sempre respeitando a ordem de priorização definida pelo P.O.

Além disso, o time também aproveita para debater como a demanda será desenvolvida, e nessa hora o P.O. pode explicar os requisitos e objetivos daquela estória de usuário. Assim a equipe conseguirá ter um entendimento mais claro, e poderá definir em conjunto qual a melhor forma de atender a demanda.

Daily Scrum

Reunião que deve acontecer diariamente para que toda a equipe fique alinhada sobre o andamento do projeto. Deve ser feita com todos os membros de pé, pois precisa ser algo rápido, durando no máximo 15 minutos.

Normalmente os desenvolvedores respondem a 3 perguntas:

O que foi feito ontem?
O que planeja fazer hoje?
Teve ou tem algum impedimento?

Sprint Review

Realiza ao final de toda sprint, essa reunião serve para avaliar se todos os itens de trabalho da sprint estão de acordo com o que cliente espera. Aqui o time apresenta o que foi desenvolvido para o P.O., e ele irá avaliar a entrega.

Nesta reunião, é comum a participação de stakeholders do produto. E nela também, que podemos realizar a manutenção do product backlog.

Sprint Retrospective

Realizada após a review, a reunião de retrospectiva serve para equipe avaliar como está trabalhando como o framework em si. Ou seja, como estão utilizando o scrum na prática e quais os resultados disso.

Alguns textos falam sobre levantar pontos negativos e positivos da sprint. Mas eu prefiro os autores que sugerem utilizar os seguintes questionamentos:

O que fizemos de bom?
O que precisamos melhorar?

E para tudo aquilo que precisamos melhorar, a equipe pode definir uma ação.

ARTEFATOS

Product Backlog

Lista de funcionalidades do produto, é criada, priorizada e mantida pelo P.O., utilizada pelo time durante o sprint planning.

Sprint Backlog

Funcionalidades selecionadas do product backlog, pelo time de desenvolvimento durante o planning. O ideal é que essa lista de itens, seja entregue no final da sprint.

Entregas Incrementais

Ao final de toda sprint, a equipe deve incrementar o produto com um entrega funcional.

Este foi o primeiro artigo da trilha de “Scrum na prática”. Onde dei uma introdução dos conceitos deste framework. E no segundo artigo, você pode conferir como funciona o fluxo do scrum.

Como escrever tarefas para o time de desenvolvimento?

Qual a melhor forma de passar demandas para o time de desenvolvimento? Sempre que falamos de gerenciamento de projetos, caímos nesse impasse. Mas como podemos fazer isso de uma maneira efetiva?

Como já falei em outro post do blog, o Kanban é uma boa alternativa pra organizar o fluxo de desenvolvimento. Mas além disso, é importante também, criar tarefas bem descritas para a equipe.

Para isso, podemos utilizar alguma estrutura padrão ao montar nossos cards no board.

Claro que os rituais como Refinement, ou Planning são de extrema importância para compartilhar as demandas com o time de desenvolvimento.

No entanto, neste post vou falar apenas em como escrever os cards de atividades e os resultados que podem ser obtidos.

Motivação

Pra começar, é sempre bom definir qual a motivação daquela tarefa. A ideia é que ao ler esse tópico, o desenvolvedor entenda o porquê de estar realizando aquela atividade. E além disso, qual o objetivo dessa funcionalidade dentro do sistema, o motivo dela existir e precisar ser desenvolvida naquele momento.

Pode parecer desnecessário, ou que isso está sempre subentendido. Porém, ter essa descrição na tarefa pode trazer muitos benefícios, como por exemplo:

Sensação de pertencimento do desenvolvedor, pois ele percebe que pode ajudar a pensar na solução.
Empatia pelo usuário. Quando se entende o problema que será solucionado e como o recurso será utilizado, fica mais fácil ter essa visão.
Alternativas de soluções mais eficientes. Quando o desenvolvedor consegue enxergar o todo, ele pode sugerir alternativas menos custosas em tempo de desenvolvimento, e por isso pode solucionar o problema com menos recursos.
Facilidade no entendimento. Ao entender os motivos relacionados a atividade, a compreensão do todo fica mais clara.

Critérios de aceite

Essa é uma parte fundamental ao escrever as tarefas. Quando listamos os critérios de aceite, estamos definindo o escopo do que será entregue e o que deve ser considerado no desenvolvimento dessa atividade. Portanto, é vital definir muito bem todos os critérios de aceite.

Os critérios de aceite precisam ser claros e objetivos, e além disso devem garantir a qualidade da entrega. Afinal é a partir destes critérios, que iremos alinhar com o time as expectativas dos stakeholders envolvidos. Portanto, esse tópico certamente é o mais importante a ser considerado no momento de escrever nossas tarefas.

Além dos pontos citados acima, a definição bem feita dos critérios de aceite contribui para o foco naquilo que deve ser entregue. Ou seja, o time de desenvolvimento sabe exatamente o qual o resultado esperado e investe seu tempo apenas no necessário.

Membro do time de desenvolvimento realizando teste — Os critérios de aceite e casos de teste, auxiliam o time de desenvolvimento na validação das atividades.

Casos de teste

Um outro ponto importante a se considerar no momento de escrever as tarefas, são os casos de teste.

Além dos critérios de aceite, é muito importante criar casos de teste para garantir que a entrega esteja alinhada com a expectativa do cliente.

Quando você define como testar uma atividade, consequentemente contribui para que o desenvolvedor entenda melhor o que precisa fazer.

E acima de tudo, os casos de teste servem para validar a qualidade da entrega. Auxiliando o time de desenvolvimento a realizar testes mais precisos que podem verificar funcionalidades específicas de suas atividades.

Uma boa ferramenta para auxiliar na escrita destes casos de teste é o Forrest.

Extra: Mockups!

Não é para toda demanda, mas mockups das telas são essenciais na maioria dos casos. Ter o desenho do resultado final da tela, pode ajudar e muito o time de desenvolvimento no momento de entender e desenvolver uma atividade.

Existem alguns casos, como demandas onde já existe um padrão de tela, que isso não é necessário, mas devemos utilizar deste recurso sempre que possível.

Conclusão

Resumindo, quando vamos escrever tarefas para o time de desenvolvimento, devemos adicionar os detalhes que irão contribuir para a qualidade da entrega e que valem o esforço.

Ou seja, não devemos investir tempo demais adicionando informações que ninguém irá utilizar, ou que não ajudarão efetivamente a equipe.

Sabemos que não existe um modelo perfeito e nem um padrão único, que possa se adequar a todas as equipes ou projetos.

No entanto, com essa estrutura você pode ter bons resultados. E com o tempo pode evoluir isso da forma que for melhor para o seu time.

Caso esteja com dificuldades ao alinhar as expectativas ou garantir a qualidade das entregas. Ou até mesmo, se estiver tendo muito retrabalho com o seu projeto, experimente escrever as tarefas seguindo essa estrutura. Você pode ter bons resultados com o seu time de desenvolvimento!

Se tiver alguma dúvida, deixe nos comentários.

STATIK – O que é e como funciona?

Você já teve dificuldades ou está com problemas ao tentar implementar o método Kanban no processo de desenvolvimento do seu time? Se a resposta for sim, uma boa alternativa é rodar o STATIK com sua equipe, para ajudar no entendimento, adoção e adaptação do Kanban ao dia a dia do time.

Como funciona?

STATIK – Systems Thinking Approach to Introducing Kanban.

O STATIK é formado por 8 passos básicos, cada um deles serve para entender a realidade do time e como o quadro kanban deverá ser montado.

Apesar de ter um “roteiro base”, você nem sempre precisa fazer todos os passos com sua equipe e também pode mudar a ordem deles da forma que achar melhor. O STATIK não é estático.

1. Entenda seu cliente

No primeiro passo, o time deve definir junto quem é o cliente que estão atendendo. Uma boa dica neste passo é usar o template abaixo para essa definição:

NÓS COMO <quem é o time>
PROVEMOS <o que o time faz>
PARA <cliente>
A FIM DE <motivo pelo qual o cliente contratou aquele time>

Neste passo assim como durante todo o processo, devemos abrir um espaço para que o time discuta e debata sobre estes pontos. Além de definir quem é seu cliente, é importante entender como a equipe se enxerga e qual é o propósito dela no contexto do projeto.

2. Insatisfações

No passo 2, vamos levantar todas as insatisfações da equipe relacionadas ao processo atual. Importante deixar claro que esse mapeamento deve considerar o processo completo.

Aqui é legal distribuirmos post-its, para que as pessoas escrevam suas insatisfações. Isso normalmente as deixa mais a vontade.

post-its com o STATIK — Post-its são importantes para “quebrar o clima” da dinâmica.

Depois que as insatisfações estiverem anotadas, é interessante pedir para que elas sejam categorizadas em internas e externas.

Internas: são tudo que envolve o time de desenvolvimento.
Externas: que são relacionadas as insatisfações geradas para o cliente.

Normalmente o número de insatisfações internas é muito maior, e aqui podemos enfatizar a importância da empatia pelo cliente.

3. Análise de demanda

Nesta fase iremos analisar o tipo de demanda em que o time está trabalhando. Normalmente pedimos para que os membros da equipe escrevam no post-it em qual atividade estão atuando no momento, e depois disso conversamos um pouco sobre essas demandas.

A intenção aqui é entender quais os tipos de atividades que estão chegando para o time. Se são features, bugs, demandas vindas direto do cliente ou geradas internamente e com qual frequência esses itens estão chegando para a equipe.

Dessa forma conseguimos ter uma noção do volume de cada tipo de demanda.

4. Análise de capacidade

Agora é hora de entender como está a capacidade do time. Aqui podemos começar levantando os últimos itens entregues pelos membros da equipe. E questioná-los sobre qual o tempo médio gasto para entregar cada um deles.

Caso o time tenha um histórico de entregas é interessante olharmos para isso também.

Neste passo podemos falar das primeiras métricas que podem ser analisadas com o uso do quadro kanban. Como a quantidade de itens entregues em um determinado ciclo de tempo (Throughput), ou o tempo total de atuação do time desde a entrada até a a entrega de um item (Lead Time).

5. Workflow

Neste passo devemos mapear o workflow completo do processo, entendendo todas as etapas pelas quais um item passa. Considerando o momento que ele entra na fila de desenvolvimento, até a fase em que será liberado para o cliente.

Precisamos entender o passo a passo do processo, e mais do que isso, o que ocorre com cada tipo de demanda. Atividades de natureza diferente, podem passar por fases específicas do fluxo.

É muito importante entender o que cada fase representa dentro do processo atual, e como iremos adaptar isso no modelo novo.

6. Classes de serviço

Aqui vamos falar mais uma vez sobre os tipos de demandas, mas neste caso focando as classes de serviço. A intenção é entender o processo de priorização e como podemos trabalhar isso com o time no novo quadro.

Classes de serviço normalmente são aquelas “raias” no kanban. Elas servem para definir uma escala de prioridade e ajudam o time a saber o que deve atender primeiro.

Este é um passo bem interessante, porém recomenda-se explorá-lo apenas com equipes de maior maturidade.

7. Design Kanban System – Modelando o novo fluxo de trabalho

Finalmente chegou a hora, vamos modelar o novo quadro kanban.

Aqui vamos usar todas as informações recolhidas durante o STATIK e modelar um kanban que adeque-se a realidade do time. É importante que a equipe participe desse processo, entendendo o que cada coluna do board representa no novo fluxo.

Devemos lembrar que o Kanban é um método evolucionário, por isso vamos criar o novo quadro com aquilo que é essencial para a equipe trabalhar. Com o passar do tempo e rodando o novo fluxo, o time pode alterar o quadro e adequá-lo as necessidades que surgirão.

8. Rollout

Com tudo pronto, é hora de colocar o novo fluxo para rodar.

Agora vamos testar nosso kanban novo, envolvendo as pessoas que participam do processo. Para o sucesso da implementação desse modelo devemos contar com a colaboração de todos.

Precisamos lembrar que as as recomendações são acompanhar o processo e melhorá-lo sempre que possível. O Kanban é um processo de melhoria contínua então fique sempre atento por melhorias e problemas que sua equipe pode apresentar.

Neste vídeo eu falo um pouco sobre o STATIK. Inclusive nessa explicação os passos foram abordados de uma forma diferente do artigo, confere ai:

https://www.youtube.com/watch?v=aA9EhpPUOlY

Se tiver alguma dúvida, deixe nos comentários.

Entenda como a gestão de software ágil pode ajudar sua empresa

Desde que a tecnologia vem sendo empregada nos negócios, algumas premissas de agilidade e eficiência passaram a ganhar um novo significado. Novas funcionalidades, como automação e virtualização de recursos, vêm materializando uma nova metodologia de trabalho denominada DevOps.

Esse novo conceito de governança de Tecnologia da Informação tem sido uma proposta bastante interessante para o atual mercado, indo ao encontro das exigências de redução de tempo de resposta para o cliente e de redução dos custos empregados nessa ação.

Mas, o que é DevOps? Quais são as melhorias propostas para os negócios? Essas e outras respostas você terá no decorrer deste conteúdo. Continue a leitura e saiba mais!

O que é DevOps?

Antes de falarmos sobre sua definição propriamente dita, vamos começar explicando que a palavra DevOps pode ser entendida a partir de duas partes: adequação de processos de desenvolvimentos (Dev) e operação (Ops) para um ciclo contínuo de execução.

Esse processo facilita a integração e os processos entre os recursos envolvidos e reduz o tempo de resposta com foco em eficiência e eficácia. Assim, é possível dizer que o DevOps surge como uma opção de reunir pessoas, processos e produtos e permitir a entrega contínua de valor aos usuários finais. Mas, afinal, o que é DevOps?

Em linhas gerais, DevOps utiliza a capacidade máxima da empresa para aumentar seu desempenho por meio de um conjunto de ferramentas e culturas, ou seja, distribuir serviços em alta velocidade. Nesse sentido, podemos dizer que é uma prática de TI que visa unir o desenvolvimento de software com as operações e os processos da empresa, integrando as áreas e alcançando uma maior qualidade nas entregas.

Quando as áreas não são integradas, há uma maior possibilidade de ocorrerem atrasos na entrega e falhas de comunicação dos times, o que pode resultar em retrabalhos e, até mesmo, baixa qualidade. Uma das características dessa situação é uma entrega de atualizações mais frequente, porém pequena. Assim sendo, com o DevOps o gestor tem um ciclo de desenvolvimento menor e as liberações são mais seguras e com melhor alinhamento aos objetivos do negócio.

Esse tipo de prática tem ajudado muitas empresas na integração contínua e na entrega eficiente dos seus produtos e/ou serviços. Por meio dela, é possível alcançar a padronização de ambientes de desenvolvimento, homologação e produção, além de auxiliar no gerenciamento e no controle sobre o ambiente e a infraestrutura.

Quais são os benefícios do DevOps?

Integrar comunicação e processos automatizados possibilita um entrosamento maior entre os times de desenvolvimento e operação. Além disso, a utilização de DevOps reduz o gap entre o desenvolvimento e a operação, já que cria um esquema de atuação que conta com uma equipe multidisciplinar.

Por sua vez, esta usa ferramentas automatizadas para construir códigos, testar, controlar incidentes e resolver problemas em um fluxo integrado e sinérgico. Entre outros benefícios, podemos destacar os que seguem.

Possibilita maior controle do produto desde a produção inicial

Por muito tempo, os processos de criação e de controle de qualidade foram divididos. Além disso, a elaboração de um software que contemplasse essa junção nem sempre atendeu seus objetivos com precisão, resultando em falhas na comunicação entre eles.

A cultura do DevOps tem como premissa que um bom controle de qualidade deve ser feito pelo mesmo grupo desde o início. Isso porque quando as pessoas já estão engajadas no que deve ser feito, a produção passa a ter maior agilidade, facilidade de comunicação e eficiência de todos os envolvidos.

Tanto as equipes de infraestrutura quanto de desenvolvimento precisam caminhar em prol de um só objetivo: entregar o produto ao cliente dentro do prazo e com a qualidade desejada.

Agrega inovação aos processos

As áreas de desenvolvimento e de infraestrutura passam a integrar suas fases de comunicação. Isso possibilita que as atualizações de softwares possam ser feitas simultaneamente, sem perder tempo na resolução de problemas.

A prática de DevOps prega que os objetivos devem ser correlatos, ou seja, um produto deve ser atualizado conforme as tendências de mercado ou de seus concorrentes. Quando isso não ocorre, ele se torna falho logo em seu núcleo.

Busca investimento em automação e infraestrutura tecnológica

Com a aplicação de recursos em infraestrutura tecnológica e automação dos processos, é possível reduzir custos financeiros e temporais, além de aumentar a qualidade do produto final. Utilizar DevOps exige que o gestor invista em automação dos processos, o que consequentemente reduz a incidência de erros e retrabalhos, economizando em gastos e gerindo melhor a equipe de trabalho.

É uma metodologia que evolui

A metodologia DevOps também evolui com o tempo. No entanto, é necessário que os gestores e toda a equipe conheçam os gargalos que persistirão em cada fase.

Como você pode perder dinheiro com DevOps próprios?

Tendo em vista as explicações acima, fica mais fácil entender o fundamento do DevOps, que junta desenvolvimento e operações de sistemas em uma única abordagem.

A aplicação do DevOps utiliza desenvolvimento ágil, porém, em vez de estar restrita apenas ao departamento de sistemas, ela pode ser aplicada para as atividades da equipe de infraestrutura, integrando práticas em um só modelo.

Isso possibilita que haja uma comunicação eficiente entre desenvolvedores e operações (infraestrutura) no ciclo de vida de desenvolvimento, na entrega e na operação de sistemas e serviços.

Abaixo, saiba mais sobre os principais fatores que explicam como você pode perder dinheiro com DevOps próprios.

Não investir em inovação

Para se manterem competitivas no mercado, as empresas precisam estar em constante evolução e desenvolvimento (Dev). Por sua vez, também necessitam estar atentas e certificar-se de que a infraestrutura e os sistemas (Ops) estejam devidamente preparados para receber as inovações da equipe de desenvolvimento. Caso as áreas não estejam compatíveis com as novas proporções de cultura organizacional, o investimento pode acabar sendo um tiro no pé.

Não capacitar e integrar a equipe

A implementação de DevOps exige que haja uma mudança cultural em toda a organização. Essa mudança requer capacitação e treinamento dos colaboradores, de modo que busquem ferramentas adequadas que efetivamente auxiliem no seu trabalho.

Quando a empresa utiliza DevOps, mas não integra ao máximo seus times de desenvolvimento e de operações, acaba perdendo os benefícios dessa prática. Assim, em vez de ter uma equipe que especifica o software e a outra que programa, tais setores devem trabalhar integrados, visando à criação de um ciclo ideal de projetos.

Esse ciclo permite uma rápida entrega, mesmo que existam atualizações, automatizando processos e melhorando a colaboração entre todos os integrantes do time. As tarefas podem ser realizadas com maior segurança e estabilidade, já que as equipes de testes e qualidade também podem (e devem) ser integradas.

Não realizar entregas de atualizações constantes

Sem dúvida, não realizar entregas de atualizações com frequência é o grande erro de muitos empreendedores que acabam perdendo com o DevOps. Efetuando modificações semanais, é possível entregar inovação e valor mais rápido e constantemente aos clientes.

Com isso, o risco de problemas nas implementações é reduzido, porque fica fácil perceber quando houver um erro, já que pouca coisa muda em uma alteração e outra.

Implementar o DevOps exige que o gestor tenha um conjunto de boas práticas que envolvem desenvolvimento de soluções agregadas com aspectos operacionais e de infraestrutura. Ou seja, é uma forma de pensar no desenvolvimento de um software com foco na qualidade do produto e com entrega rápida e eficaz.

Nosso conteúdo foi útil? Aproveite que está por aqui e complemente seus conhecimentos, entendendo como a gestão de software ágil pode ajudar sua empresa. Boa leitura!