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

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