Danilo Sato

Já faz um tempo que estou para falar das novidades e, depois das palestras em novembro/dezembro, é com orgulho que apresento o novo curso de XP na Caelum.




Eu sou um pouco suspeito pra falar bem dos cursos deles, pois não só sou amigo do pessoal de lá, como também ajudei a montar esse novo curso. No entanto, posso garantir que a preocupação deles com a qualidade do treinamento, do material, a didática e, principalmente, com o aluno é um diferencial em comparação aos cursos encontrados no mercado. É por isso que fiquei feliz com o convite para ajudar a montar esse curso e ministrar a primeira turma.




O conteúdo está muito legal e quem participar vai aprender e se divertir. O treinamento terá um enfoque bastante prático, e exigirá que os alunos programem bastante. Minha meta nessas 20 horas de curso é falar não só sobre a filosofia Ágil, os princí­pios e valores de XP, como também mostrar os aspectos técnicos e mostrar a sinergia entre as práticas da metodologia. Espero que o aluno saia do treinamento com diversas idéias novas para implantar na sua empresa.




Fico bastante feliz que novos cursos desse tipo estão aparecendo no mercado de software nacional. Isso só vem a reforçar o fato de que os Métodos Ágeis estão ganhando mais interesse no Brasil a cada dia que passa.




Quem estiver interessado em participar, é só entrar em contato com o pessoal da Caelum para mais informações ou para fazer a reserva.

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

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

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

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á!

Acabei de ler um post do Uncle Bob que tem tudo a ver com meu último post. Um trecho interessante que ele diz é:

Acceptance tests should be written at the start of each iteration. QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests written in FitNesse, or Selenium or some other appropriate automation tool.




The first few acceptance tests should arrive within a day of the planning meeting. More should arrive each day thereafter. They should all be complete by the midpoint of the iteration…

Numa tradução livre:

Testes de aceitação devem ser escritos no início de cada iteração. QA e os analistas de negócio devem pegar as histórias escolhidas na reunião de planejamento e torná-las em testes de aceitação automatizados escritos no FitNesse, Selenium ou outra ferramenta de automação apropriada.




Os primeiros testes devem chegar no dia seguinte ao planejamento. Mais testes devem aparecer nos próximos dias. Eles devem estar completos até a metade da iteração…

Apesar de já concordar com o conteúdo, ele me fez repensar algumas coisas. Como já disse anteriormente, testadores e responsáveis por QA ficam de boca aberta quando digo que o departamento deles não deve existir. Incluo minha irmã nesse grupo, que trabalha no controle de qualidade de um indústria química :-)

O que o Uncle Bob me fez pensar foi que os testes devem aparecer conforme são necessários. É a filosofia Just-in-Time da Toyota aplicada aos testes. Se você escreve os testes (de unidade ou de aceitação) pouco antes de serem necessários você:

• Evita desperdício escrevendo documentos de casos de teste ou pensando nos cenários mais elaborados do mundo. Seu foco está na pergunta: “Como sei se esta história está terminada?”.
• Evita a formação de um estoque de código sem teste (sistema pull e não push).
• Usa o teste para pensar no design do que está construindo.
• Cria um script automatizado que serve como documentação e ajudará os desenvolvedores que precisarão mexer no seu código futuramente (Benefício Mútuo).

Acho que a partir de agora vou mudar meu discurso. Ao invés de dizer que o departamento de qualidade deve ser extinguido, vou dizer que QA deve ser Lean, Just-in-Time. Acho que essa vai ser uma abordagem mais inclusiva e vai gerar menos confronto. O que você acha?

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)

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.

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.

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.

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.

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.

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á!

Boa programação!

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.

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 :-)

Qual a melhor forma de medir o sucesso de uma equipe? Os Métodos Ágeis promovem um processo empírico para desenvolvimento de software, baseado na colaboração e no feedback trazido por ciclos curtos de inspeção e adaptação. Encontrar maneiras eficazes de avaliar o processo e a equipe não é uma tarefa simples. O senso comum leva à decomposição e à proliferação de diversas métricas baseadas na premissa de que se cada parte do processo for otimizada, os resultados do processo como um todo serão otimizados também. Quando critiquei o modelo hierárquico do IO-Map, minha preocupação era justamente essa. Ao tentar micro-otimizar partes de um sistema por meio de diversas métricas, o objetivo verdadeiro se perde em meio a tantos outros substitutos e a equipe perde sua capacidade de tomar decisões num nível mais macro.




