Gestão de Projetos¶

A filosofia do Ágil¶

Quando os métodos ágeis surgiram, havia forte demanda por modelos de desenvolvimento mais flexíveis e dinâmicos — os processos existentes eram pesados, e a proposta do Ágil era torná-los leves. Isso não significa reduzir prazos de entrega a qualquer custo: o foco real é oferecer soluções relevantes e com qualidade, mesmo que isso demande um pouco mais de tempo — o Ágil prioriza a aceitação de mudanças durante a concepção do software, pois elas surgem para agregar valor de negócio a ele. Um solicitante satisfeito e um software de valor importam mais do que só cumprir um prazo (ver Manifesto Ágil).

Fluência ágil: os quatro estágios¶

Adotar as cerimônias (reunião diária, sprint, retrospectiva) não torna uma equipe ágil: muita organização segue o ritual e não colhe os benefícios, porque não entendeu a essência (colaboração, entrega de valor, adaptação). Fluência ágil (modelo de Diana Larsen e James Shore) descreve como a equipe se comporta sob pressão: não basta conhecer as práticas, elas precisam virar hábito.

Definição: fluência ágil

Capacidade de a equipe aplicar práticas ágeis de forma natural, inclusive quando há pressão ou distração. Depende de habilidades das pessoas, da estrutura de gestão, dos relacionamentos e da cultura da organização, e é conquistada em quatro estágios.

Estágio	Foco	O que a equipe ganha	Práticas típicas
1. Foco em valor	Cultura da equipe	Transparência e melhor visibilidade; a equipe passa a se responsabilizar pelo valor de negócio, não só pelas tarefas técnicas	Quadro visível, visão do produto, iterações curtas, histórias de usuário, limite de WIP
2. Entrega de valor	Habilidades técnicas	Alta produtividade e qualidade externa; produto sempre pronto para entrega	TDD, integração contínua, programação em par, propriedade coletiva do código, refatoração
3. Otimização de valor	Estrutura organizacional	A equipe direciona o produto com base em dados e feedback do mercado	Métricas, metas, demonstrações, retrospectivas
4. Otimização sistêmica	A organização inteira	Alinhamento da empresa, gestão ágil, aprendizagem contínua	Gestão 3.0, comunidades de prática, formação de equipes, escala (programas e portfólios)

Maturidade da equipe e da prática¶

Equipe, não grupo: métodos ágeis exigem verdadeiras equipes, que passam pelos estágios de Tuckman (formação, tempestade, normatização, performance — veja Liderança). Por isso, trocar pessoas de time com frequência destrói a fluência; o turnover é apontado como principal causa de perda de fluência.
Shu-Ha-Ri (aprendizado de artes marciais): Shu — seguir as regras do método à risca, sem improvisar; Ha — entender os porquês, adaptar e quebrar regras com critério; Ri — a prática é natural e a equipe inventa as suas. A mesma equipe pode estar em Ri para entregas frequentes e em Shu para programação em par. Quebrar as regras antes de dominá-las costuma levar a "fazer qualquer outra coisa chamada de ágil".

Ordem, caos e complexidade¶

Equipes e organizações podem ser colocadas numa escala entre dois extremos:

Extremo	Característica	Problema
Ordem	Regras para tudo, nenhuma autonomia	Tira a criatividade, não reage a mudança
Caos	Nenhuma regra ou restrição	Imprevisível: cada um faz de um jeito
Complexidade ("beira do caos")	Poucas regras de alto nível, e o resto é auto-organização	É onde equipes ágeis funcionam

Métodos ágeis posicionam o trabalho na complexidade: o Scrum, por exemplo, só impõe tamanho de equipe, reunião diária de até 15 min e uma entrega funcional por iteração. O papel de quem gerencia deixa de ser criar regras e passa a ser garantir que as pessoas possam criá-las juntas. Auto-organização exige empoderamento, que exige confiança; e ela sozinha pode levar a qualquer resultado, bom ou ruim, por isso precisa de metas compartilhadas (mais em Gestão de Equipes).

