diovanemonteiro / resumos

Esse repositório tem a intenção de ser uma coleção de resumos sobre meus estudos para concursos públicos da área de Tecnologia da Informação
http://diovanemonteiro.github.io/resumos
0 stars 0 forks source link

SCRUM #14

Open diovanemonteiro opened 5 years ago

diovanemonteiro commented 5 years ago

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

a) todas as práticas indicam que a Defensoria adota somente a metodologia SCRUM. 
b) todas as práticas indicam que a Defensoria adota somente a metodologia XP. 
c) nenhuma das práticas indica que a Defensoria adota uma metodologia ágil de desenvolvimento. 
d) as práticas indicam que a Defensoria adota o desenvolvimento baseado em componentes. 
e) as práticas indicam que a Defensoria adota uma metodologia híbrida que reúne práticas ágeis. 
diovanemonteiro commented 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.

diovanemonteiro commented 5 years ago

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.

Referências

PMBOK 5, p. 110 https://www.scrumguides.org/scrum-guide.html

diovanemonteiro commented 5 years ago

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.

diovanemonteiro commented 5 years ago

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.

diovanemonteiro commented 5 years ago

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.

diovanemonteiro commented 5 years ago

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.

Referências:

[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].

diovanemonteiro commented 5 years ago

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.

diovanemonteiro commented 5 years ago

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.

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.: 163.

diovanemonteiro commented 5 years ago

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.

Comentário

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.

Referências

[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.

diovanemonteiro commented 5 years ago

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.

Comentário

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.

Referências

[1] Engenharia de software: uma abordagem profissional. Roger S. Pressman - 7ª ed. - pag. 86.

diovanemonteiro commented 5 years ago

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.

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 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.

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.: 163.

diovanemonteiro commented 5 years ago

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.

Comentário

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.

Referências

[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.

diovanemonteiro commented 5 years ago

Os itens a serem entregues na sprint como incremento são escolhidos na reunião de planejamento da sprint, na qual o Scrum master determina a prioridade e a ordem dos itens que comporão a próxima sprint.

Comentário

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”.

Referência

[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...

diovanemonteiro commented 5 years ago

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.

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].

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.