Aula 13 Exercício

Prévia do material em texto

Aula 13 Exercício – Método XP e suas práticas 
1. No método XP, em relação às práticas de projeto, os desenvolvedores contam com 
auxílio mútuo para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e 
são forçados a realizar testes constantes. 
Em relação às práticas de desenvolvimento XP, a qual prática se refere o texto? 
 
A. Código padronizado. 
 
A prática de código coletivo é a resposta correta. Sua característica é o auxílio mútuo de 
desenvolvedores para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e são 
forçados a realizar testes constantes. A prática de código padronizado não se aplica ao 
texto, pois sua característica é de padronização de codificação. A prática 
de release pequeno não se aplica, pois um release são várias iterações geradas a partir de 
um use case simplificado. A prática de testes constantes não se aplica ao texto, pois refere-
se à execução de testes no decorrer do desenvolvimento. Por fim, a programação em pares 
não se aplica pois refere-se ao ato de unir programadores em pares para o desenvolvimento 
de casos de uso do sistema. 
 
B. Releases pequenos. 
 
A prática de código coletivo é a resposta correta. Sua característica é o auxílio mútuo de 
desenvolvedores para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e são 
forçados a realizar testes constantes. A prática de código padronizado não se aplica ao 
texto, pois sua característica é de padronização de codificação. A prática 
de release pequeno não se aplica, pois um release são várias iterações geradas a partir de 
um use case simplificado. A prática de testes constantes não se aplica ao texto, pois refere-
se à execução de testes no decorrer do desenvolvimento. Por fim, a programação em pares 
não se aplica pois refere-se ao ato de unir programadores em pares para o desenvolvimento 
de casos de uso do sistema. 
 
C. Testes constantes. 
 
A prática de código coletivo é a resposta correta. Sua característica é o auxílio mútuo de 
desenvolvedores para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e são 
forçados a realizar testes constantes. A prática de código padronizado não se aplica ao 
texto, pois sua característica é de padronização de codificação. A prática 
de release pequeno não se aplica, pois um release são várias iterações geradas a partir de 
um use case simplificado. A prática de testes constantes não se aplica ao texto, pois refere-
se à execução de testes no decorrer do desenvolvimento. Por fim, a programação em pares 
não se aplica pois refere-se ao ato de unir programadores em pares para o desenvolvimento 
de casos de uso do sistema. 
 
Resposta Correta! 
D. Código coletivo. 
 
A prática de código coletivo é a resposta correta. Sua característica é o auxílio mútuo de 
desenvolvedores para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e são 
forçados a realizar testes constantes. A prática de código padronizado não se aplica ao 
texto, pois sua característica é de padronização de codificação. A prática 
de release pequeno não se aplica, pois um release são várias iterações geradas a partir de 
um use case simplificado. A prática de testes constantes não se aplica ao texto, pois refere-
se à execução de testes no decorrer do desenvolvimento. Por fim, a programação em pares 
não se aplica pois refere-se ao ato de unir programadores em pares para o desenvolvimento 
de casos de uso do sistema. 
 
E. Programação em par. 
 
A prática de código coletivo é a resposta correta. Sua característica é o auxílio mútuo de 
desenvolvedores para a resolução dos diversos problemas enfrentados na programação. 
Nesse tipo de desenvolvimento, todos devem respeitar um padrão de codificação e são 
forçados a realizar testes constantes. A prática de código padronizado não se aplica ao 
texto, pois sua característica é de padronização de codificação. A prática 
de release pequeno não se aplica, pois um release são várias iterações geradas a partir de 
um use case simplificado. A prática de testes constantes não se aplica ao texto, pois refere-
se à execução de testes no decorrer do desenvolvimento. Por fim, a programação em pares 
não se aplica pois refere-se ao ato de unir programadores em pares para o desenvolvimento 
de casos de uso do sistema. 
 
2. As práticas estabelecidas pelo método XP são utilizadas em vários projetos atuais. Suas 
diretrizes são seguidas há anos por equipes de desenvolvimento e sua eficácia é 
constatada a cada produção de um novo software. Uma das práticas essenciais 
apresentadas pela metodologia XP é a refatoração (refactoring). 
Em relação a essa prática, é correto afirmar que: 
Resposta Correta! 
A. Sua característica principal é a capacidade de mudar o código sem causar problema na 
estrutura do sistema, ou seja, pode sofrer melhorias sem afetar outras funcionalidades 
do sistema. 
 
A refatoração tem a capacidade de melhorar o código do projeto sem interferir na sua 
funcionalidade. Antes de um projeto sofrer uma mudança no código, é fundamental a refatoração, 
pois, com essa prática, é possível facilitar a inserção de novas rotinas no código-fonte. Após o 
uso da refatoração, é importante realizar testes para verificar se o código continua funcionando 
como anteriormente. Portanto, a resposta correta sobre a refatoração (refactoring) é “sua 
capacidade de mudar o código sem causar problema na estrutura do sistema, ou seja, pode 
sofrer melhorias sem afetar outras funcionalidades do sistema”. 
Apesar da prática de refactoring sugerir testes pontuais após sua execução, ela não está 
centrada na realização de testes contínuos em todo o projeto como forma de realocar códigos. 
A prática de programação em pares, pertencente às diretrizes do método XP, tem a função de 
alocar programadores em pares, portanto não compete à etapa de refactoring. 
Um dos pontos principais difundidos pelo método XP é a diminuição de horas extras para a 
equipe de trabalho. Caso elas sejam necessárias, deve-se diagnosticar as práticas atuais do 
projeto para confirmação do uso efetivo do método XP no desenvolvimento. Portanto, rotinas de 
trabalho exaustivo e controle de horas trabalhadas não fazem parte da refatoração. 
O método XP sugere mudanças frequentes no decorrer do ciclo de vida do projeto, portanto não 
sugere o descarte total do código desenvolvido para evitar mudanças futuras no projeto; sua 
prática, inclusive, é tolerável a essas mudanças. 
 
B. Sua característica é permitir que os programadores possam realizar testes frequentes 
no sistema, por realocar os melhores trechos de códigos implementados. 
 
A refatoração tem a capacidade de melhorar o código do projeto sem interferir na sua 
funcionalidade. Antes de um projeto sofrer uma mudança no código, é fundamental a refatoração, 
pois, com essa prática, é possível facilitar a inserção de novas rotinas no código-fonte. Após o 
uso da refatoração, é importante realizar testes para verificar se o código continua funcionando 
como anteriormente. Portanto, a resposta correta sobre a refatoração (refactoring) é “sua 
capacidade de mudar o código sem causar problema na estrutura do sistema, ou seja, pode 
sofrer melhorias sem afetar outras funcionalidades do sistema”. 
Apesar da prática de refactoring sugerir testes pontuais após sua execução, ela não está 
centrada na realização de testes contínuos em todo o projeto como forma de realocar códigos. 
A prática de programação em pares, pertencente às diretrizes do método XP, tem a função de 
alocar programadores em pares, portanto não compete à etapa de refactoring. 
Um dos pontos principais difundidos pelo método XPé a diminuição de horas extras para a 
equipe de trabalho. Caso elas sejam necessárias, deve-se diagnosticar as práticas atuais do 
projeto para confirmação do uso efetivo do método XP no desenvolvimento. Portanto, rotinas de 
trabalho exaustivo e controle de horas trabalhadas não fazem parte da refatoração. 
O método XP sugere mudanças frequentes no decorrer do ciclo de vida do projeto, portanto não 
sugere o descarte total do código desenvolvido para evitar mudanças futuras no projeto; sua 
prática, inclusive, é tolerável a essas mudanças. 
 
C. Sua função é alocar equipes de trabalho verificando os pontos fortes e fracos de cada 
equipe, para a produção de códigos confiáveis. 
 
