Fui convidado pelo Eduardo Fiorezi para a gravação do décimo episódio do seu podcast: Tudo que quero saber. O bate papo foi muito legal e contou com a participação do Marcos Tapajós da Improve It. O assunto foi “Disciplina em XP” e o áudio já está disponível em MP3.




Alguns dos assuntos tratados foram:

  • Disciplina em XP e Métodos Ágeis em geral
  • Resistência a práticas de XP
  • Liderança e o papel do coach
  • Abordagens para adoção de XP (artigo do Kent Beck)
  • Sustentabilidade de mudanças
  • Dojo e formas de aprendizado (Shu-Ha-Ri)
  • Importância das retrospectivas (artigo do Alex)

Post to Twitter

Programadores não treinam. Essa é uma triste constatação para a grande maioria dos programadores. Apesar de não ser verdade para todos os casos, aprendi com o Scott Adams que é importante começar com uma boa frase de impacto. Agora que tenho a sua atenção, posso falar da minha tentativa de mudar essa realidade: O Dojo@SP.

O que é o Dojo?

O Dojo é um espaço onde programadores se reúnem para treinar e aprender. As reuniões são periódicas e centradas num desafio de programação. Apesar do desafio, o objetivo não é terminar o problema. A idéia é aprender com as experiências vivenciadas pelo grupo. O ambiente é inclusivo, seguro e convidativo.

Dojo Audience

Eu vejo vários princípios de XP na forma como o Dojo funciona: passos de bebê, humanidade, falha, redundância, qualidade, melhoria, dentre outros.

Randori

As reuniões geralmente são conduzidas em dois formatos: no formato Kata alguém resolve o desafio em casa e apresenta na reunião “ao vivo”, começando do zero e seguindo TDD. No formato Randori o problema é resolvido “ao vivo” pelos participantes, usando TDD e Programação Pareada em turnos. A cada turno, o piloto volta para a platéia, o co-piloto passa a pilotar e um novo co-piloto é convidado da platéia.

Kata

Um pouco de história

A idéia do Kata como exercí­cio de treinamento foi proposta originalmente por Dave Thomas numa série de posts do seu blog. No final de 2003, Laurent Bossavit levou a analogia um passo adiante e propôs a criação de um espaço de treinamento em grupo um Dojo. A partir daí­, juntamente com Emannuel Gaillot, eles fundaram o Dojo de Paris, que está em funcionamento desde 2003. Outros gostaram da idéia e começaram movimentos semelhantes em outras partes do mundo.

Ruby Code

Depois de conhecer o Emannuel e a Emily no XP 2007, me motivei para começar um Dojo por aqui. Com o apoio deles e do wiki internacional, criado justamente para esse propósito, reuni alguns colegas e começamos a nos reunir no mês de Julho de 2007. Desde entnao estamos nos reunindo toda quarta-feira no Instituto de Matemática e Estatí­stica da USP.

Retrospectives

No Brasil, o Ivan Sanchez foi o primeiro a trazer essa idéia, fundando o DojoFloripa. Nossa iniciativa é a segunda do Brasil e esperamos que a participação do público paulista cresca no futuro e que outros Dojos comecem a aparecer em outras localidades do país.

Update: Esqueci de mencionar o Dojo de Recife que começou suas atividades no mesmo mês que a gente.

Como posso participar?

Se você está em São Paulo, junte-se a nós! Leia um pouco mais sobre nossas experiências no wiki e entre no nosso grupo de discussão. Não é necessário ter profundos conhecimentos de Python, Ruby ou TDD. Caso não esteja seguro para programar “ao vivo”, participe como ouvinte para sentir o clima. Espero vocês lá!

Food for the

Boa programação!

Post to Twitter

August 14th, 2007Chega de Processos!

