SóProvas

Questões de Scrum

ID
119290
Banca
FCC
Órgão
TRF - 4ª REGIÃO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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

ID
121153
Banca
FCC
Órgão
AL-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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)

ID
147292
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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. 

ID
173821
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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?

ID
183769
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto das regras do SCRUM, é correto afirmar:

Alternativas
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.

ID
183772
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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?
ID
183775
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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

ID
186772
Banca
FCC
Órgão
TRE-RS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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

ID
189232
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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....

ID
189235
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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.
ID
201331
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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?

ID
215668
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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.
ID
218191
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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.

     

ID
239728
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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.

ID
243058
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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!

ID
260248
Banca
FCC
Órgão
TRT - 4ª REGIÃO (RS)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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

ID
314671
Banca
FCC
Órgão
TRT - 1ª REGIÃO (RJ)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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.

ID
319672
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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?

ID
321154
Banca
CESPE / CEBRASPE
Órgão
Correios
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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

ID
321169
Banca
CESPE / CEBRASPE
Órgão
Correios
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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).

    mauriciorochabastos@gmail.com

ID
326248
Banca
FUMARC
Órgão
CEMIG-TELECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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...)

ID
337732
Banca
CS-UFG
Órgão
UFG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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

ID
362893
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

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.

Alternativas
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...

ID
450004
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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
ID
450007
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

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:

Alternativas
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...

ID
471133
Banca
FCC
Órgão
INFRAERO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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!

  • 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...

ID
543940
Banca
FCC
Órgão
INFRAERO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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:

Alternativas
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."

ID
627913
Banca
FCC
Órgão
TCE-SE
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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.

ID
642337
Banca
FCC
Órgão
TCE-PR
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre os papéis da metodologia ágil Scrum está o Scrum Master. NÃO se inclui entre as funções deste papel

Alternativas
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.

ID
642340
Banca
FCC
Órgão
TCE-PR
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

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,

Alternativas
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"

ID
644440
Banca
FCC
Órgão
TJ-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre XP e SCRUM é INCORRETO afirmar:

Alternativas
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

ID
646153
Banca
FCC
Órgão
TJ-PE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

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,

Alternativas
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.

ID
659914
Banca
FCC
Órgão
TRE-CE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

No SCRUM, sprint é

Alternativas
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.

ID
661801
Banca
FCC
Órgão
TRE-CE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

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

Alternativas
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.

ID
695257
Banca
FCC
Órgão
TRF - 2ª REGIÃO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Segundo Roger S. Pressman, em seu livro Engenharia de Software, 7a edição, 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 atividades estruturais de 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

Alternativas
Comentários
  • Sprint (corrida)

    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" (ou seja, restrito a uma duração específica) 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.


    http://pt.wikipedia.org/wiki/Scrum
  • A)Process Backlog não é nada (pelo menos nao relacionado a Scrum), taí mais para confundir quem leu bem por cima sobre Scrum
    B)Scrum Master é uma pessoa não um processo (também acho que é so para enganar quem apenas viu algo sobre Scrum e não prestou atenção)
    C)Product Owner mesma coisa que a alternativa B
    D) Backlog por si só, para o Scrum, não é nada, ou é product backlog ou Sprint backlog  talvez quem só viu os termos do Scrum se confunda 
    E) Sprint, a resposta certa. (A pessoa chega nessa até por eliminação, se for o caso)

ID
701566
Banca
FCC
Órgão
TRE-SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Analise o texto:

O Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser eficazes para projetos com prazo de entrega apertados, requisitos mutáveis e críticos de negócio. Cada um desses padrões de processos define um conjunto de ações de desenvolvimento. Uma dessas ações consiste em manter uma lista com prioridades dos requisitos ou funcionalidades do projeto que fornecem valor comercial ao cliente. Os itens podem ser adicionados a esse registro em qualquer momento. O gerente de produto avalia o registro e atualiza as prioridades conforme requisitado.

A lista citada no texto é conhecida como

Alternativas
Comentários
  • 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 Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste.

    Fonte: Wikipédia




  • Gabarito "D". Segundo Pressman, o registro pendente de trabalhos (backlog) consiste em uma lista com prioridades dos requisitos ou funcionalidades do projeto que fornecem valo comercial ao cliente. Os itens podem ser adicionados a esse registro em qualquer momento (é assim que as alterações são introduzidas). O gerente do produto avalia o registro e atualiza as prioridades conforme requisitado. (Fonte: Livro Engenharia de Software 7ed, Pressman, pag 95)

  • É bom lembrar que existe o Product Backlog e o Sprint Backlog, chega no primeiro, passa para o segundo e então sim é realizado ou não no Sprint, se não der de entregar volta para o backlog do produto.

ID
713215
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

SCRUM é uma metodologia ágil para gerência de projetos que

Alternativas
Comentários

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

    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. 

    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.



  • d)utiliza reuniões com objetivos específicos para o planejamento e o acompanhamento do projeto.

    como toda metodologia agile, scrum prioriza envolvimento do cliente e reunioes constantes para inspecionar progresso. é baseado no empirismo e controle de processo. 

ID
723562
Banca
FCC
Órgão
TRT - 6ª Região (PE)
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Na metodologia Scrum, NÃO faz parte de uma revisão do sprint (sprint review) o seguinte procedimento:

Alternativas
Comentários
  • 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 asquestõ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; e,
    • 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.
    Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho, faz parte da retrospectiva da sprint e não da revisão
  • "Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho." é propósito da Retrospectiva da Sprint. Guia Scrum pg 12
  • GABARITO: E

    Uma boa forma de pensar e gabaritar as questões envolvendo Sprint Review e Sprint Retrospective é fazer um relacionamento com Produto e Processo, respectivamente. Ou seja, quando a questão/alternativa fizer uma associação com com Produtos, trata-se de Sprint Review. De modo análogo, quando a questão/alternativa fizer uma associação com com Processos, trata-se de Sprint Retrospective.

    Na ocasião a alternativa E fala em "Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho", a expressão como está relacionado a PROCESSO, ou seja, como deve-se trabalhar (quais passos deve-se seguir... quais tarefas deve-se fazer) para atingir a meta, consequentemente trata-se de um objetivo da Sprint Retrospective.

    Todas as outras alternativas fazem referência ao PRODUTO, logo trata-se de objetivos da Sprint Review.

    Espero ter contribuído!

    Bons estudos e VQV!!!

  • Fiquei em dúvida na letra c.

    c) O time de desenvolvimento discute quais fatores positivos e negativos ocorreram durante o sprint e como os problemas foram resolvidos.

    Esses fatores positivos e negativos não estão associados aos aspectos gerenciais do processo?

  • Segundo o Guia do Scrum, páginas 11 e 12:

    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”;  <<< AQUI ESTÁ A RESPOSTA "B"

    - A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos; <<< AQUI ESTÁ A RESPOSTA "C"

    - A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento; <<< AQUI ESTÁ A RESPOSTA "D"

    - 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; e, 

    - 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. <<< AQUI ESTÁ A RESPOSTA "A"


    O propósito da Retrospectiva da Sprint é: 

    - Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas; 

    - Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e, 

    - Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;   <<< AQUI ESTÁ A RESPOSTA "E"


    Fonte: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf

  • fui na letra C tbm

     

    The Development Team discusses what went well during the Sprint, what problems it ran

    into, and how those problems were solved; 

     

    nem adianta reclamar

     

    as questoes de SCRUM sao copy and paste do guide

  • A letra C realmente tem alguma ambiguidade, mas a E não deixa dúvidas de que se refere à retrospectiva. Portanto, não faz parte da revisão.

  • Fui na C pq quando falou em Time de Desenvolvimento....... Imaginei que estava faltando citar o Scrum Master.... Mas vamo nessa

  • NADA COMO UMA BOA LIDA NO PRÓPRIO GUIA!

  • Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho. (Retrospectiva da Sprint)

ID
726907
Banca
INSTITUTO CIDADES
Órgão
TCM-GO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

São consideradas metodologias ágeis de desenvolvimento:

I. Scrum

II. DSDM

III. XP (Extreme Programming – Programação Extrema)

IV. FDD

Alternativas
Comentários
  • Não conhecinha a métodologia DSDM!
    Metodologia de Desenvolvimento de Sistemas Dinâmicos (do inglês Dynamic Systems Development Method - DSDM): 
    É interativa e incremental de propriedade da Agile Alliance. Caracterizada por cronogramas e custos limitados.
    3 fases: pré-projeto, ciclo de vida, e pós-projeto.
    A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do Modelo Funcional, iteração de elaboração e construção e, por fim, implantação.
  • Modelos Ágeis:
    - DSDM (Dynamic Systems Development Method)
    - Scrum
    - Crytal
    - FDD (Feature Driven Development)
    - XP (Extreme Programing)
    - ASD (Adaptive Software Development)

  • - Kaban

    - DDD (Domain-Driven Design)

    - TDD (Test-Driven Development)


  • METODOLOGIA DE DESENVOLVIMENTO ÁGIL
    1.   RUP
    2.   SCRUM
    3.   XP
    4.   DSDM
    5.   DAS OU ASD
    6.   FDD
    7.   MODELAGEM ÁGIL
    8.   OPEN SOURCE SOFTWARE DEVELOPMENT - segundo o Cespe


    Só não entendi a carinha amarela

    Basta consultar Pressman que gabarita a questão

    Letra E

  • RUP???

  •  e)Todas as afirmações .

    Metologias agile prescrevem desenvolvimento de software com varias iterações por todos os esteagios da produção varias vezes, o que faz com que seja chamado de modelo iterativo e desenvolvimento espiral. Os estagios sao os mesmos do waterfall model (analise, design, implementação, testes, implantação, manutencção), mas produz uma versao funcionald o software no final de cada ciclo. metologias agile:

    XP (programação a 2 e testes antes do codigo), Scrum (equipes auto-organizaveis com base no empirismo), FDD (features a cada 2 semanas), crystal (uma familia determinada por cores e com incrementos a cada 4 meses), DSDM (base no RAD (rapid application development) com destaque à participação do usuario)

  • RUP não é agil.

ID
753190
Banca
FCC
Órgão
MPE-AP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Na metodologia de desenvolvimento SCRUM, o proprietário do produto (Product Owner) é responsável por maximizar o valor do produto e o trabalho da equipe de desenvolvimento. O proprietário do produto é a única pessoa responsável pela manutenção do Backlog do produto. Este gerenciamento inclui

Alternativas
Comentários
  • Questão Retirado literalmente do Guia do Scrum ( Pag. 5 )
    O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.
    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; Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
  •  a) assegurar que a equipe de desenvolvimento compreenda os itens do Backlog do produto no nível necessário. -correto- Product backlog é a 1° fase em SCRUM. É a parte de software development que compreende analisar as necessidades do usuário a fim de que o SCRUM Master possa atribuir as tarefas de desenvolvimento baseando-se no que o usuário realmente precisa.
  • Alternativas restantes correspondem à atribuições do Scrum Master
    O Scrum Master trabalhando para o Product Owner
      O Scrum Master serve o Product Owner de várias maneiras, incluindo:
       Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto; (b) Claramente comunicar a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento; (c) Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa; (d) Compreender a longo-prazo o planejamento do Produto no ambiente empírico; (e) Compreender e praticar a agilidade; e, Facilitar os eventos Scrum conforme exigidos ou necessários.

  • ✅ Gabarito - A de Acertei!

    Direto do guia.:

    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 o

    que 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.

ID
770146
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens que se seguem, em relação a metodologias de
análise, projeto e desenvolvimento de sistemas.

Em um projeto gerido com a metodologia Scrum, um produto estará, ao final de cada sprint, completamente testado, estando 100% completos todos os requisitos do product backlog.

Alternativas
Comentários
  • O erro da questão esta presente na afirmativa "ao final de cada sprint, ..., estando 100% completos todos os requisitos do product backlog". Na verdade ao final de cada sprint o Sprint Backlog e que estará 100% completo. Sprint Bakclog é derivado do Product Backlog, são tarefas que a equipe se compromete em concluir ao final de cada sprint.
  • O Product Owner(PO)(dono do produto - cliente ou representante) com a ajuda do Scrum Master(facilitador do projeto) define e prioriza uma lista com todas as funcionalidades do produto.(isso é denominado product backlog).

    Na primeira parte da reunião de planejamento da sprint, o Product Owner define quais funcionalidades do product backlog serão escolhidas para compor uma determinada sprint(ciclo de 30 dias aproximadamente).

    Na segunda parte da reunião de planejamento da sprint, o Time de Desenvolvimento define quais tarefas deverão ser realizadas numa sprint para atender às funcionalidades escolhidas pelo PO. (isso é denominado sprint backlog).

    Portanto, cada sprint backlog diz respeito à parte das funcionalidades do product backlog. Ou seja, a cada sprint(ciclo de 30 dias) completada teremos uma determinada funcionalidade pronta e não todo o produto pronto.









  • Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir.

    Guia Scrum.
  • Você tem partes testadas e não o produto inteiro !
  • Gente um produto nunca estará completamente testado.

  • " Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto  também existir."

    Fonte: Scrum Guide (Versão em Português), 2013. Página 13.

  • Só fazendo uma pequena correção no comentário do Leonel. Em alguns casos, o Sprint Backlog não estará 100% completo ao final de cada sprint. A equipe, por alguns impedimentos, pode não finalizar todas as tarefas planejadas para o sprint.

  • ✅ Gabarito - E de Esmerilhando

    Product backlog é um artefato vivo.

ID
770149
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens que se seguem, em relação a metodologias de
análise, projeto e desenvolvimento de sistemas.

O escopo, a importância e a estimativa de um Sprint do Scrum são definidos pelo product owner.

Alternativas
Comentários
  • a estimativa é definida pela equipe e pelo scrum master através de uma reunião.
  • Apenas complementando a resposta acima...
    A definição de escopo da Sprint é feita pelo PO, que informa durante a reunião de planejamento da sprint quais itens do product backlog serão priorizados, e pela equipe que irá determinar/estimar quantos itens poderá atender dentro do timebox da sprint. Do resultado da reunião surge o Sprint Backlog
  • O escopo, a importância e a estimativa de um Sprint do Scrum são definidos pelo product owner.

    As funcionalidades do produto(escopo) e o seu grau de importância(prioridade) são definidos pelo Product Owner.( o scrum master pode ajudar nessa parte).

    O Sprint Backlog(Lista de tarefas por  fazer durante a Sprint) é realizado pela Equipe de Desenvolvimento. Assim, ela possui os requisitos para estimar o tempo, o custo e o esforço que uma determinada funcionalidade demanda. Saberá, por exemplo, que uma determinada função de login, de acordo com programas realizados anteriormente, necessitará de x linhas de código, ou tantos dias de trabalho, etc.
  • A Equipe de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve 
    influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as 
    pessoas que irão realizar o trabalho fazem a estimativa final.

    Fonte: Scrum Guide, tópico: Backlog do Produto

  • Estimativa de que???????????????? ¬¬

  • Após o PO priorizar o que deve ser feito para a próxima sprint. O time de desenvolvimento fará a estimativa do que poderá realmente ser feito, criando assim a selected list backlog. Na segunda parte do planejamento da sprint, o time irá detalhar os itens selecionados e os decompor em atividades. Depois irão se auto-organizar e criar planos de entrega para cada atividade. Daí cria-se o sprint backlog, artefato que somente poderá ser alterado pelo time de desenvolvimento.

  • Escopo e Importância (no sentido de prioridade) = Product Owner (1º parte do planejamento da sprint).

    Estimativa = Time de desenvolvimento (2º parte do planejamento da sprint).


    Gabarito: Errado.

  • ✅ Gabarito - E de Estupefato

    Estimativa -> Time de desenvolvimento

    Regra de ouro: quem estima é quem faz.

ID
770155
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens que se seguem, em relação a metodologias de
análise, projeto e desenvolvimento de sistemas.

A metodologia Scrum, ágil para gerência de projetos, baseia-se em ciclos de 30 dias, denominados sprints, em que se trabalha para alcançar objetivos bem definidos.

Alternativas
Comentários
  • Eu pediria troca de gabarito da questão visto que um sprint tem tempo variável entre 2 e 4 semanas.
  • você tem toda razão o prazo do sprint é variável, durando comumente entre 2 e 4 semanas, mas isso não é regra.
  • Não acreditei que o gabarito para essa questão era "CORRETO". (mas no site do Cespe consta que o item está correto)
    Será que ninguém entrou com recurso não?
    Como a moça ali disse: é de 2 - 4 semanas cada sprint. Logo a questão é ERRADA.
  • Ágil para gerência de projetos está certo? Não entendi... O Scrum não prevê equipes auto-gerenciáveis? Não entendi o termo usado na afirmação. Alguém poderia explicar?
  • Também não entendi isso de 'ágil para gerência de projetos'...

    No Pressman ( pag 69 6° edicao) ele diz:
    Os princípios do scrum são usados para guiar as atividades de desenvolvimento dentro de um processo que incorpara as seguitnes atividades do arcabouço: requisitos, análise, projeto, evolução e entrega;
  • "(...)ágil para gerência de projetos(...)"... (De desenvolvimento de Software).

    o "em ciclos de até 30 dias" não vejo como um erro. Talvez ele tenha colocado o prazo máximo (30 dias) mas não torna errado o ítem. (Se fosse "ciclo de 45 dias...talvez)
  • Figura clássica do SCRUM pode ser encontrada na wikipedia  http://pt.wikipedia.org/wiki/Scrum
  • Tratando-se do CESPE, a expressão "baseia-se em ciclos de 30 dias", que em todo caso já não é uma afirmativa precisa, pode ter uma gama de dimensões maior ainda.Quanto à parte inicial está correto, pois, em princípio , a finalidade do Scrun era o gerenciamnto de projetos de fabricação de veículos...não me recordo a fonte em que li isto, mas, pode ser pesquisado na internet.
  • se estivesse escrito EXATAMENTE 30 dias estaria errada.
    A CESPE é assim.
  • No Guia Oficial do Scrum, não há nada dizendo sobre 2 a 4 semanas. O Guia diz: "Sprints são limitadas a um mês corrido". Portanto, há sprints de 10, 15, 20, 25 ou 30 dias. A questão não restringiu a 30 dias, portanto está correta.

    Quanto ao comentário do colega Marcus Lavinas, está correto: "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".

    Lembremos que o Scrum está para o XP como o PMBoK está para o RUP. Scrum e PMBoK são guias para Gerência de Projetos (de qualquer área) e XP e RUP são metodologias para Desenvolvimento de Software (área de TI). Entretanto Scrum e XP são ágeis!
  • Questão correta e só para registrar que se escreve "O" Cespe .. hehehe

  • Eu pediria recurso, quando se afirma "baseia-se em ciclos de 30 dias" está claramente dizendo que os ciclos são exclusivamente de 30 dias, e sabemos que o ciclo de um sprint varia de 2 a 4 semanas. Só pra constar, 4 semanas = 28 dias.

  • Concordo que deveria ser entre 2 e 4 semanas!


  • Questão totalmente passível de recurso. Os sprints tem duração fixa, definida de acordo com as necessidades das equipes e do projeto, recomendando-se que eles durem entre duas semanas e um mês. Sendo assim, não tem como encaixar sprints de 3 semanas em ciclos de 30 dias. Mas fazer o que, as bancas geralmente se valem de conhecimento superficial dos assuntos e argumentos bobos para validar esse tipo de questão.

  • Scrum é um framework para desenvolver e manter produtos complexos.
     

    Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos.

     

    Produto <> Projeto
     

  • ✅ Gabarito - C de Cê errou também?

    Poxa vida, cespe sendo cespe

ID
779212
Banca
CESPE / CEBRASPE
Órgão
TRE-RJ
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, acerca das metodologias de análise,
projeto, desenvolvimento de sistemas e ferramentas de
desenvolvimento e apoio ao desenvolvimento de software.

A metodologia scrum prega que a equipe complete e entregue partes do produto final constantemente ao final de cada interação. Essa interação deve ser curta e possuir tempo de execução definido previamente.

Alternativas
Comentários
  • Questão maldosa! Qual o conceito de curta? Há sprints de 2 semanas podendo chegar até 1 mês. Não considero 1 mês como sendo um período curto. Eu marcaria ela como "Errada".

    Alguém poderia ajudar?

    Grato!
  • Acredito que isso seja uma características das metodologias ágeis.


    No livro do Pressman ( pag 70 6° edição) ele fala sobre as sprints, dizendo que: 
    "o sprint permite que os membros da equipe trabalhem em um ambiente de curto prazo, mas estável".

    Acima, no mesmo parágrafo do trecho citado, ele fala sobre um período típico de uma sprint( 30 dias).
  • O conceito da questão está correto. O que me deixou insatisfeito foi trocarem o conceito de ITeração por INTeração e mesmo assim considerarem a questão correta.
  • A questão estava correta mas escrever iNteração, para mim, anulou a questão.
    Marquei como errada por isso :/ Assim fica difícil
  • Silas, entendo você considerar que 1 mês é muito tempo, mas isso quando você pensa em metodologias ágeis. Se você for considerar que no modelo Espiral uma ciclo completo pode levar até 1 ano, então 1 mês é na velocidade do som, não é?
    Valeus!
    Augusto
  • Eu marquei ERRADA devido ao possível erro na palavra iNteração.

    Porém depois fui analisar melhor e penso que apesar das várias iterações do Scrum, a entrega do resultado de uma ITeração ( sprint ) é feita após uma INTeração, a reunião Sprint Review. Uma reunião se encaixa no sentido da palavra INTeração.

    Mesmo que isto não fosse o objetivo inicial da questão... pode ter sido um bom argumento para a banca ter mantido a questão como CERTA.

    O que acham?
  • A palavra interação com certeza invalídaa questão quer seja erro de digitação ou não!
    Com certeza caberia um recurso e muito bem fundamentado.
  • Já deu pra aprender que para responder provas da CESPE e da FCC você deve rasgar o dicionário e os livros didáticos e aceitar que ITeração é sinônimo de INTeração.

  • Caraca! É a típica pergunta que eu não saberia como responder na prova. Interação é complicado

  • Os estagiários estão por toda parte! Chessuis!

  • @Alex: cheguei a tentar pensar algo do tipo, mas o problema também foi que o item falou "cada interação", e não temos apenas uma. E não é em toda reunião que é entregue parte do produto final.

  • Para resolver questões do Cespe desse tipo (troca de iteração por interação) procuro raciocinar da seguinte forma:


    Se for dito na questão apenas INteração (sozinha), considerarei INteração = ITeração pois, conforme alegado anteriormente pela banca, esse erro de escrita não interfere na interpretação da questão. Caso esteja escrito INteração e ITeração na mesma questão esse argumento da banca cairá por terra, o que provavelmente invalidará a assertiva.


    Bons estudos!


  • A CESPE é maluca!

    Em questões do mesmo dessa considerou errado ~interação~ e agora considera certo.

    kkkkkkkkkkkkkkkk

ID
783586
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o  item  seguinte , relativo a processos de software e a sistemas orientados a objetos (OO).

O SCRUM é um método ágil em que todos os itens do sprint backlog advêm do product backlog.

Alternativas
Comentários

  • Na versão Scrum Guide 2013 os itens que compoẽm o Sprint Backlog são os que possuem maior transparência e detalhamento do Product Backlog, recebendo o nome de preparados.

  • Deveria estar errada por afirmar que Scrum é um método.

  • Ao meu ver, os itens do Sprint Backlog (SB) são baseados na Product Backlog (PB) mas eles trazem mais informações pois cada item da PB é quebrado em diferentes tarefas para ser colocado na SB. 

     

    SB = itens da PB quebrados em tarefas + itens (tarefas) adicionados ou removidos durante a sprint.

     

    A questão foi lançada como CORRETA mas depois foi anulada, acredito que seja por isso que falei acima.

     

    Fonte: https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog

     

  • Se está anulada, tira do site.

ID
784777
Banca
ESAF
Órgão
CGU
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

No Scrum os projetos são divididos em ciclos chamados de

Alternativas
Comentários
  • O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.
     
    Características:
    Scrum é um esqueleto de processo que contém grupos de práticas e papéis pré-definidos. Os principais papéis são:
    o ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto);
    o Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio;
    a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto, implementação, teste etc.
     
    Sprint (corrida)
    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" (ou seja, restrito a uma duração específica) de comprimento constante.
     
    http://pt.wikipedia.org/wiki/Scrum
  • Minha nossa, nunca vi uma questão tão ridícula elabora pela ESAF! 
ID
792430
Banca
ESAF
Órgão
Receita Federal
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Na metodologia Scrum de desenvolvimento ágil, as regras SMART significam

Alternativas
Comentários
  • S - (Specific) Específico
    M - (Measurable) Mensurável
    A - (Achievable) Realizáveis
    R - (Realistic) Realístico
    T - (Duração fixa) Time-based

  • Qual a fonte da informação ? pls.

  • Só achei em conjuntos de slides essa informação.

    No scrum guide não faz referência ao SMART.


    Fonte: http://pt.slideshare.net/powerirs/scrum-desenvolvimento-gil#btnNext

  • As regras SMART para verificar os objetivos dos stakeholders são:

    -Specific (específico): todos terão o mesmo entendimento a respeito dos objetivos
    -Measurable (mensurável): podemos determinar objetivamente se os objetivos foram alcançados.
    -Achievable (realizável): os clientes concordam sobre o que são os objetivos.
    -Realistic (realista): devemos ser capazes de realizar os objetivos do projeto com os recursos disponíveis.
    -Timed (cronometrado): prazos definidos para a realização dos objetivos são viáveis.
    Fonte: slides do prof. Márcio Victorino de ES do Cathedra.

  • M – Measurable (Mensurável)

    Vale repetir a famosa frase “Você não pode gerenciar o que não pode medir”.

    A – Attainable (Atingível)

    Os objetivos sempre devem ser agressivos, mas nunca impossíveis de atingir.

    R – Realistic (Realista)

    Muitas vezes o objetivo é possível, mas não é realista. 

    A equipe aceitará perseguir o objetivo?

    Este objetivo está alinhado com a missão e visão da organização?

    Algum princípio ético é ferido com este objetivo?

    T – Timely (Em Tempo)

    Esta característica se mistura um pouco com o S (específico). Significa que além do inicio e fim do período de busca do objetivo serem bem definidos, este período não deve ser tão curto que torne o objetivo impossível nem tão longo que cause uma dispersão da iniciativa com o tempo

ID
795151
Banca
FCC
Órgão
TST
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A Sprint é considerada o coração do Scrum. Uma nova Sprint inicia-se imediatamente após a conclusão da Sprint anterior. Durante a Sprint

Alternativas
Comentários
  • Em sprint, o staff cria partes do projeto, de acordo com o backlog (lista com os requerimentos).Encontros decidem quais partes do backlog vão p/ o sprint.O product owner é quem decide quais partes do backlog precisam ser completadas, e o staff (única entidade q pode mexer no backlog) se organiza p/ cumprir tal meta , a qual é timeboxed: tem que estar tudo pronto a tempo, geralmente 1 mês p/ 1 demo. Caso necessite d mais tempo, o próximo timebox comporta as questões pendentes do sprint atual.
  • O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
    As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a restrospectiva da Sprint.
    Durante a Sprint:
    ? Não são feitas mudanças que podem afetar o objetivo da Sprint;
    ? A composição da Equipe de Desenvolvimento permanecem constantes;
    ? As metas de qualidade não diminuem; e,
    ? O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.
    Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

    Fonte: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf
  • Solução: letra A.
    Segundo o Scrum Guide, a equipe de desenvolvimento pode colaborar com o Product Owner para negociar o escopo do backlog da Sprint dentro da Sprint. Durante essa fase a equipe tem em mente o objetivo ou meta da Sprint, implementando funcionalidades e tecnologias, porém, o trabalho pode ser diferente daquilo que foi planejado, nesse caso,  negociar o escopo do Backlog da Sprint com o Product Owner é necessário.

    As assertivas corretas são:
    a) O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.
    b) A composição da equipe de desenvolvimento permanece constante.
    c) As metas de qualidade não diminuem.
    d) Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês.
    e) Não são feitas mudanças que podem afetar o objetivo da Sprint;

  • a. correta

    b. A Equipe de Desenvolvimento é uma equipe estática, que não muda(ou muda em casos extremos e muito pouco)

    c. As metas não são reduzidas. Durante o planejamento da Sprint, a Equipe de Desenvolvimento planeja, somente ela, o que deve ser realizado na Sprint que está para iniciar. Dessa forma, definem as metas com base em suas competências.

    d. O time-box do Scrum não é flexível. E é, para menos e, apenas quando as Sprints são mais curtas que o provável.

    e. Não são permitidas mudanças. Caso raro, ocorre quando os objetivos da Sprint que está sendo realizada não é mais viável para o projeto em desenvolvimento. 

  • Do Scrum Guide 2013

    Durante a Sprint:

     Não são feitas mudanças que possam por em perigo o objetivo da Sprint;

     As metas de qualidade não diminuem; e,

     O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de  Desenvolvimento quanto mais for aprendido.




    Conforme o Time de Desenvolvimento trabalha, ele mantém o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam a funcionalidade e a tecnologia. Caso o  trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da  Sprint.


  • Sou fã do "pode ser"

ID
795163
Banca
FCC
Órgão
TST
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

O Scrum é fundamentado nas teorias empíricas de controle de processo (empirismo). A função de cada um dos três pilares que apoiam a implementação de controle de processo empírico está apresentada a seguir:


I. Se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, implicando que o produto resultante será inaceitável, o processo ou o material sendo produzido deve ser ajustado.


II. Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Isso requer que os aspectos sejam definidos por um padrão comum para os observadores compartilharem um mesmo entendimento do que está sendo visto.


III. Os artefatos Scrum e o progresso em direção ao objetivo devem ser frequentemente checados para detectar indesejáveis variações. Isso não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.


A associação correta do nome do pilar com a sua função está expressa em:

Alternativas
Comentários
  • Transparência
     
    Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.

    Por exemplo:
    Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e,
    Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.
     
     
    Inspeção
     
    Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. Esta inspeção,não deve no entanto, ser tão freqüente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
     
    Adaptação
    Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. 
     
    O Scrum prescreve quatro oportunidades formais para inspeção e adaptação, como descrito na seção Eventos do Scrum deste documento.
     Reunião de planejamento da Sprint
     Reunião diária(originária do Daily Scrum)
     Reunião de revisão da Sprint
     Retrospectiva da Sprint
     
     http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf
  • Para responder a questão, é necessário apenas conhecer os 3 pilares que são:
    Transparência para poder Inspecionar e se necessário Adaptar.

  • I. Se um ou mais aspectos de um processo desviou (adaptação) para fora dos limites aceitáveis, implicando que o produto resultante será inaceitável, o processo ou o material sendo produzido deve ser ajustado.


    II. Aspectos significativos do processo devem estar visíveis (transparência) aos responsáveis pelos resultados. Isso requer que os aspectos sejam definidos por um padrão comum para os observadores compartilharem um mesmo entendimento do que está sendo visto.


    III. Os artefatos Scrum e o progresso em direção ao objetivo devem ser frequentemente checados (inspeção) para detectar indesejáveis variações. Isso não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

  • Teoria do Scrum

    Scrum, que é fundamento na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos.


    O primeiro pilar é a transparência

    A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.


    O segundo pilar é a inspeção

    Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.


    O terceiro pilar é a adaptação

    Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o mterial sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

    Existem três pontos para inspeção e adaptação em Scrum. A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho. Além disso, as reuniões de Revisão da Sprint e de Planejamento da Sprint são utilizadas para inspecionar o progesso em direção à Meta da Versão para Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint. Finalmente, a Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

    http://www.scrumminas.com.br/SCRUM.aspx

  • Vide Guia do Scrum

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

  • ✅ Gabarito - D de Deus

    Questão dá pra acertar apenas por eliminação, basta ter atenção.

ID
804529
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que processo de software pode ser definido como um conjunto de atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas), julgue o  item  que se segue.

O framework scrum engloba conceitos como times scrum, eventos com duração fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração fixa: a reunião de planejamento da versão para entrega, a sprint, a reunião diária, a revisão da sprint e a retrospectiva da sprint.

Alternativas
Comentários

  • Planejamento da spring - 8 horas
    Spring - time-boxed de um mês ou menos.
    Reunião diária - 15 minutos
    Revisão da sprint - 4 horas
    Retrospectiva da sprint - 3 horas

  • O certo seria dizer que o time-boxed tem uma duração máxima fixada, pois dizer que a duração é fixa causa confusão ao conhecermos que um sprint dura em torno de 2 a 4 semanas, e nem sempre 30 dias fixo, como deixa a subentender a afirmativa.

     

    Mais um conceito do CESPE para nós gravarmos.

  • ✅ Gabarito - C de Cristo

    Resolvendo questões Cespe há uma máxima. Se o "erro" está escrachado, então pode marcar como certo. Se o erro está disfarçado, pode marcar errado.

    Parece que quando eles querem deixar uma alternativa certa, fazem de qualquer jeito, e quando querem deixá-la errada, então são mais atenciosos.

    Planejamento da sprint - 8 horas (considerando um Sprint de até 4 semanas)

    Revisão da sprint - 4 horas (considerando um Sprint de até 4 semanas)

    Retrospectiva da sprint - 3 horas (considerando um Sprint de até 4 semanas)

    Não é que sempre será de 8, 4 ou 3 horas, leva-se em conta o tamanho da sprint.

  • Ao meu ver, se a SPRINT pode durar de 2 até 4 semanas, a duração não é fixa.

ID
814240
Banca
FAPERP
Órgão
TJ-PB
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Baseado no de desenvolvimento ágil de software Scrum, assinale a alternativa que define o termo Sprint:

Alternativas
Comentários

  • Sprint – Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de 2 semanas, 3 ou 4 semanas, que é o Timebox das Sprints.

     

    Fonte: http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/

     

  • ✅ Gabarito - B

    Direto do guia scrum:

    "Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado".

ID
814243
Banca
FAPERP
Órgão
TJ-PB
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando os papéis contemplados no desenvolvimento de software Scrum, assinale a alternativa referente à denominação dada ao membro da equipe responsável por descrever os requisitos do cliente e priorizá-los no backlog do produto.

Alternativas
Comentários

  • Product Owner - Define a visão do produto. Para tanto, ele recolhe informações(requisitos) junto ao cliente, usuários finais, time, gerentes etc.

  • ✅ Gabarito - C de Cristo.

    Questão proibida de errar. Resolvível em no máximo 10 segundos. Terminou de ler o enunciado e já está soando na sua cabeça: PO.

ID
836563
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do processo de desenvolvimento de software, julgue os itens
subsequentes.

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

Alternativas
Comentários
  • O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. 
     
    As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazê-lo sob influência das partes interessadas, do Time ou do ScrumMaster. 
  • Scrum Guide 2011 em português.

  • 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.

  • Ó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

ID
836572
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do processo de desenvolvimento de software, julgue os itens
subsequentes.

Uma das atribuições do product owner, papel definido pelo Scrum, é a responsabilidade pelo gerenciamento do backlog. Tal atribuição pode ser delegada aos outros membros do time Scrum.

Alternativas
Comentários
  • Eu errei, porém, analisando melhor vi que não pode haver duas pessoas com o papel de product owner. Isto, porque é ele o responsável pelo ROI (Return on Investment) e além disso é quem ditará (dirá metas, objetivos, missão clara) como o time SCRUM deverá trabalhar dentro de um tempo determinado.

    Agora, poderá haver a substituição da pessoa caso o rendimento da equipe caia. Foi esse o ponto que eu acreditei ser correto para a questão e não o era.
  • O Guia do Scrum diz: "O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui: (...). O Product Owner pode fazer o trabalho acima, ou delegar para a Equipe de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos".

    A questão afirma que: "(...) a responsabilidade pelo gerenciamento do backlog pode ser delegada aos outros membros do time Scrum". A questão já está errada por afirmar que a responsabilidade pelo gerenciamento do backlog pode ser delegada. O Guia do Scrum diz que o gerenciamento pode ser delegado, não a responsabilidade. E a ressalva, ao final do paráfrafo, coaduna com o que foi dito, uma vez que - mesmo delegando o gerenciamento à Equipe de Desenvolvimento - a responsabilidade continua sendo do Product Owner.
  • Não dá pra saber se o "tal atribuição" se refere à "responsabilidade" ou a "gerenciamento", ficou ambíguo o 2º período da assertiva.

    Por isso a questão anulada pelo Cespe com a justificativa:

    94  - Deferido c/ anulação
    A redação do item prejudicou seu julgamento objetivo, motivo pelo qual se opta pela anulação do item.

    Fonte: http://goo.gl/8fVD7X

  • ? Clearly expressing Product Backlog items; ? Ordering the items in the Product Backlog to best achieve goals and missions; ? Optimizing the value of the work the Development Team performs; ? Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what

    the Scrum Team will work on next; and, ? Ensuring the Development Team understands items in the Product Backlog to the level

    needed.

    The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

  • qual atribuição?

ID
836575
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do processo de desenvolvimento de software, julgue os itens
subsequentes.

Uma sprint do Scrum tem duração prevista de 2 meses.

Alternativas
Comentários
  • A sprint é a iteração ou ciclo de desenvolvimento, que contém a reunião de planejamento, o trabalho de desenvolvimento propriamente dito, a reunião de revisão e a reunião de retrospectiva. Cada sprint tem uma meta bem definida, que determina o que é imprescindível que esteja pronto ao seu final. As sprints têm duração fixa de duas semanas a um mês e ocorrem uma atrás da outra.
  • Errado. Uma sprint deve ter uma duração de 2 a 4 semanas, segundo o SCRUM.
  • Ilustrando os prazos/fases do SCRUM:

    FONTE:http://www.methodsandtools.com/archive/archive.php?id=18

  • E eu errei pq li semanas e estava escrito meses... 


    Nessa eu não vacilo mais.....

  • scrum = 2 semanas

    FDD = 2 semanas

    crystal = 4 meses. 

  • ✅ Gabarito - E de Escovinha

    Atualmente, o guia não fala mas de 2 a 4 semanas.

    Segue do guia:

    "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."

ID
861496
Banca
CESPE / CEBRASPE
Órgão
TCE-ES
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de software, julgue os itens subsecutivos.

O Product Backlog, um dos artefatos utilizados na metodologia ágil denominada Scrum, constitui-se da lista priorizada de todos os requisitos do produto final.

Alternativas
Comentários
  • A questão está correta, apesar do peso que o termo "todos" colocou na assertiva.

    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
  • Muito estranho, se o Product Backlog pode crescer e mudar, então não possue todos os requisitos do produto final. Alguém explica?
  • Essa palavra todos me deixou com uma pulga atrás da orelha. Veja algumas definições de Product Backlog abaixo.

    The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product.
    http://www.mountaingoatsoftware.com/scrum/product-backlog

    The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format (See terminology below). The product backlog is the “What” that will be built, sorted in the relative order it should be built in
    http://en.wikipedia.org/wiki/Scrum_(development)#Product_Backlog
  • Pessoal, realmente o backlog do produto pode evoluir, porém em um dado momento ele conterá todas as características que o produto final terá.
    • PRODUCT BACKLOG: Lista ordenada por prioridades de tudo que é necessário para o produto, ou seja, uma lista de funcionalidades.
          Ele é um artefato DINÂMICO, ou seja, nunca está completo.
          A prioridade é de acordo com a vontade do cliente;
          Pode ser replanejado no início de cada sprint (Sprint Review);
          O DONO DESSE ARTEFATO É O PRODUCT OWNER.
  • Estranho pq neste artigo "XP e Scrum sob uma Abordagem Comparativa
    " eu encontrei isso....

    "No Scrum, as funcionalidades
    priorizadas no Product Backlog, as quais recebem a
    denominação de Sprint Backlog, são implementadas e
    testadas paralelamente. Isso ocorre no Sprint (período
    no qual ocorre o desenvolvimento)"

    Então estaria errada...
  • Seguindo a linha de raciocínio de vcs, praticamente todas as questões estarão erradas.

    PAREM COM ISSO.

    O que é Product Backlog?
    "É uma lista contendo todas as funcionalidades desejadas em um produto."

    PRONTO. Questão correta.
  • Concordo que a ideia geral da questão esteja correta, porém o uso do termos "requisitos" confunde um pouco e deixa a questão um tanto quanto imprecisa. Para mim a definição de requisito é muito mais forte que uma ideia.

    Segundo http://www.scrumalliance.org/pages/scrum_101:
    Product backlog: ordered list of ideas for the product

    Segundo IEEE Standar Glossary of Software Engineering Terminology (1990) in Software Requirements 2 (Karl E. Wiegers, 2009):
    requirement
    1. A condition or capability needed by a user to solve a problem or achieve an objective.
    2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification. or other formally imposed document.
    3. A documented representation of a condition or capability as in 1 or 2.
  • Product Backlog: TODAS as funcionalidades ou mudanças definidas para o produto, pelo Product Owner.
    Esta lista (funcionalidades e/ou mudanças) é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.

    Fonte: artigo “Scrum in Five Minutes“, criado pela SoftHouse.

  • Product Backlog: É uma lista priorizada de todos os requisitos necessários no produto.

    O Product Backlog é a origem única de todos os requisitos para qualquer mudança a ser feita no produto, e é mantido pelo Product Owner.

    O Product Backlog nunca está pronto. Uma vez que o Scrum aceita as mudanças, a cada ciclo de desenvolvimento, novos requisitos são descobertos, e esses devem ser incluídos no backlog de acordo com sua prioridade.

    Da mesma maneira, durante o ciclo de vida de um produto pode-se perceber que determinados itens do backlog deixaram de fazer sentido, não sendo mais necessários. Esses itens devem ser removidos do Product Backlog tão logo se perceba essa necessidade.

  • Segundo o Scrum Guide, o Backlog do Produto é uma lista ordenada de tudo o que deve ser necessário no produto, e é uma origem únic a dos requisitos para qualquer mudança a ser feita no produto. O Product Backolo e, geralmente, ordenado por valor, risco, prioridade e necessidade. Os itens do topo da lista ordenada do Backlog do produto determinam as atividades de desenvolvimento mais imediatas.

  • Se é o produto final, então são todos os requisitos mesmo. Não sei o que esta questão mediu, mas tudo bem.

ID
869497
Banca
VUNESP
Órgão
TJ-SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre as metodologias de desenvolvimento de software, pode-se citar a linha dos métodos ágeis. Assinale a alternativa que contém apenas métodos dessa linha.

Alternativas
Comentários

  • Questaão pra não zerar. 

  • Alternativa correta: LETRA C

ID
884956
Banca
CESPE / CEBRASPE
Órgão
ANP
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O desenvolvimento ágil de software é um conjunto de
metodologias de desenvolvimento de software. A respeito desse
tema, julgue os itens a seguir.

De acordo com a metodologia Scrum, a constituição ideal da equipe de desenvolvimento para que o trabalho se mantenha ágil deve ser de menos de três pessoas.

Alternativas
Comentários
  • "Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade"

    "    Havendo mais de nove integrantes é exigida muita coordenação."

    Fonte: Guia do Scrum  - Um guia definitivo para o Scrum:As regras do jogo. (Ken Schwaber e Jeff Sutherland)

    Sendo assim, o tamanho ideal para uma equipe de desenvolvimento seria entre 3 e 9 integrantes
  • Complementando:

    O PO (Product Owner) e o Scrum Master não podem estar incluídos nesta contagem, salvo se eles executarem o trabalho elencado no Backlog da Sprint.
  • Amigos, 
    tenho uma dúvida. Eu li uma vez e até coloquei nos meus resumos que o time seria Formado por 7 pessoas, podendo variar de  ±  2. 

  • Não... já está consolidado na doutrina que o mínimo é de 3 e o máximo de 9, podendo, em casos específicos, ultrapassar este último limite.

  • Team (equipe) "- + 03 até 09 pessoas", multifuncional, dedicação integral, auto-organizável (sem rótulos) e trocas só na mudança de sprints.

  • Pelo Scrum Guide: 3 a 9 pessoas

    Pela InfoQ:  7 +/- 2

  • Então,  pq está errado?????
  • Está errado pq a afirma considerada ideal. No scrum guide ele recomenda de 3 a 9 mas não afirma qual é o ideal.
  • Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. 

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

  • ✅ Gabarito - E de escovinha

    De acordo com o Guia Scrum:

    "Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade."

    "Havendo mais de nove integrantes é exigida muita coordenação".

    Em outras palavras, o Time de Desenvolvimento ideal está entre 3 e 9 integrantes.

ID
884965
Banca
CESPE / CEBRASPE
Órgão
ANP
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O desenvolvimento ágil de software é um conjunto de
metodologias de desenvolvimento de software. A respeito desse
tema, julgue os itens a seguir.

O ciclo de vida da metodologia Scrum se divide nas fases de pré-planejamento, desenvolvimento e pós-planejamento. O documento denominado product backlog é gerado na fase de desenvolvimento.

Alternativas
Comentários
  • O product backlog é gerado na fase de pré-planejamento.

    fonte: http://www.youtube.com/watch?v=nr95nzsGB8Y

  • O ciclo de vida da SCRUMé baseado em três fases principais, divididas em sub-fases:

    1) Pré-planejamento (Pre-game phase): os requisitossão descritos em um documento chamado backlog. Posteriormente eles são priorizadose são feitas estimativas de esforçopara o desenvolvimento de cada requisito. O planejamento inclui também, entre outras atividades, a definição da equipe de desenvolvimento, as ferramentasa serem usadas, os possíveis riscosdo projeto e as necessidades de treinamento. Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos requisitos descritos no backlog são identificadas, assim como seus possíveis riscos.

    2) Desenvolvimento (game phase): as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas durante o desenvolvimento. Ao invés de considerar essas variáveis apenas no início do projeto, como no caso das metodologias tradicionais, na SCRUM o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Nesta fase o software é desenvolvido em ciclos (sprints)em que novas funcionalidades são adicionadas. Cada um desses ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em seguida o projeto, implementação e testes. Cada um desses ciclos é planejado para durar de uma semana a um mês.

    3) Pós-planejamento (post-game phase):após a fase de desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração , testes finais e documentação.

  • Fonte http://www.devmedia.com.br/processos-ageis-para-desenvolvimento-de-software-parte-02/9209

  • Dividindo para conquistar:


    O ciclo de vida da metodologia Scrum se divide nas fases de pré-planejamento, desenvolvimento e pós-planejamento (Correto). O documento denominado product backlog é gerado na fase de desenvolvimento (Errado. Product backlog é gerado na fase de pré-planejamento/pre-game)


    Bons estudos!

ID
900379
Banca
IADES
Órgão
EBSERH
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O SCRUM trabalha com períodos definidos de tempo e, em cada período, uma determinada função deve ser desenvolvida. O nome dado a esse espaço de tempo é

Alternativas
Comentários

  • SPRINT
    •   São projetos divididos em ciclos, tipicamente, mensais.
    •   Representa m tempo definido dentro do qual um conjunto de atividades deve ser executado.
    •   Geralmente duram 2 a 4 semanas
    •   Dentro de uma Sprint, as metas não diminuem e não são feitas mudanças que possam afeitar o objetivo da Sprint.

    Fonte: Gabriel Pacheco

  • Esta e para não zerar a prova

  • ✅ Gabarito - D de Deus

    Questão proibida de errar.

ID
906340
Banca
FCC
Órgão
TRT - 9ª REGIÃO (PR)
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Os modelos de processos tradicionais surgiram em um cenário muito diferente do atual, baseado em mainframes e terminais remotos. Já os modelos de processos ágeis são adequados para situações atuais nas quais a mudança de requisitos é frequente. Dentre os modelos de processos ágeis mais comuns temos: Extreme Programming (XP), Scrum e Feature Driven Development (FDD).

Algumas das práticas e características desses modelos de processo são descritas a seguir:

I. Programação em pares, ou seja, a implementação do código é feita em dupla.

II. Desenvolvimento dividido em ciclos iterativos de até 30 dias chamados de sprints.

III. Faz uso do teste de unidades como sua tática de testes primária.

IV. A atividade de levantamento de requisitos conduz à criação de um conjunto de histórias de usuários.

V. O ciclo de vida é baseado em três fases: pre-game phase, game-phase, post-game phase.

VI. Tem como único artefato de projeto os cartões CRC.

VII. Realiza reuniões diárias de acompanhamento de aproximadamente 15 minutos.

VIII. Define seis marcos durante o projeto e a implementação de uma funcionalidade: walkthroughs do projeto, projeto, inspeção do projeto, codificação, inspeção de código e progressão para construção.

IX. Os requisitos são descritos em um documento chamado backlog e são ordenados por prioridade.

A relação correta entre o modelo de processo ágil e a prática/característica é:

Alternativas
Comentários
  • Referente ao item V, o manual oficial do scrum não fala sobre este tal ciclo de vida em três fases, porém pesquisando encontrei o seguinte artigo http://dc471.4shared.com/doc/vVNfxCWW/preview.html que mostra que a afirmação está correta

  • IV. A atividade de levantamento de requisitos conduz à criação de um conjunto de histórias de usuários.

    Essa não é a definição de product backlog do scrum (o conjunto de histórias do usuários)? 

    Os itens II,V,VII e IX são definitivamente scrum, mas para mim o IV também. Se alguém puder tirar a dúvida fico grato.

  • "Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc. However, these XP practices can be used if the team thinks they are appropriate."

    (Fonte: Livro Engenharia de software, 9 ed, pag 74)

    Então Kaio, o Scrum não diz como você escreve seus requisitos. Você poderia escrever na forma de história do usuário, caso de uso, texto etc. Por outro lado, escrever requisitos na forma de histórias é listada como uma das práticas primárias do XP. (http://desenvolvimentoagil.com.br/xp/praticas/historias)

  • Sobre o item V, encontrei essa explicação: http://www.scrummethodology.org/scrum-phases.html

  • Questão meio mal elaborada. Bastava saber que o item II é do Scrum e matava a questão.

  • b

    palavras-chave que definem cada uma das metodlogias:

    XP - pair programming, testes escritos antes do codigo

    scrum - backlog (requisitos do cliente), sprints (ciclos), scrum team (product owner, equipe desenvolvimento, scrum master).

    fdd - features, 2 semanas, planejamento,cronograma, monitoramento, implementação por features.

  • Robson Gomes, na vdd bastava saber o item  I 

  • Questão pra tirar tempo do candidato. Se souber a I já mata.

  • Questão só pra assustar, só precisa ler 3 palavras

ID
943267
Banca
CESPE / CEBRASPE
Órgão
INPI
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a Scrum e eXtremme Programming (XP), julgue o item abaixo.

No Scrum, o Product Owner (PO) é responsável por definir a visão do produto e remover os impedimentos, enquanto o Scrum Master (SM) é responsável por elaborar e manter o Product Backlog, bem como por ajudar o PO a executar suas atividades diárias.

Alternativas
Comentários
  • O Scrum Master  (SM) é responsável por  remover os impedimentos

    De acordo com o Mike Cohn, autor do livro “Agile Estimating and Planning”, o Scrum Master é:
     
    …responsável por garantir que o time Scrum vivencia os valores e práticas do Scrum. O ScrumMaster protege o time, se certificando que eles não se comprometam com mais itens de backlog do que eles podem entregar em uma Sprint. O ScrumMaster facilita a reunião de Daily Scrum, e é responsável por remover quaisquer obstáculos que são levantados pelo time durante essas reuniões. O papel de ScrumMaster é tipicamente preenchido por um gerente de projetos ou líder técnico, mas pode ser qualquer pessoa.
     
    Em adição, o Scrum Master é responsável pela qualidade do trabalho do time.
     
    Em tempo, o Product Owner é:
     
    … (tipicamente alguém da área de Marketing ou um usuário chave no desenvolvimento interno) responsável por priorizar o Product Backlog. O time Scrum olha para o product backlog priorizado, e puxa as fatias mais altas do mesmo, os itens mais prioritários, e se compromete à entregar os mesmos durante uma Sprint. Estes itens viram o Sprint Backlog. Em retorno pelo seu comprometimento em entregar as tarefas selecionadas completas (as quais, por definição, são as mais importantes para o Product Owner), o P.O. se compromete que ele ou ela não vai trazer novos requisitos para o time durante a Sprint. Requisitos podem mudar (e a mudança é encorajada) mas somente os requisitos do product backlog, que não estão na Sprint. Uma vez que o time começou numa Sprint, ele se mantém completamente focado em entregar o objetivo daquela Sprint.
  • remover impedimentos é Scrum Master

  • conceitos trocados

  • ERRADO!

    Product Owner (OP): Pessoa responsável por gerenciar o backlog do produto (garantindo que esteja visível para todos ), priorizando os resultados que trarão maior valor agregado ao projeto.

    Scrum Master: Responsável por implementar o método SCRUM assim como por ensiná-lo a todos os envolvidos nos projetos e assegurar que todos sigam as suas regras e práticas. Ele atua como MEDIADOR entre a equipe e qualquer influência desestabilizadora.


    Fonte:

    Implantando a Governança de Ti - da Estratégia À Gestão Dos Processos e Serviços - 3ª Ed.

    ARAGON


  • O PO define a visão do produto que representa sua necessidade, é o que deve ser satisfeito no fim do projeto;elaborar e manter o Product Backlog (O conteúdo desta lista é definido pelo Product Owner.)

    Scrum Master: remover os impedimentos;ajuda o PO a executar suas atividades diárias;


  • No Scrum, o Scrum Master (SM) é responsável por definir a visão do produto e remover os impedimentos, enquanto o Product Owner (PO) é responsável por elaborar e manter o Product Backlog /  Scrum Master (SM) - é bem como por ajudar o PO a executar suas atividades diárias.

  • ✅ Gabarito - E de escovinha

    Parei de ler quando falou que o PO "remove os impedimentos".

    Atribuição de SM.

  • Serviços do Mestre Scrum para o Dono do Produto.

    Garantir que as METAS, o ESCOPO e o DOMÍNIO DE PRODUTO foram entendidos por todo o Time Scrum tão bem quanto possível.

    Encontrar técnicas para o efetivo Backlog Produto.

    AjudandAR o Time Scrum a entender a necessidade de ter claro e conciso a síntese dos itens do Backlog de produto.

    Entender o planejamento de produto para o ambiente empírito (direcionado a experimentos e experiências.

    Garantir que o Dono de Produto sabe como organizar o Backlog do produto para maximizar valor para aumentar valor.

    Entender e praticar agilidade

    Facilitar os eventos Scrum assim que requisitados ou necessitados.

ID
946909
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, acerca de metodologias ágeis de desenvolvimento.

Scrum é um processo de desenvolvimento que tem como ponto de partida um conjunto de requisitos bem definidos.

Alternativas
Comentários
  • Marquei errado pela expressão: "... Um conjunto de requisitos bem definidos..""
    Acredito que o examinador quis dizer que o Scrum precisa de TODOS requisitos definidos

    Alguem mais?
  • As metodologias ágeis de gestão de projeto não estabelecem uma regra para o levantamento de requisitos no começo de cada iteração. De acordo com o SCRUM após as reuniões de Sprint Planning a equipe deve possuir um Sprint Backlog estimado e priorizado em conformidade com o que o Product Owner e a equipe do projeto acreditam que deve ser executado na Sprint atual. Durante essas reuniões, o time inteiro e o Product Owner são incitados a tirar dúvidas e levantar mais detalhes em relação a cada User Story que foi selecionada como escopo da Sprint, porém não há nenhuma recomendação sobre formas de propagar requisitos ou até mesmo descrevê-los.
  • Esse tal de CESPE é muito engraçado. Fiz uma prova de auditor de controle externo no TCEES e uma questão afirmava que o Product Backlog possuia todos os requisitos do sistema. Agora, esses senhores doutores em computação afirmam que os requisitos não são bem definidos. Ora, será que o CESPE está criando nova metodologia: CESPE agile? Afinal, o product backlog tem ou nao os requisitos por completo? Vou continuar seguindo a abordagem oficial, mesmo que o CESPE nao concorde. 
  • Marquei errado por causa da expressão: "Scrum é um processo"

    Logo pensei, Scrum é uma metodologia, o que, segundo bate um profº meu, são coisas distintas!
  • Scrum é um processo de desenvolvimento que tem como ponto de partida um conjunto de requisitos bem definidos.


    Segundo Ken Schwaber, Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para a criação de produtos.

    Scrum faz parte dos modelos ágeis que têm como características, a capacidade de se adaptar a mudanças de requisitos, de equipe e de tecnologia, ou seja, possui requisitos e prioridades instáveis; projeto e construção são realizados simultaneamente; e análise, projeto, implementação e testes não são previsíveis.

    Portanto, questão ERRADA.

  •    O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

       Scrum possui seu foco no gerenciamento de projeto da organização onde é dificil planejar à frente.

  • Processo pelo qual podem ser empregado  processos e técnicas variadas (trabalhar junto para alcançar um objetivo). 

    Não tem conjunto de requisitos bem definidos.


    Errado!

  • "Scrum é um processo de desenvolvimento que tem como ponto de partida um conjunto de requisitos bem definidos."

    De maneira literal, o Scrum não é um processo nem uma metodologia. É um framework de processos. Porém, não se pode marcar errada uma questão por causa dessas 'nomenclaturas'. Infelizmente, temos que aceitá-las.

    Segundo Kent Back, o Product Backlog é uma lista ordenada de tudo o que é necessário no produto. No product Backlog são colocados os requisitos e até mesmo outros artefatos (como Casos de Uso, por exemplo - mesmo que incomum) que são definidos pelo PO (Product Owner - que representa o cliente)

    Cada item (funcionalidades) do Product Backlog deve ter seu peso (prioridade) de acordo com a vontade do cliente (PO). 

    Só que, a questão está errada quando afirma que o Scrum tem como ponto de partida um conjunto de requisitos bem definidos.  O Product Backlog é um artefato dinâmico. Ele nunca está "congelado", nunca está "completo".

    O product backlog pode ser replanejado (repriorizado) no início de cada Sprint de acordo com a vontade do cliente. Então, não pode ter um conjunto de requisitos bem defindos.


  • Se não tem conjunto de requisitos definidos o que é o Product Backlog?? O que é o Sprint Backlog???

  • O que deve está bem definido são as atividades da sprint backlog. Essas precisam está detalhadas ao máximo para o desenvolvimento.

  • Concordo com Marcos!!

  • Segundo o Scrum Guide:

    Scrum È um FRAMEWORK ESTRUTURAL que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o inicio de 1990. Scrum NÃO é um PROCESSO OU TÉCNICA PARA CONSTRUIR PRODUTOS; em vez disso, é um framework dentro do qual VOCÊ PODE EMPREGAR vários processos ou técnicas. 
    Fala também que os REQUISITOS nunca param de mudar.Sendo assim, a questão está ERRADA do início ao fim.

  • Scrum não é um processo de desenvolvimento de software, mas sim um framework em que você pode aplicar processos ou técnicas. Outro erro é dizer "conjunto bem definido de requisitos" se isso fosse verdade não faria sentido o scrum ser adaptável a mudanças e usar a abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. A questão se refere ao modelo de processo em CASCATA e vou reescrever a questão como seria o CORRETO.


    O modelo em Cascata é um processo de desenvolvimento que tem como ponto de partida um conjunto de requisitos bem definidos. Isso é o certo.

  • Assertiva ERRADA. 


    Nenhum método ágil (XP, Scrum, Kanban, TDD, etc) partem de um conjunto de requisitos bem definidos. Você pode ter um ou outro requisito bem definido no começo, mas todos não. Não é atoa que são guias iterativos de desenvolvimento. 

  • mas não tem pelo menos parte dos requisitos definidos? vai começar a primeira sprint do projeto como? plantando bananas?

  • Só dele ser ÁGIL já se mata aquestão. Ágil não tem caracteristicas de ter requisitos bem definidos.

  • e-

    com agile (xp, scrum etc) os requisitos vao sendo refinidos á medida q o projeto progride

ID
966205
Banca
Marinha
Órgão
Quadro Técnico
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação aos modelos de desenvolvimento ágil, analise as características abaixo.
I - Engloba um conjunto de padrões de processos enfatizando prioridades de projeto, unidades de trabalho compartimentalizadas, comunicação e feedback freqüente por parte dos clientes.
II - Diariamente uma reunião curta (tipicamente de 15 minutos) é realizada para que os membros da equipe respondam a questões básicas, como: o que foi realizado desde a última reunião, quais obstáculos estão encontrando e o que planejam realizar até a próxima reunião.
III- Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo chamado sprint.

As características acima se referem à qual modelo de desenvolvimento ágil?

Alternativas
Comentários

  • É um framework de processo dentro do qual podem ser empregados processos e técnicas variadas.


    É possível adicionar papeis, artefatos atividades e "cerimônias" de acordo com a necessidade.

  • O Scrum é um método ágil, usada no gerenciamento de projeto,  que prioriza a entrega de maior valor de negócio no menor tempo.  É também um processo de software que contém um pacote com mais de 50 modelos de relatórios completos, 9 livros que indicam as melhores práticas no gerenciamento de projetos, 1 framework em software com ferramenta CASE para auxiliar os seus implementadores uma ferramenta de Gerenciamento de Projetos integrada ao pacote de escritório da sua organização?
    R: Não
    É um processo iterativo e incremental par ao desenvolvimento de produtos e gerenciamento de projetos.
    Está mais para um Framework do que para uma metodologia.
    O Scrum não te dirá o que fazer, apenas te dará transparência para enfrentar os desafios do dia , a decisão é tua.
    O Scrum permite a construção de software incrementalmente por meio de iterações curtas para promover visibilidade para o desenvolvimento e pressupõem equipes pequenas, requisitos pouco estáveis ou desconhecidos.
    Método ágil para gerenciamento de projetos baseado em times pequenos e auto-organizados.
    Apresenta forte visibilidade e rápida – adaptação e mudanças.
    O Rup é centrado em arquiteturas e negócio o scrum é centrado em valores, entregas reais de produtos.
    Interativo para garantir inspeção e adaptação produto e incremental para garantir.
    “Estamos descobrindo melhores maneiras de desenvolver software, fazendo – o e ajudando outros a fazê-lo.”
    Ao longo deste trabalho, começamos a valorizar:
    •   Indivíduos e interações em vez de processos e ferramenta
    •   Software funcional em de doc extensiva
    •   Resposta à mudança em vez de seguimento de um plano.

    O SCRUM ESTRUTURA-SE SOBRE:
    •   Roles (Regras)
    •   Artefatos
    •   Atividades
    •   Papéis

    PRINCÍPIOS DO SCRUM
    •   Requisitos
    •   Análise
    •   Projeto  
    •   Evolução
    •   Entrega

ID
977434
Banca
CETRO
Órgão
ANVISA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Leia o parágrafo abaixo, relacionado à metodologia Scrum, e, em seguida, assinale a alternativa que preenche correta e respectivamente as lacunas.

É um(a) __________ dentro do(a) qual as pessoas podem tratar de problemas complexos e adaptativos e resolvê- los, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.
Fundamentado ___________ de controle de processo, o Scrum emprega uma abordagem __________ para aperfeiçoar a previsibilidade e o _______.

Alternativas
Comentários

  • Tirado do guia do Scrum 

    (https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese_European.pdf):

    "Scrum (n): é uma estrutura processual na qual as pessoas podem resolver complexos problemas 

    de adaptação, enquanto que, de forma produtiva e criativa, oferecem produtos de maior valor. "


    "O Scrum foi fundado com base na teoria empírica do processo de controlo, ou empirismo. O 

    empirismo afirma que o conhecimento vem da experiência e da tomada de decisão com base 

    naquilo que é verdadeiro e conhecido. O Scrum emprega uma abordagem iterativa e 

    incremental para otimizar a previsibilidade e controlo do risco. "



  • Só um detalhe: no enunciado cita "metodologia Scrum" mas o Guia Definitivo Scrum 2013 diz explicitamente que Scrum é um framework. No entanto, aparentemente, quase todas as bancas usam os termos "metodologia" ou "método"... 

  • ✅ Gabarito - E de escovinha

    Página 4 do Guia Scrum:

    "Teoria do Scrum

    Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos."

    Apenas com esses conceitos chaves daria pra resolver me medo de ser feliz.

ID
977704
Banca
FUNRIO
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre os princípios do método de desenvolvimento Scrum, que são consistentes com o manifesto ágil, julgue as seguintes afirmativas e assinale a alternativa correta.

I - Testes e documentação constantes são realizados à medida que o produto é construído.

II - O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos.

III - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes.

Alternativas
Comentários
  • Pressman 6ª Ed. página 69

    Princípios do Scrum

    - Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação e minimizar a supervisão
    - O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios
    - O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos
    - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento ou em pacotes.
    - Teste e documentação contantes
    - Fornece a habilidade de declarar o produto pronto sempre que necessário 

  • Manisfeto Ágil
    Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
    1.Indivíduos e interação entre eles mais que processos e ferramentas
    2.Software em funcionamento mais que documentação abrangente
    3.Colaboração com o cliente mais que negociação de contratos
    4.Responder a mudanças mais que seguir um plano
    Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

    Amigos, nas medologias ágeis, o mais importante não é o software rodando do que a documentação? Existe documentação, claro, mas muito pouca como em comparação ao RUP por exemplo. Por que o item I fala em documentação constante?


  • André,
     
    .Sim, o mais importante é o software rodando do que a documentação, entretanto a documentação não é negligenciada. É um contraponto aos modelos mais tradicionais que se preocupam demais em manter a documentação o mais completa possível ao invés de se preocupar com o que realmente tem de ser preocupado, que é o sistema rodando.

    . A documentação é constante, pois você não espera o sistema ficar pronto para documentá-lo, mas vai documentando no decorrer da construção e faz a entrega dessa documentação junto a entrega do software rodando, ou seja, você entrega a documentação completa daquela parte e para você entregar a documentação completa da parte que acabou de codificar a documentação foi elaborada de forma constante em conjunto com a documentação e até mesmos as demais etapas como arquitetura, testes, etc.. você sempre documenta, faz isso de forma constante.

    Entendeu ? qualquer dúvida diz ai.

    Abs.

     

  • Errei devi ao item 3 porem o vinicius sanou a duvida citando o Pressman. (melhor errar aqui que na prova) valeu

  • A questão deveria ser iniciada assim "De acordo com Pressman".

    Times de Desenvolvimento por Pressman

    "O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes. "

    De acordo com o Scrum Guide

    "Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios."

  • também errei pela questão 3 o vinicius sanou a duvida... vlw

  • André Veras ,

    Ter uma documentação constante não quer dizer que isso seja mais importante do que o software em funcionamento. A equipe pode ir fazendo, também, a documentação, entretanto, isso não é a principal atividade.

  • Alguém poderia me esclarecer melhor o item III? O que quer dizer pessoal de baixo acoplamento?

  • "Em pacotes" que deixou a questão III bem duvidosa. O SCRUM trabalha com Sprints

  • I - Testes e documentação constantes são realizados à medida que o produto é construído. 
    Para o Scrum, o próprio código é a documentação, por isso que ela é constante e realizados à medida que o produto é construído. Testes são importantes para verificar se as funcionalidades implantadas estão corretas e atingem os objetivos pretendidos.
    II - O processo produz frequentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos.

    III - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes. 

    Quando diz que o trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, quer dizer que o trabalho de desenvolvimento (sprints), depois que se inicia, não pode ser alterado, ou seja, seu escopo é claro (sprint backlog). Baixo acoplamento quer dizer que o pessoal não possui papéis definidos e eles são auto-organizáveis, ou seja, não há acoplamento, dependência nem com a sprint nem com o team scrum. Pacotes podem ser traduzidos em Sprints.

  • Não gostei do item III. O pessoal que realiza o desenvolvimento é dividido em partições claras??????

    Pior é, em uma divergência, a banca desconsiderar o Scrum Guide

  • ✅ Gabarito - D de Deus

    Item III - O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes.

    Pensei assim: "O trabalho de criar software e o pessoal (devs) que o realiza (realiza o quê? criar software) é dividido em partições claras (é divido em partes, que vem do Scrum, as Sprints > iteração > incremento). A gente pode pensar dessa forma, se vou gera incrementos, é interessante ter baixo acoplamento ou no mínimo estar em um modelo de pacotes.

ID
984634
Banca
CESPE / CEBRASPE
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

No que se refere às metodologias ágeis, julgue os próximos itens.


Na metodologia Scrum, a fase em que se integra o software, realizam-se os testes finais e gera-se a documentação do usuário é denominada pós-planejamento (post-game phase).

Alternativas
Comentários

  • O ciclo de vida da SCRUM é baseado em três fases principais, divididas em sub-fases:

    Pré-planejamento (Pre-game phase): os requisitos são descritos em um documento chamado backlog. Posteriormente eles são priorizados e são feitas estimativas de esforço para o desenvolvimento de cada requisito. O planejamento inclui também, entre outras atividades, a definição da equipe de desenvolvimento, as ferramentas a serem usadas, os possíveis riscos do projeto e as necessidades de treinamento. Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos requisitos descritos no backlog são identificadas, assim como seus possíveis riscos.

    Desenvolvimento (game phase): as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas durante o desenvolvimento. Ao invés de considerar essas variáveis apenas no início do projeto, como no caso das metodologias tradicionais, na SCRUM o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Nesta fase o software é desenvolvido em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em seguida o projeto, implementação e testes. Cada um desses ciclos é planejado para durar de uma semana a um mês.

    Pós-planejamento (post-game phase): após a fase de desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração, testes finais e documentação.

    (Fonte: Processos Ágeis para desenvolvimento de Software – Parte 02 http://www.devmedia.com.br/processos-ageis-para-desenvolvimento-de-software-parte-02/9209)

    Gabarito "C".

  • pessoal, nunca vi essa definição em nenhum lugar. Ela não consta no scrum guide por exemplo.

    O comentário da colega Amanda é ótima e bem esclarecedor, mas alguém tem alguma outra referência? De preferência da Scrum alliance?

  • Isso que foi colocado aí não é oficial.
    É invenção de algum autor ou parece que o cespe pegou a questão do site devmedia. Será??!!!


    Não existe no Scrum Guide nada sobre isso.

  • Que susto, eu achando que eu fiquei doido...


    Pelos comentários dos colegas, não estou tão louco assim...

    Acho que a Amanda que elaborou essa questão para o CESPE....

  • The postgame phase (closure phase)

    The management ends the development process and the product is being prepared for a release. This includes: integration, testing, user documentation, training and marketing material preparation. 

    As we can see the Scrum methodology is very well organized and very effective. What is also worth mentioning is that the whole Scrum process is limited in time. If the time of the sprint has ended the process has to be stopped. It makes the process more resolute , people work at the most important things and don’t waste their time.


    http://scrummethodology-org.etltools.net/scrum-phases.html

ID
984640
Banca
CESPE / CEBRASPE
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

No que se refere às metodologias ágeis, julgue os próximos itens.


A metodologia Scrum é uma forma de trabalho rígida empregada em ambientes organizacionais departamentais e conservadores

Alternativas
Comentários

  • Com o Scrum, os projetos não têm escopo rígido e cada etapa é construída de forma evolutiva,com cliente e fornecedor atuando conjuntamente.

  • São três as ideias principais em que a metodologia Scrum se ampara:

    • Transparência;
    • Inspeção;
    • Adaptação.


    Leia mais em: Desenvolvimento ágil com Scrum: uma visão geral http://www.devmedia.com.br/desenvolvimento-agil-com-scrum-uma-visao-geral/26343#ixzz3kFIaqANd

ID
984676
Banca
CESPE / CEBRASPE
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação às metodologias ágeis de desenvolvimento, julgue os itens a seguir.


O Scrum diferencia-se do XP pela existência do papel de product owner (PO), tendo o Scrum master e o coach atribuições similares em uma equipe ágil de desenvolvimento.

Alternativas
Comentários

  • Embora em uma primeira vista pareçam similares, os papéis de SM e COACH são bem diferentes. O Scrum Master é um cara mais focado em disseminar o processo Scrum, facilitando o acontecimentos de seus eventos, removendo impedimentos, etc. Ele não é um cara técnico, de mão na massa, na verdade é interessante que ele tenha as chamadas soft skills, que estão mais voltadas para relações interpessoais.

    O Coach do XP já se diferencia do SM por ser um cara mais técnico. Ele também vai ajudar o time na implantação do método ágil, porém ele pode sugerir mudanças, melhorias e inclusive pôr a mão na massa se for necessário. Diferente do SM, o coach é uma espécie de líder técnico da equipe.

  • Coach:

    Responsável pelas questõestécnicas do projeto de software. O coach deve possuir grande conhecimento emtodas as fases do XP e conhecer bem os membros da equipe. É o responsável porestimular a equipe a dar o melhor sempre que possível. Ao conhecer e aplicar osconceitos de XP, o coach deve estar apto para sinalizar a sua equipe os erros cometidosao longo do projeto e dar os passos necessários para consertá-los.

    Scrum Master:

    É o responsável porproteger os membros da equipe de desenvolvimento de qualquer pressão ou ameaçaexterna, seja isto clientes esbravejantes, diretores da empresa insatisfeitosou qualquer outra coisa que seja considerado “perigoso” para a produtividade daequipe. Tenta garantir que todas as práticas do Scrum sejam utilizadas com perfeiçãopela equipe. Assim como também tem um papel de facilitador nas reuniões daSprint. Normalmente assumem esse papel os gerentes de projeto ou líder técnico,mas na prática pode ser assumido por qualquer um com experiência o suficientena metodologia.


  • XP = O cliente é o maior interessado no software que esta sendo desenvolvido, além de ser a fonte de informações que a equipe precisa para desenvolver a melhor solução. Por isso, a sua presença junto ao desenvolvimento é muito importante afinal, o objetivo do projeto é que o sistema realmente o atenda.

    product owner (PO) também pode ser o cliente.

    Marquei (E) devido " O Scrum diferencia-se do XP "

ID
992035
Banca
FCC
Órgão
TRT - 12ª Região (SC)
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

SCRUM é um framework baseado no modelo ágil. No SCRUM,

Alternativas
Comentários
  • O Time Scrum é composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master.

    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;
    • Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
    • Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
    • Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
  • a) ERRADA - não necessariamente a equipe deve estar dividida em analista, designer e programador.
    b) ERRADA - o correto seria Sprint Backlog.
    c) ERRADA - SC não é gerente de projetos. Ele é apenas um facilitador para que a sprint possa ocorrer bem, blindando a equipe de desenvolvimento de problemas externos. Ele não decide os requisitos mais importantes (é papel do PO).
    d) ERRADA - o correto seria um prazo entre 2 a 4 semanas.
    e) CORRETA.

  • Só uma pequena correção ao comentário do Silas, no item B não é sprint backlog e sim product backlog. O sprint backlog é o conjunto de histórias explodidas em tarefas a serem executadas em cada sprint. O item B se refere a lista de histórias a serem implementadas no projeto não na sprint, então é product backlog.

  • Item c :


    Scrum Master Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva.

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

  • product owner não seria o próprio cliente ? 

  • Não  marcelo.

    Product Owner

    • Define os requisitos do produto, decide a data de release e o que deve conter nela.
    • É responsável pelo retorno financeiro (ROI) do produto.
    • Prioriza os requisitos de acordo com o seu valor de mercado.
    • Pode mudar os requisitos e prioridades a cada Sprint.
    • Aceita ou rejeita o resultado de cada Sprint.


  • a.o Scum Team é composto pelo Producto Owner, o Time de Desenvolvimento e o Scrum Master (variando de 5 a 7 pessoas (time) + Product Owner e Scrum Master)

    b. Essa lista é o Backlog do Produto e, depois de escolhidos os itens para a Sprint, haverá a formação do Backlog da Sprint.

    c. o Scrum Master motiva o time de desenvolvimento, dando os entendimentos do Scrum.

    d. A Sprint, varia de 1 a 4 semanas (7 a 30 dias), geralmente.

    e. correta

  • Errado a letra C pois o Scrum Master não decide quais os requisitos mais imporatntes, mas sim o Product Owner!