A refatoração tem a capacidade de melhorar o código do projeto sem interferir na sua 
funcionalidade. Antes de um projeto sofrer uma mudança no código, é fundamental a refatoração, 
pois, com essa prática, é possível facilitar a inserção de novas rotinas no código-fonte. Após o 
uso da refatoração, é importante realizar testes para verificar se o código continua funcionando 
como anteriormente. Portanto, a resposta correta sobre a refatoração (refactoring) é “sua 
capacidade de mudar o código sem causar problema na estrutura do sistema, ou seja, pode 
sofrer melhorias sem afetar outras funcionalidades do sistema”. 
Apesar da prática de refactoring sugerir testes pontuais após sua execução, ela não está 
centrada na realização de testes contínuos em todo o projeto como forma de realocar códigos. 
A prática de programação em pares, pertencente às diretrizes do método XP, tem a função de 
alocar programadores em pares, portanto não compete à etapa de refactoring. 
Um dos pontos principais difundidos pelo método XP é a diminuição de horas extras para a 
equipe de trabalho. Caso elas sejam necessárias, deve-se diagnosticar as práticas atuais do 
projeto para confirmação do uso efetivo do método XP no desenvolvimento. Portanto, rotinas de 
trabalho exaustivo e controle de horas trabalhadas não fazem parte da refatoração. 
O método XP sugere mudanças frequentes no decorrer do ciclo de vida do projeto, portanto não 
sugere o descarte total do código desenvolvido para evitar mudanças futuras no projeto; sua 
prática, inclusive, é tolerável a essas mudanças. 
 
D. Apesar da refatoração permitir rotinas de trabalho exaustivo por parte da equipe, elas 
não poderão ultrapassar as 40 horas trabalhadas. 
 
A refatoração tem a capacidade de melhorar o código do projeto sem interferir na sua 
funcionalidade. Antes de um projeto sofrer uma mudança no código, é fundamental a refatoração, 
pois, com essa prática, é possível facilitar a inserção de novas rotinas no código-fonte. Após o 
uso da refatoração, é importante realizar testes para verificar se o código continua funcionando 
como anteriormente. Portanto, a resposta correta sobre a refatoração (refactoring) é “sua 
capacidade de mudar o código sem causar problema na estrutura do sistema, ou seja, pode 
sofrer melhorias sem afetar outras funcionalidades do sistema”. 
Apesar da prática de refactoring sugerir testes pontuais após sua execução, ela não está 
centrada na realização de testes contínuos em todo o projeto como forma de realocar códigos. 
A prática de programação em pares, pertencente às diretrizes do método XP, tem a função de 
alocar programadores em pares, portanto não compete à etapa de refactoring. 
Um dos pontos principais difundidos pelo método XP é a diminuição de horas extras para a 
equipe de trabalho. Caso elas sejam necessárias, deve-se diagnosticar as práticas atuais do 
projeto para confirmação do uso efetivo do método XP no desenvolvimento. Portanto, rotinas de 
trabalho exaustivo e controle de horas trabalhadas não fazem parte da refatoração. 
O método XP sugere mudanças frequentes no decorrer do ciclo de vida do projeto, portanto não 
sugere o descarte total do código desenvolvido para evitar mudanças futuras no projeto; sua 
prática, inclusive, é tolerável a essas mudanças. 
 
E. Sua característica principal é o retrabalho, ou seja, reescrever todo o código para 
impedir alterações futuras que possam comprometer a estrutura do projeto final. 
 
A refatoração tem a capacidade de melhorar o código do projeto sem interferir na sua 
funcionalidade. Antes de um projeto sofrer uma mudança no código, é fundamental a refatoração, 
pois, com essa prática, é possível facilitar a inserção de novas rotinas no código-fonte. Após o 
uso da refatoração, é importante realizar testes para verificar se o código continua funcionando 
como anteriormente. Portanto, a resposta correta sobre a refatoração (refactoring) é “sua 
capacidade de mudar o código sem causar problema na estrutura do sistema, ou seja, pode 
sofrer melhorias sem afetar outras funcionalidades do sistema”. 
Apesar da prática de refactoring sugerir testes pontuais após sua execução, ela não está 
centrada na realização de testes contínuos em todo o projeto como forma de realocar códigos. 
A prática de programação em pares, pertencente às diretrizes do método XP, tem a função de 
alocar programadores em pares, portanto não compete à etapa de refactoring. 
Um dos pontos principais difundidos pelo método XP é a diminuição de horas extras para a 
equipe de trabalho. Caso elas sejam necessárias, deve-se diagnosticar as práticas atuais do 
projeto para confirmação do uso efetivo do método XP no desenvolvimento. Portanto, rotinas de 
trabalho exaustivo e controle de horas trabalhadas não fazem parte da refatoração. 
O método XP sugere mudanças frequentes no decorrer do ciclo de vida do projeto, portanto não 
sugere o descarte total do código desenvolvido para evitar mudanças futuras no projeto; sua 
prática, inclusive, é tolerável a essas mudanças. 
 
