Agile da Vida Real

E todo mundo fala de ágil mas você sabe o que é? Eu não vejo mais nenhuma empresa que não trabalhar com a idéia de Agile!

O Agile (Ágil) é uma abordagem (prefiro pensar como mentalidade) de desenvolvimento de software que se baseia em alguns princípios fundamentais estabelecidos no Manifesto Ágil.

Princípios Fundamentais:

1. Indivíduos e interações acima de processos e ferramentas
2. Software funcionando acima de documentação abrangente
3. Colaboração com o cliente acima de negociação contratual
4. Responder a mudanças acima de seguir um plano

Transformação de Mentalidade

O desenvolvimento de software tradicional frequentemente se parece com encomendar um carro sem nunca visitar a fábrica. O cliente faz um pedido inicial detalhado, a equipe de desenvolvimento começa a trabalhar, e três meses depois, quando o cliente vê o produto pela primeira vez, surge aquela frase familiar: "Não era bem isso que eu tinha em mente."

O problema não é só técnico - é um problema de expectativas e visibilidade. O cliente pensa: "Como pode demorar tanto tempo e custar tanto dinheiro?" Enquanto isso, a equipe de desenvolvimento se frustra porque recebeu 47 pedidos de mudança desde o início do projeto, cada um impactando o trabalho já realizado.

É aqui que o Agile entra como solução, não apenas como metodologia, mas como uma transformação na relação cliente-equipe. Imagine agora que, em vez de esperar três meses para ver o produto, o cliente participa de reuniões semanais onde pode ver o software crescendo, como assistir à construção do carro em tempo real.

Em cada reunião, o cliente vê o progresso real: "Olha, implementamos o login que você pediu. Ah, quer mudar a cor dos botões? Okay, mas isso significa que precisaremos adiar a implementação do relatório que estava previsto para esta semana." O cliente passa a entender que cada mudança tem um impacto real no desenvolvimento.

Esta transparência traz três benefícios fundamentais:

1. O cliente vê seu dinheiro se transformando em produto a cada semana, não apenas no final do projeto.
2. As mudanças de requisitos são discutidas e priorizadas em tempo real, com entendimento claro dos impactos.
3. A equipe pode se adaptar rapidamente às necessidades mais importantes do cliente, em vez de seguir cegamente um plano obsoleto.

O Agile não elimina mudanças - ele as torna visíveis e gerenciáveis. Quando o cliente diz "precisamos mudar isso", ele entende que não está apenas mudando uma linha em um documento, mas redirecionando o trabalho de pessoas reais que ele vê toda semana.

Este novo modelo de trabalho transforma a relação de "nós versus eles" em uma verdadeira parceria. O cliente deixa de ser um observador distante que julga apenas o resultado final e se torna parte ativa do processo de desenvolvimento, entendendo que cada decisão sua molda não apenas o produto, mas também o caminho para chegar até ele.

No final, o Agile não é sobre entregar software mais rápido - é sobre entregar o software certo, com total transparência do processo e das decisões que o moldaram. É sobre transformar o desenvolvimento de software de uma caixa preta misteriosa em um processo colaborativo onde todos entendem os desafios, custos e impactos de cada decisão.

Uma frase para refletir... Para a empresa ela deixa de trabalhar com a empreitada e começa a trabalhar com a diária.

Para a Empresa:

• Garante remuneração pelo tempo e expertise dedicados
• Protege-se de mudanças constantes de escopo
• Pode demonstrar de forma clara o trabalho realizado
• Tem flexibilidade para adaptar a equipe conforme necessidade

Para o Cliente:

• Mantém o poder de decisão sobre prioridades levando em consideração os conselhos e as dependências mostradas pela empresa.
• Visualiza o retorno do investimento em ciclos curtos
• Pode ajustar o rumo do projeto mas saberá dos impactos
• Paga pelo valor efetivamente entregue

---

Na prática, o desenvolvimento ágil funciona assim:

• Entregas Incrementais
  • O produto é desenvolvido em pequenos incrementos funcionais
  • Cada incremento entrega valor real ao cliente
  • Ciclos curtos de desenvolvimento (geralmente 1-4 semanas)
• Colaboração Constante
• Equipes auto-organizáveis
• Comunicação diária entre membros do time
• Cliente participa ativamente do desenvolvimento
• Feedback contínuo e adaptação
• Flexibilidade a Mudanças
• Planejamento adaptativo
• Aceitação de que requisitos podem mudar
• Priorização contínua baseada no valor para o negócio

