Fred Brooks sobre colaboração

October 22nd, 2009 § 2 comments

Ontem, cortesia da Caelum, tive oportunidade de ver Fred Brooks falar sobre desenvolvimento, arquitetura de sistemas e colaboração entre times.

O evento, lançamento da tradução brasileira de seu trabalho mais famoso–O Mítico Homem-Mês–contou com várias outras palestras e uma sessão de Q&A com Brooks mas, infelizmente, só pude participar dos quarenta ou cinqüenta minutos que ele passou discorrendo sobre o assunto. Mesmo assim, foi muito bom ver o velho professor–ele está com quase 80 anos atualmente–falando sobre assuntos que eram relevantes em 1975, quando o livro foi impresso pela primeira vez, e que ainda são relevantes hoje, quase 40 anos depois.

O Mítico Homem-Mês é um livro que qualquer pessoa que desenvolve ou gerencia algum processo de desenvolvimento de software deveria ler. Apesar da ironia do próprio Brooks ao dizer que seu livro é como uma Bíblia de Engenharia de Software, porque “todo mundo lê mas ninguém faz nada sobre o assunto”, o livro permanece uma influência seminal entre todos os trabalhos que foram feitos no campo nos últimos 30 anos, especialmente entre os responsáveis por grande parte das metodologias de desenvolvimento que são usadas atualmente.

Um dos pontos interessantes da palestra–e algo que que só tem um conhecimento superficial do livro não notaria–é que Brooks possui uma visão particular de desenvolvimento que vai muito contra o que se fala hoje em termos de desenvolvimento “ágil”. Um dos exemplos engraçados disso foi quando um dos participantes, ao final da palestra, perguntou o que ele pensava sobre o papel da arquitetura e design colaborativos dentro de um time ágil–um time de Scrum, digamos. Brooks declarou enfaticamente, em resposta à insistência do participante, que, sem um arquiteto-chefe, nada que fosse feito teria a consistência–a integridade conceitual, por assim dizer–necessária para o bom desenvolvimento do software.

Falando sobre colaboração, Brooks apontou o papel do trabalho solo de grandes artistas e realizadores como essencial para a criação de obras duradouras. Mesmo no contexto de colaboração, ele diz, as maiores equipes raramente passam de uma colaboração complementar entre duas pessoas. Mais do que isso resulta em difusão da integridade conceitual da obra em face a desafios maiores.

Inclusive, comparando com o modelo de colaboração de projetos de código livre ou aberto, Brooks aponta o fato de que, nesses projetos, os construtores e clientes geralmente são os mesmos e isso torna o desenvolvimento algo completamente diferente. Há integridade conceitual, sim, não do sistema como um todo mas de suas partes. Isso pode realmente ser comprovado de maneira fácil do desenvolvimento dos grandes projetos como o Linux onde uma pessoa retém a visão intelectual mais profunda do desenvolvimento e onde as partes são íntegras entre si por via de convenções–style sheets de desenvolvimento, como Brooks denomina o processo.

Em suma, a visão de Brooks é refrescante em tempos em que metodologias ágeis estão em voga em uma compreensão real do que elas representam. É bom ver alguém que pensou exaustivamente sobre o assunto–e que está pronto para lançar mais um livro sobre suas reflexões ao longo dos anos–mostrar o que realmente importa no desenvolvimento. Raros são os times e empresas que possuem maturidade para ver as coisas dessa forma.

Minha única tristeza na participação do evento foi não ter podido pedir a Brooks para autografar meu exemplar–que repousa em Belo Horizonte à espera de uma mudança futura para São Paulo.

Tagged

§ 2 Responses to Fred Brooks sobre colaboração"

  • Sabe Ronaldo, estava pensando muito sobre esse tema ultimamente. Eu coordeno um time de desenvolvimento, e estamos pensando em adotar algumas práticas do Scrum e estávamos discutindo justamente a dificuldade de adaptar o que o Scrum prega em alguns aspectos do desenvolvimento de software.
    Excelente post.

  • Ronaldo says:

    Ricardo, obrigado!

    A sua percepção é bem válida. Acho que uma das coisas que a comunidade ainda não percebeu–principalmente aqui no Brasil onde métodos ágeis tem sido uma febre nos últimos meses–é que o Scrum é um framework gerencial e não de desenvolvimento.

    É preciso combinar o Scrum com algum tipo de prática de desenvolvimento e engenharia de software que faça sentido para a empresa e times. XP é um bom exemplo mas existem vários outros também.

    Enfim, bastante coisa para aprendermos ainda.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Fred Brooks sobre colaboração at Superfície Reflexiva.

meta