As propostas estão disponíveis no site e o público pode fazer comentários. Minhas submissões:

Líder Técnico - O Ex-Arquiteto virou Faz-Tudo!

Ele era o centro das atenções. Nenhuma classe era criada sem a sua aprovação. Nenhuma biblioteca era introduzida sem que ele homologasse. Nada entrava ou saía sem a sua verificação. Seus diagramas formavam o livro sagrado do sistema, se o sistema não reflete o diagrama então os desenvolvedores devem ser punidos, obviamente eles não entender seu Grande Plano para Tudo™.

E daí veio este tal de agile. Não apenas introduziu práticas de qualidade duvidosa (duas pessoas, um computador? Sério?) mas também quer eliminar seu papel de visionário. Como um time poderia funcionar sem a visão inpiradora? Como um mero desenvolvedor pode decidir o que é melhor para um projeto onde são investidos milhões?

Pior ainda, o que o líder faz agora que não existem mais diagramas para desenhar?

Arrumando a Casa Após a Festa: Saindo do Pseudo-Agile

Tudo parecia muito simples. Os cartões vão na parede, os times se auto-gerenciam, o tal do Product Owner escreve nos cartões, o time faz retrospectiva… Tantos casos de sucesso por aí, tantos sorrisos e tapinhas nas costas…

Por que está dando tão errado aqui? Por que está fazendo da minha vida um inferno? Por que meu time não está aumentou a produtividade? Por que meus produtos continuam sendo uma porcaria? Por que parece que ninguém sabe o que está acontecendo?

Este é o saco de dúvidas que tenho encontrado por aí.

A maioria vai achar que basta seguirmos os 12 passos do programa e, eventualmente, as coisas vão entrar nos eixos. A maioria acha que basta demitir os gerentes de projeto e colocar coisas coloridas na parede. A maioria acha que basta escrever testes e seu código vai ter qualidade. A maioria acha que basta quebrar casos de uso em histórias e você terá melhor comunicação.

A maioria vai falhar miseravelmente.

Nos últimos anos tenho gasto uma boa parte do meu tempo tentando fazer clientes entender que não importa a cor do cartão na parede, não importa a sua plataforma de desenvolvimento, não importa se você usa cruise ou hudson, não importa se retrospectivas são quinzenais ou mensais… a única coisa que importa nesses tais métodos ágeis é termos ciclos de feedback curto.

Nesta sessão vamos conversar sobre alguns cenários, todos baseados em projetos reais, e no que pode ser feito para tirar o pseudo do seu agile.

E, além das duas palestras, o Rodrigo Yoshima me convidou para ajudá-lo no seu workshop de modelagem:

Reconheça! Você não sabe modelar! Iniciando Projetos Ágeis

Neste workshop prático vamos simular o planejamento inicial de um projeto ágil utilizando as mais variadas técnicas de modelagem como Domain-Driven Design, CRC Cards, User Stories, Paper Prototyping e Brainstorming.

Ajude o cliente a compreender melhor o problema, melhorando seu planejamento e auxiliando as suas estimativas. Um bom modelo ou protótipo serve como uma simplificação de algo complexo, uma abstração útil para o desenvolvimento do projeto. Em projetos ágeis a modelagem está presente, porém, ao invés de uma modelagem solitária numa ferramenta UML, equipes ágeis inovam em colaboração, usando artefatos simples numa dinâmica divertida.

Host: ThoughtWorks Brazil
Date: Saturday, 30 January 2010
Time: 09:00 - 13:00
Location: Mercure Botafogo, Sala Petrópolis, Rua Sorocaba, 305- Botafogo
Description
ThoughtWorks is hiring in Porto Alegre. We recognise that not everyone’s lucky enough to live there yet, so we’re giving people in Rio the opportunity to find out more about us and to take our assessments :-)

Please note that we do not currently have plans to open an office in Rio. Please only come to this event if you are serious about relocating to Porto Alegre in the next couple of months. I will beat you with twigs if you come along and don’t want to relocate.

ThoughtWorks’ hiring process includes some assessment tests. Many ThoughtWorkers consider them fun, although they are challenging. We’re running some sessions for you to take them and to give you a chance to find out more about ThoughtWorks.

