Adolfo Sousa

Já faz algum tempo que não tenho tanta paciência para ficar discutindo metodologias ágeis para desenvolvimento de software. A minha cabeça de alguma forma passou a pensar que tudo se resume a aplicar bem o manifesto ágil. E isto, por si só, não é nada fácil. Exige muita disciplina, capacidade, atenção e profissionalismo. Nenhuma metodologia, ferramenta ou gerente vai resolver o real problema do nosso mercado: escrever software útil e de qualidade.

Danem-se os selos CMMI, as certificações do PMI e da Scrum Alliance, os programadores que enchem currículos de siglas e código de sujeira. O que vai resolver o nosso problema é gente competente, disciplinada (no sentido dado pelo Uncle Bob no seu keynote da RailsConf), capaz de ouvir o cliente e criar uma relação verdadeira de parceria com ele, com características para evoluir constantemente. Se você ou a sua empresa são capazes de fazer isso bem, não se preocupe em dar um nome para os métodos que você usa para fazer o seu trabalho. É feio sair por aí dizendo que aplica scrum (ou qualquer outra coisa da moda), encher o bolso de dinheiro e se esquecer os princípios básicos do manifesto ágil.

Esta introdução longa é para desabafar a raiva acumulada pelo monte de besteiras que eu ouvi em algumas palestras no Scrum Gathering 2009. Muita gente já escreveu e/ou tocou em pontos polêmicos sobre o evento. Quero dar os meus pitacos, então vamos ao que mais me irritou naqueles dois dias:

• Times auto-gerenciáveis - pelo menos 2 palestrantes (Ricardo Vargas e Fábio Câmara) afirmaram categoricamente que nunca viram um time capaz de se gerenciar. E somente isso. Não contaram alguma experiência ou analisaram o motivo pelo qual isso é impossível no ambiente deles. Este é um assunto muito interessante e qualquer discussão é válida.
• Ken Schwaber - imagine que você vai ter uma aula de futebol com o Ronaldinho Gaúcho e o cara gasta o tempo falando que no futebol a bola é redonda, os times têm 11 jogadores, o objetivo é fazer o maior número de gols, etc, etc, etc. Pois é, assim foi a palestra de um dos criadores do scrum. O sujeito ficou quase uma hora falando o básico e o óbvio, fez uma brincadeira mais do que manjada para falar de “comando e controle” versus “times auto-gerenciáveis” e finalizou anunciando que a Scrum Alliance vai lançar o treinamento para CSD (Certified Scrum Developer) e que este vai ser baseado em ferramentas da Microsoft. Precisa falar mais alguma coisa?
• Fábio Câmara - a palestra do Fábio foi a mais polêmica, ainda mais sabendo que ele é um CSP (Certified Scrum Practitioner). Li o título “Usando scrum com o Visual Studio Team System” e fiquei curioso para saber o que faz alguém precisar tanto de uma ferramenta para usar scrum. No meio da palestra o Fábio algumas afirmações, dentre elas: “eu questiono o uso de testes, principalmente os unitários, em projetos time-driven”; “eu tinha um estagiário que eu chamava de controller porque ele ia todo dia de manhã de mesa em mesa perguntando para o desenvolvedor se ele estava fazendo a tarefa que ele deveria estar fazendo. O VSTS me diz isso, uma vez que ele cria um link entre o requisito e o pedaço de código que foi escrito para atender aquele requisito. Eu também consigo saber quem escreveu cada linha, porque quando você pergunta numa sala ‘quem escreveu essa linha aqui?’ fica todo mundo assobiando”; “é incrível como o princípio de pareto se aplica em quase todos os projetos de software. 20% das pessoas fazem 80% do trabalho”; “os desenvolvedores, no final do dia de trabalho, fazem check-in do que eles produziram. No VSTS eu consigo ver cada check-in e passar a mão no telefone pra perguntar por cara lá em Recife porque ele subiu só 25 linhas de código quando a média dele era de umas 200″; “o scrum master e responsável por distribuir as tarefas para o time”. Logicamente algumas pessoas começaram a questionar tudo isso e ele descreveu um cenário para ‘justificar’ tudo isso: “imagine uma equipe grande. Eu já gerenciei equipes com 60 pessoas, algumas trabalhando em outros estados, etc …”. As minhas sugestões para o Fábio são as seguintes: 1) demita umas 50 pessoas da sua equipe (olha o problema do princípio de pareto sendo resolvido) e forme um time com os 20% que fazem 80% do trabalho e no qual você possa confiar e não controlar (opa, pode mandar o controller embora também). Pare de procurar culpados, isso não resolve nada, é desperdício. Se alguém fez alguma coisa errada no código, esse alguém foi o time e ele mesmo resolve (você já deve ter ouvido falar de propriedade coletiva do código e programação em par). Você não vai precisar ficar bancando o detetive pra descobrir quem foi o infeliz que escreveu a linha 1567 da classe XXXX ou bancando o leão-de-chácara do repositório. Deixe os seus programadores escreverem muitos testes e automatizá-los. 2) se vocês estão sem tempo para escrever os testes, peça a colaboração do seu cliente; explique que o time precisa escrever testes para entregar um produto de qualidade, trabalhem com ele na priorização das histórias, mostre as vantagens de desenvolver um produto iterativamente, melhorando continuamente, respondendo às mudanças. 3) pare de valorizar mais o Visual Studio do que a sua equipe. 4) nunca, jamais, de forma alguma, esqueça do manifesto ágil 5) e, POR FAVOR, pare de falar que o que você está fazendo é scrum.

Na minha opinião, o evento contou com palestras muito boas (Juan Bernabó, Alexandre Magno e Luiz Cláudio Parzianello), mas estes 3 fatos citados bastaram para fazer do Scrum Gathering 2009 - Brazil e da Scrum Alliance um baita fiasco.

É bem provável que aqueles que se interessam por metodologias ágeis de desenvolvimento já leram (ou ao menos ouviram falar) do livro Scrum & XP from the Trenches. Ele é um excelente relato da experiência prática de Henrik Kniberg com estas duas metodologias. Inspirado pela idéia de Henrik, Bob Galen disponibilizou um “rascunho” do seu livro Becoming a Great Scrum Product Owner.

Mais uma fonte para quem se interessa pelo papel de PO do Scrum e sente falta de referências na literatura especializada. Aproveitem!

http://www.rgalen.com/publications.html