SCRUM e o caso do “Muito cacique pra pouco índio.”

Trabalhar no setor de tecnologia de uma empresa normalmente te coloca em uma posição de “Muito cacique pra pouco índio.” aonde os demais setores da empresa possuem necessidades individuais e tudo é “urgente”. Se esse fluxo de entrada não for corretamente gerenciado haverá degradação de produtividade, qualidade e bem estar da equipe.

O maior problema nesta situação são as interrupções contínuas no trabalho da equipe. Toda vez em que um setor possui uma necessidade “urgente” acontece esta interrupção. Muitas vezes devido a pessoa que chefia o setor gritar mais alto e convencer a equipe a parar tudo o que está fazendo para atendê-lo. Outra forma que isto acontece é o pedido vir “de cima”, e normalmente quem está pedindo é um “mensageiro” desta outra pessoa com mais poder…

Uma forma muito eficiente de lidar com esses casos é a utilização de metodologias ágeis como o SCRUM. No SCRUM cria-se uma lista de tarefas a serem executadas em ordem de prontidão e prioridade. Note que prontidão vem antes de prioridade, pois nenhuma tarefa que não esteja pronta a ser executada pode estar no topo da lista.

Tarefa pronta para execução

Estou utilizando o nome tarefa e não requisito, pois a equipe de SCRUM é multidisciplinar e não focado apenas em desenvolvimento de software. Na lista de tarefas teremos itens diversos como análise, prototipagem, teste, certificação de qualidade e qualquer outra necessária à equipe para a entrega de um incremento de trabalho.

Uma tarefa é considerada pronta para execução quando ela está bem definida, ou seja definida a um nível satisfatório para a equipe. A tarefa deve estar também subdividida nas suas menores partes, o que deve ser feito pela própria equipe em etapas de refino da tarefa.

Essa subdivisão em etapas ou sub-tarefas é muito importante pra evitar esquecimento de itens necessários, outro benefício é que ao definir as etapas que compõem o trabalho a ser executado já se definem indicadores de progresso. As sub-tarefas ajudam ainda a definir possibilidade de trabalho em paralelo.

Backlog, a lista ordenada de tarefas

Chama-se backlog a lista ordenada de tarefas a serem executadas. Elas podem estar bem definidas ou não. A ordenação da lista se dá pela prontidão da tarefa e pela prioridade. Como disse acima a ordem de prontidão é mais importante do que a ordem de prioridade, pois preza-se pela qualidade do produto e incerteza induz ao erro.

Os responsáveis pela lista de afazeres são os clientes, não a equipe. Esse é o fato mais importante do backlog. Ele é de responsabilidade do cliente, do stakeholder, do proprietário do produto (product owner). Note que escrevi em singular, sim deve haver apenas um.

Esta pessoa é a responsável em realizar a conversa com as demais equipes, criar o backlog, refiná-lo e ordená-lo. Lógico que ela pode ter ajuda da equipe, mas possui palavra final na gestão do backlog. Normalmente na TI é o gerente de projeto(s) que se reúne com os clientes e ordena as necessidades.

E é na formação e no refino do backlog que se exclui o problema de “muito cacique pra pouco índio”. Para se definir o backlog e refiná-lo até que as tarefas do topo estejam a ponto de execução realizam-se reuniões com os clientes de forma que eles conversem entre si e organizem seus pedidos visualizando o todo.

A transparência de deixar todos os setores da empresa vislumbrarem a lista de coisas a serem feitas leva a um maior entendimento da carga de trabalho da equipe. Por estarem todos vendo o que vai ser feito, os próprios solicitantes podem discutir entre si a ordem de execução. Retira-se o ônus da equipe em organizar a ordem de entrega, esta já vem acordada entre os “caciques”.

Uma vez acordada que as N primeiras tarefas serão colocadas para execução – que pode ser desenvolvimento, teste, análise, captura de requisito ou prototipagem, entre outros – estes itens são retirados da lista e não mais podem ser alterados. Eles formam o backlog do Sprint, que é de propriedade e responsabilidade da equipe de desenvolvimento. Faz-se o acordo entre a equipe e o cliente que aquelas tarefas serão entregues no final do período de trabalho (1, 2, 3 ou 4 semanas) e somente elas serão entregues.

Fecham-se as portas e iniciam-se os trabalhos. Diariamente são realizadas reuniões de 15 minutos para dar atualizações sobre o trabalho, levantam-se impedimentos e definem-se ações a serem tomadas para o atingimento da meta.

Ao se isolar a equipe de desenvolvimento é excluída a possibilidade de interrupção e só é possível adicionar novas tarefas ao que está sendo feito se alguma outra coisa sair da lista. E isto envolve discutir com as pessoas que possuem itens sendo executados, entre os caciques e não pela equipe. Fica o Scrum Master encarregado de evitar quaisquer desvios do planejado, sanar quaisquer impedimentos e impedir que problemas externos adentrem a equipe de desenvolvimento. Então é de sua responsabilidade tratar das mudanças de prioridades enquanto a equipe trabalha sem interferência.

Comments are closed.

%d bloggers like this: