Curso Metodologias ágeis. Scrum.

Nome e sobrenome

O Departamento de Recursos Humanos da empresa de energia Iberdesa está considerando

adotar as chamadas metodologias ágeis.

Você trabalha em uma consultoria estratégica com grande experiência em Agile e eles
te pediram ajuda para iniciar essa adoção do Agile.

O Departamento de RH É composto por 50 profissionais, distribuídos em sete equipes

cada uma com um diretor.

Solicita-se:

1. Faz sentido que usem "metodologias ágeis"? E o Scrum?

Faz sentido para eles usarem o Agile. Embora quando essa metodologia foi criada
ela tenha sido projetada para ser implementada apenas no desenvolvimento de
software e em setores mais técnicos, adotar uma metodologia ágil em qualquer
outro contexto pode se tornar uma vantagem competitiva. Quanto ao framework
SCRUM, ele permitiria criar equipes autogerenciadas e auto-responsáveis, que
com o tempo amadurecerão e melhorarão os prazos de entrega, bem como os
resultados.

2. Eles pedem uma proposta de 3 valores que estão alinhados com o Agile. Quais
seriam? Eles devem ser comentados.

Os valores ágeis estão escritos no manifesto assinado por 17 desenvolvedores de

software em 2001. Três deles seriam os próximos.

- Indivíduos e interações sobre processos e ferramentas. Uma das

principais características das metodologias ágeis, se não a mais
importante, é que tudo é focado nas pessoas que compõem a equipe
(humanismo) em comparação com o taylorismo que reinou nos anos
anteriores. E, por outro lado, as interações de cada um dos membros do
grupo com outros membros, superiores, stakeholders, clientes, etc., o
que torna o ambiente mais aberto e transparente. Isso não significa que
processos e ferramentas sejam deixados de lado, já que sem eles seria
impossível concluir os projetos.
- Software executado em extensa documentação. O que é importante e o que
tem um valor real que pode ser entregue ao cliente e transferido para o
mercado é o software ou o produto/serviço que está sendo desenvolvido;
Portanto, não é tão necessário escrever documentação extensa e volumosa.
Isso não significa que essa documentação não será realizada, mas o que
realmente tem que ser valorizado são os diferentes elementos que compõem
o projeto.
- Responder à mudança sobre seguir um plano. O desenvolvimento de software
é um mundo de mudanças e tentativas e erros, por isso a equipe como um
todo tem que estar aclimatada para reagir rapidamente a imprevistos,
erros ou mudanças nas necessidades do cliente. Portanto, o importante
será que o produto/serviço que você desenvolve cubra essas necessidades.
3.
• Como as equipes seriam formadas?

Uma equipe Scrum é composta por um Scrum Master (1), um Product Owner
(1) e uma equipe de desenvolvimento (3 – 9 membros). O Scrum Master é
responsável para que a equipe funcione corretamente em torno dos valores
do Scrum. Por outro lado, a principal função do Product Owner é
maximizar e otimizar valor; é responsável por problemas em relação ao
produto/serviço que possam ocorrer. E, por fim, a equipe de
desenvolvimento, que é quem deve executar as tarefas e subtarefas
necessárias para alcançar o projeto. Neste último caso, o ideal é que
seja formado por 6 pessoas.

• Qual seria o tamanho das equipes?

O Departamento de Recursos Humanos é composto por 50 pessoas,

distribuídas em 7 equipes, cada uma com um diretor.

Portanto, uma possível divisão das equipes poderia ser a seguinte: 6

equipes de 7 pessoas e uma de 8. Todos eles terão o diretor (mencionado
no comunicado), o Scrum Master e o Product Owner. Quanto à equipe de
desenvolvimento, 6 equipes terão 4 membros e um deles, 5.

• Que papéis teriam?

Os papéis são os mencionados acima. Um Scrum Master encarregado de

supervisionar se os eventos, artefatos, tarefas, etc. do Scrum estão
sendo realizados corretamente; um Product Owner que é quem vai canalizar
a equipe e será responsável por otimizar o valor do produto/serviço e
gerenciar o backlog do produto; e, finalmente, a equipe de
desenvolvimento que executa as tarefas relacionadas a um produto ou
serviço e é responsável por entregar um incremento de produto que pode
ser colocado em produção no final de cada iteração.

• Haveria diretores nas equipes?

No time Scrum não há diretores; É um papel que não existe. Sim, haverá
diretores, gerentes ou superiores no projeto, mas eles não fazem parte
do time Scrum. Além disso, o Scrum Master será responsável pela mediação
entre o restante da equipe Scrum e o diretor.

• Quais são as habilidades para cada função?

- Scrum Master: desempenha um papel muito importante, pois é o

