Praia de Iracema por "deltafrut's photostream"

Aconteceu no dia 13/11/10 o Maré de Agilidade em Fortaleza. A organização e o lugar foram ótimos, não ouvi reclamações sobre nada (nem wi-fi, coffee-break, etc), mais sobre isso ao final. Sobre as palestras ressalto que não quis fazer um resumo acurado, apenas ressaltar alguns pontos ou aquilo que achei interessante comentar sob meu ponto de vista. Nada comparado a estar presente.

TDD & Design

Começando com Paulo Silveira (Caelum). Incrível o equilíbrio em relevância técnica, diversão (Código! Ritmo!) e clareza de ideias. O Paulo soube passar suas mensagens (duas palestras), sem se/nos perder em detalhes desnecessários. Anotações feitas durante sua apresentação sobre Test-Driven Development:

• É melhor que objetos recebam suas dependências (IoC). Por isso é fácil singleton e métodos estáticos atrapalharem testes de unidade.
• Ele prefere injetar dependências via construtores. Se forem muitos parâmetros pode-se passar um “Builder”.
• Fazer testes antes ajuda a evitar código mais custoso para mudanças e que são trabalhosos de se testar (o que seria uma das causas para não o fazerem). Além de inibir também a prática de “chutar métodos”, ou seja, ficar imaginando métodos que podem nem ser utilizados no fim das contas.
• Para ele, Implementação, Design e Arquitetura possuem importâncias parecidas.
• Disse que enquanto a técnica de TDD pode ajudar a criar o design de classes, esta só irá ajudar a evoluir uma arquitetura, ou seja, ela ainda deve ser pensada a parte.

Bônus: No break deu uma dica que para equipes novas em testes de unidade ou TDD pode ser interessante começar a explicar a técnica sem o uso de frameworks (que viriam em um segundo momento).

Slides:

Não encontrado. Mas tem-se um gostinho na apresentação abaixo sobre Arquitetura e Design:
http://www.slideshare.net/caelumdev/arquitetura-designq-con2010paulosilveiracaelum

Kanban & Scrum

Rodrigo Yoshima (Aspercom) passou suas experiências e ideias sobre como Kanban pode auxiliar em situações onde só a cartilha de Scrum não basta. Ele não é tão equilibrado quanto Silveira, o que é um dos seus pontos fortes! =P

Chicken Run: Dreamworks Pictures, AARDMAN production.

Gostei bastante de sua comparação de Scrum a um programa de dieta. É fácil quebrar um regime e voltar a velhos hábitos devido ao seu impacto emocional. De forma semelhante, Scrum traz mudanças sérias em papéis, fluxo de processos, exigência de cadência, etc. Feito de forma muito brusca pode fazer as pessoas voltarem ao que estavam acostumadas rapidamente, ou ainda, prejudicar o status quo e ferir os egos das hierarquias, a ponto de ao se verem deixados do lado de fora da “caixa” (referência ao timebox/sprint) criarem uma “Revolta das Galinhas”.

Vemos assim que tanto a gerência média quanto o “chão de fábrica” podem sabotar Scrum (suspeito que qualquer coisa). Além disso, situações onde há muitas dependências externas ou entre times, e/ou demandas não controláveis (que quebram seguidamente o Sprint) desafiam a cartilha do Scrum.

Daí entra Kanban que visa auxiliar na:

• Visualização do fluxo de trabalho;
• Limitação de trabalho em progresso (WIP);
• Medição e gerenciamento do fluxo;

Isso ajuda, por exemplo, em dois pontos sensíveis:

• Quando o time vê sua eficiência e/ou resultados finais impactados por fatores externos a ele, isso abala seu comprometimento em relação ao projeto.
• Sem visibilidade do processo as únicas ferramentas da gerência média são o chicote e a “aporrinhação”.

Slides:

Não encontrado. Mas tem um resumo em vídeo dele falando apenas sobre Kanban aqui: http://vimeo.com/12967031

Bônus: http://kanbansket.ch/ (Ferramenta para criação de Kanban online usada por ele durante apresentação)

HTTP & Otimização

Maurício Linhares fez uma palestra sobre otimização de Front end inspirada pelo humor e gírias locais (falou muito dos “machos” daqui =P). Impossível cochilar durante sua palestra seja pelas boas dicas, humor ou volume de voz! =P Pena eu ter visto a palestra no evento online “Labsconf” na semana anterior, embora essa versão tenha sido mais completa. Anotações:

• Conheça bem as tecnologias que você usa. Se usamos a Web é bom conhecermos bem o protocolo HTTP. Grande parte das dicas deriva desse conhecimento.
• Recomenda bastante o Nginx como Proxy-server. Principalmente por facilidade de uso e desempenho.

Suas dicas estão bem documentadas na apresentação.

Slides:

http://www.slideshare.net/mauricio.linhares/seu-site-voando

Liderança servidora & Coaching Ágil

Alexandre Magno não pode ir e Fabiano Milani assumiu seu lugar com outra palestra. Pena que a apresentação já tinha sido feita em um outro evento em que fui (Agile tour) com menos de um mês de diferença. Então não houve novidade para mim. Acho que a pressa prejudicou um pouco seu desempenho dessa vez. Mesmo assim, ele sempre consegue passar muita energia, emoção e crença no que faz. Acho ótima sua ênfase nas pessoas, principalmente quando diz que para ser um bom líder é preciso gostar delas. Anotações:

• A administração no sentido clássico está morta. O comando e controle já era.
• Um líder procura conhecer liderados, descobrir seus objetivos, sonhos. Procura dar oportunidades de trabalharem naquilo que sentem prazer.
• O Scrum Master deveria ser um Líder servidor. Empenhado no crescimento das pessoas à sua volta, estimulando liderados a pensarem por si mesmos.
• Somos bons ouvintes? Quantas vezes formulamos respostas antes mesmo das pessoas terminarem de falar?
• Falou rapidamente de várias ferramentas de Coaching: Âncoras, Ganhos e perdas, SWOT, Roda comportamental, Modelo I.D.E.A.L., Valores, Crença limitante.
• “Nada é tão inútil quanto fazer com grande eficiência algo que não deveria ser feito em primeiro lugar.” (Peter Drucker)
• “Devemos permanecer unidos ou com certeza seremos enforcados separadamente.” (Benjamin Franklin)

Kanban & Visibilidade

Uma das apresentações mais esperadas por mim. Alisson Vale não decepcionou, usando a ferramenta Prezi e uma ênfase mais teórica (o que também curto) fez uma apresentação de alto nível, instigante e que passa um pouco aquela sensação de “wow” que atribuo por estar algo próximo do estado da arte do tema.

Ele mostrou a ideia do “Kanban Multiverse” de Karl Scotland que pode ser melhor investigada visitando os slides em flash encontrados em:

http://skillsmatter.com/podcast/agile-scrum/karl-scotland-on-a-kanban-multiverse

Sugeriu que Kanban tem maior potencial para criar significados compartilhados e com isso auxiliar na elaboração conjunta de solução de problemas, justificando isso pelas ideias apresentadas por Tom Wujec na seguinte palestra em vídeo (exibida durante apresentação, legendas pt-br):

http://www.ted.com/talks/…/tom_wujec_on_3_ways_the_brain_creates_meaning.html

Em resumo, pode-se auxiliar o cérebro a criar significados:

• Usando imagens para clarear ideias;
• Interagindo com imagens e com isso criando engajamento;
• Aumentando a memória com persistência e envolvimento visuais (cores, movimento, formas básicas, etc);

A visibilidade do Kanban ajuda todos a compartilharem um “modelo mental”, tirando de gavetas e cabeças o que se passa durante um processo de trabalho coletivo. Isso permite a um time ver como as coisas estão funcionando, auxiliando a colaboração, análise sistêmica e a contínua melhora do próprio processo.

Foi perguntado ao final sobre o Kanban eletrônico, ele disse que acaba-se perdendo algo com ele (por exemplo, engajamento). Se for o caso de usá-lo, deve-se procurar perder o mínimo possível e antes dele usar por um tempo a versão física do Kanban, de forma a facilitar a criação da cultura.

“Slides”:

http://prezi.com/ubums2ymmtyb/kanban-expandido-usando-visibilidade-para-transformar-processos/

Deploy Contínuo

A segunda palestra do Paulo Silveira (Caelum) mostrou como evoluir de um deploy demorado, adiado, manual e cheio de problemas até um que seja rápido, frequente e automatizado, nos fornecendo mais confiança e menos preocupações sobre mudanças indo para a produção.

Para conseguir essa situação confortável se faz necessário testes automatizados (de unidade, de integração, de aceite) e integração contínua. Tudo isso visando encontrar cedo problemas por meio de feedback rápido.

Dicas:

• Com o tempo e crescimento, testes de aceite podem apresentar alguns desafios de manutenção e demora. Sugere então que estes se atenham ao cerne do sistema.
• Recomenda criar uma forma simples para que qualquer um possa, com apenas um clique, ter versões entregues para homologação e deploy.
• Logo nos primeiros dias de um projeto construir automatização para o deploy de forma que esta solução evolua junto com o sistema.

Slides:

Não encontrado. Mas tem esse vídeo do seu irmão falando sobre o tema com praticamente os mesmos slides: http://vimeo.com/12976766

Agilidade & Empresa

Bruno Pedroso e Renato Willi (ambos SEA Tecnologia)  mostraram um relatório com resultados do contágio interno de princípios usados primeiramente em projetos (com métodos ágeis) para outras áreas/setores da empresa SEA. Os princípios são: Comunicação, Liberdade, Respeito, Confiança, Participação, Aperfeiçoamento contínuo, iniciativa, auto-organização, “Give give give” e Meritocracia.

Esses princípios foram então usados para repensar a forma de se trabalhar o RH (Relações humanas), em suas atividades de Seleção, Formação e Avaliações, assim como o Marketing e a Gestão. Simplificando enormemente, traduziram em ações esses princípios por meio de dinâmicas que envolvem a participação mais democrática das pessoas, buscando-se atingir consensos coletivos (Por exemplo, usando “World Café”). Além de incentivar elas a compartilharem e construírem conhecimentos em conjunto não só entre os membros da própria empresa, mas também com a comunidade a sua volta (Por exemplo, por meio de Dojos, Workshops, etc).

Em sua maioria os resultados apresentados quanto aos aspectos negativos apontaram para o aumento de custos, tempo e esforços, além de enfrentarem às vezes a falta de auto-motivação e iniciativa de membros. E quanto aos aspectos positivos apontam geralmente para maior aprendizado, melhor entrosamento de membros, melhoria em motivação e consciência de auto-responsabilidade.

Acho muito interessante e precioso o que estão fazendo, gostaria que alguém aplicasse métodos de pesquisa sobre o porquê das coisas ocorrerem como apresentado, criando hipóteses sobre como melhorá-las e experiências para validá-las… Um Drucker lá seria ótimo!

Slides:

http://www.slideshare.net/seatecnologia/agilidade-dos-projetos-empresa-uma-histria-de-intracontgio

Bônus: Durante a apresentação lembrei do conceito de Adhocracia, o oposto de burocracia (Google it).

Agile & Open Source

Relato da experiência da evolução do framework Demoiselle por Serge Rehem. Bacana ver os obstáculos e soluções encontradas na construção coletiva à distância. Só foi meio cansativo ver o que pareceu ser o histórico das retrospectivas em frente ao “burn down” de cada release do framework. Mas também, eu já estava meio cansado de só ver palestras…

Slides:

http://www.slideshare.net/serge_rehem/agile-open-source-a-experincia-do-framework-demoiselle

Sem mesa, mas redondo

Sorte que em seguida ocorreu o que para mim foi o ponto alto do evento. Ao invés da “Mesa redonda” programada, Bruno Pedroso (SEA) sugeriu um outro formato de conversa, o “Fishbowl Conversation”.

Basicamente as pessoas se organizam em um círculo grande e um menor dentro deste, onde uma pequena quantidade de pessoas possa manter uma conversa sem muita desorganização e os de fora possam acompanhá-la. Neste círculo menor há um lugar vazio que poderá ser ocupado por qualquer um do círculo maior que deseje participar da conversa, quando isso ocorre alguém do círculo menor deve sair de forma a sempre manter um lugar disponível.

Foi uma experiência excelente. Curioso que mais cedo cheguei a conversar com o Barroso (Por sinal, parabéns pela organização)  justamente sobre a possibilidade de usarem esse tipo de modelo mais participativo nos eventos. Não bastasse a atração do formato em si, o conteúdo do que foi conversado também foi bem bacana. Tanto que espero (sentado) fazer um post exclusivo sobre. Dentre os tópicos abordados ou questões despertadas em mim (versões minhas):

• Scrum: Influenciado pelo Lean?
• Scrum Alliance: Benéfica? Necessária? Inevitável?
• “Metodologia open source” vs. “Comitê da Verdade Certificada”
• Quem é o Inimigo? Comando e Controle! (by Alisson Vale)
• A paixão matou RUP?
• Mercado e Academia, Academia vs. Mercado.

Encerramento

Acho que pelo menos para mim posso fazer a seguinte retrospectiva.

O que foi bem:

• Palestrantes e temas
• Organização
• Dinâmica final
• Networking

O que poderia melhorar:

• Preço (Maré de Agilidade em frente ao mar, legal, mas…)
• Concorrência com feriadão
• Ineditismo de palestras (2 reprises pra mim!)
• Trilhas com diversidade de temas/níveis (Ou talvez uso de abordagens mais participativas)

Sobre esses últimos itens acredito ser importante uma análise de retrospecto do que já se falou em eventos locais e uma pesquisa com questionários prévios visando criar uma boa programação. Por sinal, seria bacana uma pesquisa de feedback/retrospectiva sobre o evento, não? Porque não aplicar Scrum/Lean na própria organização dos eventos? Por falar nisso, pelo menos pra mim, o formato de apenas palestras grandes está meio desgastado, felizmente tivemos uma inesperada e boa surpresa ao final. Acho que vale a pena experimentar mesclar o modelo baseado em palestras grandes com o mais participativo (Lightning Talks, Sessões de World Café, Coding Dojos, Design Dojo, etc), permitindo uma espécie de auto-organização do evento, quem sabe facilitando atender tantos gostos e níveis diferentes (Além de incentivar a superação de barreiras como a timidez do público da área). Co-criação pessoal! É isso, obrigado a todos que participaram e tornaram o evento possível.

Fotos

http://picasaweb.google.com/cmilfont/Maredeagilidade2010fortalsabado#

http://picasaweb.google.com/handersonbf/MareDeAgilidade2010SabadoFortaleza#

http://www.facebook.com/album.php?aid=13278&id=100001667503379

Fiz um resumo informal do que dizem em um mapa mental: Ingredientes para Motivação no Trabalho (se preferir ver como imagem clique aqui). Durante a elaboração do resumo tentei identificar os “ingredientes” chaves envolvidos em suas opiniões e relatos na forma como trabalham. Depois fiquei refletindo sobre tais “ingredientes” numa equipe de desenvolvimento. Creio que muitas equipes ágeis falham ou desandam por não se preocupar o suficiente com tais itens, muitas vezes subestimados e visto como óbvios, talvez por serem banalizados por todo um mercado de consultoria. Contudo, são bastante difíceis de se praticar e se manter na maioria dos ambientes de trabalho. Seria possível escrever livros sobre cada um (e de fato existem), mas vou tentar ser breve e menos óbvio.

Conexão/Prazer: Sentir prazer por uma atividade deve ser a forma mais proveitosa de se conectar a mesma. Imagine a enorme paciência e persistência dedicados a um jogo de videogame para uma idéia do que falo. Conseguir sentir prazer em fazer algo para alguém pode ser ainda mais poderoso. Seria como sentir-se conectado aos outros por meio de um trabalho ao qual está conectado. Mais que prazer, é a oportunidade de dar significado e propósito ao que se faz. Parece ser comum encontrar pessoas que dizem não gostarem do que fazem, mas ao meu ver muitas estão apenas indiferentes devido a problemas de percepção e contato. Por exemplo, imaginemos o caso de um desenvolvedor que pouco se esforça no que diz respeito a usabilidade recebendo visitas de usuários finais reclamando de dores em articulações devido a necessidade de usar muitas vezes o mouse em tarefas repetitivas que poderiam ser melhor feitas usando o teclado. Nesse momento, ele pode perceber que o que faz impacta no bem-estar dessas pessoas ao influenciar suas saúde e eficiência. Os resultados do empenho do desenvolvedor agora possuem destino, rostos e sentimentos reais. Se o desenvolvedor se importa com os usuários/clientes, acabará valorizando comunicação e feedback. É mais uma razão para a aproximação entre clientes e desenvolvedores. Infelizmente, me parece que para a maioria de nós é mais fácil entender razões que emoções. Pode parecer bobagem, mas mesmo nas tarefas mais técnicas o envolvimento emocional pode fazer diferença, por exemplo, agindo de forma apaixonada em relação ao código. E se algo no trabalho lhe frustra ou chateia, é preciso lidar com tais fontes de “desprazer” como alvos a serem resolvidos também, resolvê-los de forma criativa, como por exemplo, automatizando tarefas repetitivas (vide testes automáticos). É outra forma de entender a frase, “trabalhar para viver”.

Criação/Expressão: Espaço para criatividade e expressão pessoal. Algo de arte e liberdade. Não consigo imaginar alguém motivado em um trabalho onde só faz o que mandam e/ou repete os mesmos procedimentos eternamente. Processos burocráticos que oneram e tentam prevenir qualquer mudança também não ajudam. Fora que não dá para ser plenamente criativo em um ambiente que tenta forçar você a ser igual a todos, que não respeita sua personalidade e talento. Além disso, há outro tipo de espaço necessário para a inovação: Espaço de tempo. As pessoas precisam de tempo para refletirem sobre como estão fazendo as coisas, ao invés de simplesmente fazerem. Precisam de tempo livre para explorações de novidades e realizações de experiências que podem beneficiar enormemente o trabalho. Tempo para manterem-se conectadas ao que ocorre no mundo, mais que motivador, isso é essencial para a área de tecnologia.

Colaboração/Confiança: Em um verdadeiro trabalho em equipe teremos “co-criação”. É difícil ficar motivado quando um pequeno grupo isolado (às vezes de uma só pessoa) define e modela soluções/regras sem sequer ouvir sua opinião. Como pode haver comprometimento sem envolvimento? Principalmente numa área que envolve conhecimento é muito importante incentivar o livre pensar, a delegação de tarefas, enfim, permitir que as pessoas tomem decisões e aprendam com seus erros e acertos. Claro que para isso será necessário confiar nelas. Os reais benefícios de um trabalho em equipe só surgem quando há confiança entre seus membros, de outro modo pode-se ter muita gordura (“burrocracia”) e conflitos desnecessários. Além do mais, essa confiança mútua pode ter reflexos internos ao estimular a auto-confiança dos indivíduos. Quando as pessoas confiam em si e nos outros há mais troca de experiências e surge uma sinergia na equipe, tornando a mesma maior que a simples soma de esforços separados. Um dos desafios é saber lidar com pessoas que não sabem trabalhar em equipe e/ou não confiam em outras pessoas. Pois precisa-se de humildade, paciência e confiança para ouvir e permitir contribuições naquilo que fazemos. Muitas pessoas adoram quando superiores/donos exercitam essas qualidades com elas, mas muitas dessas mesmas já não suportam fazer programação em par, por exemplo.

Energia/Foco: Se pedem algo que pode ser feito em 2 horas, mas só vão precisar mesmo daqui dois meses, adivinha quando começará a ser feito? Sim, condições favoráveis para a síndrome do estudante. Muitas vezes é melhor estar no “acontecendo” dos eventos para aproveitar a energia do momento, onde os esforços podem ser concentrados. Para tanto, desejo e vontade precisam ser projetados em objetivos comuns, considerando tanto aquilo que cada um quer quanto aquilo que o grupo precisa, conciliando partes e todo. A idéia de fazer o cliente explicar suas necessidades e tê-lo re-priorizando a cada iteração deixa claro ao desenvolvedor o que precisa ser feito no curto tempo da iteração, que muitas vezes termina com uma entrega parcial. O comprometimento com o cliente para aquela entrega parcial ajuda naquilo que chamam na entrevista de “senso de urgência”. Vejamos “urgência” aqui mais como diz sua raiz, “urgir”, que no Houaiss também quer dizer: “ser necessário, realizar-se ou resolver-se sem demora“, o que me lembra o conceito de “agilidade”. Esse estado de foco e concentração se faz importante principalmente em grupos, ainda mais para aqueles onde é mais fácil enxergar diversão em grupo que trabalho em grupo. De qualquer forma, a motivação aqui vem de ver as coisas progredindo, de fazer aquilo que realmente importa e faz diferença, no agora.

Evolução/Qualidade: Quem se importa com o que faz, faz com esmero. Trata-se de não apenas fazer, mas estar atento a como melhorar o que se faz. Concordo com o que foi dito aqui, qualidade tem a ver com respeito para com quem irá usar seus serviços/produtos e respeito para consigo mesmo. Não a vejo em prática enquanto vista mais como obrigação do que como elemento motivador, ou seja, ela deve ser alvo principalmente de quem bota a mão na massa. Assim, há uma urgência por qualidade, ela não fica eternamente para “depois”. E quanto mais cedo visada, mais saudável e duradoura será a evolução daquilo que se faz. Para mim, não tem nada a ver com controle (“de qualidade”) e sim com consciência e aprendizagem. Pessoas conscientes sabem que são passíveis de falhas, sabem que sempre podem melhorar, sabem ouvir. Daí ser importante identificar erros e oportunidades de melhoria (consciência), e aprender com estes (aprender = compreender + adaptar). Isso que nos faz relevantes, distintos da concorrência e nos torna continuamente mais adequado aos clientes. É motivante saber que faço algo, ou estou em um lugar, que me permita/estimule crescer continuamente como pessoa e profissional.

Exemplos/Liderança: Líder aqui não é necessariamente um gerente moderno e carismático. No contexto a que me refiro, cada um pode eleger seus líderes. São ídolos ou referências que servem de exemplo, de inspiração para aquilo que queremos ser. Podem ser personagens históricos cujas biografias são admiráveis e, em alguns casos, não precisam sequer ser pessoas, podem ser histórias, mitos, livros, filmes, personagens fictícios, enfim, o papel e influência acabam sendo bem parecidos. Ambos os tipos inspiram posturas, atitudes, valores. Mas para algumas pessoas, tais referência são míticas e distantes demais, que por assim serem podem ter “qualidades superiores”. Daí a importância também de referências próximas e palpáveis: Exemplos. Nesse ponto muitos pensam no papel do Líder. Mas líder pode ser raro de se achar, já exemplo qualquer um pode ser. Na verdade, cada um de nós é um exemplo em potencial (para o bem ou para o mal), basta ter uma atitude que em algum momento em uma certa atividade seja reconhecida, daí ser importante estar sempre ciente desse potencial e responsabilidade. Esse reconhecimento e consciência de influência, por menor que seja, pode ser motivador. Assim, independente de estar ou não em um cargo superior, constantes atitudes exemplares até podem tornar alguém um líder aos olhos dos outros. Esses líderes naturais podem servir de catalizadores de grandes mudanças pessoais e culturais a sua volta, pois passam uma mensagem de transformação (ensinam) da melhor forma possível. Em um mundo melhor, seria ótimo ter chefes (ou mesmo colegas) que antes de tentarem terem “cargo de líder”, tentassem antes serem exemplos e líderes naturais. Mas é mais fácil tentar mudar os outros que a si mesmo, não?

Percebam que esses “ingredientes” não são isolados uns dos outros, como em um bom prato, eles funcionam misturados e podem ser dosados de diferentes formas, desde que se atente a importância de saber equilibrá-los. Quando se fala em foco, não se pode perder de vista o todo, o ambiente, nem muito menos deixar que as urgências tomem todo seu tempo, a idéia é dar mais urgência ao que é importante e menos importância ao que é urgente. Agilidade de entregas não deve comprometer a qualidade do código, ou a necessidade de criação individual não deve eclipsar a necessidade de padronização do código coletivo. Além disso, pessoas diferentes possuem gostos diferentes, alguns ingredientes motivarão mais que outros dependendo de seus desejos e talentos. É uma arte saber aproveitar e desenvolver o potencial alheio e/ou o próprio. E ressalto o “próprio”, pois é importante notar que não basta uma empresa dar estímulo e condições para esses itens se o indivíduo não perceber sua parcela de responsabilidade por sua própria motivação. A verdade é que não se trata apenas de trabalho, se não formos capazes de trazer algo disso tudo para nossa própria vida no dia-a-dia fica difícil ser realmente motivado. Assim, a vida pode ser bem mais saborosa, seja onde for.

***

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.

• Inteligência, bom senso, esperteza, sutileza, talento, habilidade, sagacidade. saber (uso arcaico).
• Web Interactive Talk (internet)
• Wit Stwosz: Escultor polonês

• West Indian, West Indies. (English)
• Wavelet Image. (Computer)
• kana japonês que representa um tipo de som (Wikipédia).

• Tubérculo comestível das ilhas de Samoa (priberam)
• Primeiro pessoa do Singular de “Tarar” (Houaiss):

pesar (algo) para abater a tara;

ficar louco;

gostar muito; adorar;

Lembra: Tarô…

Destruere, ?.