Scrum¶

Definição: Origem do Scrum

Embora Ken Schwaber e Jeff Sutherland sejam frequentemente creditados por formalizá-lo em 2001 (do jeito que se conhece hoje), suas origens remontam a 1986, quando Hirotaka Takeuchi e Ikujiro Nonaka perceberam que uma formação tática do Rugby poderia ser adaptada ao desenvolvimento de software: toda a equipe em torno de um objetivo comum, entregando o software com o maior valor de negócio possível, dentro do prazo e com agilidade — como um time de Rugby avançando junto contra um adversário, em sincronia, até a linha de fundo do oponente.

Papéis¶

Definição: Product Owner (PO)

A pessoa "dona" do produto (software) — tem o conhecimento sobre o que deve ser automatizado, a capacidade de priorizar o que deve ser feito, e é o contato principal (mas não único) para obtenção de informações. Faz parte da equipe do solicitante.

Definição: Scrum Master (SM)

A pessoa responsável por guiar o desenvolvimento do software, assegurando que o Scrum esteja sendo seguido da melhor forma — tanto na codificação em si quanto nas prioridades definidas, prazos acordados, qualidade da codificação e documentação. Faz parte da equipe de desenvolvimento.

Definição: Time (desenvolvimento)

As pessoas responsáveis por codificar, testar e documentar o software, seguindo à risca os princípios do Scrum e as boas práticas de codificação. Fazem parte da equipe de desenvolvimento.

Artefatos¶

Definição: User Story / História de Usuário (HU)

Documento que declara uma necessidade que o PO deseja que o software atenda — indica quem quer, o que deseja e o porquê da solicitação. Ainda não constitui a documentação completa do software (nem para isso, nem para a codificação); num primeiro momento deve ser simples e sucinta, mas depois deve ser expandida em cenários e critérios de aceitação.

Definição: Item de Backlog (IB)

O item responsável por definir o que deve ser feito — uma necessidade/funcionalidade a ser automatizada, um bug a ser resolvido, uma tarefa técnica de suporte, uma pesquisa/prova de conceito, ou qualquer coisa que gere valor para o software e precise ser gerenciada, implementada e discutida pela equipe.

Definição: Product Backlog x Sprint Backlog x Release/MVP

Product backlog é o grupo de IBs que o PO sabe precisarem ser atendidos, mas ainda não priorizados ou detalhados. Sprint backlog é o grupo de IBs que o PO priorizou e que devem ser trabalhados na sprint atual. Release (ou MVP — Minimum Viable Product) é o grupo de IBs priorizados, detalhados e atendidos nas sprints que compõem a entrega atual — devem representar o valor de negócio mais alto no momento corrente, entregues ao final da sprint em que a versão nova e funcional do software estiver disponível.

Definição: Burndown Chart

Ferramenta visual que acompanha o progresso de um time durante uma sprint, mostrando a relação entre a quantidade de HUs entregues e o tempo de duração da sprint — duas linhas, uma de esforço ideal e outra de esforço real. Linha de esforço real abaixo da ideal indica que o time está adiantado (restam menos HUs do que planejado); acima da ideal indica atraso (restam mais HUs do que planejado).

Cerimônias¶

Definição: Sprint e Sprint Planning

Sprint é o período (de 2 a 4 semanas) em que as solicitações priorizadas devem ser atendidas — ao final, uma release/MVP é criada e disponibilizada; idealmente, um MVP deve conter de 2 a 4 sprints. Sprint Planning é a reunião inicial em que o PO e o SM definem, em conjunto, quais HUs do Product Backlog serão alocadas no Sprint Backlog — considerando valor, complexidade, tempo de entrega, entre outros fatores.

Definição: Daily Scrum Meeting

Reunião diária (preferencialmente) em que o time troca experiências e desafios vivenciados durante a sprint, com o objetivo de obter e disseminar conhecimento. Não deve ultrapassar 30 minutos, e deve ser guiada pelo Scrum Master — a participação de cada membro é crucial para resolver problemas de forma célere e compartilhar conhecimento.

