Exercicíos Scrum e o planejamento

Prévia do material em texto

1. 
Uma importante ferramenta utilizada na gestão de projetos é a Planning Poker. Sobre ela, analise as afirmativas a seguir:
I. É um método que privilegia a opinião do "jogador" ganhador em detrimento da opinião dos demais.
II. O "jogo" é composto por cartas com números que representam esforço estimado.
III. O "jogo" tem 356 cartas.
IV. Há uma forte interação entre os "jogadores" e product owners, que discutem questões do projeto antes de realizarem suas jogadas.
Estão corretas as afirmativas:
Você acertou!
A. 
II e IV.
A afirmativa I está incorreta, pois o Planning Poker não privilegia a opinião do "jogador" ganhador, pois todos têm a mesma importância no jogo. A afirmativa II está correta, já que o "jogo" é composto por cartas com números que representam o esforço estimado da História do Usuário. A afirmativa III está incorreta, uma vez que esse jogo não tem 2. 
Em todos os projetos que utilizam a metodologia ágil Scrum, existe uma divisão das atividades a serem realizadas em Sprints. Em um Sprint de desenvolvimento, o Scrum Master solicita à equipe uma reunião para alinhar as atividades. Nessa reunião, os integrantes foram convidados a avaliar a complexidade das Histórias de Usuários e apresentar uma nota que é representada pela escolha de uma carta de baralho.
Dentro do conceito de Scrum, dá-se o nome a essa reunião de:
Você acertou!
A. 
Planning Poker.
O Planning Poker é uma técnica utilizada em Scrum para a definição da complexidade de uma tarefa a partir da análise de uma História de Usuário. Esse processo ocorre como em um jogo de pôquer, com cartas especiais que representam a complexidade da tarefa. Já o CALL não está correto, pois representa uma chamada que não está associada à questão. O Sprints também não está correto, pois o conceito está ligado a uma fase do projeto Scrum. Kick-off não está correto, uma vez que representa o início de um projeto. Por fim, Daily Scrum também não está correto por representar uma reunião diária realizada pela metodologia do Scrum.
356 cartas, e, sim, em média, 14 cartas que representam a sequência adaptada de Fibonacci e outros símbolos como zero, infinito, interrogação e café. A afirmativa IV está correta, pois, realmente, há uma grande interação entre os "jogadores" e product owners, que debatem pontos do projeto antes de realizarem suas jogadas.
3. 
A análise por ponto de função é realizada como um estratégia para definir estimativas em projetos ágeis de software.
A partir do conceito de análise de pontos por função, analise as seguintes afirmativas:
I. É feita com base na especificação funcional do software.
II. Define uma pontuação para determinadas características do software, de acordo com seu nível de complexidade.
III. O valor apresentado pela análise de pontos por função é a quantidade de dias de duração do projeto.
IV. A análise de pontos por função é restrita a softwares orientados a objetos.
V. Avalia entradas, saídas e consultas dos usuários, além dos dados utilizados pelo sistema.
Quais afirmativas estão corretas?
Você acertou!
D. 
I, II e V.
A afirmativa I está correta, pois a análise de pontos por função é realizada a partir das especificações funcionais do software.
A afirmativa II está correta, uma vez que, a partir do nível de complexidade das características do software, é definida uma pontuação.
A afirmativa III está incorreta, já que o valor apresentado pela análise de pontos por função define uma estimativa comparada e não está diretamente associado à quantidade de dias de duração do projeto. 
A afirmativa IV está incorreta, pois a análise de pontos por função pode ser utilizada para qualquer tipo de linguagem de desenvolvimento de software e não está restrita a softwares orientados a objetos.
A afirmativa V está correta, pois a análise por ponto de função considera outros aspectos para a definição da pontuação, tais como: entradas, saídas e consultas dos usuários, além dos dados utilizados pelo sistema.
4. 
A análise de ponto por função é utilizada como estratégia para estimar a complexidade de um projeto, principamente quando se trata de um projeto de escala corporatva.
A análise de pontos por função é um método que:
Você acertou!
B. 
padroniza a medição de projetos de desenvolvimento de software. O objetivo é definir uma estimativa de tamanho, chamada de pontos de função, que considera as funcionalidades efetivadas a partir da ótica do usuário.
A análise de pontos por função permite que exista uma medição padronizada de projetos de desenvolvimento de software. Essa estimativa de tamanho, denominada pontos de função, considera as funcionalidades implementadas por meio do ponto de vista do usuário. A tecnologia não é considerada um fator decisivo no projeto. O foco de medição não é centrado no analista ou gerente de projetos, e, sim, no usuário.  A análise é feita no projeto como um todo, e não apenas em parâmetros de retorno diferente de nulo (null) e também em outros parâmetros que indicam erro de código.  A verificação das telas dos sistemas não é considerada nesse tipo de análise. ​​​​​​​
5. 
Todo projeto de criação de um software tem diversas fases de acordo com a metodologia escolhida.
Leve em consideração uma empresa desenvolvedora de software que tem um processo de software composto pelas seguintes fases: Levantamento de Requisitos, Análise de Software, Projeto de Software, Codificação, Testes e Entrega do Software. Além disso, tem a cultura de estimar seus projetos utilizando Análise de Pontos por Função.
Caso essa organização esteja interessada na criação de uma referência de estimativas de seus projetos, a contagem de pontos por função seria mais indicada em qual momento?
Você acertou!
D. 
No início do projeto, para poder estimar a duração do projeto e elaborar um cronograma inicial, depois do detalhamento dos requisitos para refinar o cronograma e após o software ter sido concluído para, com base no tamanho real, recalcular a taxa média de produtividade da organização. 
A análise de pontos por função deve ser feita no início do projeto, pois, dessa forma, é possível definir uma estimativa da duração do projeto e, com isso, elaborar um cronograma inicial. Após o detalhamento dos requisitos, a estimativa será utilizada para refinar o cronograma e, por fim, após o software ter sido concluído, com base no tamanho real, pode-se recalcular a taxa média de produtividade da organização. As etapas de Análise de Software, Levantamento de Requisitos, Projeto de Software e Codificação deverão ser feitas após a definição inicial das estimativas levantadas pela aplicação da análise de pontos por função. ​​​​​​​​​​​​​​