Já escrevi aqui uma série de artigos sobre SCRUM que me motivaram a novas leituras e conversas muito interessantes. Foi o Alexandre Marcondes quem apresentou-me ao SCRUM, lá em 2006 e, com o passar do tempo, acabei até traduzindo uma palestra do Mike Cohn sobre o assunto. Nesse exato momento estou refinando a palestra que ministrarei no evento Metodologias ágeis para desenvolvimento com Software Livre, que acontece no próximo dia 24 de junho na Unicamp, para a qual convidei o pessoal que trabalha comigo no Innovation Center Unicamp/Microsoft a fim de que também falem um pouco do aspecto prático do uso das ferramentas do SCRUM em seu dia-a-dia.
É justamente no dia-a-dia que o SCRUM vai tornando-se mais importante. Depois de algum tempo praticando, as ferramentas vão tornando-se um hábito. Em nossa empresa é muito comum, já em uma primeira reunião com um cliente, começar a pensar nos termos do Product Backlog, imaginando como será a formação da equipe e parceiros de desenvolvimento e nos Sprints que ocorrerão até a entrega do projeto. Quando a proposta é feita, muitas vezes em conjunto com um ou mais parceiros de negócios, ela traz embutida o Product Backlog e um cronograma que dará origem ao Burndown Chart. O perigo de uma coisa que se torna cotidiana, porém, é que essa coisa pode começar a se deteriorar sem que a gente perceba. É preciso prestar atenção aos cheiros do SCRUM pra ver se não há algo de podre no reino da Dinamarca, como diria Hamlet.
Quem usou pela primeira vez o termo Code Smells (o cheirinho do código) foi o Kent Beck, criador do Extreme Programming, enquanto ajudava o Martin Fowler em seu livro sobre Refactoring. Segundo Martin, "um método muito extenso é um bom exemplo - apenas de olhar para um código meu nariz começa a se contorcer se eu vejo mais do que uma dúzia de linhas em Java". Já o meu nariz fica incomodado ao ver que o código está escrito em Java, não que eu tenha algo contra essa linguagem de programação!
A analogia com o "cheiro" é bastante simples. Muitas vezes sabemos que há algo errado, algo está cheirando mal, mas nem sempre é fácil identificar a origem. Mike Cohn, que muitos já notaram ser uma das minhas fontes preferidas, propôs um catálogo de cheiros do SCRUM em 2003, buscando auxiliar na identificação de alguns problemas:
- Perda de ritmo: acontece quando os Sprints começam a ter duração variável. É muito importante para o sucesso do SCRUM que a equipe adquira a naturalidade em seu ritmo, concluindo cada Sprint com algum incremento ao projeto. Se, por qualquer razão, um Sprint tiver a duração de uma semana, outro de duas, mais outro de uma e assim por diante, será impossível que o ritmo adquira uma naturalidade. Eu vejo a tendência disso acontecer quando o time é formado por "porcos" que têm muitos outros compromissos. Porcos são aqueles que entram com o "toucinho" no projeto, os que devem estar verdadeiramente comprometidos. O ScrumMaster deve considerar a duração do Sprint algo sagrado e, se for o caso, conversar com o patrocinador do projeto exigindo a participação do devido porco ou até sugerindo a troca de porcos.
- Galinhas falantes: na reunião diária do projeto, apenas os porcos podem falar. As galinhas, que entram com os ovos, estão envolvidas, mas não comprometidas com o processo. O Mike é totalmente contra permitir que as galinhas se intrometam, mas concorda que elas podem assistir às reuniões. Eu concordo, mas também aceito que, na informalidade, uma galinha tente transmitir a um porco suas idéias, fora das reuniões. Em raros casos, e sempre entre o fim de um Sprint e o começo de outro, aceito a indicação de um porco para promover uma galinha a porco também.
- Porcos que faltam: cada vez mais desenvolvedores trabalham em horários flexíveis. Isto é um problema quando se quer estabelecer um ritmo e tem a ver com o primeiro dos problemas aqui colocados. As reuniões diárias devem ser rápidas, de quinze minutos, aproveitando ao máximo o tempo dos participantes. Os porcos escolhidos devem saber disso e estar de acordo logo no início do projeto. O porco que faltar estará sujeito às decisões dos demais, sem querer negociar posteriormente. Mas, e com equipes que trabalham remotamente? Aí eu sou mais flexível, mesmo reconhecendo que essa flexibilidade é, às vezes, contraproducente e que o ScrumMaster acaba tendo a sobrecarga de ficar dando puxões de orelha aqui e ali... Nesses casos, o que faço é ter vivo um documento compartilhado, onde as decisões têm seu horário de fechamento. Passado esse horário, quem não contribuiu sujeita-se às decisões dos demais.
Em meu próximo artigo, mais sobre o catálogo de cheiros do SCRUM e outras referências interessantes.
Artigo produzido para o Dicas-L
Ir para a Parte 2
