Fragmental

Semana passada o Richard Durnall me chamou para assistir a uma aula que ele deu na University of Melbourne. O Rich é o guru local de Lean e é uma figura.

A aula foi interessante. O curso é o mestrado em alguma das 343.435 ramificações de Tecnologia da Informação, basicamente uma escolinha para CIO-wannabe. Para se ter uma idéia todas as perguntas da sessão foram sobre implantação de ERPs, você via claramente que nenhum dos estudantes tinha a mínima vivencia na indústria e acreditavam piamente nas suas Info Corporate da vida.

A matéria era sobre comparação de metodologias e o Rich não foi o único. Antes dele apresentou um senhor, que é professor da instituição e arquiteto do maior banco da Austrália, onde inclusive tenho conta (brr…). A palestra do senhor arquiteto foi sobre como ele participou da salvação de um projeto de data mining usando o bom e velho waterfall. O único ponto diferente de uma lição clássica sobre como não fazer software foi sobre o uso de técnicas de Six Sigma para avaliação e priorização dos requisitos.

Quando chegou a vez do Rich apresentar Agile/Lean foi um contraste enorme. Na sessão de perguntas:

- Você falou sobre estes métodos ágeis e sobre como eles…er.. não ligam para requisitos. O [cara defendendo waterfall] apresentou um caso real de um grande banco. Você realmente acha que as técnicas de algo como agile podem competir com Six Sigma? [nota: uh?]
- Então, na minha apresentação eu fui bem ralo e essa é uma palestra introdutória, então foi bom você perguntar isso. Eu trabalhei na [top 5 montadora de automóveis], na [maior empresa aérea do mundo] e em alguns bancos. Nas duas primeiras empresas eu fiz parte da implantação de Six Sigma, inclusive eu sou Black Belt. O que eu vi deste processo foi […] e por isso que agile/lean é uma boa escolha.

Agora pense que em vez de “Six Sigma Black Belt” ele tivesse dito algo como “inclusive eu sou Agile Software Specialist e os problemas de Six Sigma são […]”. Teria o mesmo efeito?

Outro caso recente e interessante foi no Australian Architecture Fórum em Sydney. O Halvard estava apresentando uma palestra extremamente interessante sobre governança de projetos SOA onde a única ferramenta é um wiki. Em algum momento alguém levanta:

- Ok, ok, isso aí é muito Web 2.0, muito legal mas não é aplicável no meu cenário.
- E qual seu cenário?
- Eu trabalho em um banco, faço parte do grupo de controle de serviços de segurança. Isso de REST, wiki é muito legal mas vocês não entrariam num banco de modo algum!
- Uhm.. interessante você falar disso porque segurança em serviços é uma das minhas áreas de estudo… eu concluí meu Ph. D. em SOA na Universidade de Sydney e meu foco é exatamente segurança. Na verdade, na ThoughtWorks a maioria dos clientes são bancos e, inclusive, tivemos hoje de manhã o arquiteto principal do banco [top 5 banco australiano] falando exatamente sobre como usaram este tipo de técnica para governança num projeto que participei.

Imagine que ele tivesse falado “Eu sou um Wiki Certified Contributor e um RESTafarian Official Gold Partner”. Teria o mesmo efeito?

Por que das historinhas? Para argumentar numa discussão que eu tive com o grande Juan Bernabó sobre a total e completa ausência d sentido em algo como Certified Scrum Master. O Juan argumentou que certificações são valorizadas -e requeridas- pelas empresas. Meus pontos são:

• Eu não conheço nenhuma pessoa que acredite que um curso de dois dias, sem sequer uma avaliação final –pagou, passou na pratica- deva ser valorizada. Se nós sabemos que a certificação não tem valor por que a venderíamos de outra forma? Agile não é sobre trazer valor e melhorar praticas?
• O mercado também quer porque quer e acha que precisa de cronogramas detalhados, requisitos esmiuçados e projetos que terminam em uma grande fase de testes. Nós sabemos que isso não traz valor não fazemos apologia a este tipo de coisa, por que com certificação seria diferente? Por que ao invés de combater a ineficiência e a busca por respostas fáceis nós criamos e glorificamos nossos próprios selos?
• Uma certificação emitida por si mesmo não vale nada. A menos que alguém já acredite que Scrum traz algum valor essa certificação é como acreditar que o Inri Cristo é Jesus porque ele afirma o ser.

Em resumo, eu acho o curso que é dado com o CSM ótimo. Ele abre mentes e é uma fantástica introdução. E só. O certificado emitido por este curso não tem qualquer valor real e propagandear o contrario, ajudando empresas a continuar glorificando certificações sem sentido, vai contra a primeira linha do Manifesto Ágil:

We are uncovering better ways of developing
software by doing it and helping others do it.

O debate completo está aqui.

Com mais calma agora, volto a falar do evento. O fórum foi patrocinado pela IASA, que possui um capítulo bem forte em Melbourne. A idéia é prover mais mesas redondas do que apresentações, minha palestra foi uma das três únicas que não seguiam este formato.

Eu cheguei atrasado e fui direto para uma mesa redonda sobre REST x SOAP. O apresentador/moderador era claramente tendencioso a favorecer REST e, apesar de adorar essa arquitetura, eu acho que isso foi uma falha grave. A parte boa foi que diversas pessoas tentaram defender SOAP usando argumentos bem interessantes. Nenhum deles me convenceu inteiramente mas me fizeram pensar sobre alguns cenários onde usar REST seria reinventar SOAP, ainda que mais coeso.

Minha apresentação foi bem interessante, eu não sei estimar tempo de palestras em inglês ainda e acabei usando apenas 30 minutos dos 50 esperados. Isso acabou sendo bom porque houveram muitas perguntas, especialmente sobre os widgets em JavaScript. No final da apresentação eu tive uma conversa muito interessante com uma pessoa que foi arquiteto de um dos principais canais de TV australianos e é impressionante como os cenários e problemas são os mesmos.

Durante o resto do dia eu fiquei no stand da ThoughtWorks conversando com as pessoas. Foi bem interessante ver o que os arquitetos presentes pensam da ThoughtWorks e fazer contatos profissionais, tanto para possíveis futuros colegas quanto para futuras oportunidades de projetos.

Uma coisa engraçada em eventos ora do Brasil é que apesar de nos consideramos os seres mais sociais do universo conhecido nossos ventos são sobre grupinhos. As pessoas não interagem com desconhecido. Nos eventos aqui e em outros países, no entanto, é tudo sobre networking. Chega a ser meio constrangedor você está saindo do banheiro e alguém fala um “Oi, eu sou X, quem é você?”.

Segunda-feira eu embarco para Sydney para mais um dia de evento. Isto é algo também interessante, como o evento é durante a semana e Melbourne e Sydney são cidades distantes o mesmo evento ocorre nos dois lugares.

Estes últimos dias (meses?) foram bem corridos e eu fico feliz de pelo menos esta tarefa se concluir.

A apresentaçao em Melbourne acabou de terminar. Foi bem interessante e o evento em si está sendo uma experiência diferente. É algo mais como mesas redondas do que apresentações, mais sobre isso depois.

| View | Upload your own

Aproveitando, agradecendo novemente ao Antônio Carlos pela liberação dos nomes e marcas, a apresentação ia ficar bem sem graça sem os screenshots :)

Falando em coisas agitadas, fui convidado para palestrar no Australian Architecture Forum 2008. O título é “Lightweight SOA Through Web Widgets” e falar de SOA com REST num evento onde vai estar presente o impagável Jim Webber é algo bem diferente.

Como meu Google Analytics diz que ese blog é acessado por pessoas aqui na Austrália fica o convite.

A quantidade de dados disponível na Internet é algo interessante e quando temos a ferramenta certa algumas realidades são tão claras que chegam a ser constrangedoras. Para mim a rede social mais relevante hoje é o Linkedin. Apesar de haverem centenas de desesperados para arrumar um emprego e ganhar recomendações sem merecer é m sistema bem feitinho e de uma empresa que parece ter o pé no chão: nada de criar o novo Facebook, foco foco foco!

