Algumas pessoas me pediram os slides da minha apresentação no Falando em Agile 2008 sobre liderança de equipes ágeis, então decidi disponibilizá-los no SlideShare.
Enjoy! 
Archive for the ‘Eventos’ Category
[Falando em Agile 2008] Liderando Equipes Ágeis
Thursday, October 30th, 2008[Falando em Agile 2008] Retrospectiva do evento
Monday, October 27th, 2008O Falando em Agile foi ótimo!
Gostei muito de praticamente todas as apresentações que assisti. Para mim os destaques foram:
1) David Anderson fez uma apresentação de abertura que foi legal – apesar de não concordar com algumas coisas que ele fala. Mas isso é assunto para outro post, pretendo discutir alguns assuntos em maior profundidade nos próximos dias (ou meses, do jeito que a coisa está complicada).
2) Danilo Sato e Frank Trindade mostraram erros comuns na adoção de metodologias ágeis e veio a calhar para as pessoas que estão começado. Aliás o nível do pessoal estava bem variado: tinham desde gurus até gente que nem começou ainda.
3) Danilo Bardusco falou um pouco do que aconteceu no início da adoção de Scrum na Globo.com, assunto que desperta interesse e curiosidade nas pessoas. No início da apresentação ele teve problemas técnicos com dois notebooks Linux e acabou tendo que usar o meu MacBook. Só essa foto já valeu todo o evento! Pra quem não sabe o Danilo diz que é anti-Apple mas a verdade é que ele é um Macmaníaco enrustido, além de amar o seu iPhone…
4) Antonio Carlos Silveira falou sobre o papel do Product Owner no Scrum e fez uma apresentação muito bem humorada! Além do conteúdo relevante ele acabou revelando o quanto eu e Azambuja somos bons no Guitar Hero.
5) Phillip Calçado mostrou dois cases e apresentou alguns problemas que têm sido muito comuns em equipes ágeis. Todo mundo estava achando que ele falar mal da apresentação do David mas foi bem longe disso.
A minha apresentação sobre liderança de equipes ágeis felizmente foi bem aceita. Eu estava preocupado porque além de ser um tema bem difícil de se falar, é difícil de encontrar material e foi a primeira vez que fiz a apresentação. No final acabou dando certo e fiquei feliz pela quantidade de feedbacks positivos. Já tive várias idéias novas e colhí vários feedacks para melhorar a apresentação, então da próxima vez será bem mais legal. Se alguém tiver alguma coisa a acrescentar ou criticar, por favor sinta-se a vontade para me mandar um e-mail.
Sei que já deve estar ficando repetitivo, mas não dá pra não falar. “Pra variar”, o melhor do evento sem dúvida foram as conversas, o chopp ágil e as novas amizades. Tive a oportunidade de conhecer pessoas muito legais de todos os lugares do Brasil, além de reencontrar o pessoal já conhecido! Veja as fotos no meu Flickr. Assim como na Rails Summit o Twitter foi bastante usado como divulgador de notícias e opiniões durante o evento e só aí eu já conhecí pelo menos umas 3 pessoas também.
Parabéns mais uma vez para a Caelum e o Alexandre Magno pela organização do evento! Espero ver todos no Falando em Agile 2009!
Zen of Agile Management Workshop + Falando em Agile 2008, aí vou eu!
Monday, October 20th, 2008Daqui a pouco estou indo mais uma vez para São Paulo para participar de dois eventos bem legais!
O primeiro deles é o workshop “Zen of Agile Management” que está sendo organizado pelo Adail Retamal da Heptagon e será ministrado pelo David Anderson. O David tem algumas opiniões um pouco controversas sobre integração de Agile com CMMI mas mesmo assim ele é um profissional experiente e com certeza tem muito para acrescentar. Acho que as discussões serão muito interessantes e enriquecedoras.
O segundo é o “Falando em Agile 2008″, que está sendo organizado pela Caelum e será o primeiro grande evento de metodologias ágeis do Brasil. Neste evento vou fazer uma apresentação entitulada “Liderando equipes ágeis”, que é um apanhado de várias apresentações que assistí, livros que lí e experiências que tive liderando equipes ágeis. Estou bastante ansioso pra falar sobre o assunto… espero que todos gostem! Além disso o Danilo Bardusco vai falar sobre a implantação do Scrum na Globo.com e ainda teremos vários outros palestrantes como o Danilo Sato, Phillip Calçado, Antonio Carlos Silveira, David Anderson (sim, ele estará nos dois eventos), a galera da Caelum e muitos outros!
Essa semana ágil promete! Até lá! 
[Rails Summit Latin America] Retrospectiva do evento
Sunday, October 19th, 2008Excelente! Eu estava com boas expectativas sobre o evento mas não imaginava que seria tão legal como foi. Os três destaques para mim foram:
1) Chad Fowler deu um show na abertura do evento. A palestra entitulada “Being Remarkable” foi um resumão do livro dele “My Job Went to India”, que já é velho conhecido e leitura altamente recomendada. Apesar do conteúdo não ser novo ele é um excelente apresentador e fez com que valesse a pena ouvir tudo denovo.
2) Hongli Lai e Ninh Bui da Phusion falaram um pouco sobre o Passenger, mas o mais legal mesmo foi o que eles falaram sobre escalabilidade. Apesar de não terem falado nenhuma novidade, é legal reforçar sempre que não existe aquele papinho de “Rails não escala” – o que faz uma aplicação escalar é a sua arquitetura. Em termos de conteúdo acho que essa foi uma das melhores apresentações. Fora isso o interpretador de Brainfuck em Ruby que eles fizeram ficou o máximo!
3) Dr. Nic é um tremendo fanfarrão! Apesar do conteúdo da apresentação não ter sido tão interessante a palestra foi uma das melhores por todas as piadas que ele fez e gargalhadas que ele arrancou da galera.
Fora essas três assistí às duas apresentações do David Chelimsky sobre BDD com RSpec e Cucumber, a do Jay Fields sobre testes, a do Charles Nutter e Thomas Enebo sobre JRuby e todas as outras dos palestrantes internacionais. Só fiquei um pouco decepcionado com o DHH, porque acabaram fazendo um painel de perguntas e respostas e as perguntas que foram feitas não foram tão interessantes assim (com exceção de uma ou duas), mas não deixou de ser legal.
Uma pena que não pude assistir à última palestra do Obie Fernandez sobre a Hashrocket porque senão perderia meu vôo de volta para o Rio. O pior foi ver as mensagens no Twitter dizendo que ela foi muito boa… Minha sorte é que já assistí apresentações dele em eventos anteriores, então nem fiquei tão triste.
Mesmo com isso tudo, o melhor desses eventos são sempre as pessoas. Foi ótimo conversar com tanta gente legal e ainda conhecer pessoas novas da comunidade Ruby e Rails. Dessa vez devo ter falado com umas 100 pessoas diferentes entre pessoas que já conhecia e que não conhecia! Não vou citar nomes para não arriscar esquecer alguém mas foi ótimo conhecer e conversar com todos.
Antes de terminar, andei ouvindo uns burburinhos por aí de algumas pessoas reclamado sobre o preço da entrada (R$ 300). Galera, esse evento foi de graça! Sério, esse valor é absurdamente ridículo para dois dias de evento num local excelente, com comida boa e palestrantes de alto nível. Mesmo contabilizando as passagens e hospedagem em São Paulo não há dúvidas de que esse tipo de investimento vale muito a pena.
Parabéns mais uma vez para o Akita e a Locaweb por terem conseguido reunir todos esses grandes nomes num grande evento!
Esperamos ansiosos por um Rails Summit melhor ainda em 2009!
Rails Summit Latin America, aí vou eu!
Tuesday, October 14th, 2008
Daqui a pouco estou partindo para São Paulo para participar do Rails Summit Latin America!
Esse vai ser o primeiro grande evento de Ruby on Rails do Brasil (já tivemos outros menores como a RejectConf, o Minas on Rails e o Rio on Rails). Teremos a presença de vários palestrantes internacionais famosos como o David Heinemeier Hansson (por vídeo conferência), Chad Fowler, Dr. Nic Williams, Ninh Bui e Hongli Lai (criadores do Passenger), Jay Fields, Obie Fernandez e muitos outros, além de vários participantes nacionais como o meu amigo fanfarrão Vinícius Teles, o grande Fabio Kung, Danilo Sato e mais um monte de gente! Esse evento promete… É sempre legal encontrar toda essa galera reunida e rever os amigos!
O Fabio Akita e a Locaweb já estão de parabéns pela organização do evento e por conseguirem mobilizar todas essas pessoas. Nos vemos lá!
[Agile 2008 Conference] Vídeos e fotos da conferência
Sunday, August 24th, 2008Para quem quiser saber um pouco mais sobre o que rolou na Agile 2008 Conference, veja a página especial do InfoQ sobre a conferência. Foram filmadas 18 apresentações que serão disponibilizadas conforme o calendário que está no site. Assistam no mínimo 10 Ways to Screw Up with Scrum and XP do Henrik Kniberg, que inclusive comentei aqui no blog! Essa é muito legal!
Além disso têm algumas fotos que você pode ver no meu Flickr e no do Marcello Azambuja. Enjoy!
[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams
Saturday, August 23rd, 2008
Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…
O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.
Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.
A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.
Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!
Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.
Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.
A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.
Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.
A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.
[Agile 2008 Conference] Henrik Kniberg: 10 ways to screw up with Scrum and XP
Thursday, August 7th, 2008
Gostei muito da apresentação do Henrik Kniberg “ensinando” 10 maneiras para arruinar seus projetos mesmo usando XP e Scrum. É óbvio que eu não quero acabar com os meus projetos, mas é legal debater sobre os erros mais comuns nas adoções de metodologias ágeis e seus motivos para poder evitá-los.
Uma coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a apresentação (mesmo quando ainda não tinha assistido) e o seu blog sempre foram boas fontes de referência para mim.
Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:
- Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um P.O.! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
- Definition of Done: muitos times não tem uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.
- Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.
- Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.
- Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.
- Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.
- Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.
- Product Backlog: não existe ou não está priorizado corretamente.
- Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.
- Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.
É óbvio que essas não são as únicas maneiras de fazer besteiras em projetos com XP e Scrum e pode até ser também que tenham algumas maneiras mais “eficazes” que essas. No entanto esses problemas são muito comuns e acho que por isso mereceram destaque na apresentação.
Você pode encontrar os slides da apresentação no site do Henrik Kniberg. Esses slides são de uma apresentação um pouco mais antiga mas não há muitas diferenças.
[Agile 2008 Conference] Mary Poppendieck: The five dimensions of a system
Wednesday, August 6th, 2008
Pela primeira vez tive a oportunidade de assistir uma apresentação da Mary Poppendieck, e devo dizer que fiquei impressionado pela qualidade da apresentação… A mulher é simplesmente uma enciclopédia humana!
A Mary começou falando sobre histórias de “plank roads” (estradas de tábuas de madeira). Há muito tempo, quando todas as estradas eram de terra e cheia de buracos, alguém teve a idéia de fazer estradas de tábuas de madeira. Os benefícios foram muitos e enormes para a época: os transportes ficaram muito mais rápidos, o desgaste dos carros ficou muito menor, e por aí vai. Como essas estradas tinham um custo muito alto para serem produzidas, estimou-se que seriam necessários dez anos para que elas se pagassem. No entanto, quando as estradas ficaram com cinco ou seis anos começaram a se deteriorar, e era seria necessário fazer uma grande reforma para que elas voltassem a ser usáveis. Desta forma as estradas de tábuas se mostraram um péssimo negócio, pois com esse ciclo de implementação e manutenção jamais se pagariam. E aí a Mary levantou uma questão: assim como acreditava-se que as estradas de tábuas de madeira resolveriam todos os problemas do mundo até que os pontos negativos foram percebidos, será que o desenvolvimento ágil também não é uma estrada de tábuas e a qualquer momento vamos achar seus problemas?
Isso foi o gancho para ela mostrar várias histórias de estradas de tábuas, ou seja, histórias de coisas que acreditava-se que eram excelentes mas que depois foram mostrando seus problemas. Ela citou vários exemplos desde o waterfall até as ferramentas RAD, e levantou vários pontos sobre porque essas idéias fracassaram.
O que estamos tentando fazer hoje com desenvolvimento ágil é uma tentativa de resolver vários desses fracassos que tivemos em experiências passadas. A experiência com esses problemas e o entendimento das suas causas fez com que nascessem várias das linhas de desenvolvimento ágil que temos hoje como o XP, Lean Software Development e Scrum. Ainda acredita-se que o desenvolvimento ágil está no caminho de resolver vários problemas, portanto, respondendo à pergunta inicial, na opinião da Mary ainda não existem evidências de que o desenvolvimento ágil é uma “estrada de tábuas”.
Para encerrar, a Mary falou das cinco dimensões de um sistema e algumas questões sobre essas dimensões. Se você responder sim para todas essas perguntas (ou pelo menos a maioria), você está no caminho certo para desenvolver software de qualidade, de forma eficiente e que atende aos seus clientes.
Motivo/Razão do sistema
- Os especialistas técnicos estão sempre atualizados com o objetivo geral do sistema?
- Os técnicos do time vão checar por sí mesmos qual é o verdadeiro problema que o sistema deverá resolver?
- Existe um líder técnico que é responsável por atingir o objetivo do sistema e que guia o time tecnicamente caso necessário?
- Existem ciclos de aprendizado para descobrir se o sistema está servindo para o que se propõe e melhorá-lo de acordo com os objetivos?
Estrutura
- O time tem uma boa visão do todo sobre o que eles estão produzindo, sobre a empresa e sobre como o seu trabalho se encaixa no todo?
- Existem ciclos de aprendizado que munem os desenvolvedores com feedback sobre o uso do sistema?
- Os desenvolvedores menos experientes são treinados e supervisionados para garantir que eles produzirão código de boa qualidade que incorpora a aprendizagem de erros cometidos anteriormente?
- O trabalho é revisado por alguém apropriado?
Integridade do sistema
- A integridade do sistema é parte integrante do desenvolvimento, e quando ele é finalizado pode-se assumir que o sistema já está completamente testado?
- O sistema é desenvolvido de tal forma que é necessário um tempo desprezível para merges e testes no final?
- As falhas são raras e são investigadas a fundo para descobrir padrões que podem servir para resolver e previnir problemas similares no futuro?
- Esse conhecimento é capturado, consolidado e disseminado de uma maneira efetiva?
Tempo de vida do sistema
- O tempo de vida e possíveis futuras modificações são considerados no projeto e desenvolvimento do sistema?
- As pessoas que vão operar o sistema estão envolvidas no seu projeto?
- O time de desenvolvimento permanece envolvido com o sistema a longo prazo?
- As recompensas estão estruturadas de forma que desenvolver um sistema robusto que funcione bem ao longo dos anos é o comportamento mais encorajado?
Resultados do sistema
- O sistema atinge muito bem o seu objetivo e os clientes conseguem antecipar algum retorno sobre o investimento?
- O sistema atinge seus objetivos financeiros, dentro do seu custo e prazo planejados?
- O sistema funciona sem falhas e há confiança que ele continuará assim?
- O sistema atende plenamento àqueles que o operam, usam, suportam, mantém e criam algum valor com ele?
Você pode encontrar os slides da apresentação no site da Mary Poppendieck.
Agile 2008 Conference, aí vou eu!
Thursday, July 31st, 2008
Na próxima semana estarei em Toronto/Canada para a Agile 2008 Conference, a maior conferência sobre desenvolvimento ágil do mundo!
Com mais de 400 apresentações em 5 dias, o calendário da conferência, divulgado no início do mês passado está ótimo! Teremos a presença de vários nomes conhecidos do mundo ágil como Jeff Sutherland, Mary Poppendieck, Robert Martin (o Uncle Bob), Mike Cohn, Henrik Kniberg, Dan North, Mishkin Berteig, Scott Ambler, Linda Rising, Jim Highsmith, Neal Ford, James Shore… Vai ter tanta coisa legal que está até difícil escolher quais apresentações vou assistir! E isso tudo sem falar do amigo brasileiro e ThoughtWorker Danilo Sato, que apresentará o case do Coding Dojo de São Paulo.
Quem lê meu blog já deve ter percebido que desenvolvimento ágil é um dos meus assuntos favoritos, por isso podem esperar que provavelmente vou blogar mais do que o normal na semana que vem!
