Conhecimentos e Comportamentos Digitais Flashcards
Qual a diferença entre:
Poder Legítimo
Poder Coercitivo
Poder de Recompensa
Poder de Competência
Poder de Referência
Poder de Informação
Poder Pessoal
Poder Legítimo: É o poder que está relacionado à hierarquia (estrutura formal da empresa).
Ou seja, relaciona-se à posição hierárquica (ao cargo) que a pessoa ocupa dentro de uma
organização. Por exemplo: o poder que o diretor de uma empresa tem sobre seus gerentes
subordinados.
Poder Coercitivo (Poder de Coerção): O poder sobre as pessoas está amparado em
ameaças, castigos e punições. Ou seja, o detentor deste tipo de poder pode punir as outras
pessoas. Portanto, as pessoas obedecem pois tem medo da punição.
Poder de Recompensa: Trata-se do poder de recompensar as pessoas por determinado tipo
de comportamento (como bom desempenho ou atingimento de metas, por exemplo).
Quem detém esse poder pode incentivar e alterar o comportamento das pessoas através de
melhores salários, prêmios, bônus, etc.
Poder de Competência (Poder de Perito ou Poder de Especialização): Esse tipo de poder
acontece quando a pessoa possui habilidades, conhecimentos, expertise ou know-how
sobre determinado assunto específico. Essas competências o diferenciam das demais
pessoas, e lhe dão “poder” nessa determinada área. Por exemplo: O médico neurologista
que possui poder de competência sobre sua equipe em virtude de sua vasta experiência e
conhecimento da área.
Poder de Referência (Poder Referente ou Poder Carismático): Trata-se do poder baseado
no carisma e na empatia que o líder possui. As pessoas se identificam com as características
do líder e o veem como um tipo de “herói”. As características do líder são vistas como
“características desejáveis”. Portanto, as pessoas passam a segui-lo e são influenciadas por
ele. A visão do líder em relação aos objetivos inspira as demais pessoas. Por exemplo: o
jogador de futebol e seus fãs.
Poder de Informação: Esse tipo de poder acontece quando a pessoa detém a posse de
informações estratégicas que orientem processos decisórios ou que auxiliem a empresa em
situações críticas. Tratam-se daquelas informações “privilegiadas”.
Poder Pessoal: É o poder que deriva das características individuais da pessoa.
Em métodos ágeis por que valorizar mais indivíduos e suas interações do que processos e ferramentas?
Porque, em última instância, quem gera produtos e serviços são os indivíduos, que possuem
características únicas como talento e habilidade
Em métodos ágeis por que valorizar mais software em funcionamento do que documentação abrangente?
A documentação é
importante, sim; mas valoriza-se mais o software em funcionamento, que é o que de fato
agrega valor ao cliente
Em métodos ágeis por que valorizar mais colaboração com o cliente do que negociação de contratos?
Desenvolvedores e clientes
devem estar sempre lado a lado, visto que ambos possuem interesses em comum. Um
software que agregue valor!
Em métodos ágeis por que valorizar mais a resposta a mudanças do que seguir um planejamento específico?
Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um
desenvolvimento contínuo do software. Todo projeto deve balancear o planejamento com a
mudança, dependendo do nível de incerteza do projeto.
Quais os pilares do Scrum (TIA)?
Transparência: Todos os aspectos relevantes do processo devem ser visíveis a todos os envolvidos. Isso inclui o progresso do trabalho, impedimentos, desafios enfrentados e objetivos a serem alcançados.
Inspeção: Os artefatos produzidos e os progressos devem ser frequentemente inspecionados para identificar variações indesejadas ou problemas emergentes. Isso permite que a equipe detecte e corrija problemas o mais cedo possível.
Adaptação: Com base nas informações obtidas por meio da inspeção, a equipe deve adaptar seus processos, artefatos e objetivos para otimizar o valor entregue e responder a mudanças de forma eficaz.
O que é uma Sprint no Scrum?
É um ciclo completo de
desenvolvimento de um incremento potencialmente entregável de um produto (Transparência, Inspeção e Adaptação). Uma Sprint é um período de tempo fixo durante o qual uma equipe de desenvolvimento trabalha para entregar um incremento de produto pronto e utilizável. Geralmente, a duração de uma Sprint no Scrum é de duas a quatro semanas. Durante a Sprint, a equipe seleciona itens do backlog do produto (trabalho a ser feito) e trabalha para completá-los. No final da Sprint, a equipe deve ter criado um incremento de produto potencialmente entregável, pronto para ser revisado pelo Product Owner e, se aprovado, potencialmente entregue aos clientes. As Sprints fornecem uma estrutura de tempo fixa para o trabalho, promovendo foco, colaboração e entrega regular de valor.
Quem faz parte do Scrum Team (Equipe Scrum)
DEVELOPERS
( DESENVOLVEDORES )
PRODUCT OWNER
( DONO DO PRODUTO )
SCRUM MASTER
( MESTRE SCRUM
Quem pode gerenciar e alterar o Product Backlog?
Somente o PO (PRODUCT OWNER)
Quais as responsabilidades do PO (Product Owner) ou Dono do Produto?
Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho dos desenvolvedores, sendo o único
que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para os desenvolvedores, mas ainda será
considerado o responsável pelos trabalhos.
Ele é responsável por priorizar/ordenar os itens do Product Backlog e selecionar aqueles que serão
implementados.
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que a Equipe Scrum vai trabalhar a seguir.
Ele é responsável por garantir que os desenvolvedores entendam os itens do Product Backlog no nível
Quais as responsabilidades dos Desenvolvedores no Scrum Team?
Responsável pela micro-gestão e pela criação do produto.
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz aos desenvolvedores como transformar o
Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.
Times 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 específicos para os desenvolvedores, independentemente do trabalho que
está sendo realizado pela pessoa;
Individualmente, os desenvolvedores podem ter habilidades especializadas, mas a responsabilidade
pertence aos desenvolvedores como um todo.
Os desenvolvedores não contêm sub-times dedicados a domínios específicos de conhecimento, tais como
teste ou análise de negócios.
Os desenvolvedores são estruturados e autorizados pela organização para organizar e gerenciar seu
próprio trabalho.
Quais os deveres do Scrum Master (SM)?
Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a
Equipe Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações com
a Equipe 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 pela Equipe
Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog.
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam
sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de
qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os
problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando técnicas
de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade.
Ele treina os desenvolvedores em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.
Ele comunica claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores.
O que é um Product Backlog? E porque ele é um artefato dinâmico?
Product Backlog é uma lista ordenada (por valor, risco,
prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter criada
pela Equipe Scrum.
O Product Backlog é um artefato dinâmico que nunca estará completo e existirá enquanto o produto também existir. Porque sempre haverá novos requisitos, novas necessidades e mudanças a serem incorporadas. Logo, trata-se de um artefato vivo – sempre em movimento.
Somente o PO (Product Owner) pode alterar o Product Backlog.
O que é um Sprint Backlog e quem é responsável por ele.
Trata-se de conjunto de itens selecionados do Product Backlog, mais a meta da sprint e mais um plano de ação para entregar um incremento potencialmente usável – é criado e gerenciado pelos desenvolvedores. Ao final de cada Reunião de Planejamento, um novo Sprint Backlog é criado.
O que é um Product Increment e Definition of Done (DoD)?
Trata-se da é da soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as sprints anteriores – sendo validado como “pronto”.
O DoD é um acordo formal que define claramente quais são os passos mínimos para a conclusão de um
item ou funcionalidade potencialmente entregável. Trata-se de uma lista de verificação de
atividades necessárias para que um incremento seja considerado como completo.
Qual a diferença do Definition of Done (DoD) e o Definition of Ready (DoR)?
O DoD é um acordo formal que define claramente quais são os passos mínimos para a conclusão de um
item ou funcionalidade potencialmente entregável. Trata-se de uma lista de verificação de
atividades necessárias para que um incremento seja considerado como completo.
Definition of Ready (DoR) é um
checklist de critérios acordados para que os desenvolvedores possam aceitar um requisito.
Sempre lembrando que o Definition of Ready é opcional, já o Definition of Done é obrigatório.
Qual o objetivo de uma Sprint, qual a duração, com qual frequência ela ocorre e quem participa?
O objetivo da sprint é atingir a meta de incremento.
A duração é medida em semanas, e pode ter no máximo um mês.
A frequência da Sprint é sempre contínua, sem intervalos prolongados.
Todos do SCRUM Team participam da Sprint. (PO, Developers e SM).
Qual o Objetivo da Sprint Planning, quem deve participar e qual é seu objetivo?
O objetivo é planejar o ciclo de desenvolvimento de maneira mais técnica.
Não é obrigatória a presença do PO, mas se existirem dúvidas, ele deve ir.
O objetivo da Sprint Planning é a Meta da Sprint e a Sprint Backlog.
Quando é feito a Sprint Planning e qual sua duração?
A Sprint Planning deve ser feito no início de cada Sprint.
A duração é proporcional a 8 horas para 4 semanas. Ou seja, metade disso, 2 semanas de Sprint significa 4 horas de Sprint Planning.
Qual o Objetivo de uma Daily SCRUM, qual o tempo utilizado e quem deve participar?
O objetivo é planejar o próximo dia de desenvolvimento e discutir os empecilhos.
O tempo é em média até 15 minutos.
Os desenvolvedores que participam, mas o PO e SM também podem, mesmo não sendo obrigatório.
Qual o Objetivo da Sprint Review, qual o tempo utilizado e quem deve participar?
O objetivo é mostrar uma demo funcional do produto, ou um protótipo para verificar as expectativas do PO.
O tempo é proporcional de 4 horas para 4 semanas de Sprint. Ou seja, se a Sprint durou 2 semanas, a Sprint Review deve durar no máximo 2 horas;
Todos devem participar da Sprint Review (PO, Developers e SM).
Qual a Timebox de uma Sprint Planning?
No máximo oito horas para uma sprint de um mês de duração – para sprints menores, a duração é menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propósito.