Bem, dia desses eu vi que eles lançaram páginas das empresas. Além de uma interação redondinha com a BusinessWeek o perfil da empresa possui diversos dados extraídos dos perfis dos seus funcionários e, como a experiência de trabalhar com alto volume de dados e acessos me mostrou, isso não é nada fácil.

Mas aí vem a parte engraçada. Pegue a página de uma empresa de três letrinhas qualquer. Veja o box “Related Companies” e perceba a quantidade de empresas de três letrinhas dos dois lados (antes de entrar na empresa, depois de sair). Agora clique em uma empresa de três letrinhas da lista. Tente achar uma delas que não tenha uma empresa de três letrinhas como “after”.

É óbvio que isso não é nenhum dado científico mas mostra a realidade que quem trabalha nessas empresas vive -falo isso de conhecimento próprio. A coisa mais comum para o desenvolvedor de sistemas no Brasil é viver entre consultorias, você fica um pouco em uma, recebe uma proposta melhor, vai para outra, tira um certificado, volta pra anterior, quer ganhar mais, muda de novo. Sair deste ciclo não é fácil, exige sorte e/ou muita vontade. Não é fácil arrumar um bom lugar para se trabalhar e ainda ganhar a mesma coisa, mas existe. Na verdade eu percebo que tirando poucas exceções a maioria das pessoas com nível técnico bom que eu conheço ou não estão mais neste ciclo ou estão saindo dele.

Existe uma onda de pessoas que estão indo trabalhar com produtos, fazer consultoria por conta própria ou abrir sua própria startup. Isso é ótimo, quebra o paradigma infeliz de que para um técnico ter uma carreira de sucesso e;e deve sair da área.

Aqui em Melbourne -e imagino que na Australia toda- existe um saudável mercado de pequenas consultorias. São empresas pequenas, de umas dez pessoas, que conseguem competir nesse mercado tão cheio de absurdos. Infelizmente no Brasil isso é meio impossível -e dá para entender o Viícius-, as consultorias ganham contratos na base do… bom, vocês são brasileiros e sabem do que eu estou falando. Aqui existem as grandes também, Melbourne é um centro mundial, mas ainda que as pequenas estejam longe das contas megalomaníacas elas conseguem se virar com empresas que precisam de resultado de verdade, e não apenas encher uma sala de gente que finge que desenvolve.

Afinal, quantas permutações você consegue fazer com três letrinhas?

Recentemente terminei meu primeiro projeto na ThoughtWorks. Como de normal com projetos ágeis esse terminou no prazo e com clientes satisfeitos já prontos para a segunda fase, mas teve algo especial. Foi meu primeiro projeto agile white-label.

A ThoughtWorks é uma empresa especializada em boas práticas de gestão de projetos, análise de negócios e desenvolvimento de software. Não é uma empresa especializada em XP ou Scrum ou Crystal ou que quer que seja.

Com tantos especialistas no escritório não é difícil imaginar que se pega o que melhor funciona em uma metodologia e em outra para formar uma metodologia única, adaptada àquela empresa. Como evangeliza Jacobson, o importante não é o processo em si e sim as praticas.

Nossas praticas neste projeto variaram entre XP e Scrum e as desenvolvidas internamente na ThoughtWorks e que não são tão conhecidas ou por um acaso nunca foram publicadas.

Eu notei algumas coisas boas e ruins no processo. Como estou acostumado a seguir um conjunto específico de metodologias foi muito bom não estar preso à uma prática. No Scrum, por exemplo, se você não segue uma pratica pode complicar outras, elas são habilidosamente encadeadas. Como nós criamos o nosso encadeamento não havia tanto problema em mudar as regras no meio do jogo quando víamos que algo não ia dar certo, mas ao mesmo tempo a falta de uma “arquitetura de processo”, uma linha-guia que dita a estratégia, foi sentida.

