AV POS 2017 GERENCIAMENTO DE PROJETO DE SOFTWARE

Prévia do material em texto

15/09/2017 BDQ Prova
http://simulado.estacio.br/bdq_prova_resultado_preview.asp 1/3
Disciplina: GERENCIAMENTO DE PROJETOS DE SOFTWARE
Avaliação: NPG1397_AV_201604056347 Data: 24/08/2017 15:40:03 (F) Critério: AV
Aluno: RIBEIRO
Professor: RAFAEL DIAS RIBEIRO
 
Turma: 9001/AA
Nota Prova: 10,0 de 10,0 Nota Trab.: Nota Partic.: Nota SIA: 10,0 pts
 
NPG - GERENCIAMENTO DE PROJETOS DE SOFTWARE 
 
 1a Questão (Ref.: 711959) Pontos: 1,0 / 1,0
A ____________________ é uma forma eficaz de reduzir a incidência de bugs em um sistema. Quem trabalha
continuamente com ____________________ se habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao
dia. 
 A incidência de erros identificados pelo colega costuma ser tão elevada que surpreende quem não está acostumado
ao uso da técnica e as equipes que trabalham em par conseguem reduzir drasticamente a inserção de defeitos em
seus códigos. 
 A ____________________ ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de
implementar e mais fáceis de manter. A ____________________ também é uma forma de fazer com que o
desenvolvedor tenha mais confiança no código que produz. Observe que todas estas característica fazem com que a
____________________ acelere o desenvolvimento significativamente, embora à primeira vista pareça o contrário.
 programação em par
propriedade unitária do código
modelagem prévia
elicitação codificada
programação individual
 2a Questão (Ref.: 709030) Pontos: 1,0 / 1,0
Marque a opção que NÃO representa um dos benefícios do uso do Kanban
 Eliminar o Planejamento
Limitar o WIP ( Trabalho em Progresso)
Tornar Regras e Processos Explícitos
Visualizar o Fluxo de Trabalho
Colaboração
 3a Questão (Ref.: 709041) Pontos: 1,0 / 1,0
Com o aumento do projeto é comum que pequenas partes de código mal escrito se acumulem e, quando menos se
esperar, compromete todo o projeto. Este conceito foi nomeado por Joe Yoder como ¿Big Ball of Mud¿. 
 É uma técnica controlada para reestruturar um trecho de código existente, alterando sua estrutura interna sem
modificar seu comportamento externo. 
 O trecho acima refere-se à:
Propriedade Individual de Código
Feedback
Limitar o WIP ( Trabalho em Progresso)
Programação Estruturada
 Refatoração
 4a Questão (Ref.: 709045) Pontos: 1,0 / 1,0
Marque V (verdadeiro) ou F (Falso): 
 ( ) Quando refatoramos constantemente, nosso débito é perceptivelmente menor do que quando refatoramos com
intervalos maiores. 
 ( ) Feedback é um valor que engloba as relações interpessoais, mas também se refere ao feedback que o próprio
15/09/2017 BDQ Prova
http://simulado.estacio.br/bdq_prova_resultado_preview.asp 2/3
código do projeto devolve aos membros do time. 
 ( ) O XP prega que os desenvolvedores precisam ter coragem para refatorar o código em prol de melhorias em
clareza e design e coragem para não tentar prever o futuro, mas sim focar no que é realmente necessário no
momento. XP associa a essa ideia a sigla YAGNI (you ain¿t gonna need it - você não vai precisar disso)
V-F-V
F-V-V
 V-V-V
F-F-V
V-F-F
 5a Questão (Ref.: 709002) Pontos: 1,0 / 1,0
Marque V (verdadeiro) e F (Falso) para as sentenças abaixo: 
 1- Processos e ferramentas não são importantes segundo o Manifesto Ágil, já que priorizam Indivíduos e interações.
 2- Colaboração com o cliente mais que negociação de contratos, significa que não vamos ignorar os contratos , mas
a prioridade é atender o cliente e não parar o projeto para discutir contratos. Os contratos podem/devem ser
negociados sem prejudicar o trabalho em andamento. 
 3- Nos métodos ágeis não planejamos (executamos direto para ganhar tempo)
 F¿V-F
V-V-V
V-V-F
V-F-V
F-F-F
 6a Questão (Ref.: 711931) Pontos: 1,0 / 1,0
Uma das razões por que se mede a velocidade do Time de Desenvolvimento nos Sprints é...
Para que o Product Owner possa cobrar do Time de Desenvolvimento que ele mantenha sempre a mesma
velocidade.
Para que o Product Owner possa cobrar do Time de Desenvolvimento que ele tenha uma velocidade cada vez
maior.
Para que o ScrumMaster possa cobrar do Time de Desenvolvimento que ele mantenha sempre a mesma
velocidade.
 Para ajudar o Time de Desenvolvimento a decidir o quanto do Product Backlog ele irá selecionar para
desenvolver no Sprint.
Não se deve medir a velocidade do Time de Desenvolvimento em nenhum Sprint.
 7a Questão (Ref.: 711950) Pontos: 1,0 / 1,0
Como vimos na aula anterior, o XP prega o uso extensivo de testes automatizados que descrevem o comportamento
de uma funcionalidade, preferencialmente escritos antes mesmo do código que eles testam, prática que recebe o
nome de desenvolvimento dirigido por testes (Test Driven Development - TDD). Os testes automatizados tem 2
funções importantes. Marque a oção que melhor representa estas funções.
 Refatorar e Documentar
Validar com cliente
Planejar e Executar testes na fase de testes
Validar com Scrum Master
Verificar e Validar o plano de testes
 8a Questão (Ref.: 1099348) Pontos: 1,0 / 1,0
Qual afirmação descreve melhor a reunião de revisão da Sprint?
 
É a reunião de avaliação interna do trabalho do time (não do produto).
É uma demonstração no final do Sprint para que todos na organização ofereçam informações sobre o
trabalho realizado.
15/09/2017 BDQ Prova
http://simulado.estacio.br/bdq_prova_resultado_preview.asp 3/3
É uma revisão das atividades da equipe durante o Sprint.
Ele é usado para parabenizar a equipe se ele fez o que comprometeu a fazer ou a equipe se não cumpriu
seus compromissos.
 É quando o time Scrum e as partes interessadas (Dono do Produto/Cliente) verificar se o trabalho proposto
para a Sprint foi realizado de acordo com a definição de pronto e com o estabelecido no inicio da Sprint.
Uma reunião para aprovar ou rejeitar o trabalho do time realizado na sprint.
 9a Questão (Ref.: 802981) Pontos: 1,0 / 1,0
Quando as partes interessadas tem MAIS influência no projeto ?
No meio do projeto
Não influenciam diretamente o projeto
No término do projeto
No início do projeto
 Durante todo o projeto
 10a Questão (Ref.: 711942) Pontos: 1,0 / 1,0
Com que frequência a reunião de retrospectiva deve ser realizada e por quê?
Ao final do projeto, porque as lições aprendidas podem ser usadas nos próximos projetos.
Sempre que solicitado pelo Gerente de Projetos
Sempre que o Time de Desenvolvimento achar necessário, pois o time é auto-organizado.
Se o Time de Desenvolvimento está entregando, a reunião de retrospectiva não é necessária.
 Ao final de cada Sprint, pois é através dela que o Time de Desenvolvimento inspeciona seus processos para
então adaptá-los, de forma a melhorar continuamente.