3. A dinâmica do trabalho em pares no método XP permite que visões diferentes sejam 
contempladas no decorrer da programação; enquanto um programador digita um trecho 
de códigos, o outro poderá analisar os códigos como um todo e apontar possíveis 
problemas. 
Em relação à prática de programação em pares, é correto afirmar que: 
A. Os grupos são escolhidos a partir de avaliações internas na empresa. Seu desempenho 
satisfatório nos testes realizados será fator essencial para o início dos trabalhos. 
 
A programação em pares do método XP sugere o trabalho com equipes de dois programadores 
trabalhando em apenas uma máquina, onde um codifica e o outro critica ou dá sugestões. Os 
pares trocam de lugar periodicamente e são organizados pelos próprios desenvolvedores ou 
pessoa alocada para gerenciamento das equipes. Essa prática é excelente e favorece 
comunicação e aprendizado. A resposta correta, portanto, é que “os programadores têm 
autonomia na sugestão da montagem da equipe de trabalho. Eles deverão oferecer todo o 
suporte necessário para o sucesso de sua equipe de trabalho, mesmo que seja necessário 
auxiliar um colega inexperiente”. Como os grupos são gerenciados pelos próprios 
desenvolvedores, todos possuem responsabilidade pelo projeto desenvolvido e não existe 
avaliação interna para a formação dos grupos. Os gerentes de projetos não são os únicos que 
escolhem a equipe de trabalho, as opiniões dos desenvolvedores devem ser consideras. Não 
existe realocação de equipes quando são encontrados bugs no código, eles devem ser 
resolvidos pelo próprio grupo e, após sua resolução, seguem com a codificação de sua 
funcionalidade. Não existe categorização de duplas de trabalho por experiência, portanto um 
grupo formado por um programador experiente com um programador novato deve se ajudar 
mutuamente. 
 
B. Os gerentes de projetos são os únicos que escolhem as equipes de trabalho. A equipe 
é determinada pela experiência prévia de cada programador desempenhada em projetos 
anteriores. 
 
A programação em pares do método XP sugere o trabalho com equipes de dois programadores 
trabalhando em apenas uma máquina, onde um codifica e o outro critica ou dá sugestões. Os 
pares trocam de lugar periodicamente e são organizados pelos próprios desenvolvedores oupessoa alocada para gerenciamento das equipes. Essa prática é excelente e favorece 
comunicação e aprendizado. A resposta correta, portanto, é que “os programadores têm 
autonomia na sugestão da montagem da equipe de trabalho. Eles deverão oferecer todo o 
suporte necessário para o sucesso de sua equipe de trabalho, mesmo que seja necessário 
auxiliar um colega inexperiente”. Como os grupos são gerenciados pelos próprios 
desenvolvedores, todos possuem responsabilidade pelo projeto desenvolvido e não existe 
avaliação interna para a formação dos grupos. Os gerentes de projetos não são os únicos que 
escolhem a equipe de trabalho, as opiniões dos desenvolvedores devem ser consideras. Não 
existe realocação de equipes quando são encontrados bugs no código, eles devem ser 
resolvidos pelo próprio grupo e, após sua resolução, seguem com a codificação de sua 
funcionalidade. Não existe categorização de duplas de trabalho por experiência, portanto um 
grupo formado por um programador experiente com um programador novato deve se ajudar 
mutuamente. 
 
