Font size
WorksheetsGestão de Projetos
Total questions: 16
Worksheet time: 16mins
Assinale qual a primeira cerimônia que acontece em uma Sprint.
Daily Meeting
Sprint Planning
Retrospectiva
Review
Grooming
Podemos dizer que o Scrum Master é o antigo Gerente de Projeto?
Verdadeiro
Falso
O Product Owner, também conhecido como PO:
É o dono do produto, o cliente. Representa a área de negócio. Ele é o responsável pelo Product Backlog.
É a área operacional que utilizará o sistema que será construído.
É o dono do produto, o cliente. Representa a área de negócio. Ele é o responsável pelo Sprint Backlog.
É a maior autoridade dentro do time (Squad). Deve ser respeitado. Seu pedido é uma ordem.
O que é timebox?
É uma caixa que contém todos os pedidos do cliente. É dela que sai todas as necessidades que deverão ser analisadas e construída.
É um espaço de tempo, determinado de 1 a 4 semanas, onde deverá ocorrer uma Sprint, compreendendo desde o planejamento (Sprint Planning) até a Retrospectiva.
É um espaço de tempo, determinado de 1 a 10 dias, onde deverá ocorrer uma Sprint, compreendendo desde o planejamento (Sprint Planning) até a Demonstração (Demo).
É um espaço de tempo, determinado de 1 a 4 semanas, onde deverá ocorrer uma Sprint, compreendendo desde o primeiro dia (Daily) até a revisão (Review).
A duração de uma Sprint é de:
1 a 4 semanas
1 a 4 dias
1 a 2 semanas
1 a 2 meses
O que significa DoR?
Definition of Ready, ou Definição de Preparado. São critérios que definem quando uma história de usuário está pronta para sair da Sprint, ou seja, está concluída;
Definition of Rule, ou Definição de Regra. São todas as regras que o time deve seguir dentro de uma Sprint, para que o projeto não entre em caos.
Definition of Rule, ou Definição de Regra. É a declaração do requisito de negócio que o PO escreve na história de usuário;
Definition of Ready, ou Definição de Preparado. São critérios que definem quando uma história de usuário está preparada para entrar na Sprint Planning.
O que é INVEST?
É uma técnica que ajuda o time a buscar uma história de usuário mais completa e pronta para entrar na Sprint. É um acrônimo para histórias serem: Independentes, Negociáveis, Valorável (que tenha valor para o negócio), Estimável (que dê para estimar de alguma forma), Pequena (Small) e finalmente testável.
É uma técnica que ajuda o time a buscar uma história de usuário mais completa e pronta para entrar na Sprint. É um acrônimo para histórias serem: Independentes, Negociáveis, Vitoriosa (caso seja construída, o time vence o desafio), Estimável (que dê para estimar de alguma forma), Saudável (dentro de critérios que traga saúde para o desenvolvimento do projeto) e finalmente Testável.
É um termo que fomenta o investimento do time em melhoria contínua, ou seja, lembra o time continuamente que independente de qualquer problema que esteja acontecendo, não podemos perder o foco na melhoria contínua.
É um termo que deriva de Investigação. O time deve sempre investigar se está trabalhando em um ritmo sustentável e caso não seteja, deve melhoriar.
Uma História de Usuário:
É a mesma coisa que um Requisito Funcional, só muda o termo, ajustado para os projetos ágeis. Quanto maior, melhor, pois dá para entregarmos mais coisas de uma vez.
É o usuário relatando a sua necessidade em uma reunião de trabalho, com intuito do time de desenvolvimento transformar em entrega de software.
É a mesma coisa que um Requisito Funcional, só muda o termo, ajustado para os projetos ágeis. Quanto menor, melhor, pois é mais fácil de construir, testar, homologar e implantar.
É uma gíria dos desenvolvedores. Quando o cliente inventa muita moda na escrita da história, os desenvolvedores soltam o comentário: “Ah isso é história de usuário!”.
Quando se trata de estimativa de esforço, a melhor opção é fazermos isso em horas de trabalho, pois estamos acostumados a fazer esse processo e somos bons por natureza em estimar as coisas com exatidão.
Verdadeiro
Falso
Um meio intermediário de estimar o trabalho a ser feito em desenvolvimento de software é:
Por horas, uma vez que isso é fácil e eficiente de fazer.
Por complexidade (Story Points, por exemplo), uma vez que somos melhores em estimativa por complexidade do que por exatidão (horas, por exemplo).
Por dias úteis, visto que trabalhamos apenas 5 dias por semana.
Por dias corridos, uma vez que é válido estimar os fins de semana também, para que se tenha uma ideia por completo do esforço necessário a ser empreendido no projeto.
LeadTime
É um indicador puramente técnico, onde o time de desenvolvimento estima a quantidade de dias a ser feito um determinado trabalho.
É um indicador meio de negócio (LEAD), meio técnico (TIME), onde as duas áreas juntam seus indicadores de produção e somam a quantidade de dias trabalhados para entregar uma demanda de negócio.
É o momento de refletir se a liderança tem desempenhado um bom trabalho, principalmente caso os indicadores de desempenho do negócio estejam ruins.
É um indicador puramente de negócio, onde o time mede a quantidade de dias necessário para se entregar algo ao mercado, desde a concepção do produto até a entrega na produção.
A Sprint Planning é uma cerimônia em que o time de desenvolvimento se compromete com a entrega que o PO solicita. O que é decisivo para que essa cerimônia dê certo? Assinale mais de uma alternativa se achar que faz sentido.
As histórias de usuário precisam estar prontas para serem discutidas na Sprint Planning e para isso é essencial que elas tenham passado por refinamento funcional e técnico, também conhecido como Groomings.
É preciso aceitar tudo o que o PO pede. Se não der tempo de fazer, sem problemas, pois haverá outras Sprints, onde poderá ser concluído o trabalho planejado.
As histórias de usuário precisam estar prontas para serem discutidas na Sprint Planning e para isso é essencial que a equipe tenha definido os critérios que definem que a história está preparada para a Sprint Planning, também conhecido como DoR – Definition of Ready.
O time de desenvolvimento precisa estar consciente de que o que é solicitado pelo PO não é uma ordem, mas sim algo que precisa ser negociável, discutido e decidido juntos. Saber dizer “NÃO” deve ser uma coisa natural.
A respeito do Scrum Master, é correto dizer:
O time é totalmente dependente desse papel. Sem o Scrum Master, toda equipe está fadada ao fracasso.
O Scrum Master é um papel fundamental em uma equipe Scrum, mas isso não significa que a equipe precisa ser dependente desse perfil. O ideal é que ele fique com a equipe para que a maturidade ágil aumente e com o tempo, o Scrum Master vá se distanciando da equipe, dando a ela mais autonomia e auto-organização.
Todas as cerimônias precisam ter o Scrum Master como responsável. Sem ele, é impossível ocorrer Daily Meeting, Sprint Planning, Sprint Review e Retrospectiva.
Se não existe um Scrum Master definido na equipe, qualquer outra pessoa pode assumir esse papel.
Assinale a hierarquia correta de artefatos:
História > Épico > Sub-tarefas
Sub-tarefas > História > Épico
Épico > História > Sub-tarefas
Uma ferramentas de fluxo de projeto ágil:
Microsoft Project
Atlassian Confluence
Atlassian Jira
HP ALM
Uma das coisas mais importantes que uma boa história de usuário precisa ter é:
Critérios de aceite.
O responsável por desenvolver a história.
Quando ela deverá ficar pronta.
A quantidade de horas esperadas para concluir o desenvolvimento
