Estimating and planning are critical to the success of any software development project. Foi com essa citação de Mike Cohn que Raphael Rodrigues começou o SoftDrops do dia 24 de outubro, no qual discutiu Métricas e Estimativas Ágeis. O QA propôs tal tema ciente da sua importância para os processos de trabalho, principalmente em relação à priorização e prazos para entregas.
Estimativas
Uma estimativa é uma avaliação ou cálculo aproximado de algo que se baseia em evidências já conhecidas. No caso do desenvolvimento de software, estimar objetiva alinhar a finalidade da Sprint, visto que ela sempre possui uma meta a ser alcançada; e proporcionar o diálogo, pois geralmente nos times existe alguém que é referência técnica.
“Essa pessoa influencia as outras em uma determinada direção e estimar oportuniza a troca de conhecimentos entre profissionais de diferentes áreas e níveis. Com o intuito alinhado e o diálogo aberto, a entrega da Sprint é facilitada e o time todo evolui, pois aprende em conjunto”, explicou Raphael.
As estimativas mais utilizadas são Fibonacci e T-Shirt Size (P, M, G). Para o QA, enquanto a primeira é mais específica, a segunda é mais genérica, pois não se preocupa com a diferença do meio para o um, do um para o dois, ou do um para o três, por exemplo. “A T-Shirt Size não questiona as diferenças neste contexto. Utilizamos P, M e G e convertemos para a quantidade de dias necessários, na média, para concluir uma tarefa de determinado tamanho”, salientou.
Métricas
As métricas de software são baseadas nas estimativas e permitem identificar as quantidades de esforço, custo e atividade que serão necessários para realização de um determinado projeto. Entre elas estão a Capacidade da Sprint, o Work in Progress, o Lead Time e o Cumulative Flow Diagram.
Raphael esclareceu que a Capacidade da Sprint revela quantas funcionalidades o time consegue entregar por Sprint. Já a Work in Progress, ou WIP, diz respeito a todo o trabalho já iniciado, mas ainda não finalizado. “É o clássico quase pronto, ou seja, a funcionalidade não passou por todo o ciclo de desenvolvimento. Quanto mais tempo ela estiver parada, sem ser finalizada, menos feedback o time recebe, e aí o desenvolvimento deixa de ser ágil”, destacou o QA.
O Lead Time, por sua vez, é a informação de quantos dias demorou do início ao fim de determinada tarefa de tamanho P, M ou G. Ele pode conter user stories, tarefas, bugs, incidentes, entre outros. E o Cumulative Flow Diagram mostra todos os itens do backlog em conjunto, quantos foram finalizados, quantos estão em progresso e quantos ainda restam ser feitos. Para Raphael, “essa métrica pode ser muito interessante pois mostra o histórico do time durante o projeto, permite negociações com o cliente e possibilita a aplicação de melhorias para os próximos trabalhos”.
