Metodologias Ágeis no Setor Público: Scrum, Kanban e Lean O Manifesto Ágil e a Mudança de Paradigma 1.1. Contexto Histórico Em fevereiro de 2001, dezessete profissionais de desenvolvimento de software — entre eles Jeff Sutherland e Ken Schwaber, criadores do Scrum, e outros metodologistas como Kent Beck, Martin Fowler e Alistair Cockburn — reuniram-se em Snowbird, Utah, nos Estados Unidos, para discutir alternativas aos modelos tradicionais de gestão de projetos. O modelo dominante à época era o cascata (waterfall), caracterizado por fases sequenciais rígidas (análise, projeto, implementação, teste, implantação), cada uma gerando documentação volumosa e com quase nenhuma flexibilidade para mudanças após a aprovação da etapa anterior. Dessa reunião nasceu o Manifesto para o Desenvolvimento Ágil de Software, documento fundacional que inaugurou uma nova filosofia de trabalho, centrada em entregas rápidas, colaboração intensa e adaptação contínua a requisitos mutáveis. Atenção para concurso: A reunião ocorreu em fevereiro de 2001, em Snowbird, Utah (EUA), com 17 signatários. Sutherland e Schwaber já eram co-autores do Scrum e integraram esse grupo. 1.2. Os Quatro Valores do Manifesto Ágil O Manifesto Ágil estabelece quatro pares de valores. A expressão "mais que" indica que os itens da direita também têm importância, mas os da esquerda recebem prioridade: 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. No contexto do setor público, esses valores se traduzem: o foco recai sobre a comunicação direta entre a equipe e os agentes públicos que representam o cidadão; sobre a entrega incremental de políticas ou serviços digitais que gerem valor perceptível; sobre a cocriação com a sociedade em vez de especificações fechadas em editais; e sobre a capacidade de ajustar a rota diante de mudanças legislativas ou de novas evidências. 1.3. Os Doze Princípios do Manifesto Ágil Os princípios detalham como operacionalizar os valores. São doze ao total: Nossa maior prioridade é satisfazer o cliente por meio da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando à vantagem competitiva do cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário, e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é a conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à 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 se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. Atenção para concurso: O princípio 11 fala em "equipes auto-organizáveis", linguagem do Manifesto de 2001. O Scrum Guide 2020, posterior, substituiu "auto-organizado" por "auto-gerenciado" especificamente para o Time Scrum (ver seção 2). 1.4. Contraste com o Modelo Cascata (Waterfall) | Modelo Cascata | Modelo Ágil | |---|---| | Fases sequenciais estanques | Ciclos iterativos e incrementais | | Planejamento detalhado no início | Planejamento contínuo e adaptativo | | Mudanças são custosas e evitadas | Mudanças são bem-vindas e esperadas | | Documentação extensa como garantia | Software funcionando como medida primária | | Cliente participa predominantemente no início e no final | Cliente envolvido diariamente | | Entrega única ao final do projeto | Entregas frequentes de valor | Scrum: O Framework Empírico de Controle de Processos O Scrum foi desenvolvido por Jeff Sutherland (1993) e Ken Schwaber de forma independente, mas convergente. A inspiração vieu do artigo "The New New Product Development Game", de Hirotaka Takeuchi e Ikujiro Nonaka, publicado na Harvard Business Review em 1986, que descrevia como equipes multifuncionais e auto-organizadas podiam desenvolver produtos complexos com mais velocidade e flexibilidade. A primeira apresentação formal do Scrum ocorreu na conferência OOPSLA em 1995. A versão mais recente do Scrum Guide (novembro de 2020) — a única versão oficial em vigor — define o Scrum como um framework leve que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. O Scrum Guide 2020 também removeu referências exclusivas ao desenvolvimento de software, tornando o framework aplicável a qualquer domínio de trabalho complexo. Atenção para concurso: O Scrum não é uma metodologia prescritiva, mas um framework — conjunto mínimo de regras que devem ser seguidas para permitir a inspeção e adaptação empíricas. O que está além das regras do Scrum Guide fica a critério das equipes. 2.1. Pilares Empíricos do Scrum O Scrum baseia-se em três pilares que sustentam o empirismo: Transparência: O processo e o trabalho devem ser visíveis para quem realiza e para quem recebe. Decisões tomadas com base em artefatos opacos levam a desperdício e risco. Sem transparência, a inspeção é enganosa e a adaptação, ineficaz. Inspeção: Os artefatos e o progresso em direção às metas acordadas devem ser inspecionados com frequência e diligência para detectar variações indesejadas — mas sem frequência excessiva que atrapalhe o trabalho. Adaptação: Se qualquer aspecto do processo se desviar além dos limites aceitáveis, o processo ou o material produzido deve ser ajustado. Quanto mais cedo o ajuste, menor o desperdício. 2.2. Valores do Scrum A adesão aos cinco valores é essencial para a efetividade do framework: | Valor | Descrição | |---|---| | Compromisso (Commitment) | O Time Scrum se compromete a atingir seus objetivos e a apoiar uns aos outros. | | Coragem (Courage) | Os membros do Time têm coragem de fazer a coisa certa e trabalhar em problemas difíceis. | | Foco (Focus) | O foco principal é o trabalho da Sprint e o progresso em direção às metas. | | Abertura (Openness) | O Time Scrum e seus stakeholders são abertos quanto ao trabalho e aos desafios. | | Respeito (Respect) | Os membros do Time respeitam-se mutuamente como pessoas capazes e independentes. | 2.3. O Time Scrum (Scrum Team) O Time Scrum é auto-gerenciado (self-managing) e multifuncional (cross-functional). A mudança do termo "auto-organizado" (Scrum Guide 2017) para "auto-gerenciado" (Scrum Guide 2020) reforça que o time escolhe internamente quem faz o quê, como e quando — sem que essa escolha dependa de um gerente externo. O Time Scrum é composto por três responsabilidades (o Scrum Guide 2020 substituiu o termo "papéis" por "responsabilidades"/accountabilities): Atenção para concurso: O Scrum Guide 2020 também substituiu o termo "Time de Desenvolvimento" por simplesmente "Developers", abrangendo qualquer profissional que produza o incremento, independentemente da área técnica. 2.3.1. Product Owner (PO) Responsável por maximizar o valor do produto resultante do trabalho do Time Scrum. É a única pessoa que gerencia o Product Backlog, cabendo-lhe: Declarar claramente os itens do Product Backlog; Ordená-los para melhor alcançar as metas; Garantir que o Product Backlog seja transparente, visível e compreendido; Garantir que o Time Scrum compreenda os itens do Product Backlog ao nível necessário. O PO é o elo entre o Time e os stakeholders, mas precisa ter autoridade real para tomar decisões — não pode ser um "comitê" ou intermediário sem poder decisório. Quando o PO não tem essa autoridade, o Scrum fica inoperante. 2.3.2. Scrum Master (SM) É um líder servidor (servant leader), responsável por estabelecer o Scrum conforme definido no Scrum Guide. Suas atribuições incluem: Ajudar o Time Scrum e a organização a compreenderem a teoria e a prática do Scrum; Remover impedimentos ao progresso do Time; Facilitar os eventos Scrum garantindo que sejam positivos, produtivos e dentro do timebox; Proteger a equipe de interferências externas; Atuar como coach para o PO, os Developers e a organização. O Scrum Master não é um gerente de projetos. Não atribui tarefas, não controla entregas individualmente nem tem autoridade sobre os Developers. 2.3.3. Developers Profissionais que realizam o trabalho de entregar um Incremento potencialmente utilizável a cada Sprint. São responsáveis por: Criar o plano para a Sprint (Sprint Backlog); Garantir a qualidade do Incremento, aderindo à Definição de Pronto; Adaptar o plano de trabalho diariamente em direção à Sprint Goal; Responsabilizar-se mutuamente como profissionais. Tamanho do Time Scrum: O Scrum Guide 2020 recomenda que o Time Scrum tenha, em geral, 10 pessoas ou menos (incluindo PO e SM). Times menores comunicam-se melhor e são mais produtivos; times maiores devem ser reorganizados em múltiplos Times Scrum coesos, alinhados ao mesmo produto. 2.4. Eventos do Scrum Todos os eventos são timeboxed — têm duração máxima definida. O timebox cria regularidade e evita desperdício de tempo em reuniões sem foco. 2.4.1. Sprint É o coração do Scrum — um período de tempo fixo de até um mês (usualmente de duas semanas) durante o qual um Incremento "Pronto" é criado. Cada Sprint começa imediatamente após a conclusão da anterior. Características da Sprint: Não há mudanças que coloquem em risco a Sprint Goal; A qualidade não diminui; O Product Backlog pode ser refinado conforme necessário; O escopo pode ser esclarecido e renegociado com o PO conforme se aprende mais. Somente o PO tem autoridade para cancelar a Sprint, o que deve ocorrer apenas se a Sprint Goal se tornar obsoleta. 2.4.2. Sprint Planning Realizada no início de cada Sprint para planejar o trabalho. A Sprint Planning aborda três tópicos: Por que esta Sprint é valiosa? — O PO propõe como o produto pode aumentar seu valor e utilidade. O Time define a Sprint Goal. O que pode ser feito nesta Sprint? — Os Developers selecionam itens do Product Backlog para incluir no Sprint Backlog. Como o trabalho será realizado? — Os Developers decompõem os itens em tarefas menores (de no máximo um dia de trabalho). Timebox: 8 horas para Sprint de um mês; proporcionalmente menor para Sprints mais curtas. 2.4.3. Daily Scrum Reunião diária de 15 minutos exclusiva dos Developers para inspecionar o progresso em direção à Sprint Goal e adaptar o plano de trabalho para as próximas 24 horas. Atenção para concurso: O Scrum Guide 2020 removeu as três perguntas fixas da Daily Scrum (o que fiz ontem, o que farei hoje, quais impedimentos). A estrutura é livre — qualquer técnica que permita inspecionar o progresso e identificar impedimentos é válida. Não é uma reunião de status para o SM ou PO. 2.4.4. Sprint Review Realizada ao final da Sprint para inspecionar o Incremento produzido e coletar feedback dos stakeholders. O Time Scrum e os stakeholders discutem o que foi feito, o que mudou no ambiente e o que deve ser feito a seguir. O Product Backlog pode ser ajustado com base nessa conversa. Timebox: 4 horas para Sprint de um mês. A Sprint Review não é uma cerimônia de aprovação — é uma sessão de trabalho colaborativo para coleta de feedback e adaptação. 2.4.5. Sprint Retrospective O último evento da Sprint, focado em como o Time Scrum pode melhorar seu processo de trabalho. Inspecionam-se indivíduos, interações, processos, ferramentas e Definição de Pronto. As melhorias identificadas podem ser adicionadas ao próximo Sprint Backlog. Timebox: 3 horas para Sprint de um mês. 2.5. Artefatos e Compromissos do Scrum Cada artefato contém um compromisso associado que fornece transparência e foco: | Artefato | Compromisso | |---|---| | Product Backlog | Meta do Produto (Product Goal) | | Sprint Backlog | Meta da Sprint (Sprint Goal) | | Incremento | Definição de Pronto (Definition of Done) | 2.5.1. Product Backlog e Meta do Produto Lista ordenada de tudo o que se sabe ser necessário para o produto. É a única fonte de requisitos para quaisquer mudanças. Os itens mais prioritários são geralmente mais detalhados; os de menor prioridade, mais abstratos. A Meta do Produto (Product Goal) descreve o estado futuro desejado do produto, servindo de alvo de longo prazo para o Time Scrum. Cada Sprint deve aproximar o produto da Meta do Produto. O Time Scrum persegue uma Meta do Produto por vez. Product Backlog Refinement (Refinamento): Atividade contínua pela qual o PO e os Developers detalham, estimam e ordenam os itens do Product Backlog. Não é um evento formal do Scrum, mas uma prática recorrente que não deve consumir mais de 10% da capacidade dos Developers. Conceito adicional — Definition of Ready (DoR): Embora não seja parte formal do Scrum Guide, muitos times adotam a Definição de Pronto para Entrar na Sprint (Definition of Ready) — critérios que um item do Product Backlog deve satisfazer antes de ser selecionado na Sprint Planning (ex.: critérios de aceitação definidos, estimativa realizada, dependências identificadas). 2.5.2. Sprint Backlog e Meta da Sprint Conjunto de itens do Product Backlog selecionados para a Sprint, mais o plano de entrega elaborado pelos Developers. A Meta da Sprint (Sprint Goal) é o objetivo único da Sprint — mesmo que o escopo de itens seja ajustado, a meta permanece. 2.5.3. Incremento e Definição de Pronto O Incremento é a soma de todos os itens do Product Backlog concluídos durante a Sprint e todas as Sprints anteriores, que atende à Definição de Pronto (Definition of Done — DoD). A DoD é um acordo formal — definido pela organização ou pelo Time Scrum quando não existe padrão organizacional — que descreve as condições que um incremento deve satisfazer para ser considerado concluído. Sem uma DoD clara, não há transparência sobre o progresso real e surgem "dívidas técnicas" ocultas. 2.6. Métricas Scrum Embora o Scrum Guide não prescreva métricas específicas, as mais utilizadas são: *Velocidade (Velocity): Quantidade de trabalho (em pontos de história ou outras unidades) que o Time conclui por Sprint. Usada para previsão de capacidade futura — não para comparação entre times. Burndown Chart: Gráfico que mostra o trabalho restante ao longo do tempo na Sprint (ou no projeto). A linha desce conforme os itens são concluídos. Burnup Chart: Exibe o trabalho total e o trabalho concluído. Facilita a visualização de mudanças no escopo (o teto sobe quando itens são adicionados). Kanban: Fluxo Contínuo e Gestão Visual do Trabalho O Kanban surgiu como um sistema de sinalização visual no Sistema Toyota de Produção (TPS) — a palavra japonesa kanban (看板) significa "cartão" ou "sinal visual". No desenvolvimento de software e gestão do conhecimento, foi adaptado e sistematizado por David J. Anderson a partir de 2004, cujas ideias foram publicadas no livro Kanban: Successful Evolutionary Change for Your Technology Business (2010). Diferentemente do Scrum, que opera em Sprints com iterações fixas, o Kanban é baseado em fluxo contínuo: o trabalho é puxado (pull system) assim que há capacidade disponível, sem compromisso com iterações predeterminadas. Atenção para concurso: O Kanban não prescreve papéis, eventos nem timeboxes fixos. Ele respeita os papéis e processos existentes na organização, propondo uma evolução incremental. Essa é a principal distinção estrutural em relação ao Scrum. 3.1. Princípios Gerais do Método Kanban Princípios de gestão da mudança: Comece com o que você faz agora: Respeita o processo, as responsabilidades e os títulos existentes. Acorde em buscar mudanças evolucionárias e incrementais: Propõe pequenas melhorias graduais, reduzindo resistência. Incentive atos de liderança em todos os níveis: Todos são responsáveis pela melhoria contínua. Princípios de entrega de serviços: Entenda e foque nas necessidades e expectativas dos clientes. Gerencie o trabalho; deixe as pessoas se auto-organizarem em torno dele. Evolua políticas para melhorar os resultados para clientes e organização. 3.2. Práticas Centrais do Método Kanban As seis práticas nucleares do Método Kanban são: Visualizar o fluxo de trabalho (workflow): Utiliza-se um quadro Kanban — físico ou digital — com colunas representando os estágios do processo (ex.: Backlog, Análise, Desenvolvimento, Teste, Feito). Cartões representam unidades de trabalho. A visualização expõe o estado real do trabalho e torna os problemas visíveis. Limitar o Trabalho em Progresso (WIP — Work in Progress): É a prática central e mais poderosa do Kanban. Cada coluna do quadro tem um número máximo de itens que pode conter simultaneamente. Limitar o WIP força a conclusão de itens antes de iniciar novos, o que: Reduz o tempo de ciclo (cycle time); Diminui o desperdício de troca de contexto; Expõe gargalos (bottlenecks) no fluxo. Lei de Little: O lead time médio é igual ao número médio de itens em progresso dividido pelo throughput médio. Reduzir o WIP reduz diretamente o lead time. Gerenciar o fluxo: Medir métricas de fluxo para identificar e eliminar gargalos. Tornar políticas explícitas: Regras como critérios de entrada e saída de colunas, definição de WIP e critérios de aceitação devem ser visíveis e documentadas — não podem ficar na cabeça das pessoas. Implementar ciclos de feedback (Kanban Cadences): O Método Kanban define sete cadências de reuniões de feedback com diferentes propósitos e frequências, desde a reunião de estratégia (trimestral) até a revisão de entrega (por item). As mais comuns são: Standup Meeting diário (equivalente à Daily Scrum), Replenishment Meeting (priorização do backlog) e Retrospective. Melhorar colaborativamente, evoluir experimentalmente: Usar o método científico (hipótese → experimento → mensuração → aprendizado) para implementar melhorias — alinhado ao conceito Lean de Kaizen. 3.3. Métricas Kanban | Métrica | Descrição | |---|---| | Lead Time | Tempo total desde que o pedido é recebido (ou o item entra no backlog) até sua entrega. Reflete a perspectiva do cliente. | | Cycle Time | Tempo que um item passa efetivamente em trabalho (da entrada em "Em Progresso" até a conclusão). Reflete a velocidade interna. | | Throughput | Quantidade de itens concluídos por unidade de tempo. Reflete a capacidade produtiva. | | WIP | Quantidade de itens em trabalho simultâneo em um dado momento. | | CFD (Cumulative Flow Diagram) | Gráfico de área que exibe, ao longo do tempo, a quantidade de itens em cada estágio. Permite visualizar tendências de gargalo, acúmulo e variação do fluxo. | 3.4. Classe de Serviço e SLA Itens de trabalho podem ser classificados em classes de serviço (ex.: urgente, data fixa, padrão, intangível), cada uma com políticas específicas de tratamento e expectativas de tempo de espera (Service Level Expectation — SLE ou SLA). No setor público, a classe de serviço data fixa pode representar um prazo legal improrrogável. 3.5. Scrumban O Scrumban é uma abordagem híbrida que combina elementos do Scrum e do Kanban, frequentemente adotada por times em transição ou com fluxos de trabalho mais imprevisíveis. Características comuns: Mantém a estrutura de papéis do Scrum (PO, SM, Developers); Adota limites de WIP explícitos do Kanban; Pode ou não usar Sprints fixas; Usa reuniões on demand para planejamento, em vez de Sprint Planning em ciclos fixos. Lean: A Eliminação do Desperdício e a Criação de Valor O Lean é uma filosofia de gestão originada no Sistema Toyota de Produção (TPS), desenvolvido por Taiichi Ohno, Shigeo Shingo e Eiji Toyoda no Japão após a Segunda Guerra Mundial. O Lean busca maximizar o valor para o cliente eliminando sistematicamente os desperdícios — muda (無駄), em japonês. O livro The Machine That Changed the World (Womack, Jones e Roos, 1990) popularizou o TPS no Ocidente sob o nome Lean. Posteriormente, Lean Thinking (Womack e Jones, 1996) sistematizou os cinco princípios Lean. No desenvolvimento de software, Mary Poppendieck e Tom Poppendieck adaptaram o Lean em Lean Software Development (2003). 4.1. Os Cinco Princípios Lean Valor: Definido pelo cliente (cidadão). Apenas as atividades pelas quais o cliente reconhece e estaria disposto a pagar agregam valor. Fluxo de Valor (Value Stream): Mapear todas as etapas que criam (ou não) valor, desde a necessidade do cidadão até a entrega do serviço. O Mapeamento do Fluxo de Valor (Value Stream Mapping — VSM) é a ferramenta central. Fluxo Contínuo: Fazer o trabalho fluir sem interrupções, filas ou retrabalhos. Reduzir o tamanho dos lotes. Produção Puxada (Pull): Iniciar o trabalho apenas quando houver demanda real, conforme a capacidade disponível — não produzir para estoque. Perfeição (Kaizen): Busca contínua pela melhoria, envolvendo todos os colaboradores na eliminação de desperdícios. O Kaizen (改善, "mudança para melhor") pode ser incremental (Kaizen cotidiano) ou radical (Kaikaku). 4.2. Os Oito Desperdícios (Muda) Taiichi Ohno identificou originalmente sete desperdícios; posteriormente, um oitavo foi acrescentado: | # | Desperdício | Exemplo no Setor Público | |---|---|---| | 1 | Superprodução | Relatórios gerados periodicamente que ninguém lê; documentos produzidos sem demanda real. | | 2 | Espera | Processos parados aguardando assinatura, aprovação ou informação de outro órgão. | | 3 | Transporte | Circulação desnecessária de documentos físicos entre setores ou unidades. | | 4 | Processamento Excessivo | Tripla conferência manual de um procedimento que poderia ser automatizado; exigência de cópias autenticadas quando a lei dispensa. | | 5 | Estoque | Acúmulo de processos não analisados, formulários obsoletos, demandas represadas. | | 6 | Movimentação | Deslocamento desnecessário de servidores entre andares ou unidades para obter assinaturas. | | 7 | Defeitos/Retrabalho | Processos devolvidos por inconsistências; documentos com erro exigindo reconfecção. | | 8 | Subutilização do Potencial Humano | Não aproveitar o conhecimento, a criatividade e as habilidades dos servidores por falta de engajamento ou autonomia. | 4.3. Ferramentas Lean Relevantes para Concursos 5 Porquês (5 Whys): Técnica de análise de causa raiz desenvolvida por Taiichi Ohno. Consiste em perguntar "por quê?" sucessivamente (geralmente cinco vezes) até identificar a causa raiz de um problema. Exemplo no setor público: um processo é devolvido repetidamente → "por quê?" → porque falta documento → "por quê?" → porque o sistema não orienta o cidadão → causa raiz: falha no design do formulário digital. Diagrama de Ishikawa (Espinha de Peixe): Ferramenta de análise de causa raiz que organiza as possíveis causas de um problema em categorias (Método, Máquina, Mão de Obra, Material, Medição, Meio Ambiente). Complementar aos 5 Porquês. Mapeamento do Fluxo de Valor (VSM): Representação visual de todas as etapas de um processo, distinguindo etapas que agregam valor (value-added) das que não agregam (non-value-added). Permite calcular a Eficiência do Processo = Tempo de Valor Agregado / Lead Time Total. Ciclo PDCA (Plan-Do-Check-Act): Método científico de melhoria contínua associado a W. Edwards Deming e ao Lean. Amplamente exigido em concursos: Plan (Planejar): identificar o problema e elaborar plano de ação; Do (Fazer): executar o plano em pequena escala; Check (Verificar): medir os resultados e compará-los com o esperado; Act (Agir): padronizar o que funcionou ou reiniciar o ciclo com novos dados. 4.4. Lean Government Lean Government é a aplicação dos princípios Lean à administração pública. Exemplos incluem: eliminar exigências documentais redundantes, simplificar formulários, reduzir o tempo de tramitação de processos, automatizar etapas que não exigem julgamento humano e redesenhar fluxos a partir da perspectiva da jornada do cidadão. No Brasil, o arcabouço normativo de desburocratização dialoga com os princípios Lean: Lei nº 13.726/2018: Racionaliza atos e procedimentos administrativos dos Poderes da União, dos Estados, do Distrito Federal e dos Municípios. Institui o Selo de Desburocratização e Simplificação, dispensa reconhecimento de firma e autenticação de cópias em vários casos, e cria mecanismos de simplificação análogos à eliminação de desperdícios Lean. Decreto nº 9.094/2017: Dispõe sobre a simplificação do atendimento prestado aos usuários dos serviços públicos; ratifica a dispensa de reconhecimento de firma e autenticação; institui a Carta de Serviços ao Usuário e o formulário Simplifique!, pelo qual qualquer cidadão pode solicitar a simplificação de um serviço público que não observe as diretrizes do decreto. Lei nº 13.460/2017 (Código de Defesa do Usuário do Serviço Público): Estabelece direitos dos usuários dos serviços públicos, deveres das administrações e mecanismos de participação e controle, incluindo avaliação de satisfação. Regulamentada pelo Decreto nº 9.094/2017. OKR — Objectives and Key Results OKR é uma abordagem de definição e acompanhamento de metas, criada por Andy Grove na Intel (onde eram chamados de iMBOs — Intel Management by Objectives) na década de 1970, com inspiração no MBO (Management by Objectives) de Peter Drucker. O modelo foi levado ao Google em 1999 por John Doerr, que aprendeu com Grove na Intel, e a partir daí se difundiu para organizações de todo o mundo. O livro de Doerr, Measure What Matters (2018), é a referência principal sobre o tema. Embora não seja uma metodologia ágil por si, os OKRs complementam frameworks como Scrum e Kanban, fornecendo alinhamento estratégico e transparência em todos os níveis da organização. 5.1. Estrutura dos OKRs Objective (Objetivo): Descrição qualitativa, aspiracional e inspiradora do que se deseja alcançar. Deve ser: Significativo, concreto e orientado à ação; Capaz de motivar e engajar a equipe; Limitado a poucos por ciclo (geralmente 3 a 5 por nível organizacional). Exemplo no setor público: "Tornar o atendimento ao cidadão o mais simples e acessível do país." Key Results (Resultados-Chave): Conjunto de 3 a 5 métricas quantitativas que medem o progresso em direção ao objetivo. Cada Key Result deve ser: Mensurável e específico; Com prazo definido; Desafiador, mas alcançável (a zona recomendada por Grove era de 60–70% de taxa de alcance; metas 100% alcançadas são consideradas pouco ambiciosas). Exemplo: "Reduzir o tempo médio de espera em filas presenciais de 45 para 15 minutos até dezembro." / "Aumentar a taxa de serviços 100% digitais de 30% para 70% até o final do trimestre." 5.2. Características dos OKRs Ciclos curtos: Trimestrais (operacionais) e anuais (estratégicos), com revisão frequente do progresso. Transparência total: Todos na organização podem ver os OKRs de todos — do nível estratégico ao operacional. Alinhamento em cascata: Equipes definem seus próprios OKRs em cascata a partir dos objetivos estratégicos, garantindo coerência vertical e horizontal. Separação de performance e remuneração: Na concepção original, OKRs não devem ser vinculados diretamente à avaliação de desempenho individual, para não induzir conservadorismo nas metas. Distinção de Tarefas (Initiatives): Key Results medem resultados, não atividades. As atividades que levam ao resultado são chamadas de "iniciativas" e não fazem parte dos OKRs em si. 5.3. OKRs no Setor Público Brasileiro O Governo Federal brasileiro adotou OKRs como parte da Estratégia de Governo Digital e em programas como o Conecta Gov e a transformação digital de serviços. Alguns órgãos, como o Serpro e a Dataprev, utilizam OKRs integrados a metodologias ágeis em suas equipes de tecnologia. Design Thinking no Setor Público O Design Thinking é uma abordagem de inovação centrada no ser humano, que utiliza a sensibilidade e os métodos do designer para criar soluções que atendam às necessidades reais dos usuários. Popularizado pela consultoria IDEO (Tim Brown) e pela Stanford d.school (Hasso Plattner Institute of Design), é estruturado em fases iterativas e não lineares. 6.1. As Cinco Fases do Design Thinking Empatia (Empathize): Mergulhar no contexto do usuário, compreender suas dores, necessidades e desejos por meio de observação, entrevistas e imersão etnográfica. No setor público, isso envolve compreender a jornada do cidadão, não apenas os requisitos do processo. Definição (Define): Sintetizar os achados da fase de empatia e definir o problema central a ser resolvido, de forma clara e focada no usuário. A ferramenta-chave é o Point of View (POV) ou declaração "Como poderíamos...?" (How Might We?). Ideação (Ideate): Gerar o maior número possível de ideias para solucionar o problema, utilizando técnicas como brainstorming, bodystorming, SCAMPER, e analogias. O julgamento é suspenso nessa fase. Prototipação (Prototype): Construir representações tangíveis e de baixo custo das ideias selecionadas — protótipos de papel, encenações (role-playing), mockups digitais. O objetivo é aprender rapidamente com o mínimo de investimento. Teste (Test): Colocar os protótipos nas mãos dos usuários reais, observando a interação, coletando feedback e iterando. O ciclo prototipação → teste pode ser repetido várias vezes antes de uma solução ser implementada. Atenção para concurso: As fases do Design Thinking são não lineares — é comum retornar à fase de empatia após os testes revelarem novas necessidades não percebidas. 6.2. Duplo Diamante (Double Diamond) Desenvolvido pelo British Design Council (2005), o modelo do Duplo Diamante estrutura o processo criativo em quatro fases dentro de dois diamantes: Diamante 1 — Problema: Descobrir (divergir: pesquisa ampla) → Definir (convergir: problema central). Diamante 2 — Solução: Desenvolver (divergir: geração de ideias e prototipagem) → Entregar (convergir: solução testada e implementada). Esse modelo é crescentemente cobrado em concursos de gestão pública e inovação. 6.3. Design Thinking no Setor Público Brasileiro Laboratórios de inovação aplicam Design Thinking para redesenhar serviços públicos e criar políticas centradas no cidadão: GNova Lab (ENAP): Laboratório pioneiro do governo federal brasileiro, resultado de parceria com o governo da Dinamarca. Parte da Diretoria de Inovação da ENAP, utiliza Design Thinking, etnografia, ciências comportamentais e análise de dados. Em 2024, lançou o LIIA (Laboratório de Inovação em Inteligência Artificial). (011).lab (Prefeitura de São Paulo / SMIT): Laboratório de inovação da Secretaria Municipal de Inovação e Tecnologia. Fundado em 2017, atua em projetos de ciclo curto com Design Thinking, ciências comportamentais e abordagens ágeis. Frameworks de Escala: SAFe, LeSS e Nexus À medida que as metodologias ágeis ganham escala em grandes organizações — com múltiplos times trabalhando no mesmo produto ou portfólio —, surgem os frameworks de escala (scaling frameworks). Eles são crescentemente cobrados em concursos de TI e gestão pública em nível avançado. 7.1. SAFe — Scaled Agile Framework O SAFe (criado por Dean Leffingwell) é o framework de escala mais amplamente adotado. Organiza os times em três ou quatro níveis: Time (Team): Times Scrum ou Kanban individuais. Programa (Program / ART — Agile Release Train): Conjunto de 5 a 12 times que planejam e entregam juntos, em ciclos de PI (Program Increment) de 8 a 12 semanas. O evento central é o PI Planning, uma reunião presencial de dois dias com todos os times. Portfólio: Alinhamento estratégico entre temas de investimento e os ARTs. Grande Solução (configuração de 4 níveis): Para sistemas ultracomplexos. 7.2. LeSS — Large-Scale Scrum O LeSS (criado por Craig Larman e Bas Vodde) estende o Scrum com mínimas adições. Mantém um único Product Backlog, um único PO e múltiplos times Scrum que trabalham em uma Sprint sincronizada e entregam um único Incremento integrado. 7.3. Nexus O Nexus foi criado por Ken Schwaber (co-criador do Scrum) e é mantido pela Scrum.org. É uma extensão do Scrum para 3 a 9 times. Adiciona um elemento central — a Nexus Integration Team — responsável por garantir que os incrementos de todos os times sejam integrados corretamente a cada Sprint. Quadro Comparativo: Scrum, Kanban e Lean | Característica | Scrum | Kanban | Lean | |---|---|---|---| | Natureza | Framework iterativo e incremental | Método de fluxo contínuo | Filosofia de gestão | | Cadência | Sprints (timeboxes fixos, 1–4 semanas) | Fluxo contínuo, sem iterações obrigatórias | Fluxo contínuo, com eventos Kaizen | | Papéis/Responsabilidades | PO, Scrum Master, Developers | Não prescreve (respeita papéis atuais) | Não prescreve; foco na cultura | | Eventos formais | Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective | Cadências (sem timebox fixo) | Eventos Kaizen; análise de VSM | | Limitação de WIP | Indireta (via Sprint Backlog e compromisso) | Explícita e central (WIP limits por coluna) | Via redução de lotes e fluxo puxado | | Métrica principal | Velocity, Burndown/Burnup | Lead Time, Cycle Time, Throughput, CFD | Eficiência do Fluxo de Valor | | Foco da melhoria | Inspeção e adaptação (processo e produto) | Otimização do fluxo; eliminação de gargalos | Eliminação de desperdícios (muda) | | Mudança organizacional | Prescritiva (regras do Scrum Guide) | Evolucionária e incremental | Cultural e sistêmica | Aplicação no Setor Público: Avanços e Limitações 9.1. Adoção por Órgãos Públicos Brasileiros A adoção de metodologias ágeis no setor público brasileiro tem crescido, impulsionada pela necessidade de maior eficiência, transformação digital e entrega de valor ao cidadão: Serpro e Dataprev: Pioneiros na adoção de Scrum e Kanban em desenvolvimento de sistemas. O Serpro opera com múltiplos times ágeis e utiliza frameworks de escala. Tribunal de Contas da União (TCU): Utiliza métodos ágeis em fiscalizações de transformação digital e orienta os jurisdicionados sobre governança ágil. Receita Federal: Adota práticas ágeis em projetos de TI e transformação de serviços (ex.: portal e-CAC). GNova Lab (ENAP): Utiliza Design Thinking, métodos ágeis e ciências comportamentais para desenvolvimento de soluções de gestão pública e capacitação de servidores. (011).lab (Prefeitura de São Paulo): Aplica Design Thinking e abordagens ágeis para redesenho de serviços municipais e capacitação de equipes internas. 9.2. Marco Normativo de Referência A Lei nº 14.133/2021 (Nova Lei de Licitações e Contratos) introduziu mecanismos que dialogam com princípios ágeis: Diálogo Competitivo (art. 32): Modalidade licitatória em que a Administração realiza diálogos com licitantes previamente selecionados para desenvolver alternativas que atendam às suas necessidades antes de definir o objeto da contratação — algo análogo a ciclos de descoberta e feedback ágeis. Aplica-se a contratações que envolvam inovação tecnológica ou técnica, ou em que as especificações técnicas não possam ser definidas com precisão suficiente. O arcabouço de desburocratização completa esse cenário: Lei nº 13.726/2018: Racionaliza atos e procedimentos administrativos em todos os Poderes e entes federativos; institui o Selo de Desburocratização e Simplificação. Decreto nº 9.094/2017: Simplificação do atendimento ao usuário dos serviços públicos; Carta de Serviços ao Usuário; formulário Simplifique! Lei nº 13.460/2017: Código de Defesa do Usuário do Serviço Público — direitos dos usuários, avaliação de satisfação e mecanismos de participação. 9.3. Desafios e Limitações A implementação de metodologias ágeis no setor público enfrenta obstáculos estruturais: Rigidez orçamentária e legal: A execução orçamentária pública segue ritos anuais (LOA, empenhos, licitações) que nem sempre se encaixam em ciclos curtos e adaptativos. Cultura de aversão ao risco e ao erro: O princípio da legalidade estrita e o controle formal tendem a preferir processos previsíveis e documentados. A cultura do erro como fracasso contradiz o princípio ágil do aprendizado por experimentação. Instabilidade das equipes: Alta rotatividade, designações temporárias e ausência de propriedade de produto dificultam a formação de times estáveis e de alta performance. Dificuldade de definir e medir "valor público": A tradução de benefícios sociais em métricas objetivas (equivalentes a KRs ou Sprint Goals) nem sempre é direta ou consensual. Contratação de software ágil: A legislação de licitações foi historicamente estruturada em torno de especificações fechadas, incompatíveis com o desenvolvimento iterativo. A IN SGD/ME nº 1/2019 (Instrução Normativa sobre contratação de soluções de TIC) e o Framework de Transformação Digital do governo federal buscam mitigar isso, mas a implementação ainda é desafiadora. Dependência de fornecedores externos: Em times de desenvolvimento terceirizados, papéis como Scrum Master e Product Owner ficam frequentemente com o fornecedor, reduzindo a capacidade interna de gestão do produto. 9.4. Boas Práticas para a Adoção Ágil no Governo Organizações internacionais como a OCDE e o BID, bem como o próprio governo federal (via EGD — Estratégia de Governo Digital), recomendam: Iniciar com projetos-piloto de menor risco antes de escalar; Investir na capacitação interna de Product Owners governamentais; Adaptar os ritos ágeis ao calendário orçamentário (ex.: planejar Sprints dentro dos ciclos de programação da LOA); Usar indicadores de valor público como proxy* de OKRs (ex.: tempo de espera do cidadão, taxa de resolução no primeiro contato, NPS de serviços públicos); Fortalecer laboratórios de inovação como espaços de experimentação segura. Síntese para Prova: Pontos Mais Cobrados | Tema | O que saber | |---|---| | Manifesto Ágil | 4 valores, 12 princípios; 17 signatários; fevereiro de 2001; Snowbird, Utah | | Scrum Guide | Versão 2020 (novembro) é a vigente; mudança de "auto-organizado" para auto-gerenciado | | Time Scrum | PO, Scrum Master, Developers; até 10 pessoas; sem sub-times nem hierarquias | | Eventos Scrum | Sprint (≤1 mês); Planning (8h); Daily (15min); Review (4h); Retrospective (3h) — todos para Sprint de 1 mês | | Artefatos e compromissos | Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Incremento → DoD | | Kanban | Fluxo contínuo; sem papéis/eventos prescritos; WIP limit é a prática central; métricas: Lead Time, Cycle Time, Throughput, CFD | | Lean | 5 princípios; 8 desperdícios (muda); PDCA; 5 Porquês; VSM; Kaizen | | OKR | Objetivo qualitativo + 3–5 Key Results quantitativos; ciclo trimestral; Andy Grove (Intel) → John Doerr (Google) | | Design Thinking | 5 fases não lineares: Empatia → Definição → Ideação → Prototipação → Teste; Double Diamond | | Legislação | Lei 14.133/2021 (art. 32 — Diálogo Competitivo); Lei 13.726/2018; Dec. 9.094/2017; Lei 13.460/2017 | | Scaling | SAFe (ART, PI Planning); LeSS (um único PO/backlog); Nexus (Nexus Integration Team, 3–9 times) | Exercícios: Qual dos seguintes princípios é um dos valores do Manifesto Ágil de 2001? No framework Scrum, qual é a função do Product Owner (PO)? Qual das opções abaixo descreve um dos princípios do Kanban? No contexto do Lean, qual é um dos 7 desperdícios clássicos identificados por Taiichi Ohno? O que caracteriza o método OKR (Objectives and Key Results)? Qual das seguintes fases faz parte do modelo de Design Thinking? Complete a frase: O Time Scrum é _____ e multifuncional, mudança terminológica que reforça que a equipe escolhe internamente quem faz o quê, como e quando. Complete a frase: A prática de limitar o _____ força a conclusão de itens antes de iniciar novos, o que reduz o tempo de ciclo e expõe gargalos no fluxo. Complete a frase: No contexto dos desperdícios da filosofia Lean aplicados ao setor público, a exigência de tripla conferência manual em um procedimento que poderia ser automatizado é classificada como um exemplo de _____. Complete a frase: No framework não linear do Design Thinking, a elaboração da declaração 'Como poderíamos...?' (How Might We?) é a ferramenta-chave utilizada de forma convergente na fase de _____. Complete a frase: A Nova Lei de Licitações introduziu o mecanismo de _____, aplicável a contratações que envolvam inovação tecnológica onde as especificações técnicas não possam ser definidas com precisão suficiente desde o início. Complete a frase: No framework de controle de processos empíricos, o compromisso associado exclusivamente ao artefato Product Backlog, que descreve o estado futuro desejado, é denominado _____. Complete a frase: Na estrutura metodológica de gestão, a meta aspiracional e qualitativa é apoiada por um conjunto reduzido de métricas de progresso estritamente _____, chamadas de Resultados-Chave. Complete a frase: O framework de escala focado em sincronização estrutural de poucos times introduz a _____, cuja responsabilidade primordial é assegurar que o trabalho das diversas equipes seja corretamente unificado a cada iteração. Complete a frase: O evento de alinhamento diário possui duração máxima fixada em quinze minutos e destina-se à participação exclusiva dos _____, visando inspecionar o progresso em direção ao objetivo de curto prazo. Complete a frase: O responsável por maximizar o valor da solução tecnológica não deve atuar como um _____, mas sim deter autoridade individual e inquestionável para a ordenação dos requisitos e tomadas de decisão.