Se você é de São Paulo ou do Rio de Janeiro, nunca me (ou)viu falar ao vivo e estiver interessado em me conhecer para bater um papo, vai ter algumas chances nos próximos meses. Depois de participar de um evento de Software Livre, de XP e de Python nesse ano, vou apresentar algumas palestras para a comunidade Java, Ruby e Rails. Detalhes a seguir…

09/Nov e 10/Nov: Conexão Java '07 Hands On


Conexão Java '07

No dia 10 de Novembro, das 11:30 – 13:00, vou apresentar uma palestra sobre Métodos Ágeis chamada “Agile Methods for the Traditional Guy”. Espero que o título não assuste as pessoas, pois o tema é legal e a idéia é dar uma introdução geral sobre os princípios do Manifesto Ágil, XP, Scrum, Lean, discutir problemas dos métodos tradicionais e desmistificar alguns mitos sobre Métodos Ágeis. As inscrições podem ser feitas pelo site do evento (com desconto até o dia 31/Out) e o evento acontecerá na Universidade Anhembi Morumbi da Vila Olímpia.

Quem for participar terá a chance de assistir ótimas palestras de alguns amigos: o Carlos Villela vem apresentar o keynote e falar sobre o “Arquiteto de uma nota só”; o Phillip Calçado vem reapresentar a ótima palestra sobre arquitetura do JustJava (dessa vez sem o Paulo), além de coordenar uma atividade que promete ser divertida: a Oficina do Arquiteto; O Fernando Meyer vai falar sobre DSLs e ANTLR; o Alexandre Magno vai falar sobre Scrum, dentre outras palestras muito boas.

Além das palestras, estarão acontecendo também mini-cursos em paralelo. O pessoal da Caelum vai ensinar Hibernate, AJAX e JSF, Java ME e JPA. Pelo que conheço da qualidade dos cursos deles, são mini-cursos ótimos e imperdíveis se você estiver interessado em aprender um pouco sobre essas tecnologias.

17/Nov: RejectConfSP '07


RejectConfSP '07

No fim de semana seguinte (sim, no meio dos feriados) estou ajudando o Fabio Akita a organizar a primeira RejectConf em São Paulo. A idéia é juntar a comunidade Ruby e Rails para mini-apresentações (de 10 a 30 minutos) sobre diversos assuntos, além do networking, troca de conhecimentos e diversão :-)

O evento vai acontecer no IME-USP, no Auditório Jacy Monteiro, das 11:00 – 17:00. As inscrições são gratuitas estão atualmente com lista de espera, mas pode ser feitas neste formulário. Quem estiver interessado em apresentar algum tópico, basta preencher este outro formulário.

Minha mini-palestra será sobre RSpec e RSpec on Rails. Quem quiser um gostinho de como é programar com RSpec/RBehave pode assitir o screencast #01 do Dojo@SP.

08/Dez: Rio on Rails


Rio on Rails

Por fim, mais um evento da comunidade Rails, organizado pelo Vinicius e o pessoal da Improve It. O evento está confirmadíssimo e acontecerá no SENAC, das 9:00 – 18:00. As inscrições custarão R$50,00 e estarão disponíveis em breve no site do evento (disponibilizado pela Improve It nos próximos dias).

O assunto será RSpec e RSpec on Rails novamente, mas dessa vez terei mais tempo para me apresentar.

Nos vemos por lá!

Acredito que os eventos serão bastante divertidos e informativos e espero que ninguém durma de tédio nas minhas apresentações :-). Faça sua inscrição e deixe um alô nos comentários para saber se devo te encontrar por lá!

Post to Twitter

Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?




Nesse post, inspirado por uma pergunta na XP@Rio, espero dar algumas dicas para ajudar quem tenha se identificado com minha alfinetada. :-)

O que é Teste de Aceitação?

Em primeiro lugar, é bom deixar claro qual a visão Ágil sobre testes. XP, em particular, pede que sejam escritos dois tipos de testes automatizados:

  • Testes de Unidade: testes do programador. Geralmente testa um pedaço isolado do código. Quando seguimos TDD, o teste é escrito antes do código e funciona como especificação, te ajudando a pensar no design. Depois de escrito, serve como documentação executável do seu código.
  • Testes de Aceitação: testes do cliente. Um teste de aceitação (ou Story Test, ou Customer Test) descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história está completa (aceita).

Um pequeno adendo: apesar de ser importante reconhecer esses dois tipos de teste propostos por XP, existem outros tipos de teste igualmente importantes como: testes funcionais, de interação, de carga, de segurança, etc… Isso varia conforme sua situação particular, mas esse não é o assunto desse post :-)

Algumas desculpas