C. A realocação de grupos ocorre quando são encontrados bugs nos códigos-fonte da 
equipe. Depois de solucionar os bugs, outra equipe é formada para dar continuidade à 
funcionalidade. 
 
A programação em pares do método XP sugere o trabalho com equipes de dois programadores 
trabalhando em apenas uma máquina, onde um codifica e o outro critica ou dá sugestões. Os 
pares trocam de lugar periodicamente e são organizados pelos próprios desenvolvedores ou 
pessoa alocada para gerenciamento das equipes. Essa prática é excelente e favorece 
comunicação e aprendizado. A resposta correta, portanto, é que “os programadores têm 
autonomia na sugestão da montagem da equipe de trabalho. Eles deverão oferecer todo o 
suporte necessário para o sucesso de sua equipe de trabalho, mesmo que seja necessário 
auxiliar um colega inexperiente”. Como os grupos são gerenciados pelos próprios 
desenvolvedores, todos possuem responsabilidade pelo projeto desenvolvido e não existe 
avaliação interna para a formação dos grupos. Os gerentes de projetos não são os únicos que 
escolhem a equipe de trabalho, as opiniões dos desenvolvedores devem ser consideras. Não 
existe realocação de equipes quando são encontrados bugs no código, eles devem ser 
resolvidos pelo próprio grupo e, após sua resolução, seguem com a codificação de sua 
funcionalidade. Não existe categorização de duplas de trabalho por experiência, portanto um 
grupo formado por um programador experiente com um programador novato deve se ajudar 
mutuamente. 
 
D. Existem duas categorias nas duplas de trabalho: uma é formada por programadores 
experientes e a outra é formada por programadores novatos. Após essa categorização, 
são formadas as duplas, que seguirão juntas por todo o projeto. 
 
A programação em pares do método XP sugere o trabalho com equipes de dois programadores 
trabalhando em apenas uma máquina, onde um codifica e o outro critica ou dá sugestões. Os 
pares trocam de lugar periodicamente e são organizados pelos próprios desenvolvedores ou 
pessoa alocada para gerenciamento das equipes. Essa prática é excelente e favorece 
comunicação e aprendizado. A resposta correta, portanto, é que “os programadores têm 
autonomia na sugestão da montagem da equipe de trabalho. Eles deverão oferecer todo o 
suporte necessário para o sucesso de sua equipe de trabalho, mesmo que seja necessário 
auxiliar um colega inexperiente”. Como os grupos são gerenciados pelos próprios 
desenvolvedores, todos possuem responsabilidade pelo projeto desenvolvido e não existe 
avaliação interna para a formação dos grupos. Os gerentes de projetos não são os únicos que 
escolhem a equipe de trabalho, as opiniões dos desenvolvedores devem ser consideras. Não 
existe realocação de equipes quando são encontrados bugs no código, eles devem ser 
resolvidos pelo próprio grupo e, após sua resolução, seguem com a codificação de sua 
funcionalidade. Não existe categorização de duplas de trabalho por experiência, portanto um 
grupo formado por um programador experiente com um programador novato deve se ajudar 
mutuamente. 
 
Resposta Correta! 
E. Os programadores têm autonomia na sugestão da montagem da equipe de trabalho. 
Eles deverão oferecer todo o suporte necessário para o sucesso de sua equipe de 
trabalho, mesmo que seja necessário auxiliar um colega inexperiente. 
 
A programação em pares do método XP sugere o trabalho com equipes de dois programadores 
trabalhando em apenas uma máquina, onde um codifica e o outro critica ou dá sugestões. Os 
pares trocam de lugar periodicamente e são organizados pelos próprios desenvolvedores ou 
pessoa alocada para gerenciamento das equipes. Essa prática é excelente e favorece 
comunicação e aprendizado. A resposta correta, portanto, é que “os programadores têm 
autonomia na sugestão da montagem da equipe de trabalho. Eles deverão oferecer todo o 
suporte necessário para o sucesso de sua equipe de trabalho, mesmo que seja necessário 
auxiliar um colega inexperiente”. Como os grupos são gerenciados pelos próprios 
desenvolvedores, todos possuem responsabilidade pelo projeto desenvolvido e não existe 
avaliação interna para a formação dos grupos. Os gerentes de projetos não são os únicos que 
escolhem a equipe de trabalho, as opiniões dos desenvolvedores devem ser consideras. Não 
existe realocação de equipes quando são encontrados bugs no código, eles devem ser 
resolvidos pelo próprio grupo e, após sua resolução, seguem com a codificação de sua 
funcionalidade. Não existe categorização de duplas de trabalho por experiência, portanto um 
grupo formado por um programador experiente com um programador novato deve se ajudar 
mutuamente. 
 
