“Philosophy is questions that may never be answered. Religion is answers that may never be questioned.”

(“Filosofia são questões que podem nunca ser respondidas. Religião são respostas que nunca podem ser questionadas.”)

Quando li essa frase imediatamente lembrei do que acontece no dia-a-dia do nosso mercado; do ambiente de trabalho a conferências e listas de discussão. Sem querer entrar em detalhes profundos ou em opiniões/flames sobre assuntos não-técnicos, vejo que existem dois tipos de programadores: os Religiosos e os Filósofos.

A palavra “religião” vem do latim “religio”, que significa “prestar culto a uma divindade”. Os programadores Religiosos fazem exatamente isso: aproveitam todas as oportunidades que podem para louvarem a sua linguagem ou framework favoritos. Os Religiosos dificilmente aceitam “religiões” diferentes da sua e os mais extremistas acreditam que a sua linguagem ou framework resolve todos os problemas do universo e são a chave da salvação da humanidade. Eles aceitam tudo cegamente e nunca reconhecem ou questionam os defeitos desses projetos que apoiam (e em alguns casos mais extremos até transformam esses problemas em “features”). Quando aparece um problema pela frente não precisa nem pensar: ele usará a sua ferramenta favorita para resolvê-lo, não importa o que seja (um padrão também conhecido como “One Ring to rule them all”).

“Filosofia” vem do grego “philos” (que ama) + “sophia” (sabedoria), ou seja, “que ama a sabedoria”. Filosofia é a investigação crítica e racional de questões, ou seja, um programador Filósofo não está procurando defender uma linguagem ou framework mas sim em investigar várias delas, analisar como elas funcionam e refletir sobre como elas podem ajudá-lo a resolver problemas. Os Filósofos são curiosos; eles sempre querem compreender e questionar o funcionamento e utilidade das ferramentas que usam. Quando precisam resolver um problema eles analisam de forma racional todas as opções que conhecem e se nenhuma delas for boa o suficiente eles pesquisam e procuram uma opção mais eficiente.

Um programador precisa resolver problemas complexos com qualidade e precisa ser cada vez mais produtivo/veloz para atingir um objetivo (desenvolver um produto, terminar um projeto da sua empresa e por ai vai). A melhor ferramenta não é a sua preferida ou aquela que você escolheu para seguir e amar, e sim aquela que te faz ser mais rápido, mais produtivo, com mais qualidade e que te dá mais conforto para trabalhar. A melhor ferramenta é a que melhor atende os requisitos da sua profissão e do seu projeto, não o seu ego (ou sua religião).

Seja menos “religioso” e mais “filósofo”! Com a mente aberta e sem encarar ferramentas como “a verdade definitiva” (ou descartando-as sem ao menos testar e conhecer como funcionam) você terá muito mais chances de ser bem-sucedido.

Esta será a segunda edição do evento no Brasil, que também já acontenceu em Sunnyvale, Londres, Bangalore e Taiwan. A última edição no Brasil foi em novembro de 2008 e foi um sucesso enorme; com aproximadamente 200 participantes e uma porção de hacks interessantes!

Serão 24 horas sem parar de hacking, aprendizado, diversão e a oportunidade de conhecer outros hackers! O Yahoo! vai patrocinar comida, bebida e tudo mais que os hackers precisarão para ficarem confortáveis, felizes e liberarem sua criatividade! Haverá também um espaço pra dormir caso alguém queira tirar uma soneca.

No último Hack Day (que eu infelizmente não estava presente) houve hacks muito legais, de aplicações móveis a hacks de hardware. Por exemplo, os ganhadores da categoria “What the Hack” usaram Python, Flickr, Twitter e alguns pedaços de hardware para construir uma placa com LEDs que piscavam mais ou menos dependendo do número de fotos no Flickr e posts no Twitter com a tag oficial do Hack Day.

Também houve um hack super criativo sem código (como assim?!?!), que inclusive acabou obrigando que uma nova categoria fosse criada – “Using the environment Hack”:

Vamos juntos criar novos aplicativos usando as plataformas abertas do Yahoo! como YQL, YAP, Meme, YUI3, Pipes, Flickr e, é claro, quaisquer outras ferramentas de desenvolvimento abertas que você quiser usar. Os melhores hackers ganharão um prêmio e o direito de serem vangloriados até o fim dos tempos ou o próximo Hack Day, o que quer que aconteça primeiro.

As inscrições são limitadas, portanto corra e faça logo a sua em http://hackday.com.br! Caso tenha alguma dúvida entre em contato pelo e-mail openhackbrazil@yahoo-inc.com.

Está aberta a temporada de hacking no Brasil!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor.

Quando você começa com desenvolvimento ágil não é só o processo de desenvolvimento de software que muda mas também vários detalhes de como a sua empresa funciona. Por exemplo, é muito difícil imaginar um time ágil que funcione com “comando-e-controle”. Os times são auto-gerenciados, o que implica em um outro estilo de gestão. Ao invés de chefes que cobram, aparecem os líderes-servidores, que dão todos os recursos possíveis para que seus times possam trabalhar e tomar decisões. A base da pirâmide é que passa a decidir e não mais o topo, porque eles são os mais indicados por deterem o melhor conhecimento para fazer isso. Em alguns casos mais extremos em empresas mais modernas como a Semco, são os próprios funcionários que contratam seus gerentes.

Ou seja, quando falamos de métodos ágeis, por mais que estejamos nos referindo aos métodos ágeis de desenvolvimento de software existem uma porção de outros conceitos e filosofias que acabam entrando no mesmo barco por serem tão intimamente relacionados.

Tenho um exemplo para tentar explicar melhor onde eu quero chegar. Uma vez eu trabalhava numa empresa de tamanho razoável que, como várias outras desse porte, tinha um tradicional departamento de RH. Num dia eu tive um problema bem urgente e precisei da ajuda do pessoal do RH. Quando fui conversar com eles, duas coisas desagradáveis aconteceram. Primeiro, eles me trataram mal e como se estivessem fazendo um favor pra mim. Segundo, eles disseram que meu pedido só seria atendido em alguns dias, porque eles tinham muitas coisas importantes para fazer. O que acontece é que minha filha estava muito doente, eu tive um problema com meu plano de saúde e eles não estavam liberando meu atendimento por nada. Um time de RH com a “cultura ágil” saberia em primeiro lugar que, dado que eu sou o principal “usuário” deles, eu mereço atenção, respeito e os meus problemas são os problemas deles. As urgências dos funcionários deveriam ser mais importantes do que qualquer papelada que eles tenham para fazer. E em segundo, mesmo que o backlog deles fosse absurdamente grande, um assunto com tamanha severidade com certeza “furaria” a fila.

Então, quando eu digo que outros departamentos das empresas poderiam ser “ágeis”, não estou sugerindo que eles trabalhem com desenvolvimento ágil de software – o que não faria nenhum sentido – mas sim que eles usem os mesmos conceitos de liderança, times auto-organizados trabalhando num ambiente participativo, baseado na confiança e cooperação, fazendo um movimento e esforço maiores para entenderem quem de fato são seus “usuários” e quais são suas necessidades, criar visões para seus produtos e departamentos (que os ajudariam a tomar melhores decisões) e por aí vai.

Pegando esse departamento de RH que falei acima como exemplo, não seria perfeitamente aceitável que eles fizessem um exercício de personas para descobrirem qual é o perfil dos seus usuários? Não seria ótimo que eles fizessem sessões de chartering, discutissem seus valores, fizessem retrospectivas para descobrirem como melhorar seu processo e assim por diante? Imagine quão transparente e organizado seria chegar na sala deles e ver um quadro de Kanban mostrando sua linha de atividades, o progresso delas e os gargalos da equipe?

Acho que talvez isso não aconteça porque grande parte do material e exemplos disponíveis sobre esses assuntos estão formatados para pessoas relacionadas à desenvolvimento de software. Sim, existem livros como os do Ricardo Semler que estão categorizados nas livrarias como “Administração” ou “Negócios”, mas não sei porque o pessoal de Administração e Negócios não parece se interessar por esses assuntos. Porque será?

Já está na hora desse “fork” entre a comunidade ágil das empresas e as outras áreas acabar. Chega uma hora que parece que existem duas empresas funcionando totalmente diferentes dentro de uma. Precisamos trazer pessoas das outras áreas e outros níveis hierárquicos para as conferências e para o nosso mundo. Vou adorar o dia que eu for na Agile Conference e conversar com Gerentes de RH, VPs de Marketing e outras pessoas que não sejam do departamento de desenvolvimento; ou então quando for nas reuniões de grupos de usuários e não encontrar somente os “agilistas” mas também os administradores, os analistas de recursos humanos, os contadores e por ai vai.

E aí, por onde vamos começar?

Meu sonho aqui era ajudar a construir uma coisa maior do que eu e ter uma história para contar. Tenho muito orgulho de ter contribuido para mudar uma empresa tão tradicional como a Globo e de ter trabalhado diretamente num dos maiores exemplos de mudança organizacional e adoção de metodologias ágeis do Brasil. Trabalhei nos produtos de maior audiência da Internet brasileira, entreguei dezenas de projetos bem sucedidos, quebrei diversas barreiras e ganhei o respeito de dezenas de pessoas. Foi incrível! Me sinto feliz por ter cumprido uma grande parte dos meus objetivos e sei que meus amigos que vão me substituir vão continuar a fazer mais conquistas e vão fazer um trabalho muito melhor que o meu, levando a Globo.com para o caminho do sucesso. E como eu já aprendi, o mundo dá voltas. Quem sabe um dia eu sinto saudades do Rio de Janeiro…

É muito difícil saber as palavras certas pra usar numa hora dessas. A Globo.com é uma empresa incrível para trabalhar e, até onde eu consigo enxergar, a melhor do Brasil. Disparada. Ela foi inspiração para dezenas de posts desse blog e eu não tenho palavras pra dizer o quanto sou grato por ter tido a oportunidade de trabalhar com pessoas tão talentosas nesses anos todos aqui. Eu adoro essa empresa, dei meu sangue por ela, aprendi mais do que em qualquer outro lugar que trabalhei e conheci alguns dos melhores profissionais desse mercado. Queria citar os nomes de todos vocês e agradecê-los por terem me ensinado tanto, mas não quero correr o risco de esquecer nenhuma sequer das dezenas de pessoas que me apoiaram ao longo desse caminho. Em todas as minhas temporadas e equipes na Globo.com fiz amigos que vou levar para a vida toda e que vou sentir muita falta. É muito triste e muito difícil deixar tantas conquistas e realizações para trás, mas o tempo não pára e eu preciso seguir em frente para conquistar todos os meus sonhos.