Como disse no início do post, muitas equipes deixam de automatizar seus testes de aceitação. Existem muitas justificativas para explicar esse fato:

  • Automatizar testes de aceitação é difícil: Testar um sistema web do ponto de vista do usuário ficou muito mais fácil atualmente com ferramentas como o Selenium ou Watir. Testar uma interface gráfica Swing é um pouco mais chato porém não impossível. Testar um software que gera imagens ou modelos visuais (um CAD como o Archimedes, por exemplo) é bem mais difícil. Testar um sistema embarcado depende do hardware. Testar um jogo depende de um jogador (automatizar o jogador pode não ser tão fácil). E por aí vai… dependendo da sua situação, tenho que concordar que sua tarefa pode não ser tão fácil. Mas qual a graça de programar sem desafios? :-)
  • O teste fica muito grande: Para testar um cenário, geralmente é preciso fazer muito setUp. Você vai precisar criar diversos objetos, suas associações e terá que se preocupar em apagá-los depois (para manter a independência entre os testes e entre diferentes execuções do mesmo teste). Isso pode gerar problemas de dependência e você passa a perder mais tempo fazendo setUp e tearDown do que efetivamente escrevendo os testes importantes.
  • O teste demora muito: O problema anterior faz com que seu teste demore muito para executar. Muitas vezes você pode depender de um banco de dados ou de outro sistema para testar um cenário de aceitação real. Se utiliza um sistema de Integração Contínua, perceberá rapidamente que seus ciclos de build demoram muito mais.
  • O cliente não sabe escrever testes: É muito mais fácil um programador aprender a usar o JUnit ou qualquer framework do que o cliente. É papel da equipe encontrar a melhor forma de comunicação com o cliente. Se o cliente trabalha num banco, tente usar uma planilha ou uma tabela. Se seu sistema é cheio de regras de negócio complicadas, tente explorar os diferentes cenários pensando em exemplos. Infelizmente, não existe uma estratégia universal.

Alguns desses problemas são mais difíceis que outros. Mas de que adianta falar mal e enumerar problemas sem dar idéias de soluções?

Sugestões para melhorar a situação

Um novo papel

Quando falo que a Toyota eliminou o departamento de qualidade e teve ganhos incríveis de produtividade, geralmente recebo olhares espantados e desconfiados, principalmente da equipe de testes. “Você está dizendo que devo ser demitido?”. Calma, não é bem assim. A Toyota não eliminou sua preocupação com qualidade. Pelo contrário, ela valoriza tanto esse aspecto que compartilhou essa responsabilidade com TODOS os envolvidos no processo. Não quero que os testadores sejam mandados embora. Pelo contrário, suas habilidades devem ser espalhadas e aproveitadas por todo o processo de desenvolvimento. Devem trabalhar muito mais próximos e não no final da cadeia. Shigueo Shingo já dizia: “Inspecionar para procurar defeitos é desperdício. Inspecionar para previnir defeitos é essencial”.

O papel do testador numa equipe ágil é tão importante quanto o do programador. Ele ajuda a equipe e o cliente a aprimorar suas estratégias de teste (principalmente de aceitação). Eles fazem parte da equipe e também são responsáveis pela entrega! Lembrem-se: a história não está pronta enquanto não estiver testada!

Reaproveitando uma estratégia conhecida

Eu citei os maiores benefícios dos testes de unidade e TDD: eles te ajudam antes, durante e depois. Antes, te ajudam a especificar o problema e pensar no design do código. Durante, eles servem como rede de segurança, identificando um bug de regressão assim que ele é inserido e dando suporte à refatoração sem medo. Depois, servem como documentação executável do seu código, auxiliando você a dar manutenção e novos integrantes a entender o que o sistema faz.

Esses mesmos benefícios se aplicam aos testes de aceitação! O Kent Beck percebeu essa Auto Semelhança na segunda edição do livro de XP. A prática conhecida como Story Test Driven Development (ou STDD) funciona exatamente como TDD, porém no nível das histórias. Eu comentei sobre essa prática num post anterior da XP2007.

O cliente deve colaborar com a equipe para enumerar os cenários de aceitação. Pense em exemplos. Uma pergunta que te ajuda a definir tais cenários é: “Como saberei que terminei essa história?”. Se seu cliente não sabe ou não quer definir os cenários de aceitação, apenas responda: “Pronta!”. Os testes de aceitação te ajudam a saber quando a história está pronta. Se o cliente não define nenhum cenário de aceitação, a história está automaticamente pronta (inclusive testada!!). :-)

Ferramentas

Diversas ferramentas e frameworks têm surgido para auxiliar sua vida. Como já disse anteriormente, o Selenium e o Watir podem facilitar sua vida no teste de aplicações web. O FIT, que já comentei algumas vezes aqui, também te ajuda a sair do lado técnico e define uma linguagem de comunicação mais simples com o cliente (através de tabelas de exemplo). O Fitnesse armazena essas tabelas (e outras informações) num wiki.

Um framework que atraiu bastante minha atenção ultimamente foi o RBehave. Atualmente ele está sendo incorporado ao RSpec, um framework bem conhecido para BDD em Ruby (e Rails, mais recentemente). O assunto teve até um tutorial na última RailsConf na Europa. Ele te permite escrever cenários de aceitação da história de forma executável. Vale a pena dar uma olhada. Tem a versão Java também: jBehave.

Apesar de ter escrito muito, acredito ter apenas arranhado a superfície desse assunto tão interessante e tão amplo. Para um pouco mais de informações, sugiro ouvir o AgilCast #9 e assistir alguns dos nossos AgilVídeos.

Também gostaria de saber: O que você programa/desenvolve? Qual sua estratégia para automatização dos testes de aceitação? O que de legal você fez em relação ao assunto? Qual sua maior dificuldade?

Post to Twitter

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 Brooks já disse 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

Hoje tive a honra de ser entrevistado pelo Vinicius Teles e inaugurar a nova Série Experiências Ágeis no podcast da Improve It. Ele foi extremamente ágil e conseguiu terminar de editar e publicar o podcast no mesmo dia. Além dos assuntos mencionados no blog da Improve It, conversamos sobre Programação Pareada Promíscua, técnicas para criar e validar interfaces gráficas, AgilCoop e Métodos Ágeis no Brasil em geral. Aproveitem!




MP3 do Improvecast 7

Post to Twitter

June 23rd, 2007XP 2007 – Dia 5

No último dia da conferência, um tutorial pela manhã e um workshop de tarde. Alguns dos temas do dia foram: barreiras invisíveis, teoria das restrições e área de trabalho informativa.

How to Overcome Invisible Barriers – Christoph Steindl e Christian Federspiel

Esse tutorial da parte da manhã foi o mais fraquinho dos que participei. Apesar disso, pude aproveitar algumas das idéias apresentadas e acho que elas podem trazer valor na hora de discutir um problema invisível. Como o Tom de Marco disse: “Não importa qual o problema, é sempre um problema com pessoas”. Algumas das ferramentas apresentadas e exercitadas ao longo da sessão foram:

  • 5 Por Quês?: Essa é uma excelente ferramenta que a Toyota usa quando precisa encontrar a verdadeira causa de um problema. Corrigir sintomas não curam a causa, então ao perguntar o “Por Quê?” do “Por Quê?”, você quase sempre chega na raíz. Essa ferramenta eu já conhecia e posso dizer que ajuda muito.
  • Diagrama de Resolução de Conflitos (Conflict Resolution Diagram ou CRD): Uma forma de estruturar um conflito de idéias entre membros da equipe e explorar as suposições que estão por trás daquilo. Apesar de não ter gostado muito da forma como o modelo te obriga a preencher alguns poucos quadradinhos, tirei duas idéias boas do exercício: ele te força a pensar no objetivo em comum por trás das suposições dos pontos de vista opostos e ele te força a usar palavras extremas e exageradas ao defender as diferentes suposições. Com isso, você acaba chegando em frases do tipo: “Tecnologias tradicionais NUNCA são arriscadas”, “A ÚNICA forma de motivar os desenvolvedores é utilizando tecnologias de ponta” ou “As novas tecnologias são SEMPRE o MAIOR risco”.
  • Mapa de Objetivos Intermediários (Intermediate Objective Map ou IO-Map): Uma árvore para estruturar os fatores críticos de sucesso e as condições necessárias para atingir um objetivo (raíz da árvore). Acredito que é fácil utilizar essa ferramenta do jeito errado (quebrando o objetivo em diversos fatores de sucesso e sub-otimizar as partes ao invés do todo), no entanto tirei uma lição do exercício prático: mesmo não sendo muito eficaz, ela te força a pensar sobre o objetivo e a expressar essas idéias, levando a um maior entendimento a respeito do objetivo (ou mesmo encontrando um objetivo melhor).

Nosso Diagrama de Resolução de Conflitos

Além dessas ferramentas, o palestrante comentou rapidamente sobre outras (nem vale a pena citar, pois achei muito complicado e estranho) e sobre a Teoria das Restrições, que é uma boa forma de tratar um problema sistêmico (ao invés de otimizar partes, você precisa focar na sua maior restrição). Eu já conhecia um pouco sobre a Teoria das Restrições e acho que ela é muito alinhada com os valores Lean.

Reface Your Team Space – Patrick Kua

Um workshop excelente do Patrick Kua, da Thoughtworks de Londres. Em uma atividade interativa e criativa, discutimos em equipes diversas formas de exibir informações no espaço de trabalho. Como podem ver pelas fotos, passamos boa parte do tempo rabiscando e discutindo várias formas de tornar o progresso visível e ajudar a equipe a entender o andamento do projeto (tanto da iteração atual quanto do projeto como um todo).

Primeira Iteração do Quadro Branco

Na segunda parte do workshop, sentamos em uma espécie de “mesa-redonda” (sem a mesa no meio) e discutimos diversas práticas e ferramentas que utilizamos em projetos passados. Levantando idéias que deram certo e outras que não deram certo, aprendi bastante com a experiência das outras pessoas. Algumas das coisas que compartilhei que as pessoas gostaram:

  • Retrospectivas fora do ambiente de trabalho: quando a retrospectiva é feita no mesmo (ou próximo do) ambiente de trabalho, eles tendem a se concentrar menos, pois estão no seu habitat natural. Ao invés de rearranjar ou refatorar o ambiente para diversos propósitos, as vezes é melhor trocar de ambiente. Essa técnica funcionou muito bem para mim.
  • Humorômetro: já utilizei essa técnica em diversos projetos e todo mundo parece gostar e adotar. A idéia é japonesa, e se chama Niko-niko calendar. Cada membro da equipe tem uma linha num calendário e, ao final do dia, cola um adesivo colorido ou desenha um smiley que representa seu humor naquele dia. Esse indicador geralmente não serve para a comunicação com gerentes ou pessoas externas (Não é para virar algo do tipo: “Em média, o Fulano é mais triste que o Siclano”), mas sim como um fator de motivação dentro da equipe. As pessoas tendem a soltar a criatividade e eu diria que 99% dos projetos que começaram a usar decidiram continuar com essa prática.
  • Combinados ao invés de regras: essa foi uma idéia que o Cícero, da Paggo, compartilhou com a gente na última palestra no IME. Ao invés de definir regras para a equipe, ele define “combinados” pois é algo que as pessoas concordam em seguir e soa menos como uma imposição. E outra coisa: quando você combina alguma coisa, sua responsabilidade em cumprir o combinado é muito maior do que quando quebra uma regra alheia.

E agumas coisas legais que aproveitei e vou testar:

  • Mantra do dia: a equipe tem uma pilha de “mantras” e a cada dia, na reunião em pé, uma é escolhida e compartilhada na área de trabalho.
  • Diferentes materiais: estou trazendo comigo post-its em forma de setinhas que são muito legais. Além disso, conheci uma folha de papel com estática (não sei o nome certo) que gruda na parede e serve como quadro branco improvisado. Infelizmente não sei se vou conseguir achar um desses no Brasil. Outra idéia boa de material é usar uma espécie de cera (ou massinha) para grudar os cartões na parede.
  • Sinais sonoros: quando o build quebra, ao invés de mandar e-mail (que na minha experiência não é uma boa mídia, pois as pessoas ignoram depois de um tempo) ou usar uma lava-lamp (que é legal, mas hardware X10 no Brasil é muito caro), usar algum sinal sonoro para avisar que tem algo errado. Pensei na trilha do plantão da globo, pois essa é uma música que sempre me assustou e me fez prestar atenção. :-)
  • Tokens: além do token da reunião em pé e da integração, que já utilizei em algumas ocasiões, conheci outros tipos de tokens: um peixe, para quando alguém começa a desviar do assunto você arremessar e “pescá-lo” de volta; um timer de tomate (aqueles de cozinheiro), para usar como estimativa e para servir como cronômetro e focar o trabalho durante um certo período de tempo (olha que divertido: “Essa história eu estimo em 4 tomates”).
  • Sino da História: um sino que é tocado sempre que um par termina uma história. Numa equipe grande isso pode ser uma boa forma de mostrar que as coisas estão andando.
  • Nariz de Palhaço: esse pode ser um pouco ofensivo, mas se o seu build estiver quebrando frequentemente, considere premiar alguém com um desses. :-)

Quadro Branco Refatorado da Outra Equipe

Na discussão, surgiram assuntos relacionados ao espaço físico da equipe. Uma idéia interessante foi a existência de um espaço coletivo, onde a equipe pareia, e um espaço privatido onde cada um pode fazer coisas pessoais e falar no celular. O Kent Beck descreve um ambiente assim no segundo livro de XP. Outra idéia foi utilizar as janelas para colar post-its ou cartões. Eu já testei e é uma boa forma de ganhar espaço quando o número de quadro brancos é restrito. Só não deixe os post-its colados por muito tempo (mais que 10 minutos) pois eles tendem a cair. A gravidade atrapalha. :-)

Por fim, uma pequena discussão sobre a eficácia das informações visuais espalhadas pela área de trabalho: se alguém não está mais olhando alguma coisa (ou atualizando), se você tem muitas coisas espalhadas ou muitas informações, geralmente é um bom sinal para refatorar seu espaço de trabalho. As reuniões de retrospectivas são um bom momento para discutir coisas desse tipo e descobrir o que está sendo realmente útil e o que é apenas “barulho visual”.

Conclusões e Próximos Passos

Essa conferência foi muito proveitosa. Pelo fato de ser bem menor que a Agile (esse ano foram aproximadamente 200 participantes), tive a oportunidade de ficar muito mais perto de pessoas importantes como Kent Beck, Joshua Kerievsky, Mary e Tom Poppendieck, dentre outros. Além disso, conheci muitas pessoas da comunidade XP na Europa e tive a chance de compartilhar experiências e aprender bastante. Esse tipo de evento é sempre empolgante e estimulante, pois saímos com diversas idéias novas. Espero poder compartilhar algumas dessas idéias com a comunidade ágil do Brasil e volto no final de semana com vontade de fazer um monte de coisas novas por aí. Me aguardem… :-)

Post to Twitter

