Ágil, Scrum e Kanban: O que essas palavras realmente significam?

Quando um desenvolvedor de software ouve notícias sobre uma “nova estrutura JavaScript” ou um “novo IDE”, ele não precisa fazer mais perguntas para esclarecer do que se trata. Mas se ele ouvir falar de uma “nova estrutura ágil”, provavelmente fará o aceno de Homer-Simpson, fingindo que sabe do que se trata, mas terá uma, e apenas uma, pergunta: O que diabos faz “estrutura ágil” quer dizer?

No ambiente moderno de desenvolvimento de software, ouvimos cada vez mais palavras como “ágil”, “scrum” e “kanban”, e muitas vezes são usadas de forma inadequada. Neste artigo, tentarei explicar e esclarecer alguns desses termos.

Ágil

Se você quer ser o espertinho da multidão, deve usar a palavra “ágil” em todas as outras frases quando estiver falando sobre o processo de trabalho. Tem uma abrangência bem ampla, não obriga você a saber muito sobre o assunto que está falando, e é um adjetivo ou advérbio muito bacana: “pensar ágil”, “abordagem ágil”, “segundo princípios ágeis”. Mas o que realmente significa “ágil”?

“Ágil” refere-se ao “desenvolvimento ágil de software”, a abordagem de desenvolvimento que segue os princípios ágeis. Mas o que diabos são “princípios ágeis?” Dê uma olhada no Manifesto Ágil e nos 12 princípios do ágil, que estabelecem as bases do desenvolvimento ágil. Do Manifesto:

Os princípios ágeis incentivam a entrega contínua de software em funcionamento, comunicação próxima entre as equipes e alta adaptabilidade às necessidades em mudança. Se você seguir esses valores e princípios em seu trabalho, pode dizer que está trabalhando em um ambiente ágil. Assim, o desenvolvimento ágil de software não é uma metodologia, é apenas um conjunto de diferentes metodologias, frameworks e técnicas que seguem os mesmos princípios. Pode-se dizer que “ágil” é uma estrutura para pensar e tomar decisões.

Mas por que é tão importante seguir esses princípios em nosso trabalho?

O Manifesto e os princípios são o resultado da busca das melhores soluções que evoluíram ao longo das décadas em resposta aos desafios do desenvolvimento de software. Ao longo dos anos 70, 80 e 90, diferentes desenvolvedores e equipes em todo o mundo experimentaram métodos de trabalho e abordagens para resolução de problemas, inventando diferentes frameworks e técnicas (como Scrum e Extreme Programming) e até chegando ao mesmo ideias em paralelo. Finalmente, em fevereiro de 2001, dezessete desenvolvedores se reuniram e encontraram os denominadores comuns para todas essas diversas idéias e experiências. Foi assim que o manifesto foi criado.

Scrum

Se você fala sobre métodos “ágeis” sem saber o que eles significam, pode escorregar e dizer coisas que vão te revelar na frente do interlocutor que conhece o assunto: “Scrum e outras metodologias ágeis”.

Scrum não é uma metodologia, embora todos nós já tenhamos ouvido isso com mais frequência do que o número de mortes em Game of Thrones . O Scrum não responderá a todas as perguntas e não fornecerá o procedimento preciso para responder a todas as situações que você enfrentar. E provavelmente como resultado dessa interpretação incorreta, a maioria das implementações de scrum também está errada: as equipes não obtêm valor. Isso resulta provavelmente na afirmação mais tola sobre scrum: “Scrum não funciona”.

O que é scrum? O Guia do Scrum define scrum como:

Portanto, é um framework e, como qualquer outro framework, pode ser, e regularmente é, usado de maneira errada. Usar o scrum de forma eficaz requer não apenas a adoção da estrutura definida pelo scrum, mas também um profundo entendimento e apreciação dos princípios ágeis em toda a equipe.

Scrum consiste nos seguintes papéis: Product Owner, Scrum Master, Time de Desenvolvimento.

Há também quatro cerimônias Scrum: Reunião de Planejamento, Daily Scrum, Sprint Review, Sprint Retrospective

E os três artefatos: Product Backlog, Sprint Backlog, Product Increment.

Os projetos Scrum são organizados em prazos regulares, que chamamos de sprints. Geralmente duram duas semanas.

