Questões de Processos de Software - Desenvolvimento Ágil

Questão 5239

• Banca: CESGRANRIO
• Órgão: REFAP SA
• Ano: 2007
• Provas: CESGRANRIO - 2007 - REFAP SA - Analista de Sistemas Júnior
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

NÃO é uma característica da Extreme Programming (XP):

• A. simplicidade.
• B. agilidade.
• C. desenvolvimento orientado a testes.
• D. programação em par.
• E. documentação extensa e abundante em artefatos.

Gabarito: E

Comentários

• Milho R$ 16,00 Trigo R$ 25,00??? hehehe
• De onde surgiu esse Milho e Trigo? :D
• a) Correto! Fazer apenas aquilo que o cliente pediu!
  b) Correto! Por isso reduz várias etapas como a análise e desenho, por exemplo.
  c) Correto! Os testes são feitos antes mesmo da codificação
  d) Correto! Um programa e o outro avalia, sendo que eles revezam.
  e) Utiliza da Engenharia Reversa, pois não se interessam em focar-se na Análise e Desenho.

• e)documentação extensa e abundante em artefatos.

  Vai contra o principio da simplicidade, o que é necessari considerando que agile prevê que alterações de requisitos sempre vao aparecer

Questão 5422

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2006
• Provas: CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno - Engenharia de Software; CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno - Processos
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Há um considerável debate sobre os benefícios e a aplicabilidade do desenvolvimento ágil de software em contraposição aos processos mais convencionais de engenharia de software. Relacione o modelo ágil de software com a sua respectiva característica.

Modelo
I - DAS II - DSDM III - FDD IV - XP

Característica

(P)
Define um ciclo de vida que incorpora três fases: especulação, colaboração e aprendizado. Durante a fase de aprendizado, à medida que os membros de uma equipe começam a desenvolver os componentes que fazem parte de um ciclo adaptativo, a ênfase está tanto no aprendizado quanto no progresso em direção a um ciclo completo.

(Q)
O conceito característica é uma função valorizada pelo cliente, que pode ser implementada em duas semanas ou menos. Este modelo define seis marcos de referência durante o projeto e implementação de uma característica: travessia do projeto, projeto, inspeção de projeto, código, inspeção de código, promoção para construção.

(R)
Fornece um arcabouço para construir e manter sistemas que satisfazem às restrições de prazo apertadas por meio do uso de prototipagem incremental em ambiente controlado de projeto. Essa abordagem sugere uma filosofia que é emprestada de uma versão modificada do princípio de Pareto.

A relação correta é:

• A. I - P, II - Q, III - R.
• B. I - P, II - R, III - Q.
• C. I - Q, III - R, IV - P.
• D. II - P, III - R, IV - Q.
• E. II - Q, III - P, IV - R.

Gabarito: B

Comentários

• Só uma dica: esta questão é fácil para quem sabe o signigicado da sigla do modelo FDD (Feature Driven Development) ou Desenvolvimento Baseado em Característica. O único item que fala de característica é o item III, e só existe uma opção com III - Q.
• O Pressman é uma otima referencia de agile.....pracaba mesmo

• FDD ( Feature Driven Development )

  • Foco em desenho e construção
  • Iterativo
  • Não existe nenhum processo específico de modelagem.
  • Resposta rápida para mudanças de requisito e de mercado
  • Preocupação com a qualidade, entregas frequentes e tangíveis

  Processos

  1. Desenvolver um modelo compreensível
  2. Construir uma lista de funcionalidades
  3. Planejar por funcionalidade
  4. Projetar por funcionalidade
  5. Construir por funcionalidade
• DAS - P - Ele define um "ciclo de vida" DAS que incorpora três fases: especulação, colaboração e aprendizagem.
  DSDM - R - Oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado, através do uso da prototipagem incremental em um ambiente de projeto controlado.
  FDD - Q - funcionalidade é uma função valorizada pelo cliente passível de ser implementada em duas semanas ou menos
  
  Pressman, 7ed, 2011
• Usei a linha de raciocínio que Gabriel usou, pois não conhecia as metodologias DAS e DSDM

•  b)I - P, II - R, III - Q.

  é só lembrar que em agile é DSDM que trabalha com prototipos. Outro conceito-chave do DSDM são os prazos apertados, além do destaque à participação do usuario. FDD 9feature-driven development) é o que estabelece entrega em no max 2 semanas

Questão 17752

• Banca: CESGRANRIO
• Órgão: BNDES
• Ano: 2008
• Provas: CESGRANRIO - 2008 - BNDES - Profissional Básico - Análise de Sistemas - Desenvolvimento
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software; Processos de Software - Desenvolvimento Ágil; RUP (Rational Unified Process) - Processo Unificado Rational; XP (eXtreme Programming)

Que situação favorece a escolha do uso de XP para um projeto de desenvolvimento de software, em oposição à escolha do RUP ou do modelo Cascata?

• A. Equipe do projeto localizada em diferentes cidades e com poucos recursos de colaboração.
• B. Equipe do projeto formada por pessoas com alto grau de competitividade.
• C. Cliente do projeto trabalhando em parceria com a equipe do projeto e sempre disponível para retirar dúvidas.
• D. Requisitos do software com pequena probabilidade de mudanças.
• E. Presença de um processo organizacional que exige a elaboração de vários documentos específicos para cada projeto.

Gabarito: C

Comentários

• O cliente sempre presente é uma das práticas do XP, como pode ser observado em:

  Cliente Sempre Presente - o cliente não é alguém de fora, mas sim um membro da equipe. Ele deve estar sempre disponível e pronto para atender às dúvidas dos desenvolvedores.

  http://agilblog.locaweb.com.br/tag/xp/

•  a)Equipe do projeto localizada em diferentes cidades e com poucos recursos de colaboração.errado - XP favorece pair programming e trabalho em proximidade com os stakeholders. 

   b)Equipe do projeto formada por pessoas com alto grau de competitividade. - XP encoraja compartilhamento do codigo e trabalho junto; o oposto de competeição

   c)Cliente do projeto trabalhando em parceria com a equipe do projeto e sempre disponível para retirar dúvidas.- correto

   d)Requisitos do software com pequena probabilidade de mudanças. - errado- XP prevê que mudanças podem ocorrer a qualquer momento

   e)Presença de um processo organizacional que exige a elaboração de vários documentos específicos para cada projeto.- agile nao gosta de documentação. 

• TCU é sessão extraordinária.

Questão 27286

• Banca: FCC
• Órgão: TRE-SE
• Ano: 2007
• Provas: FCC - 2007 - TRE-SE - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Na XP (eXtreme Programming)

• A. deve-se usar o modelo em cascata para o desenvolvimento do software.
• B. os programadores desenvolvem o software criando primeiramente os testes.
• C. deve ser evitada a comunicação pessoal entre clientes e desenvolvedores, sempre dando preferência a outros meios de comunicação mais formais.
• D. os programadores desenvolvem o software fazendo todos os testes possíveis no término do desenvolvimento.
• E. deve-se projetar todas as funções possíveis com a máxima previsão do que ocorrerá no futuro, antes do desenvolvimento do software, a fim de evitar alterações desnecessárias.

Gabarito: B

Comentários

• "O XP recomenda que depois que as histórias forem desenvolvidas e o trbaalho preliminar de projeto for feito, a equipe não avance para o código mas, em vez disso, desenvolva uma série de testes unitários." (Eng. Software - Pressman)
• A opção correta é a letra B, "os programadores desenvolvem o software criando primeiramente os testes."É o que chamamos de Test First Design - Primeiro são escritos os testes, depois é feita a implementação e por último trabalha-se o design.
• a) Uma das características do XP é a refatoração, contrário ao modelo de ciclo de vida em cascata tradicional.
  b) correto!
  c) Comunicação com os clientes é uma das características principais do XP.
  d) Não existe nenhum modelo que faça todos os testes possíveis. ISSO É IMPOSSÌVEL! Princípios básicos da Engenharia de Software.
  e) Não é necessário no XP, visto que ele prega a refatoração.
• De acordo com [1], são práticas do XP:
  1. Planejamento incremental;
  2. Pequenos releases;
  3. Projetos Simples;
  4. Desenvolvimento test-first;
  5. Refactoring;
  6. Programação em pares;
  7. Propriedade coletiva;
  8. Integração contínua;
  9. Ritmo sustentável;
  10. Cliente on-site;
  [1]: Sommerville, ENg. de Software, 8 ª edição, página 264

• Isso é uma obrigação? Escrever testes primeiro é uma prática, que você pode ou não executar.

•  b)os programadores desenvolvem o software criando primeiramente os testes.

  EM XP, os desenvolvedores agem em pares planejam testes antes do codigo. 

Questão 28570

• Banca: CESGRANRIO
• Órgão: DECEA
• Ano: 2006
• Provas: CESGRANRIO - 2006 - DECEA - Técnico de Defesa Aérea e Controle de Tráfego Aéreo - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Assinale a metodologia de desenvolvimento de software que tem como prática a programação em pares.

• A. MSF
• B. XP
• C. RUP
• D. PMBOK
• E. CMMI

Gabarito: B

Comentários

• Programação Extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.
  
  Para aplicar os valores e princípios durante o desenvolvimento de software, 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. Uma destas práticas é a "Programação em Pares".
  
  Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na liguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
  
• Programação Extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. [http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_Extrema]
  
  O MSF para Desenvolvimento Ágil de Software é um guia de procedimentos, uma coleção de boas práticas para projetos de desenvolvimento de softwares. [http://pt.wikipedia.org/wiki/Microsoft_Solution_Framework]
  
  O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation. [http://pt.wikipedia.org/wiki/Rup]
  
  O Project Management Body of Knowledge, também conhecido como PMBOK®[1] é um conjunto de práticas em gerência de projetos. [http://pt.wikipedia.org/wiki/Pmbok]
  
  O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)) [http://pt.wikipedia.org/wiki/Cmmi]
  
  portanto, XP é a única metodologia de desenvolvimento de software dentre as listadas.
• Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.Ou seja a resposta correta é a letra B
• pessoalzinho do CTRL+C CTRL+V, ao menos divulguem a fonte.

• Sem mistérios! Falou em programação em PARES falou em Extreme Programming - XP -  que é uma metologia de desenvolmento ágil.

• XP

  caracteristicas de cp (extreme programming) stand-up meetings, pair programming, escrita de testes antes do codigo, 5 valores (comunicação, simplicidade, feedback, coragem, respeito).

Questão 56722

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Analista Administrativo - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Segundo Ian Sommerville, (Engenharia de software, 2007, p.
5), a engenharia de software é uma disciplina de engenharia
relacionada a todos os aspectos da produção de software, desde
os estágios iniciais de especificação do sistema até sua
manutenção. Acerca da engenharia de software, julgue os itens a
seguir.

Extreme Programming é um modelo de processo de desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem software com base em requisitos vagos e que são modificados rapidamente.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• a questão ficou errada apenas por colocar que é para equipes grandes... As equipes devem ter no máximo 10 desenvolvedores.
• ERRADO.
  Extreme Programming é um modelo de processo de desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem software com base em requisitos vagos e que são modificados rapidamente.
  As equipes no XP devem ter tamanho pequeno ou médio, agora grande número de pessoas não e é aí que está o erro da questão. O Software tem requisitos vagos e sofre constante mudanças.
  
  []s
  Bons estudos
  Marcelo

• queria que na minha prova do TRE fosse assim!

Questão 72097

• Banca: CESGRANRIO
• Órgão: IBGE
• Ano: 2010
• Provas: CESGRANRIO - 2010 - IBGE - Analista de Sistemas - Desenvolvimento de Aplicações
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

O XP (Extreme Programming) usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento predileto. Nessa perspectiva, analise as afirmativas abaixo.
I - A atividade de Codificação começa com a criação de um conjunto de histórias que descreve as características e as funcionalidades requeridas para o software a ser construído.

II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.

III - O XP emprega a técnica de refectoring na codificação, mas desaconselha a utilização da programação por pares.

IV - A criação de testes unitários antes da codificação começar é uma prática do XP.

V - Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto.

Estão corretas APENAS as afirmativas

• A. I, II e IV.
• B. I, III e IV.
• C. I, IV e V.
• D. II, III e V.
• E. II, IV e V.

Gabarito: E

Comentários

• A maior duvida deve ficar entre a alterntiva "C" e "E". Existe uma pequena nuance no item I. que diz "A atividade de Codificação começa com a criação de um conjunto de histórias" Atividade de codificação começa com a escrita de testes. Já o item III pode ser desconsidera, pois o XP encoraja a programação em pares.
• Eu entendo que a opção I está incorreta porque a criação das estórias é feita anteriormente à codificação, e não como inicio da mesma. Se observar bem, I e IV são conflitantes pois, se você começa a testar antes de codificar (e isso está correto), não é possível escrever os testes se primeiro definir a estória.Assim, I não é uma afirmação verdadeira.
• I. O conjunto de histórias se desenrola nas atividades de planejamento e projeto, na codificação já deverão estar prontas.
  
  III. A codificação no XP é feita através da programação em pares.
  
  Demais questões corretas.
• I - A atividade de (Codificação) Planejamento começa com a criação de um conjunto de histórias que descreve as características e as funcionalidades requeridas para o software a ser construído. 
  Errado. O XP envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: Planejamento, Projeto, Codificação e Testes. Na atividade de Planejamento (também denominada o jogo do planejamento) é que são criadas as histórias de usuários. Essas histórias descrevem o resultado, as características e a funcionalidade para o software a ser construído. (pag 88)
  
  II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos.
  Certo. A XP encoraja o uso de cartões CRC como um mecanismo eficaz para pensar sobre o software em um contexto orientado a objetos. Os cartões CRC identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto produzidos como parte do processo XP. (pag 89)
  
  III - O XP emprega a técnica de refectoring na codificação, (mas desaconselha) como também a utilização da programação por pares. 
  Errado. Um conceito-chave na atividade de codificação (e um dos mais discutidos aspectos da XP) é a programação em dupla. A XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho para criar código para uma história. (pag 90)
  
  IV - A criação de testes unitários antes da codificação começar é uma prática do XP.
  Certo. A criação de testes de unidade, antes de começar a codificação, é um elemento-chave da abordagem XP. (pag 90)
  
  V - Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto.
  Certo. Se um difícil problema de projeto é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto. Denominada solução pontual, o protótipo é implementado e avaliado. O objetivo é reduzir o risco para quando a verdadeira implementação iniciar e validar as estimativas originais para a história contendo o problema de projeto. (pag89)
  
  (Fonte: Livro Engenharia de Software 7ed, Pressman)
  
  Logo, gabarito "E"

Questão 104959

• Banca: FCC
• Órgão: TRE-AM
• Ano: 2010
• Provas: FCC - 2010 - TRE-AM - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

São algumas das metodologias de desenvolvimento de software consideradas ágeis (Agile Software Process Models):

• A. RUP, XP e DSDM.
• B. Waterfall, RUP e FDD.
• C. XP, FDD e RUP.
• D. Scrum, XP e FDD.
• E. Scrum, Waterfall e DSDM.

Gabarito: D

Comentários

• d) Scrum, XP e FDD. Some of the well-known agile software development methods: * Agile Modeling * Agile Unified Process (AUP) * Dynamic Systems Development Method (DSDM) * Essential Unified Process (EssUP) * Extreme Programming (XP) * Feature Driven Development (FDD) * Open Unified Process (OpenUP) * Scrum

•  Cabe recurso. Alguns autores consideram RUP uma metodologia ágil.

• RUP não é metodologia é uma framework
  http://www-01.ibm.com/software/awdtools/rup/
• O SCRUM também não é uma metologia e sim um framework de processos, assim como o RUP, mas em todas as provas o SCRUM é considerado uma metodologia.

• "Scrum é uma metodologia ágil para gestão e planejamento de projetos de software."

  http://www.desenvolvimentoagil.com.br/scrum/

•  d)Scrum, XP e FDD.

  modelos agile:

  XP (extreme programming)

  scrum

  DSDM (dynamic system development method)

  crystal

  FDD - funcionality driven development

• Há também AUP - agile unified process, o qual é uma versão simplificada do RUP, que aplica tecnicas de desenvolvimentop por testes (test-driven development), modelagem agile & fatoração. Os principios do AUP: 

  a- simplicidade

  b- flexivel a mudancas

  c- 1° obj.: sofwtare

  d- viablizar esforcos futuros

  e- alteracoes incrementais

  f- maximizar investimento de stakeholders

  g- modelar com prototipo

  h- multiplos mdoelos

  i- qualidade

• RUP não é metodologia é um framework.

  Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

  DSDM é um dos modelos de Metodologia Ágil de desenvolvimento de software.

  XP é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software

  FDD é uma das seis metodologias ágeis originais do desenvolvimento de software.

  O Modelo em Cascata (do inglês: Waterfall Model) é um modelo de desenvolvimento de software sequencial

Questão 119284

• Banca: FCC
• Órgão: TRF - 4ª REGIÃO
• Ano: 2010
• Provas: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

A Feature Driven Development (FDD) é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto afirmar:

• A. Não pode ser combinada a outras técnicas para a produção de sistemas.
  
• B. Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e Implementar por Funcionalidade.
  
• C. Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada categoria, os papéis são atribuídos a um único participante que assume a responsabilidade pelo papel.
  
• D. Mantém seu foco apenas na fase de modelagem.
  
• E. Mantém seu foco apenas na fase de implementação.

Gabarito: B

Comentários

• A FDD é, classicamente, descrita por cinco processos: * Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção. * Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto). * Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção. * Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos. * Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.
• A) ERRADA - Ela interage com outras metodologias.
  
  B) CORRETA - O processo Implementar por Funcionalidade é mais conhecido como Construir por Funcionalidade (Build by Feature).
  
  C) ERRADA - FDD implementa em torno de 15 cargos e responsabilidades entre as categorias principais, de apoio e adicionais.
  
  D) ERRADA - O foco do FDD é tanto para o desenho como para construção do sistema.
  
  E) ERRADA - O foco do FDD é tanto para o desenho como para construção do sistema.
• Uma equipe de FDD pode ter até 250 pessoas, seria mais ou menos assim em ordem crescente de detalhamento:  XP < FDD < RUP
  
  Sobre os papéis:
  
  Temos:
  • Project Manager - Administração
  • Chief Architect - Interno ao projeto
  • Development Manager
  • Chief Programmers
  • Class Owners (Desenvolvedores Individuais)
  • Domain Experts ("Stake Holders" - servem pra tirar duvidas sobre os requisitos de domínio da aplicação)

• 
  

  OS CINCO PROCESSOS SÃO BEM DEFINIDOS E INTEGRADOS DO FDD:
  1.   DMA (Desenvolver a lista de funcionalidades): Decomposição Funcional
  2.   CLF  (Construir a Lista de Funcionalidades): Decomposição Funcional
  3.   PPF  (Planejar por Funcionalidade): Planejamento Incremental
  4.   DPF  (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  5.   CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos
  

•  b)Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e Implementar por Funcionalidade.

  é uma metodologia adaptativa que opera em torno de features, cujos processos sao, consoante questao: Desenvolver um Modelo Abrangente, Construir ,Planejar, Detalhar e  Implementar features.

Questão 119287

• Banca: FCC
• Órgão: TRF - 4ª REGIÃO
• Ano: 2010
• Provas: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos cartões que são conhecidos como

• A. cartões de requisitos.
  
• B. cartões de planejamento.
  
• C. cartões chave.
  
• D. cartões inteligentes.
  
• E. histórias de usuário.

Gabarito: E

Comentários

• Alguma práticas de XP para vocês decorarem :))* Metáforas* Time pequenos e coeso (até 10 membros)* Posse Coletiva do Código* Programação em Par(Pair Programming)* Padrões de Codificação* Clientes Presentes* Jogo de Planejamento: escolhem o que fazer na semana (o mais importante)* Releases Curtos (Small Releases)* Desenvolvimento guiado pelos testes(Test Driven Development) - Automatizados (ex.: JUnit)* Integração Continua(Continuous Integration)* Refatoração(Refactoring ou refabricação: todos são obrigados a melhorar o código)* Reuniões de Pé(Stand-up Meeting)* Ritmo Sustentável(Sustainable Pace)* Duração máxima de 36 meses com semana de 40 horas* Design simples do sistema***** CRC: modelagem de classes usando story cards (usuários descrevem funcionalidade do sistema)
• Leoh,originalmente, ou seja, aquilo que está nos literatura científica é o que realmente podem ser utilizados para resolver problemas em concurso. Apesar de serem práticas adotadas por alguns, não é parte do XP definir desta maneira as coisas, logo, segundo Kent Beck e Vinicius Teles, algumas das práticas que você colocou estão incorretas. Tais são:-Duração máxima de 36 meses com semana de 40 horas-Times Pequenos.Ainda há autores que consideram que a Design Simples não é uma prática e sim um valor.Em regra geral, não é o que falam por ai que vale para concurso, precisa-se ter embasamento literário aceito no mundo acadêmico. Logo: -Duração máxima de 36 meses com semana de 40 horas, não é uma prática do XP. Qualquer pessoa que adotá-lo pode mudar estes valores, logo não é aceito como uma prática do XP e -Times Pequenos, não é uma prática e sim uma recomendação (apesar de ser praticada).Sobre a questão:a) Cartão de Requisito ainda não foi criado na literatura nacional, pelo menos que eu conheça. Logo ERRADA.b) Cartão de Planejamento: apesar do XP se utilizar de cartões para planejar (estimar) isto não o classifica como cartão de planejamento. Logo ERRADA.c) Cartão chave que eu conheço é aquele que dá acesso a entrada em um quarto no Hotel 5 estrelas aqui da cidade. ERRADAd) Cartões inteligentes são, atualmente, considerados aqueles que possuem um chip e capazes de armazenas informações, inclusive certificados digitais, como é o caso do e-CPF. Logo ERRADA.e) As Historias do Usuário, também conhecido como Store Card (Cartão de História) e a alternativa CORRETA.
• Citando: Pressman, Engenharia de Software, 6ª edição, p. 63
  "Planejamento. A atividade de planejamento começa com a criação de um conjunto de histórias (também chamado de histórias de usuário) que descrevem as características e funcionalidades requeridas para o software a ser construído. Cada história (semelhantes aos casos de uso descritos nos Capítulos 7 e 8) é escrita pelo cliente e é colocada em um cartão de indexação."

• Segundo SOMMERVILLE,
  Os cartões de estória são as principais entradas para o processo de planejamento em XP ou "jogo de planejamento". 

Questão 119290

• Banca: FCC
• Órgão: TRF - 4ª REGIÃO
• Ano: 2010
• Provas: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Na fase de desenvolvimento do Scrum, o software é desenvolvido em processos iterativos denominados

• A. Building Products.
  
• B. Product Backlog.
  
• C. Sprint.
  
• D. Product Owner.
  
• E. Product Backlog Cycle.

Gabarito: C

Comentários

• As perguntas sobre SCRUM quase sempre enfatizam alguma terminologia. Vejam a figura abaixo onde estão as principais terminologias adotadas no SCRUM:http://screencast.com/t/ODI0NGIzAlem destas, é importante saber dos dois principais papeis que aparecem no SCRUM: Product Owner e o SCRUM Master.
• a) Building Products.  - É o resultado de uma Sprint. Deve ser uma parte totalmente funcional do produto final.
  b) Product Backlog. - São os requisitos do produto todo. - cada sprint tem seu backlog que contém o escopo daquela sprint.
  c) Sprint. - É uma iteração do desenvolvimento do produto, dura entre 2 e 4 semanas. Ao final gera-se um incremento do produto final.
  d) Product Owner - É o "cliente" ele que define os aspectos mais importantes que devem ser entregues nas primeiras sprints.
  e) Product Backlog Cycle - Este termo não existe o correto é Sprint.

• c-

  Sprint é a iteração do scrum, sendo que, por ser um processo ciclico, deve ocorrer para todas fases do projeto

Questão 121153

• Banca: FCC
• Órgão: AL-SP
• Ano: 2010
• Provas: FCC - 2010 - AL-SP - Agente Técnico Legislativo Especializado - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

São consideradas metodologias ágeis de desenvolvimento de software:

• A. XP e UP.
• B. SCRUM de DSDM.
• C. SCRUM e RUP.
• D. DSDM e Cascata.
• E. Cascata e PRINCE2.

Gabarito: B

Comentários

• Dynamic Systems Development Method, ou Metodologia de Desenvolvimento de Sistemas Dinâmicos (em português), é uma metodologia de Desenvolvimento de Software originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD).

• Resposta por exclusão. Uma delas seria SCRUM, naturalmente. A segunda, vai do candidato já ter ouvido falar em DSDM.
• Para os que nunca ouviram falar sobre DSDM, o Pressman comenta-o em seu capítulo sobre metodologias ágeis.

• "Metodologia de Desenvolvimento de Sistemas Dinâmicos (do inglês Dynamic Systems Development Method - DSDM) é uma metodologia de desenvolvimento de software originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD). DSDM é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário.

  Seu objetivo é entregar softwares no tempo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos modelos de Metodologia Ágil de desenvolvimento de software, e seu formato é propriedade da Agile Alliance."
  
  Fonte - http://pt.wikipedia.org/wiki/Dynamic_Systems_Development_Method

• b) SCRUM de DSDM.
• Primeiro o pessoal da FCC precisa aprender a escrever, daí poderão almejar coisas mais ambiciosas como aprender a formular questões.

• LETRA B O Dynamic System Development Method (Método de Desenvolvimento de Sistemas Dinâmicos) ou DSDM é mais uma abordagem de desenvolvimento de software ágil que oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado através do uso da prototipagem incremental.
  
  Leia mais em: Modelos de Processos Ágeis: conceitos e princípios http://www.devmedia.com.br/modelos-de-processos-ageis-conceitos-e-principios/30059#ixzz3bSHHM9oC
  
  Scrum é um método de desenvolvimento ágil de software criado por Jeff Sutherland e a sua equipe de desenvolvimento de software.
  
  Leia mais em: Modelos de Processos Ágeis: conceitos e princípios http://www.devmedia.com.br/modelos-de-processos-ageis-conceitos-e-principios/30059#ixzz3bSHONHpn
  
• Questão deveria ser CANCELADA. Pois, SCRUM não é uma metodologia. SCRUM é um Framework.
  Fonte retirada do Guia Scrum.
  http://www.fabiocruz.com.br/wp-content/uploads/2013/09/Scrum-Guide-Portuguese-BR2013.pdf
  
• Scrum pode ser considerado (a) um processo de gerenciamento e controle ou (b) um framework. Não é uma metodologia.
  Fonte: https://www.scrum.org/resources/what-is-scrum
  
  DSDM é considerado um framework. Embora o M da sigla seja método (não metodologia, como dito), DSDM é um framework.
  Fonte: http://www.dsdm.org/content/what-dsdm 
  Dica: Algumas bancas ou algumas questões se prendem a semântica, outras não. Marquem sempre a alternativa que considerarem menos errada.

• b)SCRUM de DSDM.

  metodologias agile têm como principio o modelo iterativo & desenvolvimento espiral, o qual visa produzir no final de cada ciclo uma versao funcional do software. As metodologias agile masi conhecidas: xp (programação em pares, plano de testes antes do codigo,abordagem orientada a objetos) scrum (sprints, empirismo, controle de processo, abordagem ioncremental & iterativa), DSDM (envolvimento do usuario, base no RAD, para projetos com cronogramas apertados), crystal (para diversos projetos, codigo de complexidade por cores, desenvolvimento incremental a cada 4 meses no max), FDD (trabalha com features que sao implementadas a cada 2 semanas)

Questão 126226

• Banca: FCC
• Órgão: DPE-SP
• Ano: 2010
• Provas: FCC - 2010 - DPE-SP - Agente de Defensoria - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Na engenharia de software, um processo iterativo denominado sprint, que segue o ciclo PDCA para entregar, num período de 30 dias aproximadamente, um incremento do software pronto, caracteriza a metodologia ágil

• A. SCRUM.
• B. DSDM.
• C. Crystal.
• D. FDD.
• E. XP.

Gabarito: A

Comentários

• O Scrum é uma metodologia ágil para Gerenciamento de Projetos.O Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka. Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming (XP) e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.Características de Scrum:1. Cada sprint é uma iteração que segue um ciclo (PDCA)(Plan, Do, Check, Action) e entrega incremento de software pronto;2. Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI e por conhecer as necessidades do cliente); 3. Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints; 4. Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião). 5. Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos; 6. Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada. O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint.

• Projetos dos Modelos agile usam modelos iterativos & desenvolvimebnto em espiral. Eles passam por todos os estagios do modelo waterfall, mas em ciclos menores que no final produzem um incremento, o que é uma versao funcional do software. cada incremento tem mais features com cada ietração.

   a)SCRUM. - correto - ciclos sao SPRINTS. equipes em scrum sao auto-organizadas sem influencia externa e têm 3 partes: product owner, development team & scrum master. 

   b)DSDM. (dynamic system development method) - ênfase- envolvimento do usuario. baseado no RAD (rapid application development development). Indicado para prazos apertados.

   c)Crystal. - a familia crystal determina a compelxidade do projeto por cores. + escura, + complexo. ideal para projetos diversos com desenvolvimento incremental em no maximo 4 meses.

   d)FDD. ((functionality driven approach). trabalha com features que sao implementadas a cada 2 semanas. 

   e)XP. (extreme programming) - + usado. promove programação em pares, reunioes em pé e plano de testes antes do codigo. ideal para pequenas equipes em pequenas & medias empresas. XP conta com 5 valores: comunicação, simplicidade, feedback, coragem, respeito.

• O Scrum defende que um projeto seja executado em pequenas etapas, com no máximo 30 dias, chamadas de sprint, e que ao término de cada etapa, o produto desenvolvido possa ser entregue para avaliação do cliente.

Questão 128473

• Banca: FCC
• Órgão: TRT - 15ª Região (SP)
• Ano: 2009
• Provas: FCC - 2009 - TRT - 15ª Região - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Histórias de usuários na atividade de planejamento, encorajamento de uso de cartões CRC e de refabricação, reuniões em pé e programação em pares são características típicas do modelo de processo de software

• A. XP.
• B. SCRUM.
• C. DSDM.
• D. DAS.
• E. MVC.