June 21st, 2007XP 2007 – Dia 4

Conforme eu havia previsto, hoje teria menos coisas para escrever. Como houve manifestações a favor dos meus relatos, vou tentar compensar esse post mais “magro” com mais fotos. Mas isso não significa que pouca coisa aconteceu. Pelo contrário, muita coisa interessante aconteceu: 2 tutorias excelentes, almoço com a Mary e Agile Café. Pena que está acabando…

Thinking, Refining, and Communicating the Business Perspective with Executable Documents – Rick Mugridge e David Hussman

Pela manhã, decidi participar do tutorial sobre Documentos Executáveis com o David Hussman (Agile Coach) e o Rick Mugridge, co-autor do famoso livro sobre FIT, apesar de ter participado de uma sessão sobre o framework na Agile 2006. O interessante foi que a ênfase da apresentação foi muito além da ferramenta FIT/FitNesse/FitLibrary. O conceito da documentação executável como elemento de comunicação com os clientes e como forma de definir os cenários de aceitação de uma história vai muito além da ferramenta. Documentos Executáveis são aqueles que não são escritos uma vez só; aqueles que não tendem a ser esquecidos ou a crescer infinitamente; aqueles que ajudam as pessoas a pensar e colaborar; aqueles que ajudam as pessoas a comunicar o que o produto realmente faz.

Algo que gostei muito, e que não tinha visto de forma formalizada antes, foi a prática conhecida como Story-Test Driven Development (STDD ou Desenvolvimento Dirigido por Testes de Histórias), onde antes de fazer TDD, a equipe de programadores, analistas, testers e clientes colabora para definir os critérios de aceitação da história antes mesmo de começar a desenvolver. Como a Mary disse no seu tutorial, por que uma equipe de desenvolvedores deve começar a trabalhar numa história sem saber o que deve fazer? Segunda ela, na empresa do Jeff Sutherland (criador do Scrum e CTO da PatientKeeper) os desenvolvedores não podem colocar a mão numa história se ela não é “testável”. Se o cliente não consegue (ou não se importa em) sentar com a equipe para definir exatamente o que espera do software desenvolvido, não tem sentido começar a programar. Qual o valor esperado?

David Hussman apresentando STDD

Segundo os palestrantes, o caminho para chegar a uma documentação executável passa por diversas etapas:

  • Personas: Para quem não conhece, é uma prática criada por Alan Cooper para descrever os usuários do sistema de forma mais humana. Ao invés de usar “homens-palito” (ou seja lá como chamam esses bonequinhos), uma persona tem nome, foto (ou caricatura), interesses pessoais e valores que espera extrair do produto. No artigo que vou apresentar semana que vem na WDRA (em Porto de Galinhas!), apresento de forma breve essa prática que é muito eficiente (e divertida).
  • Histórias: Partindo das personas, você consegue enxergar diversos objetivos e tarefas que um usuário irá realizar no seu sistema. Fica bem mais fácil escrever histórias a partir dessas tarefas.
  • Testes de Histórias (Story-Tests): Uma vez que temos histórias, é hora de colaborar com o cliente para entender o que eles realmente querem. Dessa conversa devem surgir os testes de histórias (ou testes de aceitação, como o Kent Beck definiu em XP).
  • Cenários, tabelas/fixtures (no caso do FIT), APIs, etc: No momento que a equipe entende a real necessidade do cliente (que pode mudar com o tempo, mas isso é normal), precisam garantir que aquilo seja armazenado de forma executável e que sirva como ferramenta para informar o desenvolvedor quando uma história está quase pronta (“quase” pois o seu conceito de “pronta” pode – e deve – ir mais além da codificação/teste).
  • Documentos Executáveis: Só depois de tudo isso você é capaz de construir uma documentação executável. Essa documentação serve como registro de como o sistema deve funcionar e, quando o cliente mudar de idéia ou quiser discutir algo em particular, ela pode ser alterada/testada em ciclos curtos de feedback para garantir que o sistema se adapta às novas necessidades.

Personas

No final, o grupo se dividiu e a discussão continuou entre os mais interessados no nível mais técnico (discutindo o FIT/FitNesse em particular) e os mais interessados no nível mais amplo. Fiquei um pouco em cada discussão.

From User Story to User Interface – Jeff Patton

Na parte da tarde participei de mais um excelente tutorial com o Jeff Patton, da Thoughtworks. Material impecável, slides e timing muito bons, didática excelente e exercícios práticos divertidos e instrutivos. E, claro, um assunto muito interessante: como o design de usabilidade (por aqui mais conhecidos como Interaction Design) e o design de interfaces gráficas se encaixam no mundo ágil?