Um Product Owner é responsável por orientar a direção do projeto. À medida que novas tarefas e recursos são determinados, o proprietário do produto os adiciona a um backlog do produto. Um sprint começa com uma reunião de planejamento onde a equipe de desenvolvimento seleciona as tarefas do backlog para trabalhar e planeja como elas serão implementadas. Isso é seguido pelo desenvolvimento, durante o qual a equipe de desenvolvimento usa o backlog para acompanhar o progresso e se reúne para a reunião diária para sincronizar as atividades e ajustar o plano, se necessário. O resultado do desenvolvimento deve ser um incremento de produto, algo que possa ser aplicado ao produto e lançado imediatamente. No final do sprint, o incremento do produto é apresentado ao Product Owner na revisão do sprint, onde o backlog do produto é aumentado se forem necessárias alterações adicionais. Depois, toda a equipe participa da retrospectiva do sprint, onde falam sobre o processo de trabalho e como ele pode ser melhorado.

É fácil aprender e entender o scrum, mas é difícil de adotar. Há muitas razões pelas quais essa estrutura pode ou não ser uma boa opção para um projeto. Muitas vezes, exige muitas mudanças, não apenas no desenvolvimento cotidiano, mas também culturalmente. O Scrum se encaixa melhor no desenvolvimento de produtos complexos, que duram muito tempo e que incluem diferentes tipos de especialistas.

Por que o scrum é tão popular e por que ele tem uma vantagem sobre o modelo tradicional em cascata? Simplificando, porque entrega mais valor a um produto e clientes. Com métodos “pesados” como cascata, abundam as histórias de horror em que ninguém vê nada do projeto por meses. Com scrum, isso não é possível.

Scrum tem tudo a ver com o valor que é entregue aos usuários finais. Se você realmente utiliza o scrum, precisa entregar algo de valor a cada sprint. O valor pode ser medido, e a equipe também é forçada a inspecionar impedimentos e se adaptar, com o objetivo de entregar mais valor na próxima iteração.

Na maior parte do desenvolvimento de software, não estamos construindo um arranha-céu; não precisamos ter todo o plano pronto antes de começar, e manter esse plano até o fim. Estamos desenvolvendo software e temos a capacidade de nos adaptar a diferentes situações e alterar os requisitos do produto durante o desenvolvimento. Por muito tempo, muitos desenvolvedores viram isso como o oitavo pecado mortal, mas do ponto de vista do produto é um grande benefício para otimizar a previsibilidade e controlar o risco. O Scrum é desenvolvido em torno dessa capacidade, e sua implementação oferece uma maneira confiável e eficiente de lidar com as mudanças necessárias.

Muitas técnicas são usadas em conjunto com o scrum: pôquer de planejamento, programação em pares, desenvolvimento orientado a testes (TDD), desenvolvimento orientado a comportamento (BDD) e outros. Eles não são realmente uma parte do scrum, mas sim técnicas compatíveis. Um método frequentemente mencionado ao mesmo tempo que o scrum é o kanban, e há muita confusão sobre o que essas duas coisas significam uma em relação à outra.

Kanban

Quando você fala sobre scrum e kanban, uma pergunta frequente da multidão será: “O que é melhor, scrum ou kanban?” E você não saberá o que responder porque é como comparar maçãs e laranjas, ou perguntar: “O que é melhor, panquecas ou cerveja?” Ambos são melhores.

Kanban é um método simples que visa a entrega just-in-time sem sobrecarregar os membros da equipe. É semelhante ao scrum, pois o objetivo é entregar o máximo valor no final, mas é muito mais flexível que o scrum.

Kanban não foi inventado pela comunidade de desenvolvimento de software. Na verdade, tem sua origem nos processos de fabricação da Toyota, e tem amplo uso em outras esferas. Não há procedimentos estritos que você deva seguir, e nenhuma maneira estrita de implementar e usar o kanban; é, em vez disso, um conjunto de princípios e práticas, e você pode escolher entre essas práticas para atender às suas necessidades. Mas há uma implementação de kanban mais usada no desenvolvimento de software que inclui o uso de um quadro kanban , consistindo de colunas representando estágios de trabalho e tarefas.