Gabarito: A

Comentários

• Características da XP.
  
  Acrescento outras [1] Planejamento Incremental; Pequenos releases; Projeto Simples; Desenvolvimento test-first; Propriedade coletiva; Integração contínua; Ritmo sustentável; Cliente on-site.
  [1] SOmmerville, Engenharia de Software, 8ª Edição, página 264

• MVC (Padrão de arquitetura de software - Model, View, Controller)
  

•  a)XP.

  XP prioriza simplicidade, comunicação, feedback, coragem & respeito, além de programação a 2 e planejamento de testes antes do codigo

• A questão tem uma parte errada: "encorajamento de uso de cartões CRC". Os cartões CRC são usados na fase de "Projeto", dentro do ciclo do XP.

   

  Planejamento > Projeto > Codificação > Teste = Entrega de release

Questão 136249

• Banca: ESAF
• Órgão: MPOG
• Ano: 2010
• Provas: ESAF - 2010 - MPOG - Analista de Planejamento e Orçamento - Tecnologia da Informação - Prova 2
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Outros modelos de Processo de Software; Processos de Software; Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

As atividades do modelo espiral de Engenharia de Software são:

• A. Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação feita pelo cliente.
• B. Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.
• C. Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.
• D. Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação feita pelo cliente.
• E. Planejamento, Projeto, Análise dos Riscos e Engenharia.

Gabarito: B

Comentários

• =>As atividades do modelo espiral de Engenharia de Software são:
  
  Apesar de que está faltando Construção e Comunicação com Cliente, o item mais coreto é:
  b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente
  
• Modelo Espiral de Boehm: Planejamento, Análise de riscos, Engenharia e Avaliação do cliente
  Modelo Espiral de Pressman: Comunicação, Planejamento, Análise de riscos, Engenharia, Construção e release e Avaliação do cliente

• Complementando a resposta, muito boa do colega Leonardo:

  Modelo Espiral de Boehm: Planejamento, Análise de riscos, Engenharia e Avaliação do cliente
  Modelo Espiral de Pressman: Comunicação, Planejamento, Análise de riscos, Engenharia, Construção e release e Avaliação do cliente 

  Modelo Espiral do Sommerville: 

  1) Determinação de objetivos, alternativas e restrições;

  2) Avaliação de alternativas, identificação e solução de riscos;

  3) Desenvolvimento, verificação e produto no próximo nível;

  4) Planejamento da próxima fase;
  

Questão 140890

• Banca: CESPE / CEBRASPE
• Órgão: ANTAQ
• Ano: 2009
• Provas: CESPE - 2009 - ANTAQ - Analista Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito da engenharia de software, julgue os itens de 101 a 109.

O extreme programming (XP) constitui método ágil de desenvolvimento de software. Uma das práticas que se enquadram nos princípios dos métodos ágeis é a programação em pares, que promove o compartilhamento da autoria do código do sistema. Além dessa vantagem, a programação em pares atua como processo informal de revisão porque cada linha de código é vista por pelo menos duas pessoas.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Nao concordo com o gabarito. Programação em pares é príncipio do XP, não de metodologias ágeis. Alguém pode justificar o gabarito?
  
  

  Os princípios do desenvolvimento ágil valorizam:

  • Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
  • Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
  • Softwares funcionais são a principal medida de progresso do projecto;
  • Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
  • Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
  • Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
  • Design do software deve prezar pela excelência técnica;
  • Simplicidade;
  • Rápida adaptação às mudanças;
  • Indivíduos e interações mais do que processos e ferramentas;
  • Software funcional mais do que documentação extensa;
  • Colaboração com clientes mais do que negociação de contratos;
  • Responder a mudanças mais do que seguir um plano.

• Tem vários princípios Ágeis espalhados por aí hehehe Os mais cobrados são os 12 princípios da Agile Alliance (que consta no livro do Pressman), os 5 da Wikipédia e os 5 Princípios do Sommerville.

  Os 12 princípios da Agile Alliance estão aqui -> http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

  Os 5 princípios da Wikipédia são: Feedback rápido, Presumir simplicidade, Mudanças incrementais, Abraçar mudanças e Trabalho de alta qualidade.

  Os 5 princípios do Sommerville são:  Envolvimento do Cliente, Entrega Incremental, "Pessoas, não processo", Aceite as mudanças e Mantenha a Simplicidade.

  A maioria desses princípios é autoexplicativa, com exceção de um:

  Pessoas, não processo: As habilidades da equipe devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos.

  Sommerville afirma ainda que a Extreme programming envolve um número de práticas que refletem cada um desses princípios dos métodos ágeis:

  1. Desenvolvimento Incremental é apoiado por pequenos e frequentes releases do sistema e por uma abordagem de descrição de requisitos baseadas nas histórias ou cenários do cliente e podem ser a vase para o planejamento do processo.

  2. O Envolvimento do cliente é apoiado pelo engajamento em tempo integral deste na equipe de desenvolvimento. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

  3. As pessoas, não o processo, são apoiadas ao dividirem a programação com seus pares, partilhando a propriedade do código do sistema e um processo sustentável que não envolva excessivas horas de trabalho.

  4. As mudanças são apoiadas por meio de releases regulares de sistema, desenvolvimento test-first e integração contínua.

  5. A manutenção da simplicidade é apoiada pelo refactoring constante para aprimorar a qualidade do código e o uso de projetos simples que não antecipam mudanças futuras no sistema.

  (Fonte: Livro Engenharia de Software, 8ed, Sommerville, pag 264)

  Logo, não há nada de errado em associar uma prática do XP a um princípio ágil. Questão Correta.

• Errei, pois quem promove o compartilhamento do código é a prática de "Propriedade Coletiva", não a "Programação em Pares". Mas que seja, ainda assim a questão está correta.

• Concordo com o José Roberto. Para mim o gabarito está errado, pois programação em pares é um princípio do XP e não das metodologias ágeis em geral.

Questão 142231

• Banca: CESGRANRIO
• Órgão: BNDES
• Ano: 2009
• Provas: CESGRANRIO - 2009 - BNDES - Profissional Básico - Análise de Sistemas - Desenvolvimento
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Determinado projeto de software utiliza XP (eXtreme Programming) como metodologia de desenvolvimento. A esse respeito, é INCORRETO afirmar que

• A. o cliente participa ativamente e acompanha os passos dos desenvolvedores diariamente.
• B. os integrantes da equipe se reúnem rapidamente no início do dia, de preferência em pé.
• C. a equipe de desenvolvimento concentra esforços naquilo que gera maior valor para o cliente.
• D. a programação em pares dispensa o desenvolvimento orientado a testes no projeto.
• E. as funcionalidades do software são descritas em histórias, da forma mais simples possível.

Gabarito: D

Comentários

• A programação em pares NÃO dispensa o desenvolvimento orientado a testes no projeto

• Continuous Integration - Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

  Sendo assim, a programação em pares não tem porque dispensar o desenvolvimento orientado a testes no projeto, muito pelo contrário a programação em pares ajuda nos testes pois o código a qualquer momento está na forma mais simples para que passe em todos os testes (simple design).

• Achava que "os integrantes da equipe se reúnem rapidamente no início do dia, de preferência em pé." era apenas característica do SCRUM, mas 
  concordo que a letra D tá mt errada. 
• XP, RUP e SCRUM utilizam TDD.
• A prática da programação em par permite que o código seja revisado permanentemente enquanto é construído. A programação em par é um mecanismo de validação do que está sendo construído. Por esse motivo não existe uma fase específica de teste, e acredito que tenha sido esse o foco do avaliador.

Questão 142870

• Banca: FIP
• Órgão: Câmara Municipal de São José dos Campos - SP
• Ano: 2009
• Provas: FIP - 2009 - Câmara Municipal de São José dos Campos - SP - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Assinale a alternativa que não apresenta características dos métodos ágeis de desenvolvimento de software:

• A. entregas parciais do sistema em períodos curtos, que duram de semanas a meses, com preferência para intervalos de tempo menores.
• B. atribuição dos requisitos de maior complexidade funcional e não funcional nas primeiras interações com os clientes, de forma a priorizar os aspectos críticos do sistema.
• C. quantidade de código executável considerada a medida mais importante do progresso do desenvolvimento de um software.
• D. mudanças nos requisitos, mesmo quando ocorrem próximas ao final do desenvolvimento.
• E. processos de desenvolvimento e recursos tecnológicos disponíveis considerados mais importantes do que as interações entre os membros das equipes.

Gabarito: E

Comentários

• Letra E.
  Pode-se verificar o erro da questão através dos cinco valores fundamentais da metodologia XP: comunicação, simplicidade, feedback, coragem e respeito
• Bruno....
  o Spint da Scrum por exemplo duracao aproximadamente de 30 dias....
• Questão com duas alternativas incorretas.
  
  b) atribuição dos requisitos de maior complexidade funcional e não funcional nas primeiras interações com os clientes, de forma a priorizar os aspectos críticos do sistema.
  essa característica é do RUP. métodos ágeis priorizam as funcionalidades mais relevantes para o cliente e para o negócio.
  
  
  e) processos de desenvolvimento e recursos tecnológicos disponíveis considerados mais importantes do que as interações entre os membros das equipes.
  isso fere o primeiro princípio fundamental dos métodos ágeis.
  Indivíduos e interação entre eles mais que processos e ferramentas
• Tudo bem que outras alternativas podem gerar dúvidas (como alguns colegas já citaram), mas ao ler o texto do manifesto ágil, podemos chegar a conclusão de que a letra E realmente "fere" aquilo exposto no manifesto á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:

  Indivíduos e interação entre eles mais que processos e ferramentas (LETRA E mostra o conceito invertido)Software em funcionamento mais que documentação abrangenteColaboração com o cliente mais que negociação de contratosResponder a mudanças mais que seguir um plano

  Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

  Errada é a letra E.Bons estudos.

Questão 144607

• Banca: CESPE / CEBRASPE
• Órgão: SECONT-ES
• Ano: 2009
• Provas: CESPE - 2009 - SECONT-ES - Auditor do Estado – Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

De acordo com os conceitos relacionados a processos de
desenvolvimento de software e medição de software, julgue os
próximos itens.

Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Entre esses métodos está o extreme programming, que envolve um número de práticas, como o planejamento incremental, a definição de um ritmo de trabalho sustentável e a divisão das equipes de trabalho por meio da especialização de seus membros.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Os Métodos Ágeis de desenvolvimento de software têm como objetivo primordial o desenvolvimento de código-fonte de qualidade que atenda às necessidades do cliente. Este objetivo é alcançando através da construção de um ambiente participativo onde a colaboração frequente entre todos os envolvidos é incentivada e praticada diariamente e onde a qualidade do software é buscada diariamente em cada pequena atividade.

•  Métodos ágeis de desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento.
  Correto. O processo de desenvolvimento incremental permite que o projeto se adeque as mudanças nos requisitos.

  Entre esses métodos está o extreme programming, que envolve um número de práticas,
  como o planejamento incremental, OK
  a definição de um ritmo de trabalho sustentável OK
  e a divisão das equipes de trabalho por meio da especialização de seus membros.
  Incorreto: não há menção no XP sobre essa divisão da equipe nem a especialização de membros. O que o XP prega é uma equipe coesa e multidisciplinar.

• Acertei essa questão porque me lembrei que as equipes no XP são pequenas e que por isso não há espaço para especializações.
•  A XP defende a não especialização dos membros do time (todos participam de todas as atividades, em pares e com sistema de rodízio dos pares), o desenvolvimento de infra-estruturas e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.

• equipes multidisciplinares

• O que o XP prega é uma equipe coesa e multidisciplinar, além disso as equipes no XP são pequenas e que portanto não há espaço para especializações.
  

Questão 144823

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2009
• Provas: CESPE - 2009 - INMETRO - Analista Executivo em Metrologia e Qualidade - Desenvolvimento de Sistemas - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

São práticas ou princípios recomendados no modelo de desenvolvimento de software XP (eXtreme Programming) proposto por Kent Beck: programação em pares; semana de trabalho de 40 horas; refatoração sem piedade; desenvolvimento orientado a testes TDD (Test Driven Development); e desenvolvimento de metáforas arquiteturais.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Acho que refatoração sem piedade, quis dizer que deve-se refatorar(otimizar) o máximo que puder, sem alterar as funcionalidades já existentes, e não deixar nada que possa ser refatorado sem rafatorar.
• Isso da semana de 40 horas eu não sabia.
  
  achei no wikipedia falando dos princípios do xp:
  
  Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
  
  interessante...
• O candidato lê essa questão, conhece tudo sobre o assunto, mas vem a banca e põe a expressão sem piedade no meio. Nesse momento a banca ao invés de exigir do candidato o conhecimento da matéria está exigindo que a gente tenha poderes sobrenaturais de ler a mente do avaliador.
  A interpretação da expressão é ambígua. Na hora da prova eu estaria quebrando a cabeça pra decidir se o avaliador quis dizer refatoração constante ou se ele quis inventar uma modalidade fictícia de refatoração para tornar a questão errada.
  Aí é falta de respeito com quem está se ralando nos estudos como a gente. Quer exigir interpretação por parte do candidato, que o faça, mas dentro dos limites de proporcionalidade e da razoabilidade.
• Concordo com o que foi dito e vou além: quem garante que essa questão não foi feita para "alguém" acertar? Diante de tamanho disparate a hipótese torna-se provável.
• Concordo PLENAMENTE com o que foi dito pelo colega Fabiano, até porque, a CESPE é craque em tornar uma questão errada apenas por uma "palavra", tanto que sempre que estou resolvendo uma prova da banca eu leio atentamente a questão, palavra por palavra, porque em muitos casos o examinador apenas "enfia" uma expressão no meio e torna a questão errada. Tive o mesmo sentimento quando cheguei na palavra "sem piedade":
  
  - E aí, marco certo pois a palavra em questão não contraria a definição do quesito mencionado, ou marco errado por achar que a cespe só "copiou" a definição e colocou uma palavra no meio pra tornar a questão errada (como já fez em diversas questões)?
  
  Sinceramente, uma falta de respeito com o concurseiro. Questão muito mal elaborada.
• Pelo que eu vejo, assim como está no livro de Kent Beck o cara tira maior onda. Acho que a CESPE tentou passar esse espírito para a questão, por isso não vejo problema nenhum nesta questão. CORRETÍSSIMA!!!

• 40 horas semanais é novo para mim
  

• No pain no gain kkkk (sem piedade?)

• Ao meu ber, esse sem piedade é ainda mais crível que as metáforas arquieturais. Quando ele diz: "e desenvolvimento de metáforas arquiteturais." ele restringe o conceito. O "sem piedade" pelo menos não restringe.

• Alguém explica ou cita a fonte que fala de "Metáforas Arquiteturais"?

• Aconselho aos nobres colegas a conhecer as regras que norteiam o XP antes de saírem comentando o que não conhecem, pois, não tem nada de errado o próprio nome é da coisa em si é "PROGRAMAÇÃO EXTREMA" e sim Kent orienta o que é bom deve ser levado ao extremo, se refatorar é bom? Então refatore sem pena, se testar é bom ? teste sem dó, e um dos artefatos do XP é o uso de metáforas, muito choro e pouco conhecimento.

  recomendo o curso de metodologias ágeis do Pedrosa no PdTI

• Gostaria de saber mais sobre Metoforas Arquiteturais...

Questão 144832

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2009
• Provas: CESPE - 2009 - INMETRO - Analista Executivo em Metrologia e Qualidade - Desenvolvimento de Sistemas - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

A ferramenta CruiseControl, empregada no âmbito de métodos de desenvolvimento que aderem ao ciclo de vida ágil, é uma ferramenta de gerenciamento de versões de código.

• C. Certo
• E. Errado

Gabarito: E

Comentários

•  O erro está em "empregada no âmbito de métodos de desenvolvimento que aderem ao ciclo de vida ágil"?

• CruiseControl é uma ferramenta de integração contínua e não de gerenciamento de versões de código.

Questão 144838

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2009
• Provas: CESPE - 2009 - INMETRO - Analista Executivo em Metrologia e Qualidade - Desenvolvimento de Sistemas - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

Nas abordagens de desenvolvimento bazaar e catedral e na sua relação com modelos de ciclo de vida de software, observa-se que em um desenvolvimento na abordagem bazaar, a arquitetura é emergente, o que não ocorre com um desenvolvimento na abordagem catedral; o conceito de liberação de código cedo e frequente, presente na abordagem catedral, afina-se com os métodos da eXtreme Programming e em ambos modelos, o desenvolvimento de software é colaborativo, aberto e embasado em prototipação.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• A questão se entrega nesse ponto:"o conceito de liberação de código cedo e frequente, presente na abordagem CATEDRAL"O correto seria:"o conceito de liberação de código cedo e frequente, presente na abordagem BAZAR"

•  Apenas complementando...

  Não existe uma formalização acadêmica sobre os modelos bazar e catedral. Esta foi apenas uma metáfora abordada por Eric S. Raymond (http://www.dominiopublico.gov.br/download/texto/tl000001.pdf) em um artigo que ele escreveu analisando a estratégia de desenvolvimento de Linus Torvalds. Um dos focos importantes é que o modelo catedral é o modelo tradicional, robusto de desenvolvimento de softwares, no qual entregas de valor são realizadas após longas iterações de desenvolvimento. Neste modelo, erros são complexos e profundos e são descobertos como uma surpresa infeliz pelo usuário, trazendo insatisfação pela inviabilização do uso do sistema. O modelo bazar enfatiza o conceito "Libere cedo, libere freqüentemente", por meio do qual os erros se tornam triviais e de fácil manutenção, pelo fato de vários "testadores" estarem analisando o software em curtos períodos de tempo. Este modelo também se baseia no efeito Delphi, no qual sociologistas descobriram que a opinião média de uma massa de observadores especialistas (ou igualmente ignorantes) é um indicador mais seguro que o de um único observador escolhido aleatoriamente.  

   

•  Ainda há alguns conceitos importante sobre o modelo bazar:

   

  • Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz. 
  • Dada uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém. (lei de Linus)
  • Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. Brooks, Capítulo 11: "Mostre-me seu código e esconda suas estruturas de dados, e eu poderei continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não necessitarei do seu código; ele será óbvio.''
  • Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso. 
• é correto afirmar que XP é embasado em prototipação?

• Entendo que não seja correto dizer que o desenvolvimento de software XP é embasado em prototipação.

  Se fosse "metáfora" no lugar de "prototipação" tudo bem. Mas prototipação é diferente.

Questão 147292

• Banca: FCC
• Órgão: SEFAZ-SP
• Ano: 2009
• Provas: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

O conceito de sprint aplica-se ao modelo ágil do processo de engenharia de software denominado

• A. XP.
• B. DAS.
• C. DSDM.
• D. Scrum.
• E. Crystal.

Gabarito: D

Comentários

• O Scrum trabalha com uma série de iterações, são diversos ciclos chamados de Sprints, um ou o conjunto de Sprints executados se consegue montar uma ou mais funcionalidades do sistema, o conjunto de funcionalidade integrada forma o sistema.

  Cada Sprint normalmente leva de 2 a 4 semanas para ser executada, esse período é chamado de Time Box.

• Os modelos agile tratam de modelos iterativos e de desenvolvimento. basicamente passa por modos os estagios do waterfall mdoel, mas em iterações que visam produzir uma versao funcional do software a cada incremento. Entre os principios agile estao simplicidade, conversa cara a cara, proximidade entre agentes do negocio & desenvolvedores etc. Todos os metodos agile têm a mesma filosofia de definição de de necessidades, planejamento do projeto, execução e monitoramento e entrega em ciclos rapidos e com foco na adaptação a eventuais mudanças no projeto. porem, ha algumas caracteristicas distintas entre os metodos:

   a)XP.- extreme programming. é o mais usado. o plano de testes é feito antes do codigo e programação é em pares. geralmente funciona para pequenas equipes, sendo IXP ideal para grandes empresas. 

   c)DSDM.- destaque à participação do usuario. baseado no RAD (rpaid application development). usa prototipos incrementais. 

   d)Scrum.- correto- framework estrutural para problemas complexos.  baseado no empirismo. 

   e)Crystal.- é uma familia (!) na qual a complexidade do projeto é determinada por cor. é ideal para diferentes projetos. o desenvolvimento incremental é no maximo 4 meses. 

Questão 149971

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Técnico Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

Para o método ágil de desenvolvimento conhecido como extreme programming, todos os requisitos funcionais são expressos como cenários (histórias do usuário) que são implementados diretamente como uma série de tarefas.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.Fonte: http://engenhariadesoftware.blogspot.com/2007/03/programao-extrema-xp.html
• [1]:
  "...os requisitos de usuário na XP são expressos com ocenários ou histórias, e o usuário prioriza esses requisitos para o desenvolvimento. A equipe de desenvolvimento avalia cada cenário e o divide em tarefas. Cada tarefa representa uma característica discreta do sistema e um teste unitário pode então ser projetado para essa tarefa."
  [1]; Sommerville, Engenharia de Software, 8ª Edição, página 266

Questão 149974

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Técnico Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Refatoração; XP (eXtreme Programming)

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

A técnica conhecida como refactoring é constantemente aplicada no desenvolvimento baseado no método ágil extreme programming.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte; Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

• Segundo Pressman, em seu livro Engenharia de Software, o XP encoraja a refabricação (refactoring). Um projeto em XP deve manter a simplicidade. Ele (o projeto) é visto como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção prossegue.

  A intenção do refactoring é controlar essas modificações sugerindo pequenas alterações de projeto que "podem aperfeiçoar radicalmente o projeto".

• Otimização constante.

• Refatoração: constante melhoramento, faz parte do extreme programming

Questão 149977

• Banca: CESPE / CEBRASPE
• Órgão: ANAC
• Ano: 2009
• Provas: CESPE - 2009 - ANAC - Técnico Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Teste de Software; XP (eXtreme Programming)

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

No modelo extreme programming, os testes de software só são realizados na etapa, final de desenvolvimento do software e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Programação em Pares (Pair Programming): é a programação em par/dupla num ÚNICO computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem.
  
  Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema
• Se testar é bom, vamos testar toda hora. Levar ao extremo.

• Extreme Programming inclui uma abordagem de testes que reduz as chances de erros desconhecidos na versão atual do sistema. O desenvolvimento test-first é uma das mais importantes inovações no XP. Em vez de escrever algum código e, em seguida, escrever testes para esse código, você escreve os testes antes de escrever o código. Isso significa que você pode executar o teste enquanto o código está sendo escrito e pode encontrar problemas durante o desenvolvimento.

  Fonte: SOMMERVILLE, Engenharia de Software, 9 Ed., pág 47.
  

• Dividindo para conquistar:

  
  

  No modelo extreme programming, os testes de software só são realizados na etapa final de desenvolvimento do software (Erro 1: os testes são feitos o tempo todo (ao extremo), até mesmo antes da codificação de cada funcionalidade, já que o XP faz uso do TDD) e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador (Erro 2: Os programadores trabalham sempre em pares, sendo vinculado apenas um computador para cada dupla de desenvolvedores).

  
  

  Bons estudos!
  

Questão 152503

• Banca: CESPE / CEBRASPE
• Órgão: TRE-MG
• Ano: 2009
• Provas: CESPE - 2009 - TRE-MG - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software; Processos de Software - Desenvolvimento Ágil; RUP (Rational Unified Process) - Processo Unificado Rational; XP (eXtreme Programming)

Assinale a opção correta acerca das metodologias de desenvolvimento de software.

• A. Extreme programming é um método centrado no usuário, na produtividade do desenvolvimento e na documentação de apoio.
  
• B. RUP, uma metodologia adequada para grandes projetos de desenvolvimento, tem como características a facilidade de uso e a agilidade do projeto.
  
• C. O Microsoft Solution Framework (MSF), apesar de não ser uma metodologia em si, mas um guia genérico para desenvolvimento, é uma solução ampla de engenharia de software que orienta desenvolvedores tanto no ambiente Microsoft, como em Unix.
  
• D. O uso de uma ou mais metodologias de desenvolvimento é prejudicial ao bom desempenho do projeto.
  
• E. Por ser embasado em componentes relacionados a objetos, o RUP permite a produção de uma arquitetura executável nas fases iniciais do projeto.

Gabarito: E

Comentários

• A) Errado! O XP não se preocupa tanto com documentação de apoio;
  B) Errado! O RUP não prega a agilidade;
  C) Errado! MSF não é utilizado no UNIX;
  D) Errado! As metodologias foram feitas para melhorar o desempenho, não piorar;
  E) Correto!  O RUP utiliza protótipagem e modularização, o que faz com que exista modelos executáveis até mesmo para o levantamento de requisitos (protótipos).

• o XP(extreme progamming) O método Programação eXtrema (XP, do inglês eXtreming Programming) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software.
  
  o uso de uma   ou mais....letra d) se eu não uso metodologias eu vou contra as boas práticas de desenvolvimento de software na atualidade, ficaria artesanal o desenvolvimento, agora não podemos usar várias ao mesmo tempo, misturar metodologias pode não ser muito prático.

• Gostaria de saber em qual literatura a banca se fundamentou para justificar a letra "d" como falsa. Parece ir contra o bom senso dizer que é benéfico ao projeto a utilização de múltiplas metodologias de desenvolvimento. Quem souber de onde a banca tirou essa "pérola". Por favor, me diga?
• Márcio, acho que o maior problema da letra D está em dizer que o uso de UMA ou mais metodologias de desenvolvimento é prejudicial. O uso de UMA metodologia certamente NÃO é prejudicial.
  Mais que uma, só se fosse SCRUM + XP, algo assim....
• Marcio, ha duas afirmacoes:
  O uso de uma metodologia de desenvolvimento é prejudicial ao bom desempenho do projeto. ERRADO.
  O uso de mais de uma metodologia de desenvolvimento é prejudicial ao bom desempenho do projeto.  CERTO
  Um item errado torna a questa errada.
  Questao de ler com calma.
  

• Ao contrário se uma ou mais prejudica então uma apenas prejudica.

   

  Será que tinha MSF no edital? Qual a base do CESPE para considerá-la errada? Na prática é difícil ver MSF em ambiente UNIX mas é impossível? E se por exemplo considerarmos tecnologias como Xamarin para Android e iOS ambos baseados em Unix(Linux e XNU/BSD)

   

  Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology solutions from Microsoft. MSF is not limited to developing applications only, it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology (Waterfall, Agile) but lets them decide what methodology to use.

   

• Embora o RUP não seja um processo adequado a todos os tipos de desenvolvimento de software, ele representa uma nova geração de processos genéricos. A mais importante inovação é a separação de fases e workflows, e o reconhecimento de que a implantação de software no ambiente do usuário é parte do processo. As fases são dinâmicas e tem objetivos. Os workflows são estáticos e constituem atividades técnicas que não estão associadas a uma única fase, mas podem ser utilizados ao longo do desenvolvimento para atingir os objetivos de cada fase 

Questão 162205

• Banca: FCC
• Órgão: TCE-AL
• Ano: 2008
• Provas: FCC - 2008 - TCE-AL - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Originalmente, o único produto da atividade de Projeto que é realizado como parte do processo XP (Extreme Programming)

• A. é a definição do caso de uso de contexto.
  
• B. são os cartões CRC.
  
• C. são os diagramas de objetos.
  
• D. são os diagramas de seqüência.
  
• E. é a codificação, feita em pares.

Gabarito: B

Comentários

• O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.
  
  Retirado de: http://engenhariadesoftware.blogspot.com/2007/03/programao-extrema-xp.html
• Como o projeto XP praticamente não usa nenhuma notação e produz poucos, ou nenhum produto de trabalho que não sejam os cartões CRC e as soluções de ponta, o projeto é visto como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção prossegue.
  
  Pressman, págin 65

• Atividades metodológicas do XP:

  - Planejamento: critérios de teste de aceitação, priorização das estórias de usuário, plano de iteração

  - Projeto: cartões CRC, soluções pontuais, protótipos

  - Codificação: refatoração, programação em dupla, testes de unidade, integração contínua

  - Teste: teste de unidades, integração contínua, testes de aceitação

Questão 163672

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2010
• Provas: CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Engenharia de Software
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software; Processos de Software - Desenvolvimento Ágil; RUP (Rational Unified Process) - Processo Unificado Rational; XP (eXtreme Programming)

Em metodologias de desenvolvimento de software, tem-se que

• A. as 6 fases da Unified Process (UP) são: Concepção, Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção.
  
• B. a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças.
  
• C. a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP) utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída.
  
• D. a Rational Unified Process (RUP) possui práticas em engenharia de software e sugestões de uso de ferramentas automatizadas que possibilitam acelerar a implementação do CMMI nível 2 e criar uma base consistente para o CMMI nível 3.
  
• E. a Rational Unified Process (RUP) é usada para desenvolver software de forma sequencial contínua, sem retroalimentação ou repetições evolutivas, e onde o produto só é verificado e testado no final da última fase.

Gabarito: D

Comentários

• a) as 6 4 fases da Unified Process (UP) são: Concepção, Elaboração, Construção e Transição. Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção.
  
  b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças.
  
  c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP)  utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída. --> conceitos trocados
  
• a) as 6 4 fases da Unified Process (UP) são: Concepção, Elaboração, Construção e Transição. Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção.
  
  b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças. 
  
  c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP) utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída.  --> conceitos trocados
  
  
  e) a Rational Unified Process (RUP) é usada para desenvolver software de forma sequencial contínua, sem retroalimentação ou repetições evolutivas, e onde o produto só é verificado e testado no final da última fase.
• Correção do comentário da Fernanda
  As quatro fases to processo unificado são: Concepção, Elaboração, Construção, Transição
  ou em inglês: Inception, Elaboration, Construction, Transition