4. A prática da integração contínua faz parte do conjunto das doze práticas fundamentais 
para o desenvolvimento de um projeto de programação extrema. O conjunto de todas as 
práticas permite à equipe excelência em seus processos. 
 
Analise as afirmações a seguir sobre a prática de interação contínua. 
I - Testar toda a aplicação sempre que uma nova funcionalidade é implementada. 
II - Testar os códigos do sistema com o uso de ferramentas automatizadas de 
desenvolvimento ou a partir de rotinas manuais definidas pelos programadores. 
III - Une o trabalho desenvolvido por uma equipe de trabalho, composta por dois 
programadores (programação em par), a todo o código do projeto. 
 
IV - Estabelecer que o par de desenvolvedores separe todo o código testado do restante 
gerado de forma coletiva; essa prática impede a interferência de inserção de códigos em 
métodos de outras equipes. 
V - Produzir trabalho disciplinado e organizado com alocação de horas extras essenciais 
para a finalização e homologação do projeto. 
As afirmações que representam de forma correta as práticas de interação contínua são: 
A. I - II - V. 
 
A afirmativa I está correta, pois as práticas de integração contínua estabelecem o teste de toda 
a aplicação sempre que existir uma nova funcionalidade. A afirmativa II está correta, 
pois a integração contínua estabelece testes que podem ser automatizados ou realizados de 
forma manual. A afirmativa III está correta, pois a integração contínua estabelece a união dos 
códigos dos grupos para composição do projeto final. A afirmativa IV está incorreta, pois 
a integração contínua estabelece que os códigos devem ser unidos e não separados entre 
grupos de trabalhos, portanto é natural que ocorra inserções ou alterações no código. A 
afirmativa V está incorreta, pois não é função da prática de integração contínua definir alocação 
de horas extras. Vale ressaltar que essa prática, inclusive, deve ser evitada no método XP. 
 
Resposta Certa! 
B. I - II - III. 
 
A afirmativa I está correta, pois as práticas de integração contínua estabelecem o teste de toda 
a aplicação sempre que existir uma nova funcionalidade. A afirmativa II está correta, 
pois a integração contínua estabelece testes que podem ser automatizados ou realizados de 
forma manual. A afirmativaIII está correta, pois a integração contínua estabelece a união dos 
códigos dos grupos para composição do projeto final. A afirmativa IV está incorreta, pois 
a integração contínua estabelece que os códigos devem ser unidos e não separados entre 
grupos de trabalhos, portanto é natural que ocorra inserções ou alterações no código. A 
afirmativa V está incorreta, pois não é função da prática de integração contínua definir alocação 
de horas extras. Vale ressaltar que essa prática, inclusive, deve ser evitada no método XP. 
 
C. I - III - IV - V. 
 
A afirmativa I está correta, pois as práticas de integração contínua estabelecem o teste de toda 
a aplicação sempre que existir uma nova funcionalidade. A afirmativa II está correta, 
pois a integração contínua estabelece testes que podem ser automatizados ou realizados de 
forma manual. A afirmativa III está correta, pois a integração contínua estabelece a união dos 
códigos dos grupos para composição do projeto final. A afirmativa IV está incorreta, pois 
a integração contínua estabelece que os códigos devem ser unidos e não separados entre 
grupos de trabalhos, portanto é natural que ocorra inserções ou alterações no código. A 
afirmativa V está incorreta, pois não é função da prática de integração contínua definir alocação 
de horas extras. Vale ressaltar que essa prática, inclusive, deve ser evitada no método XP. 
 
