Fragmental

Não tem problema, siga o exemplo do Rodrigo e mande a sucata para quem regula uma profissão com leis de sucata.

Siga o exemplo do Rodrigo:

Aproveite e pergunte ao seu político preferido se ele tem respostas para as questões levantadas aqui.

Mensagem na Agile-Brasil:

Saudações,

Estamos implementando a Retrospectiva de release em nossa equipe de desenvolvimento. Já fizemos 4 retrospectiva, mas acho que está faltando algo a ser feito. Primeira vou demonstrar como estamos fazendo.

Basicamente é o seguinte, um pouco antes de concluir uma release (aqui chamamos de versão) enviamos um e-mail para todos os colabores com as seguintes questões:
* O que foi bom durante a versão e devemos continuar a fazer?
* Quais as lições aprendidas na ultima versão?
* O que podemos fazer para melhorar?
* O que mantivemos de mais importante? (coisas que começamos a fazer recentemente e que foi importante)
* O que podemos mudar para a próxima versão?
* O que podemos adicionar ou tirar de todos o processo de desenvolvimento?
* Ocorrências na versão 2.19b que não se enquadram nos tópicos acima.

Ao retornarem, separamos o que realmente é útil e colocamos em um documento para ser discutido na reunião. O que não é considerado útil é conversado com o colaborar para explicar o porque não será considerado no documento o que ele passou, as vezes, a pessoa que redigiu o texto acaba explicando o que quis dizer e passa a ser útil.
As questões acima são respondidas por todos, inclusive pelo gerente da equipe. Tudo vai para o documento, algumas coisas são elevadas a um tópico maior que é de discussão. Normalmente são coisas que devemos discutir durante a retrospectiva para saber a opinião de todos.
Durante a reunião é lido o documento e firmado alguns pontos.

Normalmente o documento chega a 4 páginas e a retrospectiva dura em média 1h30min. Não é um processo tão ágil, desde o envio do e-mail até a retrospectiva, normalmente passam 2 dias.

Gostaria de saber a opinião dos nobres membros dessa lista sobre como estamos fazendo a retrospectiva.
Sugestões, alterações no nosso sistema são bem vindas.
Se puderem, descrevam como fazem a retrospectiva em suas empresas, isso pode agregar muito.

Atenciosamente

Evandro

Métodos ágeis são baseados em ciclos curtos com feedback constante e a retrospectiva é uma das partes mais importantes. Eu perguntaria o porque do documento mas seja qual for a resposta sugiro que este formato seja alterado imediatamente.

Um dos grandes benefícios em usarmos cartões (ou post-its se você preferir) é ter a informação escrita em algo que pode ser facilmente alterado, manuseado e, principalmente, rasgado. Um cartão de história não é uma descrição funcional, é um convite ao dialogo entre os membros do time.

Quantas vezes você revisa um documento antes de enviar para seu chefe? Quantas vezes você não tira aquelas alfinetadas que estão entaladas na sua garganta mas você não teria coragem de escrever num documento? Quantos workflows seus documentos passam?

Isso não pode acontecer numa retrospectiva. As pessoas devem se sentir à vontade para levantar pontos e criar um processo de envio de emails e confecção de documentos a ser discutido –além de extremamente ineficiente por si só- inibe o fluxo do feedback.

Existem diversas maneiras de fazer retrospectivas mas a minha preferida é a mais simples de todas que conheço.

1. Arrume um quadro branco e um numero razoável de canetas. Se não tiver quadro-branco arrume 3 cartolinas e post-its grandes.
2. Divida o quadro em 3 partes: Deu Certo, Precisa Melhorar e Dúvidas. Nota: a menos que você viva num ambiente muito sem-graça não use estes nomes. Seja criativo, use ícones, sei lá.
3. As pessoas escrevem seus pontos nas respectivas seções(pequenas, uma frase. Lembre-se: convite ao dialogo!)
4. Depois de todos os pontos escritos cada pessoa explica brevemente porque escreveu aquilo ali. É na verdade uma tentativa de venda do ponto para ser votado
5. Depois de descritos os pontos as pessoas pegam as canetas e votam nos pontos que consideram relevantes.
6. Discutem-se os pontos mais votados, até o tempo acabar.

Uma das coisas mais importantes é que para cada item discutido devem haver pontos de ação. Quem conduzir a retrospectiva (e a sugestão é que o condutor varie a cada semana) deve estimular as pessoas participando da discussão a enumerar medidas praticas que podem ser tomadas e associar um responsável por estas. Na próxima retrô antes do ponto 1 acima o condutor pergunta aos responsáveis se as medidas foram tomadas.

Este formato não requer preparação e é bem eficiente. Eu já participei de retrospectivas assim em times com mais de vintes pessoas e em menos de uma hora os pontos relevantes eram endereçados. Uma outra coisa importante é que retrospectiva é um processo. Realizar uma única retro não vai dar o feedback necessário, você precisa manter as retrospectivas acontecendo com freqüência para que o funcione.

O Guilherme Chapiewski causou uma bela confusão com seu último post. Uma chuva de comentários debate: O Scrum Master deve ser técnico?

Eu já conversei com o Guilherme sobre isso algumas vezes e sei o que ele quis dizer, mas acho que colocou de uma forma meio confusa. Para mim o ponto é: o Scrum Master deve ser um gerente de projetos/facilitador/babá em tempo integral?

Após alguns anos nessa estrada dá para entender porque algumas pessoas se preocupam tanto em afastar o papel de gestor (seja Scrum Master of Universe ou qualquer outro termo que você preferir) do papel de técnico. Muitas vezes técnicos quando postos no papel de gestor não conseguem tirar a mão da graxa e isso atrapalha o andamento das coisas. Eu já tive gerentes de projeto que afundaram todo um release porque pegavam para si tarefas técnicas e não conseguiam exercer suas tarefas oficiais.

Isso acontece bastante mas não quer dizer que vá acontecer sempre, ou que não possa ser resolvido. Dizer que o gestor não pode exercer tarefas técnicas e ponto final é ignorar a característica empírica de um processo ágil.

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papeis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

Seguir à risca todos os documentos possíveis ou acreditar piamente que um selo traz qualidade é buscar respostas fáceis.

Desde outubro que eu não trabalho com Scrum. A ThoughtWorks não possui exatamente uma metodologia de trabalho, nós entendemos que agilidade é um processo empírico:

The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.

Cada projeto é um projeto, cada time é um time e aplicar uma receita de bolo, seja ágil ou não, é ruim. No meu projeto atual temos um time de desenvolvedores do mesmo nível. O papel de gestor de projetos fica com o tech lead e isso basicamente quer dizer que ele é quem perde 1/2 do dia em reuniões e é quem pede cerveja para a retrospectiva de sexta-feira. No resto do tempo está na máquina dele com o Eclipse aberto.

A diferença é que ele atua como tech lead, não como desenvolvedor. Ele não pode se comprometer com uma tarefa grande, ou em programar em par. O que ele faz é (1) ter certeza que possui entendimento sobre o que está sendo feito e dar sua posição sobre isso e (2) servir como palavra final quando algum assunto técnico atinge um impasse.

Eu pedi demissão da Globo.com um pouco antes do projeto acabar. Alem de atuar como Scrum Master e líder técnico da equipe eu ainda tinha que resolver algumas milhares de coisas relacionadas à minha viagem. Mesmo assim eu não abdiquei da minha responsabilidade de líder técnico. Eu desenhei com o Guilherme os WebServices que utilizávamos e não só sabia como eles funcionavam bem como enchi o saco dele para que tal coisa fosse desse jeito e não do outro. Eu trabalhei na primeira versão do framework JavaScript que criamos com o Tiago e depois fizemos algumas sessões de pair programming nas últimas alfinetadas.

Nas primeiras iterações eu ainda consegui pegar tarefas para mim, com o tempo isso foi ficando impossível mas eu não deixei de ser o líder técnico do projeto por isso. Assumir o papel de gestor do projeto me deixou com tempo fragmentado mas quanto mais ágil seu processo (e sua empresa) menos você precisa assumir o papel de gestor. Quando a empresa não requer muita burocracia desnecessária não há muito à facilitar, quando o time se gerencia não há muito há resolver.

Como o Antônio comentou no blog é muito bom chegar ao nível de ter essas discussões, pensar sobre o que é feito, mas é melhor ainda quando percebemos que processos ágeis são sobre pessoas e adaptação. Eu diria que um time não precisa muito mais de um Scrum Master Power Turbo do que de um tech lead, ambos são papeis importantes. Se você coloca seu tech lead como gestor de projeto e o impede de exercer suas funções técnicas você tem que ter uma estratégia para substituir essa perda.

Você pode ter certeza que as práticas que você mais odeia em uma metodologia de desenvolvimento não-ágil não foram criadas por pura maldade dos autores (bem, não sempre…). Estas práticas fizeram (e fazem) sentido nos cenários experimentados. Elas foram úteis e resolveram problemas. A grande questão é que não é porque uma coisa faz sentido em um cenário que ela deve ser aplicado à todos, ou sequer à maioria.

Cuidado para não ficar preso às respostas fáceis. Cuidado para não transformar processos empíricos em processos prescritivos. Cuidado para não tentar programar FORTRAN em qualquer linguagem.

Metodologias ágeis pensam sempre em times de especialistas generalistas. Isso é algo fantástico.

É óbvio que ter um especialista em banco de dados Oracle no time aumenta bastante a capacidade técnica, é óbvio que ter o James Gosling como programador Java aumenta a produtividade nesta linguagem mas é mais que óbvio que a grande, grande maioria dos projetos de software hoje em dia não precisam de especialistas extremos, precisam de gente boa o suficiente na tecnologia.

Isso nos coloca confortáveis para ao invés de um DBA dedicado termos apenas bons desenvolvedores, que ainda que não saibam diferenciar todos os tipos de tablespace possíveis conseguem fazer o sistema funcionar de forma razoável –e razoável significa dentro dos requisitos funcionais e não-funcionais.

Não consigo lembrar de nenhum projeto que eu tenha participado nos últimos três anos que não envolvesse mais de uma linguagem de programação, geralmente Java com Ruby, C++, JavaScript, C#, Bash e/ou PERL (alem das DSLs: HQL, SQL, etc.). Nos bons times não havia “desenvolvedor C#”, havia desenvolvedor, e isso significava que o cara usava as ferramentas que melhor servissem para o trabalho.

Mas o que isso quer dizer do ponto de vista do desenvolvedor? Quer dizer que ele vai ser exposto à tecnologias diferentes, o que é ótimo, mas também quer dizer que ele terá que abandonar algumas das suas preferências pessoais em favor do time, o que pode não ser tão bom.

Em um time ágil, todos os membros devem estar comprometidos com o projeto. Não tem essa de “a minha parte está feita, falta Fulano terminar a dele”, todos são responsáveis e todos vão ajudar. Se você foi contratado como programador SQL e precisamos de uma mão para terminar de escrever testes em Selenium é sua obrigação para com o time se voluntariar.

Mas isso, como tudo na vida, tem dois lados. Existem pessoas que não ligam para a tecnologia utilizada, elas gostam do projeto em si, mas no mundo do desenvolvimento existem muitas pessoas –e geralmente pessoas muito boas- que possuem suas preferências. O cara não gosta de programar em Ruby, ele prefere Java. Se o time precisar ele escreve Ruby mas por ele fazia tudo em Java -ele não acredita que Ruby tenha a mesma qualidade, ou algo do tipo.

Lembre-se que o manifesto ágil coloca pessoas acima do processo, se o processo diz que o desenvolvedor deve ser bombril multi-uso mas a pessoa não se sente a vontade nessa área você como gestor tem obrigação de fazer algo a respeito.

O que fazer? Deixar este desenvolvedor apenas nos projetos Java? Se isso for uma opção tudo bem, mas e em times pequenos? Eu vejo essa situação como um contrato entre as partes:

• O desenvolvedor deve saber que sua preferência de linguagem/tecnologia/plataforma/framework/biblioteca não necessariamente é a melhor para o caso e/ou não é viável na atual situação.
• O desenvolvedor deve se comprometer a utilizar a tecnologia em questão quando o time necessitar que ele o faça –e ele tem o direito de dizer até 3 palavrões por linha de código escrita
• O gestor tem que garantir que o desenvolvedor tenha direito à expressar sua opinião quanto às escolhas do grupo
• O gestor tem que saber que essa pessoa não está confortável nessa posição e fazer o possível para que isso seja amenizado

