Tarefas Pequenas

Jean Carlo Machado
BlogTech
Published in
2 min readJun 9, 2017

--

Na Compufácil utilizamos o Coderockr Way para gestão do time de desenvolvimento. Em nossa aplicação da metodologia nenhuma tarefa pode levar mais de dois dias para ser concluída. O segredo desse raciocínio não é estritamente o período de “dois dias” o importante é haver um tempo limite pequeno para entrega de tarefas. O tempo limite permite organizarmos as tarefas de forma a terem tamanhos similares e por consequência gerarmos uma quantidade de entrega razoavelmente estável por “sprint”. Entregas similares nos possibilitam prever quanto tempo levaremos para desenvolver partes do sistema.

Nem todas as tarefas vão ter um tamanho que se encaixe nesse período de dois dias. Muitas tarefas são muito complexas para serem realizadas durante o tempo limite. Por isso existe a necessidade de quebrar as tarefas em unidades menores que componham o todo.

Essa disciplina nos força a termos muitas tarefas pequenas no board, que por consequência gera outro aspecto positivo: as entregas são pequenas e os code-reviews são pequenos. É comum menosprezar esse benefício mas na prática esse aspecto é vital. Existe um ditado que diz que “um review de 10 linhas vai ter 10 comentários, já um review de 1000 linhas não vai ter nenhum”. E a realidade prova o ditado.

Um aspecto que pode parecer negativo em ter tarefas pequenas é que as pessoas poderiam se aproveitar desse conceito para ficar criando tarefas desnecessárias a fim de procrastinar. Nossa experiência indica o contrário.

Muitas vezes acontece que, em primeira análise, uma funcionalidade parece ter complexidade X mas na verdade tem complexidade 3X. Pois alguns aspectos necessários para sua realização não foram observados durante a análise. Então uma tarefa que levaria, digamos, 1.5 dias vai levar 4.5 dias. O que fazemos nessas situações? Renomeamos a tarefa para descrever o que foi feito no período válido dela e criamos outras tarefas para completar o trabalho.

Alguns sentem que renomear tarefas é “roubar” no jogo. Entretanto é muito melhor pensar nisso como transparência. Se você passou 2 dias trabalhando em algo que então se provou ser apenas parte do trabalho que você tinha que fazer, é muito mais semântico descrever o que você fez e criar outra tarefa do que tentar reduzir a real complexidade do problema. Dessa forma nosso Kanban é muito mais próximo da realidade e não existe trabalho escondido.

Por fim, a killer feature dessa prática é o benefício psicológico. É fácil perder a motivação quando seu time aparenta não estar sendo produtivo. Com a conclusão de várias tarefas por semana a moral do time tende a ficar maior. Mais que isso, tarefas pequenas é sinônimo de entregas incrementais. O que permite uma melhora contínua do sistema perceptível para os clientes, que também ficam contentes.

Se você ficou interessado no Coderockr Way e quer saber mais o Elton Minetto tem uma série de vídeos explicando o processo. Também fique atento ao nosso blog para mais novidades.

--

--

I care about science and humanism. Programmer, teacher, philanthropist, violinist.