10 Referências Ágeis: Se apoie em ombros de gigantes

Ainda estou longe de onde quero chegar, ta certo, já tive algumas conquistas, mas ainda tenho muito que aprender e me espelhar, com os que chamo de referências ágeis.

E me lembro, quando estava começando com Métodos Ágeis lá em 2007, era muito difícil encontrar informação boa, sobre o que era novo até então no Brasil. E hoje, nós temos o contrário, agora é muita informação que até ficamos perdidos.

Mas como acredito que todo conhecimento deve ser compartilhado, resolvi fazer aqui a lista dos 10 referências ágeis (acredito que essa seja a melhor definição) que eu sigo e que recomendo a vocês seguirem também.

Referências Ágeis, que você deve seguir para ontem!

Annelise Gripp

Especialista em Transformação Ágil, Consultora em Processo, Projetos,Instrutora,Auditora e Coach.

Tem um blog, onde compartilha sua experiência através de muita conteúdo de qualidade sobre métodos ágeis e coach.

Artigo: Você sabe a diferença entre Coaching e Mentoring

Marcelo L. Barros

Agile Coach e colunista do Agile Momentum.

Marcelo é Agile Coach e fundador do Agile Momentum, costuma trazer em seus artigos muita reflexão, sobre cultura organizacional e como ela influencia no dia-a-dia das pessoas.

Artigo: Empresa rasa só serve para encalhar barcos

Agile.Pub

Excelente blog sobre os Métodos Ágeis e Gestão.

Possui muito conteúdo de qualidade, que com certeza irão te ajudar no dia-a-dia. Além de ser um blog bem leve, com clima de Happy Hour.

Artigo: Cliente como PO – Pode isso?

Fabio Cruz

Agile Coach, Agile Enterprise, Consultor e Trainer Especialista em Gestão Ágil, Palestrante e autor de livros.

Muita experiência em jogo com o Fábio Cruz, todo conteúdo gerado é certeza de valor agregado.

Artigo: Product Owner e a sua Startup

[epico_capture_sc id=”348″]

Rodrigo Yoshima

Entrepreneur, Owner & Lean / Agile Specialist at Aspercom. Lean-Kanban University Trainer and Coach

Acredito que seja a maior referência que temos de Kanban no Brasil. Tem muita experiência e sempre está conectado e trazendo novidades que ainda nem vimos por aqui.

Artigo: Série: Complexidade e Agilidade (4 artigos)

Alexandre Magno

Founder Learning30co. Author of “How Creative Workers Learn”, the first Learning 3.0 book. Now writing “How Creative Teams Learn”

Não tenho certeza, mas acredito que seja um dos responsáveis por trazer o Scrum de maneira consistente para o Brasil. Apensar de não estar escrevendo em blogs atualmente é um excelente referência no que diz a respeito de Agilidade e Aprendizado.

Artigo: PO dentro do Taxi

André Faria

CEO at Bluesoft.

O foco principal de seu trabalho é no desenvolvimento de negócios, atuando também na liderança de equipes de produto e engenharia de software, no coaching de métodos ágeis, e no desenvolvimento de produtos para a Internet.

Artigo: Práticas Ágeis: A grande lista completa

Daniel Wildt

Mentor @ Wildtech, Blogger/Youtuber @ danielwildt.com, CTO @ uMov.me

Um dos pioneiros em métodos ágeis no Brasil e com isso também uns dos que mais tem experiência para compartilhar.

Artigo: OKRs – Objetivos e Resultados Chave

Samuel Crescêncio

Criador da Pirâmide Lean, engenheiro de software, empreendedor, trainer e coach em lean, software engineering e agile.

Muito conteúdo sobre Lean e Métodos Ágeis. Samuel tem muita experiência. Foi um dos fundadores do Agile Brazil.

Artigo: Autonomia – Como obtê-lá

 Paulo Caroli

Digital Transformation & Innovation Adept, Lean & Agile Expert, Father, Author, Speaker, Blogger. Principal Consultant at Thoughtworks.

Tem mais de vinte anos de experiência em desenvolvimento de software, passando em várias empresas no Brasil, Índia, EUA e América Latina. Em 2000, conheceu o Extreme Programming e, desde então, concentrou sua expertise em processos e práticas da Agile & Lean.

Artigo: Vamos parar de usar o termo errado! Escalando, aprofundando e expandindo o ágil

É muito provável que outros grandes nomes tenham ficado de fora dessa minha lista.

Aprender com quem já “chegou lá” e continuar compartilhando conhecimento é um ciclo de progressão e aprendizado.

Se você conhece alguém que deveria estar na nessa lista, por favor, compartilhe conosco nos comentários.

Já curtiu nossa página no Facebook? Curta agora, lá temos muito conteúdo de qualidade.

[epico_capture_sc id=”348″]

Métodos Ágeis: O que são e por que você deve conhecer

Métodos ágeis são abordagens de gestão de projetos e desenvolvimento de produtos baseadas em ciclos curtos, entrega incremental e adaptação constante — ao contrário do modelo tradicional, que divide o trabalho em etapas fixas definidas no início do projeto.

O que são

Abordagens iterativas e incrementais para desenvolver produtos, com entregas curtas e revisáveis.

Origem

O termo nasceu no Manifesto Ágil, em 2001, com influência do Lean/Toyota e de artigos sobre desenvolvimento iterativo de produtos.

Principais métodos

Scrum, Kanban, XP, FDD e Lean Startup são os mais utilizados hoje.

Cuidado

