option
Questions
ayuda
daypo
search.php

ERASED TEST, YOU MAY BE INTERESTED ON ASM-LRDF-RP

COMMENTS STATISTICS RECORDS
TAKE THE TEST
Title of test:
ASM-LRDF-RP

Description:
SIMULADO 1

Author:
JFrancisco62
Other tests from this author

Creation Date: 19/02/2025

Category: Others

Number of questions: 40
Share the Test:
New CommentNuevo Comentario
No comments about this test.
Content:
Em uma reunião de Planejamento da Sprint, o Product Owner seleciona para estimar a seguinte história de usuário do Backlog de Produto: Como um administrador de sistemas, eu quero gerenciar o acesso dos usuários. Os Desenvolvedores alegam que essa pode não ser uma boa história de usuário para estimar no momento. Qual é a razão mais provável para os Desenvolvedores dizerem isso? A história de usuário não fornece detalhes suficientes e deve ser refinada. A história de usuário deveria ter sido ordenada antes de ser estimada. A história de usuário não segue o modelo Scrum para histórias de usuário.
Uma startup que utiliza o Scrum tem uma discussão. Alguns dos funcionários não veem sentido no uso do planejamento do portfólio por uma empresa tão pequena, afinal há apenas dois times Scrum pequenos. Por que o planejamento do portfólio é importante para essa empresa? Alinhar os dois times Scrum no planejamento do portfólio para identificar quaisquer dependências ajudará esses times a ser mais produtivos Definir o horizonte de planejamento para os próximos três a cinco anos permitirá aos funcionários trabalhar sem mais orientações Determinar que produtos suportam as metas e objetivos organizacionais é importante para uma empresa de qualquer porte Assegurar que o Backlog de Produto seja claramente documentado, refinado e tornado visível criará o máximo de valor.
Um time Scrum utiliza um gráfico Burn-Down para monitorar seu progresso. Durante a Sprint, o gráfico tem o seguinte aspecto: O que o gráfico diz sobre essa Sprint? Os Desenvolvedores estão fazendo menos que esperavam. Os Desenvolvedores estão no caminho certo para concluir a Meta da Sprint Os Desenvolvedores inseriram itens demais na Sprint. Os Desenvolvedores se depararam com um bloqueio e estão travados.
Um time Scrum está em uma reunião de Planejamento da Sprint. O Scrum é relativamente novo para alguns membros do time, apesar que uns dois deles têm experiência com projetos semelhantes. O Product Owner é muito experiente e tem um bom entendimento do Backlog de Produto. O Scrum Master também é experiente e vem orientando o time sobre técnicas de estimativa. Eles usam planning poker para estimar o tamanho do trabalho para cada tarefa. Para uma dada tarefa, as opiniões são amplamente divergentes: os membros experientes mostram cartas de 5, já os membros menos experientes mostram cartas que vão até 21. Há uma discussão para explorar questões e opiniões. As cartas são novamente jogadas e desta vez valem 5, 5, 5, 5, 13, 21 e 40. O que o Scrum Master deve fazer? Reconhecer que o planning poker é demasiado complexo e não funciona neste contexto, e mudar para o método de tamanhos de camiseta Pedir ajuda ao Product Owner, pois ele entende melhor o Backlog de Produto e fez a estimativa original Facilitar uma discussão, assegurando que cada membro do time é realmente ouvido e pode explicar seu ponto de vista Usar o 5, pois já houve discussão e os membros do time mais experientes sabem mais.
Um time que precisa de um novo Scrum Master tem vivenciado uma falta de motivação, apesar de ir bem na produção dos resultados que desejava e com os quais se comprometeu durante uma Sprint. O time é muito experiente em seu trabalho, mas nem todos os Desenvolvedores estão cientes das mudanças recentes na metodologia que estão usando. Suas competências de comunicação poderiam melhorar. Qual é a característica mais importante para esse novo Scrum Master? Ser um bom coach, capaz de apoiar o aprendizado dos Desenvolvedores Ser novo na organização e ver as coisas com novos olhos Ter experiência em diferentes projetos e com novas tecnologias Ter a capacidade de implementar boas ferramentas para facilitar o trabalho em equipe.
Petra é uma gerente de projetos experiente, com um histórico de tomar grandes decisões para o time que gerencia. A empresa está migrando para o Scrum e convida Petra para se tornar Scrum Master após a migração. Que atividades de gestão de projetos um Scrum Master realiza? Assegurar que o projeto alcance os objetivos estabelecidos Assegurar o monitoramento, a notificação e a manutenção da documentação Gerenciar o escopo, os custos, a qualidade e os riscos relacionados Gerenciar a comunicação com as partes interessadas e a elaboração de relatórios.
No Scrum, é essencial que o times sejam autogerenciados. Por que isso é essencial? O autogerenciamento assegura que todas as decisões importantes do projeto sejam revisadas por várias partes. O autogerenciamento ajuda os membros do time a tomar suas próprias decisões sobre o que traz valor O autogerenciamento permite que os Desenvolvedores escolham suas próprias tarefas, o que ajuda a criar um verdadeiro compromisso.
Um time tem dificuldades para manter a reunião de Planejamento da Sprint dentro do time-box, pois passa muito tempo planejando o trabalho para concluir sua Sprint dentro do prazo esperado. Quem deve assegurar que a reunião fique dentro do time-box? Os Desenvolvedores, pois devem assumir a liderança da reunião de Planejamento da Sprint A organização, pois deve promover maneiras de ajudar o time a ficar dentro do time-box O Product Owner, pois deve preparar o time para o Planejamento da Sprint O Scrum Master, pois é responsável por garantir uma reunião eficiente.
Uma empresa de jogos decidiu migrar para o Scrum. Para continuar lucrativa, precisa colocar novas ideias de jogos em produção mais rápido que a concorrência. A empresa dividiu os Desenvolvedores em quatro times Scrum diferentes e nomeou quatro Scrum Masters. Depois de um tempo, a empresa contrata Afia, uma Scrum Master experiente, para resolver alguns problemas que a empresa enfrenta. Os quatro times têm ideias diferentes sobre como o Scrum deve funcionar para a empresa e no seu time. Os Desenvolvedores culpam a forma como o Scrum foi implementado por tudo que dá errado. Eles querem adaptar a forma como usam o Scrum a suas necessidades individuais. O time de gestão da empresa de jogos está reconsiderando sua decisão de usar Scrum na empresa. O que Afia deve fazer? Reunir todos os Desenvolvedores e desenvolver um tipo de Scrum customizado para toda a empresa Certificar-se que os Desenvolvedores entendem o Scrum e sabem por que é importante seguir as regras à risca Parar com o treinamento dos times que não seguem as regras e começar um time Scrum para um pequeno experimento Levar a sério cada time Scrum e desenvolver um tipo de Scrum customizado para cada time Scrum.
Um time tem problemas com a gestão do Backlog de Produto. Os Desenvolvedores nem sempre entendem a ordenação dos itens do Backlog de Produto, às vezes têm dificuldade para entendê-los e selecionar os itens certos para o Backlog da Sprint atual. Qual é uma responsabilidade principal do Scrum Master neste cenário? Orientar os clientes para ajuda-los á criar histórias de usuário mais claras Encontrar maneiras de melhorar a gestão do Backlog de Produto Ajudar os Desenvolvedores a ordenar os itens do Backlog de Produto Treinar os Desenvolvedores para usar a Voz do Cliente (VoC).
Um time migrou recentemente para o Scrum. Como muitos times Scrum novos, esse time tem uma base de dados de erros conhecidos que descreve erros e problemas não críticos. Qual é a melhor forma de lidar com esses erros conhecidos? Ignorar a base de dados de erros conhecidos e, em vez disso, focar em criar novas funcionalidades Inserir todos os erros críticos na próxima Sprint para corrigi-los, mas ignorar os erros não críticos Executar algumas Sprints para corrigir os erros conhecidos antes de passar para novas funcionalidades Monitorar todos os erros conhecidos no quadro Scrum e inserir alguns erros em cada Sprint.
A Red Industries cria produtos para seus clientes há anos usando formas tradicionais de trabalho. A empresa ia muito bem até recentemente, mas atualmente está perdendo clientes para concorrentes pequenos que trabalham de forma Ágil. Qual é a razão mais provável para os concorrentes menores se saírem melhor? Os concorrentes têm funcionários melhor treinados que cria produtos melhores Os concorrentes incorporam o feedback de seus clientes ao desenvolvimento Os concorrentes têm Desenvolvedores com ideias novas e podem inovar melhor. Os concorrentes têm menos gastos com pessoal e, assim, uma maior margem de lucro.
O Scrum é novo para um time, que está entusiasmado para testá-lo. A empresa é muito aberta e há confiança suficiente entre os gerentes e funcionários. Os Desenvolvedores do time trabalhavam anteriormente em dois times separados, com especialidades diferentes e rivais, competindo para se tornar o time do mês. Como acreditam que precisam de todas as competências no time para ser autossuficientes, formarão um time juntos. Para que o Scrum tenha sucesso, o time tem que fazer o seguinte (em ordem aleatória): - mudar suas premissas sobre como trabalhar e como os outros podem ser capazes de ajudar - transformar a cultura em uma verdadeira cultura Ágil, pois atualmente está apenas a meio caminho disso - mudar o foco de métodos tradicionais de desenvolvimento para entregar valor para o cliente, em cooperação com o cliente - implementar e começar a usar um novo conjunto de métricas Ágeis para monitorar o progresso Qual é mais provavelmente o maior desafio para esse time? Mudar as premissas Mudar a cultura Mudar o foco Mudar as métricas.
O uso de um quadro Scrum é uma prática universalmente aceita, embora alguns times usem quadros Kanban ou técnica Kanban além de um quadro Scrum. Por que técnicas Kanban ajudam a fazer o melhor uso de um quadro Scrum? Como todos os times são diferentes, as técnicas Kanban são mais adequadas para times que já têm alguma experiência prévia com Lean ou Agile. Como os quadros Scrum não foram projetados especificamente tendo em conta o fluxo, as técnicas Kanban podem ser usadas por times que têm dificuldade com a migração. Usar limites de trabalho em progresso (limites de WIP) em um quadro Scrum pode ajudar um time a identificar possíveis gargalos e a melhorar o fluxo.
Todos os membros do time Scrum, incluindo os Desenvolvedores, devem ajudar o Scrum Master a identificar e resolver impedimentos durante uma Sprint. Por que os Desenvolvedores também devem ajudar o Scrum Master? Os Desenvolvedores são responsáveis por garantir que o progresso é feito em função da Meta da Sprint O Scrum Master é uma única pessoa que já é responsável por garantir o treinamento e o coaching O time Scrum é autogerenciado, o que significa que todos são responsáveis por garantirem tudo.
A empresa Software Express teve dificuldade com a migração para o Scrum, mas agora todos os times estão contentes de terem feito a migração. Além de o tempo de mercado ter sido reduzido em semanas, verificou-se também que: - Os membros do time estão mais contentes e mais satisfeitos com seu trabalho. - A qualidade do trabalho do time melhorou. - Os times estão mais produtivos agora e liberam de modo incremental. - Novos desenvolvimentos custam significantemente menos agora. Qual desses feitos está relacionado diretamente com um menor tempo de mercado? A maior satisfação com o trabalho A qualidade melhorada A Liberação incremental Os menores custos de desenvolvimento.
Uma empresa desenvolve um novo pacote de educação infantil, com quatro aplicativos: - um aplicativo para aprender a ler - um aplicativo para aprender a contar - um aplicativo para treinar adição e subtração básicas - um aplicativo para os pais e professores acompanharem os aplicativos para as crianças Todos os aplicativos do produto são interdependentes e devem se integrar uns com os outros. A empresa usará um Nexus para escalar o projeto. Qual é a melhor forma para escalar o Backlog de Produto? Criar um Backlog de Produto e um conjunto de itens do Backlog de Produto para cada aplicativo Criar um Backlog de Produto para cada camada de tecnologia que lida com a integração Criar um único Backlog de Produto e nomear um Product Owner para cada aplicativo Criar um único Backlog de Produto e nomear um único Product Owner para o produto.
Mesmo em grandes projetos de desenvolvimento, pode ser melhor ter apenas um Backlog de Produto para um produto. Para gerenciar corretamente esse único Backlog de Produto, um único Product Owner deve ser suficiente. Qual é uma vantagem importante de ter um único Product Owner? Facilitar a coerência na ordenação dos itens do Backlog Tornar o Product Owner um recurso escasso, o que aumenta a eficiência Reduzir custos para a empresa por não contratar um time inteiro de Product Owners Reduzir a competição que um time de Product Owners normalmente cria.
Um Product Owner atribui tarefas para os Desenvolvedores na reunião de Planejamento da Sprint. Os Desenvolvedores não se importam que o Product Owner lhes atribua suas tarefas. Entretanto, o Scrum Master acha que com isso os Desenvolvedores retrocedem a uma antiga conduta, anterior à migração para o Scrum. O Product Owner deve continuar a atribuir tarefas para esse time? Sim, os Desenvolvedores concordam com essa forma de trabalho, então o Product Owner pode continuar a atribuir as tarefas. Sim, o time Scrum é autogerenciado e seus membros podem resolver isso sozinhos Não, o Scrum Master deve informar o Product Owner que apenas os Desenvolvedores podem escolher as tarefas Não, o Scrum Master deve se pronunciar sobre quaisquer dúvidas e facilitar uma discussão com o time.
O Scrum tem times multifuncionais. O que isso significa? Qualquer membro do time pode fazer qualquer tarefa na Sprint. O time tem membros em cada um dos papéis Scrum O time toma suas próprias decisões sobre como trabalhar Juntos, os membros do time têm todas as competências necessárias.
No Scrum, recomenda-se manter os times Scrum relativamente pequenos. A razão é que times menores são mais produtivos. Por que times menores são geralmente mais produtivos? Times pequenos são menos propensos a formar subgrupos, a contribuição de todos é mais visível e a coordenação é mais fácil. Times pequenos podem alternar entre diferentes projetos a cada Sprint de maneira mais fácil, o que ajuda a agregar o máximo valor de negócio. Times pequenos normalmente têm Desenvolvedores com percursos e capacidades técnicas similares, o que acelera a comunicação.
Um erro é encontrado durante o desenvolvimento de software. O que deve ser feito durante a Reunião Diária? - O erro deve ser acrescentado ao quadro Scrum para ser resolvido. - O time analisa se o erro deve ser resolvido posteriormente. - O erro deve ser ordenado pelo Product Owner. - Os Desenvolvedores realocam as tarefas durante a Reunião Diária. - O Product Owner puxa novas tarefas do Backlog de Produto. - O cliente deve ser atualizado com o efeito do erro. - O Scrum Master prolonga a Reunião Diária. - Os Desenvolvedores ajudam o Product Owner a entender o erro. - O Product Owner determina o impacto nas outras tarefas. .
Uma Product Owner refina o Backlog de Produto. Ela dá mais detalhes para as histórias de maior prioridade após falar com vários clientes. Também agrupa diversas histórias de usuário de menor prioridade em Épicos. Essa é a maneira correta de refinar o Backlog de Produto? Sim, pois os requisitos dos clientes que são muito claros resultam em histórias detalhadas Sim, pois histórias de usuário de alta prioridade devem ser inseridas logo em um Backlog da Sprint. Não, pois qualquer história no Backlog de Produto pode ser detalhada ou em alto nível. Não, pois agrupar as histórias de usuário em Épicos leva a perda de detalhes importantes.
Um time está migrando para o Scrum. Hashim, um dos membros do time, não gosta do Scrum,embora não comente. Espera que se ignorar a mudança, ela desaparecerá. Hashim é cético. Addy é o Scrum Master do time e deseja ajudar Hashim a superar sua resistência. Qual é a melhor maneira de ajudar um cético a superar a resistência? Reconhecer os medos de Hashim e enfrentá-los, tornando-o insatisfeito com a forma de trabalhooriginal Não deixar Hashim falar nas reuniões, transferi-lo para um outro time, ou, se isso não der certo, talvez mesmo demiti-lo Certificar-se que Hashim compreende o Scrum, lhe dar algum tempo para se adaptar e nomear um campeão cético Moldar os comportamentos desejados, envolver Hashim nas atividades do time e elogiá-lo por fazer o certo .
Metal Company entrega software customizado para outras empresas. Recentemente, migrou um time para o Scrum, pois seus clientes queriam estar mais envolvidos com a criação de software, e estabeleceu Sprints de duas semanas para garantir que pode fazer mudanças no produto frequentemente. O Product Owner será instruído pelos clientes e passará algum tempo em suas empresas para ajudá -los a entender seus negócios e suas prioridades. Por outro lado, os clientes não querem vir à Metal Company para muitas demonstrações, pois isso lhes custaria tempo e, consequentemente, dinheiro também. Cada cliente está disposto a participar de um número diferente de demonstrações. Como o time Scrum deve trabalhar com esses clientes? Pedir para os clientes participarem de todas as demonstrações a cada duas semanas se estiverem empenhados a se envolver mais, para ajudá-los a ver o valor deste envolvimento Alocar os Desenvolvedores que trabalham em projetos específicos com os clientes para assegurar que obtenham informação por meio de comunicação osmótica Deixar o Scrum Master agir como uma segunda Voz do Cliente (VoC) para gerar melhor feedback e conduzir um número limitado de demonstrações Certificar-se que o Product Owner compreende muito bem os clientes e agendar um número de demonstrações que convenha a cada cliente.
Um time Scrum concordou sobre a seguinte definição de potencialmente lançável: Incrementos potencialmente lançáveis devem ter sido testados e atender às condições de satisfação fornecidas pelo Product Owner. Por que é importante incluir "testados" na definição do que é potencialmente lançável? Cada incremento potencialmente lançável que passou por esses testes será liberado para usuários Incrementos não são considerados feitos sem serem testados, para garantir que o produto funcionará como esperado Testes mostram como os incrementos desenvolvidos em separado são integrados uns com os outros Testes comprovarão que os incrementos são parte de um todo coerente e da Meta da Sprint que foi estabelecida.
Alisha é um novo membro que ingressa em um time, tendo trabalhado anteriormente em times Scrum como Scrum Master. Suas histórias deixam o time entusiasmado com o Scrum. O time gostaria de tentar trabalhar em um ambiente Ágil e de migrar lentamente para o Scrum Pede então a seu gerente para apoiar seus experimentos com o Scrum. O gerente, apesar de hesitante sobre o Scrum, permite ao time tentar e pede apoio do time de gestão, que também permite um experimento, mas se recusa a mudar qualquer estrutura de gestão ou expor a comunicação com os clientes aos membros do time. Esse time deve experimentar uma forma mais Ágil de trabalho agora? Sim, pois Alisha era Scrum Master e pode ensinar ao time como trabalhar de forma Ágil. Sim, pois o time está muito entusiasmado e isso faz com que agora seja o momento ideal para migrar para o Scrum. Não, pois o Agile tem que ser apoiado pela cultura da empresa e pela gestão, e os dois apoios estão ausentes neste caso. Não, pois o time não é formalmente treinado no framework Ágil e isso é necessário para o sucesso.
Um time Scrum possui limites de trabalho em progresso em seu quadro Kanban e também usa tíquetes bloqueadores para indicar que uma tarefa não consegue avançar. Após resolver o tíquete bloqueador, o time o guarda para uso posterior. Qual é o melhor uso para os tíquetes bloqueadores uma vez que são resolvidos? Criar diagramas de afinidades que mostram temas e iniciativas de melhoria nos quais o time deveria investir Discutir os tíquetes bloqueadores durante a reunião de Revisão da Sprint para encontrar a raiz do problema e a solução Monitorar o número de tíquetes bloqueadores para ver se o time consegue reduzir esse número com o passar do tempo Registrar os tíquetes bloqueadores em um Backlog de Melhoria Contínua ou no Backlog de Produto para revisão posterior.
Estimar em dias ideais é diferente de estimar em pontos de história. Qual é a diferença? Estimativa usando dias ideais assume que não há interrupções durante uma tarefa. Estimativa usando pontos de história considera as interrupções Estimativa usando dias ideais pode ser feita rapidamente usando notas adesivas. Estimativa usando pontos de história deve ser feita com cartas de poker Estimativa usando dias ideais tem tempo real como indicativa de tamanho. Estimativa usando pontos de história tem uma medida relativa de tamanho. Estimativa usando dias ideais é normalmente feita usando o método de tamanhos de camiseta. Estimativa usando pontos de história pode ser feita usando quantidade de horas.
Os diferentes papéis no Scrum são responsáveis por garantirem e executarem elementos diferentes. Um dos papéis é responsável por garantir a promoção da qualidade aderindo à Definição de Pronto (DoD). Que papel é responsável por garantir isto? Os Desenvolvedores O Product Owner O Scrum Master.
Uma grande empresa, com mais de 400 pessoas, migrou para o Scrum, usando a abordagem de aplicar o Scrum em todos os projetos da organização, com uma migração all-in. Os líderes relutaram a se comprometer plenamente com o Scrum e ainda não havia Scrum Masters experientes disponíveis na organização. Seis meses depois, o Scrum fracassou na empresa. Foram tentadas muitas aplicações diferentes do Scrum, com maior ou menor êxito. A empresa desistiu e voltou para o método Cascata. Qual é a razão mais provável para a migração não ter dado certo? A migração para o Agile não foi disruptiva o suficiente para provocar uma mudança real e não houve compromisso suficiente para manter o novo processo. A empresa era grande demais para migrar facilmente. Um projeto piloto bem-sucedido devia ter sido feito antes, para que pudesse ser copiado. Não houve demonstração pública de Agilidade e, portanto, os clientes continuaram a pedir projetos Cascata. A empresa desistiu cedo demais. O Scrum não foi devidamente promovido como uma melhor prática e a melhor forma para resolver os problemas da organização, o que gerou um grande risco.
A Electra Industries migrou recentemente para o Scrum. Agora, precisa começar o processo de melhoria contínua. Que evento Scrum é o melhor para iniciar a melhoria contínua? A Reunião Diária, pois a melhoria contínua deve ser um acontecimento diário O Planejamento da Sprint, pois itens de melhoria devem ser acrescentados ao planejamento A Revisão da Sprint, pois o feedback do cliente deve ser incorporado às melhorias A Retrospectiva da Sprint, pois é concebida para focar no que pode ser melhorado.
Que metodologias Ágeis podem ser usadas para escalar o Scrum ou o Agile? DSDM e Kanban Kanban e LeSS LeSS e SAFe SAFe e Extreme Programming (XP).
Uma organização deseja migrar para o Scrum e quer se certificar que essa migração correrá bem. Que fator mais ajuda a garantir uma migração sem sobressaltos? Avaliar o nível de maturidade Ágil da organização Assegurar que todos os times sejam treinados no framework Scrum Fazer com que a liderança crie e demonstre um mindset Ágil Formar times autônomos, autorregulados e multifuncionais.
Um time, com velocidade de 11 pontos de história por Sprint, tem as seguintes histórias de usuário: 1) "Como usuário, eu posso salvar meus dados pessoais" - 3 pontos de história - Pronto 2) "Como usuário, eu posso mudar meus dados pessoais" - 3 pontos de história - não começado 3) "Como usuário, eu posso recuperar meus dados pessoais" - 3 pontos de história - fora da Sprint 4) "Como administrador, eu posso ter uma lista dos usuários registrados" - 5 pontos de história - Pronto O time seleciona as histórias 1, 2 e 4 para uma Sprint. Quando a Sprint termina, o time completou a história 1 e a história 4, e sequer começou a história 2. Ao revisar, conclui que a história 1 demandou muito mais trabalho que o esperado e deveria ter sido estimada como 6 pontos de história. O time também conclui que subestimou o esforço necessário para as histórias dos dados pessoais do usuário. O que o time deve fazer? Estimar novamente todas as histórias de usuário como histórias de 6 pontos cada. Estimar novamente as histórias 2 e 3 como histórias de 6 pontos cada. Estimar novamente a velocidade do time como 17 pontos de história O time não deve estimar novamente nada.
Uma empresa está perdendo clientes e precisa mudar sua forma de trabalho. Um novo time Scrum é formado, pois os clientes estão cada vez mais insatisfeitos com os produtos. Os clientes deixam a empresa todos os dias. O novo Product Owner tem conversado com vários clientes para conhecê-los. Os clientes desejam sobretudo ser levados mais a sério e ser envolvidos no processo. Para eles, isso parece ter mais valor que uma atualização sobre o produto. Os Desenvolvedores usam Cascata há vários anos. Izzy, uma Scrum Master bem treinada, é convidada para integrar o time e lhe dar treinamento sobre como usar o Scrum. A Scrum Master tem diversas opções para treinar o time, cada uma tem uma desvantagem: - O time pode simplesmente começar de imediato com um piloto e aprender durante as primeiras Sprints, mas isso provavelmente levará a uma baixa velocidade nas primeiras Sprints e a um certo retrabalho. - A Scrum Master pode treinar o time de uma vez só, ela mesma, mas isso provavelmente resultará em uma velocidade mais baixa por algum tempo. - O time pode ser enviado para um treinamento externo um a um ao longo de três meses, mas desta maneira os membros do time não são treinados juntos e o início do Scrum terá que ser adiado. Quando questionados, os Desenvolvedores e o Product Owner não têm preferência por nenhuma das opções e estão satisfeitos com todas elas. Qual é a melhor forma de treinar esse time? Simplesmente começar com um projeto piloto de imediato Deixar a Scrum Master treinar o time Enviar o time para o treinamento externo.
Um Product Owner quer ter uma visão geral rápida do progresso do time em função da Meta da Sprint. Que radiador de informação é mais adequado neste caso? Um gráfico Burn-Down Um gráfico de Gantt Um quadro Kanban.
A Voltex é um distribuidor tradicional de equipamentos elétricos que usa uma forma de gestão de comando e controle. Como resultado, o nível de confiança entre funcionários e gerentes é baixo. A alta gestão deseja se tornar mais Ágil para sobreviver em seu mercado competitivo. O Scrum é novo para o time de eletricidade da Voltex e adotar o Agile será uma mudança cultural significativa. Assim, a gestão pediu a Jennifer, uma Scrum Master experiente, para liderar o novo time. Os Desenvolvedores e o Product Owner têm dificuldades para seguir os conselhos dados durante o treinamento Scrum. Desejam adaptar as práticas Scrum para que se encaixem em seu trabalho anterior e não entendem as mudanças. Por exemplo, o Product Owner e os Desenvolvedores questionam por que os Desenvolvedores devem escolher em que trabalhar em vez de os gerentes atribuírem as tarefas. O que a Scrum Master deve fazer? Solicitar treinamento Scrum para os membros do time e sugerir que o Product Owner simplesmente divida todas as tarefas Explicar como o autogerenciamento traz compromisso e como isso beneficia os membros do time e o fluxo Ignorar as objeções do time e simplesmente implementar de modo rígido as práticas Scrum e os artefatos do Scrum e deixar que o time se ajuste Deixar que o time adapte as práticas Scrum às suas próprias necessidades, pois é isso que significa ser Ágil.
Espera-se que um time Scrum entregue software potencialmente lançável no final de cada Sprint. Durante a última Sprint, o time não conseguiu entregar um incremento potencialmente lançável. A fim de entender como o time poderá ter um desempenho melhor no futuro, devem-se fazer algumas questões. Quem é responsável por garantir que essas três questões são feitas? Os Desenvolvedores O Product Owner O gerente de projetos O Scrum Master.
A sede de uma cadeia de lojas de departamento encomendou atualizações de um pacote de software para melhorar a gestão de estoque de seu armazém e serviços ao cliente. O time Scrum está implementando notificações sobre a hora do dia que um item em falta no estoque chega a uma loja indicada. O time não tem acesso aos dados do estoque, que é gerenciado pelo time de gerenciamento da informação. Isso forma um grande bloqueio. Como essa funcionalidade tem um valor externo alto, é importante que esse bloqueio seja removido. Qual é a melhor maneira para o Scrum Master ajudar o time nessa situação? Pedir para o Product Owner mover o item do Backlog para o Backlog de Produto Orientar o time de gerenciamento da informação para falar com os membros do time Deixar o time resolver esse problema porque todos são profissionais treinados Negociar com o time de gerenciamento da informação para acessar os dados.
Report abuse