-
Pressman 6ª Ed. página 69
Princípios do Scrum
- Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação e minimizar a supervisão
- O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios
- O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos
- O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento ou em pacotes.
- Teste e documentação contantes
- Fornece a habilidade de declarar o produto pronto sempre que necessário
-
Manisfeto Ágil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
1.Indivíduos e interação entre eles mais que processos e ferramentas
2.Software em funcionamento mais que documentação abrangente
3.Colaboração com o cliente mais que negociação de contratos
4.Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Amigos, nas medologias ágeis, o mais importante não é o software rodando do que a documentação? Existe documentação, claro, mas muito pouca como em comparação ao RUP por exemplo. Por que o item I fala em documentação constante?
-
André,
.Sim, o mais importante é o software rodando do que a documentação, entretanto a documentação não é negligenciada. É um contraponto aos modelos mais tradicionais que se preocupam demais em manter a documentação o mais completa possível ao invés de se preocupar com o que realmente tem de ser preocupado, que é o sistema rodando.
. A documentação é constante, pois você não espera o sistema ficar pronto para documentá-lo, mas vai documentando no decorrer da construção e faz a entrega dessa documentação junto a entrega do software rodando, ou seja, você entrega a documentação completa daquela parte e para você entregar a documentação completa da parte que acabou de codificar a documentação foi elaborada de forma constante em conjunto com a documentação e até mesmos as demais etapas como arquitetura, testes, etc.. você sempre documenta, faz isso de forma constante.
Entendeu ? qualquer dúvida diz ai.
Abs.
-
Errei devi ao item 3 porem o vinicius sanou a duvida citando o Pressman. (melhor errar aqui que na prova) valeu
-
A questão deveria ser iniciada assim "De acordo com Pressman".
Times de Desenvolvimento por Pressman
"O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes. "
De acordo com o Scrum Guide
"Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios."
-
também errei pela questão 3 o vinicius sanou a duvida... vlw
-
André Veras ,
Ter uma documentação constante não quer dizer que isso seja mais importante do que o software em funcionamento. A equipe pode ir fazendo, também, a documentação, entretanto, isso não é a principal atividade.
-
Alguém poderia me esclarecer melhor o item III? O que quer dizer pessoal de baixo acoplamento?
-
"Em pacotes" que deixou a questão III bem duvidosa. O SCRUM trabalha com Sprints
-
I - Testes e documentação constantes são realizados à medida que o produto é construído.
Para o Scrum, o próprio código é a documentação, por isso que ela é constante e realizados à medida que o produto é construído. Testes são importantes para verificar se as funcionalidades implantadas estão corretas e atingem os objetivos pretendidos.
II - O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos.
III - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes.
Quando diz que o trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, quer dizer que o trabalho de desenvolvimento (sprints), depois que se inicia, não pode ser alterado, ou seja, seu escopo é claro (sprint backlog). Baixo acoplamento quer dizer que o pessoal não possui papéis definidos e eles são auto-organizáveis, ou seja, não há acoplamento, dependência nem com a sprint nem com o team scrum. Pacotes podem ser traduzidos em Sprints.
-
Não gostei do item III. O pessoal que realiza o desenvolvimento é dividido em partições claras??????
Pior é, em uma divergência, a banca desconsiderar o Scrum Guide
-
✅ Gabarito - D de Deus
Item III - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes.
Pensei assim: "O trabalho de criar software e o pessoal (devs) que o realiza (realiza o quê? criar software) é dividido em partições claras (é divido em partes, que vem do Scrum, as Sprints > iteração > incremento). A gente pode pensar dessa forma, se vou gera incrementos, é interessante ter baixo acoplamento ou no mínimo estar em um modelo de pacotes.