Ter menos documentação formal não significa abandonar disciplina, processo ou responsabilidade.

O que são Métodos Ágeis?

Os métodos ágeis são uma alternativa ao modelo tradicional de gestão de projetos, que divide o desenvolvimento em etapas rígidas e sequenciais, definidas por completo antes de começar. Em vez disso, os métodos ágeis trabalham com iterações curtas, em que o resultado é medido por produto pronto e utilizável ao final de cada ciclo.

O modelo de entrega ágil é baseado em ciclos iterativos e incrementais, o que traz flexibilidade e adaptabilidade ao processo. Uma característica central é a inspeção e adaptação constantes a cada ciclo, com foco em gerar melhoria contínua para equipes e processos.

Existe uma ideia equivocada de que métodos ágeis são contra documentação e processo formal. Na prática, eles priorizam o que realmente agrega valor ao resultado – documentação continua existindo quando é útil, só deixa de ser um objetivo em si.

Ambientes ágeis costumam ser formados por equipes com autonomia, capazes de se auto-organizar em busca de objetivos e metas claros. Hoje, práticas e abordagens ágeis são utilizadas em diferentes setores e contextos, especialmente onde adaptação, aprendizado rápido e entregas frequentes são importantes.

De onde vieram os Métodos Ágeis?

Depois da Segunda Guerra Mundial, a Toyota criou o TPS (Toyota Production System), também conhecido como Lean Manufacturing: um sistema de produção enxuto, focado na redução de custos através da redução de desperdícios.

Muita gente associa a origem dos métodos ágeis diretamente à Toyota e ao Lean. Outros associam ao artigo The New New Product Development Game, de Hirotaka Takeuchi e Ikujiro Nonaka, que descreve características de produção iterativa. Esse “link” existe pela semelhança de conceitos – mas o termo método ágil, como usamos hoje, surgiu mesmo durante a formação do Manifesto Ágil, em 2001.

O Manifesto Ágil

Em 2001, um grupo de 17 pessoas se reuniu para discutir uma nova abordagem para a gestão de projetos de software. Ao final do encontro, todos assinaram o que ficou conhecido como Manifesto Ágil, composto por quatro valores centrais.

Desde então, os métodos ágeis seguem esses valores por completo: mesmo quando há valor nos itens à direita de cada comparação do manifesto, os itens à esquerda continuam sendo os mais importantes.

Tipos de Métodos Ágeis

Scrum e Kanban concentram boa parte da adoção global de métodos ágeis, mas existem outros métodos, cada um com uma forma própria de abordar a agilidade. Abaixo, um resumo dos métodos mais utilizados ou conhecidos.

Scrum

Scrum é um framework leve para lidar com problemas complexos por meio de ciclos curtos de inspeção, adaptação e entrega incremental. Veja o guia completo de Scrum para entender como aplicá-lo na prática.

Kanban

Kanban não é apenas um quadro na parede – é um método de gestão focado em fluxo de valor. No Kanban, a evolução do processo é constante, graças à visibilidade dos problemas que o método traz à tona.

XP (Extreme Programming)

Metodologia ágil com valores centrais de comunicação, simplicidade, feedback, coragem e respeito. É uma excelente abordagem para equipes pequenas com mudanças constantes de escopo – e nasceu antes do próprio Manifesto Ágil.

FDD (Feature Driven Development)

Metodologia ágil guiada pelo desenvolvimento de funcionalidades, com duas fases centrais: concepção e construção. É um método bastante enxuto.

Lean Startup

Nascido dentro dos conceitos de startup, o Lean Startup é hoje usado em qualquer contexto de desenvolvimento de produto. É fortemente indicado para validação de ideias e hipóteses, através de três passos: Construir, Medir e Aprender.

Erros comuns sobre Métodos Ágeis

• Achar que métodos ágeis significam não ter documentação nem processo.
• Confundir “métodos ágeis” com “Scrum” como se fossem sinônimos.
• Achar que Kanban é só um quadro de tarefas, sem entender o fluxo de valor por trás.
• Adotar um método ágil sem adaptar ao contexto real do time.
• Tratar a melhoria contínua como opcional, em vez de parte central do método.

Perguntas frequentes sobre Métodos Ágeis

Engajamento de Equipes: Como criar times produtivos

Engajamento de equipes nasce do equilíbrio entre o desafio proposto e a competência do time: quando esse equilíbrio existe, o time produz resultado, e o engajamento aparece como consequência — não o contrário.

O que gera engajamento

Resultado, que vem da competência certa aplicada ao desafio correto.

Sinal de desequilíbrio

Desmotivação, falta de foco e uma união do time que surge do sofrimento em comum, não da realização.

Como medir

Mapear o conhecimento técnico e de negócio do time contra o tamanho real do desafio.

Cuidado

Uma “união forte” do time nem sempre é sinal positivo – pode ser sintoma de um time sofrendo junto, não de um time engajado.

O ciclo da satisfação e do engajamento

A relação entre satisfação no trabalho e engajamento é real e comprovada: pessoas com um alto grau de satisfação têm maior engajamento e, com isso, são mais produtivas. Um time engajado produz melhor, gera um cliente mais satisfeito, e cliente satisfeito se torna cliente leal – o que traz maior lucratividade e crescimento para a organização.

O que faz um time se sentir engajado com o que faz? A resposta central é resultado: um time que gera resultados consistentes se sente realizado, e esse é o combustível do engajamento. Resultado, por sua vez, é consequência de o time ter a competência certa para o desafio correto.

O equilíbrio entre desafio e competência

Toda atividade de trabalho pode ser desafiadora demais, fácil demais, ou estar no ponto certo. Medir a relação entre o desafio proposto e a competência disponível no time é uma ferramenta valiosa para construir times engajados – a pergunta importante é: como perceber quando esse equilíbrio está quebrado?

Sinais de um time sobrecarregado

Times enfrentando desafios maiores do que sua competência atual costumam apresentar três sinais: desmotivação, falta de foco e, de forma menos intuitiva, uma união forte entre os membros. A desmotivação surge da falta de resultado – o time passa a desacreditar das próprias competências. A falta de foco é consequência direta disso. E a união forte nasce do sofrimento em comum: como uma tribo, o time se une diante de uma dificuldade compartilhada – um comportamento natural, mas que é sintoma de desequilíbrio entre desafio e competência, não de um time saudável.

Como equilibrar a balança

Equilibrar a balança começa por entender onde está a principal dor do time – geralmente em um de dois lugares:

• Conhecimento técnico do time
• Conhecimento de negócio

Fazer um mapa de conhecimento com o time ajuda a identificar as virtudes técnicas e de negócio já existentes – e onde estão os gaps. Quando o gap é técnico, a prioridade é investir em treinamentos, workshops e dojos: isso traz conhecimento e, ao mesmo tempo, motivação, porque as pessoas se sentem valorizadas. Quando o time já tem conhecimento técnico acima do desafio atual, o problema é outro – falta de desafio real -, e a saída é fomentar inovação dentro do próprio projeto, com o time sugerindo onde evoluir. Quando o gap é de negócio, pequenas palestras internas sobre o contexto do projeto ajudam – e envolver o Product Owner ou o cliente nesse processo gera sinergia adicional.

Erros comuns sobre engajamento de equipes

• Interpretar uma equipe “muito unida” como sinal automático de engajamento, sem investigar a causa dessa união.
• Tentar motivar o time sem antes medir se o desafio proposto está equilibrado com a competência real.
• Investir em treinamento técnico quando o gap real é de conhecimento de negócio (ou vice-versa).
• Ignorar sinais de desmotivação e falta de foco até que o problema se torne crítico.
• Tratar engajamento como responsabilidade só da liderança, sem envolver o próprio time no diagnóstico.

Perguntas frequentes sobre engajamento de equipes

Eficiência e Eficácia: Como conseguir o equilíbrio perfeito

Eficiência é fazer mais em menos tempo; eficácia é fazer exatamente o que o cliente precisa. Não é preciso escolher uma: o Manifesto Ágil, através dos seus 4 valores, já é a materialização do equilíbrio entre as duas.

Eficiência

Produzir mais, em menos tempo – o foco do século XX, impulsionado pelas guerras mundiais e pelo crescimento populacional.

Eficácia

Fazer exatamente o que resolve a dor do cliente – o foco da Era da Informação, onde o produto certo nem sempre é óbvio de antemão.

Como se relacionam

Os 4 valores do Manifesto Ágil equilibram diretamente eficiência (lado direito de cada valor) e eficácia (lado esquerdo).

Cuidado

Eficácia sem eficiência não sobra tempo para experimentar; eficiência sem eficácia só acelera a entrega da coisa errada.

De onde vem a eficiência?

O século XX pode ser chamado de “o século da eficiência”. Dois fatores contribuíram diretamente para isso: a Segunda Guerra Mundial e o crescimento populacional. Quem venceu a guerra foi quem teve o maior poder de produção – mais armas, aviões e tanques, em menos tempo. Isso é eficiência: produzir mais, em menos tempo.

O crescimento populacional reforçou essa pressão: durante o século XX, a população mundial triplicou, de 2 para 6 bilhões de pessoas, obrigando as indústrias a produzir de forma cada vez mais eficiente para atender a demanda. Uma caneta que levava dias para ser produzida passou a levar menos de uma hora – o produto não mudou, a eficiência do processo é que mudou.

E a eficácia? Por que devemos ser eficazes?

Se o século XX foi o século da eficiência, o século XXI pode ser chamado de século da eficácia – vivemos a Era da Informação, onde a informação está em todo lugar e muda a cada instante. Quando essa informação se combina com a experiência das pessoas – os trabalhadores do conhecimento -, ela gera inovação. E essa transformação constante é o que torna o mercado atual tão imprevisível: empresas quebram e surgem rapidamente, mesmo sendo extremamente eficientes.

A diferença está no tipo de produto: quando o produto já é conhecido (como uma caneta), otimizar o processo é relativamente simples – isso é eficiência. Quando o produto é novo (como um app), o “como fazer” não é óbvio, e o próprio usuário pode não gostar do resultado mesmo que ele seja bem executado. Ser eficaz é acertar exatamente o que o cliente precisa – e a única forma confiável de descobrir isso é experimentando, validando e adaptando: errar rápido, para acertar mais rápido.

Isso não significa abandonar a eficiência – pelo contrário: só existe tempo para experimentar quando o processo por trás dos experimentos é eficiente. Fazer a melhor coisa possível (eficácia) no menor tempo possível (eficiência) é o equilíbrio que o mercado atual exige.

Como o Manifesto Ágil equilibra os dois

O Manifesto Ágil é pautado em 4 valores. Nenhum deles menciona literalmente “eficiência” ou “eficácia” – mas em cada um, o lado direito da comparação favorece eficiência, e o lado esquerdo favorece eficácia.