ID
1029799
Banca
CESPE / CEBRASPE
Órgão
TCE-RO
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação às metodologias ágeis de desenvolvimento, julgue os itens subsequentes.

Na metodologia Scrum, a equipe trabalha nos processos e não há cargos na equipe. Como um dos papéis necessários, o Scrum master deve garantir que o processo seja entendido e atuar como facilitador para ajudar a equipe.

Alternativas
Comentários

  • Scrum é um framework de processos que contém grupos de práticas e papéis pré-definidos. Os principais papéis são:

    1. o ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto);
    2. o Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio;
    3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto, implementação, teste etc.

  • O Scrum Master

    O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. De maneira geral podemos dizer que compete a ele:

    -Ser responsável pela aplicação dos valores e práticas Scrum;

    -Remover obstáculos, facilita resultados;

    -Garantir a plena funcionalidade e produtividade da equipe;

    -Blindar a equipe contra interferência externas;


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


  • Lembrando que o Scrum Master não organiza o time, pois este é auto-organizável/gerenciável.  

  • Não há cargos e sim papéis.

ID
1042588
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação às abordagens de desenvolvimento de software, julgue os próximos itens.

Scrum é uma metodologia de desenvolvimento de software que possui entre os seus princípios a realização do trabalho em sprint. Nessa metodologia, o tempo da sprint é variável, o que a faz adaptar-se mais facilmente às mudanças que possam ocorrer.

Alternativas
Comentários
  • O erro aqui é afirmar que o tempo da sprint é variável, o tempo é fixo caso chegue uma mudança ela entrará em um novo sprint ou será implementada no sprint atual sem alterar o prazo para o fim do sprint que é geralmente de 7 a 30 dias.

  • Não entendi porque foi anulada. Alguém sabe?

  • Justificativa do cespe:

    "A redação do item causou ambiguidade em relação ao “tempo da sprint”, razão suficiente para sua anulação. "


    http://www.cespe.unb.br/concursos/MPU_13_2/arquivos/JUSTIFICATIVAS_DE_ALTERA____O_DE_GABARITO_MPU_PARA_P__GINA_DO_CESPE.PDF


  • Acho que realmente há ambiguidade. O tempo de um sprint é fixo, porém existe variação de tempo quando comparamos vários sprints de um projeto scrum.

  • Outro erro descarado é afirmar que o Scrum é uma metodologia de desenvolvimento de software. Na realidade ele se presta ao gerenciamento ágil de projetos de SW.

  • Não precisava ser anulada. Só de afirmar que "Scrum é uma metodologia" já colocaria a assertiva como ERRADA.

ID
1044145
Banca
CETRO
Órgão
ANVISA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

É correto afirmar que, de acordo com a definição oficial, o Scrum é um(a).

Alternativas
Comentários

  • Definição copiada do Guia Scrum:

    "Scrum é um framework estrutural que está sendo usada para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. 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. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las."

    (Fonte: Guia do Scrum, 2011, Ken Schwaber e Jeff Sutherland)

    Gabarito letra "A". Lembrando que apesar do guia jurar de pé junto que não se trata de um processo, a maioria das questões, artigos na internet, e diversos autores (inclusive o Pressman) considera o Scrum sendo um método/processo ágil. Mas a questão foi bem legal em deixar explícito que queria a definição oficial, então nessa questão vale o que tá no guia.

  • a-

    É um framework agile para processos de software, embora seja possivel usar os metodos agile para outras áreas.

  • ✅ Gabarito - A de austeridade

    Parece que o elaborador dessa questão era um concursei que sempre levantou a bandeira "SCRUM NÃO É MOTODOLOGIA É UM FRAMEWORK!"

    CTRL+C CTRL+V do guia.

ID
1044148
Banca
CETRO
Órgão
ANVISA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto à metodologia Scrum e no que diz respeito às características das Equipes de Desenvolvimento, é incorreto afirmar que:

Alternativas
Comentários

  • 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 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. 

    (Fonte: Guia do Scrum, 2011, Ken Schwaber e Jeff Sutherland)

    Logo, a única errada é a letra "E". Esquipes de Desenvolvimento Scrum não possuem subequipes dedicadas.

  • 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 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. 

     

    (Fonte: Guia do Scrum, 2011, Ken Schwaber e Jeff Sutherland)

  • e-

    Se são auto-organizadas e multifuncionais, nao ha porque haver subequipes. Quem delega é o scrum master

ID
1055344
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto à gestão ágil de projetos com Scrum e às noções gerais de DevOps, julgue os itens subsecutivos.

Integração contínua, entrega contínua, teste contínuo, monitoramento contínuo e feedback são algumas práticas do DevOps.

Alternativas
Comentários

  • DevOps (amálgama de Desenvolvedor e Operador) é uma metodologia de desenvolvimento de software que explora a comunicação, colaboração e integração entre desenvolvedores de software e profissionais de TI (Tecnologia da Informação). DevOps é a reação à interdependência entre desenvolvimento de software e operações de TI. Pretende ajudar organizações a produzir software e serviços rapidamente.

    Empresas que liberam novas versões de software frequentemente podem precisar das considerações ou orientações de um DevOps. O Flickr desenvolveu capacidades de DevOps para suprir uma necessidade do negócio de realizar dez implementações por dia, este ciclo diário de implementações será muito maior em organizações que produzem aplicações multi-foco ou multi-funções. É conhecido como implementação contínua ou entrega contínua  e é frequentemente associado com a metodologia Lean Startup.Grupos de trabalho, associações de profissionais e blogs estão tratando do tema desde 2009

  • Integração contínua - agiliza o processo de geração das build's. 
    Entregra contínua - agiliza o processo de entrega das build's em um ambiente produtivo ou de homologação, dependendo de uma intervenção manual para enviar ou não para produção.
    Implantação contínua - envolve integração e entrega contínua, tudo automatizado entregando um build diretamente no ambiente de produção. 

  • 2016 - TRT

    Atividades típicas em DevOps compreendem teste do código automatizado, automação de fluxos de trabalho e da infraestrutura e requerem ambientes de desenvolvimento e produção idênticos.

  • As principais características do DevOps são: colaboração entre equipes; fim de divisões; relação saudável entre áreas; teste, integração e entrega contínuos; automação de deploy; controle e monitoração; gerenciamento de configuração; orquestração de serviços; avaliação de métricas e desempenho; logs e integração; velocidade de entrega; feedback intenso; e comunicação constante.

    FONTE: Estratégia Concursos

ID
1055347
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto à gestão ágil de projetos com Scrum e às noções gerais de DevOps, julgue os itens subsecutivos.

No Scrum, durante um script, mudanças que afetem o objetivo da Sprint podem ser realizadas somente se elas forem aprovadas pelo Product Owner e não acarretarem diminuição das metas de qualidade do produto.

Alternativas
Comentários

  • Durante a Sprint: Não são feitas mudanças que podem afetar o objetivo da Sprint; A composição da Equipe de Desenvolvimento permanecem constantes; As metas de qualidade não diminuem; e, O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.

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

    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. 


  • Acho que o erro é devido à palavra script. O certo seria sprint. 

ID
1055350
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto à gestão ágil de projetos com Scrum e às noções gerais de DevOps, julgue os itens subsecutivos.

O DevOps aplica abordagem ágil de desenvolvimento de software ao permitir que um negócio maximize a velocidade de entrega de um produto ou serviço.

Alternativas
Comentários

  • Não seria, Minimize a velocidade de entrega ?

  • Dyogo, eu acho que não. A ideia é aumentar a velocidade da entrega, ou seja, entregas mais rápidas.

  • Integração contínua - agiliza o processo de geração das build's. 
    Entregra contínua - agiliza o processo de entrega das build's em um ambiente produtivo ou de homologação, dependendo de uma intervenção manual para enviar ou não para produção.
    Implantação contínua - envolve integração e entrega contínua, tudo automatizado entregando um build diretamente no ambiente de produção. 

    Todos os processos acima são descritos na cultura DevOps. A ideia é maximizar a velocidade de entregas e com isso aumentar o retorno do investimento. 

  • É o negócio que maximiza a velocidade de entrega?

  • O negócio, por si só, não maximiza a velocidade de entrega. No entanto, quando falamos de uma cultura que provoca feedbacks do negócio, ou que permite que o negócio maximize a velocidade de entrega, estamos diante de uma nuance clara do manifesto ágil. Vale ressaltar que, nesse segundo caso, onde falamos da permissão ao negócio, é preciso que a cultura, para fins dessa análise, o DevOps, saiba como interpretar, ler ou receber feedbacks e tal permissão.

    A afirmativa diz que "o DevOps aplica abordagem ágil de desenvolvimento de software ao permitir que um negócio maximize a velocidade de entrega de um produto ou serviço." CERTO. Caso estivesse afirmando que "o DevOps" somente "aplica abordagem ágil de desenvolvimento de software ao permitir que um negócio maximize a velocidade de entrega de um produto ou serviço", estaria, a meu ver, ERRADO.


    Abs e todos e bons estudos.


    MRB

ID
1055542
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

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

Teste contínuo é uma prática do DevOps que, além de permitir a diminuição dos custos finais do teste, ajuda as equipes de desenvolvimento a balancear qualidade e velocidade.

Alternativas
Comentários

  • Teste contínuo - utilizando Maven para geração das buil's podemos configurar várias rotinas de testes unitários do JUnit, assim como testes de integração e funcionais com o uso de WebDriver (Selenium). O desenvolvedor não precisa ficar testando manualmente, automatiza todos os testes, dessa forma qualquer commit em um ambiente de integração irá executar uma bateria de testes, aumentando a qualidade dos incrementos e maior velocidade para entregar um "pronto". 

  • Testes,, as entregas contínuas permitem no DevOps reduzir os custos e tempo para galera do desenvolvimento.

ID
1055545
Banca
CESPE / CEBRASPE
Órgão
STF
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

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-box terminar, porém, a autoridade para cancelar é exclusiva do product owner.

Alternativas
Comentários

  • Questão "Correta". Essa definição consta no Guia:

    "O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. 

    Uma Sprint pode ser cancelada antes do time-box 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, da Equipe de Desenvolvimento ou do Scrum Master. 

    A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. 

    O cancelamentos de Sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns. "

    (Fonte: Guia do Scrum, 2011, Ken Schwaber e Jeff Sutherland)

  • Achava que depois da sprint, viria a revisão, e então outra reunião para definir o sprint backlog, retirado do product backlog ainda não feito. Portanto, ficou confusa essa afirmação.

  • Todos do time Scrum (menos o P.O, claro) + os stakeholders podem pedir o cancelamento da sprint. Porém a responsabilidade é exclusiva do P.O. Somente ele tem o poder para cancelar a sprint. Isso pode ser feito a qualquer tempo dentro do time-box.

  • essa questão é foda.. pq está expresso no guia: A new Sprint starts immediately after the conclusion of the previous Sprint.

     

    mas putttz.. bulll shiitt neh!!

     

    Tem o sprint review (apresentação do incremento), sprint retrospective (avaliação do processo), sprint planning da nova Sprint

    Mas enfim..

    no guia ele fala que esses eventos estão dentro da Sprint

     

    Sprints contain and consist of the Sprint Planning, Daily, Review e Retrospective

     

     

ID
1095994
Banca
CAIP-IMES
Órgão
Câmara Municipal de São Caetano do Sul - SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as afirmações abaixo.

I - 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 chamado sprint.

II - A Extreme Programming – XP emprega uma abordagem orientada a objetos como 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.

Pode-se afirmar que:

Alternativas
Comentários

  • I - 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 chamado sprint.

    Sprint não é uma medida de período? Alguém me explica porque esse item está correto?)

  • A I está certa porque é um copia e cola do Pressman: "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 chamados sprint. O trabalho realizado dentro da 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)

    Gabarito Letra "D".

  • Leia: Página 88 (Pressmann 7º Edição) e Página 95 (Pressman 7º Edição) e corra para o abraço.

ID
1112881
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O Scrum define reuniões e eventos que devem ser realizados de forma a oferecer oportunidades formais para inspeção e adaptação, cujos tempos de duração são referenciais máximos recomendados. Considere:


I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog do Produto, se necessário.

II. É uma reunião time-boxed de 3 horas para uma Sprint de um mês, sendo uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

III. É um evento time-boxed de 15 minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.

IV. É um time-box de 8 horas para uma Sprint de um mês de duração.

Estão de acordo com as definições I, II, III e IV, respectivamente, as denominações:

Alternativas
Comentários

  • Resposta: Letra B.

    Planejamento da Sprint: IV. É um time-box de 8 horas para uma Sprint de um mês de duração.

    Daily Scrum:  III. É um evento time-boxed de 15 minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.

    Revisão da Sprint:  I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog do Produto, se necessário.

    Retrospectiva da Sprint:  II. É uma reunião time-boxed de 3 horas para uma Sprint de um mês, sendo uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.


  • Só complementando em relação ao planejamento da Sprint.

    "A reunião de planejamento da Sprint é uma time-box de oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento deve ser proporcionalmente menor. Por exemplo, uma Sprint de duas semanas terá uma reunião de planejamento de Sprint de quatro horas."


    Fonte: Scrum Guide página 8


  • Reunião de Planejamento da Sprint

    O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Reunião de planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint de um mês de duração.Para Sprints menores, este evento é usualmente menor.


    Reunião Diária

    A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária.


    Revisão da Sprint

    Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor. 


    Retrospectiva da Sprint

    A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Para Sprint menores, este evento é usualmente menor. 

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

  • A redação do item I está muito esquisita, mas os outros não deixam dúvidas.

  • na revisão da sprint tbm dá pra fazer isso

     

    e eu sempre erro

     

    Time de desenvolvimento discute o que foi bom e os problemas que ocorreram

  • Bem, alguém "comeu" uma parte do texto do item I:

     

    Para uma coerência com a resposta gabarito, bem como para com os demais itens, uma boa proposta de redação seria:

     

    "É uma" reunião time-boxed de 4 horas para uma "Sprint de um mês, para inspecionar o incremento e adaptar o Backlog do Produto, se necessário".

  • Duração das cerimônias:

    Sprint Planning (Planejamento da Sprint) - 8h

    Daily Meeting  (Reunão Diária) - 15min

    Sprint Review (Revisão da Sprint) - 4h: É decidido se o o produto que o time de desenvolvimento fez está aprovado ou não.

    Sprint Retrospective (Retrospectica da Sprint) - 3h: O Team Scrum se auto avalia e estabelece melhorias. Não se avalia o produto.

     

    Geralmente as bancas tentam confundir essas ultimas duas. Mas com esse conceito básico dá pra matar a questão.

     

    Bons Estudos!

  • Sprint Review é focada no produto

    Sprint Retrospective é focado no processo

ID
1112884
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

No Scrum;

Alternativas
Comentários

  • Questão retirada do Guia Definitivo para o SCRUM.


    Link: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf

  • Questão tirada do Scrum Guide. Abaixo 
    Item A - Os de ordem mais alta precisam estarem mais claros e detalhados, pois elas que estarão mais próximas de serem implementadas.

    Item B - Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser resumido. Estas tem se provado úteis. Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que tem acontecido pode ser usado para uma tomada de decisão a respeito do que virá.

    Item C - OK

    Item D - O objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em relação as funcionalidades (não preciso) a serem implementadas dentro da Sprint.

    Conforme a Equipe de Desenvolvimento trabalha, ela mantém o objetivo em mente, e no caminho de buscar satisfazer o objetivo da Sprint, ela implementa a funcionalidade e a 
    tecnologia. Caso o trabalho acabe por ser diferente do esperado pela Equipe de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint.

    Item E - Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. O Scrum usa eventos time-boxed, onde todo evento tem uma duração máxima. Isto garante que uma quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de planejamento.

    Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente projetados (não é flexível) para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar.


  • No guia Scrum  está escrito:

    O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. 

    Substituir o "valor dos incrementos" por "tudo" é muita sacanagem...

  • questão bisonha -.-"

  • Letra A - ERRADA - Corrigindo: os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa; quanto maior a ordem na lista, maior são os detalhes. Os itens do Backlog do Produto são mais refinados apenas durante o time-box da Sprint, de onde saem “Prontos”. 
    - Houve uma inversão nos termos. 

    Letra B - ERRADA - O Scrum é baseado em teorias empíricas.

    Letra C - CORRETA - É o conceito de incremento que consta no manual do Scrum.

    Letra D - ERRADA - O product Owner pode negociar o escopo do Backlog da Sprint com o time de Desenvolvedores, sem nenhuma restrição.

    Letra E - ERRADA - A não inclusão dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar.

  • Achei a letra D mal formulada. O PO, normalmente, não pode negociar o escopo da sprint enquanto a sprint esta rodando. 

  • A Letra D não é tão difícil quanto vocês estão comentando. Devo lembrar a vocês que a "bíblia" do Scrum é o Scrum Guide que está disponível gratuitamente em português na internet.

    O primeiro erro foi: quem disse que o objetivo (ou meta) da Sprint fornece precisamente quais funcionalidades devem ser implementadas??? O guia fala: 

    "O objetivo da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro dos limites da Sprint."

    Ou seja, se dá flexibilidade, não "fornece precisamente". O foco desta letra está na palavra OBJETIVO! (no guia tem um tópico específico para os objetivos/metas da Sprint)
    O segundo ponto errado da questão é a possibilidade de se negociar o escopo da Sprint dentro da própria Sprint. 
    "Conforme o Time de Desenvolvimento trabalha, ele mantém o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam a funcionalidade e a tecnologia. Caso o trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint."
    É uma interpretação de texto sem o texto! Foco no Pressman, Sommerville e Guias Oficiais!

  • o incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e tudo das Sprints anteriores. Ao final da Sprint, um novo incremento deve estar “Pronto”, ou seja, estar na condição utilizável e atender a definição de “Pronto” do Time Scrum, independente do Product Owner decidir por liberá-lo realmente ou não.

    Esta parte final me deixou em dúvida.  Alguém pode comentar sobre?

  • ✅ Gabarito - C de Cristo

    Rapaz, a parte final me derrubou, sobre o "independente do Product Owner decidir por liberá-lo realmente ou não".

    Deve estar baseada nestes fragmentos do guia scrum:

    "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".

    "Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto".

    Acredito que seja por aí...

  • Tradução medonha usada na questão:

    André Gomes: Cada incremento é a soma de um novo incremento a todos os Incrementos anteriores completamente verificados, garantindo assim que todos os Incrementos funcionem juntos.

    SCRUM GUIDE 2020: Each Increment is additive to all prior Increments and thoroughly verified. (Cada incremento é aditivo a todos os incrementos anteriores, garantindo assim que todos os Incrementos funcionem juntos.)

    Bem, considerando a lógica da péssima tradução, se o incremento é por si só a soma dele com os incrementos anteriores (falta de completa de sentido lógico) deveriam então, é claro funcionarem juntos.

    É infeliz que uma banca utilize traduções mal feitas de guias estrangeiros, a alternativa é que o candidato se atenha a falhas contantes de algumas bancas e decorar os erros mais comuns, tentando nos recursos, algo em que não se pode confiar, ou mesmo ir à justiça, esperando que algumas começam a presar pela responsabilidade com o concurso e com o candidato.

ID
1112893
Banca
FCC
Órgão
AL-PE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Scrum e XP são duas metodologias ágeis que provêm práticas e regras que apresentam diferenças e também pontos em comum. Comparando-se estas metodologias, é correto afirmar:

Alternativas
Comentários

  • ERRADO em negrito   a) A XP enfatiza a proximidade física do cliente com a equipe de desenvolvimento para facilitar a comunicação. No Scrum existem diversos eventos formais, tais como sprint backlog meeting e product backlog review, que incentivam a comunicação entre todos os profissionais envolvidos no projeto.   Sprint review meeting    sprint planning meeting retrospective meeting   daily meeting
    ERRADO em negrito  b) As duas metodologias utilizam iterações curtas de desenvolvimento (sprints), mas divergem no tempo de duração das mesmas. Enquanto no Scrum uma sprint dura de 15 minutos a 8 horas, na XP costuma durar de 1 a 24 horas.
    Errado c) Tanto o Scrum quanto a XP explicitamente não permitem que ocorram mudanças de escopo ou definição dentro de uma sprint. Por isso o cliente deve validar todos os requisitos no início do projeto, isso vai contribuir para evitar atrasos e até mesmo construções erradas.   No SCRUm eh possivle renegocias escop durante a sprint
    CORRETA  d) A XP enfatiza que não se deve fazer horas extras constantemente e, se isso ocorrer, existem problemas no projeto que devem ser resolvidos não com aumento de horas, mas com melhor planejamento. O Scrum enfatiza que equipes auto- organizáveis escolhem qual a melhor forma para completarem seu trabalho.
    Errado em negrito e) O Scrum estabelece que os testes devem ocorrer o tempo todo durante o desenvolvimento, principalmente usando técnicas automatizadas. Na XP os testes podem ser realizados apenas na parte final de cada sprint, usando a técnica de refatoração, que busca validar todas as funcionalidades, pensando estrategicamente em como refatorar o código que está sendo implementado. refatorar eh otimizacao de codigo. os desenvolvedores fazem  continuamente testes unitarios e depois tem os testes de aceitação, desenvolvidos pelo cliente 

  • Na letra E não ocorreu troca de conceitos entre XP e Scrum?

ID
1115278
Banca
CESPE / CEBRASPE
Órgão
SUFRAMA
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

No que se refere às metodologias ágeis de desenvolvimento, julgue o próximo item.

Dentro de uma Sprint no Scrum, as metas de qualidade não diminuem e não são feitas mudanças que possam afetar o objetivo da Sprint.

Alternativas
Comentários
  • Copy and Paste do Guia:

    Durante a Sprint: 

    Não são feitas mudanças que podem afetar o objetivo da Sprint; 

     A composição da Equipe de Desenvolvimento permanecem constantes; 

    As metas de qualidade não diminuem; e, 

     O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido. 


  • O Scrum Guide traz uma redação um pouco diferente:

    "No changes are made that would endanger the Sprint Goal."

    A palavra "endanger" seria "por em risco", assim como colocado na tradução do Fábio Cruz ( www.fabiocruz.com ):

    "Durante a Sprint:
      - Não são feitas mudanças que possam por em perigo o objetivo da Sprint;"

    Entendo que "afetar" pode ser compreendido como "alterar", o que não necessariamente coloca em risco.



ID
1159357
Banca
FEPESE
Órgão
MPE-SC
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

SCRUM é um framework para gerenciar o desenvolvimento de produtos complexos.

Com relação a essa metodologia, assinale a alternativa correta.

Alternativas
Comentários

  • a) quem GERENCIA o backlog é o Product Owner e não o MASTER

    b) quem PRIORIZA o backlog é o Product Owner e não o MASTER

    c) SPRINT BACKLOG é a lista de tarefas a serem executadas no SPRINT atual e não do projeto todo.

    d) no início do projeto, o BACKLOG contém todas as funcionalidades desejadas para o sistema.

    e) CORRETA

  • Segundo Gabriel Pacheco do EU VOU PASSAR

    Uma equipe SCRUM é composta por um PRODUCT OWNER - SCRUM MASTER - TIME de Desenvolvimento

  • a) O Product Owner é o responsável primário pelo gerenciamento do Backlog do produto.

    b) O Product Owner é responsável por ordenar (priorizar) os itens do Backlog do Produto para alcançar melhor as metas e missões.

    c) O Product Backlog é uma lista de todas as tarefas que o Time de Desenvolvimento se compromete a fazer ao longo do desenvolvimento do produto.

  • O Sprint Backlog é uma lista de todas as tare- fas que o Time de Desenvolvimento se com- promete a fazer ao longo DE UM SPRINT.

ID
1159558
Banca
CESPE / CEBRASPE
Órgão
TJ-CE
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do SCRUM, assinale a opção correta.

