CØdeZØne!

Submeti hoje duas propostas de palestras para o Agile Brazil 2010, um evento bem bacana que acontece em Porto Alegre em junho. Esse ano o evento conta também com a presença de Martin Fowler, da ThoughtWorks.

Segue abaixo o resumo das minhas submissões e, se você quiser, além de poder deixar comentários aqui, também pode fazer isso no próprio site de submissões do evento.

Espero te ver lá!

Como vi Scrum ser completamente rechaçado em uma grande empresa

Ouvimos por aí muitos relatos de sucesso de implementação de métodos ágeis em empresas grandes. Nós mesmos temos alguns. Mas onde estão os relatos de derrotas?

Nesta palestra vou contar uma história real em que vi Scrum ser completamente rechaçado em uma grande empresa que trabalhei.

Essa não é uma palestra sobre apontar culpados, mas sobre identificar falhas que comprometeram completamente a adoção de métodos ágeis nesta empresa.

Princípios de Agile Coaching

O que faz um coach ágil? Quais são suas ferramentas? Em que se baseia seu trabalho?

Essa palestra é sobre alguns princípios do coach ágil e como ser eficaz nessa missão. Vou abordar temas como:

- educação
- facilitação
- feedback
- percepção
- apoio

Além de falar sobre as atitudes esperadas de um coach:

- liderança por exemplos
- equilibrio emocional
- respeito ao ritmo do time
- linguagem que vence barreiras
- deixar o time aprender com seus erros

OK. Hora do jabá…

Há alguns meses, quando comecei a mexer mais com Erlang/OTP, senti a necessidade de ter uma ferramenta que gerasse a estrutura dos projetos, bem como stubs dos módulos necessários. Não encontrei nenhuma que fosse realmente simples. O que fiz? Cocei minha própria coceira, crie o projeto otp_kickoff.

Agora, de saco cheio desconfortável de usar Make para automatizar tarefas de build, resolvi coçar minha própria coceira novamente, crie o projeto ebuilder.

Se você também está mexendo com Erlang/OTP, sugiro que dê uma olhada nestes projetos, quem sabe eles também não facilitam sua vida, ahmmm?

Se eu tivesse que descrever a minha impressão sobre a Rails Rumble em uma frase apenas, certamente, eu usaria o título deste post, porque pra mim, a Rails Rumble foi demais mesmo.

Não ganhamos a competição, mas ganhamos muito participando da competição. Aprendemos muita coisa, fizemos amigos, nos divertimos bastante e fizemos umas das coisas que mais gostamos de fazer: programamos pra caramba! – dormi aproximadamente 5 horas durante as 48 horas de competição.

Meus sinceros agradecimentos à galera do meu time: Anderson Leite (com quem pareei bastante), Rafael (que foi quem teve a brilhante idéia do projeto) e Douglas (o melhor sysadmin que eu conheço). Foi muito bom fazer parte do time com vocês.

Nosso projeto

Bem, o resultado final do nosso projeto é este: whatannoysus.com. Não é tudo que nós gostaríamos que fosse, mas com certeza, já é um ótimo começo – e vamos dar continuidade.

Nós o construímos em menos de 48 horas, usando Ruby on Rails, Cucumber e MySQL; e o botamos para rodar num Ubuntu Server com Phusion Passenger e Nginx.

Patrocínio

Vida longa à Gonow!

A Gonow nos tratou muito bem, com tudo do bom e do melhor. Comida, camiseta Rails Rumble, hotel (que eu nem fui lá conhecer) e uma infra-estrutura de primeira.

Muito obrigado mesmo, a todos da Gonow e, se precisarem de alguma coisa, é nóiz!

Poder aos pares!

Tenho que concordar com o Yoshima, parear traz um ganho incrível no desenvolvimento. Ainda tem muita gente que acha que parear é reduzir o trabalho pela metada, afinal, são dois em um computador. Mas a real é que boa parte do nosso trabalho como programadores é pensar e conceber soluções que, em última instância, codificamos. E é aí que entra o ganho da programação em parte: duas cabeças pensam melhor do que uma – e quatro olhos acham bugs mais rápido também.

Outros relatos?

É isso que eu [resumidamente] tinha a dizer. Se você quiser saber um pouco mais, conhecer outros relatos, veja os posts do Anderson Leite e do Rodrigo Yoshima. E se houver algo que eu não mencionei e que você gostariam de saber, sinta-se à vontade para deixar um comentário.

Vou ficando por aqui e espero poder rever toda a galera – que foi muito legal conhecer – na Rails Summit.

Abraço!

Então não deixe de visitar…

O site é recém-nascido, mas já tem uns recursos bem legais, como sistema de pesquisa por palavras-chave, núvem de tags e entre outros. Vale a pena conferir e acompanhar sua evolução – e oportunidades de bons trabalhos.

Mais uma iniciativa bem interessante da Caelum.

Agora a pouco o Antonio Carlos, gerente de tecnologia do Yahoo!, postou os slides de sua apresentação na Campus Party 2009 sobre desenvolvimento ágil de software com Scrum.

Resolvi postar aqui também, porque achei bem interessante para quem quer ter uma visão introdutória sobre o assunto.

Divirtam-se!

Ontem foi publicado no InfoQ Brasil a tradução de um post bem legal de Chris Sims entitulado James Shore: The Decline and Fall of Agile. O texto começa falando sobre o cenário atual dos novos times ágeis e como isso é decadente se comparado ao verdadeiro espírito ágil:

James Shore declarou que agile está em declínio. Ele cita como por exemplo os vários times fazendo ’sprints’ e stand-up meetings, sem adotar nenhuma das práticas técnicas necessárias para produzir software de alta qualidade no longo prazo. Em sua estimativa, este fato tem levado milhares de times Scrum praticar métodos Ágeis tão pobremente que eles quase certamente fracassarão, e provavelmente levarão o movimento ágil com eles.

Esse é um bom ponto de partida para que novos times ágeis façam uma reflexão sobre o quão ágeis realmente são.

Aqui na CVC Turismo estamos praticando desenvolvimento ágil há pelo menos um ano e meio, e uma das coisas que aprendemos durante esse período foi que, manter o espírito ágil realmente vivo em nós, é mais importante do que seguir “regras de caixinha”. Afinal de contas:

Indivíduos e interações são mais importantes que processos e ferramentas!

Então, muito embora Scrum seja a nossa base, não é e nem jamais será o nosso limite. Além de Scrum, há também outras práticas ágeis que estão presentes em nosso dia a dia, tais como:

- Integração Contínua (mesmo antes de adotarmos Scrum);
- Code review;
- Refactoring;
- Código coletivo;
- E testes, testes e mais testes!

Ainda temos muito que aprender, crescer e amadurecer – mas acreditamos que estamos no caminho certo.

E você, o que tem a dizer sobre seu ambiente de trabalho? O quão ágil ele realmente é?

Se você quer conhecer Scrum, eu tenho uma dica pra você: Dá uma chegada no blog do Luiz Aguiar que lá tem um post super divertido de Introdução ao Scrum.

Vinicius Manhães Teles, figura super conhecida e respeitada do mundo ágil, tem postado videos muito legais no blog da Improve IT. Se você se interessa por desenvolvimento ágil, vale a pena dar uma passada por lá para conferir.

Uma tendência natural do ser humano é aos poucos ir deixando de lado os detalhes. Isso acontece em quase tudo na nossa vida. Basta você parar para pensar um pouquinho e vai ver que já fez isso inumeras vezes – no seu trabalho, nos seus estudos, na sua vida familiar. Todas as vezes que você se sente muito confortável e sabedor de algo, acaba se esquecendo de algum detalhe. E são nesses momentos que você comete os erros mais banais da sua vida.

Todos já fomos somos vítimas desse mal. Mas todos temos também a solução ao nosso alcance…

Reciclagem!!!

Todo processo e todo conhecimento precisa de reciclagem periódica. Só assim conseguimos nos manter atentos aos detalhes.

Tudo bem, mas o que isso tem a ver com o Scrum Master?

O Scrum Master deve ser o guardião dos valores e das práticas do Scrum na equipe. É dele a responsabilidade de disseminar esses valores e práticas e promover a sua reciclagem de tempos em tempos, tanto para o Time quando para o Product Owner. Isso mantém o Scrum não apenas vivo, mas evoluído na equipe.

Com isso, a toda equipe [e os projetos] só tem a ganhar. Porque nem o Time, nem o Product Owner, nem o próprio Scrum Master, se esquecerão de coisas que parecem apenas meros detalhes – mas que fazem a diferença quando observadas [e/ou aplicadas] adequadamente.

Por isso, Scrum Master, fica a você a perguntas: O que você tem feito para promover a reciclagem da sua equipe?

Afinal, ser Scrum Master é ser facilitador…

Este é o titulo de um post fantástico do Carlos Vilella, que o Rodrigo Yoshima traduziu, e que eu não poderia deixar de citar aqui no meu blog.

Leitura obrigatória!