Em Janeiro de 2010 estou me mudando para São Paulo e partindo para vôos mais altos e novos desafios no Yahoo!, assumindo a posição de Software Development Manager. Aliás, aproveitando a oportunidade, temos várias vagas em aberto, mas isso é assunto para um outro post.

Muitos desafios me aguardam e eu espero ter bastante história pra contar. Estou muito empolgado para trabalhar em produtos novos e criar novas maneiras de facilitar e divertir a vida das pessoas. Vou trabalhar também para tornar o Yahoo! um lugar ainda mais incrível para trabalhar, com ainda mais software e produtos de qualidade e mais uma referência em desenvolvimento ágil no Brasil e – sendo um pouco mais ambicioso (no sentido positivo da palavra) – no mundo!

Mais uma vez, obrigado Globo.com. Yahoo!, aí vou eu!

Depois de trabalhar diariamente com processos ágeis e uma porção de times diferentes na Globo.com, minha sensação é a daquele dito popular que diz que quanto mais você sabe de alguma coisa, mais você descobre que tem que aprender. De tempos em tempos surgem idéias novas excelentes e as vezes são coisas tão simples que eu me pergunto porque nunca tinha pensado nelas. Ou então algumas idéias que não deram certo no passado voltam à tona, são colocadas em prática e passam a funcionar muito bem. Sempre que eu acho que já aprendi como alguma coisa funciona alguém aparece com uma idéia melhor e me prova que eu estava errado em achar isso.

Me lembro quando perguntei lá no início para o Boris Gloger sobre o tempo que levaria para as coisas acontecerem. Na época ele falou que para uma empresa do tamanho da Globo.com certamente levaria de 2 a 4 anos para as coisas mudarem de fato. Eu achei um exagero e que ele estava louco, mas era eu que não tinha noção do tamanho da coisa toda. Ele estava certo.

Infelizmente eu não tenho uma história romântica para contar e estaria mentindo se dissesse que as coisas são maravilhosas depois que você adota Agile, Scrum ou o que quer que seja. Muito pelo contrário, os problemas começam a aparecer e tudo fica caótico. As vezes a quantidade de problemas chega a ser enlouquecedora e minha insônia aumentou consideravelmente depois disso. Mas eu não tenho nenhuma dúvida de que os processos ágeis são os que mais se adaptam às características de projetos de desenvolvimento de software, mais do que qualquer outra coisa que eu já tenha usado. Tivemos muito mais sucesso do que em qualquer outra iniciativa na história da empresa e as coisas acontecem muito mais e muito melhor do que aconteciam antes, mas mesmo assim ainda temos um caminho muito longo pela frente.

Hoje eu consigo entender com mais clareza o real sentido do empirismo que tanto se fala. Mesmo com pilhas de livros sobre desenvolvimento ágil na minha prateleira, eu olho para trás e vejo que o processo de “tentativa e erro” foi muito mais importante para o meu aprendizado do que qualquer teoria. Várias coisas escritas nos livros deram certo para alguns times e não deram para outros, e no fim das contas o que ficou foi uma mistura de todas essa experiências. Fomos fazendo as coisas, vendo o que dava certo ou errado, mudando, adaptando e seguindo em frente. Hoje não dá pra dizer que a Globo.com usa Scrum, XP, Lean ou Kanban. Você pode encontrar todos os seus sabores preferidos de Agile por aqui, às vezes misturados e até mesmo bem customizados e diferentes do tradicional.

Nesse tempo todo vivenciei muitos problemas, muitos sucessos, muitas derrotas, muitas falhas e muita mudança. Eu queria poder dizer que encontrei o Santo Graal do desenvolvimento ágil, mas dificilmente isso existe. E se existir, provavelmente o da minha empresa será diferente da sua e por ai vai. Porém, eu posso falar de algumas coisas que eu aprendi e que talvez possam ser úteis para outras pessoas e empresas:

Você sempre estará em transição.

Basicamente eu não acredito mais em transição ágil como eu já li por ai, que parece uma coisa que tem inicio, meio e fim. Hoje eu percebo que sempre se está em transição. Sempre surgirão projetos novos com características diferentes e sempre será necessário ajustar e se adaptar. Isso tudo fora que as pessoas e os times também mudam, e ai começa tudo denovo. É um trabalho que nunca acaba.

É muito fácil começar a fazer Scrum, o difícil é vencer a resistência das pessoas.

Grande parte do meu tempo nesses anos foi investido em quebrar barreiras e a resistência das pessoas. E não estou falando de diretores ou gerentes, às vezes os piores problemas estão dentro dos times. Os mais diversos tipos de problemas acontecem: tem gente que tem medo de trabalhar em par e expôr suas fraquezas para os outros, tem gente insatisfeita na empresa que envenena iniciativas, enfim, acontece de tudo. É muito importante trabalhar com pessoas bem intencionadas, comprometidas e que acreditam no que estão fazendo e que acreditam que as coisas sempre podem (e devem) ser melhoradas.

