“O Bêbado e a Equilibrista”, uma composição de João Bosco e Aldir Blanc imortalizada na voz de Elis Regina, retrata em versos uma época de exceção em nosso país. Essas duas figuras caricatas, a do Bêbado cujo vício, serve como desculpa para fazer irreverência “Pra noite do Brasil” e a da Equilibrista que “Dança na corda bamba de sombrinha”, mas que “em cada passo pode se machucar”, retratam o estado de como as pessoas viviam na época. 

Muitos de nós, gerentes, desenvolvedores ou clientes de projetos de software, atuamos em nosso dia-a-dia como essas caricaturas de Bosco e Blanc. Não mudamos a forma de conduzir os projetos que participamos, ou seja, o vício do Bêbado, apesar de continuamente não cumprirmos com os prazos e com os custos estimados e, adicionalmente, entregar valor embutido nas funcionalidades que desenvolvemos aquém da expectativa do cliente. Continuamente nos esforçamos para atender a essas expectativas com prazo de desenvolvimento irreal, pois são estipulados sem fundamento teórico, equilibrando com custos que desconhecemos. Obviamente podemos nos machucar como a Equilibrista em uma corda bamba.

O Scrum é o framework que permite mudar esse cenário. Parte de uma estratégia simples: “Dividir para Conquistar”. Um grande projeto é dividido em releases, como aquelas com as quais nos acostumamos a ver em aplicações Web 2.0. Essas releases, por sua vez, são quebradas em sprints, períodos de tempo normalmente fixados entre 15 e 30 dias, que tem um requisito fundamental: entregar valor para o cliente. Para acontecer, as releases são desmembradas em histórias, que tem normalmente uma relação direta com as funcionalidades solicitadas. Por último essas histórias são fracionadas nas atividades nas quais as pessoas que desenvolverão o produto trabalharão. O primeiro paradigma mudado é função direta da estratégia. A cada período de 15 a 30 dias o cliente confirma que recebeu o valor.

Comparando com métodos tradicionais, onde meses passam-se para isso acontecer, percebemos uma grande diferença. O cliente, que no jargão desse framework é apelidado de “Product Owner” (PO), ou representado pelo mesmo, prioriza, de um conjunto de histórias que recebe o nome de “Product Backlog”, quais são aquelas que serão entregues na próxima sprint. Aqui reside, em minha opinião, uma característica fundamental do Scrum. Como a lista de histórias a ser desenvolvida é definida para cada sprint, ao final do projeto, somente as histórias importantes, ou melhor, que realmente agregaram valor, foram desenvolvidas. Levantamento feito por especialistas mostra que 80% das funcionalidades desenvolvidas em projetos de longa duração são utilizadas uma ou nenhuma vez ao longo da vida útil do software. Isso é benefício direto.

Priorizadas as histórias, aglutina-se em uma sprint o número de histórias que aquela equipe é capaz de entregar. Ao término de uma sprint, havendo um desalinhamento de produtividade, medidas gerencias são adotadas pelo “Scrum Master” , um facilitador para o trabalho da equipe, e pela própria equipe com dias de projeto em andamento e não após meses.

Como já discutido em post anterior nesse blog, o estado de uma história é binário (concluído ou não concluído). Esse é outro benefício do Scrum. Problemas não podem ser mascarados. Existem alguns modelos para estimar custos de projetos como um todo. Dois deles são o modelo de Putnam e o processo da SPR (Software Productivity Research). Apesar de distintos, ambos baseiam-se em dados históricos. Não faz parte da discussão aqui proposta aprofundar esse assunto, mas esses modelos consideram o tamanho (muitas vezes medido em número de linhas de código), produtividade (a capacidade de uma organização produzir software de um dado tamanho em um prazo determinado), esforço (medido para projetos grandes em pessoas/ano) e tempo de desenvolvimento para chegarem a um resultado. O framework Scrum apoia essas e outras metodologias ao guardar todo o histórico de desenvolvimento já discutido.

Voltando ao Bêbado e a Equilibrista, o Scrum funciona como um caminho sólido para o desenvolvimento de projetos, independentemente de tamanho, nos permitindo equilibrar prazos, custos e funcionalidades com o orçado, e eliminando vícios de metodologias de desenvolvimento próprias para outros tipos de empreendimentos como a construção civil. Por enquanto é só.

Gostaria de saber a sua opinião sobre o que escrevi. Se concorda ou não. Se faltou algo e quais são as suas dúvidas.