A Engenharia de Software com Métodos Ágeis combina práticas técnicas, gestão de produtos, organização de processos e ciclos frequentes de aprendizado para desenvolver sistemas úteis, seguros e sustentáveis.
Agilidade não significa programar rapidamente e corrigir os problemas depois. Também não significa eliminar planejamento, documentação, testes ou controles.
Uma equipe realmente ágil procura entregar valor em partes menores, observar a resposta dos usuários e adaptar as próximas decisões. Para que isso funcione, cada incremento precisa possuir qualidade suficiente para ser utilizado, avaliado e evoluído.
Esse equilíbrio é especialmente importante em sistemas que administram pagamentos, informações pessoais, prontuários, estoques, matrículas, serviços públicos ou processos internos críticos. Uma falha pode interromper operações, expor dados, gerar perdas financeiras e comprometer a confiança dos usuários.
Por isso, a Engenharia de Software com Métodos Ágeis precisa integrar:
- Requisitos;
- Arquitetura;
- Programação;
- Testes;
- Segurança;
- Usabilidade;
- Gestão de produto;
- Observabilidade;
- Entrega contínua;
- Melhoria de processos.
O Manifesto para Desenvolvimento Ágil de Software prioriza indivíduos e interações, software em funcionamento, colaboração com o cliente e capacidade de responder a mudanças. Isso não elimina processos, ferramentas, contratos ou documentação. O manifesto afirma que esses elementos possuem valor, mas não devem ser colocados acima da colaboração e da entrega efetiva. (Manifesto Ágil)
Da mesma forma, normas e modelos de maturidade não precisam competir com a agilidade. Quando utilizados de acordo com o contexto, eles ajudam a definir requisitos de qualidade, organizar responsabilidades, avaliar capacidades e reduzir riscos.
Continue a leitura para entender o que é qualidade de software, como funcionam Scrum e sprints e que práticas ajudam a conciliar adaptação, velocidade e confiabilidade.
O que é Engenharia de Software com Métodos Ágeis?
É a aplicação dos princípios da engenharia de software em ambientes que trabalham com entregas iterativas, colaboração frequente e adaptação contínua.
A engenharia fornece fundamentos para construir e manter sistemas de forma disciplinada.
Os métodos ágeis ajudam a lidar com contextos em que:
- As necessidades mudam;
- O aprendizado acontece durante o projeto;
- Nem todos os requisitos são conhecidos no início;
- O feedback dos usuários é importante;
- O produto precisa evoluir gradualmente;
- Os riscos devem ser reduzidos por ciclos menores.
A combinação não significa diminuir o rigor técnico.
Em um projeto ágil, continuam sendo necessários:
- Critérios de aceitação;
- Revisões de código;
- Testes;
- Controle de versões;
- Gestão de configurações;
- Documentação;
- Segurança;
- Monitoramento;
- Tratamento de incidentes;
- Decisões arquiteturais.
A diferença está na forma de distribuir e revisar o trabalho.
Em vez de tentar definir e construir todo o sistema antes de receber qualquer feedback, a equipe entrega partes utilizáveis e aprende com os resultados.
Qual é a diferença entre método ágil, metodologia e framework?
Os termos são frequentemente usados como equivalentes, mas existem diferenças.
Métodos ágeis são abordagens de desenvolvimento alinhadas aos valores e princípios do Manifesto Ágil.
Eles podem influenciar:
- Planejamento;
- Desenvolvimento;
- Colaboração;
- Entrega;
- Aprendizado;
- Priorização.
Scrum é descrito oficialmente como um framework leve destinado a ajudar pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. Portanto, é mais preciso chamá-lo de framework, e não de uma metodologia completa de engenharia de software. (Scrum Guides)
O Scrum organiza responsabilidades, eventos, artefatos e compromissos. Ele não determina, por exemplo:
- Qual linguagem utilizar;
- Como desenhar a arquitetura;
- Quais testes automatizar;
- Como versionar o código;
- Qual estratégia de implantação adotar;
- Como proteger os dados.
Essas decisões precisam ser complementadas por práticas de engenharia, produto, segurança e operação.
Agilidade significa fazer tudo mais rápido?
Não.
Agilidade está relacionada à capacidade de gerar valor, aprender e responder às mudanças com segurança.
Uma equipe pode produzir muito código e continuar sendo pouco ágil quando:
- As entregas demoram para chegar aos usuários;
- Os requisitos são mal compreendidos;
- Os defeitos se acumulam;
- Cada mudança exige grande retrabalho;
- Os sistemas não possuem testes;
- A arquitetura dificulta alterações;
- Os incidentes são frequentes;
- As decisões permanecem centralizadas.
Velocidade sem qualidade pode produzir uma falsa sensação de avanço.
Quando a equipe reduz testes e revisões para terminar mais itens, os problemas podem reaparecer na forma de:
- Falhas em produção;
- Retrabalho;
- Atrasos posteriores;
- Perda de confiança;
- Dívida técnica;
- Interrupções;
- Riscos de segurança.
A agilidade sustentável procura encurtar o caminho entre uma necessidade e a entrega de uma solução confiável.
O que é qualidade de software?
Qualidade de software é o grau em que um produto atende às necessidades declaradas e implícitas de suas partes interessadas dentro de determinadas condições de uso.
A ISO/IEC 25010:2023 estabelece um modelo de qualidade aplicável a produtos de tecnologia da informação e software. A edição de 2023 possui nove características, utilizadas como referência para especificar, medir e avaliar propriedades de qualidade. (ISO)
A qualidade pode ser analisada a partir de diferentes perspectivas.
Qualidade do produto
Observa características presentes no software e em seu comportamento.
Qualidade em uso
Analisa os resultados obtidos quando pessoas utilizam o produto em um contexto específico.
Qualidade do processo
Avalia se as práticas utilizadas para desenvolver, testar, entregar e manter o software são capazes de produzir resultados consistentes.
Essas perspectivas estão relacionadas.
Um processo organizado não garante automaticamente um produto excelente, mas reduz a dependência de improvisações. Um produto que funciona em um teste técnico pode oferecer uma experiência ruim quando utilizado em condições reais.
Quais são as principais características da qualidade de software?
O modelo da ISO/IEC 25010:2023 oferece uma estrutura para transformar a palavra “qualidade” em critérios mais concretos. (ISO)
Adequação funcional
Verifica se o produto oferece as funções necessárias e se os resultados estão corretos.
Perguntas úteis:
- As funcionalidades cobrem as tarefas dos usuários?
- Os cálculos estão corretos?
- O sistema permite atingir o objetivo esperado?
- Existem funções desnecessárias que aumentam a complexidade?
Eficiência de desempenho
Analisa o comportamento do software em relação ao tempo, à capacidade e ao uso de recursos.
Pode incluir:
- Tempo de resposta;
- Volume processado;
- Consumo de memória;
- Uso de processamento;
- Capacidade para usuários simultâneos;
- Eficiência energética.
Compatibilidade
Avalia a capacidade do produto de compartilhar recursos ou informações com outros sistemas.
Pode envolver:
- Integrações;
- Formatos;
- APIs;
- Navegadores;
- Sistemas operacionais;
- Dispositivos.
Capacidade de interação
Relaciona-se à forma como os usuários interagem com o sistema e conseguem alcançar seus objetivos.
Pode considerar:
- Facilidade de aprendizado;
- Clareza;
- Operabilidade;
- Prevenção de erros;
- Acessibilidade;
- Capacidade de orientar o usuário.
Confiabilidade
Avalia a capacidade de manter o funcionamento esperado em determinadas condições.
Pode incluir:
- Disponibilidade;
- Tolerância a falhas;
- Recuperação;
- Continuidade;
- Consistência.
Segurança
Analisa a proteção de informações, identidades, acessos e operações.
Pode considerar:
- Confidencialidade;
- Integridade;
- Autenticidade;
- Controle de acesso;
- Rastreabilidade;
- Resistência a ataques.
Manutenibilidade
Representa a facilidade para analisar, modificar, testar e evoluir o software.
Um sistema pode funcionar atualmente e, ainda assim, possuir baixa manutenibilidade devido a:
- Código excessivamente acoplado;
- Falta de testes;
- Dependências desatualizadas;
- Regras duplicadas;
- Documentação insuficiente;
- Arquitetura pouco clara.
Flexibilidade
Considera a capacidade de adaptação a mudanças de ambiente, necessidade ou utilização.
Pode envolver:
- Configuração;
- Escalabilidade;
- Adaptação;
- Instalação;
- Substituição de componentes.
Proteção contra riscos
Relaciona-se à capacidade do produto de evitar consequências prejudiciais a pessoas, organizações, propriedades ou ao ambiente.
Ela ganha importância em softwares utilizados em:
- Saúde;
- Transporte;
- Energia;
- Indústria;
- Finanças;
- Segurança;
- Infraestruturas críticas.
As características não devem ser tratadas de maneira isolada. Uma decisão que melhora um aspecto pode prejudicar outro.
Aumentar controles de segurança, por exemplo, pode elevar a complexidade da interação. A equipe precisa buscar um equilíbrio compatível com o risco e o contexto.
Qual é a diferença entre requisito funcional e não funcional?
Requisitos funcionais descrevem o que o sistema deve fazer.
Exemplos:
- Cadastrar um usuário;
- Emitir um relatório;
- Calcular um valor;
- Processar um pagamento;
- Enviar uma notificação.
Requisitos não funcionais descrevem propriedades, restrições ou níveis de qualidade.
Exemplos:
- Responder em até determinado tempo;
- Manter disponibilidade;
- Suportar uma quantidade de acessos;
- Proteger informações;
- Atender a critérios de acessibilidade;
- Registrar determinadas operações.
A classificação não deve levar a equipe a tratar requisitos não funcionais como detalhes opcionais.
Um pagamento funcionalmente correto, mas vulnerável ou lento, não atende adequadamente à necessidade.
Os critérios de qualidade precisam ser discutidos desde o refinamento do produto e transformados em condições verificáveis.
O que é qualidade em uso?
Qualidade em uso analisa o resultado obtido pelos usuários no contexto real.
A ISO/IEC 25019:2023 oferece características para especificar, medir, avaliar e melhorar a qualidade em uso, considerando que o contexto é um elemento necessário para a avaliação. (ISO)
Um sistema pode ser tecnicamente correto e apresentar dificuldades quando:
- O usuário trabalha sob pressão;
- A tela é utilizada em um dispositivo pequeno;
- A internet é instável;
- Existem limitações visuais;
- O ambiente possui ruído;
- A tarefa exige rapidez;
- Os termos são desconhecidos.
Por isso, os testes não devem observar apenas se o botão executa a função.
Também é necessário verificar:
- Se o usuário encontra o botão;
- Se compreende sua finalidade;
- Se reconhece o resultado;
- Se consegue corrigir um erro;
- Se o fluxo é compatível com sua rotina.
Qualidade de software é responsabilidade de quem?
A qualidade é uma responsabilidade compartilhada.
Não deve ser transferida integralmente para uma equipe de testes no fim do processo.
Diferentes participantes contribuem de formas distintas.
Gestão de produto
Ajuda a esclarecer necessidades, prioridades, resultados e critérios de aceitação.
Desenvolvimento
Constrói, revisa, testa e mantém a solução.
Qualidade e testes
Apoiam estratégias, cenários, automação, avaliação de riscos e investigação de falhas.
Design
Contribui com pesquisa, interação, acessibilidade e experiência.
Segurança
Ajuda a identificar ameaças, controles e vulnerabilidades.
Operações
Apoiam implantação, monitoramento, recuperação e confiabilidade.
Usuários e stakeholders
Fornecem contexto, necessidades, restrições e feedback.
Criar um setor isolado de qualidade pode gerar a percepção de que os demais participantes podem entregar qualquer resultado e aguardar que alguém encontre os problemas.
A qualidade precisa estar integrada ao fluxo de desenvolvimento.
O que é garantia da qualidade de software?
Garantia da qualidade procura criar confiança de que os processos e controles são adequados para produzir o resultado esperado.
Ela pode incluir:
- Definição de padrões;
- Revisões;
- Auditorias;
- Estratégia de testes;
- Gestão de riscos;
- Critérios de qualidade;
- Métricas;
- Acompanhamento de não conformidades;
- Melhoria de processos.
Garantia da qualidade não deve ser confundida apenas com execução de testes.
Testar é uma atividade importante, mas não corrige sozinho problemas de requisitos, arquitetura, planejamento ou cultura.
O que é controle da qualidade?
Controle da qualidade verifica se o produto ou incremento atende aos critérios estabelecidos.
Pode incluir:
- Testes;
- Inspeções;
- Revisões;
- Análise estática;
- Avaliação de desempenho;
- Verificação de acessibilidade;
- Testes de segurança;
- Comparação com critérios de aceitação.
A garantia procura organizar o sistema de prevenção.
O controle verifica resultados e detecta desvios.
As duas abordagens são complementares.
O que são normas de qualidade de software?
Normas oferecem conceitos, estruturas e práticas que ajudam organizações a definir processos e critérios consistentes.
Elas podem tratar de:
- Qualidade do produto;
- Processos do ciclo de vida;
- Avaliação;
- Medição;
- Segurança;
- Dados;
- Gestão da qualidade.
Entre as referências estão:
- ISO 9000 e ISO 9001;
- ISO/IEC 25010;
- ISO/IEC 25019;
- ISO/IEC/IEEE 12207;
- Família ISO/IEC 33000;
- Normas específicas do setor.
A ISO 9001 possui aplicação geral para sistemas de gestão da qualidade. Já a família ISO/IEC 25000, conhecida como SQuaRE, concentra-se em requisitos e avaliação da qualidade de sistemas e software. (ISO)
Uma organização não precisa aplicar todas as normas da mesma maneira.
A seleção deve considerar:
- Setor;
- Risco;
- Contratos;
- Clientes;
- Legislação;
- Porte;
- Complexidade;
- Objetivos.
Normas prejudicam a agilidade?
Não necessariamente.
Uma norma pode indicar o que precisa ser controlado sem obrigar a empresa a criar fluxos lentos e documentações excessivas.
O problema aparece quando a organização:
- Cria aprovações sem finalidade;
- Produz documentos que ninguém consulta;
- Duplica informações;
- Centraliza decisões simples;
- Confunde controle com burocracia;
- Padroniza atividades que exigem adaptação.
Um processo auditável não precisa ser pesado.
Registros podem ser produzidos automaticamente por:
- Sistemas de versionamento;
- Pipelines;
- Ferramentas de gestão;
- Testes automatizados;
- Logs;
- Plataformas de observabilidade.
A equipe deve demonstrar que os controles funcionam, e não apenas que possui documentos.
O que é a ISO/IEC/IEEE 12207?
A ISO/IEC/IEEE 12207:2017 define processos que podem ser utilizados no ciclo de vida do software.
Ela também oferece uma estrutura para definir, controlar e melhorar processos em uma organização ou projeto. (ISO)
A norma pode apoiar atividades relacionadas a:
- Aquisição;
- Fornecimento;
- Desenvolvimento;
- Operação;
- Manutenção;
- Gestão;
- Suporte;
- Garantia;
- Configuração;
- Informação.
Os processos são genéricos e podem ser adaptados à metodologia, ao porte e à complexidade do projeto. Diretrizes complementares reforçam que os resultados definidos podem ser aplicados a sistemas de software em organizações de diferentes tamanhos. (ISO)
Isso permite relacionar a norma a projetos ágeis sem exigir um modelo sequencial rígido.
O que é maturidade de processos?
Maturidade de processos representa o grau em que uma organização consegue executar, controlar, medir e melhorar suas práticas de forma consistente.
Uma equipe pouco madura pode depender de:
- Conhecimento individual;
- Improvisação;
- Esforços emergenciais;
- Decisões não registradas;
- Heróis que resolvem crises;
- Resultados imprevisíveis.
Uma organização mais madura procura:
- Definir responsabilidades;
- Compartilhar práticas;
- Medir resultados;
- Aprender com incidentes;
- Reduzir variações;
- Adaptar processos;
- Manter capacidade mesmo com mudanças de pessoas.
Maturidade não significa eliminar autonomia.
O objetivo é evitar que cada projeto precise redescobrir sozinho como planejar, testar, entregar e manter um produto.
O que é SPICE?
SPICE é a sigla historicamente associada à avaliação e à melhoria de processos de software.
Atualmente, os conceitos de avaliação de capacidade são tratados na família ISO/IEC 33000.
A ISO/IEC 33020:2019 define uma estrutura de medição que apoia a avaliação da capacidade de processos. O documento relaciona capacidade à habilidade de um processo de atender de forma consistente aos objetivos atuais ou projetados do negócio. (ISO)
A avaliação pode apoiar:
- Diagnóstico;
- Autoavaliação;
- Comparação;
- Priorização de melhorias;
- Gestão de fornecedores;
- Análise de riscos.
O resultado não deve ser utilizado apenas como um selo.
A finalidade mais útil é identificar capacidades necessárias e orientar melhorias relacionadas aos objetivos da organização.
O que é CMMI?
CMMI é um modelo de boas práticas voltado à melhoria de capacidades e desempenho organizacional.
O modelo pode ser adaptado a diferentes ambientes e integrado a práticas como Agile e DevSecOps. A versão 3.0 está presente nas atuais ofertas, treinamentos e avaliações do CMMI Institute. (CMMI Institute)
Os níveis de maturidade representam uma trajetória de melhoria organizacional.
Nível 0: incompleto
O trabalho pode não ser concluído e as práticas são inconsistentes.
Nível 1: inicial
A execução tende a ser imprevisível e reativa.
Nível 2: gerenciado
Os projetos são planejados, executados, medidos e controlados.
Nível 3: definido
Existem padrões organizacionais que orientam diferentes projetos e contextos.
Nível 4: gerenciado quantitativamente
A organização utiliza dados e objetivos quantitativos para controlar o desempenho.
Nível 5: otimização
A organização utiliza sua estabilidade para sustentar inovação e melhoria contínua. (CMMI Institute)
Os níveis não devem ser interpretados como uma competição genérica para chegar ao número mais alto.
A organização precisa avaliar que capacidades são necessárias para seu negócio, risco e mercado.
Modelos de maturidade são incompatíveis com Scrum?
Não.
Scrum organiza o desenvolvimento de produtos complexos por meio de empirismo, responsabilidades, eventos e artefatos.
Modelos de maturidade ajudam a avaliar capacidades da organização.
Uma empresa pode utilizar Scrum e, ao mesmo tempo:
- Medir desempenho;
- Padronizar práticas essenciais;
- Manter gestão de riscos;
- Definir processos de segurança;
- Desenvolver competências;
- Avaliar fornecedores;
- Melhorar a previsibilidade.
O risco aparece quando a organização impõe um único processo detalhado a todas as equipes, sem considerar contexto e aprendizado.
O CMMI atual declara compatibilidade com abordagens como Agile e DevSecOps, permitindo que suas práticas sejam interpretadas de acordo com o ambiente. (CMMI Institute)
O que é o Manifesto Ágil?
O Manifesto Ágil foi criado em 2001 por profissionais ligados a diferentes abordagens de desenvolvimento.
Ele apresenta quatro valores:
- Indivíduos e interações acima de processos e ferramentas;
- Software em funcionamento acima de documentação abrangente;
- Colaboração com o cliente acima de negociação de contratos;
- Resposta às mudanças acima de seguir um plano.
O texto não afirma que os elementos à direita não possuem valor. Afirma que os elementos à esquerda devem receber maior prioridade. (Manifesto Ágil)
Os princípios complementares incluem:
- Entrega antecipada e contínua de valor;
- Acolhimento de mudanças;
- Entregas frequentes;
- Colaboração entre negócio e desenvolvimento;
- Ritmo sustentável;
- Atenção à excelência técnica;
- Simplicidade;
- Reflexão e adaptação. (Manifesto Ágil)
Portanto, qualidade técnica e agilidade não são opostas.
A capacidade de mudar depende de um software que possa ser modificado com segurança.
O que é Scrum?
Scrum é um framework baseado no empirismo e no pensamento enxuto.
O empirismo considera que o conhecimento surge da experiência e da observação.
Seus três pilares são:
- Transparência;
- Inspeção;
- Adaptação. (Scrum Guides)
Transparência
O trabalho, os objetivos e as condições precisam estar visíveis e compreensíveis.
Inspeção
Os artefatos e o progresso são avaliados com frequência para identificar problemas ou mudanças.
Adaptação
Quando os resultados se desviam do esperado, ajustes são realizados.
Sem transparência, a inspeção pode produzir conclusões incorretas.
Sem inspeção, a equipe descobre os problemas tarde.
Sem adaptação, as reuniões tornam-se rituais sem efeito.
Quais são os valores do Scrum?
O Scrum Guide apresenta cinco valores:
- Comprometimento;
- Foco;
- Abertura;
- Respeito;
- Coragem. (Scrum Guides)
Esses valores orientam a forma como o time trabalha.
Coragem pode signific comunicar um risco antes que ele provoque uma falha.
Abertura pode envolver mostrar que uma estimativa estava errada.
Respeito inclui reconhecer o conhecimento técnico e as limitações dos participantes.
Foco ajuda a evitar que o time trabalhe simultaneamente em muitas prioridades.
Comprometimento não significa aceitar qualquer prazo. Significa assumir responsabilidade pelo objetivo e pela qualidade do trabalho.
Quem faz parte do Scrum Team?
O Scrum Team é composto por:
- Product Owner;
- Scrum Master;
- Developers.
A equipe é multifuncional e autogerenciável. Seus integrantes decidem internamente quem faz o quê, quando e como. (Scrum Guides)
O termo “Time de Desenvolvimento”, utilizado em versões antigas do guia, deixou de representar um grupo separado na edição de 2020.
O Scrum Team atual trabalha de forma integrada e possui responsabilidade sobre todas as atividades necessárias para gerar um incremento de valor.
Isso pode incluir:
- Pesquisa;
- Análise;
- Design;
- Programação;
- Testes;
- Segurança;
- Dados;
- Operação;
- Documentação.
A composição depende do produto.
Qual é o papel do Product Owner?
O Product Owner é responsável por maximizar o valor resultante do trabalho do Scrum Team.
Entre suas responsabilidades estão:
- Desenvolver e comunicar o Product Goal;
- Criar e comunicar os itens do Product Backlog;
- Ordenar os itens;
- Garantir transparência e compreensão do backlog. (Scrum Guides)
O Product Owner pode delegar atividades, mas continua responsável pelo gerenciamento eficaz do backlog.
Ele não deve funcionar apenas como uma pessoa que repassa solicitações.
Seu trabalho exige:
- Compreender usuários;
- Avaliar resultados;
- Negociar prioridades;
- Tomar decisões;
- Equilibrar necessidades;
- Comunicar objetivos.
Também não é necessário que ele escreva sozinho todos os requisitos.
O refinamento pode ser colaborativo.
Qual é o papel do Scrum Master?
O Scrum Master é responsável por estabelecer o Scrum conforme definido no guia e ajudar o time e a organização a compreender sua aplicação.
Ele atua ao:
- Apoiar a eficácia do Scrum Team;
- Orientar a autogestão;
- Ajudar a remover impedimentos;
- Promover eventos produtivos;
- Apoiar o Product Owner;
- Auxiliar a organização na adoção do Scrum. (Scrum Guides)
O Scrum Master não é um gerente que distribui tarefas e cobra atualizações.
Também não precisa resolver pessoalmente todos os impedimentos.
Seu papel pode envolver ajudar o time a desenvolver capacidade para compreender e tratar seus próprios obstáculos.
Quem são os Developers?
Developers são as pessoas comprometidas com a criação de um incremento utilizável em cada Sprint.
Entre suas responsabilidades estão:
- Criar o plano da Sprint;
- Produzir qualidade de acordo com a Definition of Done;
- Adaptar o plano diariamente;
- Responsabilizar-se profissionalmente pelo trabalho. (Scrum Guides)
O termo não representa apenas programadores.
Dependendo do produto, Developers podem incluir profissionais com competências em:
- Design;
- Testes;
- Dados;
- Segurança;
- Infraestrutura;
- Pesquisa;
- Análise.
O Scrum não cria subequipes formais dentro do Scrum Team.
A integração é necessária para evitar que o incremento dependa de uma longa sequência de transferências.
O que é Product Backlog?
Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto.
Ele pode conter:
- Funcionalidades;
- Correções;
- Riscos;
- Estudos;
- Melhorias técnicas;
- Requisitos de qualidade;
- Necessidades de segurança.
O backlog não deve ser tratado como um contrato fechado contendo todo o futuro do produto.
Ele evolui à medida que a equipe aprende.
Itens muito distantes podem possuir menos detalhes.
Itens próximos da execução precisam de compreensão suficiente para serem discutidos e selecionados.
O que é Product Goal?
Product Goal é o objetivo de longo prazo do Scrum Team.
Ele descreve um estado futuro do produto e serve como referência para o planejamento.
O time precisa cumprir ou abandonar um Product Goal antes de assumir outro.
Um objetivo como “implementar 30 funcionalidades” descreve produção, mas não necessariamente valor.
Um Product Goal mais útil pode indicar:
- Reduzir o tempo necessário para determinada tarefa;
- Permitir que um público realize uma operação;
- Aumentar a confiabilidade de um processo;
- Validar um novo modelo de serviço.
O objetivo ajuda a conectar os itens do backlog a uma direção comum. (Scrum Guides)
O que é Sprint?
Sprint é um evento de duração fixa de um mês ou menos em que ideias são transformadas em valor.
Uma nova Sprint começa imediatamente após a anterior.
Dentro dela acontecem:
- Sprint Planning;
- Daily Scrums;
- Trabalho de desenvolvimento;
- Sprint Review;
- Sprint Retrospective. (Scrum Guides)
O Scrum Guide não determina que toda Sprint dure obrigatoriamente duas ou quatro semanas.
A regra é um mês ou menos.
Sprints menores podem:
- Aumentar a frequência do feedback;
- Reduzir exposição ao risco;
- Facilitar ajustes;
- Limitar o custo de hipóteses incorretas.
Durante a Sprint:
- O Sprint Goal não deve ser colocado em risco;
- A qualidade não deve diminuir;
- O Product Backlog pode ser refinado;
- O escopo pode ser esclarecido e renegociado conforme o aprendizado. (Scrum Guides)
O que é Sprint Planning?
Sprint Planning inicia a Sprint e estabelece o trabalho que será realizado.
O evento aborda três temas:
- Por que esta Sprint é valiosa?
- O que pode ser realizado?
- Como o trabalho será executado?
O Scrum Team define um Sprint Goal e seleciona itens do Product Backlog.
Os Developers planejam como transformar esses itens em um incremento.
O plano não precisa antecipar cada detalhe.
Ele deve possuir informação suficiente para iniciar o trabalho e ser adaptado ao longo da Sprint.
Uma Sprint Planning produtiva depende de:
- Backlog compreensível;
- Objetivo claro;
- Conhecimento da capacidade;
- Discussão de riscos;
- Colaboração;
- Definition of Done conhecida.
O que é Sprint Goal?
Sprint Goal é o objetivo único da Sprint.
Ele oferece uma direção e permite flexibilidade sobre o trabalho necessário para alcançá-lo.
Sem um objetivo, a Sprint pode transformar-se em uma coleção de tarefas sem relação.
Exemplo pouco útil:
“Concluir os itens 15, 18, 20 e 24.”
Exemplo mais orientado a valor:
“Permitir que alunos consultem e atualizem seus dados de contato sem solicitar atendimento.”
O Sprint Goal não impede adaptações.
Se a equipe aprende algo novo, pode renegociar o escopo com o Product Owner sem comprometer o objetivo.
O que é Daily Scrum?
Daily Scrum é um evento de 15 minutos destinado aos Developers.
Seu propósito é inspecionar o progresso em direção ao Sprint Goal e adaptar o Sprint Backlog. (Scrum Guides)
A Daily não precisa seguir obrigatoriamente três perguntas.
Os Developers podem escolher qualquer estrutura que produza um plano prático para o próximo período de trabalho.
O evento não deveria tornar-se:
- Prestação de contas ao gestor;
- Leitura de tarefas;
- Reunião longa de solução;
- Atualização individual sem colaboração;
- Espaço para cobrar produtividade.
Problemas que exigem discussão detalhada podem ser tratados depois com as pessoas necessárias.
O que é Sprint Review?
Sprint Review inspeciona o resultado da Sprint e determina possíveis adaptações futuras.
O Scrum Team apresenta os resultados aos stakeholders e discute o progresso em direção ao Product Goal.
A reunião não deve ser limitada a uma demonstração formal.
Ela pode incluir:
- Feedback;
- Dados de uso;
- Mudanças no mercado;
- Resultados;
- Riscos;
- Próximas oportunidades;
- Revisão das prioridades.
Uma Review pouco produtiva apresenta telas sem discutir se o incremento resolveu o problema.
O foco deve estar no produto e no aprendizado, e não apenas na quantidade de itens concluídos.
O que é Sprint Retrospective?
Sprint Retrospective procura planejar maneiras de aumentar a qualidade e a eficácia.
O time pode discutir:
- Pessoas;
- Interações;
- Processos;
- Ferramentas;
- Definition of Done;
- Comunicação;
- Qualidade;
- Obstáculos.
Uma retrospectiva não deve ser um espaço para culpar indivíduos.
O objetivo é identificar padrões e desenvolver ações concretas.
Ações pouco específicas, como “comunicar melhor”, raramente geram mudança.
É mais útil definir algo verificável:
“Durante a próxima Sprint, toda mudança na API terá revisão de contrato e teste de compatibilidade antes da integração.”
O que é Sprint Backlog?
Sprint Backlog é composto por:
- Sprint Goal;
- Itens selecionados;
- Plano para entregar o incremento.
Ele é criado e atualizado pelos Developers.
À medida que o trabalho avança, o plano pode mudar.
O Sprint Backlog deve oferecer visibilidade suficiente para que os Developers acompanhem o progresso em direção ao objetivo.
Ele não deve ser tratado como uma lista imutável definida por outra pessoa.
O que é Increment?
Increment é um passo concreto em direção ao Product Goal.
Cada incremento precisa:
- Ser utilizável;
- Funcionar junto aos anteriores;
- Atender à Definition of Done;
- Ser verificado.
Podem existir vários incrementos durante uma Sprint.
O valor pode ser entregue antes do fim da Sprint quando isso fizer sentido.
A Sprint Review não é uma barreira obrigatória para colocar o software em produção. (Scrum Guides)
O que é Definition of Done?
Definition of Done é uma descrição formal do estado do incremento quando ele atende às medidas de qualidade exigidas.
Ela cria transparência sobre o que significa concluir.
Pode incluir critérios como:
- Código revisado;
- Testes executados;
- Testes automatizados aprovados;
- Critérios de aceitação atendidos;
- Segurança verificada;
- Documentação atualizada;
- Monitoramento configurado;
- Integração concluída;
- Implantação possível.
Quando um item não atende à Definition of Done, ele não pode ser apresentado como parte do incremento nem liberado como concluído. (Scrum Guides)
A definição não deve ser utilizada como uma lista genérica copiada de outra organização.
Ela precisa refletir:
- Risco;
- Produto;
- Tecnologia;
- Regulação;
- Capacidade;
- Expectativas.
Com o amadurecimento da equipe, a Definition of Done pode tornar-se mais rigorosa.
Critérios de aceitação e Definition of Done são iguais?
Não.
Critérios de aceitação são específicos de um item.
Eles ajudam a verificar se determinada necessidade foi atendida.
Exemplo:
- O usuário deve receber um código por e-mail;
- O código deve expirar;
- Tentativas inválidas devem ser registradas.
A Definition of Done é aplicada ao incremento ou aos itens de maneira mais ampla.
Pode exigir:
- Revisão;
- Testes;
- Segurança;
- Documentação;
- Integração;
- Observabilidade.
Um item pode atender aos critérios funcionais e ainda não estar concluído porque não possui os controles técnicos exigidos.
O que é refinamento do Product Backlog?
Refinamento é a atividade contínua de decompor e esclarecer itens do Product Backlog.
Pode envolver:
- Discussão da necessidade;
- Divisão de itens;
- Critérios de aceitação;
- Riscos;
- Dependências;
- Estimativas;
- Alternativas;
- Qualidade.
O refinamento não é definido como um evento formal do Scrum.
Ele acontece conforme necessário.
Refinar não significa escrever todos os detalhes antecipadamente.
O objetivo é manter os itens próximos da execução em condições adequadas para discussão e seleção.
Como escrever histórias de usuário?
Histórias de usuário são uma técnica possível para representar necessidades.
Um formato comum é:
“Como [tipo de usuário], quero [objetivo], para [benefício].”
Exemplo:
“Como aluno, quero acompanhar o status da emissão do certificado para saber se preciso enviar algum documento.”
O formato não garante uma boa necessidade.
Uma história precisa ser complementada por:
- Conversas;
- Critérios;
- Exemplos;
- Regras;
- Contexto;
- Evidências.
Nem todo trabalho precisa ser escrito como história de usuário.
Correções técnicas, pesquisa, infraestrutura e segurança podem exigir outras representações.
O que é estimativa ágil?
Estimativas ajudam a compreender tamanho, esforço, complexidade, risco ou incerteza.
Podem ser realizadas com:
- Pontos;
- Faixas;
- Tamanhos relativos;
- Tempo;
- Contagem de itens;
- Dados históricos.
Story points não representam horas de forma obrigatória.
Eles podem combinar:
- Complexidade;
- Volume;
- Incerteza;
- Dependências.
O valor da estimativa está na conversa e no planejamento.
Transformar pontos em meta individual pode gerar distorções.
A equipe pode aumentar pontuações sem aumentar valor, tornando a métrica inútil.
O que é velocidade do time?
Velocidade é a quantidade de pontos concluídos em uma Sprint, quando a equipe utiliza essa técnica.
Ela pode ajudar a equipe a criar previsões internas.
Não deveria ser utilizada para:
- Comparar equipes;
- Medir produtividade individual;
- Definir premiações;
- Cobrar crescimento contínuo;
- Avaliar qualidade.
Equipes utilizam escalas, critérios e contextos diferentes.
Quando a velocidade se torna meta, a tendência é que a pontuação aumente sem representar uma melhora real.
Como medir o valor entregue?
O valor depende do objetivo do produto.
Possíveis métricas são:
- Conclusão de tarefas;
- Conversão;
- Retenção;
- Redução de erros;
- Tempo economizado;
- Satisfação;
- Adoção;
- Receita;
- Redução de custos;
- Diminuição de chamados.
Entregar muitas funcionalidades não garante aumento de valor.
Uma funcionalidade pode:
- Não ser utilizada;
- Criar confusão;
- Aumentar manutenção;
- Desviar o foco;
- Gerar riscos.
O Product Owner e os stakeholders precisam relacionar itens a resultados esperados e verificar o que aconteceu depois da entrega.
Quais testes são importantes em projetos ágeis?
A estratégia depende do produto e do risco.
Pode incluir:
Testes unitários
Avaliam partes pequenas do código.
Testes de integração
Verificam a interação entre componentes, serviços, bancos de dados ou APIs.
Testes de sistema
Avaliam o comportamento da solução de forma mais ampla.
Testes de aceitação
Verificam se os critérios e necessidades foram atendidos.
Testes de regressão
Procuram identificar se uma mudança afetou funções que já existiam.
Testes exploratórios
Utilizam investigação e aprendizado para descobrir comportamentos não previstos.
Testes de desempenho
Avaliam tempo, capacidade, estabilidade e uso de recursos.
Testes de segurança
Procuram vulnerabilidades e falhas nos controles.
Testes de acessibilidade
Avaliam a utilização por pessoas com diferentes necessidades.
Os testes devem estar distribuídos ao longo do desenvolvimento.
Deixar todas as verificações para o fim da Sprint cria filas e reduz a capacidade de adaptação.
O que é automação de testes?
Automação utiliza código e ferramentas para executar verificações de maneira repetível.
Ela pode contribuir para:
- Feedback rápido;
- Regressão;
- Integração contínua;
- Segurança;
- Confiabilidade;
- Redução de tarefas repetitivas.
Nem todo teste precisa ser automatizado.
A decisão pode considerar:
- Frequência;
- Risco;
- Estabilidade;
- Custo;
- Tempo;
- Valor;
- Manutenção.
Testes de interface excessivamente frágeis podem gerar alarmes falsos e custos elevados.
Uma estratégia equilibrada utiliza diferentes níveis de teste e mantém o código de automação como parte do produto.
O que é desenvolvimento orientado a testes?
Test-Driven Development, ou TDD, é uma prática em que o ciclo de desenvolvimento começa com um teste que representa o comportamento desejado.
Uma sequência comum é:
- Criar um teste que falha;
- Implementar o necessário para o teste passar;
- Refatorar mantendo o comportamento.
A prática pode contribuir para:
- Design mais modular;
- Feedback;
- Segurança para mudanças;
- Especificação executável.
TDD não garante automaticamente boa arquitetura ou cobertura completa.
Os testes precisam representar comportamentos relevantes e ser mantidos.
O que é integração contínua?
Integração contínua é a prática de integrar mudanças com frequência e verificá-las automaticamente.
Um pipeline pode executar:
- Compilação;
- Testes;
- Análise estática;
- Verificações de dependências;
- Empacotamento;
- Validações.
Mudanças menores facilitam a identificação da causa quando uma verificação falha.
Para funcionar, a integração contínua exige:
- Controle de versão;
- Automação;
- Feedback rápido;
- Disciplina;
- Correção de falhas;
- Ambientes confiáveis.
Um pipeline que permanece quebrado durante longos períodos deixa de oferecer segurança.
O que são entrega contínua e implantação contínua?
Entrega contínua mantém o software em condições de ser implantado.
Implantação contínua automatiza a liberação de mudanças aprovadas até a produção.
As práticas não significam publicar qualquer código sem controles.
Podem ser utilizados:
- Testes automatizados;
- Aprovações proporcionais ao risco;
- Feature flags;
- Implantação gradual;
- Monitoramento;
- Rollback;
- Ambientes temporários.
A frequência adequada depende do produto.
Um site de conteúdo e um sistema médico crítico podem exigir estratégias diferentes.
O que é DevOps?
DevOps busca aproximar desenvolvimento, operações e outras disciplinas envolvidas na entrega e na manutenção do software.
Pode incluir:
- Automação;
- Colaboração;
- Infraestrutura como código;
- Observabilidade;
- Integração contínua;
- Entrega contínua;
- Responsabilidade compartilhada;
- Feedback de produção.
DevOps não é apenas uma função ou ferramenta.
Criar um novo departamento e manter as transferências entre equipes não resolve necessariamente os problemas de fluxo.
O objetivo é reduzir barreiras entre construir, entregar e operar.
O que é DevSecOps?
DevSecOps integra segurança ao desenvolvimento e à operação.
A segurança deixa de aparecer apenas em uma revisão final.
Ela pode ser incorporada por meio de:
- Modelagem de ameaças;
- Análise de código;
- Testes;
- Gestão de dependências;
- Proteção de segredos;
- Revisão de infraestrutura;
- Monitoramento;
- Resposta a vulnerabilidades.
O Secure Software Development Framework do NIST reúne práticas de alto nível que podem ser integradas a diferentes ciclos de desenvolvimento. A versão final vigente é a SSDF 1.1, enquanto a versão 1.2 permanecia em consulta pública em julho de 2026. (NIST)
Em março de 2026, o NIST também apresentou orientações práticas para implementar o SSDF por meio de pipelines modernos de desenvolvimento, segurança e operações. (NIST)
O que é segurança por design?
Segurança por design significa considerar ameaças e controles desde a concepção do produto.
Perguntas importantes são:
- Quais dados serão tratados?
- Quem poderá acessar?
- Como a identidade será verificada?
- Que operações são críticas?
- Como detectar abusos?
- Como registrar eventos?
- Como recuperar-se de uma falha?
- Quais dependências serão utilizadas?
Adicionar segurança somente antes do lançamento pode exigir mudanças caras na arquitetura.
O risco precisa ser revisado quando:
- O escopo muda;
- Uma nova integração é criada;
- Dados diferentes são tratados;
- O produto entra em outro mercado;
- Novas ameaças são descobertas.
O que é revisão de código?
Revisão de código é a avaliação de uma mudança por outra pessoa antes da integração ou liberação.
Ela pode ajudar a identificar:
- Erros;
- Problemas de clareza;
- Duplicações;
- Riscos;
- Falhas de segurança;
- Ausência de testes;
- Decisões arquiteturais inadequadas.
A revisão não deve tornar-se uma disputa de preferências pessoais.
Padrões automatizáveis podem ser verificados por ferramentas.
A discussão humana deve concentrar-se em:
- Comportamento;
- Design;
- Manutenção;
- Segurança;
- Impacto.
Revisões muito grandes e demoradas dificultam a compreensão. Mudanças menores tendem a facilitar feedback e integração.
O que é análise estática?
Análise estática verifica o código ou os artefatos sem executar o sistema.
Pode identificar:
- Erros;
- Padrões perigosos;
- Vulnerabilidades;
- Duplicações;
- Complexidade;
- Problemas de estilo;
- Dependências.
A ferramenta não substitui revisão, testes ou conhecimento do contexto.
Ela pode gerar:
- Falsos positivos;
- Falsos negativos;
- Alertas pouco relevantes;
- Excesso de regras.
As regras devem ser configuradas de acordo com tecnologia, risco e capacidade da equipe.
O que é dívida técnica?
Dívida técnica representa decisões que facilitam uma entrega imediata, mas aumentam o custo das mudanças futuras.
Pode surgir por:
- Pressa;
- Falta de conhecimento;
- Mudança de contexto;
- Arquitetura inadequada;
- Ausência de testes;
- Dependências antigas;
- Código duplicado;
- Documentação insuficiente.
Nem toda dívida é resultado de negligência.
Uma solução simplificada pode ser uma decisão consciente para validar uma hipótese.
O problema surge quando:
- A decisão não é registrada;
- Os riscos não são compreendidos;
- A dívida cresce sem acompanhamento;
- Toda nova mudança se torna mais lenta;
- Falhas aumentam.
A equipe pode manter itens técnicos no Product Backlog e relacioná-los a riscos e resultados.
O que é refatoração?
Refatoração é a melhoria da estrutura interna do software sem alteração intencional de seu comportamento externo.
Pode ser utilizada para:
- Reduzir duplicação;
- Melhorar nomes;
- Separar responsabilidades;
- Simplificar regras;
- Aumentar testabilidade;
- Diminuir acoplamento.
A refatoração precisa ser apoiada por testes e realizada continuamente.
Esperar que todo o código se deteriore para realizar um grande projeto de reescrita aumenta o risco.
O que é observabilidade?
Observabilidade é a capacidade de compreender o estado interno de um sistema a partir de seus sinais externos.
Esses sinais podem incluir:
- Logs;
- Métricas;
- Rastreamentos;
- Eventos;
- Perfis.
A observabilidade ajuda a responder:
- O que falhou?
- Quando começou?
- Quais usuários foram afetados?
- Que mudança está relacionada?
- Qual componente está degradado?
- A recuperação funcionou?
Monitoramento e observabilidade precisam ser planejados durante o desenvolvimento.
Um sistema sem sinais adequados pode funcionar nos testes e tornar-se difícil de operar em produção.
O que é confiabilidade de software?
Confiabilidade é a capacidade de o sistema desempenhar suas funções dentro das condições e do período esperados.
Ela pode envolver:
- Disponibilidade;
- Recuperação;
- Tolerância a falhas;
- Continuidade;
- Integridade;
- Previsibilidade.
Práticas relacionadas são:
- Redundância;
- Backups;
- Testes de recuperação;
- Monitoramento;
- Implantação gradual;
- Limites;
- Circuit breakers;
- Gestão de capacidade.
A confiabilidade precisa ser definida de acordo com a necessidade do usuário.
Buscar disponibilidade máxima para todos os componentes pode gerar custos elevados sem benefício proporcional.
O que são SLI, SLO e SLA?
SLI
Service Level Indicator é a medida observada de determinado aspecto do serviço.
Exemplos:
- Disponibilidade;
- Tempo de resposta;
- Taxa de sucesso.
SLO
Service Level Objective é o objetivo estabelecido para o indicador.
SLA
Service Level Agreement é um acordo de nível de serviço, normalmente relacionado a compromissos entre as partes.
Esses conceitos ajudam a relacionar confiabilidade a resultados mensuráveis.
Um sistema pode estar tecnicamente disponível e, ainda assim, falhar na operação mais importante.
Por isso, os indicadores devem representar a experiência real do usuário.
Quais métricas podem ser utilizadas em projetos ágeis?
As métricas devem apoiar decisões e aprendizado.
Podem envolver:
Fluxo
- Lead time;
- Cycle time;
- Trabalho em andamento;
- Throughput;
- Idade dos itens.
Qualidade
- Defeitos;
- Falhas em produção;
- Retrabalho;
- Cobertura relevante;
- Vulnerabilidades;
- Incidentes.
Produto
- Adoção;
- Conversão;
- Retenção;
- Satisfação;
- Conclusão de tarefas;
- Resultados de negócio.
Confiabilidade
- Disponibilidade;
- Recuperação;
- Erros;
- Latência;
- Cumprimento de objetivos de serviço.
Nenhuma métrica deve ser utilizada sem compreender seu comportamento e suas limitações.
O que são as métricas DORA?
As métricas DORA avaliam a capacidade de uma equipe de entregar software com velocidade e estabilidade.
A estrutura atual inclui:
- Change lead time;
- Deployment frequency;
- Failed deployment recovery time;
- Change failure percentage;
- Deployment rework rate. (Dora)
Change lead time
Tempo necessário para uma mudança sair do controle de versão e chegar à produção.
Deployment frequency
Frequência de implantações.
Failed deployment recovery time
Tempo necessário para recuperar o serviço depois de uma implantação com falha.
Change failure percentage
Percentual de mudanças que provocam degradação ou necessidade de correção.
Deployment rework rate
Proporção do trabalho de implantação dedicado a corrigir ou refazer mudanças recentes.
Essas métricas devem ser analisadas em conjunto.
Aumentar a frequência enquanto cresce a taxa de falhas não representa necessariamente uma evolução.
A DORA também orienta que os indicadores sejam utilizados no contexto de uma aplicação ou serviço, evitando comparações simplistas entre equipes com responsabilidades muito diferentes. (Dora)
Métricas devem ser utilizadas para avaliar pessoas?
Não.
Quando métricas de fluxo ou qualidade são transformadas diretamente em metas individuais, podem surgir comportamentos como:
- Dividir artificialmente itens;
- Evitar tarefas complexas;
- Ocultar problemas;
- Inflar estimativas;
- Reduzir testes;
- Priorizar quantidade.
Métricas devem ajudar a compreender o sistema.
Uma equipe pode possuir lead time alto devido a:
- Aprovações;
- Dependências;
- Ambientes instáveis;
- Filas;
- Falta de automação;
- Mudanças muito grandes.
Cobrar apenas que as pessoas trabalhem mais rápido não trata essas causas.
Como equilibrar velocidade e qualidade?
O equilíbrio não é alcançado reduzindo uma dimensão para aumentar a outra.
Práticas que podem melhorar as duas são:
- Mudanças menores;
- Integração frequente;
- Automação;
- Revisões rápidas;
- Definition of Done clara;
- Testes distribuídos;
- Observabilidade;
- Ambientes confiáveis;
- Feedback dos usuários;
- Redução do trabalho em andamento.
Mudanças menores podem ser avaliadas, implantadas e revertidas com maior facilidade.
A DORA também relaciona lotes menores a uma entrega mais rápida e a uma recuperação mais simples quando ocorre uma falha. (Dora)
O que é trabalho em andamento?
Trabalho em andamento corresponde aos itens iniciados e ainda não concluídos.
Quando a equipe inicia muitas atividades simultaneamente:
- Aumenta a troca de contexto;
- O feedback demora;
- O trabalho envelhece;
- As dependências crescem;
- Os itens ficam parcialmente concluídos;
- O risco permanece aberto por mais tempo.
Limitar o trabalho em andamento ajuda a concentrar esforços na conclusão e na entrega de valor.
O objetivo não é manter todas as pessoas ocupadas o tempo inteiro.
Um sistema eficiente pode exigir capacidade disponível para:
- Colaboração;
- Revisões;
- Incidentes;
- Aprendizado;
- Variações.
O que é lead time?
Lead time é o tempo entre o início de uma demanda e sua entrega.
A definição exata precisa ser estabelecida pela equipe.
Pode começar:
- Na solicitação;
- Na entrada no backlog;
- No compromisso;
- No início do desenvolvimento.
E terminar:
- Na conclusão técnica;
- Na homologação;
- Na implantação;
- Na utilização pelo cliente.
Sem uma definição clara, diferentes equipes podem apresentar números que não são comparáveis.
Analisar a distribuição e os percentis costuma ser mais útil do que observar apenas a média.
O que é cycle time?
Cycle time mede o tempo em que um item permanece efetivamente em determinadas etapas do fluxo.
Ele pode ajudar a identificar:
- Filas;
- Esperas;
- Gargalos;
- Etapas lentas;
- Transferências.
Um item pode possuir poucas horas de trabalho e permanecer várias semanas no processo devido a esperas.
Mapear o fluxo ajuda a revelar essas diferenças.
O que é segurança psicológica em equipes de software?
Segurança psicológica é a condição em que as pessoas conseguem comunicar dúvidas, erros e riscos sem medo de humilhação ou punição desproporcional.
Ela é importante porque problemas técnicos raramente desaparecem quando são escondidos.
Uma equipe precisa conseguir dizer:
- Não compreendi o requisito;
- A estimativa está incorreta;
- Existe um risco;
- A implantação precisa ser interrompida;
- Cometi um erro;
- Precisamos de ajuda.
Isso não elimina responsabilidade.
Pessoas continuam responsáveis por agir com profissionalismo, aprender e seguir controles.
A segurança psicológica permite que problemas apareçam cedo, quando ainda podem ser tratados com menor impacto.
O que é post-mortem sem culpados?
É uma análise estruturada realizada após um incidente para compreender:
- O que aconteceu;
- Qual foi o impacto;
- Como foi detectado;
- Como ocorreu a resposta;
- Quais condições contribuíram;
- O que precisa mudar.
Evitar culpabilização simplista não significa ignorar decisões inadequadas.
Significa reconhecer que falhas geralmente envolvem sistemas, ferramentas, comunicação, incentivos e controles.
Uma análise que termina apenas em “a pessoa precisa prestar mais atenção” perde a oportunidade de tornar o sistema mais seguro.
Quais são os erros mais comuns na adoção do Scrum?
Entre os problemas estão:
- Transformar a Daily em prestação de contas;
- Manter equipes separadas por especialidade;
- Utilizar pontos como meta;
- Não possuir Product Goal;
- Aceitar mudanças que destroem o Sprint Goal;
- Tratar o Product Owner como secretário;
- Utilizar o Scrum Master como gestor;
- Exibir itens não concluídos como entregues;
- Ignorar a Definition of Done;
- Realizar retrospectivas sem ações;
- Confundir Sprint com prazo fechado para qualquer escopo.
Outro erro é aplicar os eventos sem desenvolver capacidade técnica.
Um time pode realizar todas as cerimônias e continuar incapaz de entregar um incremento utilizável.
Quais são os erros mais comuns na gestão da qualidade ágil?
Problemas frequentes incluem:
- Deixar os testes para o final;
- Separar QA e desenvolvimento;
- Criar automações frágeis;
- Ignorar requisitos não funcionais;
- Medir apenas quantidade;
- Não monitorar produção;
- Acumular dívida técnica;
- Tratar vulnerabilidades como itens secundários;
- Utilizar a Sprint Review apenas como demonstração;
- Não conversar com usuários.
A qualidade precisa aparecer no backlog, nos critérios, nas decisões arquiteturais, na Definition of Done e nas métricas.
Scrum serve para qualquer projeto?
Não existe um framework adequado a todos os contextos.
Scrum pode ser útil quando:
- O problema é complexo;
- Existe necessidade de aprendizado;
- Entregas incrementais são possíveis;
- Stakeholders podem fornecer feedback;
- O time possui competências suficientes;
- Há espaço para adaptação.
Ele pode ser menos adequado quando:
- O trabalho é predominantemente repetitivo;
- As prioridades mudam várias vezes por dia;
- A equipe não consegue formar um time estável;
- O produto não pode ser dividido de forma útil;
- Existe um fluxo contínuo mais adequado.
Mesmo nesses casos, valores ágeis e práticas de engenharia podem continuar relevantes.
A decisão deve considerar a natureza do trabalho, e não a popularidade do framework.
Scrum e Kanban podem ser combinados?
Sim, desde que a equipe compreenda a finalidade de cada abordagem.
Scrum oferece:
- Responsabilidades;
- Sprints;
- Eventos;
- Artefatos;
- Objetivos.
Kanban pode contribuir com:
- Visualização do fluxo;
- Limites de trabalho em andamento;
- Políticas explícitas;
- Métricas de fluxo;
- Gestão de gargalos.
Uma equipe Scrum pode utilizar um quadro e métricas de fluxo para compreender o trabalho.
O uso de Kanban não deve eliminar elementos obrigatórios do Scrum quando a equipe afirma seguir o framework.
Como começar a aplicar Engenharia de Software com Métodos Ágeis?
A adoção pode ser organizada em etapas.
1. Entenda o problema e o produto
Identifique usuários, necessidades, riscos e resultados esperados.
2. Defina características de qualidade
Escolha critérios relacionados a funcionalidade, segurança, desempenho, usabilidade, confiabilidade e manutenção.
3. Forme um time multifuncional
Reúna competências suficientes para transformar uma necessidade em incremento utilizável.
4. Defina objetivos
Estabeleça Product Goal e Sprint Goals ligados a resultados.
5. Organize o Product Backlog
Inclua funcionalidades, riscos, qualidade, segurança e melhorias técnicas.
6. Crie uma Definition of Done
Defina as condições mínimas para considerar o incremento concluído.
7. Automatize o feedback
Implemente controle de versão, integração contínua, testes e verificações.
8. Entregue em partes menores
Reduza o tamanho das mudanças e aumente a frequência de aprendizado.
9. Observe o produto em uso
Utilize métricas, monitoramento, pesquisa e feedback.
10. Melhore o processo
Use retrospectivas, incidentes e dados para ajustar práticas.
Checklist de qualidade para uma Sprint
Antes de iniciar:
- O Sprint Goal está claro?
- Os itens estão relacionados ao objetivo?
- Os riscos foram discutidos?
- Os critérios de aceitação são compreensíveis?
- Existem requisitos de segurança?
- Existem requisitos de desempenho?
- As dependências são conhecidas?
- A Definition of Done está clara?
Durante a Sprint:
- O trabalho está integrado frequentemente?
- Os testes acompanham o desenvolvimento?
- O código está sendo revisado?
- Os riscos estão visíveis?
- O Sprint Goal continua válido?
- O trabalho em andamento está controlado?
- As falhas do pipeline são corrigidas?
Antes de considerar concluído:
- Os critérios foram atendidos?
- A Definition of Done foi cumprida?
- O incremento funciona com os anteriores?
- Os controles de segurança foram aplicados?
- O monitoramento foi preparado?
- A documentação necessária foi atualizada?
- A implantação e a recuperação foram avaliadas?
Depois da entrega:
- Os usuários conseguiram utilizar?
- O resultado esperado ocorreu?
- Surgiram erros ou incidentes?
- As métricas mudaram?
- Que aprendizado altera o backlog?
- Que melhoria deve entrar na retrospectiva?
Perguntas frequentes sobre Engenharia de Software com Métodos Ágeis
O que é Engenharia de Software com Métodos Ágeis?
É a combinação de práticas de engenharia com desenvolvimento iterativo, colaboração frequente, feedback e adaptação.
Agilidade significa desenvolver sem documentação?
Não. A documentação deve ser suficiente para apoiar comunicação, manutenção, segurança, operação e conformidade.
O Manifesto Ágil considera processos e ferramentas inúteis?
Não. Ele reconhece seu valor, mas prioriza indivíduos e interações. (Manifesto Ágil)
O que é qualidade de software?
É o grau em que um produto atende às necessidades e aos requisitos de suas partes interessadas em determinado contexto.
Qual norma apresenta um modelo de qualidade de software?
A ISO/IEC 25010:2023 define um modelo de qualidade do produto com nove características. (ISO)
Quais características fazem parte da qualidade?
Adequação funcional, desempenho, compatibilidade, interação, confiabilidade, segurança, manutenibilidade, flexibilidade e proteção contra riscos estão entre as dimensões da edição de 2023.
Qual é a diferença entre qualidade do produto e qualidade em uso?
Qualidade do produto observa suas propriedades. Qualidade em uso avalia os resultados obtidos por usuários dentro de um contexto específico. (ISO)
O que são requisitos não funcionais?
São requisitos relacionados a propriedades como segurança, desempenho, disponibilidade, acessibilidade e manutenibilidade.
Scrum é uma metodologia?
O Scrum Guide o define como um framework leve para geração de valor em problemas complexos. (Scrum Guides)
Quais são os pilares do Scrum?
Transparência, inspeção e adaptação.
Quais são os valores do Scrum?
Comprometimento, foco, abertura, respeito e coragem.
Quem faz parte do Scrum Team?
Product Owner, Scrum Master e Developers.
O que faz o Product Owner?
É responsável por maximizar o valor e gerenciar eficazmente o Product Backlog.
O Product Owner é chefe dos Developers?
Não. O Scrum Team é autogerenciável.
O que faz o Scrum Master?
Ajuda o time e a organização a compreender e aplicar Scrum, além de apoiar sua eficácia.
Developers são apenas programadores?
Não. O termo representa as pessoas necessárias para criar o incremento.
Quanto tempo dura uma Sprint?
Um mês ou menos. (Scrum Guides)
Toda Sprint precisa durar duas semanas?
Não. A duração deve ser fixa e limitada a um mês ou menos.
O que é Sprint Goal?
É o objetivo único que oferece direção para a Sprint.
O que é Product Goal?
É o objetivo de longo prazo relacionado ao estado futuro do produto.
O que é Daily Scrum?
É um evento de 15 minutos para os Developers inspecionarem o progresso e adaptarem o plano. (Scrum Guides)
A Daily precisa seguir as três perguntas?
Não. Os Developers podem utilizar a estrutura que melhor cumpra o propósito.
O que é Sprint Review?
É o evento de inspeção do resultado e discussão das adaptações futuras com stakeholders.
O que é Sprint Retrospective?
É o evento utilizado para planejar melhorias de qualidade e eficácia.
O que é Increment?
É um passo utilizável e verificado em direção ao Product Goal.
O que é Definition of Done?
É a descrição formal do estado de qualidade necessário para considerar um incremento concluído.
Critérios de aceitação são iguais à Definition of Done?
Não. Os critérios são específicos do item. A Definition of Done define condições gerais de qualidade.
O que é Product Backlog?
É a lista emergente e ordenada do que é necessário para melhorar o produto.
O que é refinamento?
É a atividade de esclarecer, dividir e desenvolver os itens do Product Backlog.
História de usuário é obrigatória no Scrum?
Não. O Scrum não exige um formato específico para os itens.
Story points são horas?
Não obrigatoriamente. Eles costumam representar tamanho relativo, complexidade ou incerteza.
Velocidade mede produtividade?
Não de forma confiável. Ela pode apoiar previsões internas, mas não deveria ser usada para comparar pessoas ou equipes.
Qualidade é responsabilidade do QA?
Não exclusivamente. É uma responsabilidade compartilhada pelo time e pelas demais áreas envolvidas.
Testes automatizados eliminam testes manuais?
Não. Diferentes tipos de teste possuem objetivos distintos.
O que é integração contínua?
É a prática de integrar e verificar mudanças frequentemente.
O que é entrega contínua?
É a capacidade de manter o software em condições de ser implantado.
O que é DevOps?
É uma abordagem que aproxima desenvolvimento e operação para melhorar fluxo, colaboração e confiabilidade.
O que é DevSecOps?
É a integração de segurança ao ciclo de desenvolvimento e operação.
Qual é a versão final atual do SSDF?
Em julho de 2026, a versão final era o NIST SSDF 1.1. A versão 1.2 permanecia em consulta pública. (NIST)
O que é dívida técnica?
É o custo futuro criado por decisões técnicas que dificultam manutenção e evolução.
O que é refatoração?
É a melhoria da estrutura interna do software sem alteração intencional de seu comportamento.
O que é observabilidade?
É a capacidade de compreender o estado do sistema por meio de sinais como logs, métricas e rastreamentos.
O que são métricas DORA?
São métricas utilizadas para avaliar velocidade e estabilidade da entrega de software. (Dora)
Quais são as métricas DORA atuais?
Change lead time, deployment frequency, failed deployment recovery time, change failure percentage e deployment rework rate.
O que é CMMI?
É um modelo de práticas utilizado para melhorar capacidades e desempenho organizacional.
CMMI pode ser utilizado com Agile?
Sim. O modelo atual oferece contexto para integração com práticas ágeis e DevSecOps. (CMMI Institute)
O que é SPICE?
É a denominação histórica associada à avaliação de processos de software, atualmente relacionada à família ISO/IEC 33000.
Modelos de maturidade garantem bons produtos?
Não. Eles avaliam capacidades e processos, mas os resultados dependem de aplicação, decisões técnicas e contexto.
Scrum garante qualidade?
Não sozinho. Ele precisa ser complementado por práticas de engenharia, testes, segurança e operação.
Scrum serve apenas para software?
Não. O framework pode ser utilizado em outros contextos complexos, embora seja amplamente associado ao desenvolvimento de produtos digitais.
Métodos ágeis eliminam planejamento?
Não. O planejamento ocorre continuamente e é adaptado conforme o aprendizado.
A equipe pode mudar o escopo durante a Sprint?
O escopo pode ser esclarecido e renegociado com o Product Owner, desde que o Sprint Goal não seja colocado em risco. (Scrum Guides)
A qualidade pode ser reduzida para cumprir a Sprint?
Não. O Scrum Guide afirma que a qualidade não deve diminuir durante a Sprint. (Scrum Guides)
Agilidade sustentável depende de engenharia
A Engenharia de Software com Métodos Ágeis não oferece uma escolha entre qualidade e rapidez.
Ela procura criar condições para que o software possa evoluir sem transformar cada mudança em uma ameaça.
A agilidade aparece quando uma equipe consegue:
- Compreender necessidades;
- Dividir problemas;
- Entregar incrementos;
- Receber feedback;
- Observar resultados;
- Corrigir a direção;
- Preservar a qualidade.
Scrum contribui ao criar objetivos, responsabilidades, transparência e ciclos de inspeção. Porém, o framework não substitui arquitetura, testes, segurança, integração, observabilidade ou gestão do ciclo de vida.
As normas também não precisam criar lentidão. A ISO/IEC 25010 ajuda a transformar qualidade em características verificáveis. A ISO/IEC/IEEE 12207 organiza processos do ciclo de vida. A família ISO/IEC 33000 e o CMMI ajudam a compreender capacidades e caminhos de melhoria. (ISO)
As práticas atuais ampliam essa integração.
Pipelines automatizados permitem verificar mudanças com rapidez. O NIST SSDF incorpora segurança ao desenvolvimento. As métricas DORA ajudam a observar fluxo e estabilidade. A observabilidade aproxima o time do comportamento real do produto. (NIST Computer Security Resource Center)
Nenhuma dessas práticas funciona isoladamente.
Uma equipe pode possuir ferramentas modernas e continuar com decisões lentas. Pode realizar Sprints e não entregar valor. Pode ter muitos testes e ainda ignorar os riscos mais importantes. Pode medir implantações e não observar a experiência dos usuários.
O ponto central é construir um sistema de trabalho coerente.
Para profissionais que desejam atuar nesse campo, aprofundar conhecimentos sobre qualidade, processos, Scrum, testes, segurança e métricas pode ampliar a capacidade de desenvolver produtos adaptáveis sem perder confiabilidade.
A Faculdade Líbano oferece uma pós-graduação em Engenharia de Software com Métodos Ágeis voltada ao desenvolvimento de competências relacionadas à qualidade de software, às normas, aos modelos de maturidade, ao Scrum e à gestão de projetos por sprints.
Conheça a formação e avalie como seus conteúdos podem contribuir para seus objetivos profissionais.