Definição: Sprint Review x Sprint Retrospective

Sprint Review é a reunião ao final da sprint em que o Scrum Team apresenta o MVP ao solicitante, para que ele verifique se atende às expectativas — depois, o produto fica disponível por um período de homologação até ser aprovado e disponibilizado em produção. Sprint Retrospective é a reunião ao final da sprint em que o Scrum Team se reúne internamente para trocar experiências/conhecimentos, com a expectativa de que, na próxima sprint, os problemas identificados sejam minimizados.

Definição: Planning Poker / Scrum Poker

Método de quantificação do esforço necessário para o desenvolvimento das Histórias de Usuário.

flowchart LR
    PB["Product<br/>Backlog"] --> SB["Sprint<br/>Backlog"]
    SB -->|"Sprint (2 a 4 semanas,<br/>reunião diária)"| MVP["Produto ou<br/>Funcionalidade<br/>Concluída"]

Kanban¶

Definição: Origem do Kanban

Também de origem japonesa, mas ao contrário do Scrum, o Kanban não foi idealizado por pessoas específicas — e sim por uma empresa: a Toyota, mais precisamente por Taiichi Ohno, que criou um processo de produção chamado Just in Time (JIT), baseado no Lean Manufacturing. Inicialmente pensado para a indústria, o modelo foi adaptado à concepção de software por David J. Anderson, que percebeu que o "sistema puxado" preconizado pelo Kanban — no qual novas demandas só são trabalhadas quando as atuais são finalizadas e disponibilizadas, gerando espaço para absorver novas tarefas — se encaixava bem no desenvolvimento de software, evitando sobrecarregar o time com demandas não priorizadas impostas pelos solicitantes.

Definição: Work in Progress (WIP)

Processo de acompanhamento contínuo da atividade em execução — no caso, a implementação de uma funcionalidade demandada por meio de um Item de Backlog.

Definição: Cadência

Organização interna da equipe de desenvolvimento que, com o tempo, passa a identificar o período necessário para entregar uma nova versão de valor ao solicitante — pode ser semanal, quinzenal ou mensal, por exemplo. Tem forte relação com o Lead Time.

Definição: Lead Time (tempo de espera/entrega)

Tempo que um Item de Backlog leva desde sua definição, passando pela análise, codificação, teste, até a entrega ao solicitante. Identificar esse tempo contribui para definir a cadência de entrega da equipe.

Definição: Quadro Kanban

Recurso visual — altamente configurável, adaptável a qualquer projeto ou empresa — que organiza os Itens de Backlog em colunas representando as etapas do fluxo de trabalho (ex.: Análise, Codificação, Teste, Homologação, Implantado), permitindo visualizar rapidamente o WIP de cada etapa e onde estão os gargalos, sem exigir uma ordem fixa de execução entre os itens — prioridades e complexidades organizam a execução de forma livre.

flowchart LR
    Backlog --> Analise[Análise] --> Codificacao[Codificação] --> Teste --> Homologacao[Homologação] --> Implantado

Extreme Programming (XP)¶

Definição: Extreme Programming (XP)

Metodologia ágil criada por Kent Beck na década de 1990 que enfatiza a satisfação do cliente e a qualidade técnica do código: entrega o software de que o cliente precisa, quando ele precisa, e permite responder a mudanças de requisitos mesmo no fim do ciclo.

Os quatro valores que sustentam o XP:

Valor	Na prática
Comunicação contínua	Compartilhar conhecimento no time e manter contato constante com o cliente
Simplicidade	Fazer só o necessário; evitar complexidade ao enfrentar novos problemas
Feedback constante	Entregas pequenas e frequentes para incorporar o retorno rápido do cliente
Coragem	Aceitar mudanças de requisitos durante o desenvolvimento e refatorar assim que necessário