As pessoas precisam estar felizes.

É importantíssimo que a empresa reconheça seus talentos, que eles ganhem o que merecem e que eles trabalhem num ambiente agradável. Ninguém trabalha direito e dá 100% do seu potencial se não estiver feliz e satisfeito com a empresa. Pessoas infelizes e insatisfeitas podem acabar com um time inteiro, por isso a empresa tem que dar o primeiro passo e dar todas as condições para que isso não aconteça e, quando acontecer, resolver o problema o mais rápido possível.

Se o foco das pessoas for em “fazer telas”, “testar” ou “escrever software”, você está perdido. O foco das pessoas deve ser o produto, e não a sua função.

Muito desenvolvedor não gosta de fazer teste exploratório “porque isso é função do cara de QA”. Muito designer não gosta de fazer CSS e HTML porque isso é coisa de “desenvolvedor de front-end”. Bullshit! Imagine se um zagueiro está com a bola na linha do gol e diz que não vai fazer o gol porque não é atacante? Não tem essa, o foco é ganhar o jogo, entregar o produto, deixar o cliente feliz, não importa fazendo o que. Com o tempo você descobre a receita do time (quantidade de pessoas de cada especialidade) para que as pessoas passem a maior parte do tempo fazendo sua especialidade, mas isso não significa que elas não devem fazer ou entender de outras coisas.

Escalar não é facil. Aliás, se for possível, não escale nunca.

Times ágeis funcionam melhor quando são pequenos, porque o universo de pessoas é menor e a comunicação é melhor, as pessoas confiam mais no resto do time e por aí vai. Quando o número de pessoas e de times aumenta, a comunicação fica problemática e isso gera uma porção de problemas, desde coisas triviais como conflitos de merge até coisas mais complexas de resolver como falta de confiança, dificuldade em mudar de direção, dificuldade de passar a visão do produto, pessoas querendo aparecer mais do que outras e por aí vai. Faça um teste: reuna 30 amigos seus e tentem combinar um lugar para almoçar em no máximo 2 minutos. Repita o teste com 3 amigos e compare os resultados. Foi possível combinar um único lugar de forma unânime? Quanto tempo levou? Quais foram os conflitos de interesse? Qual foi o nível de barulho, stress e insatisfação das pessoas? Ter mais pessoas ajudou a fazer com que a decisão fosse mais rápida ou mais demorada? Talvez esse não seja o melhor exemplo do mundo mas vai ser bem fácil de perceber como times grandes se organizam com muito mais dificuldade.

Boas práticas de engenharia e desenvolvimento ágil como automatização, testes, refatoração, programação em par, integração contínua e TDD são fundamentais, imprescindíveis, inevitáveis, totalmente obrigatórias.

Todos os grandes saltos de qualidade e produtividade que demos na história da evolução da Globo.com foram porque essas práticas foram intensificadas e usadas com mais disciplina, e todas as vezes que elas não recebem a devida importância a velocidade diminui, a produtividade baixa e o time entrega menos (e com mais defeitos).

Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco).

As regras são excelentes quando você não sabe o que está fazendo. Depois que aprender, quebre-as.

Geralmente quando as pessoas começam com Agile o que se recomenda é que você siga as regras à risca por algumas iterações até que você aprenda e que o processo esteja “no sangue”, e só depois que possíveis customizações devem ser feitas. Muita gente confunde isso com “sempre siga as regras à risca”. Por exemplo, hoje alguém me convenceu numa conversa que o Sprint Planning 2 do jeito que um determinado time estava fazendo estava bem inútil, uma grande perda de tempo. A sugestão foi fazer uma coisa mais “just-in-time”, ou seja, na hora que a história começar a ser desenvolvida. Muita gente pode falar que “ah, mas não é assim que o Scrum funciona” ou o clássico “aqui na empresa nós não fazemos desse jeito”. Se você tem um bom motivo para mudar as regras do jogo, discuta o assunto com o time e implemente as melhorias. Não existe essa coisa de “as regras do Scrum”, existem times produtivos com alta capacidade de adaptação e em constante evolução ou times que passam 50% do tempo discutindo o processo e não deixam o cliente feliz.

Trabalhar num ambiente ágil é muito muito muito mais divertido.

Acabei de passar quase 40 dias de férias e em conferências. Muita gente estaria odiando voltar para o trabalho depois disso, mas eu gostei. Quando eu cheguei hoje na empresa depois de mais de 1 mês a minha mesa já não era mais minha e eu não achava meu computador. O escritório mudou totalmente e o time que eu estava está todo misturado. Quando eu entrei na sala as pessoas estavam em pé discutindo, rabiscando no quadro e o barulho estava alto pra caramba. Depois de contar as novidades, de almoçar e de alguns updates, passei o resto da tarde programando em par numa tarefa que nem eu e nem o meu par faziamos idéia de como resolver, mas juntos descobrimos como fazer e resolvemos o problema. Foi um dia caótico porém muito produtivo e muito divertido, como a maioria dos que eu tenho. Tudo muda muito e está em constante evolução, e cada dia é um novo desafio. Se você gosta de ficar escondido atrás da “baia” e tem dificuldades em dividir o seu teclado com um amigo, recomendo fortemente que você não use Agile.