• Brincadeira um cidadão desse que coloca um comentario só com a resposta ... Fala serio..
• a) as 6 fases da Unified Process (UP) são: Concepção, Projeto Lógico, Codificação, Projeto Físico, Testes e Manutenção. ERRADO. São 4 fases: Concepção(ou Iniciação), Elaboração, Construção e Transissão b) a Extreme Programming (XP) é uma metodologia complexa, complementar ao Unified Process (UP), concebida para sistemas de alto desempenho que exigem trabalho extremo de definição de requisitos muito bem definidos e isolados de mudanças.
  ERRADO. XP não é complementar ao RUP, muito menos concebida para sistemas de alto desempenho .... Um resumo do que é a XP: É um modelo Ágil de desenvolvimento. Sua metodologia adequada a equipes pequenas (até 10 pessoas), parte do princípio de que a melhor documentação é o código fonte. Para a XP, a arquitetura é na verdade desenvolvida ao longo do projeto onde todo o código escrito é constantemente reconstruído para aumentar a simplicidade e objetividade do mesmo.É baseada em práticas, como programação aos pares, semana de 40 horas e reuniões em pé. c) a Rational Unified Process (RUP) procura dar um enfoque menor à documentação, valorizando mais a comunicação oral; já a Extreme Programming (XP) utiliza todos os artefatos da UML2.0 para usar como componente de entrada e saída.
  ERRADO. As descrições estão invertidas. d) a Rational Unified Process (RUP) possui práticas em engenharia de software e sugestões de uso de ferramentas automatizadas que possibilitam acelerar a implementação do CMMI nível 2 e criar uma base consistente para o CMMI nível 3. CORRETA. O RUP é um processo completo de desenvolvimento de software e por causa disso acelera a implementação do CMMI nível 2. Veja abaixo o que o CMMI nível 2 pede: Nível 2: Gerenciado Planejado e executado de acordo com uma política  Emprega pessoas e outros recursos adequados Produz resultados controlados, com envolvimento de todas as partes interessadas É monitorado, controlado e revisado
  
  A maioria metas acima são atendidas se o processo de desenvolvimento é o RUP. Também se você alcança o CMMI 2 você já está com uma base consistente para trabalhar o nível 3.
    e) a Rational Unified Process (RUP) é usada para desenvolver software de forma sequencial contínua, sem retroalimentação ou repetições evolutivas, e onde o produto só é verificado e testado no final da última fase. ERRADO. O RUP é justamente o contrário de tudo acima, é um processo de software Iterativo e incremental onde o produto é verificado e testado em todas as fases

Questão 163969

• Banca: FCC
• Órgão: TJ-PI
• Ano: 2009
• Provas: FCC - 2009 - TJ-PI - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

XP (eXtreme Programming) é uma metodologia ágil para equipes pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática é denominada

• A. Time Coeso.
• B. Refatoração.
• C. Integração Contínua.
• D. Desenvolvimento Orientado a Testes.
• E. Ritmo Sustentável.

Gabarito: C

Comentários

• Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas, sendo uma delas:
   * Integração Contínua (Continuous Integration):
            - Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema.
  
            - Integrar de forma contínua permite saber o status real da programação.
• a) Time Coeso. - Mesmo se não for um time reduzido, por seguir padrões de codificação, qualquer membro do time é capaz de entender o que outro codificou.
  
  b) Refatoração. - O código é melhorado sem alterar o funcionamento externo do módulo. (Retira código redundante, cria funções, reescreve métodos... )
  
  c) Integração Contínua.  (Todo novo módulo após passar no teste unitário, já é submetido a testes de integração para garantir que não causou erros no restante do sistema)
  
  d) Desenvolvimento Orientado a Testes.  (Antes de codificar, os testes unitários já são escritos de acordo com os requisitos funcionais. Depois, são escritos os trechos de código de acordo coom estes testes)
  
  e) Ritmo Sustentável. (Não é pq chama Extreme Programming que a equipe tem que fazer horas extras, virar madrugadas, o XP diz que devem ser no máximo 8 horas de trabalho)
  
  

• Segundo Kent Beck

  Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

• c-

  a integracao continua é um conjunto de praticas q consiste em verificar que a cada modificacao o source code resultante das modificacoes nao produz regressao das aplicacoes ja criadas. o objetivo é identificar problemas de integracao o mais cedo possivel. tb permite automatizar a execucao de suite de testes e ver a evolucao do software

Questão 173821

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Arquiteto de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

Acerca dos processos XP e Scrum, assinale a afirmativa incorreta.

• A. O XP divide o ciclo de vida de desenvolvimento de software em 4 fases: Concepção, Elaboração, Construção e Transição.
• B. Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos chamados Sprints.
• C. No scrum os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade.
• D. XP é uma metodologia ágil para equipes de tamanho pequeno ou médio desenvolverem software com requisitos vagos ou que mudem rapidamente. Seus valores são comunicação, simplicidade, feedback e coragem.
• E. O Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu a partir de 1995.

Gabarito: A

Comentários

• fases do RUP: Concepção, Elaboração, Construção e Transição.

  Fases do XP: exploração, planejamento, iterações para release, validação para produção, manutenção e morte.

   

  O SCRUM possui o seguinte grupo de fases [SCHWABER, 1996]:
  Pregame:
   •  Planning: Definição do novo release baseado na lista de atividades
      conhecidas (backlog), juntamente com uma estimativa de tempo e
      custo. Se um novo sistema está sendo desenvolvido, esta fase
      consiste em conceitualização e análise do produto. Se um sistema
      existente está sendo aprimorado, esta fase consiste basicamente em
      análise.
  •  Architecture/Staging: Desenho de como os itens do backlog serão
     implementados. Esta fase inclui modificações na arquitetura do
     sistema bem como atividades de design de alto nível.
  Game:
   •  Development (sprints): Fase de desenvolvimento das funcionalidades
      do novo release, com constante respeito às variáveis de tempo,
      requisitos, qualidade e custo. A interação entre essas variáveis define
     o final dessa fase. Normalmente existem múltiplos sprints, ou
     iterações, que são usados para evoluir incrementalmente o sistema.
  Postgame:
  •  Closure: Preparação para o release, incluindo documentação do
     produto, testes e a realização do release.
   

• Questão muito fácil, pois as quatro fases da letra a são do RUP, que diferem muito do XP, mas achei a letra d) mal elaborada.
  
  a) Quem faz essa divisão é o RUP.
  b) Scrum é uma metodologia ágil. Correto!
  c) Os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade (itens mais importantes no topo). Essa lista deve ser constantemente atualizada e “repriorizada”. O scrum trabalha com desenvolvimento incremental. Correto!
  d) Os requisitos não são vagos, mas podem ser incrementados. Faltou o valor “respeito”. Não são pequenas equipes, mas pares de programação.
  e) Correto! Sem comentários.
• Henrique, sobre seu comentário a respeito da letra D, eu concordo em parte. Quanto a falta do valor respeito, está correto. Mas quanto a questão das equipes pequenas e médias, eu discordo do que você falou. O XP trabalha com equipes até 10 pessoas, sendo neste caso, 5 máquinas para cada par da equipe. A equipe é formada pelos conjuntos e pares.
  
  
  Bons estudos.
• Pessoal, entendo que a alternativa "c" contém informações erradas também. Para acertar esta questão precisa-se marcar "a mais errada".
  O product backlog contém os requisitos do sistema a ser desenvolvido ordenados por prioridade de valor para o cliente. Não há "tarefas" descritas no product backlog. Até mesmo porque quem é o dono do product backlog é o representante do cliente e ele não define tarefas para a equipe. As tarefas são organizadas no sprint backlog. Vejam o link http://improveit.com.br/scrum/product_backlog

• No scrum os requisitos do projeto são organizados em uma lista de tarefas (o correto seria funcionalidades), chamada de product backlog, em ordem decrescente de prioridade.

  Product Backlog => Lista de funcionalidades
  Sprint Backlog => Lista de tarefas
  Acho a letra C tão errada quanto a letra A. Esta questão deveria ser anulada.

• Esqueci que era FCC. em que marcar a mais errada!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Essa banca não é de Deus!!!
  

• A banca dessa vez era a FGV hehehe

• Deveria realmente ser anulada. Scrum não é uma metodologia, é um framework.

• Que pegadinha!

• Um projeto XP passa pelas seguintes fases: Exploração, Planejamento Inicial, Iterações do Release, Produção, Manutenção e Morte.

• O gabarito diz que é A. Mas essa divisão de fases não é no modelo RUP?

Questão 183766

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

É uma premissa típica do desenvolvimento ágil:

• A. O cliente aprende ao longo do desenvolvimento, à medida que é capaz de manipular o sistema.
• B. A especialização torna as tarefas mais simples e consequentemente facilita o determinismo.
• C. A especialização não impõe a necessidade, por parte de quem executa o trabalho, de pensar sobre o que está fazendo; basta fazer.
• D. O foco na execução torna o processo determinístico, para que a especificação seja transformada corretamente em software.
• E. Busca por processos determinísticos, visando menos alterações e maior previsibilidade.

Gabarito: A

Comentários

• Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.

  Os princípios do desenvolvimento ágil valorizam:

  * Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
  * Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
  * Softwares funcionais são a principal medida de progresso do projecto;
  * Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
  * Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
  * Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
  * Design do software deve prezar pela excelência técnica;
  * Simplicidade;
  * Rápida adaptação às mudanças;
  * Indivíduos e interações mais do que processos e ferramentas;
  * Software funcional mais do que documentação extensa;
  * Colaboração com clientes mais do que negociação de contratos;
  * Responder a mudanças mais do que seguir um plano.
   

• Gabarito: A
  
  Premissas do Desenvolvimento Ágil

  O cliente aprende ao longo do desenvolvimento, à medida que é capaz de manipular o sistema.

  Um dos problemas mais complexos que afetam o desenvolvimento de software é a enorme quantidade de detalhes que precisam ser considerados. Normalmente, ao especificar um sistema, o cliente tem o conhecimento de alguns aspectos do software que deseja. Entretanto, muitos outros só ficam claros quando ele tem a oportunidade de utilizar o sistema. Portanto, o cliente não especifica estes detalhes no início do projeto por uma razão muito simples: ele não os conhece [BECK, 2000]. Além do mais, mesmo que tais detalhes fossem conhecidos previamente, seria muito difícil especificá-los através de documentos, devido à grande quantidade de elementos que precisariam ser descritos.

  Perceber que o cliente aprende ao longo do desenvolvimento é a chave para se compreender o grande desafio existente no desenvolvimento de software. O cliente aprende à medida que tem acesso ao sistema e se envolve em discussões sobre ele. Este aprendizado pode ser utilizado para realimentar o processo de desenvolvimento ou pode ser ignorado. Esta última alternativa é o caminho adotado normalmente no desenvolvimento tradicional, pois ele parte da premissa que o cliente já sabe o que quer no início do projeto e a ele cabe apenas descrever os requisitos. Depois, ao final, ele receberá o sistema e não haverá ciclos de realimentação entre a especificação e a entrega do sistema [TELES, 2004].
  
  Fonte: http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=5916

Questão 183769

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No contexto das regras do SCRUM, é correto afirmar:

• A. Durante a realização do Sprint, o Backlog pode ser modificado por qualquer um dos elementos da equipe, desde que acordado nas reuniões semanais.
• B. O Sprint deve ser realizado num período não superior a 30 dias e ter um objetivo bem claro, baseado no Backlog.
• C. Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em qualquer momento no decorrer do Sprint.
• D. Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um rumo não desejável, novas funcionalidades devem ser implementadas para garantir o prazo do projeto.
• E. O foco na produtividade se estende às Scrum meetings e a conversação é pautada em discussões por toda a equipe.

Gabarito: B

Comentários

• Gabarito: B
  
  Nota sobre a questão: Ela não especifica se está tratando do Sprint Backlog ou do Product Backlog, trata genericamente um backlog o que complica um pouco o seu entendimento.
  
  A) Errada. O Product Backlog só pode ser modificado com o consentimento do Product Owner. Além disso, as reuniões durante um Sprint são diárias e não semanais. Por outro lado, se trata-se do Spring Backlog, este não pode ser modificado durante um Sprint.
  
  B) Correta.
  
  C) Errada. As modificações devem ser feitas com o consentimento de toda equipe e ainda com o consentimento do Product Owner (no caso do Product Backlog). Já o Spring Backlog não pode ser modificado, ele fica "congelado" durante um Sprint.
  
  D) Errada. Abnormal Termination: The Product Owner can cancel a Sprint if necessary.^[15] The Product Owner may do so with input from the team, scrum master or management. For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed. Fonte: Wikipedia
  
  E) Errada. Não é toda equipe que discute no Scrum Meeting : "All are welcome, but normally only the core roles speak".

• A alternativa E deveria estar certa.

Questão 183772

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Em reunião, toda conversação é restringida às respostas dos elementos às perguntas colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até a próxima reunião?"

As Scrum meetings ocorrem

• A. sempre que necessário.
• B. ocasionalmente.
• C. uma vez por semana.
• D. duas vezes por semana.
• E. diariamente.

Gabarito: E

Comentários

• Meetings (encontro Scrum)
  –Pequenos encontros diários da equipe
  •Geralmente pela manhã
  –Questões que aparecem devem ser resolvidas durante o dia e não na reunião
  –Os encontros iniciais são geralmente mais longos.
  –Questões que devem ser respondidas:
  •O quê você fez ontem?
  •O quê você vai fazer hoje?
  •Quais os problemas encontrados?
  –Evita: “Como um projeto atrasa um ano? Um dia por vez ...”
  •Qualquer deslize pode ser corrigido de imediato
• Reuniões Daily Scrum Cada dia durante o sprint, uma reunião de status do projeto ocorre. Isso é chamado de "scrum diário", ou "de pé o dia". Esta reunião tem diretrizes específicas: A reunião começa precisamente no horário marcado. Todos são bem-vindos, mas apenas "poucos" podem falar. O encontro tem duração determinada (Time-Box) e dura 15 minutos. A reunião deve acontecer no mesmo local e mesma hora todos os dias Durante a reunião, cada membro da equipe responde a três perguntas: O que você tem feito desde ontem? O que você está planejando fazer hoje? Você tem algum problema impedindo você de realizar seu objetivo?
  É papel do Scrum Master para facilitar a resolução desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a reunião possa durar menos de 15 minutos. Reunião de Planejamento da Sprint (Sprint Planning Meeting) No início do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting é realizado. Selecione o trabalho que está a ser feito. Prepare o Sprint Backlog que detalha o tempo que levará para fazer esse trabalho, com toda a equipe. Identificar e comunicar o quanto o trabalho é susceptível de ser feito durante o sprint atual. Dividida em duas partes: Parte 1 (Primeiras quatro horas): Team Product Owner: diálogo para priorizar o Product Backlog. Parte 2 (Próximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando na Sprint Backlog.

  
  No final de um ciclo de sprint, são realizadas duas reuniões: a "Sprint Review" e do "Sprint Retrospective".

   

  Reunião de Revisão da Sprint (Sprint Review) Rever o trabalho que foi concluído e não concluído. Apresentar o trabalho realizado para os interessados (ou "a demo"). Um trabalho incompleto não pode ser demonstrado. Retrospectiva da Sprint (Sprint Retrospective) Todos os membros da equipe refletem sobre a sprint passada. Três questões principais são feitas na retrospectiva sobre o sprint:
  O que deu errado?
  O que deu certo?
  O que poderia ser melhorado para o próximo sprint?

Questão 183775

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No SCRUM, o produto final, a data final e o custo do projeto são determinados:

• A. respectivamente, no planejamento, ao longo do projeto, no início do projeto.
• B. ao longo do projeto.
• C. no planejamento.
• D. respectivamente, nas fases intermediárias, no planejamento, no final do projeto.
• E. em função das iterações.

Gabarito: B

Comentários

• Resposta: letra B.
  O Scrum propõe a existência de uma tríplice restrição formada por escopo, importância e estimativa, onde escopo e importância são definidos pelo product owner. Estimativa é definida pela equipe durante uma reunião de planejamento do sprint, estas três variáveis são refinadas continuamente por diálogo cara-a-cara entre equipe e product owner.

• As expressões "em função das iterações" e "ao longo do projeto" parecem ter significados equivalentes no contexto apresentado. Vocês não acham?

   

   

• Fiquei com a mesma dúvida do rapaz acima! :/
• Concordo com o Daniel Luiz
• Fiz essa questão e também achei que as letras B e E estão certas. O custo é por funcionalidade adicionada. Cada iteração representa(m) nova(s) funcionalidade(s).
• Compartilho do entendimento dos colegas acima, os termos iterações e ao longo do projeto me parecem, no contexto, termos que tratam da mesma coisa.
  Afinal as iterações ocorrem ao longo do projeto, e o projeto é contruido em função das iterações. O produto final é contruido em função das iterações, bem como a data final e o custo do projeto.
  Questão muito estranha...
• FCC aprontando mais uma das suas... já nem me esquento mais. Imagine o tanto de recursos contra essa questão, e não foi anulada. Esse país é terra de ninguém.

• Na verdade iteração é o conceito para o ciclo do XP, assim como Sprint é o conceito da iteração no Scrum. Por isso que a questão continuou válida e o gabarito é a letra B. 
  

• SCRUM não tem iterações, mas Sprints, portanto é fácil de entender porque a E não está correta. Tem algumas perguntas da FCC que são estranhas mesmo, mas neste caso é uma resposta errada, ou seja, eles põe o que quiserem e o candidato tem que saber que aquilo não é relacionado o assunto da pergunta e ponto, se o conceito estivesse na pergunta aí sim dava para questionar anulação, mas na resposta, se fosse assim não iam existir perguntas válidas, pelo menos eu vejo dessa forma.

• Retirado so Scrum Guide 2011.

  Um dos itens da Revisão da Sprint:

  "O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data;"

  Como todos sabem, o Product Backlog é dinâmico. O custo é baseado no tempo e no escopo. Logo estão relacionados. 

  Se o Scrum Guide diz que a cada revisão é avaliado como o Product Backlog está, sabendo que o PO pode mudá-lo constantemente, e que é avaliado prováveis datas de conclusão (ou seja, a cada Revisão pode alterar)...infere-se que:

  - custo

  - data final

  - produto final (soma dos requisitos do Product Backlog implementados "Pronto",

  são decididos ao longo do projeto (Reviews)

  
  

• Pessoal, 

  Me desculpem mas eu entendo que a resposta certa para este pergunta deveria ser a C, porque o produto final , data final e o custo do projeto deve ser definido no planejamento do projeto, senão, como alguém poderia fechar um projeto utilizando SCRUM sendo que o custo seria mapeado ao longo do projeto?

  
  

  Não faz sentido :(

  
  

  a questão é que se houver mudanças ao longo do projeto, estas serão tratadas como aumento de escopo e impactarão no prazo e no custo, porém caso o projeto mantiver o backlog original, tanto o scrum master quanto a equipe, terão que trabalhar para alcançar o prazo definido com o custo definido.

• Cara Michele H., é claro que o SCRUM possui iterações, afinal de contas ele é um método ITERATIVO E INCREMENTAL, como todas as demais metodologias ágeis e até mesmo algumas não-ágeis como RUP e RAD. 
  
  

  "Scrum 
  É um processo de desenvolvimento iterativo e incremental. É utilizado quando não se consegue predizer tudo o que irá ocorrer. Em geral, utiliza-se em projetos complexos, de difícil abordagem pela Engenharia de Software."
  Fonte: http://www.inf.ufpr.br/lmperes/ciclos_vida/scrum_crystal.pdf

• Essa questão deveria ter sido anulada, pois há duas alternativas corretas a letra (B) e (E). Vejamos abaixo.

   

  Como outros métodos ágeis, Scrum é uma metodologia que prima pelo desenvolvimento iterativo e incremental de software. Em termos práticos, isto significa que ciclos contendo um conjunto de específico de atividades são repetidos continuamente ao longo de um projeto; por incremental, deve-se ter em mente a ideia de sucessivas entregas de funcionalidade, acrescentando aquilo que se espera do software em intervalos constantes de tempo.

• No Scrum, o tempo e o custo geralmente são fixos e o escopo é variável, ou seja, eu não parto do escopo para descobrir o tempo - eu parto do tempo para descobrir o escopo. Ser fixo não significa que é determinado antes. Eu posso dizer que minha data final é daqui três meses e a equipe de projeto vai fazer quantas funcionalidades conseguir nesse tempo. Ao longo do projeto, eu posso dizer que tenho mais três meses para entregar e a equipe dirá que dá para fazer mais algumas funcionalidades. Então, eu sempre parto do tempo para decidir o escopo e não do escopo para definir o tempo. Por que? Porque senão o projeto dura eternamente. O PO muda de ideia, pede mudanças, adiciona requisitos e o escopo do projeto nunca é alcançado e nunca chega ao fim do projeto. Então, isso é definido ao longo do projeto.

  Gabarito: Letra B 

• Como que a data final é definida ao longo do projeto? kkkkk

Questão 183778

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

No eXtreme Programming ? XP

• A. o código é integrado e testado depois de alguns dias e, no máximo, até o final da semana.
• B. a codificação é feita em grupos de programadores (no mínimo 3 integrantes), preferencialmente num único computador.
• C. as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode adotar as regras de outra equipe.
• D. releases quando complexos não podem deixar de fora os requisitos de negócio de maior valor para o cliente.
• E. módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.

Gabarito: E

Comentários

• a) Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

  b) A programação é em par/dupla num único computador.

  c) A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

  d) Releases é a a liberação de pequenas versões funcionais do projeto. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Portanto não são complexos. Lembre-se simplicidade é um dos valores do XP.

  e)O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema. CORRETO

• Não vejo erro na letra C)  as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode adotar as regras de outra equipe.
•  a) o código é integrado e testado depois de alguns dias e, no máximo, até o final da semana.
   
      O CODICO É TESTADO ANTES DA CODIFICAÇÃO E A INTEGRAÇÃO PODE SER DIARIA
  
  • b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes), preferencialmente num único computador.

  FEITA EM PARES

  • c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode adotar as regras de outra equipe.
  • EQUIPES SÃO AUTO-ORGANIZADAS
  • d) releases quando complexos não podem deixar de fora os requisitos de negócio de maior valor para o cliente.
  • RELEAES SIMPLES
  • e) módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.  
  • OK

•  e)módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem o direito de checar um módulo e modificá-lo.

  Em agile, sempre que um incremento é entrgue a um cliente, os testes de aceitação sao os use cases, o que causa feedback. 

• e) Propriedade Coletiva 

• Letra E. 

   

  O  Processo XP 

  Emprega uma abordagem orientada a objetos e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: 

  1 – Planejamento 

  Jogo do Planejamento, se inicia com ouvir que conduz a criação de um conjunto de histórias (similar ao caso de uso) pelo próprio cliente. Cada história é colocada em uma ficha (CRC), o cliente atribui um valor e os membros da equipe atribui um custo medido em semanas de desenvolvimento, pode ter até 3 semanas, caso tenha mais a história tem que ser quebrada e reavaliada. Clientes e desenvolvedores decidem como agrupar as histórias para a versão seguinte (incremento). As histórias podem ser ordenadas de 3 formas: 

  Depois da primeira versão (também denominada incremento de software) ser entregue pela equipe XP, é calculada a velocidade do projeto. Conforme o trabalho de desenvolvimento prossegue, o cliente pode acrescentar histórias, alterar ou eliminar outras. 

  2 – Projeto 

  Segue o princípio KIS (keep is simple, ou seja, preserve a simplicidade). Encorada o uso de cartões CRC (classe-responsabilidade-colaborador), CRC é o único artefato. Se uma história estiver traumática para ser construída, é feito um protótipo operacional (solução pontual). Encoraja a refatoração, Fowler diz: "Refabricação é o processo de alteração de um sistema de software de tal forma que não se altere o comportamento externo do código, mas se aprimore a estrutura interna. É uma forma disciplinada de organizar código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refabricar, se está aperfeiçoando o projeto de codificação depois de este ter sido feito." 

  3 – Codificação 

  Etapas: 

  4 – Testes 

  Teste de unidade deve ser automatizado encorajando uma estratégia de teste de regressão (utiliza a prática/método TDD). Testes de unidades individuais são organizados em um "conjunto de testes universal". Teste de aceitação ou teste de cliente, é especificado pelo próprio cliente obtidos de histórias de usuários 

   

   

   

  Fonte:  

  Livro: Engenharia de SOFTWARE 

  Autor: Roger S. Pressman 

  Editora: AMGH Editora LTDA 

  Edição: 7ª - 2011 

  Capítulo: 3 

Questão 183781

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Prática que deve ser utilizada com intensidade durante um projeto de XP para facilitar a comunicação e fixação dos assuntos entre as partes, uma vez que, ao criar comparações e analogias com o assunto em questão as pessoas passarão a entender de uma forma muito mais rápida e possivelmente não terão dificuldade de memorização. Ela está fortemente associada a outra boa prática, que para ser exercida exige bem estar e boa condição física do desenvolvedor. Tais práticas são, respectivamente:

• A. simplicidade e coragem.
• B. jogo do planejamento e refactoring.
• C. metáfora e ritmo sustentável.
• D. simplicidade e ritmo sustentável.
• E. jogo do planejamento e integração contínua.

Gabarito: C

Comentários

• São práticas ágeis que se aderem as características posta na questão:

  1. Metáfora: o time se comunica sobre o software em termos de uma metáfora, caso consiga encontrar uma boa.

  2. Semana de 40 horas (ritmo sustentável): trabalhar por longos períodos é contraproducente.
  

  Bons estudos!
  

  
  

• São práticas do XP:

  
  

  - Padrões de desenvolvimento;

  
  

  - Design simples;

  
  

  - Cliente sempre disponível ou presente;

  
  

  - Jogo de planejamento;

  
  

  - Stand up meeting;

  
  

  - Programação em pares;

  
  

  - Refactoring;

  
  

  - Desenvolvimento guiado por testes;

  
  

  - Código coletivo;

  
  

  - Metáfora;

  
  

  - Ritmo sustentável;

  
  

  - Integração contínua;

  
  

  - Releases curtos;

  
  

  
  

  Metodologias Ágeis - Engenharia de Software sob Medida (Sbrocco & Macedo, 1ª Edição, 2012)

Questão 186766

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

A Aliança Ágil (The Agile Alliance) define diversos princípios para aqueles que querem alcançar agilidade no desenvolvimento de software. Dentre eles, podem ser considerados:

I. Modificações de requisitos não são bem-vindas em nenhuma etapa do desenvolvimento.

II. O pessoal de negócios e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.

III. Simplicidade - a arte de maximizar a quantidade de trabalho não efetuado - não é essencial.

IV. Software funcionando é a principal medida de progresso.

Está correto o que consta em

• A. I, II, III e IV.
• B. II e IV, somente.
• C. I e III, somente.
• D. I, II e IV, somente.
• E. II, III e IV, somente.

Gabarito: B

Comentários

• I. Modificações de requisitos não são bem-vindas em nenhuma etapa do desenvolvimento. Errado. 
  
  III. Simplicidade é a arte de maximizar a quantidade de trabalho não efetuado e não é essencial. Errado.
• I. Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o cliente.
  
  III. Simplicidade - a arte de maximizar o volume de trabalho não efetuado - é essencial
• De acordo com Presman (Engenharia de Software: uma abordagem profissional, 7ª Edição)[p.  84 e 85], o grupo responsável pelo “movimento ágil”, também conhecido como Agile Alliance (Aliança dos Ágeis), estabelece 12 princípios importantes para quem desejar aderir e ter agilidade no desenvolvimento de software, são eles:
  
  1.       “A maior prioridade é satisfazer o cliente por meio de entrega adiantada e contínua de software valioso.
  2.       Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o cliente.
  3.       Entregue software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos.
  4.       O pessoal comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao longo de todo o projeto.
  5.       Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários e confie neles para ter o trabalho feito.
  6.       O método mais eficiente de transmitir informações para e dentro de uma equipe de desenvolvimento é uma conversa aberta, de forma presencial.
  7.       Software em funcionamento é a principal medida de progresso.
  8.       Os processos ágeis promovem desenvolvimento sustentável. Os proponentes, desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente.
  9.       Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade.
  10.   Simplicidade – a arte de maximizar o volume de trabalho não efetuado – é essencial.
  11.   As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.
  12.   A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo.”
• Resolvi esta questão lembrando que na xp:
  I) os requisitos são vagos e estão em constante mudança;
  II) há a prática do cliente presente;
  III) há a prática do projeto simples; e
  IV) há a prática dos pequenos releases.
  
  
  Tornando errados os itens I e III.

•  b)II e IV, somente.

  principios de agile- 

  1 satisfazer cliente sempre

  2 modificações de requisito sao bem-vindas

  3 entrega frequente de software funcional (d 2 semanas a 2 meses)

  4 pessoal negocio & desenvolvimento juntos

  5 construção de projetos por pessoas motivadas

  6 comunicação cara a cara.

  7 indicador - software funcional

  8 desenvolvimnento sustentavel

  9 excelencia contínua

  10 simplicidade

  11 auto-organização

  12 reflexões de como ser mais efetivo

Questão 186772

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Os princípios Scrum são usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouço: requisitos, análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas de trabalho ocorrem dentro de um padrão de processo chamado

• A. pendência.
• B. iterator.
• C. demo.
• D. história de usuário.
• E. sprint.

Gabarito: E

Comentários

• Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Se você chegou até aqui interessado em fazer uma das certificações disponíveis para Scrum, veja por que dizemos não à certificação?

  No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

  As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

  A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

  Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint.

  fonte:
  http://improveit.com.br/scrum
  =========================================

  Cada sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.

  fonte: http://pt.wikipedia.org/wiki/Scrum

• Gabarito "E". Os princípios Scrum são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint. O trabalho realizado dentro de um sprint (o número de sprints necessários para cada atividade metodológica varia dependendo do tamanho e da complexidade do produto) é adaptado ao problema em questão e definido, e muitas vezes modificado em tempo real, pela equipe scrum. (Fonte: Livro Engenharia de Software 7ed, Pressman, pag 95)

• Repetiram essa questão...

• e-

  sprint - a iteracao do scrum

Questão 189232

• Banca: CESGRANRIO
• Órgão: ELETROBRAS
• Ano: 2010
• Provas: CESGRANRIO - 2010 - ELETROBRAS - Analista de Sistemas - Suporte Basis SAP R3
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No âmbito do desenvolvimento ágil de sistemas de informação, é INCORRETO afirmar que, no SCRUM,

• A. as atividades são definidas com uma duração fixa.
• B. o foco é nas tarefas e não nos objetivos e resultados.
• C. o desenvolvimento é iterativo e incremental.
• D. cada iteração foca nas necessidades mais prioritárias.
• E. cada iteração é finalizada com funcionalidades completas.

