Scrum - Projetos Ágeis e Pessoas Felizes

Quem me apresentou ao Scrum foi o Alexandre Marcondes em um encontro do grupo Solivre-PR (que depois tornou-se Solivre-X) em Ivaiporã, no Paraná, em 2006. Depois da apresentação do Alexandre, parei para perguntar-me quanto tempo fazia que eu estava envolvido com gestão de projetos e o quanto pude aprender com a experiência alheia. Na época, eu já havia feito apresentações sobre o que chamei de “evolução de uma metodologia orgânica de desenvolvimento”, contando, sobretudo, a história que levou ao desenvolvimento de vários dos sistemas hoje mantidos pela cooperativa Solis.

Posso dizer que, especialmente a partir do final de 1992 (mesmo ano em que conheci o sistema operacional Linux, mas essa é história para outro livro), 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. Porém, antes disso, todo trabalho bem-feito é também 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 as estão produzindo.

Com uma frequê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 e que as pessoas não podem trabalhar “soltas”. Eu aprendi que, devidamente motivada, a pessoa trabalha dentro da agenda combinada com sua equipe e entrega seus projetos dentro dos prazos 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 até a sua entrega e aceitação. A motivação para a realização do trabalho se constrói por meio 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.

Meu livro de cabeceira sobre engenharia de software ainda é O mítico homem-mês, escrito em 1975 por Frederick Brooks Jr., o qual tive a honra de traduzir para o português em 2009. Ele acaba passando pouco tempo na minha cabeceira, pois sempre o empresto quando sinto que ele pode servir a alguém. Esse livro influenciou tanta gente que uma busca no Google pelo seu título em inglês (The mythical man-month) já permite que você absorva boa parte das ideias do autor, mesmo sem ler o livro. Se o inglês não é uma língua familiar para você, tente os resultados em português. No entanto, se a falta do conhecimento da língua inglesa é realmente o seu caso, você deveria se preocupar. Não conhecer a língua inglesa é um dos principais pontos de bloqueio no avanço em uma carreira na área de tecnologia da informação e em muitas outras.

Mas, voltando ao livro, Fred observa que, quando um projeto está atrasado, adicionar novas 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 de dobrá-lo, pois é muito fácil nos esquecermos de que o programador precisa de “tempo para pensar” além do “tempo para programar”. A forma simples e objetiva com a qual Fred via as coisas, já em 1975, cai como uma luva nas 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. Essa 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 manual de instruções. O framework, o conjunto de atitudes Scrum, é complementado pelas 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 dessas práticas.

No jogo de rugby, o “scrum” é a forma de reiniciar o jogo após uma falta acidental ou outro incidente em que não é possível determinar quem cometeu a falta. No basquete, acontece algo semelhante 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 (ou entendi), há regras quanto à forma como a bola deve ser retomada, mas já dá para ter uma ideia. O termo “scrum” foi associado ao desenvolvimento, pela primeira vez, no artigo “The new new product development game”, de Hirotaka Takeuchi e Ikujiro Nonaka. No artigo, os autores dizem que deve ser adotada uma forma de desenvolvimento em que toda a equipe trabalha como uma unidade para atingir um objetivo comum. Exatamente como é feito quando se tem de avançar a bola em um “scrum” no jogo de rugby (Figura 4.3).

Além de Hirotaka Takeuchi e Ikujiro Nonaka, outros nomes estão envolvidos na conceituação e no posterior desenvolvimento das metodologias ágeis, dentre eles, Peter DeGrace e Leslie Hulet Stahl, autores de Wicked problems, righteous solutions: a catalog of modern engineering paradigms (em que o termo “Scrum” foi especificamente associado a software). Jeff Sutherland, Ken Schwaber, Mike Cohn e Mike Beedle são alguns outros nomes pelos quais você pode procurar no Google se quiser aprofundar seu conhecimento no assunto.