Quem vive no mundo do design de interfaces e da usabilidade tem uma propensão a trabalhar com BDUF (Big Design Up-Front). O que geralmente se diz é que você precisa ter uma idéia de todas as possíveis formas de interação e atividades que um (ou vários) usuário(s) terão com o sistema antes de projetar a melhor interface e o melhor design gráfco. Nós do mundo ágil sabemos que BDUF não funciona muito bem. Num dos relatos de experiência apresentados anteriormente, Robert Beedle mostrou um estudo empírico qualitativo mostrando que, em geral, a maioria das atividades de definição de interface tendem a acontecer no início dos projetos mesmo. Ele mostrou quatro abordagens diferentes:

  • Fazer todas as atividades de design da interface antes de começar a desenvolver
  • Fazer ambas as atividades em paralelo, de forma iterativa
  • Fazer ambas as atividades em paralelo, porém trabalhando no design de interface uma iteração na frente (de forma que a equipe de desenvolvimento trabalha sempre em cima do que a equipe de interface desenvolveu na iteração anterior)
  • Começar somente com atividades de design da interface e, gradualmente, inserir atividades de desenvolvimento. Conforme as iterações vão passando, a quantidade de trabalho de desenvolvimento vai aumentando enquanto de design diminui, até o momento em que só é preciso desenvolver. Algo como aqueles gráficos de baleia do RUP.

No tutorial, Jeff apresentou o modelo em camadas proposto por James Garrett para descrever os diferentes elementos da Experiência do Usuário:

  • Superfície: interface gráfica, com cores e elementos gráficos do design.
  • Esqueleto: uma espécie de “wireframe” de como os elementos estão estruturados na interface.
  • Estrutura: como os elementos da interface estão conectados para formar um todo.
  • Escopo: uma lista de tarefas que um usuário tipicamente irá realizar através da interface.
  • Estratégia: os objetivos por trás das tarefas que serão realizadas na interface.

Apresentou também as diferentes formas de representar os usuários (Atores, Papel, Perfil ou Persona) e as diferentes formas de capturar e representar as interações do usuário com o sistema, como: Use cases, Histórias, Workflows, Cenários e Modelo de Tarefas. Durante o resto do tutorial, nos organizamos em grupos e realizamos diversas atividades para produzir e validar um protótipo em papel: partimos de uma história e definimos um simples cenário de uso, descrevendo as interações entre o usuário e o sistema (num formato de Use case essencial). A partir disso, definimos os diversos componentes que fariam parte da interface gráfica para que o cenário fosse atendido.

Componentes da interface gráfica em fase de incepção

Depois veio a parte divertida: começamos a desenhar e recortar os diversos componentes e “montar” a interface em papel, usando canetinhas, papel, transparências, cola pritt e liquid paper.

Criando nosso protótipo em papel

Por fim, vimos como funciona um teste de usabilidade num protótipo de papel e como, depois de poucas iterações, conseguimos diminuir o número de erros de usabilidade. Para isso, cada um tinha um papel (role, para não confundir): o “facilitador” apresentava nossa proposta e era o único que podia conversar com o usuário-final (num estilo narrador de esporte). Outra pessoa faz o papel de “computador” e fica trocando os papéis/botões/transparências conforme o usuário-final interage com o protótipo. Além do “usuário-final” (que eram duas pessoas vindas de uma outra equipe), alguém precisa fazer o papel de “observador” e ficar tomando nota dos problemas encontrados durante o teste.

Teste de usabilidade do protótipo com usuários de outra equipe

Foi uma experiência valiosíssima (o melhor tutorial até agora na conferência) e aprendi bastante sobre como integrar o mundo do design com o mundo de desenvolvimento. Nós sempre aprendemos bastante quando passamos por problemas parecidos. O Jeff está fazendo um trabalho excelente para juntar essas duas comunidades. Para quem se interessar, vale a pena conferir as suas idéias.

Discussões em Geral

Não bastassem os ótimos tutoriais, aind tive o privilégio de ser convidado para almoçar com a Mary e com o Tom para discutir várias coisas. Uma das discussões foi a respeito da velocidade, e expressei minha opinião (e a da Mary) na XP@Rio. Não vou me repetir por aqui. Se alguém se interessar, é só seguir o link. :-)

Como comentei, as pessoas que não estão participando de workshops ou tutoriais geralmente se reúnem nas mesas de fora do hotel para discutir assuntos ágeis, no que foi batizado como Agile Café. Dei uma passada no final do dia, mas já estava cansado e resolvi voltar pro hotel para descansar. Por hoje é só, pessoal. Amanhã é dia de mais um tutorial e um workshop. Arrivederci!

Post to Twitter

June 21st, 2007XP 2007 – Dia 3

Muitas coisas aconteceram no último dia da main track: painel de discussão sobre certificações, artigos científicos, painel de discussão sobre “melhores práticas”, DSLs e keynote do Kent Beck. No terceiro dia de conferência diversos tópicos foram abordados e, daqui pra frente, participarei apenas de tutoriais e workshops, então espero que a densidade dos posts diminua :-)

Painel de Discussão sobre Certificação

 