Erros comuns sobre eficiência e eficácia

• Tratar eficiência e eficácia como conceitos concorrentes, em vez de complementares.
• Otimizar um processo (eficiência) antes de validar se está entregando a coisa certa (eficácia).
• Achar que mais experimentação sempre exige mais tempo – sem eficiência, não há tempo para experimentar de verdade.
• Aplicar a lógica de produtos já conhecidos (otimizar processo) a produtos novos, onde o “como fazer” ainda não está definido.
• Não relacionar os 4 valores do Manifesto Ágil a essa balança, tratando-os como regras isoladas.

Perguntas frequentes sobre eficiência e eficácia

Os métodos ágeis são, hoje, as ferramentas mais indicadas para equilibrar eficiência e eficácia de forma prática no dia a dia de um time.

Valores do Scrum: Coragem, Foco, Comprometimento, Respeito e Abertura

Os valores do Scrum são Coragem, Foco, Comprometimento, Respeito e Abertura. Eles sustentam os 3 pilares do Scrum (Transparência, Inspeção e Adaptação) e não são impostos ao time – são absorvidos na prática, à medida que ritos, artefatos e papéis são usados no dia a dia.

Coragem

Fazer a coisa certa e assumir responsabilidade, mesmo em problemas difíceis.

Foco

Concentrar-se no trabalho da Sprint e nos objetivos do Time Scrum.

Comprometimento

Comprometer-se pessoalmente com os objetivos do time, não só com o resultado individual.

Respeito

Reconhecer os demais membros do time como pessoas capazes e independentes.

Abertura

Estar aberto ao trabalho, aos desafios e às mudanças que surgem no caminho.

Os valores do Scrum

Em meados de 2016, o Scrum Guide foi atualizado e passou a incluir formalmente 5 valores: Coragem, Foco, Comprometimento, Respeito e Abertura. Segundo Ken Schwaber e Jeff Sutherland, criadores do Scrum, são esses valores que dão vida aos 3 pilares do framework: Transparência, Inspeção e Adaptação.

Coragem

O Scrum Team precisa de coragem para fazer a coisa certa e trabalhar em problemas difíceis – assumindo a responsabilidade quando algo não vai bem ou quando uma solução definida não funcionou. Também é preciso coragem para fazer o melhor trabalho possível mesmo sob pressão: muitas vezes o time é pressionado a entregar algo em que não acredita, e expor o próprio ponto de vista é parte do valor.

Foco

Manter o foco na entrega e no objetivo da Sprint parece óbvio, mas é comum o time entrar na Sprint sem uma meta clara a cumprir – um dos mitos mais populares do Scrum é achar que o time precisa entregar tudo que está no Sprint Backlog, sem relação com um objetivo real. Foco também significa buscar melhoria contínua todos os dias, não só cumprir a meta da Sprint.

Comprometimento

Comprometimento talvez seja o valor mais exigente do Scrum: seguir os ritos, aplicar as práticas e gerar valor real demandam comprometimento com o resultado – mas não só com o resultado. O comprometimento no Scrum também tem um sentido de cooperação: os membros do time se comprometem uns com os outros, prontos para enfrentar qualquer desafio que apareça junto.

Respeito

Respeito é o valor que determina se o time terá ou não unidade. O Scrum Guide pede que os membros do time se respeitem como pessoas capazes e independentes – inclusive respeitando as dificuldades de cada um, o que ajuda na evolução de todos. Choques de ideias são inevitáveis em qualquer time; saber respeitar opiniões diferentes é parte do convívio diário.

Abertura

O Time Scrum e seus stakeholders concordam em estar abertos a todo o trabalho e aos desafios da execução. Abertura também significa aceitar mudanças: é comum o cliente mudar de ideia ao longo do caminho, e o time precisa estar preparado para os impactos que isso gera – ouvindo novas ideias e mudanças sem resistência automática.

Erros comuns com os valores do Scrum

• Empurrar os valores para o time como regra imposta, em vez de deixá-los emergir da prática diária dos ritos e artefatos.
• Confundir foco com “entregar tudo que está no Sprint Backlog” – o foco real está no objetivo da Sprint, não numa lista fechada de itens.
• Entender comprometimento apenas como meta individual, esquecendo o sentido de cooperação com o resto do time.
• Tratar choques de ideias como falta de respeito, em vez de reconhecê-los como parte normal da convivência do time.
• Resistir a mudanças vindas do cliente em vez de tratá-las como parte esperada do trabalho (valor da abertura).

Como aplicar os valores do Scrum no dia a dia

Os valores do Scrum excedem a execução técnica do time – são eles que dão vida ao trabalho em equipe e, em última análise, ao próprio Scrum. Uma prática simples e eficaz é usar a Retrospectiva para classificar, junto com o time, pontos positivos e negativos da Sprint à luz de cada um dos 5 valores. Repetida ao longo do tempo, essa prática aproxima o time cada vez mais dos valores – sem que eles precisem ser impostos.

Perguntas frequentes sobre os valores do Scrum

Histórias de Usuário: 8 dicas para escrever boas user stories

Uma boa história de usuário foca no cliente final, representa valor de negócio real, é informal (não substitui documentação) e segue o modelo INVEST (Independente, Negociável, Valiosa, Estimável, Pequena e Testável). Usada em qualquer Método Ágil – Scrum, Kanban, XP ou Lean Startup – ela nasceu no XP, no final da década de 80.

História de usuário

Representação informal do desejo de um usuário por uma funcionalidade – não um documento de requisitos.

Épico

Uma história de usuário grande demais, que ainda precisa ser quebrada em histórias menores.

Persona

Personagem que representa as características do seu cliente ou usuário real, usado quando você ainda não o conhece bem.

INVEST

Checklist de qualidade de uma história de usuário: Independente, Negociável, Valiosa, Estimável, Pequena e Testável.

De onde vieram as histórias de usuário?

Histórias de usuário surgiram no XP (Extreme Programming), no final da década de 80, com o objetivo de representar o desejo do usuário por alguma funcionalidade de forma fácil de priorizar. Assim como outras técnicas do XP – TDD e Pair Programming – as user stories se difundiram e hoje são usadas em praticamente qualquer Método Ágil, independente de ser Kanban, Scrum, XP ou Lean Startup.

8 dicas para escrever boas histórias de usuário

1. Foco no cliente ou usuário final

O foco de uma história de usuário deve estar sempre no que o cliente ou usuário final realmente deseja – não no que você acredita que ele deseja. Sem esse foco, as chances são de escrever user stories sem valor real para o produto.

2. Utilize personas

Quando você não conhece bem o seu cliente ou usuário final, criar personas – personagens com as características do seu usuário real – ajuda a levantar os desejos por trás das histórias. É comum um produto ter mais de uma persona; combinar personas com story mapping facilita ainda mais esse trabalho.

3. Histórias de usuário são informais

User stories não substituem a documentação do projeto. Elas servem apenas para representar os desejos de clientes e usuários – mantenha-as como conversas informais, que vão mudar algumas vezes ao longo do caminho.

4. Devem representar valor de negócio

Mesmo sendo informal, toda história de usuário precisa ter um motivo claro para existir. É comum encontrar user stories sem o “porquê” preenchido – deixe o valor de negócio explícito.

5. Siga o modelo INVEST

Segundo Mike Cohn, uma user story só é válida se seguir o modelo INVEST:

6. Comece pelas grandes e termine nas pequenas

Comece identificando os Épicos – histórias grandes demais para serem implementadas de uma vez. Por exemplo: “Como usuário, gostaria de pagar minha compra para receber os produtos” é um Épico, porque dentro dele existem várias decisões (forma de pagamento, parcelamento, etc.) que geram histórias menores. Partir dos épicos é uma boa forma de descobrir as histórias de usuário menores.

7. Mantenha as histórias de usuário visíveis

User stories existem para promover colaboração e conversa – não as deixe escondidas numa planilha. Uma técnica útil é o Story Board, um quadro com 3 colunas: Ideias (novas ideias do PO), Validação de Valor (histórias em validação de valor de negócio) e Priorizadas para o Product Backlog (histórias com valor de negócio já identificado).

8. Não confie apenas nas histórias

Como são informais, user stories não devem ser a única fonte de informação. Complemente com o que for necessário – um diagrama de sequência, um template de jornada do usuário ou um protótipo – sempre que isso agregar valor real para o time de desenvolvimento.

Erros comuns ao escrever histórias de usuário

• Escrever a história com base no que você acha que o cliente quer, em vez de validar com o cliente real.
• Tratar a história de usuário como documentação completa, em vez de um ponto de partida para conversa.
• Deixar o “porquê” (valor de negócio) vazio na história.
• Escrever histórias grandes demais (épicos) sem quebrá-las em histórias menores e testáveis.
• Manter as histórias escondidas numa ferramenta sem visibilidade para o time.

Perguntas frequentes sobre histórias de usuário

As 10 principais características do Desenvolvimento Ágil

As 10 principais características do desenvolvimento ágil são: envolvimento real do usuário final, time empoderado, entregas frequentes, foco (uma peça de cada vez), simplicidade, qualidade constante, melhoria contínua, uso de métricas, automação e colaboração entre time e stakeholders. A ordem importa: elas constroem um mindset ágil, não apenas um processo ou ferramenta.

O crescimento dos métodos ágeis é uma realidade – o mercado ficou mais dinâmico e exige agilidade das organizações. Mas esse crescimento rápido tem um efeito colateral: muitas empresas adotam o ágil como processo ou ferramenta, sem incorporar o mindset ágil por trás dos valores e princípios. As 10 características a seguir ajudam a reconhecer se o mindset está realmente presente no dia a dia do time.

1. Envolvimento real do usuário final

Em qualquer método ágil – Scrum, Kanban ou Lean Startup – o usuário final precisa estar envolvido, afinal é para ele que o time trabalha. Como ter o usuário presente no dia a dia é quase impossível, um representante fiel, com autonomia e conhecimento real do mercado e das necessidades dos usuários, é necessário.

2. Time de desenvolvimento empoderado

Um time ágil precisa de condições e conhecimento para superar os desafios que surgem – e isso só acontece com empoderamento real. O time deve poder tomar suas próprias decisões, e essas decisões devem ser respeitadas: se o time estimou, confie; se definiu a solução técnica, confie. O time é o coração de qualquer método ágil – é ele quem aprende e evolui continuamente através dos próprios erros. Cada interferência de gestão tira o foco do time; o papel da liderança é dar um objetivo claro e a capacidade de chegar lá, não ditar o caminho.

3. Entregue pouco, mas entregue sempre

Como se come um elefante? Pedaço a pedaço. Entregas frequentes são vitais para o sucesso de qualquer projeto ou produto, porque geram feedback real – e é o feedback que permite correções assertivas de rota. Entregar com frequência não significa estocar software pronto para homologação: significa colocar o que foi feito nas mãos do usuário final para ele experimentar. Minimizar o tempo que algo fica em desenvolvimento, com releases pequenas (mas não pequenas demais), é o caminho prático para isso.

4. Uma peça de cada vez

Foco é uma característica central do desenvolvimento ágil – e deve ser uma característica do time também: tudo que começa deve ser terminado antes que outra atividade comece, incluindo as atividades da Sprint. “Comece a terminar e pare de começar” é o resumo prático disso: progresso em métodos ágeis é software pronto, não trabalho espalhado. Reduzir o número de atividades em progresso simultâneas é um comportamento raro, mas é o que diferencia um time de um grupo de pessoas trabalhando em paralelo nos mesmos itens.

5. Seja simples

O Princípio de Pareto afirma que, para muitos eventos, 80% dos efeitos vêm de 20% das causas – no desenvolvimento ágil, 80% do valor entregue costuma vir de 20% do esforço. Um exemplo prático: um cliente pediu uma funcionalidade de busca por estado, e a primeira história levantada foi “Cadastro e Edição de Estados” – um CRUD completo para algo que praticamente nunca muda. A solução simples (uma tabela fixa no banco, ou até um JSON) entregava o mesmo valor com uma fração do esforço. Buscar soluções simples – em vez de soluções mirabolantes – é o que realmente impulsiona os resultados.

6. Tenha qualidade no que faz

“Teste cedo e sempre” deveria ser o lema de qualquer time ágil – sem qualidade constante, o time não sobrevive por muito tempo. Isso é cultura da qualidade: pensar em qualidade o tempo todo, seja ao escrever código, ao escrever uma história de usuário ou ao desenvolver um teste. Garantir qualidade sempre – e o “sempre” aqui é literal.

7. Melhore continuamente e sempre

Melhoria contínua é fazer hoje melhor do que ontem – mesmo que ontem já tenha sido um bom dia. É sobre inquietação: estar sempre buscando oportunidades de melhoria, em vez de se acomodar depois de um sucesso. Times que caem de rendimento depois de alcançar o sucesso normalmente pararam de evoluir; times ágeis fazem o oposto – nunca estão 100% satisfeitos.

8. Viva com métricas

Inspeção é um dos pilares do Scrum, mas vale para qualquer método ágil – e métricas são o que tornam a inspeção possível. O importante é ter métricas que agreguem valor real ao processo e ao time, não métricas de vaidade. Um time sem métricas é como um carro sem farol numa estrada à noite: pode até chegar ao destino, mas vai encontrar muito mais buracos pelo caminho.

9. Automatize as coisas chatas

É nas tarefas mais simples e repetitivas que acontecem os maiores problemas – por isso, automatizar tudo que for razoável (incluindo testes de regressão) é essencial. Seguindo um pouco a linha do Management 3.0, de Jurgen Appelo: tarefas chatas e repetitivas desmotivam o time mais cedo ou mais tarde. Ter cultura de automação – e de DevOps – é o que evita esse desgaste.

10. Colaboração entre time e stakeholders

“Colaboração com o cliente mais que negociação de contrato” – um dos 4 valores do Manifesto Ágil já resume essa característica. A colaboração entre time e stakeholders precisa ser natural e constante, porque em métodos ágeis os requisitos são leves por natureza, e é a colaboração contínua que sustenta a aceitação de mudanças. Sem requisitos leves e sem colaboração real, o risco é cair em documentação extensa, onde qualquer mudança de escopo vira um problema em vez de um resultado natural do processo.

Erros comuns ao adotar o desenvolvimento ágil

• Adotar o ágil como processo ou ferramenta, sem incorporar o mindset ágil por trás dele.
• Deixar o time sem empoderamento real, com gestores interferindo nas decisões técnicas ou de estimativa.
• Confundir “entregar com frequência” com acumular software pronto esperando homologação.
• Trabalhar várias atividades em paralelo em vez de focar em terminar uma de cada vez.
• Criar soluções complexas quando uma solução simples entregaria o mesmo valor com uma fração do esforço.
• Medir por métricas de vaidade, em vez de métricas que realmente ajudam o time a decidir.

Perguntas frequentes sobre as características do desenvolvimento ágil

Estágios da Competência: os 4 níveis de qualquer aprendizado

Os 4 estágios da competência (Incompetência Inconsciente, Incompetência Consciente, Competência Consciente e Competência Inconsciente) descrevem como qualquer pessoa ou organização aprende uma nova habilidade – inclusive a adoção de Métodos Ágeis. A teoria foi desenvolvida por Noel Burch nos anos 70, embora seja frequentemente (e erroneamente) atribuída a Abraham Maslow.

1. Incompetência Inconsciente

Não sabemos o que não sabemos – ainda não reconhecemos a habilidade como necessária.

2. Incompetência Consciente

Sabemos o que não sabemos – começamos a praticar e errar; estágio mais difícil, onde mais se desiste.

3. Competência Consciente

Executamos a habilidade, mas ainda de forma mecânica e com muita atenção.

4. Competência Inconsciente

Fazemos sem perceber – a habilidade já foi praticada tantas vezes que vira natural.

O que são os 4 estágios da competência

Inicialmente descrita como os 4 estágios do aprendizado de qualquer nova habilidade, a teoria foi desenvolvida nos anos 70 por Noel Burch. Desde então, ela é frequentemente atribuída a Abraham Maslow, embora o modelo não apareça em suas principais obras. Os 4 estágios descrevem como qualquer pessoa aprende uma nova habilidade – seja Liderança, seja a adoção de Métodos Ágeis por uma organização inteira.

