Atualmente, no ambiente de Startup e de Transformação Digital, muito se fala sobre metodologia ágil e, dentre elas, acredito que o framework mais comentado é o Scrum. Muitas Startups têm adotado Scrum para tentar navegar neste contexto de alta complexidade e muita mudança, e na Salvus não foi diferente. Estudamos o Scrum Guide, entendemos a importância dos artefatos, dos eventos e de composição do time. Quando começamos a seguir o Framework Scrum, logo no início, caiu a ficha sobre o significado da emblemática frase:
“Scrum é fácil de entender mais muito difícil de dominar.”
Entender os conceitos do Scrum Guide e perceber o potencial desse Framework é muito simples. Porém, colocar isto na prática com todas as pessoas necessárias, respeitando o core do Scrum, e continuar fazendo isso durante um tempo prolongado é extremamente complicado.
Nesse post eu gostaria de dar um salto e comentar sobre um dos grandes desafios de se executar um Framework ágil e sentir que realmente o Scrum vale a pena. O desafio se chama Estimativa de Atividades ou de Users Stories. Esse assunto extrapola o escopo do Scrum Guide e apenas define alguns conceitos sobre o tema, como por exemplo:
Quem deve estimar os Users Stories é a pessoa ou o time que vai executar; Uma atividade deve ser capaz de ser finalizada dentro do Sprint.
Vamos parar com o blá blá e vamos falar um pouco sobre Story Point e a estratégia para superar esse desafio.
Story Point É Sobre Velocidade
Eu fui bastante influenciado por Mike Cohn, que é um dos fundadores do Agile Alliance e do Scrum Alliance, escritor dos livros User Stories Applied for Agile Software Development, Agile Estimating and Planning, e Succeeding with Agile, o que me ajudou bastante a chegar nessa definição.
Story Point é uma unidade de medida relativa para estimar o esforço necessário para finalizar um determinado User Story.
Confuso, né? Vamos recapitular para entender melhor… O Product Backlog é uma lista de itens ordenada de tudo o que é conhecido como sendo necessário para um produto/serviço. Estes itens são conhecidos como os Users Stories (Eu como… Quero… Para…) e o time de desenvolvimento precisa informar o esforço necessário para realizar completamente cada User Story, ou seja, é uma estimativa de esforço.
Dentro do mindset ágil, umas das técnicas mais comum para realizar estimativa de esforço é o Planning Poker que funciona da seguinte forma: usando um baralho de 5 cartas com os números 1, 2, 3, 5 e 8 (Sequência de Fibonacci), os membros do time envolvido na User Story revelam, no mesmo momento, uma carta com o valor que achar coerente para aquela atividade. É importante que este procedimento seja seguido para que se retire a influência de um membro sobre o outro, caso não haja um consenso. Os membros do time que mostraram a carta com o maior e menor valor devem fazer suas considerações e em seguida, uma nova rodada do Planning Poker deve acontecer.
Os números da Sequência de Fibonacci foram escolhidos para ajudar na comparação de atividade, já que, por definição, Story Point é um medida relativa. Vamos a um exemplo: a User Story A recebeu uma pontuação equivalente a 1 (Story Point = 1) e estamos analisando a User Story B. Uma estratégia para se definir a pontuação da User Story B é fazer uma comparação com User Story A, estimando-se o esforço de execução da atividade B relativo à atividade A. Desta forma, se, para se para entregar o User Story B é necessário o dobro do esforço do User Story A, o User Story B recebe uma pontuação equivalente a 2 (Story Point = 2). O intuito de usar uma unidade de medida relativa é facilitar a comparação com outras Users Stories.
Na minha opinião o maior valor agregado do Story Point é a possibilidade de visualizar de maneira rápida e clara qual a velocidade do time. É possível visualizar esse número somando os Stories Point de todas as Users Stories entregue no Sprint. A velocidade do time é o fator mais importante a ser monitorado dentro de um Framework Ágil, caso se queira alcançar aquela Arte falada no título do livro mais famoso do Scrum de Jeff Sutherland, “Scrum – A arte de fazer o dobro na metade do tempo”. Se me permite, o Agile Manifest trata basicamente sobre as condições (Valores e Princípios) necessárias para que o time entregue valor de maneira rápida ao cliente. Outra característica muito importante sobre o Story Point, é a democracia. Tem uma história que o Mike Cohn conta, bem interessante para ilustrar este ponto. Imagine dois competidores de corridas amadoras, Alice e Bob. Alice convida Bob para correr um percurso de 5 Km e fala que vai tomar 30 minutos, porém Bob é mais lento que Alice e fala que para correr esse percurso ele levaria 60 minutos. Diante deste conflito, e eles entram em discussão:
Alice: – Bob, são 5 km! Isso vai durar 30 minutos.
Bob: – Eu concordo Alice, são 5 km! Mas vai levar 60 minutos.
“Levam 60 minutos! Não, Levam 30 minutos, 60, 30, 60, 30”
O problema nessa discussão é que ambos estão certos. Eles possuem habilidades diferentes e, com isso, executam atividades em tempos diferentes. Mas o que acontece quando usamos uma medida mais abstrata, nesse caso a distância que é 5 km, ambos concordam. Isso acontece no time de desenvolvimento que normalmente possuem pessoas de diferentes capacidade e habilidades, mas que vão estimar o mesmo User Story. Então, o que é preciso entender é que a discussão é sobre esforço, e não tempo, já que o tempo é diferente para cada indivíduo.
Pense Duas Vezes Em Relacionar Story Point com Tempo
O primeiro ponto que quero tocar sobre não relacionar Story Point com Tempo é um estudo conhecido como The Cone of Uncertainty de Steve McConnel, autor do livro Software Estimation. O estudo tem como foco mostrar a alta variabilidade da estimativa em tempo no desenvolvimento de software, que podem chegar até +- 4 vezes.
Outro conteúdo bem interessante sobre estimativa de esforço em tempo é a Lei de Parkinson, que diz “O trabalho expande-se de modo a preencher o tempo disponível para sua realização.” por C. N. Parkinson. Com outras palavras o que a Lei de Parkinson quer dizer é, se você tiver uma tarefa que demoraria 30 minutos para fazer, mas o seu prazo é de um dia, você provavelmente terminará ela em um dia. Se você tiver uma reunião, que poderia ser feita em 10 minutos e você alocar 1 hora para ela, 1 hora será gasta. Essa é a essência da “Lei de Parkinson”, revelada pela primeira vez em 1955, pelo historiador Cyril Northcote Parkinson, no The Economist. Parkinson disse: “O homem mais ocupado é o que tem mais tempo livre”.
Texto original em: https://linkedin.com/Caio-Cesar