O backlog é a lista de tarefas do que precisa ser feito. Esta em constante atualização e as tarefas vão ganhando prioridades ao longo do tempo.

• Práticas Comuns:

  • Daily Meetings (Reuniões Diárias) são para discutir o que cada um fez ontem e vai fazer hoje. Se tem algo que esta bloqueando a tarefa e o que é necessário fazer para seguir em frente. Essa é uma reunião rápida, só para mostrar ao cliente um pouco de progresso e sincronizar a equipe.
  • Sprint Planning (Reunião de planejamento de um ciclo). Parte das tarefas do backlog serão resolvidas no ciclo proposto.
  • Sprint Review (Revisão do ciclo). Ao final do ciclo é normal fazer uma reunião para discutir tarefas que ficaram pendentes e os motivos.
  • Retrospectivas. As vezes é feito na mesma reunião de review para alinhar as coisas entre a equipe e discutir melhorias melhorias no processo.
  • Backlog Refinement (Refinamento do Backlog). Nem sempre todas as tarefas que estão no backlog são viáveis então descartamos umas, incluimos outras e colocamos prioridades. Geralmente as mais prioritárias vão para para os ciclos.

• Papéis Típicos:

  • Product Owner (Dono do Produto). A pessoa que controla os itens do backlog e prioriza as coisas. Claro que para priorizar as coisas é necessário entender as dependências entre elas. Essa pessoa pode ser o cliente que conversa e com o lider da equipe para dar um direcionamento, mas também pode ser uma pessoa decidada para isso.
  • Team Leader (em equipes Scrum acaba sendo o scrum master). Essa figura costuma ser a pessoa com mais conhecimento na equipe. Pode ser um conhecimento técnico que ajudará a equipe a escolher as ferramentas corretas e o melhor método de fazer as coisas, mas também pode ser conhecer bem o do negócio e entender as prioridades do backlog atuando como um product owner.
  • Time de Desenvolvimento

  Essas posições são bem variadas dependendo do projeto. Já vi projeto que o Tech Leader é o product owner, é o devops, é o arquiteto de cloud e até o desenvolvedor mais experiente. As empresas não tem dinheiro para ficar contratando cada um na sua posição, o negócio é enxugar custos. Pensar no Tech Leader como o cabeça!

• Benefícios:

  • Maior satisfação do cliente
  • Redução de riscos
  • Detecção precoce de problemas
  • Melhor qualidade do produto
  • Maior engajamento da equipe
  • Entregas mais rápidas e frequentes

O Agile não é apenas um conjunto de práticas, mas uma mentalidade que valoriza:

• Adaptação contínua
• Aprendizado constante
• Melhoria iterativa
• Transparência
• Colaboração efetiva

Metodologias

Não vou falar sobre uma metodologia por que isso não faz mais sentido. O Scrum tem muitos rituais, papeis, que na prática não vejo ninguém querendo gastar tanto com isso.

O que frequentemente acontece na prática é uma adaptação do Scrum, onde as equipes mantêm apenas os elementos que agregam valor real ao seu processo. É comum ver equipes mantendo:

Daily meetings (para alinhamento rápido) Sprints (para organização do trabalho) Product Backlog (para priorização)

E simplificando ou eliminando:

• Rituais extensos de planejamento
• Longas retrospectivas formais
• Documentação excessiva
• Regras rígidas de papéis

Esta adaptação é natural e até saudável, desde que mantenha os princípios fundamentais do ágil

Um exemplo prático é uma equipe que reduziu a retrospectiva de 2 horas para um café de 30 minutos onde discutem melhorias de forma mais natural e efetiva.

O importante não é seguir o Scrum à risca, mas sim encontrar o processo que melhor funciona para sua equipe e seu contexto

Abaixo as duas metodologias mais conhecidas.

Scrum Vs Kanban

Vou explicar as principais diferenças entre Scrum e Kanban:

Característica	Scrum	Kanban
Ciclos de Trabalho	Sprints fixas (geralmente 2 semanas)	Fluxo contínuo, sem ciclos definidos
Papéis	Product Owner, Scrum Master, Time Dev	Não define papéis específicos
Rituais	Daily, Planning, Review, Retrospectiva	Não exige rituais específicos
Planejamento	Compromisso com entregas da Sprint	Planejamento contínuo e flexível
Métricas	Velocidade da equipe, Burndown	Lead time, Tempo de ciclo
Limitação de Trabalho	Baseado na capacidade da Sprint	WIP Limits (limite de trabalho em progresso)
Alterações no Ciclo	Idealmente não muda durante a Sprint	Permite mudanças a qualquer momento
Quadro	Limpo a cada Sprint	Contínuo, sem reset
Estimativas	Story Points, Planning Poker	Opcional, foco no tamanho dos itens
Priorização	Product Backlog ordenado	Visual por colunas e swimlanes
Recomendado para	Projetos com alguma previsibilidade	Serviços contínuos (manutenção, suporte)
Entregas	Ao final de cada Sprint	Contínuas, conforme conclusão
Reuniões	Cerimônias fixas e timeboxed	Sob demanda
Visual do Processo	Colunas da Sprint	Fluxo do trabalho completo
Documentação	Product/Sprint Backlog, Incremento	Políticas explícitas do quadro

Vejo que no final as empresas usam o Scrumban, uma abordagem híbrida que pega um pouco de cada metodologia. Chamo isso de "O Scrumban da Vida Real".

A Daily é mantida diariamente e rápida.

Alguns rituais do Scrum (Daily, Planning, Review e Retro) são mantidos, assim como a ideia do backlog. No entanto, este último fica disponível em uma coluna do quadro Kanban, com as prioridades definidas pela ordenação dos cards (que são as tarefas).

O conceito de Sprint se transforma em um ciclo de reuniões para Planning e Review que, na prática, acontecem juntas, geralmente a cada duas semanas, porém o fluxo de trabalho permanece contínuo.

Enfatiza-se o conceito de Épico, que representa a meta ou objetivo com tempo determinado - geralmente 2 ou 3 meses - variando de acordo com o que precisa ser implementado.

O processo se torna mais equilibrado, evitando tanto o micro gerenciamento imposto pelo Scrum quanto a flexibilidade excessiva do Kanban, encontrando assim um meio-termo pragmático.

Priorização do Backlog

Vou explicar o conceito de priorização L1, L2, L3 e L4, L5 e L6 no contexto ágil de forma clara.

No contexto ágil, os níveis L1 a L4 são uma forma de categorizar a prioridade e severidade de diferentes itens (como bugs, incidentes ou tarefas). Geralmente, uma tarefa vem com a sua prioridade definida para saber o que devemos pegar ou não primeiro para fazer.

L1 (Prioridade Crítica)

• Impacto severo que afeta funções críticas do negócio
• Requer ação imediata, geralmente em questão de horas

Exemplo: Sistema completamente fora do ar, impossibilitando operações essenciais Geralmente envolve mobilização da equipe mesmo fora do horário comercial

L2 (Prioridade Alta)

• Impacto significativo, mas sem paralisar completamente as operações
• Necessita resolução rápida, tipicamente dentro de 24-48 horas

Exemplo: Funcionalidade importante com defeito, mas existe um contorno temporário Equipe prioriza essa atividade podendo reorganizar outras tarefas.

Aqui esta um dos motivos que não dá para aplicar o Full scrum, pois sempre acontecem problemas que interferem na sprint!

L3 (Prioridade Média)

• Impacto moderado nas operações
• Pode ser resolvido dentro de uma semana ou na próxima sprint

Exemplo: Bug em função não crítica ou melhorias importantes mas não urgentes É planejado normalmente no backlog da próxima sprint e geralmente fura a fila!

L4 (Prioridade Baixa)

• Impacto mínimo no negócio
• Pode aguardar algumas sprints para ser resolvido

Exemplo: Melhorias cosméticas ou otimizações menores Entra no backlog normal do produto para priorização futura

L5 (Prioridade Muito Baixa)

• Melhorias cosméticas não urgentes
• Otimizações menores que não afetam a experiência do usuário
• Tarefas que podem esperar meses para serem implementadas
• Ideias para futuras versões do produto

Exemplo: Mudança na cor de um ícone não crítico, reformatação de código que já funciona

L6 (Prioridade Mínima)

• Desejos ou "nice to have"
• Itens do backlog que podem nunca ser implementados
• Ideias para serem consideradas em um futuro distante

Exemplo: Refatoração de código que já funciona bem, mudanças puramente estéticas

---

Na maioria das organizações, itens classificados como L5 ou L6 frequentemente acabam sendo:

• Removidos do backlog após um tempo
• Reclassificados para uma prioridade maior se ganharem importância
• Mantidos apenas como referência para futuras discussões

Por isso, a maioria das empresas trabalha apenas com a escala L1 a L4, que já é suficiente para categorizar adequadamente as prioridades dos itens de trabalho.