Agile não é o Santo Graal.

Nenhum processo de desenvolvimento (ágil ou não) é perfeito. Muita gente gosta, muita gente não gosta, alguns não se adaptam, outros se motivam a cada dia com os novos desafios e é assim que as coisas funcionam. <ironia> “Agile é tão perfeito” </ironia> que quando as coisas dão errado é muito mais fácil culpar o seu processo e reclamar que ele não funciona. Bullshit! Como o Jeff Patton fala, as pessoas fazem isso porque o processo não vai se defender de você e porque é muito mais dificil assumir e enxergar os problemas de verdade. Uma das chaves de ser bem sucedido nesses processos é entender que eles são apenas ferramentas muito simples e que se não estão funcionando é porque você precisa encontrar e resolver algum problema da sua empresa, do seu time, das pessoas ou do que quer que seja. Não bote a culpa no processo.

As pessoas são mais importantes que o processo. Foco nas pessoas.

São elas que fazem tudo acontecer. Quanto mais agentes de mudança sua empresa puder ter, melhor. A empresa tem que reconhecer essas pessoas e motivá-las para que elas motivem ainda mais seus pares e assim por diante. É preciso dar liberdade para elas criarem, tentarem coisas novas e errarem sem medo de serem repreendidas. Faça de tudo para que todos estejam felizes e motivados. Resolva os conflitos. Coloque tudo em pratos limpos. Trate todos com respeito e como amigos. Faça as pessoas crescerem e deixe (e ajude) que elas tenham visibilidade dentro da empresa. De todas as coisas que eu vi até hoje, nada é mais eficaz do que ter as pessoas certas do seu lado.

Nada disso é definitivo e eu posso mudar de opinião a qualquer momento sobre qualquer uma dessas coisas. Aliás, hoje numa conversa aprendi que é ótimo mudar de opinião, porque significa que você aprendeu alguma coisa nova/diferente que te fez pensar de uma forma nova/diferente e, portanto, você evoluiu. Fica então a última:

Crie sua opinião, aprenda mais e mude sua opinião. Esteja em constante evolução.

Esta é a minha segunda participação nessa conferência sensacional com alguns dos melhores palestrantes e profissionais de desenvolvimento de software do mundo!

Espero conseguir colocar os posts em dia durante a semana.

Amanhã será o primeiro de dois dias de tutoriais seguidos de dois dias de conferência com a participação de grandes nomes do mundo ágil como Jeff Patton, Alistair Cockburn, Mike Cohn, Jim Highsmith, Andy Hunt, David Hussman, Joshua Kerievsky, Linda Rising, Alan Shalloway e por aí vai. Para encerrar, na sexta-feira acontecerá o Agile Leadership Summit liderado pela Pollyanna Pixton.

Os próximos dias prometem!

Ficou muito muito divertido! As entrevistas com os palestrantes Ryan Ozimek, Guilherme Silveira, Fabio Akita e Jacob Kaplan-Moss ficaram ótimas e ainda conseguimos alguns convidados especiais para participarem na hora como o Paulo Silveira, Marcos Tapajós e Mauricio Samy Silva (o Maujor). Uma pena que o Nico Steppat e o Jeff Patton não puderam participar mas fica para a próxima.

Ainda, quem quiser ver o “making of” do Podcast pode acessar os vídeos no canal do Dev in Rio no Vimeo.

Eu, Guilherme Cirne, Emerson Macedo e Anselmo Alves já estamos preparando as malas para ir no Rails Summit 2009 (isso sem falar do resto da galera do Rio de Janeiro que também vai em massa)!

Tá afim de ir também? Então faça um vídeo criativo explicando porque você também quer ir na Rails Summit 2009 e poste o link aqui nos comentários. O vídeo mais criativo (que será escolhido por mim e o Fabio Akita até o fim do dia 07 de outubro) vai ganhar um convite para a Rails Summit 2009!

Mesmo tendo sido idealizado, planejado e executado em pouco mais de 20 dias, o Dev in Rio 2009 foi excelente, um sucesso total! Conseguimos reunir em plena segunda-feira cerca de 400 pessoas para falar de desenvolvimento de software, se divertirem no Dojo e terem um dia de muita diversão que terminou no maior #Horaextra de todos os tempos.

O Dev in Rio 2009 começou na hora programada quando eu e meu amigo Henrique Bastos abrimos o evento. Rapidamente falamos sobre o evento e sobre como seria o nosso dia. Tratamos de como achamos importante a interação entre comunidades e aprender com pessoas especializadas em tecnologias diversas. Aproveitamos também para agradecer muito aos nossos patrocinadores, apoiadores, comunidades e amigos que nos ajudaram muito mais do que vocês possam imaginar.

* Henrique Bastos e eu na abertura do Dev in Rio.

Abrindo os trabalhos, disparamos as duas trilhas do Dev in Rio 2009. No auditório principal, aconteceriam as palestras programadas, enquanto no foyer seria realizado o Coding Dojo.

