Suspensão da Descrença

Em Kanban, não se pode voltar uma tarefa pra fases anteriores. Como toda regra, há situações em que não se aplica. Quais? Veja nesse excelente post do grande Eduardo Zoby!

Um exemplo em especial me fez pensar.

Uma pulga atrás da orelha

O que fazer quando bugs críticos são encontrados em uma tarefa que satisfaz os critérios para revisão? Zoby explica que o time deixa a cartela em validação. Enquanto isso, subtarefas são criadas e executadas.

É uma maneira correta e funcional de modelar o processo. Como desenvolvedor, porém, sinto certo incômodo com este cenário. Por razões bobas, confesso, mas interessantes:

1. Trabalhar em algo que está “em validação” soa impreciso. Nós estamos desenvolvendo quando corrigimos falhas.
2. Pessoalmente, fico ansioso quando tenho de esperar pelo resultado de uma validação. Não há diferença prática, mas há uma psicológica. Temos agência sobre o trabalho que estamos desenvolvendo, mas não sobre o trabalho nosso que estão revisando.
3. Falta clareza na posse da tarefa. Quem é o responsável, o desenvolvedor ou o validador? O tíquete define a quem está atribuído, mas a própria coluna acaba sendo dividida entre dois papeis.

Mas… como seria uma alternativa?

Imaginando uma fábrica

Sendo Kanban inspirado por processos de manufatura, talvez um retorno às origens pudesse oferecer alguma alternativa.

Me imaginei (porque não sei nada de engenharia de produção) em uma fábrica de carros. O que acontece com um automóvel em montagem se um de seus componentes se provou defeituoso? O carro não volta na esteira de produção, mas tampouco vai ser testado. Mais crucialmente, o componente também não volta para ser consertado: ele é descartado.

Não dá para mapear um processo industrial para engenharia de software, mas a ideia de descartar o componente é instigante. Descartar os “componentes” da nossa história é um bom caminho.

Não se conserta o amortecedor enquanto se testa o carro

Como seriam os “componentes” de nossa cartela. Seriam subtarefas, mas apenas se satisfizerem duas condições:

1. são bem definidas o suficiente para serem avaliáveis;
2. são pequenas o suficiente para que possam ser descartadas.

Durante o desenvolvimento, subtarefas seriam criadas prodigamente, inclusive e especialmente se a tarefa estiver “pronta” (naquele sentido obscuro que nós programadores damos ao termo). Uma vez terminada, cada subtarefa é enviada para validação; caso falhe, é fechada e outra subtarefa é aberta. Enquanto isso, a história continua em desenvolvimento.

Imagino várias vantagens neste processo:

1. as alterações são revisadas e mergeadas gradativamente — bem à moda do trunk-based development.
2. regressões seriam descobertas mais perto da mudança que as causou.
3. estatísticas seriam provavelmente mais precisas: trabalho em bugs descobertos não seria mais computado como validação.

Certamente há pontos em aberto. O que fazer, por exemplo, se ao final a história não for aprovada? Há que se pensar. Eu tornaria a própria a revisão em uma subtarefa, mas nunca fiz isso. Como não sou engenheiro de produção, não sei o que fazem com os carros que falham ao final — talvez haja alguma inspiração la!

Um caso de uso peculiar do passado remoto

Isso tudo é um exercício mental, mas à medida que pensava, lembrei que já fiz algo similar.

Cuidei do Calendário da Liferay por anos, como uma “euquipe.” Comunicar-me com todos os stakeholders e codificar ao mesmo tempo era um desafio. Resolvi isto criando muitas subtarefas — alguns tíquetes chegaram a ter mais de trinta. Enquanto isso, os bugs e histórias permaneciam em desenvolvimento.

Às vantagens acima, somaram-se outras:

1. os pull requests menores que eram revistos rapidamente.
2. os stakeholders podiam ver o que eu estava fazendo, se quisessem.

Para um componente não-estratégico, estes detalhes foram fundamentais!

Vale a pena?

Deixar em validação ou em desenvolvimento a tarefa a corrigir é um detalhe semântico. Ainda assim, acho que pensar no assunto pode ser produtivo. Como não sou agilista, não tenho tanto know-how em definir workflows de times, mas o ponto de vista dos contribuidores individuais podem ser úteis. Quem sabe este aqui não é?