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.