Histórias – Quebrar ou não quebrar?

Em uma de nossas sessoes de coaching, o ScrumMaster tinha uma pergunta do time que tinha ficado sem resposta e precisava da minha ajuda. Se uma história de usuário será realizada somente por um programador, ou seja, é um trabalho solo, devemos quebrá-la em tarefas? A idéia de particionar a história não seria visando a execução de tarefas menores que possam ser realizadas por várias pessoas?

Eu apresentei dois pontos que podem responder. Um dos primeiros objetivos seria a rastreabilidade. Afinal, se uma história é implementada por um único desenvolvedor e esse toma o sprint inteiro para executá-la, como pessoas envolvidas no projeto (direção, GPs, stakeholders…) saberão se a história será realmente entregue ao final do sprint? As tarefas, que podem ser técnicas ou funcionais, tanto faz, como recomenda-se que sejam executadas em um dia ou menos, ajudam então nessa rastreabilidade diária. Dessa forma o burndown funcionaria perfeitamente, pois todos os dias se esperaria um decremento de uma tarefa ao menos, o que faz o burndown “fluir”.

burndow_ruim

Um outro ponto importante, que vale mais como recomendação, é que as tarefas sejam sim estimadas, mas em horas. De novo eu volto a um ponto das antigas aqui. Estimativa não é deadline! Se o team member estimou que faltam X horas para concluir uma tarefa e no meio do caminho percebeu que se enganou isso é completamente aceitável e saudável. Afinal Scrum é um framework para se atingir um time de alta performance e isso só se consegue com o tempo.

Mas voltando ao burndown e sua estimativa em horas. Naquele equipe, eles montavam o burndown usando os Story Points ao invés das horas das tarefas. O problema em se montá-lo usando Story Points é de novo a rastreabilidade. Você terá uma visão de como aquela história está indo ao final dela, o que pode ser tarde demais para tentar negociar o escopo com o Product Owner. Mas isso nos leva a mais questionamentos, como por exemplo, qual é o tamanho dessa história? É relevante aos envolvidos acompanhar o desenvolvimento dessa parte do produto? Todos os envolvidos entendem que se essa história durar dois ou três dias não há como saber quais etapas dela foram resolvidas? Se a história for pequena demais e o time tem tanto dominio sobre ela a ponto de não precisar quebrar em tarefas é ótimo! Isso indica uma alta maturidade da equipe. Agora se querem parar de quebrar por que acham chato ou improdutivo, ai não vejo como interessante. Tudo tem que ter uma razão bem definida para deixar de ser feito. Imagine o Scrum como um framework baseado em patterns, em coisas que aconteceram e as pessoa enxergaram certos padrões que se repetiam e que determinadas soluções resolviam o problema. Ou seja, muito provavelmente aquela mesma solução que atendeu milhares de pessoas também lhe atenda. Ou talvez não. Mas é importante se questionar se você está deixando de fazer por comodismo, por preguiça de mudança cultural ou por que realmente a sua situação é bastante particular. A conversa nessa empresa ficou interessante quando minhas questões começaram a atingir alguma parte sensível no cérebro daquele ScrumMaster.

Ele enfim começou a se questionar o quanto seria interessante retomar essa rastreabilidade perdida e o quanto a direção se sentiria mais confortável ao ver isso num radiador de informação, como em um burndown chart. Percebam que temos dois lados da moeda aqui. Apesar de Scrum ser focado no time e no desenvolvimento do produto, temos que lembrar que ele existe no mundo real. O mundo real tem Gerentes de Projetos, patrocinadores, Gerentes de produto e mais um monte de pessoas interessados no projeto e com vontade de saber como ele anda. Assim, mesmo o burndown sendo um radiador para o time controlar o andamento do seu trabalho dentro do sprint, é também uma ferramenta muito boa para espalhar essa informação pela organização. Isso facilita o alinhamento das expectativas entre time e os demais. Individuos e interações mais do que processos e ferramentas, ou seja processos e ferramentas tem menos peso, mas tem a sua importância. Isso é mais do que um princípio só do Scrum, mas do próprio manifesto ágil.

Aquele ScrumMaster começou o que eu chamo de processo de defesa. Começou dizendo que ali sempre foi assim, que isso já estava enraizado na cultura da empresa, que agora seria complicado demais mudar para algo mais interessante. A minha resposta pra isso é sempre a mesma: porque sempre foi está correto? porque sempre foi é a melhor maneira de fazer? De novo a defesa foi que é difícil convencer aquele time de seniores sobre qualquer coisa. Esse é o momento então de propor um experimento. Tentem, se perceberem que ficou muito ruim, voltem ao jeito antigo. Inspecionar e adaptar, tudo com muita transparência. O que não pode, não deve e não é aceitável é ficarmos com um processo que não parece o melhor simplesmente porque “sempre foi assim”.

Não existe um certo ou errado, nem tudo é preto ou branco, nem mesmo os tais “ScrumButs” são coisas ruins, desde que você compreenda profundamente o porque de cada prática, terá então o embasamento correto para decidir se esse padrão que funcionou para milhares realmente não se encaixa no seu cenário.

MatrixBluePillRedPill

Posted on: 20 de julho de 2013, by : juliano

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *