Desenvolvendo software como uma Rock Band

Há algum tempo atrás li esse post do Chapiewski sobre analogias usadas para o desenvolvimento de Software. Fiz um longo comentário lá sobre, mas, dado o tamanho que ficou, aqui teria sido o melhor lugar. Corrijo isso e aproveito para revisar a idéia original.

***

Acho que todos já ouviram falar na associação de Desenvolvimento de Software com construção de prédio (ou “construção civil”). Não gosto dela, mas ela se mostra mesmo muito atraente para muitas pessoas. É interessante por se aproximar de “negócios” e relacionar-se com uma construção coletiva. Mas além disso, ela atrai pela segurança de um modelo baseado em um “caso de sucesso”, ter relação com matemática (números…), sugerir a idéia de algo que possa ser controlado/planejado com precisão… Acontece que depois de estudar métodos agéis fica difícil ver as coisas assim. [Atualização: Além do post do Chapiewski sobre os problemas dessa analogia tem esse bem recente do Phillip Calçado]. Analogias alternativas como “Jardinagem”, “Criação de Receita” cobrem alguns aspectos defendidos pelos “agilistas”, mas não possuem a abrangência sedutora da primeira. Então, para uma analogia alternativa que seja mais adequada a minha ótica ágil e que cubra os cenários mais comuns na nossa área, penso que devemos ilustrar as seguintes dimensões:

  1. a natureza criativa e colaborativa do trabalho;
  2. o caráter iterativo/incremental da construção/descoberta das soluções;
  3. a temporalidade e a complexidade crescente dessas soluções;
  4. a necessidade de manter um negócio;

Vou tentar aqui uma analogia que me agrada mais, usando um pouco da inspiração do que já ouvi falarem na comunidade Ruby. Desenvolvimento de Software parece com composição de música. Mas se o software em questão for um sistema maior e de longa duração, algo que deve render lucro, pode ser que a melhor analogia seja com criar uma Banda de música! Sendo que criar é a parte “fácil”, difícil é gravar discos, fazer shows ao vivo, e, principalmente, manter uma carreira por um longo tempo. Tudo isso envolve arte, técnica e negócios. E, principalmente, envolve pessoas.

E falo da banda não apenas como “desenvolvedores”, mas também como parte daquilo que esta sendo “desenvolvido”. Isso se dá porque uma banda não vende apenas música, ela “vende” também a si mesma: expressões, atitude, visual, idéias, valores, etc. Gosto e acredito na idéia de que uma equipe de desenvolvimento de software tem que cuidar em se desenvolver também. Já que, em parte, colocamos a nós mesmos naquilo que fazemos…

Voltando ao que se desenvolve, neste contexto seria algo como um trabalho encomendado, onde essa “encomenda” lembra a forma como antigamente as óperas eram financiadas: Alguém com dinheiro suficiente querendo uma peça musical que atenda suas necessidades (Requiem? Lucro? Entretenimento baseado em alguma história ou tema proposto?). Os integrantes da banda então colaboram em composições e por precisarem atender a um “mecena/patrocinador” faz sentido exibirem as composições aos poucos (iterativamente) para ver se agrada/atende aos “requisitos” (muitas vezes nebulosos) e de uma forma simplificada, afinal não faz sentido orquestrar um rascunho!

[Atualização: Mesmo no caso de não haver esse “comprador” uma banda precisa de um público que a “compre”. Ela ainda precisa atender a certos requisitos nebulosos (identificação do público? divertir? voz própria?). Até conseguir ter fãs e se “achar”, ela erra bastante nos barzinhos da vida. Todo esse caminho (tocar em “espeluncas”, para amigos, gravar demos, abrir shows, etc) é bastante iterativo e incremental na sua formação. Quanto mais simples, leve e ágil (rock?) mais rapidamente pode-se aprender e ter resultados.]