Estágio 1: Incompetência Inconsciente

Não sabemos o que não sabemos. Nesse estágio ainda não se conhece a habilidade a ser aprendida, ou não se dá importância a ela. Uma organização antes de ter contato com Métodos Ágeis está nesse estágio – ela nem sabe que essas práticas existem. Para avançar, é preciso primeiro reconhecer a própria incompetência e dar valor à nova habilidade. É também aqui que muitas empresas sofrem com mudanças de mercado: simplesmente não sabem que a concorrência já domina uma habilidade que elas ainda nem conhecem.

Estágio 2: Incompetência Consciente

Sabemos o que não sabemos. É nesse estágio que o aprendizado de fato começa – reconhecemos a incompetência e passamos a valorizar a nova habilidade. É também o estágio mais difícil: erros e falhas aparecem, novas sub-habilidades se revelam, e a frustração aumenta. É aqui que muitas pessoas e empresas desistem – mas errar faz parte do processo e é necessário para avançar. Uma organização iniciando o Scrum percebe nesse estágio que, além de empoderar o time, precisa aprender sub-habilidades como Sprint Planning, Daily Scrum e priorização de Product Backlog.

Estágio 3: Competência Consciente

Experimentamos e praticamos a nova habilidade. Já sabemos executá-la, mas ainda de forma mecânica e dependendo de muita atenção para não errar. É mais fácil que o estágio anterior, mas ainda exige esforço perceptível – e os primeiros resultados começam a aparecer, o que já é motivador. Numa Transformação Ágil, é o momento em que a organização já executa todo o Scrum, mas ainda de forma mecanizada, com deslizes em estimativas e no planejamento de grandes entregas.

Estágio 4: Competência Inconsciente

Fazemos sem perceber. A habilidade já foi executada tantas vezes que agora é realizada com naturalidade – “a prática leva à perfeição”. Nesse estágio o domínio é tão grande que a habilidade começa a ser moldada e adaptada ao contexto específico. Numa organização, é o momento de Mastery: os Métodos Ágeis deixam de ser seguidos à risca e passam a ser adaptados à realidade do time.

Erros comuns ao lidar com os estágios da competência

• Desistir no estágio de Incompetência Consciente, justamente quando os erros e a frustração aumentam – é o estágio mais difícil, não um sinal de fracasso.
• Achar que a organização inteira está no mesmo estágio, quando times e pessoas diferentes podem estar em estágios distintos ao mesmo tempo.
• Confundir Competência Consciente (ainda mecânica) com o objetivo final, parando de evoluir antes da Competência Inconsciente.
• Ignorar que uma habilidade dominada (Competência Inconsciente) ainda pode e deve ser adaptada ao contexto da organização.

Perguntas frequentes sobre os estágios da competência

Planning Poker: como estimar com o time usando Story Points

Planning Poker é uma técnica de estimativa ágil em que o time estima o tamanho relativo dos itens do Product Backlog (em Story Points, geralmente na sequência de Fibonacci) jogando cartas simultaneamente, em vez de discutir um número por vez. Funciona porque somos péssimos em estimar esforço absoluto, mas bons em comparar tamanhos relativos.

Cone da Incerteza

Estimativas iniciais de um projeto podem variar de 0% a 400% – e isso é normal, não um fracasso de planejamento.

Story Point

Medida relativa de esforço, complexidade e risco – não uma estimativa de horas.

Sequência de Fibonacci

Usada no Planning Poker porque os “saltos” entre os números forçam discussão, em vez de escolher o meio-termo.

Efeito Manada

Quando todos estimam igual à pessoa mais experiente – o Planning Poker evita isso ao revelar as cartas só depois que todos já escolheram.

A incerteza das estimativas

Somos péssimos em estimar esforço – e ainda assim continuamos estimando, porque o time precisa de algum horizonte para planejar. Qualquer atividade, simples ou complexa, vai ter variação entre o estimado e o realizado: uma tarefa estimada em 8 horas pode levar 2, e uma estimada em 15 minutos pode levar 3 horas. Isso vai acontecer sempre – a questão não é eliminar a variação, é aprender a lidar com ela.

O Cone da Incerteza

Em 1958, a American Association of Cost Engineers criou o conceito de Cone da Incerteza: toda estimativa carrega um range de incerteza. Em 1981, Barry Boehm trouxe essa ideia para o desenvolvimento de software através do Modelo Espiral. O Cone prevê que estimativas iniciais podem variar de 0% a 400% – a estimativa máxima pode chegar a ser 16 vezes maior que a mínima. Com o tempo, à medida que o time entrega e recebe feedback real (como acontece a cada Sprint no Scrum), essa incerteza vai diminuindo e as estimativas se calibram com a realidade.

Planning Poker: estime pelo tamanho relativo

Somos ruins estimando esforço absoluto, mas bons comparando tamanho relativo – como ao comprar roupas: comparamos o tamanho das peças (P, M, G) em vez de calcular medidas exatas. O Planning Poker usa exatamente esse princípio: em vez de perguntar “quantas horas?”, pergunta “é maior ou menor que este outro item que já conhecemos?”.

Story Points: o que é afinal?

Segundo Mike Cohn, “um story point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma feature, a complexidade desse desenvolvimento e o risco contido nele”. Em outras palavras: Story Point é uma medida relativa de esforço, complexidade e risco – não um substituto direto para horas.

