Rafa Nascimento

O Caminho da Felicidade

Posted in backlog, time by Rafa Nascimento on 12/06/2011

Transparência é um dos valores do Scrum. E é um valor fundamental para que o sentimento de confiança, tão importante em projetos ágeis, cresça saudável em um ambiente ágil. Confiança nos liderados e confiança nos líderes. Confiança nos gestores. Transparência é fundamental para que o foco de um Time em um projeto de desenvolvimento de software mantenha-se única e exclusivamente no problema que é preciso resolver e no software que se desencadeará dessa solução. Perde-se muito em qualidade quando o foco está em sustentar pequenas mentiras. Defender uma realidade que ainda não existe e tentar fazer com que o Time, a todo custo, crie, enfim, a realidade que foi anteriormente pintada. Sem transparência, não há qualidade.

A ferramenta-símbolo de um ambiente ágil de desenvolvimento de software é o kanban. Um kanban ajuda a gerenciar um determinado fluxo de trabalho e, no caso de Times, o mesmo fica exposto para que o Time possa, por si só, gerenciar o seu fluxo de trabalho. É um radiador de informação. Quem quer que passe por ele, será “convidado” a conferir as informações nele contidas. Informações vivas e fáceis de serem lidas ou interpretadas. Diferentemente de um cronograma criado no MS Project, por exemplo. As informações ficam guardadas, como em uma geladeira. Só temos a informação quando a procuramos. Isso, se quisermos procurar. E, mesmo que imprimamos o cronograma e o coloquemos em uma parede, não seria tão simples ler suas linhas ou interpretar suas informações ou seu gráfico de Gantt. O valor de um kanban visual é enorme: radiador de informação. Bem como o Sol, que radia luz e calor sem que precisemos pedir.

Porém, um kanban é uma ferramenta que facilita a visualização do fluxo de trabalho em um sprint. Mas, qual seria uma maneira fácil de visualizar o posicionamento de um Time frente ao projeto em que se encontra? E se o Time quiser saber o percentual de completude de uma release, ou quanto falta para uma release terminar? E sobre o projeto como um todo? Quantos % do projeto cada release represente? E quantos % de uma release representa um sprint? Ou o quanto o Time terá que se esforçar para compensar um sprint perdido e manter uma boa entrega, segundo o próprio, de acordo com a data esperada para o término de uma release? O Product Backlog contém todas estas informações. Porém, estão guardadas em uma geladeira e não são de fácil acesso para o Time. Principalmente para os desenvolvedores e testadores, que estão focados demais em seus trabalhos para calcular todas estas informações. Talvez, sequer sintam vontade de chegar a estas informações. Afinal, quando uma release ou um projeto estiver próximo do seu fim, o Product Owner deixará claro. Ou eles já saberão de antemão, no início de um projeto ou de suas releases, as respectivas expectativas de término no calendário. Mas, e durante os sprints? E durante as releases? Como permitir que um Time monitore facilmente o seu avanço? Como Scrum Master e facilitador, partindo das necessidades que o meu Time tinha em relação ao seu avanço dentro do projeto e do tamanho da sua jornada, criei um jogo chamado “Caminho da Felicidade”, como mostra a figura abaixo.

 


O Caminho da Felicidade é baseado em um “mapa do tesouro”. Ao final do caminho indicado pelo mapa está o final do projeto, o tesouro perseguido pelo Time. A felicidade. A realização individual, coletiva e corporativa. Este caminho possui marcos em % a cada 10% de sua extensão e pequenas bandeiras vermelhas, que representam releases não-entregues. Ao final de cada sprint, o Time mede, sem se preocupar muito com a exatidão da informação, mas sim com a representação gráfica mais fiel possível de seu progresso, o quanto a velocidade atingida em seu sprint contribuiu para que o Time avançasse ao encontro do seu tesouro, em Story Points. A cada release conquistada, o caminho ganha uma bandeira verde no lugar da bandeira vermelha. A bandeira amarela representa 50% do projeto.

Este “tabuleiro” fica preso junto ao kanban do time. E se utiliza de uma peça (um ímã ou adesivo), que representa o Time no Caminho da Felicidade. É responsabilidade do Time atualizar as informações de tamanho de cada release, de acordo com informações conseguidas com o Product Owner, preferivelmente, a cada final de sprint. Desta forma, eles conseguem, também, manter-se atualizados do quanto o backlog está crescendo ou diminuindo perante as negociações do Product Owner com o cliente. Então cada sprint conquistado representa x% de avanço rumo a entrega de uma release e y% rumo a entrega de um projeto.

O Caminho da Felicidade é uma maneira lúdica, simples, eficiente e divertida de encarar o progresso e os percalços de um Time durante a sua jornada rumo ao objetivo maior, que é a entrega de um software que atenda as expectativas do cliente com qualidade. Da mesma forma que um kanban é um radiador de informação para um sprint, o Caminho da Felicidade é um radiador de informação para um Product Backlog, facilitando a visibilidade do tamanho e atualizações do mesmo para o Time.

%d blogueiros gostam disto: