Fique por dentro – Concurso de TI! Comentando uma avaliação discursiva sobre o Framework Scrum – Parte 1

Faaaaaala seus lindos!!! Tudo bem com vocês?

Estamos cada vez mais nos especializando em dissertar sobre diversos temas relativos ao Gerenciamento Ágil de Projetos, e o Framework Scrum é novamente nosso tema de estudos!!

Nesse artigo vamos comentar uma avaliação discursiva da Fundação de Previdência Complementar do Servidor Público Federal do Poder Executivo (Funpresp-EXE), para o cargo de Analista de Previdência Complementar – Área de Atuação: Tecnologia, aplicada em janeiro de 2022 pela banca Cespe Cebraspe.

Esse artigo traz a análise dos itens I a III da prova, e no artigo que denominamos “Comentando uma avaliação discursiva sobre o Framework Scrum – Parte 2”, analisamos os itens IV a VII, e assim vamos tornando o nosso estudo mais leve!!

Essa avaliação cobrou de forma muito abrangente os conhecimentos sobre o Framework Scrum. Vejamos:

Ao assumir o cargo de product owner de uma organização, um servidor verificou, junto ao gestor da área de TI, as necessidades de desenvolvimento de novos sistemas e de manutenção — corretiva ou evolutiva — de sistemas já em produção. Concluindo que a área XYZ necessitava de um sistema novo para substituir as atividades manuais, o referido servidor nomeou outro servidor como scrum master para atender as demandas desse sistema. Nesse contexto, foram realizadas as atividades numeradas a seguir.

I Ao receber a demanda, que deveria ser concluída em 30 dias, o scrum master, sem contato com outras pessoas, elaborou um kanban com todas as tarefas a serem desempenhadas pela equipe, de modo que ele pudesse gerir o product backlog e publicar o product goal.

II O scrum master enviou o kanban para o product owner, para que este criasse um plano imutável para alcançar o sprint goal. 

III Após a elaboração do kanban com os cartões para cada requisito, o product owner solicitou que apenas o scrum master realizasse a priorização dos cartões, de modo a elencar os requisitos mais importantes a serem desenvolvidos, e que criasse o sprint backlog, responsabilizando-se pela ordenação de seus itens.

IV Ao se iniciar efetivamente o desenvolvimento do sistema para a área XYZ, houve a incidência de vários impedimentos ao progresso do scrum team, os quais foram levados ao conhecimento do gerente de TI, quem, por sua vez, afirmou que a remoção dos obstáculos era função dos developers.

V No sprint planning, por meio de discussão com o product owner, os developers selecionaram os itens do product backlog a serem incluídos na sprint atual.

VI Ao longo do desenvolvimento, o scrum team percebeu que a primeira sprint do projeto não iria ser concluída em um mês, tal como combinado; então ficou decidido em reunião diária, no 20.º dia da sprint, que a sprint seria estendida por 20 dias ou mais, sem prazo fixo, sendo possível também modificá-la, incluindo-se mais tarefas,

de modo a ser entregue o melhor para o cliente.

VII Durante uma reunião, o product owner esclareceu que, no momento em que um item do product backlog satisfaz à definition of done, nasce um increment. Ficou acertado que poderiam ser criados múltiplos increments dentro de uma sprint, inclusive com a possibilidade de um increment poder ser entregue aos stakeholders antes do fim da sprint.

Após observar essas atividades, o gestor da área de TI encontrou problemas em cinco delas.

Considerando a situação hipotética precedente, redija um texto analisando cada uma das atividades numeradas de I a VII. Em seu texto, ainda, identifique, à luz do Scrum 2020, as atividades que apresentam problema, explicitando qual é o problema e qual deve ser

a respectiva solução.

Então vamos dividir para conquistar!! Essa é nossa técnica infalível. 

No item I, o enunciado diz que ao receber a demanda, o scrum master, elaborou, sozinho, sem a participação do time Scrum, um kanban com todas as tarefas a serem desempenhadas pela equipe. 