D. I - II - III - IV - V. 
 
A afirmativa I está correta, pois as práticas de integração contínua estabelecem o teste de toda 
a aplicação sempre que existir uma nova funcionalidade. A afirmativa II está correta, 
pois a integração contínua estabelece testes que podem ser automatizados ou realizados de 
forma manual. A afirmativa III está correta, pois a integração contínua estabelece a união dos 
códigos dos grupos para composição do projeto final. A afirmativa IV está incorreta, pois 
a integração contínua estabelece que os códigos devem ser unidos e não separados entre 
grupos de trabalhos, portanto é natural que ocorra inserções ou alterações no código. A 
afirmativa V está incorreta, pois não é função da prática de integração contínua definir alocação 
de horas extras. Vale ressaltar que essa prática, inclusive, deve ser evitada no método XP. 
 
E. I - II - III - V. 
 
A afirmativa I está correta, pois as práticas de integração contínua estabelecem o teste de toda 
a aplicação sempre que existir uma nova funcionalidade. A afirmativa II está correta, 
pois a integração contínua estabelece testes que podem ser automatizados ou realizados de 
forma manual. A afirmativa III está correta, pois a integração contínua estabelece a união dos 
códigos dos grupos para composição do projeto final. A afirmativa IV está incorreta, pois 
a integração contínua estabelece que os códigos devem ser unidos e não separados entre 
grupos de trabalhos, portanto é natural que ocorra inserções ou alterações no código. A 
afirmativa V está incorreta, pois não é função da prática de integração contínua definir alocação 
de horas extras. Vale ressaltar que essa prática, inclusive, deve ser evitada no método XP. 
 
5. Para aplicar os valores e princípios durante o desenvolvimento de software, a 
XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas; 
os pontos fracos de cada uma são superados pelos pontos fortes de outras. 
Algumas práticas apresentam as seguintes características: 
I - Reunião que conta com a colaboração de todos da equipe. O cliente, bem como todos 
os envolvidos no projeto, deverá fazer parte dessa reunião. 
II - Controle de horas excedentes com o objetivo de evitar queda de produtividade e 
qualidade no código gerado. 
III - Visão geral do sistema apresentada de forma simples, para ser compartilhada entre 
clientes e desenvolvedores. 
IV - Várias iterações que ocorrem no decorrer do projeto, gerando casos de usos 
simplificados. 
Em relação as práticas de metáfora, releases pequenos, jogo de planejamento e semana 
de quarenta horas, a alternativa que representa, respectivamente, as características de 
cada prática é: 
A. III - II - I - IV. 
 
Metáfora: visão geral do sistema, apresentada de forma simples para ser compartilhada entre 
clientes e programadores. Encontrar nomes simples para as principais características do 
desenvolvimento é primordial para o entendimento de todos. Releases pequenos: 
um release significa várias iterações, onde para cada uma é gerado um use case simplificado. 
Cabe ao cliente selecionar qual será implementado. É importante que o release seja pequeno 
(de dois a três meses) e contenha os requisitos mais importantes para o negócio. Quanto mais 
releases, maior será o feedback para os clientes e programadores. Jogo de planejamento: trata-
se de uma reunião que conta com a colaboração de todos da equipe. É possível dividir os 
envolvidos por área de atuação: negócios (pessoas que conhecem a área de negócios) e parte 
técnica (pessoas envolvidas na implementação e descrição das funcionalidades). Semana de 
quarenta horas: as equipes não devem ultrapassar duas semanas além das 40 horas semanais 
estabelecidas de trabalho. Caso ocorra horas excedentes, isso poderá resultar em queda de 
produtividade e de qualidade no código gerado. 
 
B. I - II - III - IV. 
 