Da mesma maneira que o gestor do projeto ou do time sabe que não pode arriscar seu sucesso por uma birra do desenvolvedor com a linguagem, ele sabe que é muito difícil encontrar bons desenvolvedores e manter um ambiente de trabalho agradável. Na minha experiência o que eu mais vi foram casos onde o desenvolvedor cumpre a parte dele no contrato acima mas o gestor não. O gestor trata todos os desenvolvedores como iguais, ignorando completamente o caráter pessoal e social de um projeto de desenvolvimento.

O que “amenizar” significa depende do seu contexto. Você pode tentar mudar a pessoa de equipe, pode fazer com que ele tenha a opção de pegar outras tarefas que não seriam imediatamente executadas, oferecer treinamento… O que você não pode fazer é que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor completamente desestimulado e frustrado na sua equipe, que enquanto você não olha está em um site de empregos.

Não deixe que para aquele desenvolvedor agile signifique trabalhar com algo que você não gosta.

Quando você introduz mudanças -seja uma metodologia nova, uma tecnologia nova, um novo modo de pensar, o que quer que seja- você sempre enfrentará problemas. Algumas pessoas vão ficar no seu caminho porque elas não querem mudar, qualquer livro de auto-ajuda destes vendidos em botequim te diz que pessoas tem medo de mudanças. Algumas –bem menos do que o senso comum diz- simplesmente não querem ter trabalho de mudar. Algumas não ligam o suficiente para desejar que aquilo melhor. A maioria, na minha experiência, simplesmente não acredita que aquilo vá dar certo.

Aí você adota uma estratégia clandestina e sem que ninguém perceba as coisas mudam para melhor. No blog da Object Mentor, Tim Ottinger escreveu um post bem interessante sobre o que acontece nesse estágio.

The CIO looked into the eyes of his agile development staff last Friday. “Your attitude is affecting other departments” he said.

Eu já passei por uma situação parecida com essas diversas vezes. Muitas vezes é nessa hora que cortam suas asas, muitas vezes é nessa hora que você percebe que a empresa não quer melhorar, que ela não se importa em gastar rios de dinheiro à toa. Algumas vezes pode significar sua demissão ou término de contrato. Destas você aprende muito, sai frustrado mas pronto para tentar de novo.

Fatalmente você aprende um ou outro truque sobre como fazer as pessoas entenderem que do modo antigo não dá certo. E fatalmente você acaba ouvindo algo que te dá muito mais responsabilidade:

“Your attitude has been affecting other departments”, he said. “And I want to thank you for it.”

Recebi este e-mail esses dias (nome oculto por falta de permissão do autor):

[…]

Eu trabalho com Java a pouco tempo (desde maio de 2006), mas sempre procurei aprender bastante. Na época eu não conhecia nada, […] não sabia Java a fundo[…] comecei num projeto que já tinha essa arquitetura de usar TO, BO, etc. e tal, e a partir dele comecei a aprender e abstrair, com isso acabei criando umas coisas que depois viraram o “framework das arquiteturas” da empresa, framework que segue aquela porcaria de lógica de negócio separado de dados. Não trabalho mais nessa empresa, e meu antigo analista me fala com orgulho que aquele framework que fiz já é base para 5 projetos, me deixa feliz e ao mesmo tempo preocupado. Hoje estou em outra, e faltamente com a responsabilidade de novo de definir a arquitetura dos projetos (não acho que tenha experiência suficiente
para isso, mas eu tento estudar ao Maximo e fazer o melhor), e dessa vez, o negócio é grande, pois a empresa é infinitamente maior.

Lendo as várias discussões que vocês têm no GUJ, bem como seu blog, eu tenho certeza que aquele framework era errado. Quando criei, ainda era dependente de tecnologias, muita coisa mudou, e no fim não era mais dependente de nenhum framework especifico, ele continha uns utilitários, as interfaces e algumas abstrações para serem implementadas e especializadas em cada projeto, mesmo assim não
consegui juntar os dados com a lógica.

Bem, juntar eu até consigo, mas ai não consigo mais imaginar um framework, perfeito, vocês falam que esse framework é, teoricamente, uma coisa ruim. Porem morrendo esse cara, todos meus programadores terão de programar o modelo sempre do zero, bem como saber programar
da forma certa (o que acredite em mim, acho que 80% das pessoas não fazem noção nem do que é a forma certa, quem dirá fazer, eu posso ser uma delas, mas pelo menos tenho noção de que da forma que esta feito, é errado), ai que volto a pensar em ter um framework para eles
estenderem e não precisarem se preocupar com tanta coisa.

Ai surgem minhas duvidas, para mim, seguir os conceitos de DSL, DDD, Fluent Interfaces etc. é algo que exige do programador um bom conhecimento, e eu não tenho muita experiência com bons programadores, a maioria se quer sabe a importância de uma interface, programa em
Java como se estivesse programando em C, como cobrar desses caras uns conceitos que nem eu entendo a fundo, ai volto a pensar naquele framework, que ao menos obriga eles seguirem algo dividido em camadas, fazendo eles separar a lógica de negocio do acesso aos dados, a lógica de negocio de cliente da lógica de negocio de fornecedor, enfim, consigo que pelo menos saia algo não tão feio, e que em eventuais manutenções consigo fazer de forma rápida.

Mas para mim isso é péssimo, porque não consigo evoluir, não consigo aplicar nos projetos as coisas que gostaria de aprender. Mas acho que a culpa é minha, porque em todo lugar tem programadores que devem não conhecer, e isso não pode ser um impeditivo.

Por isso, gostaria muito que você me indicasse livros, mas que seguisse uma ordem certa de aprendizado, o que eu preciso saber primeiro, depois e depois, eu não sei se eu devo começar lendo sobre a modelagem em si, ou conceitos DDD, DSL, sei la, queria apenas que você me guia-se recomendando links e principalmente livros.

Por exemplo, nesse tópico você deu exemplo de vários livros http://guj.com.br/posts/list/60/71466.java (na pagina 5 do tópico), qual seria o mais recomendado para iniciar, e depois, depois etc. […]

Antes de mais nada eu diria que você está na trilha certa. A primeira coisa que um bom arquiteto deve fazer é se questionar o tempo todo, e justificar suas escolhas para si mesmo antes mesmo de alguém falar qualquer coisa.

Uma coisa que você precisa ter em mente é que o framework perfeito não existe. Quando discutimos design muitas vezes focamos no ideal, mas nem sempre o ideal deve ser implementado. Dificuldades tecnológicas são um grande fator, mas como você mesmo notou um fator muito importante é que arquitetura é sobre pessoas. Não adianta você ter a arquitetura tecnologicamente, perfeita, o design que melhor modela seu domínio e a maior performance possível se seus desenvolvedores não entendem ou não entenderão este zoológico.

Eu fui freelancer por um bom tempo, e nesse período não só eu era completamente verde sobre tecnologias bem como na época o acesso à informação era restrito (Internet só depois da meia-noite, lembra do pulso único?). Ainda assim eu tive que definir arquiteturas para alguns sistemas que duram até hoje, e aprendi bastante com isso.

Uma das coisas que aprendi é um clichê: Keep it Simple. Uma boa arquitetura, sofisticada ou não, é composta de primitivas arquiteturais bem definidas. Para entender essa afirmação pense na linguagem Java. A linguagem possui primitivas que giram em torno de objetos, definidos por classes que trocam mensagens através de métodos. Você não precisa de exceções à estas primitivas, consegue implementar tudo no seu sistema com elas. Assim deve ser sua arquitetura.

Se você ainda não tem conhecimento para utilizar conceitos mais rebuscados se mantenha simples e elegante -e elegante para mim significa ter boas primitivas e pouquíssimas exceções. Claro que sua arquitetura não vai servir para todas as coisas mas lembre-se que arquiteturas devem ser pensadas de acordo com o projeto, não existe arquitetura de referência.

Mas se eu não tenho uma arquitetura de referencia como confio nos meus desenvolvedores? Primeiro você deve contratar desenvolvedores bons, ou experientes ou com um bom potencial. Como falei diversas vezes neste blog entre 2005 e 2007 uns bons 40% do meu tempo foi dedicado contratando gente. O que eu aprendi nessa fase é que os bons desenvolvedores dificilmente vão caber no seu orçamento. Eles já são superstars em outras empresas. O que você precisa fazer é criar um time de pessoas eficientes, compromissadas e competentes. Este tipo de pessoa pode não ter a bagagem técnica necessária mas possui um potencial tão grande que você cria seus próprios superstars.

Mas se você não está contratando ninguém, como fica? Então você precisa é de gerencia de conhecimento. Muitas vezes eu já entrei num projeto onde as pessoas repetiam um mantra qualquer como “Não podemos fazer isso porque vai dar conflito com a rebimboca” o tempo todo e quando você pergunta ninguém consegue te explicar direito o que é a tal rebimboca ou porque ela cisma de conflitar com seu software.

Pense no seguinte: se as pessoas fossem ler por si só livros e bibliografias complicadas elas já teriam feito isso por elas mesmas. Se elas não procuraram para ter sucesso profissional elas não vão procurar apenas para entender seu software.

Criou uma arquitetura nova? Crie uma página no wiki da empresa (ou na Intranet, ou sei lá) contendo a descrição do que vocês fizeram. Não pense numa especificação de arquitetura, pense que você está escrevendo um artigo para um grande site sobre a arquitetura. O objetivo é criar algo útil e informativo. Organize sessões onde as pessoas troquem conhecimentos, talvez através de palestras ou de lighting talks ao menos duas vezes por mês.

E quanto aos livros? Recomendar livros depende muito do que você quer aprender. Eu não vou recomendar os livros neste post, vou tentar fazer algo mais abrangente e criar uma serie de posts chamados Proposta de Trilha. Eles vão conter uma bibliografia que eu ache interessante e na ordem que eu gostaria ter seguido. Imagino posts específicos para: Desenvolvedor, Arquiteto, Testador e Gerente de Projeto. Talvez mais, talvez menos.

Ontem tivemos mais um Community College na ThoughtWorks Melbourne, desta vez focamos no Qi4j.

É uma idéia interessante. Basicamente o qi4j (”quiforjêi”) usa micro-aspectos para modelar qualquer coisa. O problema é que a sintaxe atrapalha. Eles usam a Linguagem Java, com Language Adaptations e uma Factory mágica, provavelmente uma linguagem própria teria mais efeito.

Eu tenho reclamado constantemente do WordPress no meu blog. Além do motivo óbvio –ter conteúdo e meu servidor comprometidos- existe uma hidden agenda neste interesse por uma engine de blogs… decente.

Para quem ainda não sabe eu deixei a ThoughtWorks há uma semana. Se você notar todos os meus posts falam de projetos passados, nada muito recente. Mas por quê?

Foi notada que existe uma carência no Mercado brasileiro de blog genéricos de tecnologia. Sabe aqueles blogs que trazem notícias do mundo da tecnologia traduzidas diretamente dos sites internacionais e com fotos hot-linkadas? Pois é, não temos muito no Brasil e temos que nos acostumar com conteúdo original, que notoriamente não tem a mesma qualidade do conteúdo traduzido. Para melhorar também precisamos de um grande fórum onde pessoas comuns podem discutir tecnologia. Onde a minha tia possa falar do que ela gosta do Windows Vista e odeia Linux, onde meu primo possa falar que acha Java lento. Claro que tudo movido à ads do Google.

Vendo essa necessidade, a hef-bite technologies de Townsville, QLD me contatou e me fez uma proposta indecente. 10% de todos os cliques do novo site serão meus, e como falamos de uma população de 200 milhões de habitantes isso dá uns bons milhares de dólares por semana, e eu nem preciso voltar para o Brasil.

O site ainda está em construção. Estamos usando um framework web brasileiro para ficar mais “produto nacional” e conversando com alguns sites famosos para comprarmos seus domínios. Provavelmente vamos fechar negócio com um desses sites e você não vai nem perceber.

E porque eu estou falando isso agora? Bem, porque nesta data eu paro de escrever neste blog. Para evitar que o site seja hackeado e manter o conteúdo on-line eu vou bloquear o acesso de escrita no banco de dados, mas não espere novo conteúdo aqui. Eu ainda estou interessado nos mesmos temas e você pode esbarrar comigo em algum fórum da vida, mas meu contrato não me deixa ter mais de um blog. Caso não dê certo eu volto a blogar, mas eu espero que meu próximo post seja para informar que me aposentei com menos de 30 anos e estou indo morar em Bali ;)