Gestão Ágil de Produtos e Projetos
Visão do professorComece pelo Scrum Guide 2020: responsabilidades, eventos, artefatos e compromissos. Depois compare fluxo Kanban, princípios Lean, práticas XP e escala no SAFe. O cuidado principal é não atribuir a um framework as regras de outro. Memorize definições centrais e limites, mas também explique o propósito: uma Daily não é prestação de contas ao chefe e um limite de WIP não é meta de iniciar tarefas. Essa ordem é pedagógica; o retorno por hora varia conforme seu domínio prévio.
Entenda do zero · Gestão Ágil
Agilidade é aprender e entregar valor em ciclos curtos, ajustando o caminho com base no que se observa. Não é trabalhar sem planejamento.
1. Por que não planejar tudo de uma vez?
Em um produto novo, nem todas as necessidades são conhecidas de início. Entregar uma parte utilizável, observar seu uso e ajustar a próxima entrega reduz o risco de construir uma solução inteira que não resolve o problema. O planejamento continua existindo, mas é revisto à medida que surgem informações.
2. Scrum: um ciclo de inspeção e adaptação
Scrum é um framework: uma estrutura leve, não uma receita detalhada de todas as tarefas. O Product Owner responde pela maximização do valor e pela gestão eficaz do Product Backlog. Os Developers criam o incremento utilizável. O Scrum Master ajuda a estabelecer o Scrum e a melhorar a efetividade do time. Não é um chefe distribuindo tarefas.
A Sprint é um período de até um mês. O time planeja um objetivo, trabalha, inspeciona diariamente o progresso, examina o resultado com interessados e reflete sobre como melhorar seu modo de trabalho. A Definição de Pronto estabelece o padrão de qualidade do incremento.
Na prática · um painel de arrecadaçãoEm vez de prometer um painel completo só daqui a seis meses, o time pode entregar uma primeira versão utilizável para comparar arrecadação e meta. Os usuários descobrem que precisam detalhar por município. Esse aprendizado ajuda a reordenar o backlog. Não significa aceitar qualquer mudança sem avaliar seu impacto no objetivo da Sprint.
3. Kanban: enxergar o trabalho e melhorar o fluxo
Um quadro mostra etapas como “a fazer”, “em andamento” e “concluído”. Mas Kanban não é só um quadro: inclui explicitar políticas, limitar trabalho em andamento (WIP) e acompanhar o fluxo. Começar muitas tarefas ao mesmo tempo pode aumentar filas e atrasar entregas.
4. Entregar tarefa não garante resultado
“Publicar três relatórios” mede uma entrega. “Reduzir o tempo de análise de cinco para dois dias” mede um resultado. Em OKR, o objetivo indica a direção e os resultados-chave permitem verificar o avanço. Quantidade de trabalho não é sinônimo de valor.
Confira se entendeu: a Daily Scrum é uma reunião para prestar contas ao chefe?
Não. É um evento dos Developers para inspecionar o progresso em direção à Meta da Sprint e adaptar o Sprint Backlog.
A seguir, estude os termos oficiais, os eventos e as métricas.
Manifesto Ágil: 4 valores e 12 princípios
Lei seca · Manifesto (2001)Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Pegadinha FCC"O Manifesto Ágil dispensa documentação, processos e planejamento." Errado: os itens da direita têm valor; apenas os da esquerda são mais valorizados. Também cuidado com troca de pares: "colaboração com o cliente mais que seguir um plano" está errado (o par correto é negociação de contratos).
MnemônicoEsquerda dos 4 valores = "I-S-C-R": Indivíduos, Software funcionando, Colaboração, Responder. Direita = "P-D-N-P": Processos, Documentação, Negociação, Plano. Na prova, confira se cada item da esquerda está com o seu par certo da direita, na mesma linha.
BizuO Manifesto foi assinado em 2001, em Snowbird (Utah), por 17 profissionais de métodos "leves" (Scrum, XP, DSDM, Crystal, FDD etc.). É sobre desenvolvimento de software; a extensão a produtos e projetos em geral é posterior.
Os 12 princípios (síntese fiel)
- Maior prioridade: satisfazer o cliente pela entrega contínua e adiantada de software com valor.
- Mudanças nos requisitos são bem-vindas, mesmo tardiamente; processos ágeis usam a mudança como vantagem competitiva para o cliente.
- Entregar software funcionando frequentemente, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
- Pessoas de negócio e desenvolvedores trabalham diariamente em conjunto durante todo o projeto.
- Construir projetos em torno de indivíduos motivados; dar ambiente e suporte e confiar neles.
- O método mais eficiente e eficaz de transmitir informação é a conversa face a face.
- Software funcionando é a medida primária de progresso.
- Processos ágeis promovem desenvolvimento sustentável: patrocinadores, desenvolvedores e usuários devem manter ritmo constante indefinidamente.
- Atenção contínua à excelência técnica e bom design aumenta a agilidade.
- Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.
- As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
- Em intervalos regulares, a equipe reflete sobre como ser mais eficaz e ajusta seu comportamento.
BizuFrases que a FCC adora: "software funcionando é a medida primária de progresso" (não "documentação aprovada" nem "velocidade"); "simplicidade = maximizar o trabalho não realizado"; entregas de semanas a meses com preferência pelo menor prazo.
Scrum Guide 2020: teoria, pilares e valores
Lei seca · Scrum Guide 2020"Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos." "Scrum é fundamentado no empirismo e no pensamento lean. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado. O pensamento lean reduz o desperdício e foca no essencial." "O framework Scrum é propositalmente incompleto."
| Pilares empíricos (3) | Valores (5) |
|---|---|
| Transparência: processo e trabalho visíveis a quem faz e a quem recebe. Baixa transparência leva a decisões que diminuem valor e aumentam risco. Inspeção: artefatos e progresso inspecionados frequentemente; os eventos existem para provocar mudança. Adaptação: se algo se desviar além de limites aceitáveis, ajustar o quanto antes. | Compromisso, Foco, Abertura, Respeito e Coragem. |
MnemônicoPilares = TIA (Transparência, Inspeção, Adaptação). Valores = "CFARC", lido como "Com Foco Aberto, Respeito e Coragem": Compromisso, Foco, Abertura, Respeito, Coragem.
Pegadinha FCC"Os pilares do Scrum são transparência, inspeção e colaboração" ou "e comprometimento". Errado: é adaptação. Compromisso é valor, não pilar. Outra: "a transparência habilita a inspeção; inspeção sem transparência é enganosa" está certo.
Time Scrum e accountabilities
- O Time Scrum é uma unidade coesa: um Scrum Master, um Product Owner e Developers. Sem sub-times nem hierarquias.
- Multifuncional (todas as habilidades para criar valor a cada Sprint) e autogerenciável (decide internamente quem faz o quê, quando e como).
- Pequeno: tipicamente 10 ou menos pessoas. Se ficar grande, reorganizar em vários times coesos, focados no mesmo produto, compartilhando a mesma Meta do Produto, o mesmo Product Backlog e o mesmo Product Owner.
- O Time Scrum é responsável por todas as atividades relacionadas ao produto: colaboração com stakeholders, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento.
| Accountability | É responsável (accountable) por |
|---|---|
| Developers | Criar o plano para a Sprint (Sprint Backlog); instilar qualidade aderindo à Definição de Pronto; adaptar o plano a cada dia rumo à Meta da Sprint; responsabilizar-se mutuamente como profissionais |
| Product Owner | Maximizar o valor do produto resultante do trabalho do Time. Gerenciamento eficaz do Product Backlog: desenvolver e comunicar explicitamente a Meta do Produto; criar e comunicar claramente os itens; ordenar os itens; garantir que o backlog seja transparente, visível e compreendido. Pode delegar o trabalho, mas continua accountable |
| Scrum Master | Estabelecer o Scrum como definido no Guia; pela eficácia do Time Scrum. São verdadeiros líderes que servem ao Time Scrum e à organização. Serve ao time (coaching em autogerenciamento e multifuncionalidade, remoção de impedimentos, garantir que eventos ocorram, sejam positivos, produtivos e dentro do timebox), ao PO (técnicas para Meta do Produto e backlog, planejamento empírico) e à organização (adoção do Scrum, remover barreiras entre stakeholders e times) |
Lei seca"O Product Owner é uma pessoa, não um comitê." "Para que os Product Owners tenham sucesso, toda a organização deve respeitar suas decisões." "Aqueles que desejam alterar o Product Backlog podem fazê-lo tentando convencer o Product Owner."
Pegadinha FCCTrocas de sujeito mais comuns: "o Scrum Master ordena o Product Backlog" (é o PO); "o PO define como transformar itens em incremento" (são os Developers); "o Scrum Master é responsável pelo Sprint Backlog" (é dos Developers); "o Scrum Master é o gerente do projeto" (Scrum não tem gerente de projeto). E o PO pode delegar, mas a accountability não se transfere.
Eventos e timeboxes
| Evento | Timebox máximo | Quem participa / propósito |
|---|---|---|
| Sprint | 1 mês ou menos (duração fixa) | Contêiner de todos os eventos. Nova Sprint começa imediatamente após o término da anterior |
| Sprint Planning | 8 horas (Sprint de 1 mês) | Todo o Time Scrum. Tópicos: Por que a Sprint é valiosa (Meta da Sprint)? O que pode ser feito? Como será feito? Pode convidar outras pessoas para aconselhar |
| Daily Scrum | 15 minutos | Evento para os Developers; mesmo horário e local todos os dias úteis. Inspecionar o progresso rumo à Meta da Sprint e adaptar o Sprint Backlog |
| Sprint Review | 4 horas (Sprint de 1 mês) | Time Scrum + stakeholders. Inspecionar o resultado da Sprint e determinar adaptações futuras; o Product Backlog pode ser ajustado. É o penúltimo evento. "Não deve ser limitada a uma apresentação" |
| Sprint Retrospective | 3 horas (Sprint de 1 mês) | Time Scrum. Planejar formas de aumentar qualidade e eficácia: indivíduos, interações, processos, ferramentas e Definição de Pronto. Conclui a Sprint |
MnemônicoTimeboxes de Sprint de 1 mês = "8 · 15 · 4 · 3": Planning 8 h, Daily 15 min, Review 4 h, Retro 3 h. Frase: "Oito Planos, Quinze Dias, Quatro Revisões, Três Retros". Para Sprints mais curtas, os eventos costumam ser mais curtos (exceto a Daily, sempre 15 min).
| Sprint Review | Sprint Retrospective | |
|---|---|---|
| Foco | O produto (o que foi feito, o incremento) e o que fazer a seguir | O processo/time (como o trabalho foi feito) |
| Participantes | Time Scrum e stakeholders-chave | Time Scrum |
| Saída | Product Backlog possivelmente ajustado | Melhorias mais impactantes, que podem entrar no próximo Sprint Backlog |
| Ordem | Penúltimo evento | Último evento (conclui a Sprint) |
Lei seca · durante a SprintNenhuma mudança é feita que coloque em risco a Meta da Sprint; a qualidade não diminui; o Product Backlog é refinado conforme necessário; o escopo pode ser clarificado e renegociado com o Product Owner conforme mais é aprendido. "Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint."
Pegadinha FCCRefinamento do Product Backlog não é evento: é atividade contínua (decompor e detalhar itens, adicionar descrição, ordem e tamanho). "A Sprint Review é uma cerimônia de aprovação (gate) para liberar valor" está errado: o Guia diz que pode-se entregar valor a qualquer momento, inclusive antes do fim da Sprint. E a Daily não exige mais as "três perguntas" (removidas em 2020).
BizuSe o PO ou o Scrum Master estiverem trabalhando ativamente em itens do Sprint Backlog, participam da Daily como Developers. Os Developers que farão o trabalho são responsáveis pelo dimensionamento (sizing) dos itens.
Artefatos, compromissos e Definição de Pronto
| Artefato | O que é | Compromisso | Dono |
|---|---|---|---|
| Product Backlog | Lista emergente e ordenada do que é necessário para melhorar o produto; única fonte de trabalho do Time | Meta do Produto (objetivo de longo prazo) | PO |
| Sprint Backlog | Meta da Sprint (por que) + itens selecionados (o que) + plano de entrega (como). "Um plano por e para os Developers"; atualizado ao longo da Sprint | Meta da Sprint | Developers |
| Incremento | Degrau concreto rumo à Meta do Produto; aditivo a todos os anteriores; deve ser utilizável. Vários incrementos podem ser criados numa Sprint | Definição de Pronto | Time Scrum |
MnemônicoCada artefato tem seu compromisso na mesma ordem de "tamanho": Produto → Meta do Produto; Sprint → Meta da Sprint; Incremento → Pronto. Frase: "Produto tem Meta, Sprint tem Meta, Incremento fica Pronto".
Lei seca · Definição de Pronto"A Definição de Pronto é uma descrição formal do estado do Incremento quando ele atende às medidas de qualidade exigidas para o produto." "No momento em que um item do Product Backlog atende à Definição de Pronto, um Incremento nasce." "Se um item não atende à Definição de Pronto, não pode ser liberado ou mesmo apresentado na Sprint Review; deve retornar ao Product Backlog." Se a DoD é padrão da organização, todos os Times Scrum devem segui-la como mínimo; se não for, o Time Scrum deve criar uma apropriada ao produto.
Lei seca · Meta do Produto"A Meta do Produto é o objetivo de longo prazo para o Time Scrum. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo." A Meta do Produto está no Product Backlog; o restante do backlog emerge para definir "o que" cumprirá a Meta.
Pegadinha FCC"O Incremento só pode ser entregue ao final da Sprint, na Sprint Review." Errado: múltiplos incrementos podem ser criados e entregues durante a Sprint; a Review não é gate. E a Meta da Sprint é compromisso dos Developers, mas dá flexibilidade quanto ao trabalho exato necessário para alcançá-la.
BizuQuem participa de cada evento: Planning, Review e Retrospective = Time Scrum inteiro (Review também com stakeholders). Daily = Developers. O Scrum Master garante que a Daily ocorra, mas não precisa conduzi-la. Todos os eventos são oportunidades formais de inspeção e adaptação; a Sprint é o contêiner deles.
Mudanças do Scrum Guide 2017 para 2020
| 2017 | 2020 |
|---|---|
| Papéis (roles) | Accountabilities (responsabilidades) |
| Time de Desenvolvimento (time dentro do time) | Developers; um único Time Scrum, sem sub-times |
| Auto-organizado (escolhe como fazer) | Autogerenciável (escolhe quem, o quê e como) |
| Sem Meta do Produto | Meta do Produto introduzida |
| Artefatos sem compromissos formais | Compromissos: Meta do Produto, Meta da Sprint, Definição de Pronto |
| Sprint Planning com 2 tópicos (o quê e como) | 3 tópicos: inclui o Por quê |
| Daily com 3 perguntas sugeridas | Perguntas removidas; o time escolhe a estrutura |
| Scrum Master como "líder servidor" | "Verdadeiros líderes que servem ao Time Scrum e à organização" |
| Time de Desenvolvimento de 3 a 9 pessoas | Time Scrum tipicamente de 10 ou menos |
| Linguagem mais voltada a software e mais prescritiva | Menos prescritivo; linguagem simplificada, aplicável a qualquer domínio |
BizuO Guia 2020 também diz que o Scrum Master é accountable pela eficácia do Time Scrum (novo) e que o Scrum se baseia em empirismo e pensamento lean (lean foi explicitado em 2020).
Kanban: princípios, práticas, fluxo e métricas
- Origem no Sistema Toyota (cartão de sinalização para produção puxada); no conhecimento, popularizado pelo Método Kanban (David J. Anderson).
- Sistema puxado: só se puxa novo trabalho quando há capacidade (limite de WIP), em vez de empurrar tarefas.
- Sem papéis, sem iterações obrigatórias e sem timeboxes prescritos: aplica-se sobre o processo atual.
| Princípios do Método Kanban (gestão da mudança) | Práticas gerais |
|---|---|
| 1. Comece com o que você faz agora 2. Concorde em buscar mudança evolutiva e incremental 3. Encoraje atos de liderança em todos os níveis (versões anteriores: respeite o processo, papéis e responsabilidades atuais) | 1. Visualizar o fluxo de trabalho 2. Limitar o WIP 3. Gerenciar o fluxo 4. Tornar as políticas explícitas 5. Implementar ciclos de feedback 6. Melhorar colaborativamente, evoluir experimentalmente |
MnemônicoPráticas = "VeLho GaPo FeMe": Visualizar, Limitar WIP, Gerenciar fluxo, Políticas explícitas, Feedback, Melhorar colaborativamente.
Kanban Guide (Vacanti & Coleman)Define Kanban como estratégia para otimizar o fluxo de valor por meio de um sistema puxado e visual. Três práticas: definir e visualizar o workflow; gerenciar ativamente os itens no workflow; melhorar o workflow. Quatro métricas mínimas de fluxo: WIP, Throughput, Work Item Age e Cycle Time.
| Métrica | Definição |
|---|---|
| WIP (work in progress) | Itens iniciados e ainda não terminados |
| Throughput (vazão) | Itens concluídos por unidade de tempo |
| Lead time | Do pedido do cliente (entrada no sistema) até a entrega: visão do cliente |
| Cycle time | Do início do trabalho até a conclusão: visão do time (contido no lead time) |
| Work Item Age | Tempo decorrido desde que um item ainda em andamento começou |
Lei de LittleTempo médio de ciclo = WIP médio ÷ Throughput médio. Exemplo: WIP médio de 12 itens e throughput de 4 itens/semana → cycle time médio de 3 semanas. Reduzir WIP (mantida a vazão) reduz o tempo de ciclo.
Diagrama de Fluxo Cumulativo (CFD)
- Faixas coloridas empilhadas, uma por etapa, ao longo do tempo.
- Distância vertical entre faixas = WIP naquele momento; distância horizontal = tempo aproximado de passagem (lead/cycle time).
- Faixa que se alarga = acúmulo/gargalo; linha plana na faixa "concluído" = nada sendo entregue; inclinação da última faixa = throughput.
| Scrum | Kanban | |
|---|---|---|
| Cadência | Sprints de duração fixa (até 1 mês) | Fluxo contínuo; cadências opcionais |
| Papéis | PO, Scrum Master, Developers | Nenhum obrigatório |
| Limite de trabalho | Indireto: o que cabe na Sprint | Limite de WIP explícito por coluna/estado |
| Mudanças | Evita mudar o que coloca em risco a Meta da Sprint | Podem entrar a qualquer momento, se houver capacidade |
| Métricas típicas | Velocidade, burndown/burnup | Lead/cycle time, throughput, CFD |
| Quadro | Pode ser zerado a cada Sprint | Persistente |
Pegadinha FCC"O Kanban exige iterações de duração fixa e define o papel de Kanban Master." Errado. E "aumentar o WIP reduz o lead time": errado, pela Lei de Little o efeito é o contrário. Lead time não é sinônimo de cycle time: lead é mais longo, começa no pedido.
Lean, XP e outras práticas
BizuLimite de WIP na prática: quando a coluna atinge o limite, o time para de começar e começa a terminar ("stop starting, start finishing"), ajudando a desobstruir a etapa seguinte. O limite torna gargalos visíveis.
Lean Thinking: 5 princípios (Womack e Jones)
- Valor: definido pela perspectiva do cliente.
- Fluxo de valor (value stream): mapear todas as etapas e eliminar as que não agregam valor.
- Fluxo contínuo: fazer o valor fluir sem interrupções, esperas e filas.
- Produção puxada: produzir conforme a demanda do cliente.
- Perfeição: melhoria contínua (kaizen).
Mnemônico"2V-F-2P": Valor, fluxo de Valor (mapear), Fluxo contínuo, Puxar, Perfeição. Frase: "Valorize o caminho, deixe Fluir, Puxe e Persiga a Perfeição".
Sete desperdícios
| Manufatura (Toyota / Ohno) | Software (Poppendieck) |
|---|---|
| Superprodução | Funcionalidades extras |
| Estoque | Trabalho parcialmente feito |
| Processamento excessivo / desnecessário | Reaprendizado (perda de conhecimento) |
| Transporte | Transferências (handoffs) |
| Movimentação | Troca de tarefas (task switching) |
| Espera | Atrasos |
| Defeitos | Defeitos |
MnemônicoDesperdícios da manufatura = "TIM WOOD" (sigla em inglês): Transport (transporte), Inventory (estoque), Motion (movimentação), Waiting (espera), Overproduction (superprodução), Overprocessing (processamento excessivo), Defects (defeitos). Muitos autores acrescentam um 8º: talento/intelecto não utilizado.
- Lean Software Development (Mary e Tom Poppendieck), 7 princípios: eliminar desperdícios; amplificar o aprendizado (ou construir qualidade); decidir o mais tarde possível; entregar o mais rápido possível; empoderar a equipe; construir integridade; ver o todo.
- Lean Startup (Eric Ries): ciclo Construir → Medir → Aprender; MVP = versão do produto que permite o máximo de aprendizado validado com o menor esforço; pivotar ou perseverar.
Pegadinha FCCMVP não é "a primeira versão completa com o mínimo de defeitos" nem um protótipo descartável obrigatório: é um instrumento para testar hipóteses e aprender com clientes reais com o menor esforço.
XP (Extreme Programming)
- Valores: comunicação, simplicidade, feedback, coragem e respeito.
- Práticas: programação em par, TDD (teste antes do código: vermelho → verde → refatorar), integração contínua, refatoração, pequenas entregas (releases), design simples, propriedade coletiva do código, padrões de codificação, ritmo sustentável (semana de 40 horas), cliente presente (on-site), jogo do planejamento (planning game), metáfora.
BizuXP é o método ágil com foco em práticas de engenharia (código). Scrum é framework de gestão e não prescreve práticas técnicas. Kanban é método de fluxo. Outras: FDD (desenvolvimento guiado por funcionalidades), DSDM (MoSCoW: Must, Should, Could, Won't), Crystal, BDD (comportamento em linguagem de negócio: Dado/Quando/Então).
SAFe 6.0: estrutura e papéis
- Framework para agilidade em escala (Scaled Agile, Inc.), combinando Lean, Agile e DevOps.
- Configurações: Essential (base: times + ART), Large Solution (vários ARTs/fornecedores para soluções grandes), Portfolio (Essential + gestão lean do portfólio), Full (todas).
- ART (Agile Release Train): time de times ágeis (tipicamente 50 a 125 pessoas), de longa duração, que planeja, entrega e valida junto, alinhado a um fluxo de valor.
- PI (Planning Interval, antes Program Increment): cadência de tipicamente 8 a 12 semanas, em geral várias iterações de desenvolvimento + uma iteração de Inovação e Planejamento (IP).
- PI Planning: evento presencial (ou remoto) com todo o ART, normalmente em 2 dias; gera os objetivos de PI dos times e o quadro do ART (dependências). Ao final do PI: Inspect & Adapt.
| Nível | Papel | Responsabilidade principal |
|---|---|---|
| Time | Product Owner | Conteúdo e priorização do Team Backlog; aceita histórias; representa o cliente para o time |
| Scrum Master / Team Coach | Líder servidor e coach do time; facilita eventos, remove impedimentos | |
| ART | Release Train Engineer (RTE) | Líder servidor e coach do ART: facilita eventos do trem (PI Planning, I&A), gerencia riscos e dependências, promove melhoria contínua |
| Product Management | Responsável pelo "o quê" do ART: visão, roadmap, ART Backlog (features) e sua priorização (WSJF) | |
| System Architect | Visão técnica e arquitetura do ART (arquitetura emergente + intencional) | |
| Business Owners | Pequeno grupo de stakeholders com responsabilidade principal pelo valor de negócio, governança e ROI da solução; atribuem valor de negócio aos objetivos de PI | |
| Solução grande | Solution Train Engineer, Solution Management, Solution Architect | Equivalentes do RTE, PM e Arquiteto para o Solution Train |
| Portfólio | Lean Portfolio Management, Epic Owners, Enterprise Architect | Estratégia e financiamento por fluxo de valor (Lean Budgets), Portfolio Kanban, épicos |
MnemônicoEspelho Scrum → SAFe: Scrum Master está para o time assim como o RTE está para o ART; PO está para o Team Backlog assim como Product Management está para o ART Backlog. "RTE = Rei do Trem que Educa (coach); PM = Pai do Menu (backlog do trem); BO = Bolso do Orçamento (valor e ROI)."
WSJF (Weighted Shortest Job First)
FórmulaWSJF = Custo do Atraso ÷ Tamanho (duração) do trabalho
Custo do Atraso = Valor para o usuário/negócio + Criticidade de tempo + Redução de risco e/ou habilitação de oportunidade.
Maior WSJF = fazer primeiro. Estimativas relativas (escala tipo Fibonacci).
Custo do Atraso = Valor para o usuário/negócio + Criticidade de tempo + Redução de risco e/ou habilitação de oportunidade.
Maior WSJF = fazer primeiro. Estimativas relativas (escala tipo Fibonacci).
BizuSAFe 6.0 tem 7 competências da Business Agility: Liderança Lean-Agile, Agilidade de Time e Técnica, Entrega Ágil de Produto, Entrega de Soluções Empresariais, Gestão Lean de Portfólio, Agilidade Organizacional e Cultura de Aprendizado Contínuo. São 10 princípios Lean-Agile (ex.: visão econômica; pensamento sistêmico; assumir variabilidade e preservar opções; construir incrementalmente com ciclos rápidos de aprendizado; marcos baseados em avaliação objetiva de sistemas funcionando; fazer o valor fluir sem interrupções; cadência e sincronização; motivação intrínseca; descentralizar decisões; organizar-se em torno do valor).
Pegadinha FCC"O RTE é o responsável por priorizar as features do ART." Errado: priorização do ART Backlog é do Product Management; o RTE facilita e remove impedimentos. "Os Business Owners definem as histórias dos times" também está errado: eles atribuem valor de negócio aos objetivos de PI e respondem pelo ROI.
Gestão de produto digital: visão, valor, OKR e roadmap
- Visão do produto: o futuro desejado e o porquê (inspira, orienta decisões; horizonte longo). Estratégia: como chegar lá. Meta do Produto (Scrum): objetivo de longo prazo do time.
- Valor: benefício percebido por usuários/cidadãos e pela organização (resultado, outcome), não quantidade de funcionalidades entregues (output). No setor público: valor público (serviço melhor, menos custo, mais arrecadação justa, transparência).
- Projeto x produto: projeto é temporário, com início e fim; produto tem ciclo de vida contínuo, com times estáveis evoluindo-o enquanto gera valor.
OKR (Objectives and Key Results)
| Objetivo (O) | Resultados-chave (KR) |
|---|---|
| Qualitativo, inspirador, aonde queremos chegar | Quantitativos e mensuráveis: como saberemos que chegamos |
| Ex.: "Tornar a restituição do contribuinte rápida e sem atrito" | Ex.: "Reduzir prazo médio de 60 para 20 dias"; "Elevar satisfação de 6,5 para 8,5" |
- Tipicamente 3 a 5 KRs por objetivo; ciclos curtos (frequentemente trimestrais); públicos/transparentes; combinação de alinhamento de cima para baixo e de baixo para cima.
- OKRs compromissados (espera-se 100%) x aspiracionais (ambiciosos; atingir cerca de 70% já é considerado bom). Não devem ser atrelados diretamente a remuneração/avaliação individual.
- KR é resultado, não tarefa: "lançar o app" é entrega (iniciativa); "40% dos pedidos feitos pelo app" é resultado.
Pegadinha FCC"O objetivo deve ser numérico e os resultados-chave, qualitativos." Invertido. KR também não é lista de atividades; atividades são iniciativas que movem o KR.
Roadmap
- Visão de alto nível, estratégica e flexível, de como o produto evoluirá: comunica direção e prioridades, não é cronograma detalhado de tarefas.
- Roadmap orientado a resultados (temas/problemas e objetivos) é preferível ao baseado em lista de features com datas fixas. Formato comum: Agora / Próximo / Depois (now-next-later), com mais incerteza quanto mais distante.
Discovery, Design Thinking e priorização
- Product discovery: descobrir o que vale construir antes de investir na entrega (delivery). Marty Cagan: atacar os riscos de valor (vão usar/comprar?), usabilidade (conseguem usar?), viabilidade técnica (conseguimos construir?) e viabilidade de negócio (funciona para a organização: legal, financeiro, etc.).
- Design Thinking (d.school): Empatia → Definição → Ideação → Prototipação → Teste; centrado no usuário, iterativo. Duplo Diamante (Design Council): Descobrir, Definir (problema) → Desenvolver, Entregar (solução); alterna divergência e convergência.
- Priorização: MoSCoW; matriz valor x esforço; Kano (básicos, de desempenho, de encantamento); RICE (Reach × Impact × Confidence ÷ Effort); WSJF.
- Histórias de usuário: "Como <persona>, quero <ação>, para <benefício>"; INVEST (Independente, Negociável, Valiosa, Estimável, Pequena, Testável); critérios de aceite.
MnemônicoDesign Thinking = "E-D-I-P-T": "Eu Desenho Ideias, Protótipos e Testes". Riscos de Cagan = "VUVV": Valor, Usabilidade, Viabilidade técnica, Viabilidade de negócio.
Gestão de portfólio e métricas ágeis
- Portfólio: conjunto de projetos, programas, produtos e operações gerenciados em grupo para atingir objetivos estratégicos. Gestão de portfólio = selecionar, priorizar, balancear e financiar o que fazer (fazer as coisas certas); gestão de projeto = fazer as coisas direito.
- Programa: projetos relacionados geridos de modo coordenado para obter benefícios que não se obteriam isoladamente.
- Lean Portfolio Management (SAFe): estratégia e financiamento de investimentos, operações ágeis do portfólio e governança lean. Lean budgets: financiar fluxos de valor (times estáveis), não projetos isolados; guardrails orçamentários. Portfolio Kanban para épicos: Funil → Revisão → Análise → Pronto → Implementação → Concluído. Épicos podem ter Lean Business Case e hipótese de MVP.
| Métrica | O que mostra | Cuidado |
|---|---|---|
| Velocidade | Quantidade de trabalho (ex.: pontos) concluída por Sprint; serve à previsão do próprio time | Não comparar times; não é medida de produtividade nem de valor |
| Burndown | Trabalho restante ao longo do tempo (linha desce) | Mudança de escopo fica "escondida" |
| Burnup | Trabalho concluído x linha de escopo total (sobem) | Evidencia mudança de escopo |
| Lead/cycle time, throughput, CFD | Fluxo (Kanban) | Ver seção Kanban |
| Evidence-Based Management (EBM) | 4 áreas-chave de valor: Valor Atual, Valor Não Realizado, Capacidade de Inovar, Tempo para Mercado | Guia da Scrum.org; mede resultado, não só saída |
| Métricas DORA | Frequência de deploy, lead time de mudanças, taxa de falha de mudanças, tempo de recuperação | Desempenho de entrega (DevOps) |
Pegadinha FCC"Story points medem horas de trabalho e a velocidade permite comparar a produtividade entre times." Errado: pontos são estimativa relativa de esforço/complexidade/incerteza, próprios de cada time. Planning Poker usa sequência tipo Fibonacci para estimativa relativa em consenso.
BizuO edital da P1 (Adm. Geral) também pede ciclo de vida de projetos com PMBOK x ágil: preditivo (escopo definido no início, cascata), iterativo (refina por repetições), incremental (entrega em partes), adaptativo/ágil (iterativo + incremental, escopo emergente) e híbrido. No ágil, o "triângulo" se inverte: tempo e custo fixos, escopo variável.
Teste rápido
1. Segundo o Scrum Guide 2020, os pilares do empirismo são transparência, inspeção e adaptação, e os valores são compromisso, foco, abertura, respeito e coragem.
Certo. Literal do Guia: três pilares e cinco valores.
2. Cabe ao Scrum Master ordenar os itens do Product Backlog, de modo a maximizar o valor entregue pelo Time Scrum.
Errado. Ordenar o Product Backlog e maximizar o valor do produto são accountabilities do Product Owner. O Scrum Master responde pela eficácia do Time Scrum.
3. Para uma Sprint de um mês, os timeboxes máximos são: Sprint Planning de 8 horas, Sprint Review de 4 horas e Sprint Retrospective de 3 horas; a Daily Scrum tem 15 minutos.
Certo. 8 · 4 · 3 e 15 minutos.
4. No Scrum Guide 2020, o compromisso do Incremento é a Meta da Sprint e o compromisso do Sprint Backlog é a Definição de Pronto.
Errado. Invertido: Sprint Backlog → Meta da Sprint; Incremento → Definição de Pronto; Product Backlog → Meta do Produto.
5. O refinamento do Product Backlog é um evento formal do Scrum, com timebox de até 10% da capacidade dos Developers.
Errado. No Guia 2020 o refinamento é atividade contínua, não evento, e não há timebox definido no Guia.
6. A Sprint pode ser cancelada pelo Scrum Master quando a Meta da Sprint se tornar obsoleta.
Errado. Apenas o Product Owner tem autoridade para cancelar a Sprint.
7. Pela Lei de Little, mantido constante o throughput, a redução do WIP médio tende a reduzir o tempo médio de ciclo.
Certo. Cycle time médio = WIP médio ÷ throughput médio.
8. No Diagrama de Fluxo Cumulativo, o alargamento progressivo da faixa de uma etapa indica acúmulo de trabalho nessa etapa, sinal de possível gargalo.
Certo. Distância vertical = WIP; faixa que alarga = itens entrando mais rápido do que saem.
9. Entre os princípios do Manifesto Ágil está o de que a documentação abrangente e aprovada é a medida primária de progresso.
Errado. "Software funcionando é a medida primária de progresso."
10. No SAFe 6.0, o Release Train Engineer atua como líder servidor e coach do ART, facilitando eventos como o PI Planning, enquanto o Product Management responde pelo ART Backlog.
Certo. RTE = facilitação e coaching do trem; Product Management = conteúdo e priorização das features.
11. No WSJF, o custo do atraso é dividido pelo tamanho do trabalho, e o custo do atraso considera valor de negócio, criticidade de tempo e redução de risco/habilitação de oportunidade.
Certo. WSJF = Custo do Atraso ÷ Duração (tamanho do trabalho); maior WSJF tem prioridade.
12. Em um OKR, o objetivo deve ser quantitativo e mensurável, enquanto os resultados-chave descrevem de forma qualitativa e inspiradora aonde se quer chegar.
Errado. Invertido: objetivo é qualitativo e inspirador; resultados-chave são quantitativos e mensuráveis.