Estou há tempos devendo um post sobre o artigo do Ivar Jacobson (um dos inventores do RUP e pai da UML) e seus colegas, primeiramente publicado numa série de artigos da Dr. Dobb's e depois num paper no JOLT. No geral eu concordo com o seu ponto de vista, mas antes de ouvirem (lerem?) o que tenho a dizer, sugiro fortemente ler o artigo original. Pronto? Agora podem continuar a ler meus comentários…

Terminologia

Antes de falar sobre o artigo, queria esclarecer algumas coisas sobre o termo “processo”. Essa palavra geralmente vem carregada de uma série de significados que podem não ser os mesmos de pessoa para pessoa. Se você ler o Manifesto Ágil, verá que “Indivíduos e interações são mais importantes que processos e ferramentas”. Que tipo de processo o Manifesto se refere? Aquele mega-processo formalizado que todos precisam seguir ou, como diz o Tim Lister, processo é tudo aquilo que você faz no dia-a-dia, quando ninguém está olhando (ou avaliando) ou mesmo quando está sobre pressão? Recentemente, a Mary me fez repensar sobre o assunto e ela sugere a palavra “sistema” ao invés de “processo”. Como não é a primeira vez que ela me faz repensar algumas coisas, prestei atenção e concordo com a sua colocação, afinal de contas, independentemente de seguirmos algo padronizado ou não, todos acabamos fazemos alguma coisa no nosso dia-a-dia (alguns podem chamar isso de processo ou não). O “processo” do ponto de vista Lean e o “processo” na definição do Tim Lister não são o mesmo “processo” que o Ivar Jacobson está criticando. Daqui pra frente, quando eu falar em “processo”, estou me referindo ao mesmo processo do Ivar Jacobson.

O inventor do RUP está dizendo que o RUP não funciona?

Não sou o único que acredita que (e conhece) muitas empresas que implantaram o RUP de forma errada. Gostei do exemplo do Vinicius, comparando o RUP com um grande supermercado de processos, onde você faz suas compras (agora, com o OpenUP você pode fazer compras de graça) e coloca no carrinho as coisas que acha mais convenientes. Isso gerou uma série de malefícios na indústria, que vou tentar citar abaixo (alguns não são culpa direta do RUP e, pelo que vi, o OpenUP parece estar bem mais ágil):

  • Processo pesado demais: “Não sei se preciso disso, mas na dúvida é melhor não ficar sem” (quando se trata de comida, minha mãe sempre disse que é melhor sobrar do que faltar) :-)
  • Disfarce para Cascata: Incepção = Levantamento de Requisitos, Elaboração = Análise, Construção = Implementação/Testes e Transição = Implantação. Cabe aqui dizer que já ouvi gente reclamando que o RUP não lida com a fase de manutenção (que seria a próxima fase do Cascata que não aparece nos quadradinhos). Minha resposta para essa pergunta vale outro post, mas precisamos parar de pensar que desenvolver e dar manutenção são coisas totalmente diferentes. O software deve estar em constante manutenção.
  • Processo pelo processo: “Que bom! Já tenho templates de documentos prontos para tudo! É só alocar alguém para prenchê-los”. Pior, eu já vi gente fazendo “RUP” escrevendo toda essa documentação DEPOIS só para seguir o processo. Alguém escreve Use Case depois que já tem algo implementado?!?!
  • Decomposição em especialidades: “Sou apenas arquiteto, não escrevo código” ou “Esse documento é responsabilidade do arquiteto! Não ouse duvidar da sua validade, mero desenvolvedor”
  • Gerenciamento voltado para alocação de papéis e tarefas: “Essas baleias fazem sentido. Não preciso de desenvolvedores no começo e o arquiteto vai estar livre para outro projeto na terça-feira da segunda semana do mês que vem…”
  • Modelagem voltada para documentação: “Preciso gerar esses Use Cases. Preciso gerar os diagramas de classe. Preciso gerar os diagramas de seqûências, …”

Resumindo, concordo com o inventor do RUP que esse tipo de processo precisa acabar e que as pessoas não lêem os livros antes de aplicar os conceitos.

