Um guia para estudantes de análise de sistemas e engenharia de software darem um boa primeira olhada nas metodologias ágeis mais empregadas....
Este artigo apresenta os fundamentos das metodologias ágeis de desenvolvimento de software, com foco nos frameworks Scrum e Kanban. O conteúdo foi elaborado como material de apoio para estudantes de graduação em Engenharia de Software e Análise de Sistemas, abordando os valores e princípios do Manifesto Ágil, a estrutura de papéis, eventos e artefatos do Scrum, as práticas e princípios do Kanban, bem como exemplos práticos para facilitar a compreensão dos conceitos. Ao final, é feita uma análise comparativa entre os dois frameworks, auxiliando o estudante na escolha da abordagem mais adequada para diferentes contextos de projeto.
1 O Manifesto Ágil: contexto histórico e valores fundamentais
Até o final da década de 1990, o desenvolvimento de software era dominado por abordagens tradicionais e prescritivas, como o modelo Cascata (Waterfall), caracterizadas por extensas fases sequenciais de levantamento de requisitos, projeto, implementação e testes. Essas metodologias exigiam documentação volumosa e ofereciam pouca flexibilidade para acomodar mudanças de requisitos durante o projeto (SOMMERVILLE, 2016).
Em fevereiro de 2001, dezessete profissionais de desenvolvimento de software se reuniram em Snowbird, Utah (EUA), para discutir alternativas aos processos pesados e orientados a documentação que predominavam na indústria. Dessa reunião nasceu o Manifesto para Desenvolvimento Ágil de Software (BECK et al., 2001). O documento estabeleceu quatro valores centrais:
Os quatro valores do Manifesto Ágil
1. Indivíduos e interações acima de processos e ferramentas.
2. Software em funcionamento acima de documentação abrangente.
3. Colaboração com o cliente acima de negociação de contratos.
4. Responder a mudanças acima de seguir um plano.
Nota: o Manifesto reconhece que os itens à direita possuem valor, mas prioriza os itens à esquerda (BECK et al., 2001).
Além dos quatro valores, o Manifesto estabeleceu doze princípios que orientam a aplicação prática do pensamento ágil. Entre eles, destacam-se: a prioridade pela satisfação do cliente por meio de entregas contínuas de software funcional; a receptividade a mudanças de requisitos mesmo em estágios avançados do desenvolvimento; a entrega frequente de software em funcionamento; e a atenção contínua à excelência técnica (BECK et al., 2001).
É importante compreender que o Manifesto não propõe um framework ou metodologia específica; ele oferece um conjunto de valores e princípios filosóficos que servem de base para diversas abordagens, como Scrum, Kanban, Extreme Programming (XP), Lean Software Development e Crystal (PRESSMAN; MAXIM, 2021).
Exemplo prático — Valor 4 em ação
Uma startup de e-commerce planejou inicialmente uma funcionalidade de pagamento por boleto. Após duas semanas de desenvolvimento, pesquisas de mercado indicaram que o Pix havia se tornado o método de pagamento preferido dos usuários. Em uma abordagem tradicional, a equipe precisaria de um processo formal de controle de mudanças para alterar o escopo. Em uma equipe ágil, essa mudança foi incorporada ao próximo ciclo de trabalho, e a funcionalidade de pagamento via Pix foi entregue na Sprint seguinte — atendendo a uma necessidade real do mercado sem burocracia excessiva.
2 O framework Scrum
O Scrum é o framework ágil mais adotado no mundo, utilizado por cerca de 87% das equipes que seguem abordagens ágeis (EVERS, 2026). Criado por Ken Schwaber e Jeff Sutherland no início dos anos 1990, o Scrum é definido oficialmente pelo Scrum Guide, cuja versão mais recente foi publicada em novembro de 2020 (SCHWABER; SUTHERLAND, 2020).
O Scrum é fundamentado em três pilares do empirismo: transparência (os aspectos significativos do processo devem ser visíveis a todos os responsáveis pelo resultado), inspeção (os artefatos e o progresso devem ser inspecionados frequentemente) e adaptação (ajustes devem ser feitos assim que desvios forem identificados). Esses pilares são sustentados por cinco valores: comprometimento, coragem, foco, abertura e respeito (SCHWABER; SUTHERLAND, 2020).
A estrutura do Scrum pode ser sintetizada em uma fórmula simples, conhecida como 3-5-3: três responsabilidades, cinco eventos e três artefatos (CIRCLECI, 2024).
2.1 Responsabilidades (accountabilities) no Scrum
A partir do Scrum Guide 2020, o termo "papéis" (roles) foi substituído por "responsabilidades" (accountabilities), para enfatizar que essas designações não são cargos, mas sim conjuntos de responsabilidades que definem quem é responsável por quê dentro do time (SCHWABER; SUTHERLAND, 2020). O Scrum Team é composto por:
a) Product Owner (PO): é a pessoa responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. Gerencia o Product Backlog, definindo a prioridade dos itens e garantindo que a equipe trabalhe nas funcionalidades de maior valor para o negócio. O PO é a única pessoa com autoridade para decidir o que será construído (SCHWABER; SUTHERLAND, 2020).
b) Scrum Master (SM): atua como líder servidor do Scrum Team, sendo responsável por garantir que o Scrum seja compreendido e aplicado corretamente. Remove impedimentos, facilita os eventos e auxilia a organização a adotar práticas ágeis. Na versão 2020 do guia, o Scrum Master é descrito como um verdadeiro líder, cuja responsabilidade é assegurar o bom desempenho da equipe — de forma análoga a um capitão em uma equipe esportiva (DO ASYNC, 2022).
c) Developers (Desenvolvedores): são os profissionais responsáveis por criar qualquer aspecto de um incremento utilizável a cada Sprint. A equipe de desenvolvedores é autogerenciável e multifuncional, possuindo todas as habilidades necessárias para entregar valor a cada ciclo (SCHWABER; SUTHERLAND, 2020).
Exemplo prático — Responsabilidades no dia a dia
Considere uma equipe desenvolvendo um aplicativo de delivery de alimentos. O Product Owner (Maria), após entrevistar restaurantes parceiros, prioriza no backlog a funcionalidade de "cardápio com fotos". O Scrum Master (Carlos) percebe que a equipe está bloqueada por não ter acesso ao servidor de armazenamento de imagens e entra em contato com o setor de infraestrutura para resolver o impedimento. Os Desenvolvedores (Ana, Pedro e Lucas) dividem entre si as tarefas de criar a interface do cardápio, desenvolver a API de upload de imagens e implementar testes automatizados. Nenhum gerente externo atribuiu essas tarefas — a equipe se auto-organizou.
2.2 Os cinco eventos do Scrum
Os eventos do Scrum criam regularidade e minimizam a necessidade de reuniões não definidas no framework. Todos os eventos ocorrem dentro de uma Sprint, que é o evento-contêiner (SCHWABER; SUTHERLAND, 2020):
1. Sprint: é o ciclo de trabalho com duração fixa de até quatro semanas, no qual ideias são transformadas em valor. Uma nova Sprint começa imediatamente após a conclusão da anterior.
2. Sprint Planning (Planejamento da Sprint): evento que inicia cada Sprint, onde o Scrum Team responde a três perguntas: por que esta Sprint é valiosa? (define-se o Sprint Goal); o que pode ser feito nesta Sprint? (selecionam-se itens do Product Backlog); e como o trabalho será realizado?
3. Daily Scrum (Reunião Diária): reunião de no máximo 15 minutos em que os desenvolvedores inspecionam o progresso em direção ao Sprint Goal e planejam o trabalho das próximas 24 horas.
4. Sprint Review (Revisão da Sprint): realizada ao final da Sprint, é o momento em que o Scrum Team apresenta o incremento entregue aos stakeholders e coleta feedback para adaptar o Product Backlog.
5. Sprint Retrospective (Retrospectiva da Sprint): o time reflete sobre o que funcionou bem, o que pode melhorar e define ações concretas de melhoria para a próxima Sprint.
2.3 Artefatos e compromissos do Scrum
Os artefatos representam trabalho ou valor e são projetados para maximizar a transparência das informações-chave. Na versão 2020 do Scrum Guide, cada artefato passou a ter um compromisso (commitment) associado, que serve como referência para medir progresso (SCHWABER; SUTHERLAND, 2020):
| Artefato | Descrição | Compromisso |
|---|---|---|
| Product Backlog | Lista emergente e ordenada de tudo que é necessário para melhorar o produto. É a única fonte de trabalho do Scrum Team. | Product Goal (Meta do Produto) |
| Sprint Backlog | Conjunto de itens selecionados do Product Backlog para a Sprint atual, acrescido do plano para entregá-los e do Sprint Goal. | Sprint Goal (Meta da Sprint) |
| Incremento | Resultado concreto e utilizável do trabalho realizado na Sprint. Cada incremento é somado aos anteriores e deve atender à Definição de Pronto. | Definition of Done (Definição de Pronto) |
Fonte: elaborado pelo autor com base em Schwaber e Sutherland (2020).
Exemplo prático — Product Backlog de um sistema acadêmico
Imagine que sua equipe está desenvolvendo um sistema de gestão acadêmica. O Product Backlog poderia conter os seguintes itens, já ordenados pelo PO por prioridade:
1. Cadastro de alunos com validação de CPF [8 pontos]
2. Lançamento de notas por disciplina [5 pontos]
3. Geração de histórico escolar em PDF [13 pontos]
4. Painel de frequência com alertas [8 pontos]
5. Integração com sistema de biblioteca [21 pontos]
6. Módulo de avaliação institucional [13 pontos]
Na Sprint Planning, a equipe analisa sua velocidade média (por exemplo, 21 pontos por Sprint) e seleciona os itens 1 e 2 (totalizando 13 pontos), com uma meta de Sprint: "Permitir que a secretaria cadastre alunos e registre notas no sistema". Os 8 pontos restantes da capacidade podem ser alocados para tarefas técnicas ou refinamento.
Visualizando o fluxo Scrum
3 O framework Kanban
O Kanban é um método de gestão de trabalho originado no sistema de produção da Toyota na década de 1940 e adaptado para o desenvolvimento de software por David J. Anderson a partir de 2004 (ANDERSON, 2010). A palavra japonesa "kanban" (看板) significa "cartão visual" ou "sinalização", refletindo a essência do método: tornar o trabalho visível (WIKIPEDIA, 2025).
Diferentemente do Scrum, que trabalha em iterações de tempo fixo (Sprints), o Kanban opera em fluxo contínuo. Não existem iterações obrigatórias, papéis prescritos ou cerimônias mandatórias. O foco está na visualização do fluxo de trabalho, na limitação do trabalho em progresso (WIP) e na melhoria contínua do processo (ATLASSIAN, 2026).
3.1 Os quatro princípios fundamentais do Kanban
O método Kanban é guiado por quatro princípios fundamentais (ATLASSIAN, 2026):
1. Comece com o que você já faz: o Kanban não exige uma reformulação radical dos processos existentes. A implementação começa sobre o fluxo de trabalho atual, identificando oportunidades de melhoria sem rupturas.
2. Busque mudanças incrementais e evolutivas: em vez de grandes transformações, o Kanban encoraja pequenos ajustes contínuos baseados em dados e feedback real.
3. Respeite os processos, papéis e responsabilidades atuais: a adoção do Kanban não impõe novos cargos nem elimina responsabilidades existentes.
4. Encoraje atos de liderança em todos os níveis: a melhoria contínua não depende apenas de gestores; qualquer membro da equipe pode identificar gargalos e propor melhorias (KANBAN UNIVERSITY, 2021).
3.2 As seis práticas gerais do Kanban
O Método Kanban define seis práticas gerais para implementação (WIKIPEDIA, 2025; KANBAN UNIVERSITY, 2021):
| Prática | Descrição |
|---|---|
| Visualizar o fluxo de trabalho | Utilizar um quadro Kanban com colunas representando cada etapa do processo (ex.: "A fazer", "Em progresso", "Em revisão", "Concluído"). |
| Limitar o trabalho em progresso (WIP) | Estabelecer um número máximo de itens que podem estar simultaneamente em cada etapa, evitando sobrecarga e gargalos. |
| Gerenciar o fluxo | Monitorar métricas como lead time (tempo total), cycle time (tempo de processamento) e vazão (throughput) para identificar gargalos. |
| Tornar as políticas explícitas | Documentar e exibir as regras do processo (ex.: critérios para mover um cartão de coluna, definição de "pronto"). |
| Implementar ciclos de feedback | Realizar reuniões periódicas de revisão do fluxo, como a reunião de reabastecimento e a retrospectiva de serviço. |
| Melhorar colaborativamente, evoluir experimentalmente | Usar dados e experimentos controlados para propor e validar mudanças no processo de forma científica. |
Fonte: elaborado pelo autor com base em Anderson (2010) e Kanban University (2021).
Exemplo prático — Quadro Kanban de uma equipe de suporte
Uma equipe de suporte técnico de software utiliza um quadro Kanban físico com quatro colunas. Observe os limites de WIP nos círculos:
Repare que a coluna "Em Correção" tem WIP limite de 2, e há exatamente 2 tickets nela. Se um desenvolvedor terminasse o Ticket #40, ele puxaria (pull) o próximo item da coluna "Em Análise" — esse sistema de puxar garante que ninguém fique sobrecarregado e que gargalos sejam rapidamente identificados.
4 Comparativo entre Scrum e Kanban
Embora ambos os frameworks sejam ferramentas para aplicar os princípios ágeis, possuem diferenças significativas em estrutura e filosofia. A tabela a seguir sintetiza as principais distinções (PRESSMAN; MAXIM, 2021; ATLASSIAN, 2026):
| Critério | Scrum | Kanban |
|---|---|---|
| Cadência | Sprints de duração fixa (1-4 semanas) | Fluxo contínuo, sem iterações obrigatórias |
| Responsabilidades | Product Owner, Scrum Master, Developers | Nenhum papel prescrito |
| Artefatos | Product Backlog, Sprint Backlog, Incremento | Quadro Kanban com visualização do fluxo |
| Eventos formais | 5 eventos obrigatórios | Nenhum evento obrigatório (recomendados) |
| Mudanças durante o ciclo | Desaconselhadas dentro da Sprint | Permitidas a qualquer momento |
| Métrica principal | Velocidade (velocity) | Lead time e cycle time |
| Melhor cenário | Projetos com requisitos que evoluem com feedback | Operações com demanda contínua e variável |
Fonte: elaborado pelo autor com base em Pressman e Maxim (2021) e Atlassian (2026).
5 Quando usar cada framework?
A escolha entre Scrum e Kanban depende do contexto do projeto e da natureza do trabalho da equipe. Scrum tende a ser mais adequado quando os requisitos evoluem a partir do feedback dos usuários, quando o trabalho pode ser dividido em entregas incrementais e quando a equipe consegue se comprometer com metas de curto prazo. Kanban é mais indicado quando a demanda é contínua e imprevisível, como em equipes de suporte, manutenção e operações (EVERS, 2026).
Vale destacar que a combinação de elementos dos dois frameworks é possível e bastante comum na prática. A abordagem Scrumban, por exemplo, aplica limites de WIP do Kanban dentro da estrutura de Sprints do Scrum, oferecendo o melhor dos dois mundos (WIKIPEDIA, 2025).
Exemplo prático — Escolhendo o framework
Cenário A — Scrum: uma equipe de 5 pessoas está desenvolvendo um novo aplicativo de saúde. O Product Owner é um médico que dará feedback a cada duas semanas sobre as funcionalidades entregues. Sprints de duas semanas são ideais para obter validação frequente.
Cenário B — Kanban: uma equipe de DevOps recebe chamados de incidentes que chegam de forma imprevisível. Não faz sentido planejar Sprints porque a demanda é contínua e emergencial. Um quadro Kanban com WIP limits permite que a equipe priorize e trate incidentes sem sobrecarga.
Cenário C — Scrumban: uma equipe mista, que desenvolve novas funcionalidades e também mantém o sistema em produção, pode usar Sprints para o desenvolvimento e colunas Kanban com WIP limits para gerenciar os chamados de manutenção que surgem durante a Sprint.
6 Considerações finais
As metodologias ágeis representaram uma mudança de paradigma no desenvolvimento de software, deslocando o foco de processos rígidos e documentação exaustiva para a entrega contínua de valor, a colaboração e a adaptabilidade. O Scrum, com sua estrutura de responsabilidades, eventos e artefatos bem definidos, oferece um framework robusto para equipes que precisam de cadência e cerimônias claras. O Kanban, por sua vez, proporciona flexibilidade máxima ao operar em fluxo contínuo, sendo ideal para cenários de demanda variável.
Para o estudante de graduação em Engenharia de Software ou Análise de Sistemas, compreender essas abordagens não é apenas um exercício teórico: é uma competência prática essencial para o mercado de trabalho. A recomendação é que, além de estudar os conceitos, os estudantes busquem vivenciar esses frameworks em projetos acadêmicos ou pessoais, aplicando Sprints em trabalhos de disciplina ou utilizando quadros Kanban para gerenciar suas atividades de estudo.
Referências
ANDERSON, David J. Kanban: successful evolutionary change for your technology business. Sequim: Blue Hole Press, 2010.
ATLASSIAN. What is Kanban in Project Management? 2026. Disponível em: https://www.atlassian.com/agile/kanban. Acesso em: 29 mar. 2026.
ATLASSIAN. 4 Kanban Principles. 2026. Disponível em: https://www.atlassian.com/agile/project-management/kanban-principles. Acesso em: 29 mar. 2026.
BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponível em: https://agilemanifesto.org/. Acesso em: 29 mar. 2026.
CIRCLECI. What is Scrum? 2024. Disponível em: https://circleci.com/blog/scrum/. Acesso em: 29 mar. 2026.
EVERS, Bob. Scrum Framework Guide. Deckary, 2026. Disponível em: https://deckary.com/blog/scrum-framework-guide. Acesso em: 29 mar. 2026.
DO ASYNC. 12 Main Changes Made in the Scrum Latest Guide 2020. 2022. Disponível em: https://doasync.com/blog/12-main-changes-in-scrum-latest-guide-2020/. Acesso em: 29 mar. 2026.
KANBAN UNIVERSITY. The Official Guide to The Kanban Method. 2021. Disponível em: https://kanban.university/kanban-guide/. Acesso em: 29 mar. 2026.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.
SCHWABER, Ken; SUTHERLAND, Jeff. The Scrum Guide: the definitive guide to Scrum: the rules of the game. 2020. Disponível em: https://scrumguides.org/scrum-guide.html. Acesso em: 29 mar. 2026.
SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson Education do Brasil, 2016.
WIKIPEDIA. Kanban (development). 2025. Disponível em: https://en.wikipedia.org/wiki/Kanban_(development). Acesso em: 29 mar. 2026.
Fonte: Visto no Brasil Acadêmico
Comentários