2776621

INFO
STADISTICS
RECORDS
Title of test:
2776621

Description:
27766245

Author:
277621
(Other tests from this author)

Creation Date:
04/12/2018

Category:
Others
Click 'LIKE' to follow the bests test of daypo at facebook
Last comments
No comments about this test.
Content:
Um time Scrum recebeu a atribuição de um novo projeto e decide adicionar a seguinte Instrução à Definição de Finalizado: “Somente funcionalidades para os quais um design funcional tenha sido elaborado e aceito são inseridos no Backlog da Sprint”. O Scrum Master analisa isso e declara: “A documentação é necessária. Para cada funcionalidade o design deve ser criado ou atualizado." Por que o Scrum Master diz isso? Porque o cliente é valorizado em detrimento da documentação no desenvolvimento Ágil Porque a documentação pode ser criada e ajustada por funcionalidade Porque o Scrum Master sabe se o time tem tempo para implementar isso Porque o Backlog da Sprint fornece informações suficientes para fazer isso rapidamente.
Sua empresa está combinando práticas de Scrum com outro framework. Seu Time de Desenvolvimento trabalha em grande proximidade com outros departamentos. Quando algo dá errado, é fácil admitir que você causou o problema, porque sua empresa adota um ambiente onde não há repreensão. Que outro framework tem maior probabilidade de ser usado neste cenário? DevOps Lean Waterfall (Cascata).
Um novo cliente de sua empresa é cético sobre a abordagem Ágil. Ele acha que Projetos Ágeis são caóticos e está muito preocupado com o prazo. O cliente precisa do novo software em uma determinada data. Que recurso de Scrum pode dar ao cliente a confiança de que ele receberá o software no prazo combinado? Estimativa Ágil Planejamento Ágil Planejamento da Sprint Time-boxing.
Por que Ágil e ITIL apresentam boa integração? Ágil e ITIL têm princípios e componentes em comum, como inspeção e adaptação. O raciocínio do Ágil pode ser aplicado à maior parte do framework de ITIL para melhorar o sistema de Entrega do Serviço. Tanto o Ágil quanto ITIL consistem em frameworks abertos que são tecnicamente compatíveis O framework do Ágil é complementar à intenção do framework de ITIL.
Ao selecionar um Product Owner, existem algumas armadilhas comuns: • O Product Owner quer diminuir a qualidade de alguns requisitos para terminar no prazo. • O Product Owner faz parte de um time remoto e não tem contato direto com os Desenvolvedores. • O Product Owner pressiona demais o time, possivelmente causando esgotamentos. • O Product Owner delega a tomada de decisão (e então desconsidera o tomador de decisão). Uma destas armadilhas tem o potencial de entregar o trabalho com sucesso, desde que o Product Owner permaneça envolvido no projeto e estabeleça um bom relacionamento com o time. Qual cenário poderia levar ao sucesso? Delegar decisões Diminuir a qualidade Pressionar demais Time remoto.
Em um time de Scrum, qual responsabilidade pertence exclusivamente ao Product Owner? Comparecer a reuniões de Scrum Colaborar com o time Preparar o Backlog de Produto Garantir que o trabalho necessário seja realizado.
Um Product Owner sobrecarregado pode se transformar rapidamente em um ponto de gargalo e limitar o progresso do projeto. O que deve ser feito para evitar um Product Owner sobrecarregado? Criar um comitê de Product Owner. Liberar o Product Owner de todas as outras responsabilidades Introduzir um Product Owner substituto.
A CEO de uma pequena empresa assume o papel de Product Owner para um produto crítico para o negócio. Embora seja idealmente adequada para a função, ela tem dificuldade para passar tempo suficiente com o time. Uma outra pessoa do time atua como Product Owner substituto. O Product Owner substituto faz a maior parte do trabalho do Product Owner, sem ter o poder de decisão. Isto provoca uma diminuição da produtividade. Qual é a melhor solução para essa situação? Encontrar um novo Product Owner Liberar a Product Owner de outras obrigações Tratar uma questão sistêmica de modo superficial.
No Scrum, a Revisão da Sprint é um evento essencial para inspecionar e adaptar o produto. Para manter a Revisão da Sprint com valor e sem desperdício no processo, cada pessoa no Time de Scrum deve cumprir com seu papel definido. Qual das seguintes não é uma tarefa do Product Owner durante a Revisão da Sprint? Demonstrar quais Itens de Backlog de Produto estão “Prontos”. Discutir o Backlog de Produto em sua situação atual. Explicar quais Itens de Backlog de Produto não estão “Prontos”.
Você está trabalhando como gerente sênior na empresa SCR, um fornecedor de sistemas de software para controle de aviões. Você precisa indicar um Product Owner para um projeto futuro. Uma vez que o projeto requer conhecimentos específicos da área, você decide escolher um dos empregados atuais da empresa para este papel. Você deve escolher entre os seguintes candidatos: • John - um Product Owner experiente, que atualmente está gerenciando outros dois projetos críticos na sua empresa. • Peter - um Project Manager experiente, que sabe muito sobre desenvolvimento, mas não tem experiência na área de negócios. • Rosa - uma Business Line Owner que não tem experiência anterior em desenvolvimento, nem experiência como Product Owner. Com base nestas informações, quem seria o melhor candidato para a função de Product Owner? John, porque ele já tem experiência como Product Owner e este papel não permite o aprendizado durante o trabalho. Peter, porque o Product Owner precisa de experiência em codificação e desenvolvimento para gerenciar o time adequadamente. Rosa, porque ela tem conhecimento do negócio e, com o treinamento apropriado, poderia se tornar uma ótima Product Owner.
O Product Owner atribui tarefas aos desenvolvedores na Daily Scrum, e a reunião sempre dura mais de 15 minutos. Qual é a melhor resposta para o Scrum Master? Atribua as tarefas ao Time de Desenvolvimento, para que possam começar a trabalhar e a reunião permaneça dentro do tempo cronometrado de 15 minutos Convença o Product Owner a parar de atribuir tarefas ao Time de Desenvolvimento e a não participar das Dailys Scrum Não interfira nos argumentos e deixe que os membros do time auto-organizado resolvam esse problema sozinhos Explique ao Product Owner que as tarefas são atribuídas após a Daily Scrum, para que a reunião permaneça no tempo cronometrado de 15 minutos.
Cindy é uma Product Owner em uma empresa de software mobile. O Time de Scrum deveria entregar um software potencialmente utilizável no fim de cada Sprint. Quem pode dizer ao Time de Desenvolvimento como eles devem transformar o Backlog de Produto em Incrementos de funcionalidade potencialmente entregável? O Product Owner O gerente de projetos O Scrum Master Ninguém.
Sydney é um Product Owner em uma empresa de software de segurança. Já que ninguém pode prever o futuro, a melhor chance de sucesso consiste em conceber um produto que atenda às necessidades do cliente selecionado. Como esse produto é chamado? Produto de maior qualidade Produto mínimo comercializável Produto isolado Produto vencedor.
Esther, uma Product Owner para uma empresa de Desenvolvimento de Sistemas Incorporados, tem que escolher entre designs funcionalmente equivalentes. Ela seleciona o desenho mais simples para desenvolvimento. Que princípio Esther está seguindo? Just Enough Just-in-time Último momento responsável Navalha de Ockham.
Jeff é o Product Owner para uma empresa de computação na nuvem. A gerência quer que ele crie um Roadmap de Produto quando um novo produto for introduzido com sucesso no mercado. Jeff quer garantir que o Roadmap de Produto cubra um horizonte de planejamento realista. Que período ele deve enfocar? Os próximos 6 a 12 meses Os próximos 2 a 3 anos Os próximos 3 a 4 anos Os próximos 5 anos.
John é um Product Owner em uma empresa de software de mídia social. Sua empresa depende totalmente da intuição da gerência ou da habilidade técnica de seus desenvolvedores para criar novos produtos. Como é possível prevenir que apenas um grupo seleto de pessoas esteja trabalhando em inovação? Sendo muito crítico sobre a realização de investimentos à prova de falhas Criando produtos que sejam lançados com uma abundância de funcionalidades Envolvendo os clientes e usuários no processo de desenvolvimento.
Susan é uma Product Owner para uma empresa de Software de Relacionamentos com o Cliente. Três de seus clientes solicitam funcionalidades individuais que são incorporadas ao produto sem levar em conta a conexão entre eles. O resultado é um produto conhecido como sopa de recursos. Qual erro comum na criação de uma visão do produto é descrito aqui? Paralisia por análise Grande é bonito Sem Visão Visão Profética.
Leia a seguinte História de Usuário: Como digitador de dados, quero uma boa interface de usuário para a administração de faturas de clientes, para que eu possa trabalhar com rapidez. Esta História de Usuário está suficientemente completa para ser incluída no Backlog da Sprint? Não, porque a identidade do tipo de usuário não é suficientemente específica. Não, porque os termos “boa” e “com rapidez” não são suficientemente específicos. Sim, porque informações adicionais podem ser acrescentadas durante a Sprint. Sim, porque menciona a sintaxe completa de uma História de Usuário.
Uma agência de comunicação digital está desenvolvendo uma plataforma de viagem para um de seus clientes. O usuário da plataforma deve ser capaz de reservar passagens aéreas, quartos de hotel e aluguel de carros na mesma plataforma. As Histórias de Usuário são descobertas, decompostas e refinadas durante todo o projeto. Qual história pode ser identificada como um épico de História de Usuário? Como alguém que viaja a negócios, quero apenas ver os hotéis executivos disponíveis, para poder escolher um hotel de um modo rápido e eficiente. Como alguém que viaja a lazer, quero organizar toda a minha viagem em uma plataforma. Como alguém que viaja a lazer, quero escolher uma data fixa para meu voo, para poder começar a viajar assim que minhas férias começarem.
Um time de Scrum está criando um aplicativo para uma nova geração de refrigeradores. O usuário deve ser capaz de ativar os recursos usando um app de smartphone. O sistema deve responder em menos de dois segundos. Onde este requisito deve ser incluído ou incorporado? Definição de Pronto, uma vez que este é um requisito não funcional global Definição de Pronto, uma vez que este é um requisito não funcional local Backlog de Produto, uma vez que este é um requisito não funcional global Backlog de Produto, uma vez que este é um requisito não funcional local.
Requisitos não funcionais locais são aplicáveis apenas a um requisito funcional específico, por exemplo, um requisito de desempenho específico para recuperar informações. O que deve ser feito se o requisito não funcional for expresso como uma restrição? Anexar a restrição à Definição de Pronto Anexar a restrição ao Backlog de Produto Anexar a restrição à história Capturar a restrição como um esboço.
Ao criar um Backlog de Produto, quais critérios fundamentais devem ser aplicados durante a preparação do Backlog de Produto, antes de sua revisão em uma sessão de planejamento da Sprint? Identificar com clareza os esforços de trabalho para os itens e detalhar itens de alta prioridade antes da sessão de planejamento da Sprint Identificar com clareza os esforços de trabalho para os itens e detalhar todos os itens antes da sessão de planejamento da Sprint Priorizar os itens e detalhar todos os itens antes da sessão de planejamento da Sprint Priorizar os itens e detalhar todos os itens de alta prioridade antes da sessão de planejamento da Sprint.
Existem armadilhas comuns que podem afetar os esforços gerais de desenvolvimento do produto. Duas destas armadilhas são: • Relato do Burn-down da Sprint. • Um Product Owner passivo. Quais são as duas outras armadilhas mais comuns que um Product Owner pode enfrentar ao executar um programa de desenvolvimento de produto? • Ritmo agressivo • Uma reunião de revisão da Sprint onde os resultados apresentados não correspondam à Definição de Pronto • Ritmo agressivo • Repriorização do Backlog de Produto • Ritmo insustentável • Uma reunião de revisão da Sprint onde os resultados apresentados não correspondam à Definição de Pronto • Ritmo insustentável • Repriorização do Backlog de Produto.
Radiadores de informação podem demonstrar gráfico de Burn-down de versão de entrega e da Sprint, itens de Backlog de alta prioridade e Backlog da Sprint. Todos estes são exemplos de artefatos. Que outro artefato pode ajudar a promover a transparência e permitir que o time enfoque suas prioridades? Arquitetura de infraestrutura Mapa das partes interessadas Relatório de status Declaração da visão.
O time de Scrum subestimou o trabalho restante em uma iteração. O que pode aparecer no gráfico burn-down? Burn-up Dias ideais Horas ideais Pontos por História.
A X-AppGo está gerenciando um projeto de desenvolvimento de produto complexo que requer 5 times construindo uma funcionalidade crítica para suporte de um aplicativo para distribuição e rastreamento por drone. Cada time tem seu próprio conjunto de Sprints e requisitos que permitem capacidades e funcionalidades específicas do aplicativo de distribuição e rastreamento por drone. A X-AppGo está buscando maneiras para melhorar o modo de colaboração e trabalho entre os 5 times para obter especificamente os dois principais resultados a seguir: 1. Os 5 times querem ser capazes de ter uma reunião de Revisão da Sprint efetiva entre todos os times, os clientes e outros stakeholders. 2. Os 5 times querem ser capazes de identificar medidas de aprimoramento comuns e compartilhar suas ideias mútuas, usando a sabedoria coletiva do time, e permitir a interação entre membros dos times, fortalecendo assim as relações entre os times. Quais são as duas abordagens que tratam desses dois resultados? Planejamento da Sprint conjunto e Retrospectiva da Sprint conjunta Planejamento da Sprint conjunto e Scrum de Scrums Revisão da Sprint conjunta e Retrospectiva da Sprint conjunta Revisão da Sprint conjunta e Scrum de Scrums.
A X-AppGo está trabalhando de acordo com os princípios Ágeis e está interessado em mudar radicalmente o modo como desenvolve aplicativos de software para atender às intensas demandas de clientes e do mercado competitivo. Eles começaram adoptando DevOps como abordagem a ser seguida para desenvolvimento de aplicativos. A Entrega Contínua é uma área de grande interesse para eles, mas estão tendo algumas dificuldades para fazer com que o time siga regras estabelecidas e processos padronizados. Não há mecanismos de “monitoramento" estabelecidos, não há controle de alterações e não existe auditabilidade. Qual é o primeiro passo que a X-AppGo deve adotar para abordar estes pontos fracos identificados? Criar um sistema altamente automatizado e confiável quer permita o feedback rápido em todo o percurso até a operação de recursos em produção Ampliar o sistema DevOps para incluir captação de valor e maior envolvimento das partes interessadas Examinar mais profundamente os requisitos e as restrições que podem criar desperdício, como burocracia, conformidade e contabilidade Usar o planejamento de cenário para modelar possíveis estados futuros.
A X-AppGo está gerenciando um projeto de desenvolvimento de produto complexo que requer 5 times construindo uma funcionalidade crítica para suporte de um aplicativo para distribuição e rastreamento por drone. Cada time tem seu próprio conjunto de Sprints e requisitos que permitem capacidades e recursos específicos do aplicativo de distribuição e rastreamento por drone. A X-AppGo está buscando maneiras para melhorar o modo de colaboração e trabalho entre os 5 times para obter especificamente os dois principais resultados a seguir: 1. Fornecer a oportunidade de aproximar os times ou pelo menos os representantes dos times no início da reunião de Planejamento da Sprint para discutirem e entenderem a meta mais abrangente da Sprint, para a qual todos os times contribuem. 2. Permitir que múltiplos times exerçam a coordenação diariamente durante toda a Sprint. Os representantes do time se reúnem após as Dailys Scrum de seus times para discutir a situação atual, o trabalho planejado e quaisquer dependências entre os times. Quais são as duas abordagens que tratam desses dois resultados? Planejamento da Sprint conjunto e Retrospectiva da Sprint conjunta Planejamento da Sprint conjunto e Scrum de Scrums Revisão da Sprint conjunta e Retrospectiva da Sprint conjunta Revisão da Sprint conjunta e Scrum de Scrums.
Você está trabalhando em um ambiente Ágil escalado. É importante que a Arquitetura seja definida antes do início da primeira Sprint. Por que isso é importante? Para definir subgrupos do Backlog de Produto para que todos os Times de Desenvolvimento possam receber um número igual de recursos para programar Para definir subgrupos do Backlog de Produto para que todos os Times de Desenvolvimento tenham dependências mínimas durante o desenvolvimento Para definir os requisitos funcionais e incluí-los no Backlog de Produto compartilhado para prever o planejamento de todos os Times de Desenvolvimento Para definir os requisitos não funcionais para a infraestrutura usada por todos os Times de Desenvolvimento e incluí-los no Backlog de Produto.
Em projetos maiores e complexos, a reunião de Scrum de Scrums ajuda no escalonamento para times maiores. Como essa reunião deve ser realizada? Deve ser realizada após a Daily Scrum e um membro do time deve comparecer. Deve ser realizada após a Daily Scrum e um o Product Owner deve comparecer. Deve ser realizada antes da Daily Scrum e um membro do time deve comparecer. Deve ser realizada antes da Daily Scrum e um o Product Owner deve comparecer.
Grandes projetos de Scrum com frequência exigem um escalonamento da função do Product Owner, para que seja possível lidar com a maior complexidade e porte. Além da novidade do produto, que fatores são essenciais para determinar o número de times que um único Product Owner pode apoiar adequadamente? Duração da Sprint e estrutura organizacional Duração da Sprint e tamanho do time Complexidade do produto e conhecimento do Scrum Master sobre o negócio Complexidade do produto e conhecimento dos times sobre o negócio.
Nem todos os projetos são adequados para aplicar a abordagem Agile Scrum. Em qual caso o Scrum é o mais aplicável? A competência dos desenvolvedores é relativamente baixa. A organização não quer realizar testes de aceitação do usuário. Os requisitos do produto podem ser alterados no processo. Os requisitos são conhecidos antecipadamente para rápida implementação.
Dependendo do tamanho de um projeto, seu time precisará de mais ou menos recursos. Um destes recursos é o número de membros do time. Qual afirmação é verdadeira sobre o tamanho dos times? Times maiores concluem os projetos com menor esforço total, o que é mais barato. Times maiores criam mais defeitos que times pequenos e não trabalham de forma tão rapida Times menores precisam de mais tempo, o que custa mais esforços e dinheiro. Os membros nos times maiores são mais produtivos que nos times menores.
Em projetos grandes e complexos, deve ser possível escalar adequadamente o Backlog de Produto. Existem vários modos para realizar isso no Scrum. Se você, como Product Owner, quiser aplicar a técnica de “Extensão do Horizonte de Preparação", que medidas vão permitir isso? Decompor e refinar o Backlog após o planejamento da próxima Sprint Decompor e refinar o Backlog, enfocando as duas ou três próximas Sprints Decompor e refinar o Backlog a tempo para o planejamento da Sprint atual Decompor e refinar o Backlog a tempo para a Sprint subsequente.
Você é o Product Owner da área de tecnologia da empresa SHIELD, trabalhando em um novo sistema interno de Planejamento de Recursos Empresariais (ERP) que substituirá o usado atualmente, já ultrapassado. Este sistema fornecerá funcionalidade a todas as áreas da empresa e será usado em mais de 30 países onde a SHIELD fizer negócios. Este é um projeto crítico para a empresa porque permitirá que os funcionários de campo (como vendas e distribuição), assim como fornecedores e parceiros, colaborem e trabalhem on-line usando seus celulares e laptops, o que fornecerá à SHIELD uma vantagem única em comparação aos concorrentes. Uma vez que o sistema ERP é composto por 5 subsistemas, você decide usar uma abordagem de time baseada em componentes e indica 5 Product Owners. Você permite que cada um deles gerencie um dos times, que estarão trabalhando de modo paralelo em cada subsistema. Ao planejar o projeto, os Product Owners e os times propõem a criação de um Backlog para cada componente, pois isto facilitará sua manutenção e uso. O Scrum Master contesta a proposta, alegando que deve haver apenas um Backlog de Produto. Neste cenário, o que deve ser decidido sobre o Backlog de Produto? Deve haver mais de um Backlog de Produto, porque cada Product Owner será responsável pelo seu próprio. Deve haver apenas um Backlog de Produto master, mas pode haver muitos Backlog de Produto de componentes. Deve haver apenas um Backlog de Produto, porque mais de um criará despesas e desperdício significativos. Deve haver apenas um Backlog de Produto, porque o Scrum Master Principal será responsável por todo o projeto.
Quando o Valor de Negócio é entregue? Depende da organização. Quando todos os Itens de Backlog de Produto forem liberados para produção. Quando o Product Owner estiver satisfeito.
Qual é a melhor prática para agregar Valor de Negócio a um projeto Ágil? Gerenciamento efetivo do Backlog de Produto pelo Product Owner. O Scrum Master ajudando o Product Owner a encontrar técnicas para a organização dos Itens de Backlog de Produto. Os valores de Scrum sendo incorporados e vivenciados por todo o Time de Scrum.
“Nosso Time de Desenvolvimento trabalha duro, mas não sabe se o trabalho realizado produz funcionalidades valiosas." Para ajudar o time, o Scrum Master decide fazer o seguinte: 1. Ajudar o Time de Scrum a compreender a necessidade de Itens de Backlog de Produto claros e concisos. 2. Encontrar técnicas para gerenciamento efetivo do Backlog de Produto. 3. Garantir que o Product Owner saiba como organizar o Backlog de Produto para maximizar o valor. 4. Garantir que o Product Owner explique claramente o valor entregue na Revisão da Sprint. 5. Liderar e treinar a organização em sua adoção do Scrum. Qual combinação destas ações produz uma otimização do Valor de Negócio? 1, 2 e 3 1, 2 e 4 2, 4 e 5 Todas as ações.
Qual é o melhor modo de desenvolver uma compreensão profunda das necessidades do cliente e do usuário? Obter o feedback de clientes e usuários quando o produto for lançado Convidar as artes interessadas a comparecerem às reuniões de Daily Scrum Envolver os clientes e usuários no início e continuamente no processo de desenvolvimento.
Por que é importante que um Time de Scrum desenvolva uma boa compreensão das necessidades do cliente e do usuário? Clientes e usuários têm as mesmas necessidades; portanto, o Time de Scrum deve saber como essas necessidades são satisfeitas. Recebendo um feedback contínuo dos clientes e usuários, o Time de Scrum aprende e pode criar um produto vencedor. Clientes e usuários determinam se um produto está Pronto; portanto, a colaboração diária com o Time de Scrum é essencial. O Time de Desenvolvimento deve saber que recursos devem construir e por isso deve interagir diretamente com os clientes e usuários.
Report abuse Terms of use
We use cookies to personalize your experience. If you continue browsing you will be accepting its use. More information.