We are currently hiring Java developers and testers with automation experience. To be considered for a developer role, you’ll need to convince us that you’re already a pretty good Java/Ruby/C# developer who’s passionate about software development, team work and Agile development. Testers can come from a variety of backgrounds, but you’re going to be open-minded about a whole new way of testing.

While we usually start our hiring process with a telephone interview, we’re mixing it up a bit and giving people the opportunity to take our assessments first. The next stage, for developers, is to write some code and testers will do a telephone interview.

If you haven’t already, please send your CV to work@thoughtworks.com and questions to suzi@thoughtworks.com, or post on here. You only need to attend one event, and numbers are limited to 25 people per session. It would be great if we know in advance that you are coming. So, if you plan to attend, either accept on here or email me.

Mais detalhes na página do Facebook do evento. Você deve ir na página e dizer que vai para prepararmos o evento, qualquer dúvida me mande um email.

Infelizmente eu não vou ter muito mais que algumas horas para ficar no Rio, mas vai ser uma ótima oportunidade para conhecer e bater um papo com as pessoas que têm interesse em trabalhar para a ThoughtWorks. Não perca esta oportunidade!

Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.

O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.

Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.

Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.

Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.

E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:

• http://blog.fragmental.com.br/2007/03/01/voce-pergunta-001-daos-e-repositorios/
• http://blog.fragmental.com.br/2007/06/05/dao-e-repository/
• http://blog.fragmental.com.br/2008/05/22/domain-driven-design-e-simples/
• http://fragmental.tw/2008/04/25/repeat-after-me-repositories-arent-daos/
• http://fragmental.tw/2007/11/29/repositories-misunderstandings/
• http://fragmental.tw/2007/09/05/rounded-tip-scissors/

Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.

Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.

Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:

E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.

Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.

É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.

Quando começamos a pensar em montar um escritório da ThoughtWorks no Brasil nós sabíamos que este tipo de coisa ia acontecer. Não só é muito difícil achar bons candidatos para entrar no nosso time local – e se você tem que recrutar pessoas sabe que isto é um problema bem comum – mas também, mesmo se preenchermos todas as nossas vagas em um só dia estes novos ThoughtWorkers ainda precisam de algum tempo de casa para trabalhar em posições mais delicadas, como fazendo coaching, que é o caso.

Mas… e você com isso? Pois é aí que você entra!

Ainda estamos recrutando. A Suzi Edwards – que foi quem fez meu processo de seleção e contratação quando morava na Austrália – vem organizando diversos eventos de recrutamento por todo o pais. Por que tantos eventos? Porque não é fácil achar bons candidatos, vocês se escondem muito bem. Além disso, a última coisa que nós queremos é perder a chance de contratar um bom candidato só porque ela ou ele não pode ir à Porto Alegre fazer suas entrevistas.

O próximo grande evento será em São Paulo dia 23 de Janeiro. Você precisa se informar que vai (RSVP) na página do evento no Facebook para participar – a Suzi precisa ter uma idéia de quanta gente esperar.

A parte mais importante, entretanto, é que o recrutamento é focado em pessoas de São Paulo (assim como outros lugares do pais terão sua vez) mas a vaga é para Porto Alegre. Colando do Facebook:

ThoughtWorks is hiring in Porto Alegre. We recognise that not everyone’s lucky enough to live there yet, so we’re giving people in Sao Paulo the opportunity to find out more about us and to take our assessments :-)

Please note that we do not currently have plans to open an office in Sao Paulo. Please only come to this event if you are serious about relocating to Porto Alegre in the next couple of months. I will beat you with twigs if you come along and don’t want to relocate.

ThoughtWorks’ hiring process includes some assessment tests. Many ThoughtWorkers consider them fun, although they are challenging. We’re running some sessions for you to take them and to give you a chance to find out more about ThoughtWorks.

We are currently hiring Java developers and testers with automation experience. To be considered for a developer role, you’ll need to convince us that you’re already a pretty good Java/Ruby/C# developer who’s passionate about software development, team work and Agile development. Testers can come from a variety of backgrounds, but you’re going to be open-minded about a whole new way of testing.

While we usually start our hiring process with a telephone interview, we’re mixing it up a bit and giving people the opportunity to take our assessments first. The next stage, for developers, is to write some code and testers will do a telephone interview.

If you haven’t already, please send your CV to workthoughtworks.com and questions to suzithoughtworks.com, or post on here. You only need to attend one event,and numbers are limited to 25 people per session. Iit would be great if we know in advance that you are coming. So, if you plan to attend, either accept on here or email me.

To pre-empt some questions:
I am not available at those times. Can I still meet you?
We’re running three sessions and these will keep us busy, so we’re unable to accommodate requests for meetings outside of these times.
I’m away this weekend. When will you be back?
Not sure, but don’t stress. We’ll be back soon.
If I do not live in Sao Paulo, should I fly to this event?
Nope. We’re getting organised on coming to other cities. We don’t suggest people spend money on flying to cities for assessments.
When are you coming to Rio?
Very soon :-)
I am looking to be a Project Manager. Can I come along?
Not recommended. We are not hiring Project Managers at the moment.
Can I tell my friends and pass this along?
Of course!

Our assessments take about three hours and we will be running three sessions this weekend.

Mudar de cidade pode ser algo muito brusco, mesmo que seja para uma cidade próxima. O que é preciso entender, no entanto, é que o único modo de não cair no mesmo lugar é mudar o caminho tomado. E muitas vezes na vida precisamos fazer esta mudança bruscamente.

Te vejo no Away Day.

Um showcase acontece geralmente no último dia de uma iteração. Ele serve para que o time apresente aos interessados –usuários, patrocinadores, pessoas não diretamente envolvidas no projeto, etc.- o que foi feito nesta iteração.

Eu costuma lidar como showcases como o momento onde o time e o usuário interagiam, onde o usuário via o produto final como um todo, dava feedback para o time e aprovava ou rejeitava histórias.

Péssima idéia. Todos os pontos acima são extremamente importantes mas eles não devem acontecer durante o showcase e sim durante toda a iteração.

O maior problema ao utilizar o showcase como único/principal ponto de interação é que você acaba tendo um big-bang feedback. Ao invés de colher feedback iterativamente no decorrer do período, de uma maneira que o time possa agir para consertar possíveis problemas, você recebe feedback em lote sobre tudo que foi feito naquela iteração de uma só vez. Não só isso pode significar excesso de informação bem como certamente vai frustrar o time e, principalmente, o usuário já que quando o feedback chega já é o fim da iteração e tarde demais para agir. Fica para a próxima.

E um problema parecido é o planejamento em big-bang, coisa que muita gente faz no seu Iteration Planning Meeting (IPM, ou Sprint Planning I & II se você realmente vai continuar insistindo). Em muitas equipes que conheço este é basicamente o único momento onde se planeja e prioriza uma iteração.

Combinando os dois problemas você tem um cenário extremamente frustrante: o usuário faz um grande planejamento, sai por duas semanas e volta para ver se seu plano foi cumprido. Se o time não conseguiu fazer tudo que ali estava definido o usuário fica frustrado e começa a desconfiar de tudo e de todos. Este tipo de situação é péssimo para qualquer tipo de empresa mas para nós, consultores, ele é simplesmente inaceitável.

O que eu aprendi com os mais experientes gerentes de projetos que já trabalhei é que em um showcase não podem haver surpresas. O cliente deve dar feedback sobre cada história e acontecimento individualmente, e durante a iteração. Na minha palestra no Rio mês passado eu falei brevemente sobre o “modelo do sanduíche”, melhor explicado aqui. Esta é a melhor maneira que eu conheço para ter certeza de que não haverão surpresas durante o desenvolvimento: para cada história -individualmente!- o usuário planeja junto com o time o que vai ser feito e depois verifica e aprova ou rejeita o resultado.

É claro que isto funciona melhor quando o cliente está presente o tempo todo, mas isto não é estritamente necessário. Se você possui um cliente fisicamente distante pode procurar outras maneiras de receber feedback frequente, coisas simples como fazer deploy constante para um servidor e mandar um email para o usuário pedindo para ele testar uma nova história neste ambiente. Só tenha certeza que seu usuário viu, aprovou e está ciente dos possíveis problemas e eventuais workarounds antes do showcase. É melhor isso do que criar um banho de sangue quinzenal.