Meu processo é diferente do seu

Como é muito bem colocado no artigo, existem semelhanças entre os diversos processos. Mas o importante é que o processo seja “adaptativo, extensível e capaz de absorver boas idéias” (destaque meu). Ao estudar Lean, você verá que o processo existe apenas para ser desafiado. As pessoas devem ter o poder de mudá-lo sempre que encontrarem desperdícios ou pontos de melhoria. Se você estava atrás de um processo que resolveria todos os seus problemas, O processo que seria padrão da empresa, sinto informar que ele não existe (e não sou nem eu que estou dizendo, o Fred Brooksdisse isso há bastante tempo). Definir um comitê para definição DO processo é, no mínimo, um desrespeito ao intelecto das pessoas que irão seguí-lo. Como um grupo de pessoas que não está trabalhando (e usando o processo), pode definir o melhor jeito que algo deve ser feito?

Além disso, os Métodos Ágeis já sabiam dessas coisas há um certo tempo. Crystal coloca a reflexão como uma das bases da metodologia e, mais pra frente, as reuniões de Retrospectiva foram incorporadas em outros processos como Scrum e XP. Hoje em dia, utilizo retrospectivas em vários contextos! É uma ótima forma de aprender com nossos acertos e erros e de melhorar para o futuro.

Concordo com todas as críticas aos processos colocadas por Ivar Jacobson: que têm diversos pontos em comum, que nunca serão totalmente completos em todos os aspectos, que nunca serão adotados de forma completa ou by-the-book, que não transmitem o conhecimento de forma eficiente e que podem ser estúpidos em alguns casos.

Usem práticas!

A solução do Jacobson é não focar mais em processos completos e pesados, mas sim em catalogar uma coleção de práticas. Cada prática deve ser isolada e atacar um aspecto específico do desenvolvimento. Dessa forma, cada “metodologista” (como ele diz) pode montar (e mudar) o seu processo conforme suas necessidades. O que eu achei legal na definição dele é que cada prática deve se “auto-verificar”. Em outras palavras, ela deve estabelecer um objetivo claro e uma forma de avaliar se esse objetivo foi atingido. As métricas de acompanhamento podem ajudar bastante aqui.

Apenas práticas resolvem?

Apesar de eu concordar com a mudança de foco (processos para práticas), ainda acredito que só as práticas em si não são tudo. Em XP, as 12 práticas originais dobraram (13 práticas primárias + 11 práticas corolárias). E isso foi feito com base nos valores e princípios da metodologia. XP se baseia nos valores da comunicação, feedback, simplicidade, coragem e respeito. São a forma como avaliamos uma determinada situação (seja desenvolvendo software ou arrumando a casa). Valores são amplos, enquanto práticas são específicas. Não consigo convencer minha empregada a usar TDD ou Programação Pareada para limpar meu quarto, mas posso conversar de forma respeitosa e mostrar que não faz sentido guardar um pé do tênis junto com um pé do sapato. Você pode chamar isso da prática do Calçado Pareado se quiser :-)

Na segunda edição do livro de XP, Kent Beck define melhor ainda os princípios da metodologia, que ajudam a traduzir os valores (amplos) em práticas (específicas). Acredito que para adaptar um processo de forma consciente e eficiente, não basta olhar apenas para um repositório de práticas e sair escolhendo. Precisamos dessas ferramentas mentais para auxiliar a adaptação para nossa situação. No livro Lean Software Development, por exemplo, a Mary e o Tom se focam quase exclusivamente nos princípios. A GM e A Ford tentaram copiar as práticas da Toyota e não conseguiram atingir os mesmos resultados.

Eliminamos os processos. E as ferramentas?