Alternativas
Comentários

  • erros em negrito e comentarios entre ()

    Entre os objetivos da retrospectiva da sprint, inclui-se avaliar o desempenho de cada integrante da equipe de desenvolvimento. A retrospectiva da Sprint deve ocorrer antes (é depois) da revisão da Sprint, antes (é depois) da reunião de planejamento da próxima sprint e depois do término da sprint.


    Uma vez que as sprints no SCRUM são fixadas em uma time- box de um mês, as reuniões de planejamento das sprints seguem uma time-box de quatro horas. (8 horas no maximo)


    A reunião diária do SCRUM é um evento time-boxed de quinze minutos realizado para determinar o trabalho que deverá ser feito antes da próxima reunião diária com a participação do Scrum Master e do Product Owner. (ele nao participa)


    Como o cancelamento de uma sprint é um evento indesejado no SCRUM, esse evento só ocorre se o Scrum Master constatar que os objetivos pretendidos para tal Sprint são inalcançáveis. (pode haver desistencia tb)


    O Product Owner utiliza práticas de estimativa como o burndown e o burnup para acompanhar a quantidade de trabalho que a organização ainda deve realizar para alcançar os seus objetivos. Assim, se o propósito for garantir o alcance de objetivos, o trabalho poderá ser resumido em qualquer ponto do tempo. (questao certa)

  • Só corrigindo o bom comentário do Roberto Araújo , a retrospectiva da sprint ocorre Depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint

  • Achei estranho a 2a parte do item correto, mas faz sentido:

    "O Product Owner utiliza práticas de estimativa como o burndown e o burnup para acompanhar a quantidade de trabalho que a organização ainda deve realizar para alcançar os seus objetivos. Assim, se o propósito for garantir o alcance de objetivos, o trabalho poderá ser resumido em qualquer ponto do tempo.": Quando ele fala que o trabalho é resumido em qualquer ponto do tempo, ele fala que o PO pode ver o andamento do projeto olhando pro burndown ou o burnup...

  • que tradução porca que alguém fez do inglês na alternativa E. Traduzir "resume" para "resumido" é tarefa de quem não sabe o que está fazendo...

  • Só corrigindo.

    Uma vez que as sprints no SCRUM são fixadas em uma time- box de um mês, as reuniões de planejamento das sprints seguem uma time-box de quatro horas.

    Na verdade deveria ser assim.

    Caso as sprints no SCRUM sejam fixadas em uma time- box de um mês, as reuniões de planejamento das sprints seguem uma time-box de no máximo oito horas

    Reunião de planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. 

  • Quanto à letra C --> 

     

    O Scrum Master reforça a regra de que somente os integrantes do Time de Desenvolvimento participem da Reunião Diária. 

     

     

    no scrum guide só encontrei isso

     

    Various projective practices upon trending have been used to forecast progress, like burn- downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making. 

     

    Pra mim essas práticas (burndown e burnup) eram usadas pelo time de desenvolvimento!!!

     

    Mas blz, errei a questão

  • Pessoal esse "trabalho a organização ainda deve realizar" é a organização que realiza ou o time de desenvolvimento? É só uma duvida mesmo, pois errei por conta deste organização.

  • O PO pode participar sim das Daily Meetings

  •  a) ERRADO Entre os objetivos da retrospectiva da sprint, inclui-se avaliar o desempenho de cada integrante da equipe de desenvolvimento. A retrospectiva da Sprint deve ocorrer depois da revisão da Sprint, antes da reunião de planejamento da próxima sprint e depois do término da sprint.

     b) ERRADO Uma vez que as sprints no SCRUM são fixadas em uma time-box de um mês, as reuniões de planejamento das sprints seguem uma time-box de oito horas. 

     c) ERRADO A reunião diária do SCRUM é um evento time-boxed de quinze minutos realizado para determinar o trabalho que deverá ser feito antes da próxima reunião diária com a participação do Scrum Master e do Product Owner. (Em regra, ele não participa).

     d) ERRADO Como o cancelamento de uma sprint é um evento indesejado no SCRUM, esse evento só ocorre se o Product Owner constatar que os objetivos pretendidos para tal Sprint são inalcançáveis.

     e) CORRETO O Product Owner utiliza práticas de estimativa como o burndown e o burnup para acompanhar a quantidade de trabalho que a organização ainda deve realizar para alcançar os seus objetivos. Assim, se o propósito for garantir o alcance de objetivos, o trabalho poderá ser resumido em qualquer ponto do tempo.

    O gráfico burnup fornece informações sobre o status do projeto como um todo e não apenas do sprint, Já o gráfico burndown fornece informações sobre o status da sprint.

ID
1175968
Banca
CESPE / CEBRASPE
Órgão
TC-DF
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das metodologias de desenvolvimento de software, julgue os itens subsecutivos.

No Scrum, as funcionalidades contidas em um sprint são definidas pelo ProductOwner no ProductBacklog

Alternativas
Comentários

  • Eu entrei com recurso nessa questão, pois as funcionalidades contidades no no Sprint são definidas pela equipe.


    Sprint tem o sprintbacklog


    e o produto tem o ProductBackLog



    O item estava todo errada e esses fi$@$@#$ da p$@#$@# justificaram assim


    67

    C

    ‐

    Deferido com anulação

    A falta de precisão semântica na redação do item prejudicou seu julgamento objetivo. Por esse motivo, opta‐se por sua anulação


  • The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment. 





    The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. 




    As new work is required, the Development Team adds it to the Sprint Backlog.  




    O item estava errada e os caras anulam


    sacanagem

  • Motivo da anulação dado pelo Cespe: A falta de precisão semântica na redação do item prejudicou seu julgamento objetivo. Por esse motivo, opta-se por sua anulação.  

  • Para refletir:

    Quem monta o  product backlog?

    De onde a equipe tira as funcionalidades que serão desenvolvidas na sprint (sprint backlog)?

ID
1190260
Banca
FGV
Órgão
DPE-RJ
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das características da metodologia ágil Scrum é :

Alternativas
Comentários

  • a ) [incorreto] O Scrum não está "preso" a nenhuma prática de engenharia e sim dá a liberdade da equipe utilizar ou não alguma, logo não podemos dizer que esse é o foco do Scrum.
     

    b ) [incorreto] Sendo que o Scrum é uma metodologia ágil (como o XP) vale lembrar que é um dos princípios básicos do manifesto ágil, base para as metodologia ágeis: Software funcionando é mais importante do que documentação completa e detalhada. O foco não está na documentação.
     

    c) [correto] No Scrum o produto (sistema) é sempre incrementado, isto é, evolui ao longo das iterações que na metodologia é denominada de Sprit. 

     

    d) [incorreto] PMBOK é um guia de melhores práticas no gerenciamento de projetos. O Scrum é um Framework de aspectos gerenciais (as bancas o definem como metodologia ágil, mas esse conceito não é o mais correto). Remetendo o citado na alternativa "a" o Scrum não exige práticas de engenharia ou de guias e sim pode adotar métodos, guias e ferramentas para o melhor desenvolvimento do produto. Tais aspectos são definidos pela a equipe (Team).

     

    e) [incorreto] O cliente é fundamental. No Scrum é denominado de Product Owner.

     

  • Método? Estranho... "Scrum é um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos" (Guia Oficial Scrum 2013, pg. 3)

  •  c)ser um método iterativo e incremental. 

    Scrum é um framework que prioriza transparência, isnpeção, scrum team (product owner, development team, scrum master), auto-organização (equipes determinam proprias regras, sem influencia externa), & multifunção (as equipes possuem as habilidades para fazer sua parte, sem relações de dependencia).

  • Na alternativa 'c' quando diz 'método' pode induzir ao erro. pois Scrum não é um 'método' propriamente dito.

    O ideal seria "ser um framework interativo e incremental" ou simplismente omitir a palavra "método".

  • Prezados,

    Uma grande característica do Scrum é ser iterativo e incremental.
    Ele não necessariamente foca nas práticas de engenharia visto que não é uma metodologia própria para software, ele pode ser usado em outros projetos.
    Não foca na documentação formal do software e sim na entrega periódica de produtos.
    Não exige o planejamento do projeto de acordo com o PMBOK, e sim um product backlog, uma sprint backlog e as estórias de usuário.
    E o scrum exige sim uma alta interação com o cliente.


    Portanto a alternativa correta é a letra C

ID
1219891
Banca
FCC
Órgão
MPE-MA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação ao Scrum considere:

I. Refere-se às equipes de desenvolvimento.
II. Refere-se às sprints.

Assinale a alternativa em que as duas afirmativas sobre I e II são verdadeiras:

Alternativas
Comentários

  •  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. 

     

     

     

    Em uma equipe Scrum todos são "desenvolvedores", independente do que fazem.

     

    (Fonte: Guia do Scrum, 2011, Ken Schwaber e Jeff Sutherland)

  • Correto C.

    A letra B quase foi correta, faltou na opção II informar a Daily Scrum.

     

    Fortuna Audaces Sequitur

  • O comentário do Hélder Andrade está errado.

    O Correto é a letra D.

  • ✅ Gabarito - D de Deus!

    A)

    B)

    C)

    D)

    E)

    Estou editando só pra colocar isso: Passei um tempão comentando cada item pra aparecer as alternativas sem texto! kkkkk

ID
1225495
Banca
FCC
Órgão
MPE-CE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

O Scrum é um modelo ágil para a gestão de projeto de software. No Scrum,

Alternativas
Comentários

  • Deve ser por isso que o site disse Parabéns! Você acertou a questão! quando eu marquei a D...

  • Fiquei em dúvida entre a "A" e "D"

    O Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

    Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. 

    O erro da "A" foi afirmar sobre a necessidade da divisão da equipe em papéis como analista, designer e programador.

  • A scrum team não é formanda apenas pelos desenvolvedores, mas pelo conjunto (PO + SM + Dev).

  • a)  NECESSARIAMENTE, errado.

    b) NÃO SÃO AUTO ORGANIZADAS, errado.

    c) todo enunciado errado

    d) correta

     e) NÃO É RESPONSÁVEL PELO ROI, errado.

    o product owner define quais são os requisitos mais importantes a serem tratados em cada sprint, porém, não é o responsável pelo ROI (Return Of Investment), nem por avaliar as necessidades dos clientes.

  • De acordo com o Guia do Scrum:

    "O Scrum  não  reconhece  títulos  para  os  integrantes  do  Time  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." (p. 6)

     

  • a) equipe de desenvolvimento : 3 a 9 pessoas, não há divisão de papéis no time scrum

    b) as equipes são auto-organizáveis 

    c)o product backlog nunca estará completo

    d)certa

    e) é o responsável por avaliar as necessidades dos clientes

ID
1246570
Banca
UFMT
Órgão
UFMT
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

A coluna de números apresenta termos usados na Metodologia Scrum e a de parênteses, a caracterização de cada um. Numere a coluna de parênteses de acordo com a de númeors.

1 - Sprint
2 - Scrum Master
3 - Product Backlog
4 - Product Owner

(   ) Possui a atribuição de se responsabilizar pelo projeto, gerenciamento, controle e atualização das características e prioridades das ações no produto.
(   ) Possui a atribuição de vigiar a adoção das regras Scrum pela equipe e seus usos no projeto.
(  ) Possui todas as definições das características e prioridades do produto final.
(   ) Possui o conjunto de ações definidas para serem executadas num período de até 30 dias, tendo como resultado principal um produto funcional para o usuário.

Assinale a sequência correta.

Alternativas
ID
1256512
Banca
IDECAN
Órgão
AGU
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O Scrum engloba um padrão de processos enfatizando prioridades de projeto, unidades de trabalho compartimentalizadas, comunicação e feedback frequente por parte dos clientes. Enfatiza o uso de um conjunto de padrões de processo de software que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos mutáveis e críticos de negócio. "Não são introduzidos(as) durante execução de urgências (Sprint). Portanto, Sprint permite que os membros de uma equipe trabalhem em um ambiente de curto prazo, porém estável." Trata-se de

Alternativas
Comentários

  • Li 3x e não consegui entender. Qual era a pergunta afinal?

  • Essa questão parece que foi traduzida pelo Google! Hahaha. Que loucura. Só sei que não podem ser acrescentadas alterações durante uma Sprint. Portanto, letra E.

  • exatamente não conseguir entender... pqp banca do inferno.

  • O que a questão deseja saber é quais das opções  "...Não são introduzidos(as) durante execução de urgências ... "

  • Pessoal, a resposta (Letra E) é apenas a continuidade daquilo escrito no livro do Roger S. Pressman, página 95, conforme visto:


    Alterações (por exemplo, itens do registro de trabalho - backlog work itens) não são introduzidas durante execução de urgências (sprint). Portanto, o sprint permite que os membros de uma equipe trabalhem em um ambiente de curto prazo, porém estável.


    Infelizmente, a questão não mede conhecimento. Qualquer pessoa que tenha decorado este parágrafo "mataria" a questão. A banca apelou.


    Link: http://books.google.com.br/books?id=y0rH9wuXe68C&pg=PA95&lpg=PA95&dq=N%C3%A3o+s%C3%A3o+introduzidos(as)+durante+execu%C3%A7%C3%A3o+de+urg%C3%AAncias+(Sprint)&source=bl&ots=AyJgqNAeQT&sig=1kEJUNpOYH6Vq4aWg5WJyGIT9BA&hl=pt-BR&sa=X&ei=WWEfVJ76JrL7sATnnoG4Ag&ved=0CB8Q6AEwAA#v=onepage&q&f=false

  • Que questão é essa ?! Li várias vezes também e não consegui construir um raciocinio coerente para poder responder. Dá zero pra banca... rsrsrsrs

  • Cara, nem o dono do livro vai decorar qualquer coisa que seja. A chance é que temos esta em nosso banco de dados na hora de responder em papel no dia do concurso.

  • Olá, pessoal!

    Essa questão foi alterada. Os erros encontrados foram corrigidos. Conforme publicação no site da Banca.

    Bons estudos!
    Equipe Qconcursos.com

  • As alternativas d e e me parecem equivalentes. Qual a diferença?

  • Essa banca é uma comédia!

  • Li umas 3/4x pra entender que oque ele quer eh justamente saber oque NAO sao introduzidos no Sprint Backlog durante a execução de uma sprint, que no caso seriam alterações;

    Sprint nao aceita qualquer tipo de alteracao durante sua execucao

    Tudo sobre scrum e XP

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

  • A letra E é a mais clara e correta, mas desde quando Demos podem ser introduzidas durante a execução de Sprints? Até onde eu sei, Demos são feitas após a execução da Sprint junto ao Product Owner, no evento chamado Sprint Review. Estou errado? 

  • nem entendi a questão..kk


  • Também não consegui entender a questão.

  • essa questão é uma cópia do capitulo se metodologias ágeis que fala sobre o Scrum do livro do PRESSMAN ( o colega silas mais abaixo citou a página), vou tentar explicar a questão. Gente pegarei só esse pedaço da questão que é o de fato o que ele pede  "Não são introduzidos(as) durante execução de urgências (Sprint)". 

    Demo é introduzido em uma sprint? Claro, o demo nada mais é do que a DEMOnstração  do incremento produzido durante a sprint para que o cliente possa utilizá-lo e validá-lo.


    São introduzidas reuniões Scrum durante uma sprint? Com certeza, um exemplo disso são as Daily Scrum que acontecem todos os dias no mesmo local .


    Urgências também? Sim



    São introduzidos Registros pendentes de trabalhos (Backlg) isso é introduzido também em um sprint. COM CERTEZA, isso nada mais é do que o "TASK BOARD"  que é um quadro de tarefas em que você pode adicionar todos os tipos de colunas que forem necessárias e é usado assim que uma sprint é iniciada em que nesse quadro você pode visualizar as tarefas que ainda naõ foram iniciadas, o que já foi iniciado na sprint, as tarefas que já estão pronta e inclusive pode contem o gráfico Burndown. 



    Agora eu pergunto a você, uma sprint começou, está em andamento, você pode por alterações ? Tipo itens de registro backlog do trabalho? Gente claro que não, o guia deixa bem claro isso ao dizer que durante a Sprint: "não são feitas mudanças que possam por em perigo o objetivo da Sprint"; "as metas de qualidade não diminuem; e," .... (cont...).

  • A falta de fluidez textual de algumas questões elaboradas por essas bancas "menores", como Idecan, Consulplan e outras coisas do gênero é impressionante. Essa aí ela deve ter pegado lá no site do Zé Moleza.

     

    Desculpem, colegas, mas só zuando mesmo. Esse ano fiz a prova do TRF da 2ª Região, organizada pela Consulplan. Havia uma questão em que a alternativa gabarito possuía o comentário do examinador logo após o texto da assertiva. Foi inacreditável, mas acreditem: é verdade.

  • Colocaram uma capivara pra redigir essa questão?

  • Também não consegui entender a questão. kkkkkkkkk

  • Demos também não devem ser realizadas durante a Sprint (demonstrações de conteúdo). Urgência (corrida de curta distância não entendi- será que é ir ao banheiro no meio do expediente), excelente questão da banca Tabajara.

ID
1272094
Banca
MPE-RS
Órgão
MPE-RS
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que apresenta corretamente uma metodologia ágil para a gestão e planejamento de projetos de software.

Alternativas
Comentários

  • O SCRUM é considerado um framework com foco na gestão do desenvolvimento iterativo  e incremental. Por isso, pode ser utilizado de forma complementar com outras ferramentas de desenvolvimento, como o XP, por exemplo.

  • Desenvolvimento ágil" é o termo utilizado por diferentes metodologias e frameworks que desenvolvem software de forma iterativa e incremental. 
    Algumas são mais prescritivas ou menos mas as metodologias ágeis mais comuns são: Extreme Programming (XP), Scrum, Lean Development, Feature-Driven Development (FDD), Kanban, RUP e OpenUP.
    Pesquisas mostram que o Scrum é de longe o framework mais utilizado por ser o mais simples e de fácil adoção e adaptação.

     

    Fonte: www.ibm.com

  • 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 

  • RUP NÃO é uma metodologia ágil.

    RUP é um framework adaptável, para desenvolvimento de software, orientado a objetos.

     