Outra coisa importante é que eu não tentaria algo parecido com pessoas inexperientes Existe uma tendência nas adoções de agilidade à largar uma ou outra pratica que parecem menos interessantes ou mais trabalhosas. Eu sou completamente a favor de se personalizar a metodologia com o tempo mas sou completamente contra fazer isso durante a adoção inicial –a menos que seja uma ferramenta didática e a prática seja introduzida no decorrer do período. Adaptação de metodologia deve ser fruto de feedback, não se deve retirar algo do processo antes mesmo de tentar para ver as conseqüências. É claro que existem exceções mas as pessoas que criaram e mantêm as metodologias ágeis tiveram um motivo para colocar aquela pratica ali, se você não vê valor nela existe uma grande chance de não entender ara que ela existe. Tudo bem remover a pratica após entender, só não retire do processo algo que você não conhece e pode ser o coração da coisa toda.

Da mesma maneira, customização demais matou o RUP. O RUP é genérico demais e ao mesmo tempo que é tudo não é nada. Eu já trabalhei em mais de uma dezena de projetos que se diziam RUP e a única coisa que eles compartilhavam era uma burocracia infernal.

Seja qual for sua escolha, Srum, XP, Crystal ou White-Label, o que importa para mim são os valores. As praticas são apenas maneiras de se atingir os valores e apesar delas diferirem entre processos ágeis todos eles tem como objetivo –ou deveriam ter- chegar até os valores expressos aqui.

Há uns 4 ou 5 anos eu faço parte do RioJUG (mesmo na Austrália ainda faço parte do grupo) e nos últimos anos viajei e conheci JUG e outros grupos de usuários no país todo.

Acho que existem três grandes padrões para grupos brasileiros. O primeiro é do estilo do RioJUG: uma apresentação à cada X dias com uma palestra. Pouca participação do público, pouco networking. No Rio ainda é mais complicado porque as reuniões vão até tarde e as pessoas mal tem tempo para o lanche no final.

Outro padrões é o de Dojo. Pessoas se reúnem e resolvem um problema com código, aprendendo sobre ferramentas e plataformas no caminho. Muito networking, muita participação mas geralmente o conteúdo só se espalha até todos terem um razoável conhecimento sobre ele,não existe a figura de uma pessoa que apresenta algo muito novo ou experimental. Além disso no Brasil temos poucos notebooks nas mãos das pessoas -apenas gerentes líderes e etc.- o que elitiza os frequentadores.

Outro tipo é quando as pessoa apenas se reúnem para conversar. A comunidade de Software Livre é especialista nisso e geralmente a conversa começa ou termina no bar.

Todos são legais. A comunidade Java brasileira cresceu muito basicamente com este tipo de divulgação. Mas eu, sinceramente, enchi o saco.

Hoje estou no escritório da ThoughtWorks em Melbourne, onde estou baseado. Temos aqui o encontro do grupo de usuários de Ruby de Melbourne, que é hospedado aqui no escritório (também teremos aqui o BarCamp Melbourne em Fevereiro). Este grupo tem uma estrutura de reunião bem interessante.

Começa com a eventual apresentação pelo coordenador, bem rápida. Depois, durante vinte minutos, pessoas conversam sobre coisas interessantes que viram, comentários rápidos e indicações de onde achar mais informação. Depois uma apresentação sobre um tema de meia hora. Um intervalo com pizza e refrigerante (oferecidos pela anfitriã) e nos trinta minutos restantes temos lightining talks, palestras muito rápidas -cinco à dez minutos- sobre coisas aleatórias no mundo Ruby/Rails. No fim vai todo mundo para o pub, como bons australianos. Como em Melbourne anoitece às 21h nessa época do ano a noite ainda nem começou.

A palestra principal foi sobre TreeTop mas falamos sobre Faker, benchmarks de servidores web, ImageMagik, a LnuxConf Melbourne que está rolando esses dias e dezenas de outras coisas. Não haviam espectadores, todos eram participantes.

Fazia muito tempo que não tinha uma noite nerd tão agradável.

Ruby 11:41 PM:
hello, happy new year

Phillip Calcado “Shoes” 11:41 PM:
hello, happy new year u2

