Archive for November, 2009

Derrubaram as Paredes Erradas

Saturday, November 14th, 2009

Neste curto período no Brasil eu tive a oportunidade de conversar com muita gente, tanto do Rio quanto de outros locais que vieram para workshops ou eventos. Como não é novidade para ninguém o Brasil está cada vez adotando mais metodologias menos burras -ou “ágeis” se você preferir.

E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.

Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!

Só cuidado para não quebrar as barreiras que protegem o time.

Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.

E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.

Não vai.

Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.

Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.

Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.

Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.

E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.

E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.

A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.

Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.

Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”

Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.

Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.

E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.

É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.