Seu navegador não oferece leitura em voz alta. Você pode ler o guia normalmente.
Um modelo de ciclo de vida organiza as atividades do desenvolvimento de software: levantar requisitos, projetar, programar, testar, entregar e manter. A diferença entre eles está em como essas atividades se encadeiam e em quanto o plano pode mudar no caminho. Provas de TI cobram a identificação de cada modelo por suas características e o vocabulário de Scrum. Este guia trata de conceitos; não há cálculos ou códigos a executar.
Modelos tradicionais
Cascata (waterfall)
As fases ocorrem em sequência: requisitos, projeto, implementação, testes, implantação e manutenção. Cada fase só começa quando a anterior termina e é aprovada, com documentação extensa.
- Quando funciona: requisitos estáveis e bem conhecidos; escopo fechado.
- Limitação: o cliente só vê o software no final; mudanças tardias custam caro; defeitos de requisito aparecem tarde.
Incremental e iterativo
No incremental, o produto é entregue em partes (incrementos) que acrescentam funcionalidade. No iterativo, repete-se o ciclo de trabalho refinando o que já existe. Na prática, os dois se combinam: cada iteração entrega um incremento. Vantagem: valor entregue cedo e feedback do cliente ao longo do projeto.
Prototipação
Constrói-se um protótipo para esclarecer requisitos com o usuário. Pode ser descartável (jogado fora após validar a ideia) ou evolutivo (vira o produto final). Risco: o cliente tomar o protótipo por produto pronto.
Espiral
Modelo dirigido por risco. Cada volta da espiral percorre quatro atividades: definir objetivos, analisar e reduzir riscos, desenvolver e validar, e planejar a próxima volta. É indicado para projetos grandes, caros e de alto risco; seu custo de gerenciamento é alto para projetos pequenos.
Processo Unificado (RUP)
Iterativo e incremental, guiado por casos de uso e centrado na arquitetura. Define quatro fases: concepção, elaboração, construção e transição. Cada fase tem uma ou mais iterações.
Resumo comparativo
| Modelo | Característica marcante | Cliente vê o produto |
|---|---|---|
| Cascata | fases sequenciais e documentadas | no fim |
| Incremental | entregas parciais | a cada incremento |
| Prototipação | esclarece requisitos | cedo, em versão experimental |
| Espiral | gestão de riscos a cada volta | a cada volta |
| RUP | fases e iterações, casos de uso | a cada iteração |
Métodos ágeis
O movimento ágil nasceu como reação a processos pesados. Seu núcleo é o Manifesto Ágil, que declara 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.
O manifesto afirma que há valor também nos itens à direita, mas que os da esquerda valem mais. Entre os princípios que acompanham o manifesto estão entregar software funcionando com frequência, aceitar mudanças de requisitos mesmo tarde, trabalho conjunto diário entre negócio e desenvolvedores, equipes auto-organizadas e reflexão periódica para ajustar o processo.
Métodos ágeis conhecidos: Scrum, Kanban, XP (Extreme Programming), entre outros.
XP em linhas gerais
O XP prioriza qualidade técnica: programação em pares, desenvolvimento orientado a testes, integração contínua, refatoração, propriedade coletiva do código, releases pequenas e cliente presente. Os valores do XP incluem comunicação, simplicidade, feedback e coragem.
Scrum
O Scrum é um arcabouço (framework) leve para gerar valor por meio de soluções adaptativas para problemas complexos. Funciona sobre três pilares empíricos: transparência, inspeção e adaptação.
Atenção ao vocabulário, que varia entre edições do Guia do Scrum: a edição mais recente fala em um único Time Scrum com três responsabilidades; edições anteriores falavam em três papéis, com o “Time de Desenvolvimento”. Descrição conforme a edição recente, que o candidato deve confirmar no edital:
| Elemento | Descrição |
|---|---|
| Product Owner | maximiza o valor do produto e gerencia o Product Backlog |
| Scrum Master | ajuda o time a entender e aplicar o Scrum e remove impedimentos; é líder a serviço do time |
| Desenvolvedores | pessoas que criam qualquer aspecto de um incremento utilizável a cada Sprint |
Eventos
| Evento | Resumo |
|---|---|
| Sprint | período de duração fixa, de no máximo um mês, que contém todos os demais eventos; não muda de duração no meio |
| Planejamento da Sprint (Sprint Planning) | define o que será feito e como; resulta na meta da Sprint |
| Reunião diária (Daily Scrum) | evento de 15 minutos para inspecionar o progresso rumo à meta da Sprint e adaptar o plano |
| Revisão da Sprint (Sprint Review) | inspeciona o resultado e discute o que fazer a seguir com os interessados |
| Retrospectiva da Sprint | o time inspeciona a si mesmo e planeja melhorias de processo |
Artefatos e compromissos
| Artefato | Compromisso associado |
|---|---|
| Product Backlog (lista ordenada do que o produto precisa) | Meta do Produto |
| Sprint Backlog (itens da Sprint mais o plano) | Meta da Sprint |
| Incremento (passo concreto rumo à meta do produto) | Definição de Pronto |
A Definição de Pronto (Definition of Done) é o conjunto de critérios de qualidade que um item precisa atender para ser considerado parte do incremento. Um incremento só existe se estiver “pronto”.
Pegadinhas clássicas: o Scrum Master não é gerente do projeto que distribui tarefas; o Product Owner é uma pessoa, não um comitê; a Sprint pode ser cancelada apenas pelo Product Owner; e a Daily Scrum pertence aos desenvolvedores.
Kanban
O Kanban é um método de gestão de fluxo de trabalho visual. Seus elementos:
- um quadro com colunas que representam o fluxo (por exemplo, a fazer, em andamento, concluído);
- cartões para os itens de trabalho;
- limite de trabalho em andamento (WIP): cada coluna aceita uma quantidade máxima de itens, o que evita sobrecarga e expõe gargalos;
- fluxo contínuo, sem as iterações de duração fixa do Scrum;
- melhoria contínua a partir de métricas de fluxo.
| Aspecto | Scrum | Kanban |
|---|---|---|
| Cadência | Sprints de duração fixa | fluxo contínuo |
| Papéis | definidos no guia | nenhum obrigatório |
| Limites | tamanho da Sprint | limite de WIP por etapa |
| Mudança durante o ciclo | evitada dentro da Sprint | permitida a qualquer momento, respeitando o WIP |
Como escolher na prática
Não há modelo vencedor universal. Requisitos estáveis, contratos fechados e exigências de documentação formal favorecem abordagens mais preditivas; requisitos incertos e necessidade de feedback frequente favorecem as ágeis. Muitas organizações públicas combinam as duas, com contratos e prazos preditivos e execução ágil.
Erros comuns
- Achar que ágil significa “sem documentação” ou “sem planejamento”.
- Dizer que a cascata permite voltar livremente a qualquer fase sem custo.
- Chamar o Scrum Master de gerente do projeto.
- Confundir Sprint (período) com Sprint Backlog (lista de itens).
- Atribuir ao Kanban sprints e papéis obrigatórios.
- Esquecer que a espiral é guiada por risco.
Fontes e atualização
Não há norma oficial brasileira que defina estes modelos; o conteúdo segue a literatura da engenharia de software, o Manifesto Ágil e o Guia do Scrum, que é revisado de tempos em tempos (por isso a nomenclatura de papéis e artefatos pode diferir entre edições). Este guia não envolve cálculo ou código; confira no edital a bibliografia e a edição do guia adotada.
Próximos passos
- Aprofunde requisitos e testes em engenharia de software: requisitos e níveis de teste.
- Modele com UML: sequência, atividades e estados.
- Veja o contexto de carreira em carreiras de TI no serviço público.