Minha última crítica ao artigo do Jacobson é que ele dá todos os argumentos contra os processos e, no final, mostra uma nova ferramenta, o EssWork, para gerenciar o repositório das práticas (e seus cartões), para organizar a forma de trabalho da equipe (seu processo) e para integrá-lo com as ferramentas de desenvolvimento da equipe. Não que eu seja totalmente contra o uso de ferramentas, mas assinei o manifesto e prefiro valorizar indivíduos e interações. Até chegar nessa parte eu estava gostando da idéia dele de utilizar cartões para representar as práticas e para montar o processo da equipe. Digamos que me decepcionei um pouco no final, mas nada que invalidasse o resto das coisas que havia gostado.

Acredito que ouvir uma opinião dessas de um cara tão respeitado pelos mais “tradicionalistas” é muito encorajador para nós. Segundo ele mesmo coloca, estamos numa fase de transição para uma nova era da engenharia de software e acredito que os Métodos Ágeis servirão como uma excelente base para mudarmos o cenário da nossa indústria.

Post to Twitter

August 10th, 2007Mestre, finalmente…

Como falei anteriormente, defendi minha dissertação de mestrado há pouco mais de 1 mês atrás. No entanto, como também alertei, eu geralmente me atraso com algumas coisas importantes, como revisar o texto e (o mais chato) montar o índice remissivo. Enfim, chega de desculpas! Algumas pessoas entraram em contato comigo interessadas em ler o meu texto, então resolvi disponibilizá-lo no site da AgilCoop. O título: “Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software”.




De maneira geral fiquei muito satisfeito com o trabalho e, principalmente, com o conhecimento que adquiri/refinei ao longo dos últimos 3 anos e meio. Muito do meu conhecimento em Métodos Ágeis veio a partir da leitura de diversos artigos, teses e livros (blogs, podcasts e vídeocasts também). Mas o que realmente valeu a pena foi a vivência prática: tanto participando e sendo monitor da disciplina de Laboratório de XP no IME, quanto trabalhando em projetos do “mundo real”, quanto ministrando palestras e cursos, quanto escrevendo artigos ou prestando consultorias.




Quem estiver interessado em ler minha dissertação e discutir algumas das idéias, é só entrar em contato comigo. Pode deixar um comentário aqui, me mandar um e-mail pessoal ou até discutir nas listas de discussão que participo, como a XP@Rio, agile-brasil, scrum-masters-brasil ou outras.




Ufa… que alívio :-)

Post to Twitter

Esse post de propaganda vai ser curto. Tenho duas novidades para compartilhar com vocês.

Treinamento de TDD na PyCon Brasil

Eu e o RBP vamos ministrar um treinamento de TDD na Pycon Brasil 3, em Joinville, SC. O treinamento será no dia 31 de Agosto (última sexta-feira do mês) das 9:00hs ao 12:30hs. Maiores informações podem ser obtidas no site do evento. Espero encontrá-los na conferência!

AgilVídeo

A AgilCoop está lançando uma nova série de vídeos das nossas palestras e treinamentos: o AgilVídeo. Já temos 7 episódios publicados de alguns de nossos cursos de verão do começo do ano. Mais vídeos estão em edição (valeu, Julian!) e devem aparecer por lá em breve! Por isso, assinem nosso novo RSS para acompanhar as novidades. Além disso, quem ainda não conhece pode ouvir também nossa série de podcasts: o AgilCast. Novos episódios também devem sair em breve. Aguardem!

Post to Twitter

August 2nd, 2007Propaganda Ágil

Geralmente eu gosto de compartilhar notícias interessantes no meu “Shared Feeds” do Google Reader, mas essa eu acho que vale um post especial: o pessoal da Version One, do Google e da InfoQ estão apoiando um concurso de comerciais ágeis, que serão apresentados na Agile 2007 (esse ano, infelizmente, eu não vou)! Vale a pena conferir! Separei alguns dos meus favoritos:

Musical da ThoughtWorks UK:

Drama da ThoughtWorks UK:

Estilo “Mac vs. PC”, da OutSystems:

Post to Twitter


© 2007-2009 Danilo Sato | Powered by Wordpress

Page optimized by WP Minify WordPress Plugin