Metáfora: visão geral do sistema, apresentada de forma simples para ser compartilhada entre 
clientes e programadores. Encontrar nomes simples para as principais características do 
desenvolvimento é primordial para o entendimento de todos. Releases pequenos: 
um release significa várias iterações, onde para cada uma é gerado um use case simplificado. 
Cabe ao cliente selecionar qual será implementado. É importante que o release seja pequeno 
(de dois a três meses) e contenha os requisitos mais importantes para o negócio. Quanto mais 
releases, maior será o feedback para os clientes e programadores. Jogo de planejamento: trata-
se de uma reunião que conta com a colaboração de todos da equipe. É possível dividir os 
envolvidos por área de atuação: negócios (pessoas que conhecem a área de negócios) e parte 
técnica (pessoas envolvidas na implementação e descrição das funcionalidades). Semana de 
quarenta horas: as equipes não devem ultrapassar duas semanas além das 40 horas semanais 
estabelecidas de trabalho. Caso ocorra horas excedentes, isso poderá resultar em queda de 
produtividade e de qualidade no código gerado. 
 
Resposta Certa! 
C. III - IV - I - II. 
 
Metáfora: visão geral do sistema, apresentada de forma simples para ser compartilhada entre 
clientes e programadores. Encontrar nomes simples para as principais características do 
desenvolvimento é primordial para o entendimento de todos. Releases pequenos: 
um release significa várias iterações, onde para cada uma é gerado um use case simplificado. 
Cabe ao cliente selecionar qual será implementado. É importante que o release seja pequeno 
(de dois a três meses) e contenha os requisitos mais importantes para o negócio. Quanto mais 
releases, maior será o feedback para os clientes e programadores. Jogo de planejamento: trata-
se de uma reunião que conta com a colaboração de todos da equipe. É possível dividir os 
envolvidos por área de atuação: negócios (pessoas que conhecem a área de negócios) e parte 
técnica (pessoas envolvidas na implementação e descrição das funcionalidades). Semana de 
quarenta horas: as equipes não devem ultrapassar duas semanas além das 40 horas semanais 
estabelecidas de trabalho. Caso ocorra horas excedentes, isso poderá resultar em queda de 
produtividade e de qualidade no código gerado. 
 
D. I - II - IV - III. 
 
Metáfora: visão geral do sistema, apresentada de forma simples para ser compartilhada entre 
clientes e programadores. Encontrar nomes simples para as principais características do 
desenvolvimento é primordial para o entendimento de todos. Releases pequenos: 
um release significa várias iterações, onde para cada uma é gerado um use case simplificado. 
Cabe ao cliente selecionar qual será implementado. É importanteque o release seja pequeno 
(de dois a três meses) e contenha os requisitos mais importantes para o negócio. Quanto mais 
releases, maior será o feedback para os clientes e programadores. Jogo de planejamento: trata-
se de uma reunião que conta com a colaboração de todos da equipe. É possível dividir os 
envolvidos por área de atuação: negócios (pessoas que conhecem a área de negócios) e parte 
técnica (pessoas envolvidas na implementação e descrição das funcionalidades). Semana de 
quarenta horas: as equipes não devem ultrapassar duas semanas além das 40 horas semanais 
estabelecidas de trabalho. Caso ocorra horas excedentes, isso poderá resultar em queda de 
produtividade e de qualidade no código gerado. 
 
E. III - IV - II - I. 
 
Metáfora: visão geral do sistema, apresentada de forma simples para ser compartilhada entre clientes e 
programadores. Encontrar nomes simples para as principais características do desenvolvimento é 
primordial para o entendimento de todos. Releases pequenos: um release significa várias iterações, onde 
para cada uma é gerado um use case simplificado. Cabe ao cliente selecionar qual será implementado. É 
importante que o release seja pequeno (de dois a três meses) e contenha os requisitos mais importantes 
para o negócio. Quanto mais releases, maior será o feedback para os clientes e programadores. Jogo de 
planejamento: trata-se de uma reunião que conta com a colaboração de todos da equipe. É possível dividir 
os envolvidos por área de atuação: negócios (pessoas que conhecem a área de negócios) e parte técnica 
(pessoas envolvidas na implementação e descrição das funcionalidades). Semana de quarenta horas: as 
equipes não devem ultrapassar duas semanas além das 40 horas semanais estabelecidas de trabalho. 
Caso ocorra horas excedentes, isso poderá resultar em queda de produtividade e de qualidade no código 
gerado.