Archive for the ‘metodologias’ Category

Chefes e Muros

Sunday, September 5th, 2010

A edição de Novembro da Harvard Business Review traz um artigo muito interessante chamado “The Boss as Human Shield”, que se baseia no novo livro de Bob Sutton, “Good boss, bad boss”. Considerando que Sutton é o autor de No Asshole Rule eu estou bem ansioso para ler seu novo livro.

O artigo me fez lembrar sobre minhas experiências gerenciando times. Eu comecei em empresas pequenas. Nestes lugares minhas responsabilidades incluíam gerenciar pequenos times. Após um hiato trabalhando para empresas grandes eu acabei voltando a “ter meu time ” na Globo.com. Hoje em dia boa parte do que eu faço é gerenciar equipes, incluindo não apenas desenvolvedores mas todas as competências relacionadas ao desenvolvimento de software.

E uma das coisas que eu aprendi é exatamente o que este artigo diz. Para mim, a primeira obrigação de um líder de equipe —ou chefe, ou algo do tipo—é formar uma excelente equipe. A segunda obrigação é deixar este povo trabalhar em paz, sem interrupções desnecessárias.

Quando comecei na Globo.com desenvolvedores no meu time estavam acostumados a comparecer a diversas reuniões por semana. Eram reuniões internas da equipe, com outros departamentos… Naquela época nosso time ficava situado num prédio diferente do resto da empresa, o que fazia com que para cada reunião houvesse um gasto extra de uns 30/40 minutos em deslocamento.

Mudar cultura é algo sempre complicado e eu falhei diversas vezes em conseguir convencer as pessoas de que havia algo muito errado nisso. Existem momentos, entretanto, onde você pode pedir e deve carta branca. No caso do antigo time, esta ocasião foi o lançamento do GloboVideos 4.2, que é basicamente a versão que se encontra no ar ainda hoje, mais de três anos depois daquele projeto.

O time havia passado maus bocados no lançamento do GloboRádio, nosso projeto anterior. Por diversos motivos nós trabalhamos todos os fins-de-semana por um mês e meio. Para o novo projeto eu pedi à gerencia carta branca para tentar algumas coisas diferentes e deixei claro que não me comprometeria com o prazo se tivesse que trabalhar com as limitações do projeto anterior.

O pedido foi aceito e uma das mudanças que implantamos foi uma metodologia mais ágil (a primeira vez que a empresa viu um Story Wall na vida foi a cartolina improvisada que colamos no nosso rack de servidores de desenvolvimento). Uma outra foi ser mais seletivo com reuniões, especialmente reuniões que exigiam o time todo.

Nas primeiras duas semanas do projeto eu pareei com o Tiago Motta desenvolvendo o embrião do framework de widgets que desenvolvemos para o site (que eventualmente virou caso de estudo). Depois de definido um bom rascunho do framework e da nossa API de WebServices eu , praticamente, passei a atuar como porteiro para o time.

A cultura que implantamos nunca foi formalmente definida, mas alguns pontos estavam em nossas cabeças:

  • Nada é segredo, a menos que seja: Ninguém estava proibido de ir a reuniões. Todas as reuniões eram abertas ao time e eu fazia o máximo para explicar ao time o que tinha sido discutido e os impactos.
  • Liderar é basicamente coordenar: Apesar de ser o responsável técnico pelo que era produzido pelo time eu evitava ao máximo tomar qualquer decisão durante as reuniões. Geralmente eu sabia a pauta com antecedência e discutia com o time antes de falar com os outros grupos. Quando eu sabia que teríamos que decidir algo durante a reunião eu trazia o especialista naquela parte comigo.

O grande problema para mim em seguir esta estratégia foi como me manter por dentro da parte técnica. Por gastar tanto tempo em reuniões, quase sempre infrutíferas, eu tinha pouquíssimo tempo para chegar na minha mesa, atualizar meu computador com o código-fonte e dar uma olhada nos commits do dia. Eu tive que investir muito tempo extra para, geralmente em casa, entender onde estávamos e ajudar as pessoas com a visão de para onde queríamos ir. Se pensarmos que este projeto introduziu diversas tecnologias novas na empresa (Memcached, Server-side JavaScript, Widgets, REST…) isso era uma preocupação constante na minha cabeça.

Para o time na era fácil acumular as coisas que queriam conversar comigo para discussão em lotes. Por sorte nós conseguimos montar um time fabuloso antes do projeto iniciar; as pessoas conseguiam, de fato, trabalhar e decidir muita coisa em conjunto e compartilhavam a mesma visão para o produto e a arquitetura.

Essa experiência moldou a forma com que lido com meus times. No início de um desenvolvimento (ou no início do processo de refactoring, caso o trabalho que esteja fazendo seja a recuperação de um projeto que está indo mal) eu passo a maioria do tempo escrevendo código e lidando com problemas técnicos. Depois de algum tempo, talvez uma ou duas iterações, eu passo a dedicar a maior parte do tempo à não deixar desenvolvedores (e testadores, e analistas, e etc.) desperdiçarem o deles em coisas sem valor real.

Isto é central à maneira como eu vejo liderança em times de desenvolvimento. O primeiro problema que, como líder, me preocupo é o ciclo de feedback imediato, as coisas que fazem com que o desenvolvedor perca tempo para escrever código. Com este problema remediado –geralmente seguindo uma destas estratégias– eu passo a focar mais no próximo ciclo de feedback, e no próximo… Estes ciclos foram melhor explicados
na minha apresentação do Caelum Day 2009.

É duro para alguém que gosta do que faz pensar que liderar uma equipe de desenvolvedores significa ter pouco tempo para escrever código mas, no final, o que você precisa ter na cabeça é que é há muito mais valor em capacitar o seu time do que em qualquer peça de código que você consiga escrever sozinho.

AgileBrazil 2010

Wednesday, June 30th, 2010

Semana passada estive em Porto Alegre para o AgileBrazil 2010. Logo ao chegar em Porto Alegre, na quarta-feira, fui passar o dia com meus colegas e amigos da ThoughtWorks Brazil.

Numa das atividades que realizamos periodicamente na TW, o Lunch’n’Learn, o Danilo Sato nos contou um pouco sobre como foi a experiência de desenvolver o (excelente) sistema de avaliação de propostas para a conferencia.

IMG_0690.JPG

Durante o evento eu fiquei basicamente o tempo todo no stand da ThoughtWorks. Foi muito bom poder conversar com as pessoas e entender como as estão experimentando e trabalhando com métodos ágeis pelo Brasil afora.

A impressão geral é de que existe muita energia em torno das abordagens, mas o mercado ainda patina muito. A diferença maior entre o que vejo no Brasil e por outros lugares do mundo é que no Brasil não existe um numero suficiente de pessoas experientes com estas metodologias para atender à demanda nacional e, devido à carência de pessoas que falam inglês no país, não é fácil trazer pessoas de fora.

Infelizmente isso acaba ajudando a proliferação de charlatões cuja única credencial é um saco de certificações vazias. Muita gente afirmando que possui x mil anos de experiência em projetos ágeis, mas que esquecem de informar à clientela que 90% destas horas são dando treinamentozinhos onde bolinhas de tênis são jogadas por aí e apenas 10%, se isso, entregando sistemas. Bom, tomara que isso seja apenas uma fase.

Sobre apresentações, uma coisa que me deixou chateado no evento foi o fato de que tive duas propostas rejeitadas. O que me irritou foi o fato de que não foram rejeitadas pelo seu conteúdo mas apenas porque:

Infelizmente, pela regra de apenas uma sessão por autor, essa palestra
foi rejeitada.

A sessão que foi aceita não era exatamente uma proposta minha. O Rodrigo Yoshima havia me pedido para fazer uma participação em seu workshop sobre modelagem ágil e meu nome entrou como segundo autor neste.

O workshop em si foi bem legal. A demanda foi absurda, provavelmente mais de 3x o numero de lugares disponíveis. O Rodrigo conduziu sua atividade típica de modelagem e, ao final, eu fiz uma mini-palestra sobre como funciona modelagem ágil na maioria dos projetos na ThoughtWorks.

Mas este foi o meu único probleminha. De resto tudo foi excelente, certamente um dos melhores eventos que existem por aí.

Inovação: Construa e Eles Virão

Tuesday, June 1st, 2010

Inovar é preciso, e você sabe disto. Todos aqueles livros sobre a Cabeça do Pai Rico que Mexeu no Queijo do Segredo da Arte da Guerra foram bem claros: inove ou morra.

Mas como se faz isso em um ambiente corporativo? Sinceramente, não é muito difícil. A coisa mais importante é ter as pessoas ideais. Existem pessoas que trabalham de nove às cinco, e não existe problema nenhum em fazê-lo. Eu, entretanto, prefiro trabalhar com gente apaixonada pelo que faz. Gente apaixonada têm o privilégio de ter como hobby sua própria profissão. Dado este tipo de gente, basta você criar a oportunidade.

A minha experiência neste tipo de cenário começou com o que aprendi com o Antônio Carlos Silveira, que é meu grande mentor em anti-corporativismo. Quando trabalhávamos na Globo.com, a vida era uma eterna disputa entre dançar a dança tentando não cair no corporativismo das requisições de mudança, Jiras e PMAs. Das lições mais importantes que aprendi com o Toninho, uma das que mais ficou pode ser resumida em: você pode ter vestir uniforme de marinheiro mas ainda é um pirata.

E nós tentamos várias coisas, e falhamos miseravelmente em quase todas. Como exemplo, nosso time iniciou um projeto piloto para copiar os (míticos) 20% livre do Google. Sexta-feira a tarde os desenvolvedores eram livres para fazer o que quiser, seus projetos pessoais. Essa foi uma iniciativa capitaneada pelo Danilo Bardusco que, antes de ser promovido à gerente do lojinha fazia parte da finada equipe de Webmedia da Globo.com, certamente o melhor time com que já trabalhei na vida e cuja maioria dos membros são grandes amigos até hoje.

Todas as idéias que surgiram nestes projetos falharam de uma maneira ou de outra. A maioria não foi para frente por motivos técnicos/motivacionais (i.e. fogo-de-palha) e alguns chegaram a ter implementações completas mas não foram pro ar porque o pessoal de negócios não achou a idéia atraente.

Fracasso? Perda de tempo? Muito pelo contrario. O clima na equipe mudou de uma maneira tão brusca que parecia outra empresa. Quando entrei na Globo.com, em 2006, a Webmedia era, basicamente um departamento de uma grande empresa. Entravam requisitos e saia código. Após esta e muitas outras iniciativas como a adoção oficial de métodos ágeis –é bom notar que nós, na Webmedia, nunca fizemos Scrum de fato. E eu me orgulho muito disso.— o clima mudou completamente. A equipe passou a ter um clima muito diferente, bem mais próxima de uma startup do que de uma empresa de três letras. A coisa foi tão bem sucedida que o que você vê de Globo.com é uma tentativa de espalhar esta cultura.

Nos últimos dias eu tenho experimentado uma proposta parecida. Aqui na ThoughtWorks nós temos o eterno problema de tentar conciliar crescimento com qualidade e inovação. Como fazer para estimular pessoas que já trabalham em projetos para clientes para que não percam a motivação?

Algumas mentes tiveram uma ótima idéia: um concurso. Todos os ThoughtWorkers da Austrália são convidados a formar grupos e desenvolver uma aplicação para o iPad. O grupo vencedor leva dois iPads.

Parece algo bobo, mas será? Um iPad em Sydney custa por volta de AUD$1.000.00. Com descontos corporativos e uma série de benefícios fiscais que o governo fornece você consegue comprar o modelo mais caro por uns AUD$700.00. A maioria dos meus colegas ou já comprou um iPad ou está esperando a segunda geração, ninguém está contando com o prêmio em si. Por que as pessoas entrariam na competição?

Porque é divertido. Lembra de como eu falei que as pessoas que eu gosto de trabalhar misturam trabalho e diversão? Pois é. A foto abaixo mostra o Fábio Lessa e o Ben Barnard num domingo em pleno escritório:

O que é necessário para que este tipo de comportamento aconteça? Do mais importante nós já falamos: pessoas interessadas. A segunda coisa é suporte material. No caso do Fábio e do Ben, a empresa oferece algumas coisas que motivam alguém a ir para o escritório no Domingo aprender uma nova tecnologia:

  1. Um computador decente para cada empregado, neste caso um MacBook Pro trocado há cada dois anos
  2. Chave do escritório para todos os consultores, com acesso ilimitado e sem que seja feitas perguntas sobre “o que diabos você estava fazendo aqui?”
  3. Geladeira cheia de guloseimas, refrigerante, suco, cerveja e demais coisas que fazem mal
  4. Uso de cartão corporativo para pagar coisas como contas no Github, livros e downloads de screencasts
  5. Acesso corporativo às ferramentas necessárias (neste caso uma conta corporativa no iPhone Developer Program)

Mas por que a empresa oferece isso? Porque é boazinha e quer que todo mundo seja feliz? Não exatamente. A ThoughtWorks é uma consultoria, nós fazemos questão de nos diferenciarmos de outras empresas do ramo pela nossa qualidade. O concurso do qual estou falando vai ser decidido por uma banca de juízes. Nesta banca estão as pessoas de vendas da empresa.

A idéia não é apenas que um bando de desenvolvedores se junte e gaste alguns domingos bebendo cerveja de graça e esmurrando o teclado; a idéia é que criemos algo útil. Os times são estimulados a tentar focar em um dos nossos atuais clientes, pensar em um produto que possa ser interessante para os problemas que estes possuem.