Certificação no mundo ágil é um assunto que está na moda. A Agile Alliance anunciou recentemente sua posição sobre o assunto; Scott Ambler colocou sua opinião a favor num artigo da DDJ; além disso, muitos debates vêm acontecendo nas diversas listas de discussão, como scrumdevelopment@Yahoo, extremeprogramming@Yahoo e na nossa XP@Rio. A opinião dos participantes do painel estava dividida entre:

 

  • Contra: Joshua Kerievsky e David Hussman
  • A Favor: Jeff Patton e Boris Gloger
  • Em cima do muro: Rachel Davis, representando a Agile Alliance

Uma das grandes discussões girou em torno do Certified Scrum Master. Joshua e David argumentaram que é um excelente treinamento (eu concordo), porém dá um título muito poderoso (para o observador desatento) para um curso de 2 dias sem uma prova no final. Em outras palavras, empresas procuram SCMs sem saber o que eles tiveram que fazer para se tornar um (está escrito na descrição do curso na Scrum Alliance). Do outro lado o Boris argumentou que, apesar de ser sim uma ferramenta de marketing (muito eficiente, por sinal), foi um programa que propiciou a criação de uma enorme comunidade interessada no Scrum e que, de uma forma ou de outra, contribuiu para o aumento na adoção dos Métodos Ágeis na indústria. Sobre esse tópico, estou um pouco mais pendente pro lado contra (apesar de ser um SCM) devido à fragilidade da nossa indústria. Infelizmente as empresas buscam profissionais certificados sem saber o que os torna certificados. Apesar disso, concordo com o argumento do Boris de que a formação de uma comunidade é importante. Acredito que uma estratégia de longo prazo para popularização dos Métodos Ágeis não deve ser tão ambiciosa a ponto de querer atingir quantidade e qualidade ao mesmo tempo. Olhando por esse lado, acredito que é mais fácil (e natural) conseguir a quantidade antes da qualidade. Por isso, acho que os treinamentos de SCM são importantes.

Dentre outras discussões sobre o tema, surgiu a idéia de ter uma “certificação” ágil mais parecida com o que fazemos na universidade: um curso muito mais longo, muito mais abrangente e que fornece uma base comum de conhecimento para que o aluno possa evoluir. Quando um aluno se forma na graduação, não espera-se que ele saia totalmente proficiente. Existe um consenso de que a experiência trará benefícios. Gostei dessa idéia de uma “faculdade ágil”. :-)

Outro ponto interessante da discussão foi a separação entre habilidade e certificação (ou treinamento). Ter uma certificação ou participar de um treinamento não é garantia de que o participante irá adquirir a habilidade necessária. Isso pareceu ser consenso. O único ponto do Joshua foi que ele prefere chamar isso de treinamento ao invés de certificação, pois é mais realista. Por outro lado, o Boris argumentou que qualquer programa de certificação gera um mercado mais atraente para empresas.

Outros assuntos interessantes foram abordados na discussão, mas esse espaço é muito curto (e minhas anotações muito sucintas) para expor de forma adequada. Acho que a discussão está boa e deve continuar…

Artigos Científicos

 

Após o debate, houve uma sessão de apresentação de artigos científicos, dentre eles o meu. Confesso que fiquei um pouco nervoso por ter que apresentar em inglês e um pouco mais nervoso quando vi o Kent Beck na platéia. Mas isso passou assim que comecei a falar (como costumava acontecer quando tinha que tocar piano na frente dos outros.. he he) e acho que correu tudo bem. Após a sessão fui conversar com o Kent Beck (sobre outro assunto) e ele me disse que gostou da minha apresentação, o que me deixou muito orgulhoso :-)

 

Dentre os outros papers apresentados, teve um que não gostei (nem o Boris.. he he) sobre um meta-modelo para modelar e medir a eficácia de processos ágeis. O exemplo usado foi o Scrum e me pareceu uma tentativa de fazer um framework-de-processos(RUP)-ágil-genérico, onde outras metodologias ágeis poderiam ser “instanciadas”. Enfim, não deu pra entender muito bem a motivação para usar aquilo (e eu também tenho um certo preconceito quando começam a falar de processos com caixinhas parecidas com UML, setinhas e coisas <<entre símbolos estranhos>>).

 

Por outro lado, os outros dois papers foram bem mais interessantes. O primeiro foi sobre o FitClipse, um plugin do Eclipse para execução e edição de testes de aceitação do FIT. Ele roda em cima do FitNesse e permite a distinção entre testes que falham por motivos aceitáveis (ainda não foram implementados) ou por motivos inaceitáveis (já foram verde e ficaram vermelho depois de um tempo), além de mostrar uns gráficos bonitinhos. O outro foi sobre o EzUnit, uma extensão do JUnit que permite a identificação mais precisa de qual pedaço de código pode ter causado uma falha. O framework permite a definição do(s) método testado(s) (Method Under Test ou MUT) com anotações (isso achei estranho) ou, para quem é preguiçoso como eu, escreve as anotações através de análise estática e dinâmica do código. Gostei da idéia, mas não tanto dessa parte das anotações/análise estática. Concordo com o comentário do Kent Beck no final de que a análise dinâmica, associada aos deltas das mudanças efetuadas mais recentemente, dão uma informação muito boa sobre onde uma possível falha pode estar localizada. Além disso, linguagens dinâmicas não permitem análise estática de qualquer forma. Acho/espero que no futuro vamos usar testes unitários como “compiladores” e ferramentas como essa podem facilitar a vida.

 

