-
c) No XP, não há indicação de que é necessário criar documentação no código porém, os documentos tradicionais são reduzidos aos aspectos mais relevantes, visando obter no final do processo, apenas artefatos e grande importância para o projeto.
A DESCRIÇÃO ACIMA ESTARIA CORRETA SE NO LUGAR DE XP TIVESSE SCRUM. O PRINCIPAL ERRO DA QUESTÃO ESTAR EM DIZER QUE NO XP NÃO SE PRECISA DOCUMENTAR NO CÓDIGO.
-
O XP define algumas documentações mais simples, como por exemplo um modelo de arquitetura feito em um quadro branco e cartões CRC para definições das classes.
-
A resposta E está incorreta, segundo o livro Extreme Programming de Vinícius Teles. Na página 84 ele afirma o seguinte: "O cliente pode alterar as est[orias que serão implementadas em um release. Já no caso da iteração isto não é possível. Uma vez que o cliente priorize um conjunto de estórias para uma iteração, a equipe irá trabalhar somente naquelas estórias e não aceitará que o usuário faça mudanças"
Logo o XP não é receptivo a mudanças durante a iteração.
-
Comentário da letra C: "[...] os documentos tradicionais são reduzidos aos apectos mais relevantes[...]".
O único produto de trabalho (artefato) do XP são os cartões CRC. O XP produz muito pouco ou nenhum artefato atém dos cartões CRC. Assim, não há documentos tradicionais.
Comentário da letra E: "[...]no SCRUM as solicitações do cliente demvem aguardar o término da iteração em andamento".
Pressman diz que enquanto um sprint está em andamento, as pendências a que ele se relaciona são congelados, ou seja, não podem ser inseridas modificações. Contudo, dá para entender que pela passagem do livro que enquanto um sprint em andamento está trabalhando em uma ou mais pendências, somente essas pensdências ficam congeladas e modificações não podem ser inseridas. As demais não se encontram congeladas e assim, solicitações de modificação podem ser inseridas.
-
Comentário da letra E: "[...]no SCRUM as solicitações do cliente devem aguardar o término da iteração em andamento".
Se a Equipe de Desenvolvimento determina que tem
excesso ou falta de trabalho, os
itens do Backlog da Sprint pode ser renegociados com o
Product Owner. Somente a Equipe de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que a Equipe de Desenvolvimento planeja completar durante a Sprint, e
pertence exclusivamente à
Equipe de Desenvolvimento O
Product Owner é a única pessoa responsável por gerenciar o
Backlog do Produto.
Revisão da Sprint
A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que precisam ser prontas. Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.
Como vimos o cliente pode alterar o Backlog do Produto a qualquer momento porque é responsável por este artefato, porém "solicitações do cliente" nos remete a uma comunicação do cliente com os demais membros do time scrum, e portanto seria uma modificação do Backlog da Sprint.
Que só são modificadas em caso de excesso ou falta de trabalho, de acordo com a visão da Equipe de Desenvolvimento.
-
"O SCRUM tem como características a divisão do processo em pequenos ciclos de desenvolvimento chamados Sprint, o monitoramento do progresso do processo através de reuniões diárias com toda a equipe e, reuniões com os Stakeholders no fim de cada ciclo de desenvolvimento."
Reuniões com stakeholders?tá certo isso?
-
Pessoal, vamos lá.
Se o XP recomenda práticas como programação em pares e código coletivo, a documentação no código se torna necessária. Do contrário, como imaginar que qualquer programador possa alterar qualquer parte do código, sem o mínimo de orientação sobre o que exatamente aquele trecho de código se propõe a fazer.
Questão fácil de matar por eliminação e seguindo este raciocínio.
Bons estudos.
-
Um dúvida na letra B. As reuniões feitas após uma sprint não são feitas apenas com o Product Owner. O termo Stakeholders não está generalizando?
-
Além de citar reunião com os Stakeholders, o que pode abranger o cliente, não necessariamente algo obrigatório já que não fala TODOS os Stakeholders, visto que o temo generaliza todos os INTERESSADOS no projeto de algum modo, ainda cita o termo "com toda equipe" não deixa claro que equipe está sendo considerada, as reuniões diárias ocorrem apenas com a equipe de desenvolvimento, diferente de uma reunião de fim de ciclo com os interessados no projeto, correto?
-
EITA QUESTÃO DANADA DE MAL ELABORADA!
-
Opinião sobre a letra (e). O que se prevalece é aquilo que o SCRUM diz e não o sr. Pressman
"During the Sprint:
- No changes are made that would affect the Sprint Goal"
Da licença né? se o cliente pedir para mudar a cor de um grid para melhor visualizar os registros vai ter que esperar por 1mês?
-
Acho que esse é um bom artigo para abordar essa questão: http://www.eventosufrpe.com.br/jepex2009/cd/resumos/R0484-2.pdf
-
Apenas reforçando o que foi dito:
A alternativa "E" não está completamente correta, umas vez que o guia Oficial do Scrum afirma:
"During the Sprint:
No changes are made that would endanger the Sprint Goal;" Ou seja, as modificações são aceitas, desde que não coloque em perigo as metas da Sprint.
-
Este e o motivo da letra do gabarito ser incorreta :
"visando obter no final do processo, apenas artefatos de grande importância para o projeto."
Deve-se obter no final do 'processo' ou 'projeto' aquilo que adiciona valor ao "software" ou ao "negócio do cliente".
'APENAS ....para o projeto'
Software em funcionamento mais que documentação abrangente: a
documentação deve existir para ajudar pessoas a entender como o sistema foi
construído.
http://www.manifestoagil.com.br/
-
o erro da questão é dizer que no XP não há necessidade de criar a documentação no código.
Metodologias ágeis como a XP enfatizam a documentação de software no próprio código, seguindo os padrões de codificação que é uma das boas práticas que é justamente você comentar o seu código nas interfaces dos métodos, funções.
-
Na minha visão, o maior erro da alternativa D) é dizer que se deve obter apenas artefatos de grande para o projeto. XP preconiza pequenos releases que vão sendo incrementados ao primeiro release, de forma que seja possível realizar releases frequentes.
-
c)No XP, não há indicação de que é necessário criar documentação no código porém, os documentos tradicionais são reduzidos aos aspectos mais relevantes, visando obter no final do processo, apenas artefatos de grande importância para o projeto.
XP é o que usa programação a 2, plano de testes antes do codigo. é indicado sim incluir comentarios no codigo para facilitar o andamento do processo