A realidade Australiana é, certamente, bem diferente da Brasileira mas isso não quer dizer que algo do tipo não seja viável. Substitua iPads por HTML5 e você tem um programa muito parecido e com custo bem baixo, por exemplo.

E, como no caso da Globo.com, ainda que nada saia destes projetinhos seu papel já foi cumprido. Nós queremos que nossos consultores se interessem cada vez mais por tecnologia. Nós queremos que nossos clientes entendam que somos especialistas em tecnologia.

Nós queremos inovar. Sempre.

Fazer e Falar

Saturday, May 15th, 2010

Eu sou terrivelmente tímido. Você pode não acreditar dada a facilidade em que eu me meto em pagação de mico, mas esta é a verdade. Eu simplesmente morro de medo de começar uma conversa com uma pessoa que não conheço; o único motivo de fazê-lo com certa naturalidade hoje em dia é porque, apos tantos anos, eu descobri que ou me forço a falar com pessoas ou minha vida não vai para a frente.

A timidez me trouxe muitas coisas ruins mas também moldou meu comportamento de algumas formas que considero benéficas. Uma das conseqüências da timidez é que eu sou bem ruim em convencer os outros de alguma coisa. Isso é horrível em diversos cenários, mas uma coisa boa é que eu aprendi que antes de tentar convencer alguém é melhor ter meus argumentos, provas e protótipos prontos.

E, felizmente, durante a minha vida eu encontrei muitas pessoas com um comportamento parecido –ainda que, na maioria das vezes, não gerado por timidez mas sim por algum outro motivo. Especialmente, eu vi diversas vezes e espero continuar vendo o impacto que um time de “fazedores” tem em uma organização.

O cenário é sempre igual. Determinado lugar, seja um dos meus clientes atuais ou alguma das empresas para quem já trabalhei, possui um grupo de pessoas de alto prestígio dentro de casa. Infelizmente estas pessoas não entregam nada há anos, eles apenas vivem de política. Por algum motivo é formado um time com pessoas que se preocupam mais com fazer do que falar. Este time acaba entregando em uma cadência bem superior do que o melhor dos times antigos. A empresa fica feliz, os gestores resolvem espalhar a “cultura do fazer” (que sempre toma um nome mais buzzwordy como “agile”, “lean”, “times auto-geridos”, “gestão 2.0” ou coisa que o valha).

O problema é que a cultura do fazer não escala muito bem. As pessoas que preferem fazer à falar são chamadas pela diretoria e se pede a eles que ajudem a espalhar a boa nova para toda a organização. Neste ponto, em minha experiência, o time original se divide em dois.

O primeiro grupo é formado por pessoas que vêem na oportunidade um reconhecimento de que, finalmente, atingiram o nível de “ninja” –ou qualquer outro nome saído de algum desenho animado que os desenvolvedores superstar resolvam usar—e sua missão agora é virar alguma espécie de evangelista. Estas pessoas, então, passam a maior parte do seu tempo falando, e quando fazem alguma coisa estão ou trabalhando em algum projeto para reinventar a roda ou atrapalhando a vida de alguém com alguma de suas idéias brilhantes.

O outro grupo até tenta entrar na roda. Eles vão às primeiras reuniões, aos coding dojos e aos outros eventos. Eventualmente eles percebem no que estão entrando. Eles percebem que, se ficarem ali, sua vida mudará. Eles entendem que seu novo cargo não é nem um pouco diferente daquelas antigas “pessoas de alto prestígio dentro da empresa”. Possivelmente eles descobrem que tais pessoas foram, um dia, fazedores. Que estas pessoas foram convertidos de fazedores para peso-morto em um processo parecido com o que se está iniciando.

E então ocorre algum cisma. O primeiro grupo, dos desenvolvedores hax0r-evangelista-superstar-ninja-estrelinha-blogueiro-palestrante-modelo-atriz-manequim fazem da torre de marfim sua nova casa. Os desenvolvedores do segundo grupo voltam para sua caverna e tentam continuar trabalhando em paz.

Eventualmente o grupo dos ninjas começa a contratar pessoas com uma opinião parecida com a sua própria. Em pouco tempo a empresa está tomada por um estilo que um amigo costuma chamar de “awesome, dude!” (em uma voz de americano que acabou de fumar alguma coisa estranha).

Existem alguns benefícios, claro. Os problemas históricos da empresa são, geralmente, trabalhados. O problema é que ao invés de resolver o problema o time awesome está mais interessado em usar as novas ferramentas ninja. Se a ferramenta ninja não possui o necessário para resolver o problema é melhor ainda, eles podem usar suas maravilhosas habilidades awesome para desenvolver o necessário –ainda que isso signifique fazer a organização pagar um custo absurdo para desenvolver infra-estrutura em casa quando existem centenas de alternativas consolidadas e amplamente disponíveis, ainda que não sejam ninja.

Apos algum tempo as coisas começam a ficar engraçadas. O clã dos ninjas perde prazo atrás de prazo, entregando novas rodas ao invés de valor de negócio. Quando a coisa começa a apertar, o clã lança uma bomba de fumaça e some na escuridão; sua fama no meio awesome-ninja-modelo-atriz-manequim já o garantiu um outro emprego de evangelista ou coisa parecida em outro lugar. Todos os filhotes de ninja ficam perdidos. Lideranças alternativas aparecem e guerras internas sobre o que, afinal, significa ser awesome destroem a produtividade. Plataformas são reescritas a cada quinze dias.

De repente, alguém repara que o único time que anda entregando algo é o time daquele povo que fazia parte do grupo de fazedores original mas recusou-se a converter em ninja awesome. Alguém resolve visitar a caverna destas pessoas e descobre o que restou deles lá dentro, no escuro, isolado das ondas de hype. Usando ferramentas e técnicas que fora banida pelos ninjas há muito.

Infelizmente nem todos estão ali, alguns já desistiram e foram para outras organizações. E, nestas organizações, eles vão eventualmente encontrar outro grupo de fazedores. E vão entregar software de qualidade e no prazo. E vão ser chamados pela gerencia para espalhar a boa nova pela empresa. E o ciclo se repete.

Minhas Propostas para a Agile Brazil 2010

Saturday, February 27th, 2010

Acabo de submeter algumas atividades para o Agile Brazil 2010, evento que se realizará em Junho em Porto Alegre. Pelo que entendi, as propostas serão avaliadas pelo comitê organizador do evento.

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.

Sem Surpresas no Showcase!

Thursday, December 3rd, 2009

Existem muitas coisas que só se aprender na prática, depois de apanhar muito. Uma das coisas que eu –creio que- aprendi desta forma é como lidar com um showcase (ou Sprint Review, se você insiste).

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…

Preparações e Desculpas Esfarrapadas

Monday, October 26th, 2009

Para variar, a desculpa para não ter escrito mais frequentemente é a preparação requerida para a viagem ao Brasil. Eu sei que é uma desculpa esfarrapada mas infelizmente esta etapa envolve mais do que fechar malas e comprar canguru de pelúcia para as sobrinhas, meus últimos dois projetos requereram muita atenção e neste exato momento eu estou finalizando os últimos detalhes de um deles.

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:

caelum rio day

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.

Refletindo sobre Tendências

Friday, July 10th, 2009

Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.

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.

Mingle Day - Rio e São Paulo

Tuesday, June 23rd, 2009

Como este blog já anunciou este ano será cheio de eventos da ThoughtWorks no Brasil.

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

Agile Brazil 2009

Sunday, May 24th, 2009

Caso você ainda não saiba a ThoughtWorks está patrocinando um evento em Junho, no Rio de Janeiro: Agile Brazil 2009.

Além de palestrantes locais o evento vai contar com três ThoughtWokers: Jason Yip, Paulo Caroli e Adam Monago. O Jason é um dos mestre jedis em lean software development que temos na TW. O Paulo é brasileiro e trabalha oficialmente na TW US mas está em uma temporada na Índia. O Adam é gerente de produtos do Mingle.

Eu tenho conversado bastante com o Jason para explicar mais sobre o cenário de desenvolvimento de software no Brasil -que é bem diferente de qualquer outro país que eu conheça. Conhecendo a peça eu tenho certeza que a palestra vai ser uma excelente oportunidade para quebrarmos alguns mitos sobre lean que estão sendo introduzidos na cultura brasileira -como os de que contar “bugs por linhas de código” é uma métrica razoável para justificar uma prática ou metodologia.

Uma coisa boa é que ele está muito entusiasmado em fazer visitas à empresas interessantes. Eu entrei em contato com alguns lugares que considero bons candidatos mas se você tem alguma história interessante para contar e gostaria de recebê-lo por um dia me mande um e-mail que eu coloco vocês em contato. Note que ele vai estar no Rio e que você precisaria de alguma espécie de intérprete Inglês-Português.

Infelizmente eu não vou poder ir ao Brasil neste início de ano já que estou começando um projeto complicado na próxima semana que deve durar até Julho. Existe uma grande possibilidade de ir no segundo semestre, vamos ver se ela se realiza.