Painel de Discussão sobre “Melhores Práticas em Software”

 

Antes de mais nada, uma colocação da Mary: “Não existe uma MELHOR prática”. A partir do momento que consideramos algo como o melhor, deixamos de pensar em formas de melhorar, afinal de contas já temos O MELHOR. Muito bem colocado e os presentes no painel concordaram: Giancarlo Succi, Jutta Eckstein, Robert Beedle e Yael Dubinsky.

 

Os “painelistas” (como se escreve isso em português?) mostraram uma preocupação na definição e escolha de práticas muito técnicas. A agilidade propõe aspectos humanos que dificilmente são expressados em práticas específicas. Por outro lado, medir e avaliar a adoção de princípios e valores é complicado. Robert Beedle defendeu o ponto de que a prática mais importante é a colaboração. Ela inclui os valores humanos e dirige o resto do processo na direção certa. Segundo ele, sua primeira impressão sobre XP foi positiva pois servia como uma ferramenta cognitiva para compartilhamento de conhecimento que, mesmo sem saber explicar muito bem como, fazia com que as coisas certas acontecessem. Em outras palavras, se você seguisse as práticas (e suas sinergias e valores embutidos), você seria capaz de dirigir a produção do software certo, ao contrário da abordagem da engenharia de software tradicional que busca a forma certa de produzir software. Produzir certo vs. Produzir o software certo. Conceitos bem diferentes.

 

Por fim, houve uma discussão sobre como medir o sucesso nos projetos. O Giancarlo defendeu o ponto de que é preciso utilizar métricas e objetivos claros para avaliação do sucesso. Num debate sobre o valor de métricas quantitativas e qualitativas, Robert Beedle disse que para medir o lado humano dos Métodos Ágeis, métricas qualitativas são a única solução. Por outro lado, Giancarlo disse que é mais fácil entender dados quantitativos, apesar de serem facilmente manipuláveis ou mal-interpretados.

 

Birds of a Feather: Domain Specific Languages – Emily Bache

 

Apesar de não constar na programação oficial, a Emily havia mandado uma proposta de workshop que foi recusada e, mesmo assim, decidiu fazer uma sessão aberta para interessados em discutir DSLs. Eu achei muito louvável a atitude e, como não programaram nenhum Open Space na conferência desse ano, também demonstrou o poder da comunidade em adaptar o programa e compartilhar conhecimentos.

 

Nesse workshop, discutimos o conceito de uma DSL que, para minha surpresa, não era consenso. Eu ainda não tive muitas experiências utilizando uma DSL numa situação onde precisei de verdade, a não ser na definição de testes de aceitação. Porém, como disse para os participantes, já houve momentos na minha carreira (antes de saber o que era XP) onde consigo ver uma DSL ajudando a diminuir a distância entre especialistas e programadores. Após diversas discussões surgiram alguns aspectos do que seria uma DSL:

 

  • Uma DSL deve maximizar a densidade semântica: em outras palavras, dependendo do público-alvo (os especialistas no domínio), usar muitos parênteses e símbolos de programação podem atrapalhar a legibilidade (particularmente em DSLs internas).
  • Uma DSL deve ser executável: isso inclui a habilidade de edição e execução na frente do especialista do domínio, trazendo feedback imediato.
  • Deve ser fácil e rápido alterar uma DSL: em outras palavras, o especialista de domínio deve ser praticamente capaz de escrever na DSL (ler é mais fácil que escrever).

Ainda no tópico da densidade semântica, houve uma pequena discussão sobre se uma DSL deve ou não ser obrigatoriamente legível para o cliente (ao invés do programador). Nesse caso, o rake não seria uma DSL.

Keynote de encerramento: Ease at Work – Kent Beck

 

Para não tornar um post longo ainda mais longo, não vou me estender muito sobre esse keynote. Kent Beck é O CARA. E dessa vez, ao invés de falar sobre aspectos técnicos, metodologias ou empresas, ele deu uma palestra quase como psicólogo (tudo bem que a esposa dele é psicóloga), para tentar fazer-nos refletir sobre nosso papel como programadores e como encaramos nosso trabalho. Em outras palavras, como fazer com que possamos nos sentir bem com nossas qualidades e defeitos?; como conviver e aceitar que não estaremos sempre no auge ou na lama?; como sair do trabalho com a consciência tranquila de que demos nosso melhor?; Como sustentar mudanças?; Como sermos mais responsáveis e transparentes no trabalho?

 

Como disse, espero que o post de amanhã seja mais resumido pois também cansa escrever esses relatos… brincadeira :-)

 

Post to Twitter


© 2007-2009 Danilo Sato | Powered by Wordpress

Page optimized by WP Minify WordPress Plugin