Metodologias Ágeis Flashcards
Com relação ao gerenciamento de projetos, julgue o próximo item.
O Scrum diário, ou daily standup, é uma reunião de equipe de projeto, na qual é feita uma análise do progresso do dia anterior e são definidas ações para o dia em que ocorre referida reunião.
CORRETO
Daily Scrum, também conhecido como “Daily Stand-up” ou “Daily Meeting”
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão do próximo trabalho da Sprint.
[Guia Scrum - Versão 2020]
3 PERGUNTA SÃO FEITA AO DESENVOLVEDOR NA REUNIÃO
O QUE VOCÊ FEZ ONTEM ?
TEVE ALGUM IMPEDIMENTO ?
O QUE VOU FAZER PARA AJUDAR A EQUIPE HOJE
Com relação ao gerenciamento de projetos, julgue o próximo item.
Na teoria do Scrum, o Lean Thinking é uma abordagem em que o conhecimento aplicado aos projetos e a tomada de decisão são oriundos da experiência das equipes.
O Scrum se baseia no empirismo e no lean thinking:
O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base naquilo que é verdadeiro e conhecido (observado)
Já o Lean Thinking é uma espécie de estrutura mental (mindset) que permite reduzir o desperdício e se concentrar no essencial.
GUIA SCRUM 2020
Lean Thinking (ou Pensamento Enxuto) é uma filosofia de gestão focada em maximizar o valor para o cliente enquanto minimiza o desperdício. Originado no Sistema Toyota de Produção, ele se baseia em princípios como:
- Identificar valor (o que o cliente realmente quer).
- Mapear o fluxo de valor (entender o processo atual).
- Criar fluxo contínuo (eliminar gargalos).
- Estabelecer produção puxada (produzir conforme a demanda).
- Buscar a perfeição (melhoria contínua).
O objetivo é criar processos mais eficientes, ágeis e sustentáveis.
fonte: Deepseek
No que se refere a processos ágeis, julgue o item que se segue.
O scrum master é responsável por remover impedimentos, facilitar eventos do Scrum e garantir que a equipe siga os valores e princípios do Scrum.
CORRETO
RESPONSABILIDADES SCRUM MASTER
gestão de pessoas e gestão do processo
garantir que o Scrum seja entendido e aplicado, na aderência da teoria, práticas e regras do Scrum
ajudar aqueles fora da Equipe Scrum a entender quais as suas interações com a mesma são úteis
orientar o Product Owner na criação e ordenação do Product Backlog
garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam sendo seguidos.
ajudar a remover impedimentos que o time enfrente, mas sem o uso de qualquer autoridade.
utilizar técnicas de facilitação/coaching para o time conseguir visualizar os problemas/ encontrar soluções
durante eventos, ele é responsável pela fluidez da reunião, utilizando técnicas de facilitação
ajudar a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade
ensinar a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.
comunicar claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores
No que se refere a processos ágeis, julgue o item que se segue.
No Kanban, a implementação de limites de trabalho em progresso visa reduzir o tempo de entrega dos itens, sem impactar outros aspectos, como a identificação de gargalos e a melhoria contínua do fluxo de trabalho.
ERRADO
Não serve para reduzir o tempo de entrega dos itens. “Limite de Trabalho em Progresso” (ou WIP, do inglês Work in Progress) é uma prática que estabelece um número máximo de tarefas ou itens que podem estar em andamento ao mesmo tempo em uma determinada fase do fluxo de trabalho.
Resumo Simples sobre Kanban e Limites de WIP:
Limites de WIP (Work In Progress): Restrição do número de tarefas em andamento ao mesmo tempo.
Objetivos:
Reduzir o tempo de entrega: Menos tarefas ao mesmo tempo resultam em foco e mais agilidade.
Identificar gargalos: Facilita a visualização de áreas problemáticas no fluxo de trabalho.
Melhoria contínua: Ajuda a identificar oportunidades de aprimoramento no processo.
A implementação de limites de WIP otimiza o fluxo de trabalho, aumentando a eficiência e permitindo melhorias constantes.
Considerando conceitos e aplicações do DevOps no contexto das metodologias ágeis, julgue o item a seguir.
A implementação de uma pipeline de CI/CD no DevOps otimiza o processo de sprint review em um ambiente Scrum, pois resulta em uma capacidade aprimorada de demonstrar funcionalidades em ambiente próximo ao de produção.
Alternativa: Certo ✅
Justificativa:
A implementação de uma pipeline de CI/CD (Continuous Integration/Continuous Deployment) dentro do DevOps está alinhada com os princípios das metodologias ágeis, especialmente no contexto do Scrum. Essa automação facilita a entrega contínua de software e melhora a qualidade das revisões de sprint (Sprint Review) por diversos motivos:
Entrega Contínua e Rápida 🚀
A automação da pipeline permite que novas funcionalidades sejam rapidamente integradas e implantadas, garantindo que a equipe possa demonstrar incrementos do produto de forma funcional e estável no Sprint Review.
Ambiente de Teste Próximo ao de Produção 🌍
Com a integração contínua, os desenvolvedores podem validar funcionalidades em um ambiente semelhante ao de produção, reduzindo o risco de bugs e inconsistências.
Feedback Rápido e Iteração Contínua 🔄
O Scrum enfatiza ciclos curtos e entrega incremental. Uma pipeline bem configurada reduz o tempo entre o desenvolvimento e a validação do software, permitindo que ajustes sejam feitos com mais agilidade.
Redução de Riscos ✅
A automação de testes e a integração contínua garantem que o código novo não quebre funcionalidades já existentes, tornando as demonstrações mais confiáveis.
Portanto, a assertiva está correta porque a implementação de CI/CD melhora a eficiência e qualidade do Sprint Review, tornando-o mais próximo de um ambiente real de produção.
Julgue o próximo item, a respeito de metodologias de gerenciamento de projetos.
No Scrum, product owner é o responsável por maximizar o valor do produto resultante do trabalho do time scrum.
Gabarito: Correto.
No scrum, “product owner” (proprietário do produto) é um membro responável por maximizar o valor do produto. Ele trabalha com o time de scrum para criar um produto valioso, e são responsáveis pelo sucesso do produto.
Fonte (e site onde o CEBRASPE provavelmente pegou a questão, porque a questão é literalmente tradução livre desse site): https://www.scrum.org/resources/what-is-a-product-owner
Quaisquer objeções, só comentar.
Product Owner (PO): Responsável por maximizar o valor do produto, gerenciando o Product Backlog e garantindo que o time desenvolva o que traz mais valor para o negócio.
Scrum Master (SM): Facilitador e servidor da equipe, removendo impedimentos, garantindo o cumprimento do processo Scrum e promovendo a melhoria contínua.
Time de Desenvolvimento: Responsável por desenvolver o produto, auto-organizando-se e entregando um incremento de qualidade no final de cada sprint.
Julgue o seguinte item, a respeito de engenharia de software.
No Scrum, as sprints ocorrem de maneira linear: ao final de cada uma, é feita uma sprint review para analisar o que foi feito; em seguida, a sprint restropective analisa pontos positivos e negativos e realiza possíveis mudanças.
A abordagem linear é essencial para garantir que o time não apenas avalie os resultados obtidos (na Review), mas também aprenda com a experiência (na Retrospective). Isso reflete um dos pilares do Scrum: a adaptação, que ocorre a partir da inspeção tanto do produto quanto do processo. Além disso, a linearidade permite que a equipe entre na próxima Sprint com ajustes já definidos e um plano claro para evoluir.
O Kanban e o Scrum utilizam sprints no planejamento e na distribuição de tarefas.
Scrum utiliza sprints como parte central do planejamento e distribuição de tarefas.
Kanban, por outro lado, trabalha com fluxo contínuo e não utiliza sprints.
Portanto, a afirmação de que ambos utilizam sprints está incorreta, e a alternativa é Errado.
Julgue o próximo item conforme o Scrum (nov./2020).
Durante a sprint review, o scrum team e os stakeholders revisam o que foi realizado na sprint, sendo possível ajustar o product backlog a fim de atender a novas oportunidades.
Certo.
Durante a sprint review, o Scrum Team e os stakeholders revisam o trabalho concluído durante a sprint. Essa reunião serve como uma oportunidade para ajustar o Product Backlog, incorporando feedback e identificando novas oportunidades para garantir que o produto final atenda às necessidades dos usuários e do negócio.
Para não confundir a Sprint Review com a Sprint Retrospective, considere as seguintes dicas:
Sprint Review: Foca na avaliação do trabalho realizado durante a sprint e na adaptação do backlog do produto. É uma oportunidade para a equipe mostrar o que foi concluído e obter feedback dos stakeholders.
Sprint Retrospective: Foca na melhoria do processo da equipe. É um momento para discutir o que funcionou bem, o que não funcionou e como a equipe pode melhorar no próximo ciclo.
Sprint Review: Inclui a equipe de desenvolvimento, o Product Owner e stakeholders (partes interessadas). O foco é na entrega de valor e no feedback sobre o produto.
Sprint Retrospective: É uma reunião interna da equipe de desenvolvimento e, às vezes, pode incluir o Scrum Master. O foco é na dinâmica da equipe e na melhoria dos processos.
Sprint Review: Geralmente, é mais formal e estruturada. A equipe demonstra o trabalho concluído e discute o progresso em relação ao backlog do produto.
Sprint Retrospective: É mais informal e reflexiva. A equipe discute suas experiências e sentimentos sobre o trabalho realizado, o que pode incluir dinâmicas para promover a discussão.
Ambas ocorrem ao final de cada sprint, mas lembre-se que a Sprint Review é sobre o produto e a Sprint Retrospective é sobre a equipe e o processo.
Pense na Sprint Review como uma “revisão do que foi feito” (foco no produto) e na Sprint Retrospective como uma “retrospectiva de como trabalhamos” (foco no processo e na equipe).
Esses pontos podem ajudar a manter claro o propósito e a natureza de cada reunião, evitando confusões.
Julgue o próximo item conforme o Scrum (nov./2020).
Desde que o daily scrum se concentre no progresso em direção à meta da sprint e produza um plano de ação para o próximo dia de trabalho, os developers podem selecionar a estrutura e as técnicas que quiserem.
Correto
“Os Developers podem selecionar qualquer estrutura e técnicas que quiserem, desde que seu Daily Scrum se concentre no progresso em direção a Meta da Sprint e produza um plano de ação para o próximo dia de trabalho. Isso cria foco e melhora o autogerenciamento.”
Julgue o próximo item conforme o Scrum (nov./2020).
Na sprint planning, fica a critério exclusivo dos developers o planejamento necessário para se criar um incremento que atenda à definição de pronto, o que pode ser realizado decompondo-se os itens do product backlog.
Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers. Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor.”
SCRUM GUIDE 2020 PÁGINA 10