Um outro problema com métricas bastante conhecido (o Vinícius comenta sobre isso em um dos seus podcasts) é que as pessoas geralmente se comportam de acordo com a forma que são avaliadas. Robert Ausin, no livro Measuring and Managing Performance in Organizations, discute os problemas da avaliação de desempenho baseada em métricas e destaca que sua principal vantagem (“Você tem o que você mede”) é também sua principal desvantagem (“Você tem exatamente o que você mede, e nada mais”). Métricas manipuláveis serão manipuladas. Esse é o lado triste da história.




Por isso queria aproveitar esse post curto para discutir uma classificação interessante, que pode te ajudar a refletir quando estiver pensando em utilizar uma nova métrica.

Métricas Organizacionais

Também conhecidas como “métricas de avaliação” na abordagem Lean. São as métricas que medem o sistema como um todo, no nível mais alto. Elas medem o quanto de valor seu processo consegue entregar. A abordagem Lean sugere uma prática conhecida como Measure Up, onde você usa uma medida de avaliação que foge do controle de qualquer sub-parte do processo, incentivando a colaboração entre os indivíduos de diferentes equipes e evitando a micro-otimização. Essas métricas-chave devem ser geralmente escolhidas pelo cliente ou quem quer que espera extrair algum valor do sistema. Como consequência dessa prática, você acaba ficando com um número muito menor de métricas. Recentemente apresentei na XP@Rio alguns exemplos de métricas organizacionais:

• Cycle Time: métrica Lean mais conhecida que mede o tempo médio para que seu processo atenda uma nova requisição. Essa métrica geralmente surge depois que a equipe entende seu Value Stream Map e o conceito importante é que ela começa a contar com o cliente e só termina quando o cliente é atendido.
• Métricas Financeiras: o investimento de muitos projetos de software é justificado com base na melhoria de alguma métrica financeira. Essa métrica pode ser o Retorno de Investimento (ROI), Net Present Value (NPV), uma matriz de lucros e perdas ou coisas desse tipo. Como uma equipe consegue melhorar esses números de outra forma que não seja entregando o software?
• Satisfação do Cliente: Se você está preocupado em entregar valor para seu cliente, o quão satisfeito ele está? Uma métrica sugerida pela Mary e pelo Tom para medir isso é o Net Promoter Score, uma medida simples que verifica se seus clientes recomendariam seu produto para outro cliente.

Métricas de Acompanhamento

Também conhecidas como “métricas de diagnóstico”, “indicadores” ou “métricas informativas”. Elas são medidas internas da equipe que auxiliam na melhoria do processo, através dos ciclos de inspeção e adaptação. Essas métricas agregam dados, mas não os associam com nenhum indivíduo, assim como não devem ser atreladas ao valor que está sendo entregue. Seu ciclo de vida também é geralmente mais curto. Uma vez que o processo evoluiu, elas se tornam desnecessárias e devem ser descartadas. Novas métricas de acompanhamento deverão surgir conforme a equipe avança e o ciclo continua, em busca da melhoria contínua.

Um exemplo amplamente utilizado desse tipo de métrica é a velocidade. Espera-se que, após um certo tempo, a velocidade do time se estabilize (se nenhum fator externo acontecer, como mudança de membros da equipe ou mudança da linguagem de programação). Uma vez que a velocidade se torna “conhecida”, a equipe geralmente não precisa mais medí-la.

Como esse tipo de métrica surge em diferentes contextos e problemas, podemos pensar em diversos outros exemplos. Supondo que a equipe está tentando melhorar nas práticas de teste, pode utilizar a cobertura de código como métrica de acompanhamento. Se querem melhorar a integração contínua, podem medir o tempo entre commits, ou o número de linhas alteradas em cada commit. E por aí vai…

Propaganda Descarada

Aproveitando o assunto (que oportuno!), vou fazer uma propaganda descarada da defesa da minha dissertação de mestrado, na próxima sexta-feira. As informações para quem estiver interessado em assitir são:

Título: “Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software”

Orientador: Alfredo Goldman

Local: Instituto de Matemática e Estatística (IME/USP)

Sala: 256 Bloco A

Data: 29 de Junho de 2007

Horário: 9:30hs

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).

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).

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. :-)

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… :-)

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?

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.

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.

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.

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.

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!