Gabarito: B

Comentários

• b) o foco é nas tarefas e não nos objetivos e resultados.
  O foco é nos resultados, ou seja, nas entregas.
• SPRINT GOAL: - Definido na primeira parte do planejamento do sprint(sprint planning meeting); - É o objetivo final do Sprint, traduz que parte do negócio será construída naquele ciclo de iteração; - Dar visão aos desenvolvedores daquilo que está sendo construído pelo time, evitando que eles permaneçam focados apenas em suas tarefas e esqueçam-se do porque elas estão sendo construídas.   Fonte: http://www.tiespecialistas.com.br/2011/08/desenvolvimento-agil-de-software-utilizando-scrum/
• Esta questão poderia ser alvo de recurso por apresentar duas questões incorretas.
  Os livros de Ken Schwaber não formalizam o termo "atividade" na metodologia Scrum.
  Atividade na nomenclatura usual estaria mais alinhada no Scrum ao esforço para entregar um item do Product ou Sprint Backlog do que a um Sprint, que é o que aparentemente o autor da questão queria se referir.
• Questão com duas alternativas incorretas, porém uma mais fácil de acertar que a outra.
  
  a) as atividades são definidas com uma duração fixa.
  o correto seria:
  as sprints são definidas com uma duração fixa. este é o conceito de time-boxed do Scrum. as atividades compõem o Sprint backlog e foram decompostas pelo time para organizar o seu trabalho.
  
  b) o foco é nas tarefas e não nos objetivos e resultados.
  o correto seria:
  o foco é nos objetivos e resultados e não nas tarefas.
  
  O meu raciocínio foi que a banca claramente se confundiu no item a), mas definiu o gabarito letra b), que seria irrefutável.
  De qualquer modo, a questão merece ser anulada.

• DICA: SCRUM é focado em processos gerenciais, e estes não são tarefas.
  

• Como se a 'A' estivesse correta....

Questão 189235

• Banca: CESGRANRIO
• Órgão: ELETROBRAS
• Ano: 2010
• Provas: CESGRANRIO - 2010 - ELETROBRAS - Analista de Sistemas - Suporte Basis SAP R3
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No SCRUM, que papel é responsável pela visão do produto e pelo retorno do investimento?

• A. Scrum Master.
• B. Product Owner.
• C. Sprint Planner.
• D. Gerente do Projeto.
• E. Analista de Sistemas Sênior.

Gabarito: B

Comentários

• O Product Owner é o responsável inclusive pela elaboração do Product Backlog, que é uma lista de requisitos, ou funcionalidades, que se espera do software, em linguagem de alto-nível.

  As funcionalidades desse Product Backlog são quebradas em tarefas, e adicionadas ao Sprint Backlog. Ao final de um sprint todas as atividades previstas no sprint backlog devem ser concluídas.

  O Product Owner pode alterar o Product Backlog tanta quanto queira, desde de que o item em questão não esteja no sprint atual.

• 
  
  http://scrumemacao.com.br/web/index.php?option=com_content&view=article&id=11&Itemid=11
•  (E) a) Scrum Master. não é responsável pela visão do produto: "Product Owner (...) Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;" [1]
   
   (C) b) Product Owner.  "responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento" [1]
   
   (E) c) Sprint Planner. não é um papel definido pelo scrum.
   
  (E) d) Gerente do Projeto. não é um papel definido pelo scrum.
   
  (E) e) Analista de Sistemas Sênior. não é um papel definido pelo scrum.
  
  fonte: [1] http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf

Questão 189238

• Banca: CESGRANRIO
• Órgão: ELETROBRAS
• Ano: 2010
• Provas: CESGRANRIO - 2010 - ELETROBRAS - Analista de Sistemas - Suporte Basis SAP R3
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

No âmbito de desenvolvimento de sistemas, o XP tem como característica a programação em par, na qual o(a)

• A. programador codifica em companhia do analista de requisitos.
• B. testador realiza os casos de teste em companhia do programador.
• C. código é escrito em par, reduzindo a inserção de bugs.
• D. programador codifica em companhia do gestor do sistema.
• E. disseminação do conhecimento não é priorizada, mas, sim, a individualidade.

Gabarito: C

Comentários

• A idéia de programação em pares é a de que, tendo dois programadores em uma mesma estação de trabalho, enquanto um programa, o outro verifica o que esta sendo feito, sendo que ambos revezam. A intenção é a de que um possa identificar falhas do outro, reduzindo assim os erros.
• "A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela."
  
  Fonte: http://improveit.com.br/xp/praticas/programacao_par
• Alternativa C
• esse Kayto fica postando as respostas e acha que tá abafando. Baseado nos 2 primeiros comentários, qualquer um com 2 neurônios conseguiria deduzir a resposta.
• Segundo SOMMERVILLE,
  Programação em pares: Os desenvolvedores trabalham em pares, verificando o trabalho dos outros e prestando apoio para um bom trabalho sempre.
  
  

  Segundo Artigo DevMedia: 

  Programação em pares: Trata-se de duas pessoas trabalhando com uma máquina em que um codifica, e o outro critica ou dá susgetões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado.

Questão 192862

• Banca: FCC
• Órgão: MPE-RN
• Ano: 2010
• Provas: FCC - 2010 - MPE-RN - Analista de Tecnologia da Informação - Engenharia de Software
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Refactoring, programação em pares e Stand-up Meeting são características das práticas do

• A. PRINCE2.
• B. Rational Unified Process.
• C. Extreme programming.
• D. PMBOK.
• E. SCRUM.

Gabarito: C

Comentários

• Jogo de Planejamento (Planning Game):
  Pequenas Versões (Small Releases):
  Metáfora (Metaphor):
  Projeto Simples
  Time Coeso (Whole Team):
  Testes de Aceitação (Customer Tests):
  Ritmo Sustentável (Sustainable Pace):
  Reuniões em pé (Stand-up Meeting):
  Posse Coletiva (Collective Ownership):
  Programação em Pares (Pair Programming):
  Padrões de Codificação (Coding Standards):
  Desenvolvimento Orientado a Testes (Test Driven Development):
  Refatoração (Refactoring):
  Integração Contínua
   

• Me surgiu uma dúvida. O SCRUM também não possui essas características não?
• O Scrum não tem programação em pares.
• c) Extreme programming.

• "O Scrum não tem programação em pares."

  Na teoria não tem, mas na prática o SCRUM pode adotar as boas práticas do XP e utilizar a técnica de programação em pares.

• Refactoring é um conceito praticamente criado pelo XP

•  c)Extreme programming.

  o que define XP: 4 valores- comunicação, simplicidade, respeito, coragem, feedback-, programação a 2, stand-up meeting, criação de testes antes de programação

• Que explicação! Eu também cheguei a essa conclusão antes de vir aos comentários

Questão 195304

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil

Julgue os itens a seguir, relativos a modelos ágeis de processo.

O desenvolvimento adaptativo de software (DAS) é uma técnica para construção de sistemas e software complexos que foca na colaboração e na auto-organização da equipe.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• DAS - Desenvolvimento Adaptativo de software - é uma técnica paraa construção de sistemas e software complexos. O apoio filosofico do DAS concentra-se na colaboração humana e na auto-organização da equipe

• Desenvolvimento adaptativo de software (adaptive software development -- ASD): Prioriza a velocidade e a flexibilidade. Funciona melhor em cenários onde a organização precisa produzir  resultados com rapidez para um aplicativo que pode crescer à medida que os clientes o utilizam. Foi desenvolvido por Jim Highsmith. 

  fonte: http://cio.uol.com.br/tecnologia/2007/11/19/idgnoticia.2007-11-19.18...

• Livro Pressman
  

  
  

  Página 66, capítulo 4, “Desenvolvimento Ágil”.
  

  
  

  O DAS (Desenvolvimento Adaptativo de Software) foi proposto por Jim Highsmith como uma técnica para construção de sistemas e software complexos. O apoio filosófico do DAS concentra-se na colaboração humana e na auto-organização da equipe.

  
  

  Fonte: https://alessandramclima.wordpress.com/2010/09/22/tcu-2010-engsw-parte-2/
  

Questão 195307

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Julgue os itens a seguir, relativos a modelos ágeis de processo.

A agilidade não pode ser aplicada a todo e qualquer processo de software.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• A agilidade pode ser empregada a qualquer processo de software. Entretanto, para conseguir isso, é essencial que o processo seja projetado de modo que permita a equipe de projeto adaptar tarefas e aperfeiçoá-las, conduzir o planejamento para que se entenda a fluidez de uma abordagem de um desenvolvimento ágil, eliminar tudo, menos o produto do trabalho mais essenciais e mantê-los simples, e enfatizar uma estrategia de entrega incremental que forneça o software funcionando ao cliente o mais rápido possível para o tipo de produto e ambiente operacional.

   

  Pressman, 6º edição. pag. 60

• Então a agilidade pode ser a plicada a todo e qualquer processo de software, desde que seja o processo adequado! Logo... não é mais 'todo e qualquer processo de software'.
  
  Questão vergonhosa. Nada menos que isso...
• O Pressman é bem parecido com o Cespe. Ele meio que diz assim: 1+1 = 2, MAS se vc adicionar um terá o resultado 3. Que nem na questão, ele fala que TODO...e depois....DESDE QUE.....
  
  Então não é TODO !!!!

• Para ampliar a discussão: "SOMMERVILLE, 9 ed., pág. 53: "O escalamento de métodos ágeis para sistemas de grande porte é difícil. ...A integração contínua é praticamente impossível quando existem várias equipes de desenvolvimento separadas trabalhando em um projeto". E mais (pág. 52): "A introdução de métodos ágeis em grandes empresas é dificil por diversas razões: 1)...2) Nas grandes organizações existem procedimentos e padrões de qualidade que todos os projetos devem seguir e, por causa de sua natureza burocrática, geralmente são incompatíveis com os métodos ágeis". Ora, quem está certo? Os doutores do CESPE ou as referências clássicas?

• Há um tempo atrás existia um certo preconceito por parte dos autores com esse tipo de metodologia... Acho que depois do http://agilemanifesto.org ficou mais fácil marcar errado nessa questão
  

• É possível aplicar agilidade ao modelo em cascata? Não! Questão correta.

• Pressman também erra. Dessa vez falou bobagem.

• #partiu aplicar agilidade em software de aviônica, pra quê métodos formais né, se o avião cair caiu

Questão 195310

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue os itens a seguir, relativos a modelos ágeis de processo.

O processo XP (extreme programming) envolve a realização das atividades de planejamento, de projeto, de codificação e de teste.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• o XP usa a abordagem orientada a objeto com oparadigma de desenvolvimento predileto. Inclui um conjunto de regras e práticas que ocorrem no contexto de 4 atividades:

  1. Planejamento

  2. Projeto

  3. Codificação

  4. Teste

• 4 atividades básicas do desenvolvimento: Programar, testar, ouvir, projetar (Kent Beck)

  4 atividades de arcabouço:Planejamento,  projeto, codificação e teste (Pressman)

  Questão correta , seguindo a definição dada por Pressman.

Questão 195313

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue os itens a seguir, relativos a modelos ágeis de processo.

A atividade de planejamento XP inclui a criação das denominadas histórias de usuário, nas quais devem ser descritas as características e as funcionalidades requeridas para o software em desenvolvimento.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• A atividade de planejamento começa com a criação de um conjunto de histórias ( também chamadas de história dos usuários) que descrevem as caracteristicas e as funcionalidade requerida para o software  a ser construído. Cada história é escrita pelo cliente e é colocada em um cartão de indexação. O cliente atribui uma valor ( prioridade) para a história com base  no valor do negeócio global da caracterisitca ou da função. Membros da equipe XP avaliam cada história e lhe atribui um custo - medido em semanas de desenvolvimento.

Questão 195316

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue os itens a seguir, relativos a modelos ágeis de processo.

A atividade de projeto é uma desvantagem do processo XP, pelo fato de requerer uma quantidade de produtos de trabalho considerada excessiva pela comunidade de desenvolvimento de software.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• o XP segue rigorosamente o principio KIS ( Keep it  simple - mantenha a simplicidade).

   O XP encoraja o uso de cartões CRC ( class-Responsibility-Colaborator) que identifica e organizam as classes orientadas a objetos., que são relevantes para o incremento do software atual. OS  cartões CRC são o único produto de trabalho do projeto que é realizado como parte do projeto XP.

  pressamn, 6º edição. pág. 64

• Prática do XP: Projeto simples - O código está, a qualquer momento, na forma mais simples que passe todos os testes.

Questão 201328

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2010
• Provas: CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da Informação - Arquitetura de Tecnologia
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Desenvolvimento ágil de software (agile software development) ou método ágil é aplicado, principalmente, a grandes corporações, uma vez que permite produzir grandes sistemas de forma ágil.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Sistemas de desenvolvimento ágil é adequado a processo que não sejam muito longos ou complexos. O XP por exemplo, sugere um limite máximo de 36 semanas.

• Outro ponto a ser questionado sobre a aplicabilidade dos métodos ágeis:

  O fator mais importante é provavelmente o tamanho do projeto (Cohen et al., 2004)..[2] Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas.

  Fonte: http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

• Errado
  
  Desenvolvimento ágil de software (agile software development) ou método ágil é aplicado, principalmente, a grandes corporações, uma vez que permite produzir
  grandes sistemas de forma ágil.
  
  Veja a comparação entre desenvolvimento ágil e desenvolvimento direcionado ao planejamento:

  Ambiente ideal para o desenvolvimento ágil:

  • Baixa criticidade
  • Desenvolvedores senior
  • Mudanças freqüente de requisitos
  • Pequeno número de desenvolvedores
  • Cultura que tem sucesso no caos.

  Ambiente ideal para o desenvolvimento direcionado ao planejamento:

  • Alta criticidade
  • Desenvolvedores Junior
  • Baixa mudança nos requisitos
  • Grande número de desenvolvedores
  • Cultura que procura a ordem.
  
  Referência: http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software#M.C3.A9todos_.C3.A1geis_e_o_gerenciamento_de_projeto
• Bom, vou responder a questão citando uma fonte confiável: o meu querido Sommerville[1]:
  "Todos os métodos têm limites, e os métodos ágeis são somente adequados para alguns tipos de desenvolvimento de sistema. Na minha opinião, eles são mais adequados para o desenvolvimento de sistemas de pequenas e médias empresas e produtos para computadores pessoais."
  
  Ele fala mais coisas mas estou com preguiça de transcrever tudo.
  
  [1] Sommerville, Engenharia de Software, 8ª Edição, página 263
  

• errado-

  agile usa metodo iterativo em espiral de desenvolvimento no qual projeto & construção sao intercalados, isto é, eles se repetem ate o final do processo e no final de cada ciclo tem-se uma versao do software funcional

Questão 201331

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2010
• Provas: CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da Informação - Arquitetura de Tecnologia
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

O Scrum é utilizado, como função primária, para o gerenciamento de projetos de desenvolvimento de software, mas também tem sido usado como extreme programming e outras metodologias de desenvolvimento. Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Scrum é mais voltado para o gerenciamento da equipe. XP é mais voltado para metodologias práticas de desenvolvimento ágil de software. Trabalham muito bem em conjunto.

• A redação da questão, ao meu ver, é no mínimo questionável: 
  - Função primária de gerenciamento de projetos? Onde está o papel de gerente de projetos no Scrum? Essa frase pode funcionar bem como uma mera analogia. Não lembro de referências oficiais que digam que o foco do Scrum é a gestão de projetos, mas sim direcionar os ciclos de desenvolvimento a entregas rápidas e de valor para o cliente.
  - Ser usado COMO XP? Por ser um framework, vejo que ele pode ser incorporado a processos XP, mas também ao R(UP), ao FDD, ao MDD, mas não usado COMO se fosse...
  
  
  
• Acho que o trecho "...mas também tem sido usado COMO extreme programming..." foi escrito errado e deveria ter sido escrito da seguinte forma para questão ficar congruente: "...mas também tem sido usado COM O extreme programming..."
• Concordo com o comentário anterior...e visto que a questão foi escrita de modo errada, esta deveria ter sido anulada...principalmente por se tratar de uma prova com CERTO e ERRADO
• Concordo com o segundo colega, scrum é um modelo ágil de processo. Não vejo essa ligação com a parte de gerência de projetos.
  Mas essa não é a primeira questão do cespe a respeito, então acredito que, para essa banca, devemos considerar que o scrum também é usado para gerenciamento de projetos.

• Qualquer contexto?  Equipes de 500 pessoas também?  Nãooo! 
  

• Na questão: "O Scrum é utilizado, como função primária, para o gerenciamento de projetos de desenvolvimento de software,..."Concordo com o Diego. Acredito que seja ENTENDIMENTO do CESPE. Scrum serve para gerenciar e ser um utilizado com função primária.
  

• usada como XP????? ou com "o" XP?

Questão 215665

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue o seguinte item a respeito de qualidade de software.

Extreme programming (XP) é embasado em requisitos conhecidos, definidos de antemão, que não sofram muitas alterações, devendo ser usado por equipes de pequeno porte, formadas por representantes de todos os stakeholders.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Em desenvolvimento ágil, os requisitos não são estáveis e nem são previamente conhecidos

• Em XP, normalmente os requisitos são definidos no decorrer das entregas das iterações e podem sim sofrer muitas alterações no decorrer do desenvolvimento!

• A filosofia é abraçar as mudanças!
• Definição do XP - "Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” – Kent Beck

• parei de ler em "Extreme programming (XP) é embasado em requisitos conhecidos,"

Questão 215668

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Julgue o seguinte item a respeito de qualidade de software.

Produto da metodologia Scrum, o documento product backlog contém os requisitos definidos a partir da visão do cliente e é utilizado novamente no final do sprint para revisão ou modificações dos requisitos inicialmente definidos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

  Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

• CERTO
  
  O colega de cima disse tudo.
• Para quem tiver 10 Minutos este vídeo da uma revisão excelente sobre o SCRUM [ http://www.youtube.com/watch?v=xa-C0No2Uic ]
• 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.
  
  

  A Reunião de Revisão inclui os seguintes elementos:

  O Product Owner identifica o que foi “Pronto” e o que não foi “Pronto”;
  

  A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
  A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;
  O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data; 

  O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint.
  
  

  O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.
• Caros colegas, na minha opinião a questão está errada no momento que define o Scrum como um metodologia, na minha opinião a "Metodologia é Ágil" e o Scrum e um Framework, exatamente como está descrito no guia oficial.

Questão 218188

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

A metodologia XP prevê valores e princípios básicos para serem considerados durante o desenvolvimento de software. Feedback, coragem e respeito são exemplos de valores; mudanças incrementais, abraçar mudanças e trabalho de qualidade são exemplos de princípios básicos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Os valores são 5:

  CorSim ComFeRe

  1. Corajem
  2. Simplicidade
  3. Comunicação
  4. Feedback
  5. Respeito

  Os princípios são 5 também:

  1. Feedback rápido
  2. Abraçar as Mudanças
  3. Presumir Simplicidade
  4. Mudanças Incrementais
  5. Trabalho de Qualidade

• Resumo de cada VALOR.

  
  Valores do Extreme Programming

  Focada na agilidade de equipes e na qualidade dos projetos e tem como seus valores a simplicidade, o feedback, a comunicação, a coragem, o respeito.

  Comunicação: Segundo Beck “Os problemas nos projetos invariavelmente recaem sobre alguém não falando com alguém sobre algo importante”. Assim, a comunicação enfatiza que devemos sempre estar se comunicando seja entre desenvolvedores ou com os clientes.

  Simplicidade: é tentar fazer o mais simples possível e caso seja necessário faremos algo mais complexo amanhã. Muitas vezes algo é feito de forma completa e posteriormente não é mais sequer usado ou necessário.

  Feedback: é muito presente no SCRUM através das reuniões diárias, retrospectiva, reuniões de revisão do produto, etc. Feedback é o valor primordial dentro do desenvolvimento ágil.

  Coragem:XP diz que devemos ter coragem de sempre colocar o cliente a par do que está acontecendo.

  Respeito: Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores.

Questão 218191

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-se uma abordagem tradicional de controle. O Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• "Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes."
  
  http://pt.wikipedia.org/wiki/Scrum
• "Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-se uma abordagem tradicional de controle."
  
  Essa afirmação estava na Wikipedia, porém não está mais.
  Eu não seria louco de marcar errado por causa disso, porque essas bancas são uma &$#*&$#*, e o que tá pedindo é sobre Scrum.
  
  Esta afirmativa é o mesmo que dizer que os métodos "pesados" não teriam sucesso com desafios empíricos, requisitos imprecisos.
  Pode demorar bem mais, mas uma hora consegue.

• Os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar
  as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades
  estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica,
  ocorrem tarefas a realizar dentro de um padrão de processo (discutido no parágrafo a seguir)
  chamado sprint. O trabalho realizado dentro de um sprint (o número de sprints necessários para
  cada atividade metodológica varia dependendo do tamanho e da complexidade do produto) é
  adaptado ao problema em questão e definido, e muitas vezes modificado em tempo real, pela
  equipe Scrum. [Prerssman]

  A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a
  entrega de incremental prévio; equipes de projeto pequenas e altamente motivadas; métodos informais; artefato de engenharia de software mínimos
  e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que análise e projeto (embora
  essas atividades não sejam desencorajadas); também priorizam a comunicação. [Pressman]
  
  Os princípios do manifesto ágil são:

  1-Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

   

  2 - Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

   

  3 - Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

   

  4 - Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.

   

  5 - Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

   

  6 - O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

   

  7 - Software funcional é a medida primária de progresso.

   

  8 - Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

   

  9 - Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

   

  10 - Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

   

  11 - As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

   

  12 - Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

   

Questão 223999

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

No tocante às características dos métodos de desenvolvimento ágil atualmente utilizados, contém características pertinentes a esses métodos:

• A. controlado e rápido;
• B. burocrático e rápido;
• C. iterações longas e leve;
• D. controlado e burocrático;
• E. sem necessidade de prototipação e leve.

Gabarito: A

Comentários

• a) CONTROLADO E RÁPIDO

  enfatiza o desenvolvimento rápido 

  do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das 

  estimativas. As regras, práticas e valores da XP proporcionam um agradável ambiente 

  de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro 

  valores: comunicação, simplicidade, feedback e coragem

  
  

• a-

  agile é para projetos de equipes pequenas e medias e prioriza agilidade, proximidade ao cliente e sem muita documentação (apesar de alguma dever existir).

Questão 235510

• Banca: MS CONCURSOS
• Órgão: CODENI-RJ
• Ano: 2010
• Provas: MS CONCURSOS - 2010 - CODENI-RJ - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; UML

Trata-se de um modo comum de aplicar a UML, frequentemente com alto retorno no investimento de tempo. Essa definição refere-se a:

• A. Case.
• B. Objetos Syntropy.
• C. Modelagem ágil.
• D. MDA

Gabarito: C

Comentários

• Esse enunciado é praticamente um extrato do livro
  
  Referência:
  Utilizando UML e Padrões

  CRAIG LARMAN
  
  Modelagem ágil: pags 57 - 58
  ...
  Modelagem ágil enfatiza a UML como rascunho, trata-se de um modo comum de aplicar a UM, frequentemente com alto retorno
  no investimento de tempo (que é tipicamente curto).
  ...

Questão 239728

• Banca: CESPE / CEBRASPE
• Órgão: ABIN
• Ano: 2010
• Provas: CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento e Manutenção de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Julgue os itens a seguir, relativos a métodos de desenvolvimento de
software.

No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software. Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog. Isso significa que product backlog e sprint backlog são estruturas similares.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Product backlog e Sprint backlog

  Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Owner pode altera-lo a qualquer momento, desde que os itens alterados não estejam na sprint. O Sprint backlog é uma interpretação do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no Product backlog. O Product backlog e o sprint backlog são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto.

  http://pt.wikipedia.org/wiki/Scrum

• Galera,  
  
  Os itens priorizados a serem desenvolvidos não formam o SELECTED PRODUCT BACKLOG?
• Marcelo, o "Selected Product Backlog", na prática, é o "Sprint Backlog". Eles podem ser considerados sinônimos.
  
  Se você insistir em saber: para ser mais específico, a única diferença é que o "Selected Product Backlog" é a lista de itens selecionados durante a parte 1 da Spring Planning Meeting. Logo que a parte 1 acaba e vamos para a parte 2, o "Selected Product Backlog" passa a ser chamado de "Sprint Backlog". Compreende como, na prática, são a mesma coisa? Essa diferenciação somente acontece se o cara for realmente muito específico.
  
  
  Sobre a questão, o erro está na sentença "desde que os itens alterados não estejam na sprint backlog". Esta restrição não existe. O PO pode alterar o PB a qualquer momento. Se, por coincidência, for um item que tenha ido para o Sprint Backlog, paciência, ele pode alterar/apagar do PB, não faz diferença nenhuma para o Sprint Backlog.
  
  (Se, por exemplo, ele apagar os itens do PB que correspondam a todo o Sprint Backlog da Sprint atual, ainda assim, ela continua, a não ser que o PO decida por cancelar a Sprint, mas aí são outros quinhentos. O que importa é que, ao contrário do que a questão afirma, o PO não tem restrições para alterar o PB, pode fazer o que quiser e quando quiser.)
• Em resposta ao comentário do colega acima, discordo veementemente do que a wikipedia diz(*). Duas afirmações do SCRUM GUIDE confirmam meu comentário e são contra ao que a wikipedia expressou:
  
  Página 13: "During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion." Texto destacado: os itens do backlog podem ser alterados a qualquer momento pelo PO.
  
  Página 14: "The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team." Texto destacado: o Spring Backlog pertence unicamente ao Dev Team.
  
  (*) A galera tem que aprender que qualquer zé roela pode adicionar coisas naquele site, o que não quer dizer que estejam sempre certas. A CESPE e a FCC têm que entender isso também. Ah, agora a wikipedia não diz mais aquilo, pois agora eu mudei o artigo.
• Q: "(...) lista de itens priorizados a serem desenvolvidos para um software. Essa lista é mantida no product owner" 
  R: "Product BACKLOG é uma lista ordenada de tudo que deve ser necessário no produto (...)"
  fonte: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf
• Acredito que o Product Backlog e Sprint Backlog sejam estruturas similares, pois eles contêm as funcionalidades priorizadas, sendo a primeira em nível do sistema e a segunda em nível da sprint.
  Talvez o erro esteja quando foi dito que o Product Backlog seja mantida NO Product Owner
  
  Também errei a questão.

• Essa questão pode ser analisada da seguinte forma:

  - No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software. Se esse item estiver falando do Product Backlog, está correto, pois  o Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto.

  - Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog. Não deve ser um dos erros da questão, mas a lista não é mantida no PO, mas sim pelo PO pois ele é um papel, não um repositório. O Product Backlog pode ser alterado a qualquer momento pelo PO sim, pois ele é o único responsável. Já o Sprint Backlog pode ser modificado, alterado, somente pela Equipe de Desenvolvimento, que no decorrer dos trabalhos, ao perceber que é necessário incluir, ou modificar tarefas deve fazer para garantir o objetivo da Sprint.

  - Isso significa que product backlog e sprint backlog são estruturas similares. Apesar do Sprint Backog e Product Backlog serem um lista de funcionalidades a serem implementadas elas não são estruturas similares. O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, geralmente ordenado por valor, risco, prioridade e necessidade. Já o Sprint Backlog é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano de entrega do incremento do produto e atingir o objetivo da Sprint. Isso é importante esclarecer, pois normalmente acreditamos que o Sprint Backlog é apenas os item selecionados do Product Backlog na primeira parte da reunião de planejamento da Sprint. Na verdade não é, o Sprint Backlog somente é formado depois que a equipe define as estratégias para implementação desses itens, fato que ocorre na segunda parte da reunião de planejamento da Sprint.

  Questão errada.

• Caro Elson Vinícius, excelente comentário! Não tenho o que tirar nem por! Ia escrever um comentário discordando de algumas posições de outros colegas, mas iria repetir simplesmente o que você objetivamente o fez!

  O pior foi o pessoal afirmando que o Sprint backlog pode ser alterado pelo PO. Não pode! É o que você falou, o Sprint Backlog, que é definido completamente somente após a segunda parte da reunião de planejamento, passa a ser propriedade do time. Caso o objetivo do Sprint seja comprometido no meio do Sprint, o PO pode simplesmente cancelar o Sprint. Um novo sprint será criado com uma nova meta do sprint. Porém, alterar os itens do Sprint Baclog nunca. Senão, realmente, vira a casa da Mãe Joana! Veja o que Pressman coloca em seu livro: Engenharia de software - Uma abordagem profissional 7 ed: 

  "Alterações não são introduzidas durante a execução da Sprint. Portanto, o sprint permite que os membros de uma equipe trabalhem em um ambiente de curto prazo, porém estável"

  Bons estudos!

• O erro da questão está em dizer "um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um SOFTWARE"  o Scrum é uma metodologia para projetos e não somente para projeto de Software. Inclusive a metodologia foi criada para fabricação de carros.

• No Scrum, o Product Owner (PO) cria uma lista inicial de necessidades que  precisam ser produzidas para que a visão (escopo) do projeto seja bem-sucedida.  Esta lista de necessidades é chamada de Product Backlog. Uma sprint é um período de tempo entre 2 e 4 semanas que dever ser fixo, dentro do qual o time do projeto irá produzir uma parte do produto definido pelo PO. No planejamento da sprint, o PO deverá definir a meta da sprint e expor para o time os itens mais prioritários do Product Backlog. O time deve estimar os itens em tamanho e definir o que acredita que pode ser implementado dentro da sprint. Essa listagem  é chamada de Selected Product Backlog. Posteriormente, o time deverá colher  mais detalhes do Selected Product Backlog e decompô-los em tarefas, gerando  assim a Sprint Backlog. O PO pode alterar as prioridades dos itens no Product  Backlog e na Sprint Backlog; e as estruturas do Product Backlog e da Sprint  Backlog são distintas, a Sprint Backlog contém mais detalhes relacionados à estratégia de implementação.

  Referência: TECNOLOGIA DA INFORMAÇÃO – Questões comentadas Cespe/UnB / Questão 273

  
  