Ruby 11:42 PM:
Thank you. Are you busy now?

Phillip Calcado “Shoes” 11:42 PM:
not really

Ruby 11:42 PM:
ok. That’s good.

Ruby 11:42 PM:
So, Can i talk about shoes with you?

Phillip Calcado “Shoes” 11:43 PM:
actually i don’t think so. i have no relation to the shoes industry, that’s just a nickname

Ruby 11:43 PM:
ok. haha. Sorry. i misunderstanding.

Phillip Calcado “Shoes” 11:43 PM:
:) np

Ruby 11:44 PM:
But why you use “shoes” as your nickname?

Phillip Calcado “Shoes” 11:44 PM:
i’m brazilian and my surname actually means ’shoes’ in portuguese

Ruby 11:46 PM:
Oh, i see. it’s being the case.  

Phillip Calcado “Shoes” 11:46 PM:
:)

O cara me adicionou com nick de ‘ruby’ eu, sinceramente, achei que fosse a linguagem de programação :P

Removendo algumas teias de aranha do blog. Está sendo um tempo bem difícil com todos estes feriados e tudo mais por aqui mas consegui uma brecha razoável neste natal para colocar algumas coisas em dia.

Como vimos nos últimos capítulos estou em um grande cliente num projeto em Ruby. Na verdade o projeto é uma grande plataforma tecnológica onde Java é usado no produto em si e Ruby no grande conjunto de ferramentas que os desenvolvedores criaram. A parte que eu estou trabalhando neste momento (ou para onde irei voltar dia 2 de janeiro) é um sistema que atesta a veracidade de informações.

Não dá para falar muito sobre o projeto em si mas é algo bem interessante. A empresa cliente é membro de um grande conglomerado de empresas tradicionalíssimas que lidam com tecnologia e engenharia em diversas frentes. Essa empresa em específico tem um problema interessante: ela possui uma mina de ouro em dados exclusivos mas seu sistema é completamente ultrapassado. Mesmo com esse problema em forma de legado seu banco de dados é a fonte mais confiável sobre estes dados que se têm na Oceania e estes dados são necessários para praticamente todas as empresas do país, então ela se mantém como player no mercado.

Como sempre acontece nestes novos (30 anos?) tempos boa parte dos seus clientes não está satisfeita com os serviços e está usando meios alternativos para conseguir as informações que precisa sem passar pelo sistema burocrático e antiquado. Mesmo estes meios sendo mais caros e trabalhosos que o sistema legado ainda assim preferem fugir do sistema atual de alguma forma, qualquer que seja.

Há alguns anos a ThoughtWorks entrou nesta empresa para tocar um projeto que está entregando a fase final em algumas semanas. O trabalho foi tão bem aceito que a empresa adotou o estilo agile & lean de administrar as coisas para si, ao andar pelos dois prédios de 7 andares que a empresa ocupa você vai ver dezenas de cartões pregados na parede formando diversos posteres kanban, do pessoal de marketing até o da produção. Para lidar com o domínio de negócio, algo bem específico e pesado, eles formaram várias pequenas equipes, geralmente com cinco pares de desenvolvedores (100% pair programming), um ou dois analistas de negócios, um representante do cliente (client on-site) e alguns analistas de testes.

Como falei a coisa funcionou bem e o projeto onde eu estou é o segundo com participação da ThoughtWorks. Além dos nossos consultores existem diversos funcionários e alguns consultores empregados por outras empresas: É muito engraçado ver gente que trabalha oficialmente para uma empresa de três letrinhas, CMMi nível 23 e meio praticando agile feliz da vida e comentando como este é o primeiro projeto que vê funcionar na vida.

É interessante ver mais um caso de empresa que muda não para seguir a nova regrinha do jogo mas sim porque precisa mudar. Sei que tem muita gente que discorda de mim mas acho que nos últimos anos as empresas ficaram muito mais maduras com relação ao que adquirem. Há um movimento interessante nas empresas brasileiras que fazem do software seu negócio para retirar terceirizados e colocar sua gente para desenvolver.

Se você perguntar a qualquer analista de mercado ou ler qualquer boa ou má publicação vai ver que isso seria a maior besteira. Ainda que uma empresa como Globo.com, UOL, ig, e etc. dependa do software ela não produz software para viver. Uma empresa deste tipo deveria, segundo a lógica do preto-no-branco, comprar os serviços para uma empresa de desenvolvimento de software. Isso faz sentido e diminui o custo de manter uma equipe de desenvolvimento. O problema é que, como sempre diz minha esposa: economia simplista tende à economia burra.

O modelo funciona no papel e deveria funcionar na vida real mas não funciona. Segundo o pensamento acima quando contratamos uma empresa de software estamos contratando serviços de alguém especializado nisso. Mentira. A grande, grande maioria das empresas que oferecem serviços de consultoria no desenvolvimento não tem a menor idéia do que é desenvolver um software. Seus profissionais são expostos (quando são!) a um treinamento pasteurizado e superficial, os poucos profissionais capacitados destas empresas são por mérito próprio.

Então temos uma equação interessante. Digamos que manter funcionários especializados no desenvolvimento na folha de pagamento custe X. Esse é, por exemplo, o mesmo valor que pagamos à empresa JCN (nome ilustrativo, nem sei se existe uma empresa com esse nome) para alocar seus funcionários na nossa empresa. Se fosse só por isso ia ser um negócio estranho, íamos ter um 0-a-0 no investimento. O problema é que manter um corpo técnico como funcionários da empresa não custa só isso, você precisa investir para que este corpo técnico seja capacitado. Este é o custo que seria evitado contratando os serviços da JCN.

O problema é que após algumas décadas os clientes passaram a perceber que a empresa JCN não investe nada nos seus profissionais. Eles começaram a perceber que a JCN não entende nada de desenvolvimento de software. Alguns clientes não acham que valha a pena fazer algo a este respeito. Continuam na mesma coisa, exigem um certificado CMMi novo e toda vez que fecham um contrato já se preparam para o processo que sem dúvida vai acontecer quando o projeto não for entregue nos termos deste.

Tem outras empresas, no entanto, que não podem ter este prejuízo porque se o software atrasar não vai ser seu gerenciador de estoque que sai do ar, é o seu negócio como um todo, sua fonte de renda. Pelo que já vi na prática essas empresas fazem uma de duas coisas: ou (re-)internalizam o desenvolvimento ou contratam uma empresa realmente capacitada.

A primeira parte é mais cara e trabalhosa, mas pode ser melhor. O cliente adquire uma equipe de desenvolvimento e se preocupa em treiná-los. É preciso que este time entenda como desenvolver software e é por isso que estamos vendo tantos cursos in-company de Scrum, XP e etc. Você já viu consultoria de três letrinhas pagar isso para seus funcionários? Quem está comprando estes treinamentos são os clientes, não os fornecedores. Algo para pensar, não?

No segundo caso o cliente acha uma empresa em que confie para uma parceria. Neste ponto que eu acho que as pequenas consultorias tendem a fazer bastante dinheiro. Um grupo pequeno de desenvolvedores talentosos e motivados pode fazer muito mais do que uma grande corporação de três letrinhas com duzentos funcionários alocados para seu projeto. Palavra de quem já esteve dois dois lados, de quem compra e de quem vende.

O meu cliente atual está indo para a primeira opção. Para chegar lá ele tem que enfrentar dois problemas: 1) é caro e 2) se os dois projetos não saírem até o meio do ano não precisa mais continuar a contratar gente porque a oportunidade vai ser perdida. Neste cenário o que eles fazem é contratar consultores que eles confiem para atuar junto aos seus funcionários e desenvolver o software. Os consultores, mesmo os das empresas de três letrinhas, são minuciosamente entrevistados num processo que lembra o próprio processo seletivo da ThoughtWorks.

Após este tempinho lá e medindo com minha experiência passada eu acredito que estejam no caminho certo. Eles possuem equipes com profissionais muito acima da média a um custo razoável. Estes profissionais estão entregando os projetos e ao mesmo tempo construindo a cara dos departamentos de desenvolvimento. Quando os projetos encerrarem acho que 1/3 do número de pessoas vai ser necessário para manutenção e demais desenvolvimento, como é o aproximado número de consultores não deve haver problema. Os times pequenos já são rearranjados diariamente mesmo.

Claro que o processo de achar consultores é difícil e requer investimento. Seguir este plano é bem mais difícil que fazer uma ligação do tipo: “Alô, é da JCN? Me manda 300 programadores Java, por favor? 30 minutos? Obrigado”. Eu não diria que é uma solução para todos, sequer para a maioria, já falamos um pouco sobre isso aqui.

O que eu digo a respeito da situação na maioria das empresas que está com problemas no desenvolvimento (e qual não está?) é: façam algo. Após tanto tempo comprando dos mesmos fornecedores e recebendo porcaria em troca porque você continua com eles? Após tanto tempo desenvolvendo software ruimd esta forma porqu você continua fazendo isso?

Seja lá o que fizer, faça algo. Só, por favor, não compre soluções de caixinha. Certificados, ferramentas, cursos, livros, vudu… nada disso vai adiantar, pelo menos não sozinho. Descubra a motivação das coisas e veja se aquele eu fornecedor (ou se o produto que ofereces) que diz que faz a práticas X e Y e por iso tem o certificado Z sabe, ao menos, porque ele deveria fazer aquilo.

Desde que cheguei aqui na ThoughtWorks as coisas têm sido bem calmas. O primeiro dia eu fui recebido pelas pessoas e recebi meu infame MacBook Pro (eu pude escolher entre um Mac ou PC antes de vr pra Austrália, BAs pegam um MacBook comum, Devs pegam um MacBook Pro 2.2Ghz/2GB). Depois de ser resresentado ao Lotus Notes (essa porcaria que eu não usava desde 2005) eu fui para a beach.

Na ThoughtWorks, ‘beach’é quando você não está alocado em nenhum projeto. Você vai ao escritório todo dia com seu notebook e senta na “main desk”, uma graaaaaande mesa sem lugares marcados. O escritório possui tudo que você iria querer: coca-cola, sucos, frutas frescas, cereais, chocolates e doces em geral, água, café grátis (a TW tem um contrato com uma empresa tipo Starbucks), wii e… cerveja.

Na beach você faz basicamete o que quiser. A maioria das pessoas está sempre procurando sistemas para fazer e testar novos conhecimentos, a dupla Alex & Alex que costumam sentar próximos a mim arrumaram uns requisitos com a menina do RH para criar um sistema e treinar Rails. Um outro que é desenvolvedor .Net está fazendo um feed reader em GWT. Todo mundo conversa bastante e socializa, tem uma galera que, como eu, não era usuário de Mac e ficamos batendo a cabeça e chorando as pitangas juntos.

Durante meu tempo na beach eu aproveitei para brincar com o Antlr. No Fragmental.tw eu já falei uma vez que estou implementando um esquema de conectar DSLs via um barramento, eu tenho uma linguagem pronta e preciso das outras para continuar. Ainda não consigo fazer minha linguagem ser aceita pela gramática mas tá indo bem…

Outra coisa legal no escritório é que temos almoços corporativos. Serve para trazer pro escritório o pessoal que está alocado nos clientes pela cidade, ao contrário de consultorias que conheço por aí não é porque você está alocado que você não se relaciona mais com a TW, você simplesmnte é um TWer alocado. Esses almoços são dentro do escritório, aqui em Melbourne são terças e sextas. Hoje tivemos sushi.

E ontem houve também um dos eventos típicos: pelo menos uma vez por mês a TW fecha um bar ou pub e reúne todo mundo da empresa e alguns “clientes selecionados”(pessoas que trabalham nos clientes e possuem o espírito “cool”da TW).

Hoje foi meu último dia na beach, vou ser alocado em um projeto a partir de segunda. O legal é que o prédio do cliente é vizinho ao apartamento onde estou morando, literalmente à cinco minutos andando de casa.