O Coding Dojo é uma arena de programação organizada pela turma do Dojo Rio em conjunto com o Dojo@SP. A idéia é atacar problemas simples e lúdicos, utilizando técnicas de programação como Test-Driven Development e Modelagem SOLID. Este definitivamente foi o gol de placa do dia – o Dojo funcionou muito melhor do que nós poderiamos imaginar (exceto o Dojo de Java que não foi lá muito popular, tenho que admitir).

* Coding Dojo do Dev in Rio: 3 metros de código na parede!

* Galera participando do Coding Dojo do Dev in Rio.

A primeira palestra foi a do Ryan Ozymek, que entrou em cena com seu famoso pinguim para falar de sua experiência com software livre e a comunidade Joomla! Ele detalhou o funcionamento de uma grande comunidade de desenvolvimento e deu sua visão de empresário sobre como usar software livre para alavancar os negócios da sua empresa.

Logo depois, Guilherme Silveira e Nico Steppat trataram de um tema bastante polêmico: Java está morto? Abordaram os fatos de que existem muitas coisas além da linguagem no mundo Java e que apesar da linguagem estar “caducando” a JVM ainda pode ser muito útil.

Depois do almoço, Fabio Akita não deu trégua para quem estava com sono e fez uma excelente apresentação sobre o ecossistema Ruby on Rails com direito a videos, screencast e bastante informação além do código. Ele não sabe mas tirou o fôlego das meninas da tradução simultânea!

Na sequência, o (praticamente carioca) Jacob Kaplan-Moss fez sua apresentação sobre Django, o framework web para perfeccionistas desenvolvido em Python. Ele falou dos conceitos e valores que guiaram o desenvolvimento do projeto, além de mostrar um pouco de código para dar uma idéia ao público de como usar o Django na prática.

A última palestra do dia foi feita por Jeff Patton, que falou sobre desenvolvimento de produtos com métodos ágeis. Utilizando como narrativa a história de um projeto realizado em conjunto com Obie Fernandez, diversos problemas comuns no desenvolvimento de software (e suas soluções) foram destacados.

No final, nosso grande amigo Vinicius Manhães Teles liderou um bate-papo entre palestrantes, comunidades e o público. Tivemos a impressão de que se não controlassemos o relógio a conversa teria varado a noite, pois não faltavam assuntos e perguntas interessantes. O público participou bastante e foram levantadas questões como empreendedorismo e polêmicas como a estúpida regulamentação da profissão de analista de sistemas.

* Discussão liderada por Vinicius Teles. E antes que alguém pergunte, não, não é o cara do Myth Busters que está na foto, é o Jeff Patton.

Enquanto isso tudo rolava, eu, Henrique e o Gustavo Guanabara e a Flavia Freire (jornalista da Arteccom) passamos o dia gravando um gigantesco Podcast do evento, entrevistando o pessoal e filmando os bastidores. Falamos com palestrantes, patrocinadores e participantes sobre todos os assuntos abordados nas palestras! Guanabara, termina logo de editar esse treco porque eu tô ansioso pra ouvir! Veja o “making of” de alguns dos Podcasts com o Ryan Ozimek, com Guilherme e Paulo Silveira e com Fabio Akita e Marcos Tapajós. Assim que finalizarmos as edições vamos divulgar todo esse material.

* Guanabara gravando Podcast com Fabio Akita e Marcos Tapajós (e datalhe: ao fundo Guilherme Silveira e Paulo Silveira fazem Pair Programming).

Como o evento foi realizado numa segunda-feira, fechamos o evento convidando todos os participantes (ao som de “Estamos todos bêbados” do Matanza e com coreografia de Sylvestre Mergulhão e Henrique Andrade) para uma edição épica do #Horaextra no Lapa 40º. A entrada era gratuita para quem apresentasse o crachá do Dev in Rio 2009 e assim realizamos o maior #Horaextra de todos os tempos:

* Veja mais videos do Dev in Rio 2009.

Tenho certeza de que esse post não consegue transmitir 0,001% do que foi o Dev in Rio 2009 e a minha felicidade de ter conseguido realizá-lo. Gostaria de agradecer mais uma vez o apoio fundamental de toda a galera da Globo.com que viabilizou o evento, dos nossos patrocinadores Caelum, Locaweb e D-Click e de todos que nos apoiaram de alguma forma: Associação PythonBrasil, Fábrica Livre, Myfreecomm, OpenSourceMatters, Arteccom, DojoRio, Dojo@SP, #Horaextra, PythOnRio, RioJUG, RubyInside Brasil, Guanabara.info e todas as pessoas que participaram do Dev in Rio 2009. Sem vocês nada disso teria sido possivel.

* Participantes da mesa redonda do Dev in Rio.

Se você não foi no Dev in Rio, tenho duas coisas para te dizer: (1) você perdeu uma farra das melhores mas (2) em breve vamos disponibilizar os vídeos das apresentações para amenizar sua dor.

E que venha 2010!

Colaborar com outros projetos é bem fácil no Github, basta fazer um fork do projeto que eu pretendo colaborar, fazer minhas modificações e depois um “pull request” para o dono do projeto avaliar e integrar (ou não) o meu código ao dele. Antes do Github não funcionava muito diferente disso mas o que ele fez de bom foi facilitar esse fluxo e criar uma rede social bem interessante em torno desse mundo.

Isso é bem diferente de como as empresas normalmente funcionam. No caso da Globo.com, por exemplo, todos os repositórios sempre estiveram amontoados nos servidores CVS e Subversion e consequentemente “escondidos” (pouco visíveis) de possíveis colaboradores. Alguns até tinham permissão de commit restrita para um pequeno grupo e o processo de colaboração era ainda mais difícil. Não dá nem para abrir um branch seu, você tem que fazer as modificações localmente e mandar um patch por e-mail, e o merge geralmente não é muito fácil de fazer quando você tem um grande fluxos de merge para lá e para cá. Imagina então quando você trabalha na versão “v1″ do código e enquanto você produz a “v2″ um outro desenvolvedor pede merge antes de você? Era preciso esperar o merge terminar para dar checkout da versão nova e ficar mais uma vez fazendo o inferno do merge.

No início desse ano resolvemos experimentar usar o Gitorious, que é uma ferramenta similar ao Github porém Open Source e que você pode instalar num servidor da sua empresa. Isso tinha 2 objetivos: (1) criar uma cultura de “enterprise” Open Source e (2) facilitar a colaboração em projetos em que vários times trabalham e commitam ao mesmo tempo.

No início foi um inferno e houve uma rejeição muito grande de muita gente. O modelo de trabalho com o Git é bem diferente do que com CVS e Subversion. Você tem branches (e clones – que é um conceito um pouco diferente) que podem ser locais ou remotos, commits locais que não vão direto para o servidor e pulls/pushes. As pessoas tendem a fazer relações do tipo “o push é o que manda as coisas para o servidor, então ele equivale ao commit”. Mas então o que é o commit do Git? Enfim, não dá pra trabalhar pensando assim, é preciso dar um reset e entender a arquitetura desses sistemas de controle de versão distribuídos para entender que faz sentido sim ter um commit e só depois do push que o código está no repositório (no remoto, porque no local já estava).

Também foi difícil aprender a trabalhar com merges. No modelo antigo você evita fazer merges o máximo possível porque o trabalho para fazer isso é enorme. Geralmente você só faz quando acabou de fazer tudo para ter trabalho uma vez só. Ainda bem que existem ferramentas para ajudar (como as ferramentas das próprias IDEs) senão seria complicado. Se você trabalha da mesma forma com o Git geralmente vai se dar mal, porque não existem (não existiam mas estão começando a melhorar) as mesmas ferramentas de merge visual do CVS ou Subversion, e era um parto para fazer a coisa toda funcionar após fazer um merge de uma semana de fork. Com o Git funciona ao contrário: como o merge é automático (na maioria dos casos ele consegue se virar) então a estratégia é fazer merge toda hora, várias vezes por dia, o máximo que der.

Depois de alguns meses de “fricção” hoje já dá para ver um monte de frutos começando a aparecer. Por exemplo, no último sprint do meu time nós precisavamos usar um cliente Python para acessar a engine de busca da Globo.com. Como esse cliente era novo tinha uma série de problemas pequenos que precisavam ser resolvidos, mas o time que é responsável pelo projeto estava com vários compromissos e demoraria 2 semanas para trabalhar nisso. Então o Bernardo e o Andrews decidiram fazer um clone no Gitorious para contribuir com o projeto do time de busca, e eles não só resolveram os problemas como devolveram o código refatorado e com a cobertura de testes bem melhor. O outro time rapidamente integrou o novo código ao projeto e gostou tanto do trabalho deles que eles viraram commiters e agora podem fazer as modificações que forem necessárias em colaboração com o time de busca. Exatamente como funciona no mundo Open Source.

Além desse exemplo, no projeto que estou trabalhando (que é um framework para sites de publicação de conteúdo) temos vários times trabalhando no mesmo código ao mesmo tempo. Nesse momento tem cerca de 10 clones do projeto no nosso Gitorious e talvez cerca de 10 times trabalhando usando o mesmo código para fazer seus “add-ons”. O Git facilita o trabalho dos times para atualizarem constantemente sua base de código com o que entra de novo no branch master do mainline (o repositório principal do projeto) e o Gitorious torna isso tudo mais visível para todos.

Enfim, as vantages que nós passamos a ter com o Git e Gitorious são várias:

• Todo mundo pode ver facilmente os projetos que existem e quando novos projetos são criados;
• Todo mundo pode ver o que todo mundo está fazendo e em que estão trabalhando;
• Todo mundo pode facilmente criar e gerenciar seus projetos (sem precisar do Sys Admin);
• É bem facil de navegar nos projetos, ver e pegar código dos outros;
• Todo mundo pode criar seus clones de repositórios para trabalhar em cima do seu código e do código dos outros;
• Todo mundo pode colaborar de volta sem precisar de um processo complicado para isso;
• É mais fácil de fazer merges constantes e gerenciar múltiplas colaboracoes simultâneas;
• Fora as outras features interessantes que o Git tem e os sistemas de SCM antigos não como o stash, clones, merge automático e por aí vai.

Só para dizer um ponto negativo, a documentação de usuários do Git não é das melhores (mas tem melhorado bastante) e alguns comandos não são tão intuitivos (como deletar um branch remoto), mas nada que você não descubra e que não se acostume com o tempo.

Aconselho fortemente a todo mundo que puder que faça isso. Instale o Gitorious e fomente a colaboração entre os desenvolvedores da sua empresa! Se você estiver com muita grana também pode dar uma olhada no Github Firewall Install, que deve ser bem legal mas também é bem caro.

• Canal de vídeos do Dev in Rio no Vimeo
• Grupo de fotos do Dev in Rio no Flickr

Eu e Henrique acabamos de terminar um vídeo super especial de recordação do maior #Horaextra de todos os tempos! Espero que vocês gostem:

Ano passado eu fui e foi sensacional e esse ano promete ser ainda melhor! A programação está bem diferente do ano passado e conta com algumas novidades como Bryan Liles, Gregg Pollack, Jason Seifer, Pratik Naik, Richard Kilmer, Matt Aimonetti, além do pessoal que veio ano passado como Chad Fowler, David Chelimsky, Obie Fernandez e brazucas feras demais como o Fabio Kung, Marcos Tapajós, Nando Vieira, Vinicius Teles, Leonardo Borges, Carlos Brando e por aí vai. Enfim, não dá para perder de jeito nenhum!

Nós cariocas (eu, Henrique, Rafael, Sylvestre, Tapa, Vinicius, Ramon e quem mais for) vamos todos ficar no mesmo hotel pra fazermos a maior bagunça! Seguindo o exemplo do Vinicius Tapajós no ano passado, estamos divulgando o hotel pra que todo mundo possa ir pra lá e aumentar a bagunça.

Ficaremos hospedados no Holiday Inn Parque Anhembi que é dentro do Centro de Convenções Anhembi (o mesmo local do evento). O telefone para reservas é 0800-770-0858. Não é o hotel mais caro e nem o mais barato mas é pertinho do evento e fica bem fácil pra todo mundo. Nos vemos lá!

Como um bom desenvolvedor
Eu quero me cadastrar no Dev in Rio
Para que eu possa aprender mais e ser um profissional melhor
 
Cenário 1 - Cadastro no Dev in Rio
Dado que
    Eu navego para "http://devinrio.com.br/inscricoes_bra.php"
Quando
    Eu marco a radio "tipo_participacao"
    E eu clico no elemento "tipo_participacao"
    # ... tem que esperar a página ser carregada :)
    E eu espero por 5 segundos
    E eu vejo que a página atual contém "Login - Novo cadastro"
Então
    # Login
    Eu preencho a caixa de texto "email" com "seu@email.com"
    E eu preencho a caixa de texto "senha" com "senha"
    E eu preencho a caixa de texto "re_senha" com "senha"
    # Dados Pessoais
    E eu preencho a caixa de texto "nome_cracha" com "Pyccuracy da Silva"
    E eu preencho a caixa de texto "empresa_cracha" com "Globo.com"
    E eu preencho a caixa de texto "dd" com "01"
    E eu preencho a caixa de texto "mm" com "01"
    E eu preencho a caixa de texto "aaaa" com "1980"
    E eu preencho a caixa de texto "cpf" com "12345678910"
    E eu preencho a caixa de texto "ddd" com "21"
    E eu preencho a caixa de texto "telefone" com "23452345"
    E eu preencho a caixa de texto "ddd2" com "21"
    E eu preencho a caixa de texto "telefone_celular" com "23452345"
    # Endereço
    E eu preencho a caixa de texto "cep" com "23456789"
    E eu preencho a caixa de texto "endereco" com "Rua de Exemplo"
    E eu preencho a caixa de texto "numero" com "123"
    E eu preencho a caixa de texto "complemento" com "ap 101"
    E eu preencho a caixa de texto "bairro" com "Meu Bairro"
    E eu seleciono o item com texto "Rio de Janeiro" na select "estado"
    # ... tem que esperar o treco carregar os municipios :)
    E eu espero por 5 segundos
    E eu seleciono o item com texto "RIO DE JANEIRO" na select "municipio"
    # Seu perfil - pode colocar qualquer coisa :)
    E eu seleciono o item com valor "Outros" na select "ocupacao"
    E eu seleciono o item com valor "Superior completo" na select "escolaridade"
    E eu seleciono o item com valor "Amigos" na select "conhecimento"
    E eu seleciono o item com valor "Outra" na select "areas_atuacao"
    E eu clico no botão "sis_submitbutton2"
    E eu vejo que a página atual contém "sucesso"
    # E pra terminar, espera um pouquinho pra ver que a inscrição funcionou
    E eu espero por 10 segundos

Depois disso é só rodar com o comando “pyccuracy_console -l pt-br” e pronto, você já está cadastrado! Basta agora acessar o site para efetuar o pagamento com o seu cartão de crédito!

E agora, a promoção surpresa!

Ganha uma inscrição como convidado para o Dev in Rio e um kit de brinde da Globo.com (com camiseta, pen drive de 4GB e etc.) o primeiro programador que terminar o que falta do script, ou seja, fazer o pagamento completo por cartão de crédito ou boleto bancário, tanto faz (e antes que algum engraçadinho tente, não vale ninguém que já trabalha com o Pyccuracy aqui na Globo.com, hehe).

Só estará participando da promoção quem enviar os scripts aqui pelos comentários e eu vou seguir a ordem de postagem. O primeiro script que funcionar leva o prêmio!

Divirtam-se!