SCRUM, a ordem nascida do Caos - parte 1

Por Cesar Brod

Data de Publicação: 31 de Outubro de 2006

Depois da excelente apresentação do Alexandre Marcondes no encontro do grupo SOLIVRE-PR em Ivaiporã, parei para pensar há quanto tempo estou envolvido com gestão de projetos e o quanto pude aprender com a experiência alheia. Já cheguei a fazer apresentações sobre o que chamei de "evolução de uma metodologia orgânica de desenvolvimento", contando especialmente a história que levou ao desenvolvimento de vários dos sistemas da Solis. Posso dizer que, especialmente a partir de 1993 (mesmo ano em que conheci o Linux) fui me envolvendo de maneira crescente com a gestão de equipes e projetos. Como vim da área de suporte de hardware e as primeiras equipes que gerenciei trabalhavam com o suporte a clientes, estava já acostumado com o imprevisível quando, gradualmente, fui migrando para a gestão de ambientes e desenvolvimento de software. Talvez por ser virginiano (até demais, como alguns dizem), sempre me interessei por metodologias de trabalho que levassem a uma maior satisfação e produtividade, com liberdade de ação e valorização de talentos. Programação é, antes de tudo, uma arte. Mas antes disto, todo o trabalho bem feito é uma obra de arte. Assim, devemos conciliar nosso compromisso de "entregas" para nossos clientes com alguma forma de darmos a devida "liberdade criativa" aos que estão produzindo. Com uma freqüência maior do que eu gostaria, ouço pessoas dizerem que, muitas vezes, não existe a "maturidade" suficiente para que se permita um trabalho sem um absoluto controle, que as pessoas não podem trabalhar "soltas". Eu aprendi que, devidamente motivada, a pessoa trabalha dentro dos horários aos quais se impõe e entrega seus projetos dentro dos prazos (mesmo que, por vezes, tenha que renegociá-los) com a alegria de que fez algo porque quis e não porque foi obrigada a fazê-lo. Clientes, gestores e equipes envolvidos em um projeto devem concordar em uma visão, um plano de ação e serem todos cúmplices de sua execução. A transparência deve existir do início ao fim do projeto, da sua negociação comercial à sua entrega e aceitação. A motivação para a realização do trabalho se constrói através da visão da produção de um bem comum, que servirá a todos os envolvidos não só como um produto final, mas como uma oportunidade de aprendizagem e interação com outras pessoas. Cada um que trabalha no projeto deve sentir-se automotivado pela vontade de aprender, crescer, ser remunerado de acordo e fazer parte de um ambiente que valoriza seu potencial e respeita sua liberdade.

Já escrevi aqui no Dicas-L um artigo sobre Extreme Programming. Recebi uma série de comentários no artigo e através do link de contato com a Brod Tecnologia. Várias pessoas disseram-me que têm usado o artigo como uma introdução ao Extreme Programming para suas equipes de trabalho e colaboradores. para estas pessoas e para o Alexandre Marcondes, que me apresentou ao SCRUM, que dedico esta série de artigos sobre o tema.

Meu livro de cabeceira sobre engenharia de software ainda é o The Mythical Man Month, escrito em 1975 por Frederick Brooks. Ele acaba passando pouco tempo na minha cabeceira pois sempre o empresto quando há a necessidade ou quando eu sinto que o livro pode ajudar. Este livro influenciou tanta gente que uma busca no Google sobre o tema já praticamente permita que você absorva as idéias do autor sem necessariamente ler o livro. Se o inglês não é uma língua familiar para você, tente os resultados em português. Mas se a falta do conhecimento da língua inglesa é realmente o seu caso, você deveria se preocupar. A falta de conhecimento da língua inglesa é um dos principais pontos de bloqueio no avanço em uma carreira na área de informática.

Mas voltando ao livro, Frederick observa que, quando um projeto está atrasado, adicionar pessoas ao projeto servirá apenas para atrasá-lo ainda mais. Ele também diz que devemos considerar o tempo que perdemos em gestão e comunicação quando temos pessoas demais trabalhando em um projeto e que ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobrá-lo, pois é muito fácil esquecermos que o programador precisa de "tempo para pensar" além do "tempo para programar". A forma simples e objetiva com a qual Frederick via as coisas já em 1975 caem como uma luva para as, hoje, chamadas metodologias ágeis de desenvolvimento. As metodologias ágeis destacam-se por reconhecer que mudanças acontecem no decorrer do desenvolvimento de um projeto e que o cliente deve estar envolvido e presente durante sua execução. Esta presença é necessária porque a interação entre as pessoas será constante e o produto final deve ser amigável a ponto de, praticamente, prescindir de documentação.

A metodologia SCRUM complementa as práticas de Extreme Programming e, a meu ver, acaba servindo tanto como uma evolução para aqueles que já usam Extreme Programming como um excelente ponto de partida para a aplicação destas práticas. Por isso, recomendo que, os leitores que quiserem me acompanhar neste aprendizado (sim, ainda não sei nada de SCRUM e estarei aprendendo com vocês), comecem pela leitura de meu artigo anterior e voltem a se encontrar comigo na próxima semana.

Para dar um gostinho, apenas conto o porque do nome SCRUM. No jogo de rugby, o "scrum" é a forma de reiniciar o jogo após uma falta acidental ou outro incidente onde não é possível determinar quem cometeu a falta. No basquete acontece de forma similar quando o juiz não consegue determinar para qual time deve ir a bola e a joga para cima à frente de um jogador de cada time. Só que, no rugby, todos os jogadores se posicionam em um bolo humano para competir pela bola no reinício de jogo. Não é tão simples como eu descrevi, há regras quanto à forma como a bola deve ser retomada, mas já dá pra ter uma idéia. O termo foi associado ao desenvolvimento pela primeira vez no livro The New Product Development Game, de Hirotaka Takeuchi e Ikujiro Nonaka. Neste livro, os autores dizem que deve ser adotada uma forma de desenvolvimento onde toda a equipe trabalha como uma unidade para atingir um objetivo comum. Exatamente como é feito quando se tem que recuperar a bola em um "scrum" no jogo de rugby.

Até a semana que vem!