Open diovanemonteiro opened 5 years ago
O Scrum aborda o controle de riscos por diversas vezes no Scrum Guide:
O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. (p. 4).
Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. (p. 8)
Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e riscos podem aumentar. (p. 16)
Então não prevalece a afirmação de que Scrum não aborda o controle de riscos, o que não existe é um processo formal para gerenciamento de riscos, porém o Scrum não é para isso, ele é um framework para outra finalidade, portanto é necessário completá-lo com as devidas técnicas.
O processo "Coletar os Requisitos" do PMBOK documentam as necessidades e podem auxiliar no gerenciamento do backlog do produto e, inclusive, o backlog da sprint, pois auxilia a levantar requisitos e abordar um maior nível de detalhe, o que facilitará o trabalho do time Scrum.
PMBOK 5, p. 110 https://www.scrumguides.org/scrum-guide.html
No Scrum, o product owner é a pessoa que define os itens que compõem o product backlog.
Comentário: o product backlog é uma lista de tudo que precisa ser feito para desenvolver o produto e o dono dessa lista é o product owner (dono do produto). Este é quem decide sobre o produto e, por essa razão, é reponsável por definir as funcionalidades, prioridades, datas de lançamento, entre outras coisas.
No Scrum, o product backlog é uma lista que contém todos os requisitos não funcionais para um software, criada com o uso de ponto de função."
Comentário: product backlog é uma lista de tudo que precisa ser feito para desenvolver o produto. Isto é, tudo que precisa ser "construído para transformar a visão em realidade" [1]. Alguns itens dessa lista podem se classificados como requisito funcional ou requisito não funcional.
Normalmente, estima-se o quanto de esforço (pequeno, médio ou grande?) é necessário para concluir cada item do backlog. Essa estimativa é feita pela equipe que irá construir o produto.
A análise de pontos de função (técnica para quantificar as funcionalidades de um software sob o ponto de vista do usuário) não é utilizada para fazer essa estimativa.
Gabarito: ERRADO.
Referências: [1] Scrum: a arte de fazer o dobro na metade do tempo. Jeff Sutherland. 2014. Pág.: 154.
Por princípio, o processo de Scrum declara o produto como pronto somente ao fim de cada ciclo típico de sprint e após a aprovação formal das justificativas do scrum master pelos stakeholders.
Comentário: Segundo Sommerville [1], "o 'Scrum Master' é um facilitador, que organiza reuniões diárias, controla o backlog de trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerência externa à equipe". O Scrum Master é responsável pelo "uso correto do processo SCRUM e a aplicação das suas regras" [2].
A responsabilidade de aceitar ou rejeitar os resultados dos trabalhos é do Product Owner.
Gabarito: errado.
Referências: [1] Engenharia de Software. Ian Sommerville. 9ª ed. Pág.: 51. [2] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 164.
No Scrum, um dos objetivos da sprint review é mostrar o que foi feito pelos membros da equipe na sprint anterior, ao passo que a retrospectiva visa identificar o que pode ser melhorado na próxima sprint."
Comentário: a sprint review (revisão da sprint) tem como objetivos: apresentar o que a equipe fez; e entregar o produto (software funcionando) ao Product Owner (dono do produto) [1]. Já a sprint retrospective (retrospectiva da sprint) tem como objetivo identificar o que foi bom durante a sp "No Scrum, um dos objetivos da sprint review é mostrar o que foi feito pelos membros da equipe na sprint anterior, ao passo que a retrospectiva visa identificar o que pode ser melhorado na próxima sprint."
Comentário: a sprint review (revisão da sprint) tem como objetivos: apresentar o que a equipe fez; e entregar o produto (software funcionando) ao Product Owner (dono do produto) [1]. Já a sprint retrospective (retrospectiva da sprint) tem como objetivo identificar o que foi bom durante a sprint e o que pode ser melhorado na próxima [1].
Gabarito: CERTO.
[1] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 167.rint e o que pode ser melhorado na próxima [1].
O guia Scrum afirma que apenas o Product Owner possui autoridade para cancelar uma Sprint, mas destaca que ele pode ser influenciado pelo Scrum Master, equipe de desenvolvimento ou de outras partes interessadas para fazê-lo.
O scrum master é o ponto central que detém poderes de liderança sobre o produto"
Comentário: segundo Sommerville [1], "o 'Scrum Master' é um facilitador, que organiza reuniões diárias, controla o backlog de trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerência externa à equipe". Quem decide sobre o produto é o Product Owner (dono do produto) que é responsável por definir as funcionalidades, prioridades, datas de lançamento, entre outras coisas [2].
Gabarito: errado.
[1] Engenharia de Software. Ian Sommerville. 9ª ed. Pág.: 51. [2] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 163.
De maneira geral, o Scrum possui uma ou mais equipes, sendo cada uma composta basicamente de três papéis: o product owner, o scrum master e o time de desenvolvimento.
No Scrum existem esses três papéis:
O Product Owner é responsável por decidir que trabalho deve ser feito e é dono do Product Backlog [1]. Este papel precisa garantir que seja agregado valor ao negócio.
O Scrum Master, segundo Sommerville [2], é um facilitador, que organiza reuniões diárias, controla o backlog de trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerência externa à equipe.
O Time de Desenvolvimento é o time responsável pelo desenvolvimento do projeto.
Gabarito: certo.
[1] Scrum: a arte de fazer o dobro na metade do tempo. Jeff Sutherland. 2014. Pág.: 119. [2] Engenharia de Software. Ian Sommerville. 9ª ed. Pág.: 51.
Uma das características do time de desenvolvimento é a auto-organização; ao se auto-organizar, o time de desenvolvimento determina a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo product owner.
Segundo Pressman [1], a auto-organização é uma das características de uma equipe ágil. Isso implica que a equipe se organiza para o trabalho a ser feito, organiza o processo que melhor se adequa ao seu ambiente local e organiza o cronograma para melhor cumprir a entrega do incremento de software.
Gabarito: certo.
[1] Engenharia de software: uma abordagem profissional. Roger S. Pressman - 7ª ed. - pag. 86.
No Scrum, o product owner,
o Scrum master e demais interessados no produto definem o product backlog, estabelecendo os itens a serem desenvolvidos, ordenados a partir dos mais importantes ou relevantes, e respeitando critérios de ordenação que incluem fatores como valor, custo, conhecimento ou risco.
Segundo Sommerville [1], o Scrum Master é um facilitador, que organiza reuniões diárias, controla o backlog de trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerência externa à equipe.
Quem decide sobre o produto é o Product Owner (dono do produto) que é responsável por elaborar e manter o product backlog, definir as funcionalidades, prioridades, datas de lançamento, entre outras coisas [2].
Assim, o Scrum Master pode até ajudar o Product Owner com o Product Backlog, mas é responsabilidade do Product Owner definir o Product Backlog.
Gabarito: errado.
[1] Engenharia de Software. Ian Sommerville. 9ª ed. Pág.: 51. [2] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 163.
Conforme o Scrum, a equipe de desenvolvimento é responsável por determinar o tamanho do trabalho suficiente para ser entregue na próxima Sprint durante a reunião de planejamento da Sprint.
Antes de cada sprint é feita uma reunião com o objetivo de identificar quais tarefas serão executadas durante a sprint [1]. O Product Owner seleciona os itens de backlog e define a meta e a prioridade da sprint. Já a equipe de desenvolvimento define as tarefas necessárias para cumprir a meta (sprint backlog).
Gabarito: certo.
[1] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 163.
Os itens a serem entregues na sprint como incremento são escolhidos na reunião de planejamento da sprint, na qual o
Scrum masterdetermina a prioridade e a ordem dos itens que comporão a próxima sprint.
Item ERRADO.
A assertiva trata de Scrum, enquanto o enunciado da questão refere explicitamente à gestão ágil de projetos com XP. Em ambos os casos apresentam erros. Considerando que seja uma assertiva que trate de Scrum, o erro está no trecho “..., na qual o Scrum master determina a prioridade e a ordem dos itens que comporão a próxima sprint”. ~
Apesar do Product Owner ser o responsável por determinar a prioridade e a ordem dos itens que comporão a próxima sprint, no evento Planejamento da Sprint, o trabalho colaborativo de todo Time Scrum é o responsável por criar um plano de trabalho para a sprint, segundo o Guia do Scrum.
Logo, uma correção para o trecho seria “..., na qual o Product Owner determina a prioridade e a ordem dos itens que comporão a próxima sprint em trabalho colaborativo de todo Time Scrum”.
[1] : Guia do Scrum – Um guia definitivo para o Scrum: As regras do jogo, Nov. 2017. Disponível em https://www.scrumguides.org/docs/scrumguide/v20...
III. Possuir um papel que gerencie as restrições de escopo, cronograma, custo e qualidade dos projetos individuais.
Cabe ao gerente de projetos, da mesma forma que cabe ao Scrum master, executar as atividades descritas em III.
Segundo Sommerville [1], o Scrum Master é um facilitador, que organiza reuniões diárias, controla o backlog de trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerência externa à equipe.
O Scrum Master é responsável pelo "uso correto do processo SCRUM e a aplicação das suas regras" [2].
Gabarito: errado.
[1] Engenharia de Software. Ian Sommerville. 9ª ed. Pág.: 51. [2] Metodologias ágeis: engenharia de software sob medida. José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. 1. ed. - São Paulo: Érica, 2012. Pág.: 164.
Considere que um sistema está sendo desenvolvimento na Defensoria Pública e algumas das práticas adotadas são listadas a seguir:
− O Time de Desenvolvimento funciona de forma auto-organizada, sendo composto por profissionais que realizam o trabalho de entregar uma versão do sistema que seja funcional e que incrementa o produto “Pronto” ao final de cada sprint. Somente quem integra o Time de Desenvolvimento cria incrementos. − Para desenvolver o sistema podem ser criadas várias sprints. Cada sprint é uma iteração que segue o ciclo PDCA. Ao final de cada sprint bem sucedida o time terá produzido um incremento potencialmente integrável, ou seja, com qualidade, testado, completo e pronto, por isso são realizadas reuniões de planejamento para definir a meta de cada sprint. − O desenvolvedor escreve um teste que falha, faz este teste passar da maneira mais simples possível e, por fim, refatora o código. Esta prática visa a criação de código limpo, atuando como uma ferramenta de apoio na qualidade do desenvolvimento de sistema.
Um Técnico em Informática afirma, corretamente, que