O ciclo é modular: o módulo é desenvolvido, testado e validado pelo cliente, que dá retorno rápido; ajustes voltam ao time. As práticas de engenharia típicas do XP são programação em par, TDD (Qualidade), refatoração contínua e integração frequente.

XP x Scrum¶

	Scrum	XP
Foco	Gestão do projeto e entrega iterativa	Qualidade do código por meio de práticas de engenharia
Entregas	Ao final de cada Sprint (2 a 4 semanas)	Iterativas, em ciclos curtos e contínuos
Papéis	Bem definidos: Product Owner, Scrum Master, time de desenvolvimento	Menos rígidos; responsabilidades compartilhadas
Práticas	Cerimônias e artefatos	Programação em par, TDD, refatoração, integração contínua

As duas se complementam e é comum combiná-las (Scrum para gerir, XP para a engenharia). A escolha depende das necessidades do projeto e da dinâmica do time. Para a carreira no ágil, veja Plano de carreira.

Scrum x Kanban¶

Definição: Scrumban — o melhor dos dois mundos

É comum que empresas e projetos utilizem Scrum e Kanban combinados, numa abordagem chamada Scrumban — embora, nos ciclos de vida mais clássicos de cada metodologia, essa combinação não seja realizada "oficialmente" por nenhuma das duas.

Definição: O ganho comum das duas — documentação contínua

Uma característica evidente tanto no Scrum quanto no Kanban: por serem abordagens iterativas-incrementais, a documentação do software pode ocorrer de forma contínua. Isso é especialmente útil por dois motivos: mitiga falhas de entendimento que poderiam se transformar em erros de codificação, e evita retrabalho no processo de documentação (que pode ser realizado após testes, homologações e implantação, em vez de tentar antecipar tudo de uma vez).

Projeto x produto e ciclo de vida do produto¶

Os dois termos são confundidos com frequência:

	Projeto	Produto
Pergunta central	Como e quando entregamos?	O quê e por quê construímos?
Foco	Escopo, cronograma, custo, riscos	Valor para o cliente, mercado, receita
Responsável típico	Gerente de projetos (ou Scrum Master)	Gerente de produto (ou Product Owner)
Duração	Tem início e fim	Vive enquanto houver clientes

O gerente de projetos planeja e acompanha, mas não define as metas do produto (isso é do gerente de produto e dos interessados) nem gerencia pessoas (isso é do gestor). Para o desenvolvedor, ele é quem pergunta quanto falta e o que está bloqueando.

Ciclo de vida do produto¶

Todo produto bem-sucedido segue um ciclo, e cada fase pede uma mentalidade diferente de programação:

flowchart LR
    C[Conceito] --> P[Protótipo]
    P --> D[Desenvolvimento]
    D --> L[Lançamento]
    L --> M[Manutenção e evolução]
    M -->|próxima versão| C

Fase	Objetivo	Como programar
Conceito	Avaliar o que é possível e se há mercado: pesquisa, entrevistas, dados	Estudos rápidos e delimitados — o que o livro chama de "pregar grampos", hoje conhecido como *spike: aprofundar-se só o suficiente* para responder a uma pergunta específica (ex.: "esta biblioteca aguenta 10 mil conexões?"); não é pesquisa acadêmica
Protótipo	Ensinar o mercado e a equipe: validar o conceito e aprender a construir. Alguns produtos morrem aqui, e é melhor descobrir cedo	Cobrir muito terreno rápido; código descartável
Desenvolvimento	Construir a versão real	Qualidade, testes, manutenibilidade; siga boas práticas estabelecidas e não reinvente (instaladores, autenticação, logs já foram resolvidos antes)
Lançamento	Colocar nas mãos dos clientes	Estabilização, correção de defeitos críticos, preparação operacional
Manutenção e evolução	Suporte, correções e próximas versões	Atender clientes enquanto parte da equipe volta ao conceito da versão seguinte

Regras de bolso:

"Artistas de verdade entregam" (frase atribuída a Steve Jobs): a tentação de adicionar mais um recurso ou corrigir mais um defeito atrasa a entrega. Equilibre: a versão 1.1 de qualquer produto costuma ser a que deveria ter sido a 1.0, e isso é normal. Entregue e aprenda com o uso.
Concentre a criatividade no diferencial do produto — no que ele faz de novo — e use soluções conhecidas no resto.
Ciclo de vida do produto ≠ ciclo de vida do projeto: no Ágil, o produto evolui por várias iterações de tamanho fixo; cada versão é um release, não um projeto isolado.

Do desenvolvimento ao lançamento¶

Um processo típico de entrega (Gestão de releases):

O líder cria um ramo de lançamento estável, separado do tronco de desenvolvimento, que só recebe correções.
Quando a equipe acha que está pronto, a versão é rotulada candidata a lançamento (release candidate) e recebe um número.
A área de testes e, às vezes, testadores beta externos tentam derrubá-la; defeitos encontrados geram novas candidatas.
Repete-se até a gestão aprovar; a candidata final recebe o rótulo definitivo.

O lançamento é, ao mesmo tempo, "terminamos" e "estamos apenas começando": o primeiro cliente real vai encontrar o que ninguém achou. Ofereça ajuda e esteja disponível para o suporte.

Dando estimativas honestas¶

A resposta sincera a "quanto tempo leva?" é muitas vezes "não sei", mas o gestor de projetos não pode planejar com isso. Dê uma estimativa com faixa e riscos explícitos ("de duas a quatro semanas; o que mais pesa é a integração com o sistema X"), comunique o que é desconhecido por escrito e avise assim que souber de um atraso: o pior cenário é descobrir, depois de cinco meses de um projeto de seis, que ele não será entregue. Inclua tempo para testes em toda estimativa e acompanhe a precisão das suas estimativas ao longo do tempo (você começará subestimando muito). Mais em Estimativas.

Planejamento ágil e foco em valor¶

Planejar em termos técnicos ("vamos montar o módulo X") dá lugar a planejar em termos de valor de negócio: o que entrega mais retorno ao cliente primeiro? Quanto mais cedo o cliente usa o software, antes retorna o investimento, mais cedo se aprende com o uso e menos se desperdiça com requisitos que nunca seriam usados.

Visão do produto¶

Todo projeto nasce de um(a) visionário(a) (no Scrum, o Product Owner) que enxerga uma necessidade. Ele(a) precisa comunicar, e manter sempre visível (wiki, mural), três respostas: que objetivo o projeto deve atingir, por que agregará valor e como medir o sucesso. Sem essa visão geral, a equipe toma milhares de pequenas decisões por dia sem contexto. Uma forma de treinar a síntese é o discurso do elevador: em poucos segundos, dizer quem (o que o ouvinte deve lembrar), o quê (valor ou impacto), por quê (diferenciais) e qual objetivo (o que se espera que ele faça).

Planejamento iterativo¶

O projeto é dividido em iterações curtas (uma a quatro semanas; no XP, "Jogo do Planejamento"). Em vez de uma longa análise prematura de requisitos (Big Requirements Up Front) e de um design completo antecipado (Big Design Up Front) — fontes de desperdício —, detalha-se só o que está perto de ser feito. Um backlog saudável é DEEP (Mike Cohn):

Letra	Qualidade
Detalhado apropriadamente	Itens de alta prioridade, detalhados; os de baixa, só esboçados
Estimado	Todos os itens têm estimativa de esforço
Emergente	Cresce e muda conforme o aprendizado (itens entram e saem)
Priorizado	Ordenado por valor de negócio

Mantenha o backlog pequeno: a complexidade de priorizar cresce rápido com cada item novo. A conversa presencial entre equipe e PO substitui o documento extenso — comunicação em papel é "fria e pobre", sem espaço para perguntas e respostas.

Planejando uma iteração:

Calcule a velocidade da equipe: soma dos pontos das histórias concluídas na iteração anterior (ou média das últimas).
O PO escolhe as histórias de maior prioridade até esse total; a equipe as detalha e pergunta.
Se terminar antes, pede ao PO as próximas histórias.
Não adicione histórias a uma iteração em andamento; mudanças emergentes devem ser raras e negociadas (a equipe troca por algo de mesmo tamanho). Defeitos em produção costumam ter prioridade, e se o trabalho não planejado for frequente, algo está errado.

Reunião diária e WIP¶

A reunião diária (stand-up, Daily Scrum) dura cerca de 15 minutos, em pé, no mesmo horário e local. Perguntas clássicas: o que fiz desde ontem, o que farei hoje, o que me impede? Uma variação foca em entrega: que histórias ajudei a terminar, o que ajudarei a terminar hoje, como o time pode ajudar a empurrar uma história até o fim? Evite discussões longas (marque-as para depois) e deixe quem não é do time só observando — a parábola do porco e da galinha distingue quem está comprometido (porcos) de quem está só envolvido (galinhas).

Limitar o WIP (work in progress): trabalho começado e não terminado é "estoque" e desperdício. O lead time cresce proporcionalmente ao WIP; por isso, "pare de começar e comece a terminar". Defina limites por coluna do quadro (um pouco acima do número de pessoas na etapa). Quando uma etapa estoura o limite, todos ajudam a escoar o fluxo, em vez de puxar mais trabalho (veja Kanban).

Histórias, mapa de histórias e personas¶

Histórias de usuário (critérios INVEST, formato "Eu, como papel, quero funcionalidade para que valor", critérios de aceitação) e personas estão em Requisitos de Software. Complementos:

Hierarquia de requisitos: Temas → Épicos → Funcionalidades → Histórias → Tarefas (cada tarefa idealmente cabe em um dia). Histórias grandes se dividem por regra de negócio, dados, cenário ou perfil de usuário, sem perder o INVEST.
Mapa de histórias (story mapping, Jeff Patton): organiza as atividades do usuário no eixo horizontal (na ordem em que acontecem) e as histórias de cada uma no eixo vertical (por prioridade). Permite planejar releases em camadas: o primeiro release traz o mínimo de cada funcionalidade (por exemplo, carrinho, vitrine e consulta de pedidos básicos), e os seguintes aprofundam.
Injeção de funcionalidades (feature injection, Chris Matts): comece pelo valor de negócio e só depois "injete" funcionalidades que o produzam, validadas por exemplos reais. A história é invertida: "Para [valor], como [papel], eu quero [funcionalidade]" — o valor é fixo e a funcionalidade, uma opção.

Estimativas¶

Estimativas são imprecisas e melhoram com a experiência. Estime em equipe (quem executa estima; uma só pessoa tem vieses). Unidades comuns: horas ideais, ou pontos de história (relativos: toma-se uma história simples como referência e compara-se o resto) em escala de Fibonacci (1, 2, 3, 5, 8, 13…), que expressa a incerteza crescente. No Planning Poker, cada pessoa baixa uma carta ao mesmo tempo; quem deu o maior e o menor valor explica suas razões e repete-se até convergir. O importante é o consenso e a conversa, não a técnica.

Releases e roadmap¶

Release é uma entrega a produção; contém várias iterações (por exemplo, release mensal com quatro iterações semanais). O planejamento de release escolhe o mínimo de funcionalidades que agrega valor e usa a velocidade da equipe para estimar o que cabe. Não planeje prazos muito longos: a incerteza cresce com o tempo.
O ágil aceita mudanças no planejamento, com proteção para que não sejam tão frequentes a ponto de inviabilizar o projeto.
Roadmap do produto: visão de alto nível dos próximos releases e marcos, útil para marketing e negócio. Usa-se como critério relativo (o que vem antes ou depois), não como promessa de datas.

Opções reais: manter as portas abertas¶

Opções reais (Chris Matts e Olav Maassen): enxergue decisões como opções, não compromissos, e comprometa-se tarde e de forma deliberada. Três regras: (1) opções têm valor; (2) opções expiram; (3) nunca se comprometa cedo, a menos que saiba por quê. Decidir "no último momento responsável" é princípio do Lean e se conecta a contratos ágeis que mantêm o escopo aberto.