• Arregooooo!!! como tem gente, e pior BANCAS que seguem o que QUALQUER UM posta no wikipedia como verdade.
  

• acho que o erro é "mantido no PO" mesmo

  
  

  Inicialmente achei que o PO poderia pelo o menos sugerir alteração no Sprint, mas olha só o que diz o scrum guide

  Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. 

  
  

  A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. 

  
  

  
  

  Prova: CESPE - 2012 - ANAC - Analista Administrativo - Área 4
  

  Disciplina: Engenharia de Software | Assuntos: Scrum; 

   Ver texto associado à questão

  O único papel definido pelo Scrum com autoridade para cancelar uma Sprint é o do product owner.

            Certo       Errado

  certo

  Órgão: STF

  Prova: Analista Judiciário - Suporte em Tecnologia da Informação

  Resolvi certo

  Acerca de DevOps e da gestão ágil de projetos com Scrum, julgue os itens subsequentes.

  Uma nova sprint inicia imediatamente após a conclusão da sprint anterior. Uma sprint pode ser cancelada antes do seu time-boxterminar, porém, a autoridade para cancelar é exclusiva do product owner.

             

  certo

  
  

  
  

  Ele pode não ser o responsável por alterar o backlog do Sprint, mas ele pode mandar tirar

  
  

  Ano: 2013

  Banca: CESPE

  Órgão: BACEN

  Prova: Analista - Análise e Desenvolvimento de Sistemas

  Resolvi certo

  Em relação aos fundamentos de SCRUM, ITIL V3 e COBIT, julgue o  item  a seguir. 

  No SCRUM, o producto owner é responsável por alterar o backlog da sprint durante a sprint.

  errada

  
  

• Assertiva ERRADA. 
  
  Mais uma vez, textos e mais textos e nada de alguém apontar o erro. O pessoal precisa urgentemente implementar o método KIS (desculpem o desabafo). 
  
  

  - [CORRETO] No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software.

  - [CORRETO] Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento [...]

  - [ERRADO] [...] desde que os itens alterados não estejam na sprint backlog: os itens podem ser modificados caso se verifique que não cumprirão a meta do sprint. Novos itens também podem ser adicionados/removidos com a finalidade de assegurar que a meta do sprint será cumprida (mas não com a finalidade de adicionar/remover funcionalidades). 

  - [CORRETO] Isso significa que product backlog e sprint backlog são estruturas similares.

  
  
  
  
• Prezados,
  
  Essa questão contém um erro bem claro, mas se o candidato ler a questão rapidamente não consegue identificar o erro.
  O comando da questão afirma que a lista é mantida NO product owner , e não pelo product owner.
  Não obstante, o product backlog e sprint backlog não são estruturas similares, o product backlog contém uma lista de funcionalidades ou características do produto, enquanto o sprint backlog contem uma lista de tarefas alocadas para a equipe de desenvolvimento para completar alguns itens do product backlog
  
  Portanto a questão está errada.
  

• + 1 questão polêmica com vários comentários dispersos e muitas alfinetadas da galera, mas vamos ao resumo dos erros da questão:

   

   

   

  No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software.

   

  Como o outro colega citou, essa metodologia ágil para gestão e planejamento não é exclusiva de software, mas ainda não existe erro na questão já que ela não afirma isso.

   

   

   

  Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog.

   

  Galera, a metodologia é para ser ágil, certo? Imagina se o Proprietário do Produto (Product Owner) não pudesse fazer as alterações que achasse necessárias durante toda a fase do projeto no product backlog? Seria bastante burocrático e nada ágil. Então os primeiros erros são esses.

   

   

   

  Isso significa que product backlog e sprint backlog são estruturas similares.

   

  Há controvérsias, mas vamos combinar que se existisse estruturas similares dentro de uma metodologia ágil precisariamos concordar que elas seriam mescladas entre sí e não separadas, ok? A melhor definição seria que a sprint backlog faz parte (ou é um sub-conjunto) do procut backlog.

• Lendo todos os comentários, só se pode concluir uma coisa: é muito mais fácil marcar ERRADO do que CERTO uma questão do Cespe. kkkk

• During the Sprint:

  • No changes are made that would endanger the Sprint Goal;

  • Quality goals do not decrease; and,

  • Scope may be clarified and re-negotiated between the Product Owner and Development

  Team as more is learned

  Então entende-se que: Mudanças são aceitas desde que não afetem os objetivos da Sprint e o escopo é clareado e renegociado entre o PO e DT, ou seja, mudanças são aceitas, caso contrário teríamos uma sprint engessada.

• De tudo que pode ser alterado. o Product Backlog, é o mais difícil de se alterar.

  É um efeito em cascata sem precedentes

•  product backlog é uma lista de necessidade de funcionalidade.

  sprint backlog é uma lista de tarefas, do time de desenvolvimento.

Questão 239731

• Banca: CESPE / CEBRASPE
• Órgão: ABIN
• Ano: 2010
• Provas: CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento e Manutenção de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue os itens a seguir, relativos a métodos de desenvolvimento de
software.

Na extreme programming, os requisitos são expressos como cenários e implementados diretamente como uma série de tarefas. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.

  Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas.

  • Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.
  • Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.
  • ....

  pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema

• Ao meu ver, essa questão está errada, pois ela afirma "O representante do cliente" e não o próprio cliente, como colocou nosso colega aí de cima. Questão passível de recurso.
• Na verdade o XP diz claramente que se não for possível que o cliente esteja presente fisicamente no ambiente de desenvolvimento do projeto, ele pode escolher um representante que assuma essa função. Por isso tanto faz dizer "o cliente" diretamente ou "o representante do cliente", pois a função é justamente representar o cliente e seus interesses.
  
  Infelizmente não estou com a fonte dessa informação aqui, mas eu lembro de ter lido claramente essa parte em um livro escrito pelos próprios criadores do XP.
• Lembrem-se, uma questão só está errada quando encontramos um erro na questão!
  Infelizmente temos que focar no que quiz dizer o examinador e em que qual o objetivo da questão, e certamente colocando representante ou cliente ele passou a idéia que o time não é composto somente por desenvolvedores!
• Em relação ao "representante do cliente" segue o que Sommerville tem a dizer:
  
  "Cliente on-site: Um representante do usuário final do sistema (o cliente) deve estar disponível em tempo integral para apoiar a equipe de XP."
  
  Fonte: Sommerville, Eng. de Software, 8ª Edição, Página 264.

• Sommerville:
  Em extreme Programming, os requisitos são expressos como cenários (chamados de estórias do usuário), que são implementados diretamente como uma série de tarefas. Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes de escreverem o código. Quando o novo código é integrado ao sistema, todos os testes devem ser executados  com sucesso. Há um curto intervalo entre os releases do sistema.
  
  Pressman 7ª Ed.(pg. 88-90):
  Os testes de aceitação da XP, também denominados testes de cliente, são especificados pelo cliente e mantêm o foco nas características e na funcionalidade do sistema total que são visíveis e que podem ser revistas pelo cliente. Os testes de aceitação são obtidos de histórias de usuários implementadas como parte de uma versão de software.
  

• Quer dizer que o representante do cliente coloca a mão na massa, no desenvolvimento??
  O Cliente paga pelo software e ele trabalha?
  
  
  Eu pago para uma pessoa fazer meu armário e eu corto a madeira e parafuso???

• Errei por falta de atenção.

  A parte da questão onde cita "O representante do cliente faz parte do desenvolvimento" pode trazer duplo sentido.

  Eu, na primeira leitura, entendi que o representante também desenvolve o sistema (coloca a mão na massa ou desenvolve parte do sistema) e fui marcando errado por causa disso, mas o que a banca quis dizer, é que ele participa do desenvolvimento, não necessariamente desenvolve.

  Cai na armadilha.. rsrs.

• Prezados,
  
  Essa questão foi extraída do livro do Sommerville, 8º edição , página 264, vejamos o que o autor fala :
  
  Na extreme programming, todos os requisitos são expressos como cenários ( chamados histórias do usuário ), que são implementados diretamente como uma série de tarefas. O envolvimento do cliente é apoiado pelo engajamento em tempo integral deste na equipe de desenvolvimento. O representante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema. 
  
  Portanto a questão está correta.
  

• Gente, por favor, sejam menos literais nas questões do Cespe.

  Um "representante" do cliente pode ser qualquer um, e não um preposto oficialmente registrado em cartório ou qualquer outra coisa. Um representante do cliente pode ser um estagiário que o gerente colocou lá para ajudar na especificação de uma tabelinha de-para.

  "Fazer parte do desenvolvimento" não significa sentar e programar junto com os programadores. O gerente do projeto também faz parte do desenvolvimento e nem por isso programa, mas ele está lá, ajudando a desenvolver apoiando com o seu conhecimento.

Questão 243058

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Técnico de Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Julgue o próximo item, que trata de métodos ágeis de produção
de software.

Scrum é um processo ágil de produção de software que mantém o foco na entrega da maior parte do produto, no menor tempo possível.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• O SCRUM é um processo de software em forma de framework ( não é uma metodologia ), ágil, iterativo e incremental.

  No SCRUM temos os sprints ( como se fossem ciclos de trabalho), geralmente de até 30 dias, orientados pelo sprint backlog que tem as atividades que a equipe deve realizar para entregar 100% do que está colocado nesse sprint backlog.

  Por sua vez, esse script backlog é criado partindo o product backlog, que nada mais é que os requisitos, ou funcionalidades, propostas pelo cliente para o software.

  As equipes do SCRUM são de geralmente 7 pessoas.

• A questão está bem clara se levarmos em conta que está se referindo ao produto (product backlog) e não ao sistema como um todo.  Uma pegadinha como sempre....
  
• Caberia recurso nessa questão, vejam a definição de Scrum dada pelo Scrum Guide:
  
  "Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90. Este guia descreve como usar o
  Scrum para desenvolver produtos. Scrum não é um processo ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um
  framework dentro do qual você pode empregar diversos processos e técnicas. "
  
  Ou seja, além de não ser para Software especificamente, também não é um processo.
• Gabarito "C", mas eu não entendi =/ Eu errei porque achei que o foco do Scrum não seria na "...entrega da maior parte do produto..." e sim na entrega daquela parte que mais interessa ao product owner. Não necessariamente é a "maior parte", poderia ser a parte mais crítica ou aquela que gerasse mais valor para empresa sei lá. Alguém poderia comentar essa segunda parte... =)
• pensei a mesma coisa da colega Simonne Callegario há, por isso que pra mim está errada pelos treinamentos que tenho visto por ai
• Simone, tive o mesmo pensamento que você e acabei errando a questão.
  Pensei que o foco é mantido nos requisitos para aquela sprint e não no produto como um todo. Achei muito esquisita a questão.
• Temos que abstrair para entender.
  
  No Manifesto Agil temos: 
  Software Funcionando mais importante que documentação completa e detalhada.
  
  A ideia geral é realizar maior quantidade de tarefas possível na sprint, ou seja maior quantidade de itens do Backlog do Produto serão realizados na Sprint, ou seja maior parte possível do produto.
  Menor tempo possível, pois é um método ágil. Tá certo que tem até 1 mês, mas será feito em duas semanas se possível.
  
  De qualquer forma é complicado, pegadinha mesmo. Entretanto não há erro, como vimos é possível. No guia não existe limite INFERIOR de tempo.
  
• Não adianta dizer que é a maior parte do produto, sem dizer que é a maior parte relevante do produto.
  A definição está incompleta e dada a característica do SCRUM, errada.
• Não sei como tem gente que defende o gabarito... não foi pegadinha, está errado. Não existe essa definição de "maior parte do produto". Trabalhei com Scrum anos e anos e, na prática ou na teoria, nunca vi nada sobre foco na entrega da maior parte do produto... o foco está na entrega com um processo ágil, do incremento de software que foi estabelecido para a sprint a partir do backlog... não tem mistério.

• Gostaria de saber de onde tiraram que Scrum é um processo,  sendo que no Scrum guide fica bem claro que Scrum não é um processo e sim um framework.

• Scrum é um processo ágil de produção de software - Não produz somente software. É uma metodologia para projetos.
  

• Scrum não é processo, e nem somente para software, só aí já tem dois erros.
  Se levar em consideração que o foco é entregar a parte mais relevante em menor tempo possível, e não simplesmente a maior parte, são três erros. Gabarito errado, passível de recurso. Se a banca recebeu recursos e não aceitou, é devido ao conhecimento superficial que costumam ter dos assuntos. Basta ler as primeiras páginas do manual para ver que a definição acima é equivocada.

• Scrum Não é processo!

• Achei a questão muito difícil.

  Para mim o Scrum foca em entregar o que é de maior valor para o cliente naquele momento. Isso não necessariamente é a maior parte do todo.
  

• Concordo que a questão usa termos absurdos, já vi algumas da CESPE sobre Scrum sendo cobradas de maneira equivocada, em relação ao Guia Oficial do Scrum.

  http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
  

  Como já citaram acima, logo na página 3 ele informa que "Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas".

• Fiz o curso da Scrum Alliance e me certifiquei como Scrum Master.  Um tópico do curso que ficou marcado é que o Scrum é um framework, e nao um processo.  Esta questao esta errada!

Questão 246922

• Banca: COVEST-COPSET
• Órgão: UFPE
• Ano: 2010
• Provas: COVEST-COPSET - 2010 - UFPE - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Na metodologia de desenvolvimento ágil, a prática da programação em par (pair programming, em inglês) sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas. Como é denominado o papel da pessoa que revê cada linha de código enquanto ela é digitada, verificando erros e pensando sobre o projeto global?

• A. Navegador.
• B. Condutor.
• C. Piloto.
• D. Comandante.
• E. Titular.

Gabarito: A

Comentários

• "A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela."
  
  Fonte: http://improveit.com.br/xp/praticas/programacao_par
  
  Obs: Vale a pena ler esse artigo. Muito bem escrito.
• Outra fonte: http://en.wikipedia.org/wiki/Pair_programming
  
  

  Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, types in code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in. The two programmers switch roles frequently.

  While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

• Para memorizar: é como um Rally
  
  O piloto dirige (executa) , o navegador informa (verifica o código e aponta erros).
  
  
• Banca sem moral. Retira questão da Wikipédia. Assim, de quê adianta comprar livros de autores renomados???

• acertei, mas não entendi.

• Muito boa a explicação !!

• vlz

Questão 252064

• Banca: CESPE / CEBRASPE
• Órgão: STM
• Ano: 2011
• Provas: CESPE - 2011 - STM - Analista Judiciário - Análise de Sistemas - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Julgue os itens seguintes, a respeito de diferentes abordagens
para o processo de desenvolvimento de software.

As diferentes abordagens para o desenvolvimento rápido de software compartilham algumas características fundamentais, tais como: não há especificação detalhada de sistema e, na documentação do projeto, são definidas somente as características mais importantes do sistema; o sistema é desenvolvido em uma série de incrementos, em que os usuários finais e outros stakeholders participam da especificação e avaliação de cada incremento.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Olá, pessoal!
  
  Essa questão foi anulada pela organizadora.
  
  Justificativa da banca:  A redação do item prejudicou o seu julgamento objetivo, induzindo os candidatos ao erro, razão pela qual se opta por sua anulação.
  
  Bons estudos!

Questão 252067

• Banca: CESPE / CEBRASPE
• Órgão: STM
• Ano: 2011
• Provas: CESPE - 2011 - STM - Analista Judiciário - Análise de Sistemas - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Julgue os itens seguintes, a respeito de diferentes abordagens
para o processo de desenvolvimento de software.

O extreme programming (XP), que se inclui entre os métodos ágeis, apresenta, entre outras, as seguintes características: pequenos releases, projeto simples, refactoring, programação em pares e propriedade coletiva.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Práticas do XP:
  Cliente presente
  Jogo do planejamento
  Stand Up meeting
  Programação em par
  Desenvolvimento guiado pelos testes
  Refactoring
  Código coletivo
  Código padronizado
  Design simples
  Metáfora
  Ritmo sustentável
  Integração contínua
  Releases Curtos
  
  Fonte: Extreme Programming Vinicius Magalhaes Teles, Pag 23.

• Certíssimo, todo o texto correto, é a base do XP, são as práticas, a vida do XP.

Questão 260248

• Banca: FCC
• Órgão: TRT - 4ª REGIÃO (RS)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 4ª REGIÃO (RS) - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Para utilizar o processo de estimativa por Story Points em Scrum, inicialmente

• A. o Product Owner deve atribuir valores de negócio para cada um dos itens do Product Backlog.
• B. o Product Backlog deve considerar todos os fatores de Sprint contidos no Backlog Owner.
• C. os Stakeholders devem atribuir os riscos do Product Owner para cada Sprint Planning.
• D. os Stakeholders devem atribuir valores de negócio do Product Owner para cada Sprint.
• E. o Product Planning deve avaliar cada Sprint contida no Backlog transacional e decidir pela prioridade de atividades.

Gabarito: A

Comentários

• Uma das estratégias mais populares é a utilização de Story Points como unidade de medida das atividades. Mas o que são de fatos Story Points ? A resposta clássica é “uma unidade de medida criada para expressar o tamanho geral de uma atividade”, perceba que usamos a palavra TAMANHO, um erro comum é tratar Story Points apenas como medida de complexidade, mas na verdade um Story Point é uma combinação de coisas como:
  Complexidade: Ex. “Essa regra de negócio tem muitos cenários possíveis”
  Esforço: Ex. “Essa alteração é simples, mas precisa ser realizada em muitas telas”
  Risco: Ex. “Precisamos utilizar um framework X, mas ninguem na equipe tem experiência”
  Etc.
  
  Nao pode ser o "Sprint" pois este é uma iteração, logo composta de várias atividades. Se o leitor observar verá que das 5 alternativas 4 citam sprint e somente uma cita o iten do product backlog.
  
  Assim no scrum os itens do Product Backlog seriam a medida relativa do Story Points.
  
  fonte: http://lucianofelix.wordpress.com/2009/06/10/o-que-significam-story-points/ entre outros.
• Compartilhando com a comunidade meus resumos sobre SCRUM :)
  
  
  Quais as principais características do SCRUM?
  Ambientes complexos e requisitos que mudam com frequência ou não são claros
  Equipes pequenas, multidiciplinares e auto-organizadas
  Iteração curtas (sprints) que seguem o cliclo PDCA (ou ciclo de Deming)
  
  SCRUM e XP se complementam pois um foca em gerenciamento e outro em engenharia
  
  Quais as regras da Reunião Diária?
  Duração de no máximo 15 minutos e de pé.
  Responder às perguntas:
  * O que eu fiz ontem?
  * O que farei hoje?
  * Quais impedimentos eu tive?
  
  O que é o Product e Sprint Backlog e o Sprint?
  Descreva as fases do SCRUM
  
  Backlog: tudo que deverá ser produzido
  Sprint: ciclos de 2 a 4 semanas que ao final gera algo de valor para o cliente
  
  
  Fases:
  Planning: Criar backlog, Sprint Planning Meeting
  Sprint: 2-4 semanas, Daily Scrum com stand-up meetings
  Review
  
  Ao final de cada iteração o produto é entregue
  
  Quais os dois papéis definidos no SCRUM?
  Scrum Master: resolver conflitos. Facilitador que cordena o time
  Product Owner: representa o cliente dentro da empresa
  
  
  Qual a função do product owner e do ScrumMaster?
  Product Owner representa o cliente dentro da empresa
  ScrumMaster é um facilitador que coordena o time
• Como o comentário acima ajudou e muito a resolver essa questão..
  
  Para utilizar o processo de estimativa por Story Points em Scrum, inicialmente o Product Owner deve atribuir valores de negócio para cada um dos itens do Product Backlog, priorizando quantitativamente todos os itens. Estes valores podem ser números arbitrários, de 1 a 1000, por exemplo, ou o retorno esperado, em reais, de cada item
  
  Fonte: http://pt.scribd.com/doc/34235581/41/Estendendo-o-processo-de-estimativa-em-Scrum

• Quando respondi a 1ª vez essa questão não sabia o que era Story Points então resolvi simplesmente porque a única opção que podia ser válida era a primeira, uma vez que quem tem ação sobre o backlog (produto e sprint) é o Product Owner. 

  
  

  Stakeholders não tem esse "poder" e as duas outras opções não são um "papel" no Scrum mas sim o backlog do produto e "Product Planning" até onde sei nem existe, mas sim o "Sprint Planning", reunião de planejamento do Sprint.

• Backlog Owner kkkkkkkkkkkk

Questão 266812

• Banca: CESPE / CEBRASPE
• Órgão: PC-ES
• Ano: 2011
• Provas: CESPE - 2011 - PC-ES - Perito Criminal - Específicos; CESPE - 2011 - PC-ES - Perito Criminal Especial - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito de desenvolvimento de sistema, reengenharia e
linguagens de programação, julgue os próximos itens.

O extream programming é um método de desenvolvimento ágil de software, em que o representante do cliente faz parte do desenvolvimento, e os programadores de software desenvolvem testes antes da escrita do código.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Gabarito preliminar: Certo
  Gabarito definitivo: Anulada
  Justificativa: Onde se lê “extream”, deveria ser lido “ extreme”.Dessa forma, opta-se pela anulação do item.
• Poderiam ter corrigido aqui no site. Deixar uma mensagem afirmando que o item foi modificado por um erro na redação do original. Assim não se perderia uma questão.

• Independente do "estream", o representante do cliente faz parte do desenvolvimento?? 

  A questão quis perguntar se o cliente coloca a mão no código fonte ou apenas participa do "desenvolvimento" como nas 'user stories' e na priorização das funcionalidades/requisitos ???

  
  

  Ficou mal elaborada, concorda?

• acredito que não seja isso, como os colegas abaixo explicaram. O sujeito do verbo existir é o pronome relativo antes dele, que retoma uma uma ideia do período anterior: o poder não existe ... o que (há/existe)

  -suj

Questão 267811

• Banca: CESPE / CEBRASPE
• Órgão: TRE-ES
• Ano: 2011
• Provas: CESPE / CEBRASPE - 2011 - TRE-ES - Analista - Análise de Sistemas - Específicos
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software; Processos de Software - Desenvolvimento Ágil; RUP (Rational Unified Process) - Processo Unificado Rational; XP (eXtreme Programming)

A respeito de engenharia de software, julgue os itens subsequentes.

A metodologia Rational Unified Process (RUP) promove o envolvimento do cliente, bem como iterações e testes contínuos, o que torna o processo dependente de outros, apesar de reduzir os seus riscos. Já a metodologia Extreme Programming (XP) proporciona flexibilidade e agilidade, visto que, por meio dela, realiza-se a divisão de tarefas de forma específica.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Questão errada por dizer que a metodologia XP realiza a divisão de tarefas de forma específica, pois isso ocorre com o RUP e não com a XP.
  Na XP a divisão de papéis tem um caráter de “uso-geral”, sem atribuições específicas dentro das atividades.
  
  Fonte: 
  https://docs.google.com/fileview?id=0B3AIwh0y_TYqOGQ3OGVmMzEtNTI0NC00NmRmLTk3MWQtMzY1M2NiZjE3MDlk&hl=en&pli=1
  
   
• Amigos, O RUP em sua versão 7 proporciona flexibilidade e agilidade também pois suas disciplinas podem ser adaptadas à realiadado do negócio, podendo até remover algumas disciplinas. Existem também o RuP For Small Project para pequenos projetos o que o torna mais ágil e menos burocrático. Por esses fatores considerei errada a resposta.
• Conceitos trocados:
  A metodologia Rational Unified Process (RUP) proporciona flexibilidade e agilidade, visto que, por meio dela, realiza-se a divisão de tarefas de forma específica.
  A metodologia Extreme Programming (XP) promove o envolvimento do cliente, bem como iterações e testes contínuos, o que torna o processo dependente de outros, apesar de reduzir os seus riscos.
  
• O RUP não proporciona tanta flexibilidade e muito menos agilidade, metodologias ágeis surgiram como alternativas à metodologias como o RUP...
  
  O comentário do @Yes we can esta certo ao afirmar que o Rup realiza a divisão de tarefas de forma específica e não o XP
• RUP não é uma metodologia. Parei de ler aí... RUP é um framework. 

• em equipes XP há a interdisciplinaridade

Questão 275089

• Banca: COMPERVE
• Órgão: UFRN
• Ano: 2010
• Provas: COMPERVE - 2010 - UFRN - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Sobre a metodologia de desenvolvimento Extreme Programming (XP), é correto afirmar que

• A. uma das práticas de XP é a refatoração (refactoring) do código do sistema, que consiste na reestruturação de classes que implementam as funcionalidades do sistema e tem como principal objetivo facilitar os testes de unidade e aceitação.
• B. a metodologia XP motiva, como uma de suas práticas, a que os testes de unidade de classes do sistema sejam implementados inicialmente e, em seguida, sejam implementadas as funcionalidades presentes em tais classes.
• C. a prática “Programação em Pares” leva ao desenvolvimento conjunto (pares de programadores) de funcionalidades do sistema, possibilitando que um programador se concentre exclusivamente na codificação do sistema, enquanto o outro se dedique à elaboração dos testes automatizados.
• D. a metodologia XP não prevê atualmente nenhuma prática para auxiliar no planejamento e gerenciamento do projeto.

Gabarito: B

Comentários

• Alternativa B.

  b) Trata-se do TDD.

• E porque a alternativa A) está errada?

Questão 280198

• Banca: IADES
• Órgão: CFA
• Ano: 2010
• Provas: IADES - 2010 - CFA - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Assinale a alternativa correta acerca da Programação Extrema (Extreme Programming - XP).

• A. Na programação por pares, os códigos são escritos por dois programadores em cada máquina. Enquanto um dos programadores codifica, o outro é responsável para aspectos como a simplificação do código.
• B. A refatoração tem por objetivo reestruturar um software e modificar as funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode eliminar duplicações e simplificar o projeto.
• C. A estratégia adotada no projeto de software se baseia em contemplar todos os possíveis cenários de evolução empregando-se padrões de projeto. A implementação não inicia até ser concluído todo o projeto.
• D. É recomendável que não se adotem padrões para as práticas de codificação e que não se limite a quantidade de horas trabalhadas por semana.

Gabarito: A

Comentários

• 
  a) Na programação por pares, os códigos são escritos por dois programadores em cada máquina. Enquanto um dos programadores codifica, o outro é responsável para aspectos como a simplificação do código.
  BANCA DEU CORRETA. Mas não ficou claro que são dois programadores usando a mesma máquina.
  b) A refatoração tem por objetivo reestruturar um software e NÃO modificar as funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode eliminar duplicações e simplificar o projeto.
  c) A estratégia adotada no projeto de software se NAO baseia em contemplar todos os possíveis cenários de evolução empregando-se padrões de projeto. A implementação não inicia até antes de ser concluído todo o projeto.
  d) É recomendável que não se adotem padrões para as práticas de codificação e que não se limite a quantidade de horas trabalhadas por semana. (LIMITADO EM 40 HORAS)
• Essa questão era passivel de anulação, pois, a programação em pares, os códigos são escritos por dois programadores, mas sempre utilizando a mesma máquina. Portanto a letra A também está errada.
• Concordo com Emerson Abreu, em Programação em Pares, 2 desenvolvedores usam uma única máquina
• "...os códigos são escritos por dois programadores em cada máquina."
  
  O que há de dúbio aí?
• Olha a INTERPRETAÇÃO aí, pessoal!
  Concordo com o colega Mohamed.
  "Na programação por pares, os códigos são escritos por dois programadores em cada máquina."
  Está mais do que óbvio!
  Bons estudos.

• "Na programação por pares, os códigos são escritos por dois programadores em cada máquina. "
  

  Troquem a ordem: Em cada maquina, os codigos sao escritos por dois programadores. Ou, Os codigos sao escritos por dois programadores por maquina. (Em cada maquina da sala, e nao cada um na sua maquina).

• Pegadinha do MALANDRO.... Affffzzzzzzzzzz....caí bonitinho nessa.

• Deveria ser ÚNICA máquina.

• A frase "Na programação por pares, os códigos são escritos por dois programadores em cada máquina." apresenta duplo sentido. Os dois programadores em uma máquina só ou cada um em sua própria máquina ?

   

• Não existe erro de na A. "Vão duas pessoas em cada carro" é igual a "São escritos por dois programadores em cada máquina ". Acho que foi so confusão na interpretação. 

•  a)Na programação por pares, os códigos são escritos por dois programadores em cada máquina. Enquanto um dos programadores codifica, o outro é responsável para aspectos como a simplificação do código.correto, com ressalvas- dizer que algo é feito por 2 pessoas em cada maquina pode ser entendido como os 2 estarem em maquinas diferentes

   b)A refatoração tem por objetivo reestruturar um software e modificar as funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode eliminar duplicações e simplificar o projeto. - errado - refatorar significa alterar os requisitos nao-funcionais,e  nao funcionais do sistema. em suma, o software continua o mesmo para o usuario.

   c)A estratégia adotada no projeto de software se baseia em contemplar todos os possíveis cenários de evolução empregando-se padrões de projeto. A implementação não inicia até ser concluído todo o projeto.- errado- acabar uma fase p/ iniciar outra é coisa do waterfall model

   d)É recomendável que não se adotem padrões para as práticas de codificação e que não se limite a quantidade de horas trabalhadas por semana.- errado- se necessitar mais tempo, usam-se mais iterações em xp

• a) C

  b) E. A refatoração não muda o comportamento, ou seja, as funcionalidades.

  c) E. Ela é gradativa ao longo do projeto. 

  d) E. Deve-se adotar padrões e limitar horas [40h semanais segundo o XP]. 

Questão 314671

• Banca: FCC
• Órgão: TRT - 1ª REGIÃO (RJ)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 1ª REGIÃO (RJ) - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No SCRUM, o processo de desenvolvimento inicia com uma reunião de planejamento na qual o Product Owner e a equipe decidem, em conjunto, o que deverá ser implementado do Product Backlog. Assim, a equipe planeja seu trabalho, definindo o Sprint Backlog, na

• A. primeira parte da Sprint Planning Meeting.
• B. segunda parte da Sprint Planning Meeting.
• C. terceira parte da Sprint Planning Meeting.
• D. Sprint.
• E. Sprint Burndown.

