Introdução ao método XP geral 2

Prévia do material em texto

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 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 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 
equipede 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 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. 
 
 
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 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 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 afirmativa III está correta, pois a integração contínua estabelece a união doscó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 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. É importante que o release seja pequeno 
(de dois a três meses) e contenha os requisitosmais 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.