responsável máximo pela correta aplicação do framework Scrum, mas
nunca de forma exaustiva, mas com recomendações, conselhos e
sugestões; explica para pessoas de fora quais interações precisam
ser feitas, bem como como promover um bom relacionamento entre a
equipe e gerentes e diretores; Ele incentiva, em suma, que você
trabalhe corretamente sob Scrum, fazendo as mudanças necessárias
para melhorar a qualidade do produto.

- Product Owner: você deve conhecer perfeitamente o produtor ou

serviço que deseja desenvolver para gerenciar o backlog do
produto, tirar o máximo proveito da equipe de desenvolvimento
para maximizar o valor do produto a ser desenvolvido. Também é
importante que você filtre possíveis solicitações de membros da
 organização que não fazem parte da equipe Scrum para não desviar
os desenvolvedores de suas tarefas.
- Equipe de desenvolvimento: eles se organizam já que ninguém deve dizer
quais tarefas executar ou como realizá-las, eles têm conhecimento
em diferentes áreas o que lhes permite criar um aumento de
produto, todos têm o mesmo papel dentro da equipe para que nenhum
se destaque acima dos demais e, É para este último, que a
responsabilidade final é de cada membro, independentemente de sua
especialização.

4. Que eventos teriam? Qual seria a duração dos sprints? Quem os facilitaria? O
que fazer se a maioria dos membros da equipe não quiser planejar?

- Sprint: representa uma iteração onde o restante dos eventos do

Scrum ocorrem. Eles geralmente duram 2 ou 3 semanas, nunca
excedendo 4 semanas.
- Diária: É uma reunião que acontece todos os dias com 15 minutos de
duração.
As tarefas a serem executadas nas próximas 24 horas estão
previstas.
- Revisão: é a revisão do sprint, ou seja, é valorizado o que foi o
aumento feito nas semanas que o sprint durou. Além disso,
considerações apropriadas serão feitas sobre o que melhorar para
otimizar o valor.
- Retrospectiva: É o último evento da sprint, em que a equipe se
inspeciona e onde é criado um plano de melhoria que será
implementado na próxima sprint.
- Refinamento: não é um evento Scrum, mas é importante já que é
utilizado
Para gerenciar a lista de pendências do produto (adicionar ou
remover itens, reordená-los, etc.)

Eles são facilitados pelo Scrum Master, ou seja, é ele quem deve incitar
o restante da equipe a realizar esses eventos.

Sobre o último ponto; o principal é a escuta ativa que o Scrum Master

deve ter com o restante da equipe e, em seguida, explicar detalhadamente
por que o framework Scrum deve ser seguido e os benefícios desses
eventos.

5. Como você sugeriria que as placas ficassem? (Máximo 6 colunas).

Nesse caso, seria escolhido um quadro de 5 colunas: Sprint Backlog (onde

aparece a pilha da sprint atual), Fazer (as tarefas que precisam ser feitas
naquele momento), Fazer (as atividades que estão sendo realizadas no
momento), Testar (o que foi feito está sendo revisado para poder dar a
aprovação ou não) e Feito (as tarefas que passaram pelo filtro e são as
listou como feito).

No quadro físico (fólios) ou virtual (Asana, Trello, etc.), faça capturas de

tela indicando como o quadro estaria nas seguintes fases:
 Início do primeiro
sprint

Fim do primeiro
sprint

• Metade do segundo
sprint

Como o gráfico planejado versus planejado seria previsível? realizado entre

6
. os sprints 5 a 9? Inclua captura e comentário.

Velocidade prevista vs velocidade

real
O gráfico planejado versus planejado A realização reflete as possíveis
divergências entre a velocidade que havia sido estimada antes do sprint e a
velocidade real de trabalho da equipe. Sabe-se que durante as primeiras
iterações essas divergências se acentuam; Algo normal se falarmos de equipes que
acabaram de começar a adaptar essa metodologia ou uma nova tecnologia, por
exemplo. Entre os sprints 5 a 9 (a equipe vem trabalhando há vários meses ou até
mais de um ano), pode-se ver que nessas iterações a equipe está em melhoria
contínua. Embora, como você pode ver, às vezes fique acima ou abaixo da
estimativa, mas sempre perto dela. Da mesma forma, apresenta uma tendência
crescente até atingir seu limiar de eficiência.

7. Como seria o gráfico de burn-down no sprint 2? E no sprint 6? Inclua captura

e comentário.

No sprint 2, a equipe ainda é imatura, então, como visto no gráfico abaixo, a

linha vermelha sobe várias vezes em vez de descer. Isso é verdadeiro quando
tarefas adicionais precisam ser executadas. A solução seria informar o Product
Owner para remover alguns elementos com baixa prioridade, já que tudo não
poderia ser finalizado.
Agora, no sprint 6, você pode ver como a equipe funciona muito bem. Nos
primeiros dias, eles não conseguem concluir nenhuma tarefa, mas à medida que
o sprint progride, a equipe termina itens da lista de pendências do produto.