Ah, o cheirinho de SCRUM pela manhã! - parte 1

Data de Publicação: 19 de Junho de 2008

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.

Versão para impressão

Currently 3.09/5
1
2
3
4
5

Avaliação: 3.1 /5 (182 votos)

Opinião dos Leitores

Sobre o autor

O consultor de tecnologia Cesar Brod publica em seu "Diário de Bordo" do portal www.brod.com.br uma série de artigos que, como ele diz são "registros de participações em eventos, textos, coisas sérias e não tão sérias". Os artigos expressam especialmente sua visão bastante atual do mercado de informática, o papel do software livre e seu modelo de negócio e mesmo o posicionamento recente de grandes empresas como a Microsoft.

Para se manter atualizado sobre as novidades desta coluna, consulte sempre o newsfeed RSS

Para saber mais sobre RSS, leia o artigo O Padrão RSS - A luz no fim do túnel. Recomende este site
Recomendar este artigo

*Nome:
Email:
	Me notifique sobre novos comentários nessa pagina Oculte meu email
*Texto:

	Para publicar seu comentário, digite o código contido na imagem acima