Um showcase deve ter foco em mostrar para todas as partes interessadas o progresso feito, nunca em aprovar ou rejeitar histórias. Re-lembre a todos de onde viemos, onde estamos e para onde vamos. É claro que num projeto sadio sempre vai haver feedback vindo de múltiplas partes durante esta sessão, e isto é bom, mas um showcase não deve ter foco em receber feedback mas sim mostrar a evolução do projeto.

Existe todo um movimento de pessoas que prega que iterações são ruins. Um dos argumentos utilizados por esta escola de pensamento é exatamente de que o feedback em uma iteração tende a ficar apenas nos intervalos, não sendo frequente o suficiente. As pessoas vão para um modelo sem iterações e dizem que estão “livres da cerimônia” e que agora feedback e valor fluem o tempo todo. Bom, talvez o problema não seja com iterações em si mas sim na maneira como você as modela…

E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.

Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!

Só cuidado para não quebrar as barreiras que protegem o time.

Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.

E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.

Não vai.

Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.

Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.

Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.

Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.

E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.

E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.

A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.

Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.

Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”

Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.

Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.

E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.

É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.

Isso fez com que meus planos se alterassem um pouco. Infelizmente não vou ter tanto tempo quanto gostaria para encontrar pessoas, especialmente fora do Rio. Ainda vou em alguns lugares mas nada perto do que tinha em mente antes.

Sobre o evento, acho difícil haver alguém que ainda não tenha esbarrado com um dos banners ou coisa parecida sobre o Caelum Day. A programação está bem interessante e promete ser um dia útil e divertido.

Minha apresentação vai focar no que eu mais tenho feito nestes últimos dois anos: fazer com que times de desenvolvimento saiam do marasmo e comecem a entregar. Não me venha com essa história de “minha metodologia não deixa”, “meu chefe é mau”, etc., todo lugar tem problemas e as coisas dependem de você. A apresentação possui dicas e fundamentos técnicos mas sem vontade nada vai pra frente.

E para, refletir de maneira bem realista o clima da indústria de desenvolvimento de software, este ano eu escolhi mais uma vez filmes de terror para servir de pano de fundo (e comic relief). Ao contrário do ano passado, entretanto, eu escolhi um filme em específico. O primeiro comentário quem acertar o filme baseado na capa da apresentação abaixo ganha… algo… que eu ainda vou decidir:

As inscrições ainda estão abertas aqui.

Para o workshop de Domain-Driven Design não há mais vagas –mas existe uma lista de espera.

Algumas pessoas ficaram curiosas porque escrevi no meu blog em inglês que acho o assunto (DDD) tedioso. Existe uma enorme demanda de cursos sobre o tema e o Paulo Silveira e eu decimnos que valia a pena realizar mais uma rodada dos cursos. Eu continuo usando Domain-Driven Design em meus projetos e textos, mas o assunto já está meio batido e mastigado.

Na minha opinião, DDD deveria ser parte de um curso maior sobre design em geral, um workshop específico tem relevância quando o assunto é novidade mas perde o apelo quando a técnica começa a ser utilizada por mais gente. Tenho lido mais sobre outras coisas e, se tudo der certo, vamos ver se em 2010 eu consigo aposentar o workshop de DDD e partir para estas novas coisas.

Bom, por enquanto é isso. Nos vemos semana que vem.

O plano original é emendar tudo com o lançamento do livro -que eu, relapso que só, ainda não mencionei neste blog- mas este plano pode mudar. De qualquer maneira o esquema básico é o mesmo do ano passado: uma conferência e alguns workshops. Ainda não posso falar sobre nenhum deles porque nada foi decidido mas assim que eu tiver definições eu posto aqui.

Mas meu objetivo com este post é me colocar à disposição. A viagem deste ano é totalmente a trabalho -tirando alguns dias para a família e os amigos, claro- e eu pretendo visitar o maior número de grupos de usuários, empresas e comunidades de desenvolvimento de software que eu conseguir. Faz dois anos que estou na Austrália e apesar de meu contato diário com a comunidade brasileira uma coisa é falar de longe e outra é ver de perto.

Eu tenho algumas visitas já marcadas e, infelizmente, não muito tempo disponível então vou ter que priorizar as coisas. A minha idéia original é chegar no grupo de usuários/empresa/etc., fazer uma apresentação de uns 30 minutos e depois passar algum tempo pareando com as pessoas e atualizando minhas percepções sobre o mercado brasileiro em geral. Eu chego dia 31/10 e volto dia 15/11, estarei, a princípio, no Rio durante toda a viagem mas topo viagems próximas.

Topa? Me manda um email. Não sabe meu email? Se vira.

Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.

O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.

Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.

O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.

Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.

Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).

As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.

O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.

Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).

Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.

Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:

Esta é a fila dos que faltam:

(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)

Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:

early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures

Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.

Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.

É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.

Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.

Uma coisa a se notar sobre a ThoughtWorks é que somos uma empresa de consultoria mas com uma divisão de produtos. Como a eventual vinda da ThoughtWorks para o Brasil significa a vinda das duas partes é bom que também apresentemos ao mercado brasileiro os softwares que produzimos.

O software mais popular da suite é o Mingle, um sistema de gerenciamento de projetos com muitas características interessantes. Ele foi construído baseado na experiência da empresa prestando consultoria, entende bem que cada processo é diferente e que modelos engessados não funcionam bem. Também possui uma interface rica que aliada com alguns recursos de hardware se torna uma ferramenta extremamente útil quando um Kanban eletrônico é necessário. Por fim é provavelmente o mais famoso caso de uso do JRuby on Rails -o Mingle usa componentes escritos em Java aliados aos recursos do Rails.

Se você quer conhecer mais sobre o produto tem duas oportunidades. Abaixo os convites.

Rio de Janeiro

Hi,

ThoughtWorks is sponsoring Agile Brazil 2009, the first major conference on Agile methodologies to be held in Rio de Janeiro, Brazil. In this extensive, one-day event, various practitioners and speakers will conduct sessions on a range of well-known Agile methodologies and practices such as Lean, Scrum, XP, User Stories, Continuous Integration, Release management and Test Driven Development.

Date and Venue:
June 27, 2009, 8:30am - 6:00pm.
Salao A (Padre Anchieta hall)
PUC-Rio, Gavea, Rio de Janeiro, Brazil.
Registration Information
Registration: R$ 200,00.
Register for Agile Brazil 2009

Mingle User Group Meeting in Rio de Janeiro

We have organized a free follow-on event for agile enthusiasts. We invite you to the Rio Mingle User Group (MUG) Meeting, an exclusive meet for Mingle users in Brazil, to discuss and share their experience with Mingle. Adam Monago, our product expert along with other Agile experts will take you through Mingle and its features and provide you tips and tricks on how to better use Mingle for project management and collaboration. After the talk you can interact with the attendees over food and drinks.

Date: 1- July-2009
Time: 17:30 - 19:00
Venue: PUC-Rio, Rua Marques de Sao Vicente 225 - Predio Padre Leonel Franca - 13 andar - Gavea, Rio de Janeiro, Brazil

To confirm your participation for the Mingle User Group, simply reply to this email: Studios-Brazil@thoughtworks.com?

Regards,
ThoughtWorks Studios
Studios-Brazil@thoughtworks.com

São Paulo

A Aspercom e a ThoughtWorks convidam você para o Encontro Agile / Mingle User Group Meeting. Este será um evento gratuito em São Paulo com mini-palestras, discussões e muito bate-papo.

Data: 30 de junho de 2009 às 19:00hs / Local: Av. Paulista

Facilitadores:
Paulo Caroli, Adam Monago (ThoughtWorks)
Rodrigo Yoshima, José Paulo Papo

Mingle User Group Meeting

O encontro do Mingle User Group (MUG) do Brasil é uma oportunidade para conhecer, discutir e compartilhar experiências com o Mingle. Adam Monago, um especialista no produto juntamente com outros Agilistas experientes, demonstrarão o Mingle provendo dicas e truques em como usar o produto para gerenciamento de projetos e colaboração.

Local, agenda, inscrições e outras informações acesse: http://blog.aspercom.com.br/2009/06/22/evento-agile-mingle/

Rodrigo Yoshima
ASPERCOM

Paulo Caroli
ThoughtWorks