Nós já sabemos que o Product Owner é o responsável pela gestão eficaz do product backlog e também, por maximizar o valor do produto resultante do trabalho do time scrum que pode ser organizado em um kanban. Isso inclui desenvolver e comunicar explicitamente a meta do produto – product goal, além de criar e comunicar claramente os itens do product backlog. 

Nós sabemos que o time scrum é formado por Scrum Master, Desenvolvedores e Product Owner, e portanto, para criar o quadro Kanban, não faz sentido fazer isso sem a participação do P.O., que é o responsável pelo backlog do produto, e tampouco sem a participação dos Desenvolvedores, que vão executar as tarefas.

Assim, os problemas do Item I foram identificados e como solução do problema, é necessário envolver a equipe, principalmente o P.O., que é o responsável pelo product backlog.

Já o item II, menciona que o scrum master enviou o kanban para o product owner, para que este criasse um plano imutável para alcançar o sprint goal. AAHH, aí ficou fácil perceber o problema: Plano imutável não tem guarda nenhuma relação com as práticas ágeis que estudamos até aqui, não é mesmo?

Lembre que de acordo com o Manifesto Ágil, nossa fonte mais primitiva sobre práticas ágeis, as mudanças são bem-vindas, e portanto, não faz sentido para os praticantes de scrum, que é um framework ágil, criar um plano imutável.

Gestão Ágil guarda forte relação com adaptação, e, portanto, precisamos lembrar que os desenvolvedores são sempre responsáveis por adaptar o seu plano, todos os dias, na direção da meta da sprint, ou, sprint goal.

Analisando o item III, a questão menciona que depois da elaboração do kanban, o product owner solicitou que APENAS o scrum master realizasse a priorização das atividades representadas pelos cartões, e ainda, que criasse o sprint backlog, responsabilizando-se pela ordenação de seus itens.

Aqui são dois os principais problemas, de acordo com o Guia Scrum 2020. Vejamos:

1. Já falamos que o product owner, ou apenas P.O., é responsável pela gestão eficaz do product backlog, que inclui ordenar os itens do product backlog. Ele é quem deve priorizar os itens do Product Backlog para que possam então fazer parte, em algum momento, de um Sprint Backlog. O product owner pode delegar essa tarefa, mas, independentemente disso, ele ainda é o responsável por essa importante tarefa.
2. Para a criação do Sprint Backlog, todo o time Scrum deve ser envolvido, pois não faz sentido criar o sprint backlog sem a participação dos desenvolvedores, que são aqueles capazes de dizer o que é possível desenvolver dentro do timebox da sprint.

Assim, mais uma vez, demonstramos que fazer uma prova dissertativa não é nada complicado quando temos consciência do que devemos enfatizar. Ainda, como nesse caso, não são as técnicas de redação que são a prioridade da correção, e sim, a menção dos termos importantes que constam no gabarito do examinador:-)

Ah, você deve ter percebido a marcação em negrito daqueles termos importantes, que o examinador quer ler, não é? Não vamos esquecer deles! São muito importantes!

Como mencionado, no nosso artigo “Comentando uma avaliação discursiva sobre o Framework Scrum – Parte 2”, analisamos os itens IV a VII, e assim, teremos o padrão de respostas completo para essa questão tão interessante elaborada pelo Cebraspe!

E antes que eu me esqueça!! Temos um curso completo de Gerenciamento de Projetos, PMBOK 6ª edição e 7ª Edição, com 500 questões comentadas em cada um, além de um curso TOP de Gerenciamento Ágil de Projetos  abordando o Manifesto Ágil, o framework SCRUM, a metodologia eXtreme Programming – XP e o Kanban, com muitas questões comentadas, como sempre! 

Bora estudar!!

Um grande abraço!!

Professor Darlan Venturelli

Quer ficar por dentro dos concursos públicos abertos e previstos pelo Brasil?
Clique nos links abaixo:

CONCURSOS ABERTOS

CONCURSOS 2023

Receba gratuitamente no seu celular as principais notícias do mundo dos concursos!
Clique no link abaixo e inscreva-se gratuitamente:

TELEGRAM