Gabarito: B

Comentários

• Reunião de Planejamento da Sprint (8 horas) - Participantes: PO, Equipe e SCRUM Master - Esta reunião é primeira reunião, seu objetivo é fazer o planejamento da Sprint. Ela é dividida em duas partes. Na primeira parte o PO definirá prioridade, seleção dos itens do backlog e a meta da Sprint. Na segunda parte a equipe definirá a Sprint Backlog (quais são as tarefas necessárias para cumprir a meta).
• O Scrum tem as seguintes reuniões
  
  Reunião Diária Sempre no mesmo horário e mesmo local para um sprint. 15 minutos Apenas membros do time falam Scrum Master garante o bom andamento da reunião Cada membro do time deve falar: O que tem feito  depois da última reunião O que pretende fazer até a próxima reunião Quais as dificuldades enfrentadas Reunião de Planejamento da Entrega Estabelece um plano de metas Estabele a priorização de itens do Product Backlog Data de entrega e custo provável do produto Definiçao das características gerais e FuncionalidadeReunião de Planejamento do Sprint Quando cada iteração é planejada 8 horas de duração para um sprint de 1 mês, para sprints menores aloca-se 5% desse tempo para essa reunião Consiste em 2 partes Primeira parte: Foco no O QUÊ deve ser feito. Segunda Parte: Foco em COMO serão implementadas as tarefas colocadas na sprint backlog.
  Revisão da Sprint Realizada após cada sprint Dura 4 horas Reunião Informal Apresentação da Funcionalidade Entradas valiosas para a reunião de planejamento do próximo sprint.
  Retrospectiva da Sprint Reunião de 3 horas Discute o processo de desenvolvimento em si. Foco na equipe, o que pode ser feito para melhorar o time.

• A reunião de planejamento da Sprint consiste em duas partes, cada uma sendo uma time-box 

  de metade do tempo de duração da reunião de planejamento da Sprint. As duas partes da 

  reunião de planejamento da Sprint respondem as seguintes questões, respectivamente: 

  
  

    O que será entregue como resultado do incremento da próxima Sprint? 

  
  

    Como o trabalho necessário para entregar o incremento será realizado? 

  
  

  
  

  Parte Um: O que será Pronto nesta Sprint? 

  Nesta parte, a Equipe de Desenvolvimento trabalha para prever as funcionalidades que serão 

  desenvolvidas durante a Sprint. O Product Owner apresenta os itens de Backlog do Produto 

  ordenados para a Equipe de Desenvolvimento e todo o Time Scrum colabora com o 

  entendimento do trabalho da Sprint. 

  
  

  
  

  Parte Dois: Como o trabalho escolhido será Pronto? 

  Tendo selecionado o trabalho da Sprint, a Equipe de Desenvolvimento decide como irá 

  construir essas funcionalidades durante a Sprint e transformá-las em um incremento de 

  produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o 

  plano de entrega destes itens é chamado de Backlog da Sprint. 

  
  

  Fonte: Scrum guide

• Reunião de Planejamento da Sprint (8 horas)

   

  Esta é a primeira reunião, seu objetivo é fazer o planejamento da Sprint. Ela é dividida em duas partes.

   

  1 - Na primeira parte o PO definirá prioridade, seleção dos itens do backlog e a meta da Sprint.

   

  2 - Na segunda parte a EQUIPE definirá a Sprint Backlog (quais são as tarefas necessárias para cumprir a meta).

   

  "Gabarito Letra B" de "bossuet". O cara estudando e pensando naquilo, que vida sofrida kkk.

Questão 315652

• Banca: FCC
• Órgão: TRE-RN
• Ano: 2011
• Provas: FCC - 2011 - TRE-RN - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Considere as seguintes características:

I. Propriedade coletiva.

II. Integração contínua.

III. Metáfora.

Dentre as práticas componentes da Extreme Programming, aplica-se o que consta em

• A. I, apenas.
• B. II, apenas.
• C. I e II, apenas.
• D. II e III, apenas.
• E. I, II e III.

Gabarito: E

Comentários

• Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico. A lixeira, a mesa de trabalho, janelas, pastas e outros itens que estamos habituados a encontrar no computador, simulam elementos do mundo físico e seus respectivos comportamentos. XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua. 
• São práticas do XP:
  
  Posse coletiva (Collective Code Ownership) - E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.
  
  Integração contínua (Continuous Integration) - Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários. .
  
  Metáfora (Metaphor) - O time se comunica sobre o software em termos de uma metáfora, caso consiga encontrar uma boa.
  
  
• Praticas XP
  
  1.Metáfora (Metaphor)
  2.Ritmo Sustentável (40 Hour Week)
  3.Padrões de Codificação (Coding Standards)
  4.Propriedade Coletiva (Collective Ownership)
  5.Programação em pares (Pair Programming)
  6.Refatoração (Refactoring)
  7.Projeto Simples (Simple Design)
  8.Integração Contínua (Continuous Integration)
  9.Desenvolvimento Guiado pelos testes (Test First Design)
  10.  Pequenos Lançamentos (Small Releases)
  11.  Jogo do Planejamento (The Planning Game)
  12.  Cliente Presente (On-site customer)
• Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.
  
  http://engenhariadesoftware.blogspot.com.br/2007/03/programao-extrema-xp.html

•  

  Práticas do XP:

  Collective Code Ownership (Propriedade Coletiva do Código)
  Todos são responsáveis pelo código, não é necessário autorização para
  alterar qualquer arquivo.

   

  Metaphor (Uso de Metáforas no Projeto)
  Como forma de facilitar a comunicação da equipe, o estabelecimento de
  metáforas em pontos chave do projeto permite uma fácil assimilação.

   

  Continuous Integration (Integração Contínua)
  Os diversos módulos devem ser integrados tão logo sejam
  construídos. O código precisa obter sucesso em uma série de
  fatores pré-definidos

Questão 316390

• Banca: FCC
• Órgão: TRE-RN
• Ano: 2011
• Provas: FCC - 2011 - TRE-RN - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial. Este é um dos cinco valores fundamentais do XP (Extreme Programming), denominado

• A. coragem.
• B. respeito.
• C. comunicação.
• D. simplicidade.
• E. feedback.

Gabarito: D

Comentários

• Simplicidade: a solução adotada deve ser sempre a mais simples que alcance os objetivos esperados.
• Princípios Básicos do XP:
  1- Feedback rápido;
  2- Presumir simplicidade;
  3- Mudanças incrementais;
  4- Abraçar mudanças;
  5-Trabalho de qualidade;
  grande abraço
  Marcelo
  
  
  
  

• 5 Valores

  • Comunicação: evitar o gasto de um valioso esforço na tentativa de trocar informações por meios de extensos documentos escritos que freqüentemente são interpretados de forma incorreta ou incompleta;
  • Simplicidade: : garantir que seja desenvolvido apenas o suficiente para atender as necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial;
  • Feedback: fazer com que o cliente conduza o desenvolvimento diariamente a fim de garantir que a equipe direcione toda a sua atenção para aquilo que de fato irá gerar mais valor;
  • Coragem: devido ao XP ser uma metodologia de software que se baseia em diversas premissas que contrariam os processos tradicionais de desenvolvimento de software, é preciso que todos da equipe tenham coragem para adotá-las e acreditar que, utilizando as práticas e valores do XP, serão capazes de fazer com que o software evolua com segurança e agilidade.
  • Respeito

  5 Princípios Básicos

  • Feedback rápido
  • Presumir simplicidade
  • Mudanças incrementais
  • Abraçar mudanças
  • Trabalho de alta qualidade.

  Práticas

  Para aplicar os valores e princípios durante o desenvolvimento de software, 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.

  • Jogo de Planejamento (Planning Game);
  • Pequenas Versões (Small Releases);
  • Metáfora (Metaphor);
  • Projeto Simples (Simple Design);
  • Time Coeso (Whole Team);
  • Ritmo Sustentável (Sustainable Pace);
  • Reuniões em pé (Stand-up Meeting);
  • Posse Coletiva (Collective Ownership);
  • Programação em Pares (Pair Programming)
  • Padrões de Codificação (Coding Standards);
  • Testes Constantes (Unitários e de Aceitação);
  • Refatoração (Refactoring);
  • Integração Contínua (Continuous Integration);
  http://code.google.com/p/extreme-programming-mds/wiki/XP
  

• Solução:

  a) Coragem: capacidade de responder às mudanças de requisito e os problemas à medida que surgem, de forma ágil e audaciosa.

  b) Respeito: o projeto só alcança sucesso quando cada membro reconhece e respeita as contribuições de toda a equipe;

  c) Comunicação: diálogo direto e constante entre a equipe de desenvolvedores e clientes;

  d) Simplicidade: o design do software deve ser o mais simples possível;

  e) Feedback: como as entregas são feitas o mais rapidamente possível, o feedback já deve ocorrer desde o início do projeto;

Questão 319555

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Análise de Requisitos e Qualidade de Software
• Disciplina: Engenharia de Software
• Assuntos: Outros modelos de Processo de Software; Processos de Software; Processos de Software - Desenvolvimento Ágil; RUP (Rational Unified Process) - Processo Unificado Rational; XP (eXtreme Programming)

Um modelo de processo de software, como os modelos cascata, iterativo e rational unified process (RUP), consiste em uma representação abstrata de um processo de software. Abordagens como extreme programming (XP) e Scrum propõem uma forma mais ágil de desenvolver produtos de software. A esse respeito, assinale a opção correta.

• A. O RUP é constituído de quatro fases, nas quais as iterações ocorrem: concepção, elaboração, construção e transição. Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações. Na segunda, são elaborados o modelo de requisitos para o sistema, a descrição da arquitetura e o plano de desenvolvimento de software. No final da fase de construção, que se relaciona ao projeto e programação do sistema, este deve estar em funcionamento e a documentação associada pronta. A fase de transição envolve os testes e a transferência do sistema para o ambiente real.
• B. O modelo cascata representa as fases do processo separadas e encadeadas, tais como especificação de requisitos, projeto de software, implementação, teste, entre outras. A fase seguinte não pode começar antes que a fase anterior tenha terminado. O maior problema do modelo cascata é a divisão inflexível do projeto em estágios distintos, as iterações são onerosas e envolvem retrabalho.
• C. No modelo em espiral, um exemplo de modelo iterativo, cada loop da espiral representa uma fase do processo de software. Nesse modelo, os riscos não são considerados, pois podem impactar o projeto.
• D. XP engloba princípios como trabalhar com os clientes, utilizar metáforas, manter reuniões curtas, programar por pares, simplicidade, fazer releases em incrementos pequenos e integração contínua. O teste, uma importante atividade da engenharia de software, não é abordado na XP, o que constitui a sua maior limitação.
• E. Embasado nas melhores práticas aceitas pelo mercado, o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos, mas sim um framework que indica diversos processos e técnicas. Ele emprega uma abordagem iterativa e incremental, e trabalha com os seguinte conceitos: backlog do produto, uma lista priorizada de tudo que pode ser necessário no produto; product owner (única pessoa responsável pelo gerenciamento do backlog do produto); sprint (iteração); e times, cujo tamanho ideal, indicado pela abordagem, está entre 15 a 20 pessoas, de forma a facilitar a gestão.

Gabarito: B

Comentários

•  a) O RUP é constituído de quatro fases, nas quais as iterações ocorrem: concepção, elaboração, construção e transição. Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações. Na segunda, são elaborados o modelo de requisitos para o sistema, a descrição da arquitetura e o plano de desenvolvimento de software. No final da fase de construção (DURANTE), que se relaciona ao projeto e programação do sistema, este deve estar em funcionamento e a documentação associada pronta. A fase de transição envolve os testes e a transferência do sistema para o ambiente real.

   b) O modelo cascata representa as fases do processo separadas e encadeadas, tais como especificação de requisitos, projeto de software, implementação, teste, entre outras. A fase seguinte não pode começar antes que a fase anterior tenha terminado. O maior problema do modelo cascata é a divisão inflexível do projeto em estágios distintos, as iterações são onerosas e envolvem retrabalho. OK

   c) No modelo em espiral, um exemplo de modelo iterativo, cada loop da espiral representa uma fase do processo de software. Nesse modelo, os riscos não (Grenciado por risco) são considerados, pois podem impactar o projeto.

   d) XP engloba princípios como trabalhar com os clientes, utilizar metáforas, manter reuniões curtas, programar por pares, simplicidade, fazer releases em incrementos pequenos e integração contínua. O teste, uma importante atividade da engenharia de software, não é abordado na XP (É abordando com frequência), o que constitui a sua maior limitação.

   e) Embasado nas melhores práticas aceitas pelo mercado, o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos, mas sim um framework que indica diversos processos e técnicas. Ele emprega uma abordagem iterativa e incremental, e trabalha com os seguinte conceitos: backlog do produto, uma lista priorizada de tudo que pode ser necessário no produto; product owner (única pessoa (PO pode ser um conjunto de pessoas) responsável pelo gerenciamento do backlog do produto); sprint (iteração); e times, cujo tamanho ideal, indicado pela abordagem, está entre 15 a 20 pessoas, de forma a facilitar a gestão.
  
  Gabarito B

• a)  Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações e os requisitos.

  b) ok

  c) modelo em espiral -> riscos

  d) XP engloba testes

• Na primeira fase do RUP, Concepção, são identificados apenas os requisitos mais importantes, delimitando o domínio do sistema. Define-se o escopo do sistema.

  É na fase de Elaboração que se completa todos ou a maior parte dos requisitos.

• Mais uma questão para o caderno de questões que errei.

• Na letra A, o trecho "A fase de transição envolve os testes e a transferência do sistema para o ambiente real."

  Os testes no RUP estão presentes em todas as fases e não só na transição.

• Iterações onerosas? Não existem iterações no modelo em cascata, pois ele é sequencial e linear.

  Questão horrível.

Questão 319672

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Arquitetura de Soluções de Software
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Com relação ao processo Scrum, assinale a opção correta.

• A. A Time Box (caixa de tempo) dentro da qual um conjunto de atividades deve ser executado é chamada de Product Backlog.
• B. Metodologias ágeis de desenvolvimento de software são iterativas e dirigidas por risco, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. Antes de iniciar cada Sprint, os riscos de insucesso na atividade são reavaliados e geridos. O gerente do projeto deve ser capaz de reagir ou agir proativamente ante tais riscos.
• C. Caso um gerente de projetos deseje verificar quais são as funcionalidades a serem implementadas durante um projeto de software, ele deve obtê-las em uma lista conhecida como Sprint Backlog.
• D. Se um gerente de projeto deseja alterar alguns dos requisitos do software durante o desenvolvimento de um Sprint, é recomendável que ele altere o planejamento do Sprint.
• E. Se, durante um Sprint Planning Meeting, um profissional da equipe é destacado como responsável por descrever os itens do Product Backlog, então se diz que este profissional assumiu o papel de Scrum Master.

Gabarito: B

Comentários

• Acertei por eliminação. Mas, usar o termo gerente de projetos, quando estamos falando do SCRUM é uma canalhice da banca.

• Qual erro da c ?

• Concordo com o colega Nobre Nobre que o termo gerente de projetos para Scrum, da forma como foi abordado, não é nada adequado.

   

  Sobre a alternativa C...

  c) Caso um gerente de projetos deseje verificar quais são as funcionalidades a serem implementadas durante um projeto de software, ele deve obtê-las em uma lista conhecida como Sprint (PRODUCT) Backlog.

   

  A Sprint Backlog mostrará apenas as funcionalidades a serem implementadas durante a Sprint, e não durante o projeto.

  Segue abaixo algumas definições que encontrei na web.

   

  Product Backlog: Lista ordenada de tudo o que é necessário para chegar no produto final de um projeto de desenvolvimento de software. Em outras palavras, são “coisas” que devem ser desenvolvidas para chegar no resultado esperado — uma espécie de “lista de desejos”.

  Sprint Backlog: Representa tudo o que deverá ser feito durante a próxima Sprint do seu projeto.

• DENIZE ALTIVA DE OLIVEIRA LOPES

  Product Backlog