As colunas representam o estado de uma tarefa no processo de desenvolvimento. O exemplo mais simples consiste em três colunas: “A Fazer”, “Em Andamento” e “Concluído”. Assim, as tarefas são adicionadas a “A Fazer”, movidas para “Em Andamento” quando o desenvolvimento começa e consideradas “Concluídas” quando movidas para a última coluna. Mas é claro que poderia ser mais complexo:

Backlog → Definindo Especificação → Pronto para Desenvolvimento → Desenvolvimento → Revisão de Código → Teste → Implantado (→ Ninguém realmente o usa → Completamente removido).

Cada coluna pode ter subcolunas; por exemplo, “Desenvolvimento” pode ser dividido em “Planejamento” e “Codificação”; O “teste” pode ser dividido em “teste unitário” e “teste de integração” e assim por diante. As colunas podem ser dedicadas a especialistas, se apropriado. A equipe define as colunas e etapas de acordo com suas necessidades. De acordo com a filosofia de “puxar”, as tarefas só devem entrar no fluxo de trabalho quando a demanda por elas for imediata.

O objetivo deste quadro é visualizar o fluxo de trabalho, que é a primeira prática chave no kanban. Na verdade, o kanban pode ser feito sem um quadro! Pode ser uma simples lista de tarefas em uma planilha do Google com diferentes cores de fundo indicando o estado da tarefa, ou podem ser gráficos de Gantt, diagramas, tabelas… Pode até ser um conjunto de baldes em seu escritório, onde cada um representa o estado da tarefa e onde as bolas são usadas como tarefas. Basta visualizar o fluxo de trabalho e dar transparência a todo o processo.

Outro princípio importante é reduzir o tamanho do lote de seus esforços . Simplificado, isso significa evitar multitarefa. Isso pode significar reduzir o volume de tarefas em que você trabalha ao mesmo tempo. Se você tiver três designers em uma equipe, a equipe pode definir o número máximo de tarefas na coluna "Design" para três.

Assim como o Scrum, o Kanban também vê a equipe como a figura mais importante no processo. Mas ele não sugere funções como o scrum faz, e você pode manter as funções existentes para evitar fazer alterações em seu processo existente. O mesmo significa melhoria contínua: o Kanban geralmente incentiva você a aprender e melhorar continuamente, mas não prescreve um evento específico apenas para esse processo, como a Sprint Retrospective do scrum.

Qual Devo Usar?

Scrum e kanban não são mutuamente exclusivos e não são realmente comparáveis. No scrum, existem funções definidas, enquanto o kanban diz: “Que diabos, mantenha suas funções e responsabilidades atuais”. O Scrum irá forçá-lo a mudar sua forma de trabalhar; Kanban permite que você comece com seu processo existente. No scrum, um cronograma claro para eventos é prescrito pela estrutura; no kanban você não tem eventos. No entanto, eles têm muitas semelhanças: ambos são centrados em valor, os membros da equipe são respeitados como “chefes” do sistema e, essencialmente, têm a mesma missão: eliminar continuamente o desperdício e remover obstáculos.

Mas a pergunta: “O que devo usar em meu projeto específico e com minha equipe específica?” faz muito mais sentido. Kanban não requer tanto processo e mudanças culturais e, na maioria dos casos, será mais fácil de adotar do que scrum. O Scrum, por outro lado, oferece muito mais estrutura para orientar o processo, o que pode eliminar uma grande quantidade de sobrecarga, desde que todos estejam na mesma página.

Mas a beleza de ambos é que nenhum deles é um conjunto estrito de regras. Não há nada que o impeça de escolher os melhores elementos de scrum para você, como uma reunião ou revisão diária. E não há razão para que você não possa incorporar um quadro Kanban no scrum.

Scrum provou ser uma estrutura altamente eficaz quando toda a equipe o entende bem. No entanto, na minha experiência, acho difícil trabalhar em scrum com alguns clientes. O processo e as mudanças culturais necessárias para a implementação adequada do scrum podem ser demais (especialmente quando se trata de alguém que acredita que está criando um novo Google!). Por outro lado, o kanban é mais flexível e não força as pessoas a mudar. Alguns autores também dizem que o kanban é um bom caminho para a agilidade e oferece uma implementação mais fácil do scrum. Outros dizem que usar o scrum deve levar ao kanban no final.

A verdade é que cada projeto é diferente e não existe uma solução única. Como gerente de projeto, cabe a você determinar o que funciona melhor para sua equipe.