Enfim, ainda não explorei todas as possibilidades dessa analogia, mas eis alguns pontos que me ocorrem e que vejo paralelos no “desenvolvimento ágil”:

  • Ter que atender a um Produtor/Patrocinador/Gravadora (Gerentes, Analistas de negócio) e ainda por cima ao público (Usuário final) para fazer sucesso não é tarefa fácil. Ou esse intermediário faz um papel muito bom como proxy do mercado ou é melhor se aproximar mais do público para saber o que realmente desejam, ou ainda, ser alguém parecido com o próprio público. O caso é: estar bem próximo das reais fontes de necessidades e/ou anseios para responder da melhor forma.
  • Durante os primeiros rascunhos executados nem todos os trechos/músicas precisam estar no mesmo grau de maturidade, se o escopo/tempo permitir as coisas podem mudar bastante até a gravação final. Mesmo depois, se considerarmos os shows ao vivo, há variações freqüentemente.
  • Dependendo da complexidade, uma “unidade musical” (tema, melodia, canção, etc) pode ter semelhanças com uma classe ou um pacote de classes. Parece uma classe quando pode ser usada várias vezes numa mesma música e até em outras de uma mesma obra (disco? ópera?). É bem verdade que uma música de sucesso pode ter variações em discos posteriores, como se fosse transformada numa fórmula ou “modelo” promissor…
  • Novas encomendas com “requisitos” semelhantes podem reutilizar partes das soluções anteriores (ou técnicas). Muitas vezes isso extrapola a própria banda. Talvez por isso vejamos tantas bandas e/ou músicas parecidas num determinado período de tempo.
  • Várias coisas podem ser “acopladas” ao trabalho musical, tais como: clipes, capas de cd, coreografias, livros, etc. Outras vezes são pensadas juntas desde o começo com outras artes, como ocorre às vezes em trilha de filmes, musicais ou óperas. Artistas/técnicos de outras áreas agregam valor tal qual designers a sistemas baseados na web. Daí a importância de saber trabalhar com pessoas de outras áreas.
  • Treino e disciplina são importantes para dominar ferramentas, compor melhor e executar melhor em conjunto e sem erros. Não adianta crescer sozinho ou só saber tocar bem solos, é uma banda!
  • O relacionamento da banda tem que ser cultivado e mantido sadio para a banda sobreviver e continuar criativa. A saída de alguém do grupo pode prejudicar a banda/equipe, e pode haver muito trabalho para manter o tempo de resposta de quem saiu. Além disso, é preciso tomar cuidado para não perder a identidade do grupo e seu trabalho.
  • O valor não está nos instrumentos, mas em quem os usa. De pouco serve a melhor guitarra do mundo na mão de alguém que não sabe usá-la em todo seu potencial. Ou, quão bom músico pode ser considerado quem só sabe usar aquelas “Pick ups de Dj” para mixar música dos outros (“apertador de parafusos de frameworks”)?
  • A banda vai fazendo seus “discos” e vai precisando se renovar, se não fizer muitos sucessos novos o número de músicas “legado” (antigos sucessos) vai aumentando e deixando os shows mais complexos e chatos para os mesmos. A idéia é não ser uma banda de um sucesso só ou presa a um passado que não consegue superar. Se a Banda não se preocupar em se atualizar e melhorar corre o risco de só tocar em “Bailes da Saudade”… Assim como código, ela não apodrece, fica obsoleta, embora mesmo antiga ainda possa manter seu valor para muita gente. De qualquer forma, vale a pena atentar-se para o momento quando as fórmulas de antigos sucessos devem dar lugar ao novo e experimentações.
  • Quanto mais os integrantes da Banda treinarem e comporem coisas fora de sua zona de conforto melhor músicos se tornarão. Além de facilitar uma atualização contante.

Enfim, como toda analogia, há falhas. Mas não precisa ser mesmo perfeita, basta ser suficiente para ajudar na comunicação de algumas idéias.

Anúncios
Desenvolvendo software como uma Rock Band

Um comentário sobre “Desenvolvendo software como uma Rock Band

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s