Como estimar com dimensionamento relativo

Estimar por comparação e triangulação é simples: comece pelo menor item conhecido e compare os demais a ele. Em uma planta de apartamento, por exemplo:

Como jogar o Planning Poker

Durante a Sprint Planning, com os itens do Product Backlog já priorizados, algumas regras ajudam o jogo a funcionar:

• Só jogam as pessoas que vão efetivamente construir os itens.
• O Scrum Master facilita o jogo.
• O Product Owner fica disponível para tirar dúvidas e apresenta os itens priorizados ao time.
• Todos precisam ter o baralho de Planning Poker.

O time começa definindo em consenso qual é o menor item entre os selecionados – de preferência um item já entregue em uma Sprint passada, para servir de referência real. A partir daí, para cada novo item, todos escolhem sua carta em segredo e revelam ao mesmo tempo. Quem jogou o menor e o maior valor explicam o motivo – essa troca costuma revelar detalhes que o resto do time não tinha considerado. Joga-se novamente até existir consenso (ou até o time decidir uma regra de desempate, como usar a média ou o valor que mais de 70% escolheu).

Dicas para quando não há consenso

Duas regras de desempate comuns: usar a média das cartas jogadas, ou – a abordagem que costuma funcionar melhor – jogar até 3 rodadas e, se ainda não houver consenso, adotar o valor que mais de 70% do time escolheu. Se nem isso gerar maioria, é sinal de que o item precisa ser quebrado em partes menores – o que, por si só, já ajuda o time a entender melhor a história.

Por que a Sequência de Fibonacci?

Na sequência de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21, 34…), cada número é a soma dos dois anteriores. O Planning Poker usa essa sequência porque o “salto” entre os números cresce conforme eles aumentam – e é exatamente esse salto que força a discussão. Quando os itens são pequenos (1, 2, 3), a assertividade é alta porque o item é simples de entender por completo. Já entre 8 e 13 o salto é grande o suficiente para evitar que o time escolha “o meio-termo” (como 10) só para não discutir – a intenção é tirar as pessoas do piloto automático.

Benefícios de jogar Planning Poker

Acaba com o Efeito Manada

Efeito Manada é quando a pessoa mais experiente do time estima primeiro e todo mundo converge para o mesmo número, só por referência. Como as cartas do Planning Poker só são reveladas depois que todos já escolheram, esse efeito simplesmente não acontece.

Embate de ideias e conceitos

Talvez o maior benefício: quando o time discute por que estimou diferente, ideias e soluções emergem – e o conhecimento coletivo sobre o item cresce de verdade.

Mede a qualidade do Ready

Se muitos itens precisam ser quebrados durante a Planning, é sinal de que as histórias chegaram com baixa qualidade de Ready – vale revisar a Definition of Ready do time. Estimativas sistematicamente altas também indicam incerteza alta, sinal de que as histórias precisam de mais refinamento antes da Planning.

Planning Poker é só uma das práticas de estimativa e facilitação do Scrum – conhecer bem essas práticas (gestão de capacidade, times eficazes em Daily e Sprint Review) faz diferença real na carreira de quem facilita Sprints no dia a dia. Saiba mais no Scrum de Verdade.

Erros comuns no Planning Poker

• Tratar Story Point como sinônimo de horas, em vez de uma medida relativa de esforço, complexidade e risco.
• Deixar a pessoa mais experiente falar antes dos demais, recriando o Efeito Manada mesmo jogando as cartas.
• Não discutir os motivos por trás do menor e do maior valor jogado – é aí que está o maior aprendizado.
• Insistir em itens com baixo consenso em vez de quebrá-los em partes menores.
• Começar a estimar sem antes calibrar com um item de referência já entregue pelo time.

Perguntas frequentes sobre Planning Poker

Sprint Review: Entregando Software Funcionando

Sprint Review é o rito do Scrum realizado ao final de cada Sprint, no qual o Time Scrum demonstra o incremento de software que foi desenvolvido, testado e está pronto para produção. Participam normalmente o Product Owner, o Scrum Master e os Stakeholders do cliente.

O que é a Sprint Review

No Scrum, ao final de cada Sprint é necessário que seja entregue um incremento de software funcionando – ou seja, algo que o Time Scrum tenha desenvolvido, testado e que esteja pronto para ser colocado em produção. É isso que é demonstrado durante a Sprint Review, normalmente para o Product Owner, o Scrum Master e os Stakeholders do cliente.

Execução da Sprint Review

A Sprint Review deve acontecer de uma maneira focada no que está sendo demonstrado funcionando. Por isso, não é recomendada a utilização de slides e/ou apresentações prontas – assim o tempo é otimizado, não passando de 2 horas.

Durante a review, o projeto deve ser revisado de acordo com a Meta do Sprint, definida no Sprint Planning. O ideal é que o time consiga alcançar a meta estipulada, mesmo que alguns itens ainda não tenham sido finalizados.

É importante que os membros do time tomem nota dos comentários realizados durante a Sprint Review, para que consigam considerar esses itens no planejamento do próximo ciclo de desenvolvimento.

Erros comuns na Sprint Review

• Usar slides e apresentações prontas em vez de demonstrar o software funcionando de verdade.
• Deixar a reunião se estender além de 2 horas por falta de foco na demonstração.
• Não revisar o progresso em relação à Meta do Sprint definida no Sprint Planning.
• Não registrar os comentários dos participantes para aproveitá-los no próximo ciclo.

Perguntas frequentes sobre Sprint Review