ID
1282984
Banca
CESPE / CEBRASPE
Órgão
ANCINE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do Scrum e do XP (eXtreme Programming), julgue o item .


Na reunião de planejamento do sprint backlog, se o product owner afirmar que todos os requisitos do produto foram identificados, é correto concluir que o backlog do produto está completo, visto que este é uma lista ordenada de todos os requisitos necessários para o desenvolvimento do produto.

Alternativas
Comentários

  • Conforme o Scrum Guide - Scrum.org 10/2011


    "

    Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. 

    "


  • Lembre-se sempre: o Product Backlog é um documento VIVO! Isto é, está em constante mutação e existirá enquanto o produto exitir!


    Bons estudos!

  • Assertiva ERRADA. 


    O backlog nunca está completo pois, embora definidos todos os requisitos na reunião inicial, durante o desenvolvimento podem surgir requisitos novos ou os antigos podem precisar ser alterados. Sendo assim, ele nunca chega ao estado de "pronto". 

  • Pessoal, se eu tiver um produto, implementei TODOS os requisitos levantados, validei o produto com o cliente, NÃO foi visto nenhuma alteração, mesmo assim, o product backlog não estará completo? Não tem mais nada para fazer.

    *claro que é uma situação hipotética, mas a afirmação que NUNCA estará pronto, acho muito forte.

    valeu

  • Focado na missão, na teoria, teoria e prática são a mesma coisa, na prática não.

    Olhando friamente para o guia scrum, vimos que o backlog do produto é um artefato vivo. Os requisitos nunca são estáticos.

    ✅ Gabarito - E

ID
1282987
Banca
CESPE / CEBRASPE
Órgão
ANCINE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do Scrum e do XP (eXtreme Programming), julgue o  item.  

Se for averiguado, em uma organização, que o Scrum master gerencia o backlog do produto, é correto afirmar que houve falha na execução de papéis, visto que cabe unicamente ao product owner gerenciar o backlog do produto.

Alternativas
Comentários

  • Conforme o Scrum Guide - Scrum.org 10/2011


    "

    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;

    •   Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;

    •   Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o

      que o Time Scrum vai trabalhar a seguir; e,

    •   Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível

      necessário. 

    "

  • passível de anulação pois no enunciado cita "acerca de Scrum e XP", porém XP nao existe a figura de ScrumMaster e ProductOwner

  • Passível de recurso para mudança de gabarito, porque o gerenciamento do backlog pode ser delegado.

  • Tiago, agradeceria se pudesse citar uma fonte para sua afirmação.

     Até onde eu sei, o Product Backlog é de exclusividade do Product Owner. Não encontrei essa informação de que possa ser delegado.


    No Scrum Guide de 2013 diz o seguinte:

    "O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação."


  • Pagina 5 do Guia:


    Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:

    1 - Expressar claramente os itens do Backlog do Produto;

    2 -  Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;

    3 -  Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;

    4-  Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,

    5 - Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível

    necessário. 


    A Questão esta CORRETA, Contudo observem que há uma exceção (cascas de banana do cespe), que diz que o Product Owner poderá delegar o trabalho para o time de desenvolvimento e somente o time de desenvolvimento, mesmo assim, continua sendo o responsável pelos trabalhos.

    Conclusão: È o único responsável, porem pode delega para o time de Desenvolvimento.

  • De fato os papéis de Product Owner e de Scrum Master são diferentes, mas acho que um ponto fundamental da questão é que eles não devem ser acumulados. 

     

    O cenário ideal é que cada um dos três papéis sejam exercidos por pessoas diferentes, e que ainda se for pra alguém acumular a função de Scrum Master, creio que melhor que seja alguém da Equipe de Desenvolvimento que o Project Owner

     

    Agora entre não devem e não podem (em hipótese alguma) a ponto de se poder afirmar que houve falha na execução de papéis eu deixo isso a cargo do CESPE.

     

    Pessoalmente marquei C, mas com um certo medo.

     

  • responde esta então

     

    2015

    No desenvolvimento ágil de sistemas utilizando o Scrum, um integrante da equipe é encarregado de comunicar a visão, os objetivos e os itens do product backlog para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do product backlog. Esse integrante é o

     a) Product Owner, sob orientação do Scrum Master.

     b) próprio time de desenvolvimento, que realiza essas definições de forma auto-organizada.

     c) Scrum Master.

     d) Team Leader.

     e) Product Owner, diretamente.

     

     

     

    letra C

  • Vai entender, há questões do CESPE que respondi que afirmam que o SCRUM MASTER deve gerenciar o backlog do produto e agora outras que não...

ID
1282990
Banca
CESPE / CEBRASPE
Órgão
ANCINE
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do Scrum e do XP (eXtreme Programming), julgue o  item.  

No desenvolvimento de software conforme as diretivas do TDD (test-driven development), deve-se elaborar primeiramente os testes e, em seguida, escrever o código necessário para passar pelos testes.

Alternativas
Comentários

  • Ciclo de Desenvolvimento do TDD:

    1 Adicione um teste

    2 Execute todos os testes e veja se algum deles falha

    3 Escrever código

    4 Execute os testes automatizados e veja-os executarem com sucesso

    5 Refatorar código6 Repita tudo

  • Assertiva CORRETA. 


    No TDD os testes são escritos assim que se conhece um requisito. Conhecendo um requisito é possível saber como o software deve se comportar e assim se torna possível criar um teste que verifique se o software está se comportando como desejado. Por fim, escreve-se o código que tem como objetivo passar nesse teste. 

  • Test Driven Development (TDD) ou em português Desenvolvimento guiado por testes é uma técnica de  que se relaciona com o conceito de  e se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um  automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste !!

    Primeiro : conceito de  e se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um  automatizado

    Depois escreve o código..

    Não seria (E) ????

ID
1305088
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

Uma vez que o SCRUM não estabelece a programação em pares nem o desenvolvimento teste-primeiro (test-first), o XP pode ser usado em conjunto com o SCRUM em um projeto com a abordagem ágil.

Alternativas
Comentários

  • certinho, essas técnicas são pregadas pelo XP

  • Correto.


    O XP pode atuar bem em conjunto com o Scrum, pois quando o Scrum atuar com foco no gerenciamento do projeto, o XP pode atuar no processo de desenvolvimento.


  • a alternativa é correta, pois tanto XP quanto SCRUM são FRAMEWORKS DE BOAS PRÁTICAS (assim como o PMBOK) e não metodologias de desenvolvimento. Logo, pode-se elaborar uma metodologia que utilize práticas de ambos os frameworks. 

  • Confundi com o desenvolvimento em pares. É o XP 

  • Assertiva CORRETA. 


    XP foca na parte técnica do desenvolvimento e o SCRUM foca na parte gerencial, podendo ser usados para complementarem um ao outro. Como programação em pares e os testes são partes técnicas, o XP é quem lida com isso. 

  • c-

    programacao a 2 e tests antes sao tipicos do xp. o scrum usa pequenas equipes e funciona com sprints (iteracoes)

ID
1305091
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, a respeito das metodologias, dos processos e das práticas ágeis de desenvolvimento de software. Nesse sentido, considere que a sigla XP, sempre que empregada, refere-se a programação extrema.

O Scrummaster deve assumir a gerência de um projeto ágil com base no SCRUM, de modo a definir as prioridades para que a equipe entregue, primeiramente, os produtos de software que agreguem maior valor ao negócio do cliente.

Alternativas
Comentários

  • quem define o que será entregue é o PO

     

    2016

    A qualquer momento após o início do projeto, geralmente depois de analisar o retorno sobre o investimento e avaliar se um conjunto de funcionalidades já pode ser utilizado por clientes e usuários, o product owner pode decidir o tempo de entrega de uma versão.

    certa

     

    2016

    Normalmente, o time do projeto define quando a entrega de uma versão deve ser realizada após analisar o retorno sobre o investimento e avaliar se um conjunto de funcionalidades já pode ser utilizado por clientes e usuários.

    Errada

     

    2015

    Um projeto Scrum inicia-se com o Product Owner, que coleta informações dos stakeholders a fim de que seja elaborada uma lista de requisitos e de um backlog de produto.

    Certa

  • Product Owner (dono do produto)O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.


    http://pt.wikipedia.org/wiki/Scrum#Pap.C3.A9is_principais

  • Dizer que o scrumaster assume a gerência de projeto também é um erro, na minha opinião.

    Acho que já vi uma questão do cespe com essa afirmação e foi dada como errado.

  • SM não é GP.

  • Temos que o Product Owner é o dono do Produto. Quem define e prioriza  as funcionalidades de acordo com o valor para empresa é ele.

  • É um perigo confundir a função do Scrum Master com um Gerente de Projetos. Não são funções similares!

  • A assertiva está referindo-se na realidade ao P.O. - Product Owner ( Dono do Produto).

  • Dividindo para conquistar:


    O Scrummaster deve assumir a gerência de um projeto ágil com base no SCRUM (Errado. Não existe gerente de projeto no Scrum. As funções são distribuídas a cada projeto. É a velha história do boné - de desenvolvedor, testador, etc - que poderá ser redistribuído para os indivíduos em diferentes projetos), de modo a definir as prioridades para que a equipe entregue, primeiramente, os produtos de software que agreguem maior valor ao negócio do cliente (Errado. A priorização é feita pelo Product Owner na primeira etapa do planejamento do projeto)


    Bons estudos!

  • O inicio da questão quis confundir com o papel do Project Manager (gerente de projetos) do FDD (Feature Driven Development) que também é uma metodologia ágil em que esse papel que atua como gerente de projetos, um líder administrativo do projeto que vai planejar, elaborar relatórios e que pode atuar um pouco como scrum master. Então como os comentários citados dos colegas abaixo as funções do Project Manager e Scrum master são diferentes e a prioridade é definida pelo Product Owner (PO) 

  • Item errado, pois quem define a prioridade de itens do Product Backlog (refletindo diretamente nas funcionalidades que serão entregues) é o PRODUCT OWNER e não o SCRUM MASTER.

     

ID
1306591
Banca
CESPE / CEBRASPE
Órgão
ANATEL
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca dos processos de desenvolvimento de software, julgue o item subsequente.


O Scrum é um conjunto simples e eficaz de regras e ferramentas que são utilizadas para maximizar resultados. O ScrumMaster exerce o papel de facilitador e motivador da equipe, além de garantir que as regras e as ferramentas sejam utilizadas com vistas à criatividade do trabalho e ao retorno do investimento.

Alternativas
Comentários

  • Está errado! o Scrum é um processo de desenvolvimento iterativo e incremental para GP edesenvolvimento ágil de software. 

    E quem deve garantir o ROI é o Product Owner... o ScrumMaster exerce o papel de facilitador ok

  • Renato, o SCRUM nao é exclusivo para desenvolvimento de software. o SCRUM é uma estrutura processual ( framework) de gerenciamento de projetos  para entregar qualquer produto complexo nao somente  para desenvovler software (no framework utiliza conceitos relacionados a metodologia ágil (desenvolvimento rapido de incrementos de forma iterativa e incremental (incrementos e cada sprint eh uma iteração))) enquanto o XP é uma metodologia exclusiva de desenvolvimento de software 

  • Pensei do mesmo jeito que você, Renato Dias. Quem tem a papel de garantir o ROI e o Product Owner e não o ScrumMaster.
    Essa questão tinha que mudar o gabarito.

  • A questão apenas afirma que o ScrumMaster "...deve garantir que as regras e ferramentas sejam utilizadas...", ora, mas para qual propósito? "...com VISTAS à criatividade do trabalho e ao retorno do investimento ".

    Entendo que a questão não afirma que o objetivo do ScrumMaster seja garantir o retorno do investimento simplesmente!

  • Do que essa questão se refere quando ela usa a palavra "ferramentas"? O scrum não usa ferramentas, eu creio.

  • O Scrum define FERRAMENTAS? Eu entraria com recurso.

  • O Scrum NÃO prescreve ferramentas. Conforme o Guia Oficial do Scrum, não há o que se falar em ferramentas:

    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.

  • Scrum Master (Facilitador):

    Responsável pela aplicação dos valores e Práticas do Scrum;

    Remove Obstáculos e facilita resultados;

    Garante a plena funcionalidade e produtividade da equipe;

    Escudo para interferências externas.

  • Eu entraria com recurso!! Quem deve garantir o ROI é o Product Owner

  • A banca cespe se contradizendo. Assim fica dificil, mas se aparecer na minha prova eu marco certo. Eh eh questão estranha

  • Em primeiro lugar, vamos falar da "ferramenta". Todos concordamos que Scrum é um framework que segue as boas práticas do manifesto ágil, sendo considerado e usado como uma metodologia ágil.

    Se formos olhar lá no que o manifesto prega, podemos visualizar que: "Indivíduos e interação entre eles mais que processos e ferramentas". Ou seja, o Scrum Master não deve "garantir que as regras e as ferramentas sejam utilizadas" e sim que ele gerencie o uso do scrum de modo que o time de desenvolvimento não saia dos principios pregados pelo scrum. O Scrum Master gerencia o time, ele gerencia pessoas, ele garante que o time usará o scrum. Apenas isso.

    Quanto ao "ROI", está completamente errado! Pois o S.M ele apenas trabalha para aumentar, divulgar e planejar implementação do SCRUM dentro da organização. Sendo assim, ele não garante o ROI, quem garante, como já foi especificado, é o P.O.

    Quem estiver ainda com dúvida, visite o site do manifesto ágil: http://www.manifestoagil.com.br/

    Ou sobre o ROI, pode ser visto especificações das atribuições do Scrum Master para os projetos/organizações na página 7 do Scrum Guide.

    Espero que todas as dúvidas tenham sido tiradas. Não sei qual o gabarito, mas eu colocaria sem dúvidas como errada e ainda por cima, se fosse certa, entraria com recurso.

  • O Scrum Master garante que regras e ferramentas sejam utilizadas com vistas à criatividade do trabalho e ao retorno do investimento. A questão parece confusa porque o Product Owner é o encarregado de garantir o retorno do investimento. A questão não diz que o Scrum Master fica encarregado disto. Mas a utilização das regras e ferramentas pelo Time de Desenvolvimento, sob a liderança do Scrum Master, tem o objetivo de garantir a:
    1) a criatividade do trabalho
    2) e o retorno do investimento.

  • Mais uma questão do cespe na qual o examinador pode escolher tanto certo quanto errado. Espere que esse tipo de prova ( certo ou errado ) morra para sempre! rs

  • A questão cobra conhecimento sobre o framework Scrum.

    O Scrum é um framework leve e simples “dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível".  Ele é composto por times Scrum associados a papéis (Time de Desenvolvimento, Product Owner e Scrum Master), eventos (planejamento, revisão e retrospectiva da sprint etc), artefatos (backlog do produto etc) e regras [1].

    O modelo de time no Scrum como um todo “é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade". Dentro do time, o Scrum Master exerce papel de motivador e facilitador a partir do momento que exerce liderança e suporte ao time de desenvolvimento, ao Product Owner e à Organização. Ainda, ele é responsável por assegurar que o Scrum seja entendido e aplicado por todos para “garantir que o Time Scrum adere à teoria, práticas e regras do Scrum" [1].

    Assim, o Scrum-Master exerce esse papel de servo-líder almejando a entrega criativa de produtos com mais alto valor possível (retorno sobre o investimento). Cabe observar também que o Scrum Master ajuda todos (inclusive as partes externas) a mudarem as suas interações com o Time Scrum “para maximizar o valor criado pelo Time Scrum" [1]. Portanto, a questão está correta.

    Gabarito da professora: CERTO.



    Referência:

    [1] Ken Schwaber e Jeff Sutherland. Guia do Scrum - Um guia definitivo para o Scrum: As regras do Jogo.  2013. Disponível no site scrum guides.

ID
1309783
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o item a seguir, com base nos processos e nas práticas ágeis de desenvolvimento de software.


No SCRUM, cada ponto de história (PH) implica uma hora de trabalho de uma pessoa.

Alternativas
Comentários

  • Um ponto de história nada mais é do que uma unidade de tamanho, que faz sentido para o time Scrum e indica se a história é grande ou pequena.

    Por exemplo: uma história muito simples de ser implementada, para o time, poderá ter o tamanho 1. Consequentemente, uma história com o dobro de complexidade da primeira terá o tamanho 2.


    Leia mais em: Práticas e artefatos comumente utilizados com Scrum http://www.devmedia.com.br/praticas-e-artefatos-comumente-utilizados-com-scrum/27911#ixzz3GQFs1lpA

  • Os Pontos de História não possuem vinculação com tempo, eles possuem vinculação com o esforço.