• Não sabia que o gerente de projeto participava desse processo, ""os riscos de insucesso na atividade são reavaliados e geridos. O gerente do projeto deve ser capaz de reagir ou agir proativamente ante tais riscos""" Onde está isso nisso no SCRUM GUIDE?

Questão 321154

• Banca: CESPE / CEBRASPE
• Órgão: Correios
• Ano: 2011
• Provas: CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Acerca de engenharia de software, que permite a criação, de maneira econômica e confiável, de software que trabalhe eficientemente em máquinas reais, julgue os próximos itens.

Para que se obtenha sucesso na utilização do Scrum, o cliente deve se tornar parte da equipe de desenvolvimento do software, participando diretamente do processo.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• O Product Owner, como é chamado, representa um dos papéis fundamentais do Scrum. Ele pode ser o próprio cliente ou alguém que tem a visão dele e que ele confia para administrar seu projeto.
  
  http://www.scrumforteamsystem.com/ProcessGuidance/scrum/roles/product-owner
• E quanto ao trecho "o cliente deve se tornar parte da equipe de desenvolvimento do software"? Isto está mesmo correto? Alguém tem alguma referência confiável disso?
• O mais correto seria: o cliente "pode" se tornar parte do time scrum, que é composto pelo Product Owner (Usualmente é o cliente ou alguem q o represente), a equipe de desenvolvimento, e o Scrum Master.
  
  http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20Portuguese%20BR.pdf
• Questão errada na minha opinião.
  Não é isso que o Scrum fala. Então o cliente assume um papel de desenvolvimento? Claro que não.
  O que o Scrum fala é que o PO, que peferencialmente é o cliente, faça parte do TIME do Scrum, e fique próximo à equipe e ao desenvolvimento do trabalho. Ou seja, que ele se comprometa.
  
• Como não foi anulada, criem no ramo especial de aprendizado na memória para CESPE, a definição que o cliente também desenvolve softwares. CESPE tá certinha! Parabéns!

• Pessoal, entendo que o que o CESPE quis colocar na questão é que o SCRUM possui sim um papel que faz parte da equipe de desenvolvimento, que é o PO - Product Owner. Uma equipe SCRUM ou equipe de desenvolvimento SCRUM é composta por um PO, um Scrum Master e o time (equipe de aproximadamente 7 integrantes -2 ou +2). Então, no momento que o PO é parte do time SCRUM e este representa a voz do cliente fazendo com que a equipe entregue valor ao negócio, considera-se que o cliente (ou sua voz, representado pelo PO) faz parte da equipe de desenvolvimento (SCRUM).

  Bons estudos!

• A questão estaria certo se equipe equipe de desenvolvimento foi substituída por "Scrum Team", Equipe Scrum ou algo que desse um sentido mais amplo de equipe que participa do processo do Scrum. A expressão "equipe de desenvolvimento" leva a entender é quem desenvolve o produto, quem coloca a mão na massa, aquele grupo de 5 a 9 pessoas, ou seja, o Time de Desenvolvimento.

• Complicado usar o termo "equipe de desenvolvimento do software" e termos que associar ao time Scrum, em vez de time de desenvolvimento.
  

• Concordo com os amigos, a diferença entre os termos é muito grande para ser considerada correta essa questão.
  De fato, o cliente tem forte integração com a equipe Scrum, podendo até mesmo atuar como Product Owner , porém daí a dizer que o cliente se torna parte da equipe de desenvolvimento do software, participando diretamente do processo, dá a entender CLARAMENTE que o cliente senta ao lado do programador e codifica também... 

  O que me deixa menos nervoso é que a grande maioria é sensata e iria "errar essa questão" de acordo com o entendimento da banca.

• meio forçada essa afirmação

• Quando o examinador cai numa pegadinha manjada de Scrum

Questão 321169

• Banca: CESPE / CEBRASPE
• Órgão: Correios
• Ano: 2011
• Provas: CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Acerca de engenharia de software, que permite a criação, de maneira econômica e confiável, de software que trabalhe eficientemente em máquinas reais, julgue os próximos itens.

Entre as metodologias ágeis para o desenvolvimento de software, o Scrum permite a criação de equipes auto- organizadas e, consequentemente, possibilita o incentivo à comunicação verbal entre todos os membros da equipe. Da mesma forma que as abordagens típicas de Project Management Body of Knowledge ou PRINCE2, o Scrum caracteriza-se por apresentar uma abordagem elementar do gerenciamento de projetos.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• SCRUM: processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.
  PRINCE2: método de gerência de projetos relativo à gestão, controle e organização de um projeto.
  PMBOK: conjunto de práticas em gestão de projectos ou gerência de projetos.
  
  Não se pode comparar os três, SCRUM, PRINCE2 E PMBOK são respectivamente processo, método e conjunto de práticas. Segue uma comparação entre SCRUM E PMBOK:
  
  

  SCRUM	PMBOK
  Not formal	Formal
  Process based	Activity based
  Defined roles	No defined roles
  30 Day cycle	No limit/duration defined
  Many product deliveries	Only one product
  No risk management	Formal risk methodology
  Everyone is ‘committed’	Allows for flexibility
  No formal tools	Formal tools e.g. RACI, WBS etc.
  Focused on product	Activity based but product focused
  Communication via daily meetings	Communication methods (a knowledge area)

• Só complementando o colega acima aee..
  
  
  Um dos grandes Defeitos do Scrum, porém, é a abordagem de "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.
• O Scrum não incentiva a comunicação verbal entre TODOS os membros da equipe: "Galinhas" não falam com "porcos"
  
  Fonte: Scrum Guide
• Eu acredito que o erro da questão esteja na parte: " Da mesma forma que as abordagens típicas de Project Management Body of Knowledge ou PRINCE2, o Scrum caracteriza-se por apresentar uma abordagem elementar do gerenciamento de projetos". Eu não estudei o Prince2, mas pelo menos o Pmbok não consiste em uma abordagem "elementar" de gerenciamento de projetos. O resto, na minha opinião está correto.
• Em [1], temos:
  "Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto."
  Ou seja, a questão seguiu, no início, o mesmo texto citado acima.
  Mais na frente, na referência [1], temos que:
  "Uma das grandes vantagens do Scrum, porém, é que não tem abordagem "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos."
  Discordo totalmente do texto dizendo que os processos do PMBoK são prescritivos. O guia é um MODELO de gerenciamento de projetos e não uma metodologia dessa área. O exemplo de metodologia de gerenciamento de projetos é o PRINCE2.
  Referência:
  [1] http://www.grupos.com.br/blog/sistemas_integrados/
• Acredito que o erro da questão é tentar dizer que os três são elementares.. o PMBOK tem 500 páginas, isso não é nada elementar..o Scrum tbm não parece tão elementar assim, veja página 401 item 9.6.3. Estrutura do modelo Scrum -  do livro "Implementando a governança de TI" do Aragon - 3º edição:
  
  "O Scrum está estruturado em um conjunto de práticas conduzidas por equipes em papéis específicos, organizadas em um fluxo de atividades/eventos de duração fixa totalmente controlado, com artefatos e regras bem definidos, que visa a obtenção de produtos utilizáveis em intervalos curtos de tempo."
   
  
• Pessoal,
  Nesta questão devemos interpretar que:
  não elementar = processos muito prescritivos
  elementar = processos pouco prescritivos
  
  Então, abordagens como PMBOK e PRINCE2, com muitas dezenas de processos, entradas, técnicas e saídas, são muito prescritivas.
  Já o Scrum, é pouco prescritivo, com um pouco mais de uma dúzia de artefatos e controles.
• O erro esta na comparação da abordagem gerencial do SCRUM com a abordagem típica do PMBOK e PRICE2 (o PMBOK britânico) pois as duas ultimas citadas são abordagens completas que visam ser um guia de conhecimento e boas praticas. O SCRUM é uma abordagem essencialmente empírica, com interações e não um planejamento extremamente detalhado. Podemos concluir que o PMBOK e o PRICE2 não são elementares, já o SCRUM sim.

• É uma comparação de bicicleta, com banana e com camiseta. Embora eu possa andar de bicicleta, usando camiseta e comendo banana, tratam-se de coisas distintas.

  
  Scrum é processo de controle e gerenciamento com foco na construção de softwares (tem como pano de fundo o manifesto ágil). Também pode ser conceituado como um framework. https://www.scrum.org/resources/what-is-scrum

  Só um detalhe: a questão já começa errada, dizendo que Scrum é metodologia.
  PMBoK é um corpo de conhecimento (assim como existem outros BoK: BABoK, CBoK, USMBoK etc.) em gerenciamento de projetos (seja qual for o tipo ou a natureza do projeto). É reconhecido por quem o constrói e por quem o adota, de maneira integral ou parcial, como um global standard para gerenciamento de projetos, mas não é método. http://www.pmi.org/pmbok-guide-and-standards/pmbok-guide.aspx

  PRINCE2 é um método de gerenciamento de projetos (também oferece seu guia de boas práticas, mas é conceituado como um método) amplamente aceito e adotado na Inglaterra. Descreve explicitamente o que um projeto deve "fazer" e quando. https://www.prince2.com/what-is-prince2. Apesar de não acreditar na existência prática de receitas de bolo, se tem "alguém" que pode se aproximar de uma, é esse aí (comentários meus).

  [e-mail]

Questão 321376

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

Os métodos ágeis trazem para o desenvolvimento e a entrega de aplicações uma abordagem diferenciada dos métodos tradicionais. Com relação a essa abordagem, assinale a opção correta.

• A. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar.
• B. Os métodos ágeis estão embasados no pressuposto de que uma lista de requisitos já está amadurecida e claramente definida em contrato pelo cliente.
• C. A refabricação (ou refactoring) significa que primeiro deve ser desenvolvido um conjunto mínimo de funcionalidades que agreguem valor ao negócio e, depois, novas funcionalidade devem ser incrementadas ao produto já entregue.
• D. A posse do código deve ser da equipe mais hábil em executar a tarefa.
• E. A tomada de decisões deve ser reservada ao líder do projeto.

Gabarito: A

Comentários

• Um dos princípios da metodologia ágil de desenvolvimento é o envolvimento dos clientes que devem se aprofundar no processo de desenvolvimento, seu papel é fornecer e priorizar novos requisitos do sistema e avaliar as iterações do sistema. O software é desenvolvimento em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento. As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas, os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos. Aceitar as mudanças dos requisitos do sistema e adaptar as alterações, concentrar-se na simplicidade do software que está sendo desenvolvido e do processo desenvolvimento.

Questão 326248

• Banca: FUMARC
• Órgão: CEMIG-TELECOM
• Ano: 2010
• Provas: FUMARC - 2010 - CEMIG-TELECOM - Analista de TI Júnior
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

Sobre modelos de processo de desenvolvimento de software, assinale a alternativa INCORRETA:

• A. O Scrum é um processo de desenvolvimento ágil de software baseado em grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento de sistemas, onde cada sprint é uma iteração que segue um ciclo PDCA (Plan, Do, Check, Act) e entrega um incremento de software pronto.
• B. O design centrado no usuário (UCD) é uma abordagem do processo de desenvolvimento de software baseada no entendimento explícito dos usuários, tarefas, e tem como objetivo principal o casamento entre o modelo conceitual embutido no sistema pelo projetista e o modelo mental do usuário.
• C. Programação extrema (XP – extreme programming) é um processo de desenvolvimento ágil baseado em feedback rápido, e simplicidade; com enfoque explícito em tempo, custo e qualidade no desenvolvimento, que são alcançados através de uma definição rígida do escopo das funcionalidades da aplicação.
• D. O modelo em espiral é um processo de desenvolvimento de software que intercala etapas de projeto e prototipação, combinando conceitos de desenvolvimento top-down e bottom-up, e permitindo, desta forma, análise de riscos e estimativas do progresso do trabalho mais realistas.

Gabarito: C

Comentários

• c) Programação extrema (XP – extreme programming) é um processo de desenvolvimento ágil baseado em feedback rápido, e simplicidade; com enfoque explícito em tempo, custo e qualidade no desenvolvimento, que são alcançados através de uma definição rígida do escopo das funcionalidades da aplicação.
• Extreme Programmning (XP) trabalha com o conceito que os requisitos mudam. Logo não exsite uma definição rígida do escopo, ao contrário ele mudará e o projeto se adaptará as novas exigências.
• A letra A também está errada pois define SCRUM como um processo de desenvolvimento de software, quando na verdade é um processo para gerenciamento de projetos ágil.
• Ravi
  os modelos ageis podem ser encaixados em qualquer metodologia de desenvolvimento.
  da uma olhadinha no livro do Pressman =]
• Apenas complementando o primeiro comentario do colega acima, ja trabalhei com o XP, e a melhor frase que define a flexibilidade do meto e':
  "Mudancas sao sempre bem vindas"
  logo essa ideia ja mata a possibilidade de uma "definicao rigida" como afirma a letra C, tornando a afirmativa falsa e consequentemente a resposta da questao.
  Bons Estudos

• Concordo que a letra C é a correta.

  Mas alguém explica por que a letra D está certa?
  

  Análise de riscos e estimativas do progresso do trabalho mais realistas no modelo em cascata?
  

• Carla,

  Na letra D a questão cita o modelo espiral e não cascata. Acho que vc confundiu.
  

• Talvez a pressuposição equivocada "de uma definição rígida do escopo das funcionalidades da aplicação" faça sentido no ambiente real que tudo muda sempre.
  

• c-

  xp (qualquer processo agile) prevê mudanças nos requisitos, o que contradiz rigidez no escopo.

  (nao sabia que sprints no scrum se baseiam no pdca...)

Questão 331573

• Banca: FGV
• Órgão: FIOCRUZ
• Ano: 2010
• Provas: FGV - 2010 - FIOCRUZ - Tecnologista em Saúde - TI - Sistemas de Informação
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil

Os modelos de processo de Engenharia Web (WebE) adotam a filosofia do desenvolvimento ágil, que enfatiza uma abordagem de desenvolvimento simples que incorpora ciclos rápidos. Em conseqüência, o modelo de processo WebE está fixado em três pontos fundamentais, são eles:

• A. entrega após a conclusão total da modelagem, modificações somente após a implementação e cronogramas longos.
• B. entrega após a conclusão total da modelagem, modificações contínuas e cronogramas curtos.
• C. entrega incremental, modificações somente após a implementação e cronogramas longos.
• D. entrega incremental, modificações contínuas e cronogramas curtos.
• E. entrega incremental, modificações contínuas e cronogramas longos.

Gabarito: D

Comentários

• Pressman Maldito!
  
  Modelo de processo WebE (ou WebApp), segundo Pressman, 2006, está fixado em três pontos:
  • Entrega incremental
  • Alterações frequêntes
  • Tempo curto de desenvolvimento.
  
  
  
  fonte: http://pt.scribd.com/doc/44945336/Default-Title
• Pág. 383 Pressman 6a edição:
  
  Antes de definirmos um arcabouç o de process o para WebE devemos reconhece r que:
  1. WebApps com freqüência são entregues incrementalmente. Isto é, as atividades de arcabou -ço vão ocorrer repetidamente à medida que cada increment o é submetid o à engenhari a e entregue.
  2. Modificações ocorrerão freqüentemente. Essa s modificações pode m ocorre r com o resultado da avaliação de um increment o entregue ou com o conseqüênci a de condiçõe s de negóci o mutáveis.
  3. Cronogramas são curtos. Iss o alivia a criaçã o e revisão de volumos a documentaçã o de enge -nharia, ma s nã o despreza a simples realidade de que análise, projeto e teste crítico devem se r registrados de algum modo . 

Questão 334612

• Banca: FCC
• Órgão: TRT - 23ª REGIÃO (MT)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Técnico Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

No desenvolvimento de software em Extreme Programming (XP) há uma confiança muito grande na sinergia entre as práticas, já que os pontos fracos de cada uma são superados pelos pontos fortes de outras. Dentre elas, aquela em que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a equipe conheça todas as partes do sistema, é chamada de

• A. Whole Team (Time Coeso).
• B. Sustainable Pace (Ritmo Sustentável).
• C. Pair Programming (Programação em Pares).
• D. Collective Ownership (Posse Coletiva).
• E. Coding Standards (Padrões de Codificação).

Gabarito: D

Comentários

• Todas as opções são práticas do XP. Mas a que prescreve que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a equipe conheça todas as partes do sistema, é chamada de:
  Collective Ownership (Posse Coletiva).
• O QC está bugado! rsrs
  Esse meu comentário com certeza não foi feito nesta questão.
• Extraído da renomada fonte consagrada e onipresente utilizada pela FCC: wikipedia.
  
  Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.
  
  Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
  
  Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
  
  Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
• Só porque a questão está igual a da wiki não necessariamente a FCC copiou de lá. Pode ser que quem publicou na Wiki tirou da mesma fonte que a da FCC.
  
  Bons estudos e que o Monstro de Espaguete Voador esteja com vós. Rámen!

• LETRA "D" SEM DÚVIDA. TÁ NO LIVRO DO KENT BECK.

Questão 334615

• Banca: FCC
• Órgão: TRT - 23ª REGIÃO (MT)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Técnico Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil

FDD (Feature Driven Development) é uma metodologia muito objetiva, possuindo apenas duas fases:

• A. Concepção & Planejamento e Construção.
• B. Decomposição Funcional e Construção.
• C. Análise dos Requisitos e Desenvolvimento.
• D. Planejamento Incremental e Desenvolvimento por Funcionalidade.
• E. Planejamento por Funcionalidade e Construção por Funcionalidade.

Gabarito: A

Comentários

• Há divergências conceituais quanto a essa questão.
  O FDD é um processo de software que utiliza métodos ágeis.
  Possui 5 processos/fases:
  1. Develop Overall Model
      
  2. Build Features List
      
  3. Plan by Feature
      
  4. Design by Feature
      
  5. Build by Feature
  
  Esses processos/fases podem ser agrupados em Concepção&Planejamento e Construção.
  
• 
  Na verdade:
  

  
  A FDD é uma metodologia muito objetiva. Possui apenas duas fases:

  • Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas)
  • Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas)

  
  E possui cinco processos que são bem definidos e integrados:

  1. DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
  2. CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
  3. PPF (Planejar por Funcionalidade): Planejamento Incremental
  4. DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  5. CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos
  Abraço a todos...
  
• A resposta para esta questão está neste link:
  
  http://www.heptagon.com.br/fdd-estrutura
• 
  

• Feature-Driven Development (FDD)

  
  

  "É um método ágil que enfatiza o uso de orientação a objetos. Possui apenas duas fases:
  

  
  

  1 - Concepção e Planejamento;
  

  2 - Construção.
  

  
  

  A fase de Concepção e Planejamento possui três disciplinas:
  

  
  

  * Desenvolver Modelo Abrangente;
  

  * Construir Lista de Funcionalidades; e 
  

  * Planejar por funcionalidade.
  

  
  

  A fase de Construção possui duas disciplinas:
  

  
  

  * Detalhar por Funcionalidade;
  

  * Construir por Funcionalidade.

  
  

  Fonte: Prova Cobra Tecnologia 2014 - Quadrix
  

  Naquela oportunidade errei, não erro nunca mais.
  

Questão 337732

• Banca: CS-UFG
• Órgão: UFG
• Ano: 2010
• Provas: UFG - 2010 - UFG - Analista de TI - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

A abordagem iterativa de desenvolvimento de software tem se popularizado como técnica-padrão de desenvolvimento de sistemas pequenos e médios, especialmente no mundo dos negócios. Scrum e eXtreme Programming são métodos ágeis e iterativos de desenvolvimento de software que compartilham a característica de

• A. desenvolvimento e entrega incrementais de software.
• B. ênfase em processos em vez de pessoas.
• C. envolvimento restrito do cliente no processo de desenvolvimento.
• D. dificuldade de atender a contínuas mudanças nos requisitos.

Gabarito: A

Comentários

• a) desenvolvimento e entrega incrementais de software. (correto)  b) ênfase em processos em vez de pessoas. Ênfase em pessoas e interações MAIS QUE processos e ferramentas (XP)  c) envolvimento restrito do cliente no processo de desenvolvimento. Envolvimento AMPLO e contínuo do cliente. Parceria total com o cliente  d) dificuldade de atender a contínuas mudanças nos requisitos. Métodos apropriados para requisitos e prioridades INSTÁVEIS

• Manifesto do Desenvolvimento ágil de Software

  Indivíduos e interações são mais importantes que os processos e ferramentas

  Software funcionando é mais importante do que documentação completa e detalhada

  Colaboração com o cliente é mais importante do que negociação de contratos

                 Adaptação de mudanças é mais importante do que seguir o plano inicial

  
  

  http://dropsti.blogspot.com/2014/05/modelo-cascata-tambem-chamado-de.html
  

Questão 362887

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Na verdade são cinco valores:
  Comunicação
  Simplicidade
  Feedback
  Coragem
  Respeito [faltou]
  
  a questão dá margem a um entendimento de que faltou alguma coisa.
  Contudo, os valores ditos FUNDAMENTAIS são apenas os quatro primeiros
• Faltou recurso aí na Bahia... fala sériow
• Apenas acrescentado aos comentários acima...
  Na bibliografia utilizada pela banca, respeito não é um valor fundamental ao XP, mas de apoio aos demais valores. Observem as outras questões sobre o assunto e vejam por si mesmos.
• Galera, uma dica para o XP é não confundir princípios com valores!
  
  A questão está certa por que cobrou os valores.
  
  Os cinco valores fundamentais: comunicação, simplicidade, feedback, coragem e respeito.
  Princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
• só uma observação. O valor "respeito" foi adicionado na segunda edição do livro "Extreme Programming Explained" do Kent Beck.
  Talvez a questão tenha se baseado na primeira versão do livro.

•  Os valores do XP: ComFé, CorResSim

  Comunicação

  Feedback

  Coragem

  Respeito

  Simplicidade

  Os princípios do XP são 5 também:

  Feedback rápido

  Abraçar as Mudanças

  Presumir Simplicidade

  Mudanças Incrementais

  Trabalho de Qualidade

• Sem duplo sentido, faltou respeito respeito nesta questão ¬¬

• Na minha opinião o respeito também é fundamental! Esta questão deveria ser anulada! o XP possui 5 cinco valores e não 4 quatro!

• XP possui 5 cinco valores e não 4 quatro!

• Pessoal, essa questão é de 2010, nessa época só existiam 4 valores.

  Em uma outra edição posterior a data dessa prova que entrou "respeito" como valor fundamental da XP também.

Questão 362890

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

Em XP, a prática denominada programação em pares (pair programming) é realizada por um desenvolvedor em dois computadores, com o objetivo de aumentar a produtividade.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Programação em pares ( dois desenvolvedores em um computador )
  
  Questão Errada
• Se as questões fossem sempre assim! :)
• Edluise Costa O erro não está em dois programadores em um computador! É desta forma mesmo que funciona a programação em par! Imagine na aviação um avião ele precisa de um co-piloto! O erro está em com o objetivo de aumentar a produtividade. O objetivo da programação em par não é: Compartilhamento do conhecimento, Correção de falhas, Manutenibilidade, Confiança, Amadurecimento e outros.

• Fiquei com vergonha alheia de quem fez essa questão...

Questão 362893

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

A respeito das metodologias eXtreme programming (XP) e Scrum,
julgue os itens a seguir.

A metodologia Scrum é facilitada por um scrum master, que atua como um mediador entre a equipe e qualquer influência desestabilizadora, além de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando e mantendo o foco na meta da sprint.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Sobre Scrum Master:
  Scrum Master desempenha uma liderança gerenciando os interesses do Product Owner (PO) junto ao Time.
  As principais funções do Scrum Master são:
  
  1. 1 - Promove a criatividade e o conhecimento no Time.
  2. 2 - Estimula a comunicação entre todos os envolvidos.
  3. 3 - Proteje o time de interferências externas.
  4. 4 - Remove impedimentos.
  5. 5 - Garante que o processo está sendo respeitado.
  6. 6 - Gerencias as reuniões
  7. 7 - Integra Cliente e Desenvolvimento.
  O que é Product Owner (PO): 
  Pode ser um financiador ou um importante interessado no projeto, suas principais responsabilidades são:
  1. 1 - Definir as funcionalidades do produto.
  2. 2 - Concentra as informações vindas dos usuários.
  3. 3 - Prioriza o ProductBacklog.
  4. 4 - Pode alterar as prioridades dentro do sprint.
  5. 5 - Aceita ou rejeita os resultados dos trabalhos.
• ???"6 - Gerencias as reuniões"????
  Não sei que fonte o amigo acima utilizou, porém no guia Scrum temos:
  
  Reunião Diária
  
  "O Scrum Master assegura que a Equipe de Desenvolvimento tenha a reunião, mas a Equipe de Desenvolvimento é responsável por conduzir a Reunião Diária."
• Scrum não é uma metodologia, é um framework.

• Está CORRETA a afirmativa da questão.

• Ridículo não ter sido anulada... Scrum não é uma metodologia!

• Bancas como a CESPE, fazem muito disso: elas consideram tudo como Metodologia... fazem isso com o ITIL também, mesmo sendo um guia de boas práticas... é como se fosse sinônimo para eles:

  guia de processos = framework = metodologia

• Se para o CESPE => guia de processos = framework = metodologia... Segue o fluxo... e ganhe a questão...

Questão 377575

• Banca: FCC
• Órgão: TRE-AP
• Ano: 2011
• Provas: FCC - 2011 - TRE-AP - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil

As práticas se baseiam em técnicas ágeis, tais como, Test Driven Development (TDD), Agile Model Driven Development (AMDD) e Database Refactoring, concentrando as atividades de análise, desenho e requisitos unicamente na disciplina Modelagem. Trata-se de

• A. AUP.
• B. SCRUM.
• C. XP.
• D. AUP e SCRUM.
• E. XP e SCRUM.

Gabarito: A

Comentários

• AUP ( acronomo de Agile Unified Process):  é uma versão simplificada do RUP. Ele descreve uma abordegem simples, de fácil compreensão para o desenvolvimento de software, usando técnicas ágeis e conceitos do RUP. Aplica técnicas ágeis que incluem:
  1. Test Driven Development (TDD)
  2. Agil Model Driven Development (AMDD)
  3. Gerenciamento de mudanças ageis
  4. Refatoramento de banco de dados para melhorar a sua produtividade.

• O AUP (Agile Unified Process) adota uma filosofia serial para o que amplo e iterativa para o que é particular. Assim, ele adota as fases tradicionais do UP - Unified Process: Concepção, Elaboração, Construção e Transição. Entretanto, dentro de cada atividade (disciplina), a equipe itera ou se repete para alcançar a agilidade e para entregar incrementos de software significativos para os usuários finais tão rapidamente quanto possível. Cara iteração AUP dirige-se para as seguintes atividades/disciplinas:

  1. Modelagem - Representações UML do universo do negócio e do problema são criadas;

  2. Implementação - Os modelos são traduzidos para o código-fonte;

  3. Teste - Desenvolvimento baseado em TDD - Test Driven Development;

  4. Aplicação - Entrega de um incremento de software e a aquisição de feedback dos usuário finais;

  5. Configuração e gerenciamento de projeto - Gerenciamento das alterações, riscos e controle de qualquer artefato persistente. Enquanto o Gerenciamento do projeto traciona e controla o processo de uma equipe e coordena suas atividades;

  Assim, somente o único processo de desenvolvimento de software que concentra as atividades análise, desenho e requisitos na Modelagem é o AUP. Na verdade, os demais SCRUM e XP nem possuem a definição formal dessa disciplina Modelagem.

  Espero ter ajudado! Bons estudos!

• A única alternativa que apresenta as fases citadas é a da letra A. Que é o RUP Ágil

Questão 450004

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Sistemas - Especialista
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos chamados:

• A. Product Backlog.
• B. Sprint Backlog.
• C. Scrum Master.
• D. Daily Scrum.
• E. Sprints.

Gabarito: E

Comentários

• Product Backlog. - É um conjunto de requisitos, priorizados pelo product ower, que tipicamente vem do cliente
  
  Sprint Backlog - é uma interpretação do Product backlog e contém tarefas concretas que serão realizadas durante o proximo sprint(iteração curta) para implementar alguns dos itens principais do product backlog.
  
  Scrum Master - é a pessoa que mantem os processos( normalmente no lugar do gerente de projetos), tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint.
  
  Daily Scrum - Cada dia durante o sprint, uma reunião de status do projeto ocorre. Isso é chamado de "scrum diário", ". Esta reunião tem diretrizes específicas:
  

  Todos são bem-vindos, mas apenas "poucos" podem falar.
  O encontro é timebox e dura de 15 a 30 minutos.
  A reunião deve acontecer no mesmo local e mesma hora todos os dias
  Durante a reunião, cada membro da equipe responde a três perguntas:
  - O que você tem feito desde ontem?
  - O que você está planejando fazer hoje?
  - Você tem algum problema impedindo você de realizar seu objetivo?print

  Sprint - é uma  interação curta onde são entregues um conjunto fixo de itens do backlog
• Alternativa Correta
  
  E) Sprints

Questão 450007

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Sistemas - Especialista
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

Acerca dos processos XP e Scrum avalie as afirmativas a seguir:
I. XP é uma metodologia ágil para equipes de tamanho pequeno ou médio desenvolverem software com requisitos vagos ou que mudem rapidamente. Seus valores são comunicação, simplicidade, feedback e coragem.
II. O Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu em 1995 após a formalização de sua definição, feita por Ken Schwaber.
III. No XP os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade.
Assinale:

• A. se somente a afirmativa I estiver correta.
• B. se somente as afirmativas I e II estiverem corretas.
• C. se somente as afirmativas I e III estiverem corretas.
• D. se somente as afirmativas II e III estiverem corretas.
• E. se todas as afirmativas estiverem corretas.

Gabarito: B

Comentários

• O Product Backlog é uma gama de funcionalidades, definidas, no começo do projeto e é organizada por prioridade de entrega pelo Product Owner, com o suporte do scrumMaster. As funcionalidades devem ser incluídas pela lista e devem ser  visíveis ao cliente, assim como os requisitos-não funcionais para a implementação do projeto. As tarefas de maior prioridade e complexidade são divididas em subtarefas para que sejam estimadas e testadas.
  
  Ao longo do desenvolvimento do projeto, o Product Backlog pode receber novos itens, ter itens removidos ou repriorizados, de acordo com as necessidades do cliente ou visando um melhor ROI. Há a possibilidade, ainda, de inclusão de alguns requisitos técnicos que, muitas vezes, não são visíveis ao cliente.
• Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.
• Faltou respeito com um dos valores do XP.
• product backlog é um termo do SCRUM, não do XP.
• I - XP é uma metodologia ágil para equipes de tamanho pequeno ou médio desenvolverem software com requisitos vagos ou que mudem rapidamente. Seus valores são comunicação, simplicidade, feedback e coragem. (Correto. O quinto valor Respeito foi introduzido na segunda versão do livro Extremme Programming Explained - Embrace Change do Kent Beck.)
  II - O Scrum foi criado para gerenciamento de projetos de fabricação de automóveis e produtos de consumo. Sua popularização no desenvolvimento de software ocorreu em 1995 após a formalização de sua definição, feita por Ken Schwaber. (Correto)
  III - No XP os requisitos do projeto são organizados em uma lista de tarefas, chamada de product backlog, em ordem decrescente de prioridade. (Errado. No Scrum é que possui essa divisão do product backlog e a prioridade dos requisitos são definidos pelo Product Owner).
• Apenas complementando o comentário de um colega acima, RESPEITO é um valor introduzido pelo Kent Beck somente na 2a. Edição do livro "Extreme Programming Explained", livro que, em sua primeira edição, apresentou o XP.
  
  A questão está de acordo com a primeira versão do livro citado, na qual o autor elenca apenas quatro valores, como dito: comunicação, simplicidade, feedback e coragem.
• Porque eu deveria saber a história do SCRUM?
• Sabemos que XP tem 5 valores, além dos citados também temos "Respeito"
  
  Entretanto para analisar na hora de marcar, basta observar.
  "Seus valores são comunicação, simplicidade, feedback e coragem." -> 
  -> -> ->
  "comunicação, simplicidade, feedback e coragem são seus valores "
  
  Se a segunda afirmativa parecer mais correto, então a primeira está correta. Pois não foi informado "APENAS", "SOMENTE"
• Falta de criatividade... isso sim...

• Se você não sabe porque uma coisa foi criada, bem possível que ainda não tenha entendido completamente pra que ela serve, ou tudo que ela pode oferecer.

• Novamente, Porque eu deveria saber a história do SCRUM?

  Resposta: pra nada, concurso é busca em largura, não em profundidade! Não tem só SCRUM na sua prova, é mais uma palavra no mar de palavras do seu edital...o erro é da banca em cobrar esse tipo de coisa...

Questão 456184

• Banca: FCC
• Órgão: TRT - 23ª REGIÃO (MT)
• Ano: 2011
• Provas: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

NÃO se aplica à disciplina de desenvolvimento de software extreme programming (XP):

• A. Usa notações próprias para construir os diversos produtos de trabalho do projeto.
• B. Encoraja a refabricação para modificar um sofware sem alterar o comportamento externo do código.
• C. Recomenda que dois programadores trabalhem juntos no mesmo computador para escrever um código.
• D. Baseada em valores de simplicidade, comunicação, feedback e coragem.
• E. Adota como um elemento-chave a criação de testes unitários antes da codificação começar.

Gabarito: A

Comentários

• talvez o termo "refabricação" possa dar margem a uma avaliação equivocada da alternativa B.
  O termo realmente não foi muito feliz...
  Deve ser entendido como "refatoramento", o "refactoring", que é sim uma das práticas do XP.
• Domingos mas é essa a tradução que se encontra na última versão do Pressman. 
• A letra B esta correta, no Pressman fala exatamente isso.
  A letra A está incorreta, no Pressman, 6ed, diz:
  
  "Como o projeto XP praticamente não usa notação e produz
  poucos, ou nenhum, produto de trabalho que não sejam
  os cartões CRC e as soulões de ponta o projeto é visto como um artefato
  provisório que pode e deve ser (....)"
• a) Usa notações próprias para construir os diversos produtos de trabalho do projeto. - Tenta confundir com SCRUM que tem sprints, backlogs...
  b) Encoraja a refabricação para modificar um sofware sem alterar o comportamento externo do código. - Definição exata.
  c) Recomenda que dois programadores trabalhem juntos no mesmo computador para escrever um código. - Pair Programming
  d) Baseada em valores de simplicidade, comunicação, feedback e coragem. - Também Respeito
  e) Adota como um elemento-chave a criação de testes unitários antes da codificação começar. - desenvolvimento orientado a testes.
• Também fui de B, só uma dúvida, o que essa alternativa quer dizer com "comportamento externo do código." ?
  
  []´s
• Sem alterar o comportamento externo significa que o desenvolvedor pode alterar as linhas de códigos entre outras coisas mas para o usuário comum, o programa vai estar a mesma coisa. A letra B está correta, mas a questão quer a errada.
• a) é falso pessoal, o processo XP, em seu projeto, não usa praticamente nenhuma notação e produz poucos, se algum, artefatos, além dos cartões CRC e soluções pontuais.
  b) CORRETO. refabricação faz parte do XP, este também é um método de otimizaçaõ de projetos, é o processo de alteração de um sistema de software de tal forma que não se altere o comportamento externo do código, mas se aprimore a estrutura interna. É uma forma disciplinada de organizar o código [e modificar/simplificar o projeto interno] que minimiza as chances de introdução de bugs. Em resumo, ao se refabricar, se está aperfeiçoando o projeto de codificaçaõ e depois de este ter sido feito.
  
  
  
  
  não vou explicar as demais porque os colegas abaixo já explicaram direitinho.
  bons estudos.

• a)Usa notações próprias para construir os diversos produtos de trabalho do projeto.

  As notações são vistas na parte de modelagem de software, podendo usar BPMN, EPC, ARIS e/ou UML. 

Questão 459256

• Banca: FCC
• Órgão: INFRAERO
• Ano: 2011
• Provas: FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Para gerenciar uma equipe de desenvolvimento de software, que utiliza a metodologia ágil XP,

• A. não se permite a presença constante do cliente durante o desenvolvimento do projeto para não haver interferência na interpretação dos requisitos.
• B. é necessário adotar medidas para que os desenvolvedores trabalhem mais de 40 horas semanais fazendo horas extras, para agilizar o desenvolvimento e concluir o projeto em menos tempo.
• C. a programação deve ser feita em dupla, onde dois programadores trabalham em um único computador. Um desenvolvedor implementa o código, enquanto outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos.
• D. um nível médio de complexidade de programação deve ser definido de modo que satisfaça os requisitos atuais e futuros.
• E. uma entrega de versões do software a cada seis meses deve ser cumprida, contemplando o maior número possível de requisitos.

Gabarito: C

Comentários

•  a) não se permite a presença constante do cliente durante o desenvolvimento do projeto para não haver interferência na interpretação dos requisitos.
  
   b) é necessário adotar medidas para que os desenvolvedores trabalhem mais de 40 horas semanais fazendo horas extras, para agilizar o desenvolvimento e concluir o projeto em menos tempo.
  
  d) um nível médio de complexidade de programação deve ser definido de modo que satisfaça os requisitos atuais e futuros.
  
  e) uma entrega de versões do software a cada seis meses deve ser cumprida, contemplando o maior número possível de requisitos.
• É o que se chama de Programação em Pares, umas das práticas adotadas pelo XP que consiste em programação em par/dupla num único computador, Geralmente um iniciante (codificando) + um instrutor. O programa é sempre revisto, evitando defeitos.
  Abraço e bons estudos.
  Marcelo
  
• d) um nível médio de complexidade de programação deve ser definido de modo que satisfaça os requisitos atuais e futuros.
  
  O erro da opção (D) é apenas quando se refere aos requisitos futuros? O nível médio de complexidade de programação está correto? Não devria ser simples (não confundir com fácil)?
• a) Na verdade é desejável a presença constante do cliente durante o desenvolvimento do projeto. Sempre auxiliando na interpretação dos requisitos.
  b) Na verdade é necessário adotar medidas para que os desenvolvedores trabalhem no máximo 40 horas semanais. Para manter um ritmo sustentável
  c) CERTO
  d) Na verdade deve-se adotar soluções simples de programação, de modo que satisfaça os requisitos atuais e futuros. obs. quando menciona-se requisitos futuros, podemos também entender como sendo futuras refatorações nessa solução aplicada hoje. Soluções simples auxiliará futuras refatorações.
  e) Na verdade uma entrega de versões do software deve ter duração de poucas semanas (incrementos, releases).

• Nunca trabalhei com XP. Imagino que deve ser muito chato ser o programador "instrutor", que fica observando o que o colega está fazendo....
  

• XP - Programação em pares!!!!! 

• c-

  Programação a 2, um faz e o outro observa. xp nao gosta de documentação, devido a sua natureza de agile, a qual tambem prioriza proximidade com cliente e prazos curtos e entregas como milestones destes prazos

Questão 471133

• Banca: FCC
• Órgão: INFRAERO
• Ano: 2011
• Provas: FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Em relação às regras do Scrum, é INCORRETO afirmar:

• A. O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não superior a 10 pessoas.
• B. Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint, baseando num novo Sprint Backlog.
• C. As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e não devem durar mais que 30 minutos.
• D. Toda conversação restringe as respostas dos participantes às três perguntas do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu trabalho? O que planeja desenvolver até a próxima reunião?
• E. Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do trabalho.

Gabarito: A

Comentários

• O sprint leva entre 2 a 4 semanas.
• Para mim a letra d ta errada tb, a conversa com o Scrum Master não necessariamente se limitará as 3 perguntas.
• Isto está dúbio, pois a letra C diz que a reunião nao deve durar mais que 30 minutos, o que engloba 20, 21, 22... 29 minutos..
  
  Já o "manual" do SCRUM diz:
  
  "The meeting is timeboxed to 15 minutes"
  
  Ou seja.. 16...17.. 20..21,21 minutos tão fora do intervalo.
  
  E o ideal é que o periodo maximo seja de 30 dias ao invés de 40, então a logica da letra A é a mesma da letra C, ou seja aceita 31, 32, 33 dias, na minha opnião estão erradas tanto a letra A quanto a C..
• Concordo com o Murilo. A letra C também não está correta.
  
  De acordo com o guia do Scrum:
  
  
  Scrum Diário
  A Reunião do Scrum Diário é um evento com 15 minutos fixos para a Equipe de Desenvolvimento sincronizar as atividades e criar um plano para as próximas 24 horas. Isso se faz inspecionando o trabalho até o último Scrum Diário e prevendo o trabalho que pode ser Pronto antes do próximo.
  O Scrum diário se dá no mesmo horário e lugar todo o dia para reduzir a complexidade. Durante o encontro, cada membro da Equipe de Desenvolvimento esclarece:
   
  * O que tem conseguido realizar desde o último encontro?
  * O que vai ser Pronto até o próximo encontro?
  * Quais são os obstáculos que estão no seu caminho?
  
   Fonte: Guia do Scrum.
• Para mim essa questão cabe recurso,pois segundo o Scrum a letra c)  dever ser de 15 minutos
• Questão maliciosa, mas muito comum em provas de algumas bancas. É importante aprender a lidar com elas.
  c)As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e não devem durar mais que 30 minutos. O fato do avaliador dizer que as reuniões diárias não podem durar mais que 30 min. não a torna errada. Afinal de contas os 15 min. estipulados pelo Scrum estão dentro dos 30 min. A alternativa "a" está ERRADA, pois o termo "no máximo" utilizado sugere uma ampliação do tempo de sprint para 40 dia e todos sabemos que recomenda-se um período entre 2 a 4 semanas (aproximadamente 30 dias)". Este é o tipo de questão que a banca não anularia, pois causar essa confusão foi exatamente o desejo do avaliador.
• A Letra A está flagrantemente errada. Já a Letra C, para mim, contém erro em "reuniões" (no plural). De acordo com o Guia do Scrum, há quatro eventos: Reunião de Planejamento da Sprint (Até 8 horas); Revisão da Sprint (Até 4 horas); Retrospectiva da Sprint (Até 3 horas); e Revisão Diária (Até 15 minutos).
  
  A Reunião de Planejamento da Sprint ocorre antes desta; a Revisão da Sprint ocorre no final desta; a Retrospectiva da Sprint ocorre no final desta; e as Reuniões Diárias ocorrem, evidentemente, todos os dias.
  
  Portanto, Revisão da Sprint e Retrospectiva da Sprint não têm que ocorrer diariamente, no mesmo horário e no mesmo local.
• O erro da questão está em pedir o item INCORRETO. Se ela pedisse o item CORRETO teria gerado menos polêmica.
  Questão lamentável da FCC.
• O erro dessa questão está no "INCORRETO" na descrição. O certo seria "CORRETO"...
• O Erro da Questão está entre os termos "Prova:" e "- 2011 - INFRAERO - Analista de Sistemas - Gestão de TI".
• ainda bem que a FCC não aplica prova pra Petrobras.
• A questão de letra C, claramente fala em reuniões diárias, ou seja, as daily scrum.
  E em um artigo eu encontrei isso "Every day at the same time and place, the Scrum
  Development Team members spend a total of 15 minutes reporting to each other."
  
  O problema é que em uma prova eu ficaria entre a letra A e C, mas provavelmente
  colocaria a letra C e não estaria errada, mas igual eu seria prejudicada =/
• Essa questão caberia recurso. Toda referência do Scrum, INCLUSIVE MANUAL OFICIAL, fala das daily sprints sendo reuniões de no MÁXIMO 15 min. Eu fiquei na dúvida entra A e C e chutei na A. Acertei na sorte.
• essa foi a pior questao que eu ja vi na vida sobre scrum
• Questão com 3 respostas.
  
  a) o período máximo é de 30 dias (1 mês) e o tamanho da equipe varia de 3 a 9 pessoas.
  
  c) as reuniões diárias devem ter uma duração de no máximo 15 minutos.
  
  d) ficaria correto assim: [Durante a reunião diária,] toda conversação restringe as respostas dos participantes às três perguntas do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu trabalho? O que planeja desenvolver até a próxima reunião?
  
  Porém, da forma que está a letra D afirma que no Scrum ninguém conversa sobre mais nada que não seja as respostas às 3 perguntas. A opção mais escancaradamente errada na minha opinião.

• Questão completamente embaralhada e incorreta: primeiramente vamos analisar as assertivas e compará-las com o Scrum Guide:

  a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não superior a 10 pessoas. 

  - O Sprint tem um time-box de 1 mês ou menos o tamanho da equipe de desenvolvimento varia de 3 a 9 desenvolvedores.

  b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint, baseando num novo Sprint Backlog. 

  - Essa assertiva está muito vaga, pois apesar de ser possível cancelar a Sprint antes do seu time-box, somente o  Product Owner tem autoridade para fazê-lo.

  c)   As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e não devem durar mais que 30 minutos. 

  - A reunião diária do Scrum é um evento de time-boxed de 15 minutos.

  d) Toda conversação restringe as respostas dos participantes às três perguntas do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu trabalho? O que planeja desenvolver até a próxima reunião?

  - Nessa questão o entendimento é que o Scrum Master conduz a Reunião Diária. Segundo o Scrum Guide o reunião diária é da Equipe de Desenvolvimento. O Scrum Master deve assegurar que a reunião aconteça e reforçar a regra de que somente a Equipe de Desenvolvimento participe desse evento. A reunião diária é uma reunião que estabelece o compromisso mútuo da Equipe de Desenvolvimento e não há interferências nem interrogatórios por parte do Scrum Master ou Product Owner, apesar desses serem informados dos problemas que porventura aconteçam.

   e) Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do trabalho.

  - Essa assertiva é uma extensão da letra d) em que dá o entendimento de que a reunião diária é condizida pelo SM e que ele interroga a Equipe de Desenvolvimento, o que não é verdade. O SM sim, é responsável por remover os impedimentos do desenvolvimento do produto.

• Quem toma as decisões é a equipe, não o SM. Ele só resolve os impedimentos, servindo à equipe. Letra E errada.

• Além da alternativa A, a alternativa D também está ERRADA!

  "Toda conversação restringe as respostas dos participantes às três perguntas do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu trabalho? O que planeja desenvolver até a próxima reunião?"
  

  Desde quando o time se reporta ao Scrum Master nas dailies? O Scrum Guide mesmo diz:

  "A Daily Scrum é sempre realizada no mesmo horário e local, para reduzir a complexidade. Durante a reunião, cada membro da equipe de desenvolvimento explica: 

   O que foi realizado desde a última Daily Scrum? 

   O que será feito até à próxima Daily Scrum? 

   Que obstáculos estão no caminho da equipa?"

  A equipa de desenvolvimento utiliza a Daily Scrum para avaliar o progresso face à meta do Sprint e para avaliar qual o progresso do trabalho no Sprint Backlog. A Daily Scrum otimiza a probabilidade de que a equipa de desenvolvimento atinja a meta da Sprint. A equipa, muitas das vezes, reúne-se imediatamente após a Daily Scrum para re-planear o resto do trabalho do Sprint. Todos os dias, a equipa de desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar e auto-organizar-se de forma a alcançar as metas e criar o incremento esperado no restante tempo do Sprint. 

  O Scrum Master garante que a equipa de desenvolvimento tem a Daily Scrum, mas a equipa de desenvolvimento é responsável pela condução da Daily Scrum. O Scrum Master ensina a equipa de desenvolvimento a manter a Daily Scrum dentro dos 15 minutos de tempo pré-definido. 

  O Scrum Master reforça a regra de que apenas membros da equipa de Desenvolvimento participam na Daily Scrum. A Daily Scrum não é uma reunião de status e é destinada às pessoas que irão transformar os itens do Product Backlog em incrementos."

  Assim, a Daily Meeting é uma reunião do time e para o time. O SM apenas garante que a mesma ocorra como esperado pelo framework SCRUM.

  Tudo bem que o examinador que confundir, mas errando, ele consegue mesmo!

  Bons estudos!

  
  

• E essa grosseria não foi anulada pela banca? pelo mor...
  

• Essa questão resolvi por simples raciocínio:

  A. de cara vi que estava ERRADA por afirmar "período máximo de 40 dias". O certo seria 30. Até ai blza...

  B. Isso está claro na teoria do Scrum. CERTA

  C. Todos sabem que as reuniões diárias não podem durar mais de 15 minutos. Mas ai pensei, 30 é maior que 15, lógico, então se não pode durar mais que 15 minutos, quem dirá durar mais de 30 minutos. A questão não diz que duram no mínimo 30 minutos. Então... CERTA

  D. Está correta pois as três perguntas podem ser feitas pelo Scrum Master. As reuniões são conduzidas pelo team, mas o Scrum Master participa, nada impede dele fazer a três perguntas. A questão não fala que as perguntas são feitas exclusivamente pelo Scrum Master. CERTA

  E. Esse é o papel do Scrum Master relatado na teoria do Scrum. Ele toma decisões acerca de sua alçada, que é resolver problemas que impeçam o andamento dos trabalhos.

  Essa foi a minha interpretação sobre a questão.

  Espero ter ajudado.

• Pelo que entendi ate agora de Scrum, a letra A e C estão completamente erradas. Deveria ser anulada.

• Acredito que todo mundo deve ter notado que B, D, E estão corretas então eu vou explicar o item A e C blz?
  
  
  Vamos ao guia SCRUM.
  A e C podem causar um nó na cabeça do candidato, assim como causou na minha kkkkkkk, mas aí começa a ler com calma e percebe certas coisas estranhas.
  A - o guia deixa bastante explicito que uma Sprint não pode ser maior que um mês e ele deixa bem explicito que se ultrapassar esse tamanho, pode ocasionar problema como aumento de risco. 
  C- o guia só diz que é 15 minutos o recomendado, mas ele não diz que se passar desse tempo pode ocasionar problemas ao projeto. Pode acontecer de passar esse tempo sem afetar o desempenho do projeto, desde que na final da Sprint o incremento seja entregue.
  
  

• Não entendi o item D. Ele fala em 'toda conversação' e não em reuniões diárias. Como a questão pergunta do Scrum como um todo, achei esse item bem errado, pois temos conversações nas reuniões de planejamento, revisão e retrospectiva também, não?
  

• quinta questão do dia de scrum que deveria ser anulada...

Questão 495790

• Banca: FUMARC
• Órgão: BDMG
• Ano: 2011
• Provas: FUMARC - 2011 - BDMG - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

Analise as seguintes afirmativas sobre o processo ágil Extreme Programming (XP).

I. Planejamento, Projeto, Codificação e Teste são atividades de arcabouço do XP.

II. Cartões CRC (Class Responsibility Collaborator) são produtos de trabalho da atividade de projeto do XP.

III. O XP recomenda a programação em par durante a atividade de codificação.

Marque a alternativa CORRETA:

• A. apenas as afirmativas I e II são verdadeiras.
• B. apenas as afirmativas I e III são verdadeiras.
• C. apenas as afirmativas II e III são verdadeiras.
• D. todas as afirmativas são verdadeiras.

Gabarito: D

Comentários

• I. Correto
  
  Processo XP
  
  Planejamento -> Projeto -> Codificação -> Teste
  
  II. Correto
  
  Na fase de projeto utiliza-se os cartões CRC
  
  III. Correto
  
  Na fase de codificação utiliza-se a programação em par
• todas as afirmações estão corretas..... a mais estranha é a primeira: Planejamento, Projeto, Codificação e Teste são atividades de arcabouço do XP.
  troque arcabouço por framework.
• I - Certo. A Extreme Programming emprega uma abordagem orientada a objetos como o seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes. (pag 88)
  "Arcabouço de Processo" é um termo utilizado por Pressman para definir a estrutura principal de um processo, geralmente em termos de suas atividades.
  II - Certo. A XP encoraja o uso de cartões CRC como um mecanismo eficaz para pensar sobre o software em um contexto orientado a objetos. Os cartões CRC (classe-responsabilidade-colaborador) identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto produzido como parte do processo XP. (pag 89) III - Certo. Um conceito chave na atividade de codificação (e um dos mais discutidos aspectos da XP) é a programação em dupla. A XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho para criar código para uma história. (pag 90) (Fonte: Engenharia de Software, 7ed, Pressman)
  Gabarito "D".

Questão 543940

• Banca: FCC
• Órgão: INFRAERO
• Ano: 2011
• Provas: FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Um dos principais conceitos do Scrum para atacar a complexidade do desenvolvimento e gerenciamento de software é a implantação de um controle descentralizado, capaz de lidar mais eficientemente com contextos pouco previsíveis. Para tanto, o gerenciamento é distribuído por meio de três agentes independentes que são:

• A. Product Owner, Scrum Team e Scrum Master.
• B. Product Owner, Product Backlog e Planning Meeting.
• C. Product Owner, Sprint e Planning Meeting.
• D. Sprint, Scrum Master e Planning Meeting.
• E. Sprint, Scrum Team e Product Backlog.

Gabarito: A

Comentários

• Product Owner é uma pessoa, é o responsável pelo produto, pelos requisitos. Ele é o principal contribuidor, senão o único, do Product Backlog. Ele é o principal interessado em ter o produto pronto. Pode ser um Desenvolvedor, mas nunca o Scrum Master.
  
  O Scrum Team é o time de desenvolvedores - no SCRUM não há distinção entre Engenheiros, Analistas e Programadores.  Geralmente no Scrum temos equipes de até 7 pessoas.
  
  Scrum Master é o conselheiro, não é o chefe da equipe, porém é o conhece os princípios do scrum e tenta matê-los. Pode ser um desenvolvedor, mas nunca um Product Owner.
  
  === Outros Elementos === 
  
  Sprints são unidades de tempo no Scrum. Os sprints são de até 30 dias. Em cada Sprint temos o Sprint Backlog, com as funcionalidades que deverão ser implementadas nesse intervalo. 100% dessa funcionalidade deve ser entregue. 
  
  
• O Scrum Team não é o time de desenvolvedores. O Scrum Team é todo mundo, incluindo o PO e SM.
  
  Fonte: Scrum Guide Oficial (2011): http://www.scrum.org/scrumguides
  Página 5: "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master."
• Não confundir os atores com os eventos:
  Splint
  Planejamento do splint
  Reunião diária
  revisão do splint
  Retrospectiva do splint
• A definição de Scrum Team tem significados diferentes de acordo com as fontes abaixo:
  
  Segundo a documentação do SCRUM disponivel no Eclipse Process Framework (EPF) há a seguinte classificação para SCRUM ROLES: Product Owner, Scrum Master e Scrum Team.
  
  Porém no Guia Scrum, o Time Scrum é composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master. (The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.)
  
  

• concordo com acdcJunior no guia do scrum fala que o Scrum team é formado por :

  Product owner

  Equipe de desenvolvimento, e
  

  Scrum Master
  

  
  

  
  

• Conforme já citado,
  
  "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master."
  
  Erro da banca.

• Banca errou feio... Scrum team é composto de Product Owner, Scrum Master e Equipe de desenvolvimento.

• Verdade, mas quando a FCC erra você mata por eliminação, problema mesmo é quando o CESPE faz umas mancadas deste tipo.

   

   

• a-

  Product owner - interface entre negocio e sistema. representa cliente

  scrum team - 3-9 pessoas

  scrum master - lidera e orienta a equipe.

• Questão escrota, aliás, essas questões mais velhas são terríveis. Parei por aqui.

  Scrum Team = PO, EM e Development Team

• Letra A correta, porém redundante de mais!

  
  

  Scrum Team = PO + SM + DT...

  
  

  Enfim!

  
  

  Fortuna Audaces Sequitur

• Poxa vida!

  Trazer o PO e SCRUM TEAM na mesma alternativa foi maldade demais!

  Espia como está no Guia Scrum:

  O Time Scrum

  "O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master."

Questão 606214

• Banca: CESGRANRIO
• Órgão: FINEP
• Ano: 2011
• Provas: CESGRANRIO - 2011 - FINEP - Analista - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

São práticas recomendadas pelo processo ágil de desenvolvimento de software Extreme Programming (XP), EXCETO a

• A. Programação em Pares
• B. Integração Contínua
• C. Documentação Abundante e Detalhada
• D. Refatoração Frequente
• E. Padronização de Código

Gabarito: C

Comentários

• Letra C. Na Extreme Programming, a documentação existe, é simplificada, e o nível de detalhamento é básico.

• Programação em Pares: Um computador, um teclado, dois programadores; Papéis são alternados freqüentemente; Pares são trocados periodicamente. Benefícios: Melhor qualidade do design, código e testes; Revisão constante do código; Nivelamento da equipe e Maior comunicação. 

  Refatoração (Refactoring): Não existe uma etapa isolada de projeto em XP, o código é o projeto! O projeto é melhorado continuamente através de mudança proposital de código que está funcionando (melhorar o design, simplificar o código, remover código duplicado, aumentar a coesão, reduzir o acoplamento). 

  Integração contínua: manter o sistema integrado o tempo todo. Integração de todo o sistema pode ocorrer várias vezes ao dia (pelo menos uma vez ao dia) e todos os testes (unidade e integração) devem ser executados. Benefícios: Expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e freqüentes); Estimula design simples, tarefas curtas, agilidade; Oferece feedback sobre todo o sistema; Permite encontrar problemas de design rapidamente. 

  Padrões de codificação (Coding Standards): O código escrito em projetos XP segue um padrão de codificação, definido pela equipe em relação a padrão para nomes de métodos, classes, variáveis e organização do código (chaves, etc.) Facilita e estimula a posse coletiva, a comunicação dentro da equipe, a simplicidade, a programação em pares, o refinamento do design. 

  Outras práticas: 

  • Whole Team – Equipe

  • Plannig Game – Jogo do planejamento

  • Customer Tests – Testes de aceitação

  • Small releases – Versões pequenas

  • Simple Design – Projeto simples

  • Test-driven Development – Desenvolvimento orientado a testes (TDD)

  • Collective Ownership – Posse coletiva

  • Metaphor – Metáfora

  • Sustainable Place – Ritmo saudável

•  c)Documentação Abundante e Detalhada

  Como ja foi dito antes (nao lembro quem), agile não gosta de documentação

• Pessoal, a metodologia XP como todas as demais derivam do Manifesto Ágil, que diz é preferível um software em funcionamento a uma documentação abrangente. Isso não quer dizer que não haverá documentação. Haverá sim, mas apenas aquelas que realmente seja necessárias.

  Gabarito

  c) X.

Questão 627913

• Banca: FCC
• Órgão: TCE-SE
• Ano: 2011
• Provas: FCC - 2011 - TCE-SE - Analista de Controle Externo - Coordenadoria de Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Aceita a imprevisibilidade do desenvolvimento de software e a contorna através da adaptação constante. Destaca-se das demais metodologias ágeis por dar mais enfoque à área de gerenciamento. Seu nome tem origem em um esporte quando jogadores de cada time colaboram entre si numa tentativa de avançar juntos pelo campo adversário. Tais características estão presentes no processo

• A. UP.
• B. Crystal.
• C. XP.
• D. DSDM.
• E. Scrum.

Gabarito: E

Comentários

• e)Scrum.

  pricipios do scrum - transparencia, inspeção (nao muito frequente para verificar artefatos), scrum team (product owner, development team,. scrum master), auto-organização & multifunção.

Questão 642337

• Banca: FCC
• Órgão: TCE-PR
• Ano: 2011
• Provas: FCC - 2011 - TCE-PR - Analista de Controle - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Dentre os papéis da metodologia ágil Scrum está o Scrum Master. NÃO se inclui entre as funções deste papel

• A. remover impedimentos para o progresso do time de desenvolvimento.
• B. comunicar claramente a visão, metas e itens de backlog do produto ao time de desenvolvimento.
• C. determinar para o time de desenvolvimento como os itens de backlog devem ser convertidos em potenciais funcionalidades para entrega.
• D. entender o planejamento de produto de longo termo em um ambiente empírico.
• E. ajudar os empregados e envolvidos com o projeto no entendimento e promulgação de Scrum e produtos empíricos.

Gabarito: C

Comentários

• O Scrum Master é o facilitador, não é ele quem determina o sprint backlog. O time, nas últimas 4hs do planejamento da sprint, "transforma" so selected product backlog em tarefas para o sprint backlog.
• Equipe de Desenvolvimento
  A Equipe de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos. As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização paraorganizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as seguintes características:
  • Eles são auto-organizadas. Ninguém (nem mesmo o Scrum Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
  • ...
• O item B não é papel do PO? "comunicar claramente a visão, metas e itens de backlog do produto ao time de desenvolvimento."
• É sim Marcelo, mas veja que a questão pede a alternativa que não é função do papel do Scrum Master. 
  Mas eu fiquei com dúvida no termo usado na alternativa d) ... produto de longo termo... ? achei que poderia ser erro de digitação. Será?
• O Scrum Master trabalhando para o Product Owner
   Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
  Claramente comunicar a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento; (b)
  Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
  Compreender a longo-prazo o planejamento do Produto no ambiente empírico;  (d)
  Compreender e praticar a agilidade; e,
  Facilitar os eventos Scrum conforme exigidos ou necessários
  
  O Scrum Master trabalhando para a Equipe de Desenvolvimento
   Treinar a Equipe de Desenvolvimento em auto-gerenciamento e interdisciplinaridade;
  Ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de alto valor;
  Remover impedimentos para o progresso da Equipe de Desenvolvimento; (a)
  Facilitar os eventos Scrum conforme exigidos ou necessários; e,
  Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.
  
  O Scrum Master trabalhando para a Organização
   Liderando e treinando a organização na adoção do Scrum;
  Planejando implementações Scrum dentro da organização;
  Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; (e)
  Causando mudanças que aumentam a produtividade do Time Scrum; e,
  Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações
  
  Comentário alternativa c)
  As Equipes de Desenvolvimento tem as seguintes características:
   Eles são auto-organizadas. Ninguém (nem mesmo o Scrum Master) diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
  Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
  O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho   que está sendo realizado pela pessoa; Não há exceções para esta regra.
  Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e,
  Equipes de Desenvolvimento não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios

• Determinar para o time de desenvolvimento como os itens de backlog devem ser convertidos em potenciais funcionalidades para entrega. Seria função do SCRUM PRODUCT OWNER
  

• Caro colega Rodrigo Marcelo, não parece razoável que tal atividade seja uma responsabilidade do PO ou de qualquer outro indivíduo. A utilização dos termos "determinar" (...) "como" torna a assertiva muito inflexível, o que, a meu ver, não vai de encontro ao manifesto ágil.

  Possui alguma fonte para compartilhar. Fiquei curioso.

  Respeitosamente,

  Maurício

   

• Nesta questão ficou claro que você procura a resposta "menos errada"

• ✅ Gabarito - C de Cristo.

  O Scrum Master não determinar para o time de desenvolvimento como os itens de backlog devem ser convertidos em potenciais funcionalidades para entrega. Ele não precisa nem mesmo ser desenvolvedor. Inclusive, dependendo da equipe, a figura do Scrum Master é DISPENSADA.

  Do Guia Scrum:

  Os Times de Desenvolvimento tem as seguintes características:

  • Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;

  O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:

  • Expressar claramente os itens do Backlog do Produto;

  • Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;

  • Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;

  • Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar oque o Time Scrum vai trabalhar a seguir; e,

  • Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

  O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo.

Questão 642340

• Banca: FCC
• Órgão: TCE-PR
• Ano: 2011
• Provas: FCC - 2011 - TCE-PR - Analista de Controle - Informática
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Na metologia Scrum, Sprint é uma iteração de duração menor ou igual a um mês, onde uma parte incremental e funcional do produto está potencialmente pronta para entrega. É INCORRETO afirmar que, nessa fase,

• A. o escopo pode ser esclarecido e renegociado entre o time de desenvolvimento e o proprietário do produto.
• B. nenhuma alteração que afetaria a meta do Sprint é efetuada.
• C. a composição do time de desenvolvimento permanece constante.
• D. as metas de qualidade não diminuem.
• E. o Sprint pode ser cancelado por decisão do Scrum Master.

Gabarito: E

Comentários

• Quanto a letra c, precisa tomar cuidado pois a equipe permanece constante durante todo o sprint, mas pode ser modificada na mudança de sprint.
• o Sprint pode sim ser cancelado mas não é o Scrum Maste quem pode fazer isso.
  
  http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf
  
  Cancelando um Sprint.
   
  Um Sprint pode ser cancelado antes de o seu prazo ter se esgotado. Somente o Dono do produto tem 
  a autoridade para cancelar o Sprint, apesar de que ele (ou ela) pode fazer isso sob a influência dos 
  stakeholders, da equipe de Desenvolvimento ou do Scrum máste
• Letra e) Errado: 
  
  Justificativa
  Um Sprint pode ser cancelado antes de o seu prazo ter se esgotado.
  "Somente o Dono do produto tem a autoridade para cancelar o Sprint" (e não o scrum master), apesar de que ele (ou ela) pode fazer isso sob a influência dos 
  stakeholders, da equipe de Desenvolvimento ou do Scrum master.
  
  http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf
• De acordo com o Guia Scrum:
  
  
  Durante a Sprint:
  • Não são feitas mudanças que podem afetar o objetivo da Sprint; (b)
  • A composição da Equipe de Desenvolvimento permanecem constantes; (c)
  • As metas de qualidade não diminuem; e, (d)
  • O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido. (a)
  Portanto, a incorreta é a "E"

• Cancelling a Sprint 

  A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

  
  

• Já vi em diversas vídeo aulas e tutoriais afirmando que o Sprint não pode ser alterado. Mas no Sprint é possível alterar o backlog. No meu entendimento o escopo a que se refere a letra A) é o escopo do sprint, e dá a entender que ele pode ser esclarecido (tirar eventuais dúvidas) e renegociado (ser alterado). Se negociar o sprint é adicionar alguns itens do backlog para formar o sprint, então renegociar um sprint é incluir, alterar ou excluir os itens selecionados anteriormente. Isso pode? Se fosse o escopo do projeto que está em requisitos no backlog tudo bem, mas a questão induz a pensar que se fala do escopo do sprint que está em andamento.

• ✅ Gabarito - E de escovinha

  Somente o PO pode cancelar a Sprint, ainda que seja por influência das partes interessadas. O Scrum Master não pode fazer isso.

  Direto do guia não tem erro:

  "Cancelamento da Sprint

  Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master"

Questão 644440

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Analista Judiciário - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

Sobre XP e SCRUM é INCORRETO afirmar:

• A. No XP, os testes são escritos antes da atividade de desenvolvimento e todas as funcionalidades só possuem valor se forem testadas e obtiverem unanimidade de aprovação.
• B. 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.
• 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.
• D. SCRUM não especifica a programação em pares ou desenvolvimento orientado a testes, porém especifica a forma de gerenciamento dos requisitos ou características solicitadas.
• E. Enquanto o XP é mais receptivo a mudanças durante a iteração, no SCRUM as solicitações do cliente devem aguardar o término da iteração em andamento.

Gabarito: C

Comentários

• 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

Questão 646153

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Técnico Judiciário - Programador de Computador
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum; XP (eXtreme Programming)

Nos métodos ágeis XP e Scrum, as entregas de partes funcionais do projeto são divididas em ciclos, geralmente compreendidos no período de 1 a 4 semanas. Estes ciclos denominam-se, respectivamente,

• A. iterações e sprint.
• B. reunião de planejamento e backlog.
• C. período de entrega e reunião de revisão.
• D. backlog e planejamento da produção.
• E. entrega e retrospectiva.

Gabarito: A

Comentários

• LETRA A.
  XP é uma metodologia ágil, para o desenvolvimento de projetos de IT cujas especificações são passíveis a alterações. As iterações do XP costumam ser curtas, provendo constantes versões do produto (releases) para o cliente, que por sua vez provê comentários e opiniões que realimentam a próxima iteração. O objetivo do XP é tornar o projeto flexível, diminuindo o custo a possíveis mudanças. O código produzido é tomado como indicador de progresso do projeto.
  

  No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

• a-

  ciclos têm nomes diferentes dependendo da metodologia. EM xp, iterações. EM scrum, sprints.

Questão 646156

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Técnico Judiciário - Programador de Computador
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; XP (eXtreme Programming)

No contexto de programação ágil XP, um débito técnico é descrito como o

• A. número de pontos funcionais não entregues no último período.
• B. custo homem/hora da equipe técnica para um determinado projeto.
• C. método de modificação do código fonte, com alteração do seu comportamento, porém sem alteração de seu significado.
• D. dispêndio relacionado ao desenvolvimento, teste ou entrega da parte funcional do sistema.
• E. total de desenvolvimento feito de maneira rápida e simples sem, às vezes, levar em consideração testes e arquitetura do sistema.

Gabarito: E

Comentários

• Débito Técnico seria o gap entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia.
  Isso exposto, o gabarito correto é a letra E de esfuziante.
• debito tecnico é uma parte do codigo q não foi feita de forma adequada/padronizada q podera causar dificuldade em futuras manutenções.
• O defeito é o efeito visível da baixa qualidade. O efeito, nem sempre visível, é o débito técnico. O débito técnico foi um termo cunhado para descrever o valor negativo de código escrito com baixa qualidade interna. Ao longo do tempo essa baixa qualidade vai cobrando o seu preço e tornando o time de desenvolvimento menos responsivo. 
  Como o código fica cada vez mais difícil de manter, para continuar atendendo o cliente, os desenvolvedores desrespeitam, cada vez mais, bons padrões de desenvolvimento de software, em um ciclo que vai se retroalimentando, engessando o time de forma crescente, gerando insatisfação nos seus membros e também com os clientes

• Matéria interessante que explana o assunto: http://bytesdontbite.com/2011/09/26/a-metafora-da-divida-tecnica/

Questão 659914

• Banca: FCC
• Órgão: TRE-CE
• Ano: 2012
• Provas: FCC - 2012 - TRE-CE - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

No SCRUM, sprint é

• A. um representante dos stakeholders e do negócio.
• B. uma lista de requisitos que tipicamente vêm do cliente.
• C. uma lista de itens priorizados a serem desenvolvidos para um software.
• D. uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
• E. um conjunto de requisitos, priorizado pelo Product Owner.

Gabarito: D

Comentários

• Um sprint é a unidade básica de desenvolvimento em Scrum. Sprints tendem a durar entre uma semana e um mês, e são um esforço dentro de uma "caixa de tempo" de um comprimento constante.

  Cada sprint é precedido por uma reunião de planejamento, onde as tarefas para o sprint são identificadas e um compromisso estimado para o objetivo do sprint é definido e seguido por uma reunião de revisão ou de retrospectiva, onde o progresso é revisto e lições para os próximos sprints são identificadas.

  Durante cada sprint, a equipe cria um incremento de produto potencialmente entregável (por exemplo, software funcional e testado). O conjunto de funcionalidades que entram em um sprint vêm do "backlog" do produto, que é um conjunto de prioridades de requisitos de alto nível do trabalho a ser feito. Quais itens do backlog entram para o sprint são determinados durante a reunião de planejamento do sprint. Durante esta reunião, o Product Owner informa a equipe dos itens no backlog do produto que ele ou ela quer concluídos. A equipe então determina quantos eles podem se comprometer a concluir durante o próximo sprint, e registram isso no backlog do sprint. Durante um sprint, ninguém está autorizado a alterar o backlog do sprint, o que significa que os requisitos são congelados para esse sprint. O desenvolvimento está dentro de uma caixa de tempo, o que significa que o sprint deve terminar a tempo. Se os requisitos não são completados por qualquer motivo, eles são deixados de fora e voltam para o backlog do produto.

  Um princípio chave do Scrum é o reconhecimento de que, durante um projeto, os clientes podem mudar de idéia sobre o que eles querem e precisam (muitas vezes chamados requisitos churn), e que os desafios imprevisíveis não podem ser facilmente tratados de uma maneira preditiva ou planejada tradicional. Como tal, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe para entregar rapidamente e responder às necessidades emergentes.

  • Cada sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
  • Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI e por conhecer as necessidades do cliente).
  Fonte: http://pt.wikipedia.org/wiki/Scrum
• Corrigindo a primeira frase do nosso amigo acima. Segundo o livro SCRUM e XP além das trincheiras
  
  "Scrum não é uma metodologia, é um framework. O que significa que o Scrum não vai te dizer exatamente o que fazer."
• a) um representante dos stakeholders e do negócio. PRODUCT OWNER
  b) uma lista de requisitos que tipicamente vêm do cliente. PRODUCT BACKLOG
  c) uma lista de itens priorizados a serem desenvolvidos para um software. PRODUCT BACKLOG
  d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto. SPRINT
  e) um conjunto de requisitos, priorizado pelo Product Owner. PRODUCT BACKLOG
  
• Sprint deve passar a idéia de iteração onde as atividades priorizdas são desenvolvidas.
  
  As atividades de um determinado Spring vem do Product Backlog e chamam-se SPRINT BACKLOG.

• ✅ Gabarito - D de Deus

  Direto do guia scrum:

  A Sprint

  O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

Questão 661801

• Banca: FCC
• Órgão: TRE-CE
• Ano: 2012
• Provas: FCC - 2012 - TRE-CE - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Processos de Software - Desenvolvimento Ágil; Scrum

Um dos pontos da metodologia Scrum é o Daily Scrum, que consiste em uma reunião diária com aproximadamente 15 minutos de duração onde são tratados assuntos relacionados ao projeto. Nessa reunião são feitas 3 perguntas a cada membro do time de desenvolvimento, constando o que foi feito desde a última reunião, o que será feito até a próxima reunião e qual

• A. modelo de testes está sendo utilizado pela tarefa atual.
• B. o tempo restante para finalização da tarefa.
• C. a relação da tarefa atual com o outro membro da equipe.
• D. a tarefa que está sendo executada no momento.
• E. obstáculo impede o desenvolvedor de prosseguir com a tarefa.

Gabarito: E

Comentários

• O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

  • O que você fez ontem?
  • O que você fará hoje?
  • Há algum impedimento no seu caminho?
• Daily Scrum: 15 minutos de reunião diária. Os membros da equipe respondem às questões básicas:
  
  1) O que você fez desde a última reunião Scrum?
  2) Você tem algum obstáculo?
  3) O que você vai fazer antes da próxima reunião?
  
  Reposta: "E"
  
  Fonte: Livro "Engenharia de Software" - Roger Pressman Sexta Edição
  
  

• e-

  3 questoes do scrum: o que fez, o que vai fazer e o que esta atrapalhando.