Engenharia que sustenta a agilidade¶

Práticas técnicas já descritas em outras páginas: TDD e testes, refatoração, código limpo, dívida técnica e code review, integração contínua (CI/CD), linguagem ubíqua (DDD). Pontos adicionais:

Pirâmide de testes (Mike Cohn): muitos testes de unidade (rápidos e baratos), menos de integração/serviço e poucos de ponta a ponta/interface (lentos e frágeis), mais testes exploratórios manuais, em que a pessoa testadora vai além do roteiro. A qualidade vem desde o início; um defeito achado cedo custa muito menos.
Código legado = código sem testes (Michael Feathers). Para começar: liste os casos de teste, classifique por risco, custo de teste manual e esforço de automação, ordene e automatize alguns a cada iteração começando pelos de maior risco.
Design iterativo: o design detalhado emerge durante o desenvolvimento; fixá-lo cedo gera desperdício. Um bom design é simples, sem repetição e eficaz.
Definição de pronto (Definition of Done, DoD): checklist do que deve valer antes de uma história ser dada por concluída (código revisado, testes passando, documentação mínima, implantada em homologação...). Existe para história, iteração e release; é única para a equipe, visível e evolui com a maturidade.
Programação em par: alterne os pares para disseminar conhecimento (uma matriz de quem já pareou com quem mostra lacunas) — e é uma defesa contra o desperdício por falta de foco.
Mural de práticas: tornar explícitas as práticas ágeis da equipe (e métricas associadas) para que não existam só no papel.

Métricas, demonstrações e retrospectivas¶

Metas e métricas ágeis¶

Metas: definem direção; devem ser explícitas e visíveis, não usadas para ameaçar nem vinculadas a bônus financeiros (isso corrompe a colaboração).
Gráficos: burndown (trabalho pendente x tempo; sobe se adicionar escopo), burnup (trabalho concluído e escopo total), e diagrama de fluxo cumulativo (CFD), que mostra em qual etapa o trabalho se acumula (gargalo).
Velocidade: pontos entregues por iteração; serve ao planejamento, não para comparar equipes.
Indicadores indutores (leading) x de resultado (lagging): os primeiros antecipam (cobertura de testes, número de testes automatizados); os segundos confirmam (defeitos em produção, satisfação).
Meça equipes, não indivíduos: medir pessoas faz com que corrompam a métrica e prejudica a colaboração.
Otimização local x sistêmica: otimizar uma métrica isolada (como "defeitos encontrados" de um fornecedor de testes pago por defeito) pode piorar o resultado global; prefira métricas de mais alto nível como retorno sobre o investimento.
No XP existe o papel de tracker, que acompanha métricas (variação da velocidade, horas extras, testes) e faz perguntas simples para apontar problemas.

Demonstração da iteração (Sprint Review)¶

Ao fim de cada iteração, reúna os interessados e mostre o software em funcionamento (não slides). Eles comentam e pedem mudanças, que viram itens de backlog.

Retrospectivas¶

A retrospectiva é a prática de melhoria contínua: ao fim de cada iteração a equipe discute o que funcionou e o que não, e escolhe ações. Costuma ser a primeira prática cortada sob pressão — um erro, pois é quando mais se precisa dela.

Quem participa: só a equipe, para haver segurança; um facilitador neutro (pode rodiziar) cuida do tempo, da participação de todos e de evitar o jogo de culpas. A primeira diretriz de Norm Kerth: "independentemente do que descobrirmos, entendemos e acreditamos genuinamente que todos fizeram o melhor trabalho que puderam, dado o que sabiam, suas habilidades e capacidades, os recursos disponíveis e a situação".
Cinco etapas (Derby e Larsen): preparação (meta clara), apresentação de dados (métricas, linha do tempo de eventos), geração de insights (brainstorming, votação por pontos, 5 porquês — perguntar "por quê?" repetidamente até a causa-raiz), decisão do que fazer (uma ou duas ações por iteração, com responsáveis) e fechamento (registrar e rever na próxima retrospectiva).
Comece simples: "o que está indo bem?" e "o que pode melhorar?", e varie as dinâmicas depois.

Antipadrões corporativos que você deve reconhecer¶

Assim como existem design patterns de código, existem padrões ruins recorrentes na gestão de projetos. Você dificilmente os corrige sozinho (são construídos ao longo de anos e por muitas mãos), mas reconhecê-los cedo ajuda a se proteger, comunicar riscos e decidir se vale ficar. Em entrevistas, descrever um desses cenários com maturidade (sem culpar ninguém) mostra senso crítico.

Antipadrão	Como se manifesta	O que fazer
"O cronograma é o rei"	Um plano (Gantt) com centenas de tarefas e dependências é montado para dezoito meses e vira verdade imutável, mesmo baseado em suposições impossíveis de validar. Na hora do aperto, corta-se o que for (testes, qualidade) para manter a data	Tratar o plano como hipótese, usar horizontes curtos, priorizar por valor (cortar o que for menos importante, não o mais difícil de fazer) e comunicar riscos com antecedência
O mítico homem-mês	Atraso? Põe-se mais gente no projeto. Mas a comunicação e a coordenação crescem mais depressa que a capacidade, e adicionar pessoas a um projeto atrasado o atrasa mais (Lei de Brooks)	Conversar mais com o time, convidar os novatos para sessões de programação em par e documentar o contexto; sugerir reduzir escopo ou ajustar a data
A apresentação do taco de hóquei	Projeção de receita lenta no começo e depois uma subida vertical sem qualquer base que explique a virada. O gráfico vira a "prova" de que o plano é bom	Pedir o cenário realista e as premissas; um bom plano de negócios mostra também o cenário em que o produto não explode
A grande reescrita	O time, cansado de um legado difícil, convence os interessados a recomeçar do zero. O trabalho é subestimado porque o código antigo continha regras de negócio ocultas; o prazo estoura enquanto o produto antigo precisa continuar evoluindo	Antes, tente melhorar por partes (Código legado) e separar complexidade necessária de acidental — a necessária não se joga fora
Medir pessoas por linhas de código	Produtividade vira volume; incentiva-se o código inchado	Propor métricas de resultado: valor entregue, qualidade, tempo de ciclo (Métricas)
Cascata com teste só no fim	Defeitos descobertos a semanas do prazo, quando o custo de corrigir é máximo	Testes automatizados e integração contínua desde o início (Engenharia que sustenta a agilidade)

A mensagem é: nenhum destes mata sozinho a empresa, mas todos anunciam tempos difíceis. Aprenda a reconhecer os sinais e a falar sobre eles com fatos, em particular e de forma construtiva.

Lean: eliminando desperdícios¶

O Lean (Toyota Production System) busca eliminar desperdício — tudo o que não agrega valor ao cliente. Em software, as fontes principais (Mary e Tom Poppendieck):

Desperdício	Exemplo	Remédio
Trabalho parcialmente pronto ("estoque")	Requisitos detalhados cedo demais; código não integrado	Iterações curtas, WIP baixo, entregas frequentes
Funcionalidades inúteis	Dado muito citado (de origem questionável): só cerca de 20% das funcionalidades são muito usadas	Foco em valor, MVP, feature injection
Documentação que ninguém lê	Documentos burocráticos	Documentar só o necessário e manter o que se documenta
Falta de foco	Trocar de tarefa ou pertencer a várias equipes (cada interrupção custa tempo)	Equipe dedicada, par, WIP baixo
Atrasos	Aprovações, contratações, indisponibilidade	Decisões rápidas, autonomia
Pessoas indisponíveis	PO ausente: dúvidas sem resposta	PO próximo da equipe
Defeitos	Quanto mais tarde achados, mais caros	Testes automatizados, CI, TDD