Prática ágil: busque e compartilhe o conhecimento

Sintoma: os desenvolvedores de um projeto jamais enfrentaram um tipo de problema e decide resolvê-lo. Uma história começa a ser desenvolvida, mas o mesmo fica parado diversas vezes em pequenos detalhes que impedem completá-la pois ninguém na equipe possui tanta experiência com a ferramenta: existem mais dúvidas do que respostas na equipe.

Ação: participe ativamente em listas e fóruns de discussão de plataformas ou linguagens, como o Tectura, o GUJ ou o guru-sp.

As chances de outras empresas e desenvolvedores terem passado pelos mesmos problemas que nós em algum momento no passado é muito grande. Em toda singularidade de nossos projetos, a similaridade é muito grande.

Em casos pequenos como uma mensagem de erro jamais vista, buscadores são seus amigos, como quando procuramos no google entre as páginas do brasil a mensagem exata de erro “java.lang.IllegalStateException: Response already committed”:

Buscando por uma exception no google entre as páginas do Brasil: ajude a comunidade local a se desenvolver.

Em casos em que não encontrar publicada a resposta para sua pergunta, não deixe de aproveitar para colaborar: compartilhe suas dúvidas e soluções.

Como professores, sabemos que escrever a dúvida ajuda no processo do desenvolvedor entender o seu próprio problema. Ajuda a expressar aos outros um conceito e problema abstrato: algo que requer exercício para dominar.

Quando tentamos explicar o que está ocorrendo conosco para terceiros somos obrigados a pensar nele com mais calma do que o momento de estresse no qual estamos tentando as soluções.

Ao mesmo tempo ajudar outros a resolverem problemas facilita o processo de assentamento do aprendizado uma vez que o processo de explicação exige uma estruturação maior do que foi aprendido. Criar um blog público sobre tópicos do desenvolvimento dentro da empresa e, principalmente no início, incentive a criação de um posts regulares até o momento em que compartilhar as experiências se torne algo natural.

Utilizar os fóruns para compartilhar as idéias, começando novas threads como no caso do Tectura, é um exercício ainda melhor onde não só doamos parte de nosso conhecimento para um mercado de maior qualidade mas também aumentamos nossa capacidade de expressar nossas idéias.

Se o assunto for grande o suficiente, considere escrever para as revistas da área, sites de notícias ou apresentar em grupos de usuários e eventos.

Prática: abra mão de começar pela solução mais elegante

Sintoma: um desenvolvedor começa a implementar uma funcionalidade e já no início, em algo simples e que resolveria o problema de maneira elegante, está com problemas em algo pequeno e aparentemente ilógico, que deveria funcionar. Por esse motivo a equipe não conseguem continuar com a funcionalidade, com a qual se debatem durante algumas horas.

Ação: deixe de lado a solução mais elegante temporariamente. Se possível siga a prática de baby steps. Procure ajuda em um fórum ou lista de discussão, e implemente uma solução mais simples e básica enquanto isso.

Se o desenvolvedor julga a solução daquele trecho de código algo simples e perde muito tempo para implementar, temos um indicador de um de dois possíveis motivos:

a) se a solução era tão simples quanto imaginado, ela não deveria ter demorado tanto tempo, portanto a solução não é tão simples assim: abra mão dela e implemente uma mais simples

b) com o cansaço mental em cima do problema, fica difícil ver um erro pequeno e geralmente bobo que impede o correto funcionamento.

Independente de qual dos dois for o problema, compartilhe ele de maneira assíncrona – lista ou fórum – com outros que estão com a cabeça fresca e não viciada no problema.

Listas e fóruns são úteis para buscar e discutir abordagens.

As metodologias ágeis deixam claro que tentar lançar o produto perfeito já na sua primeira versão é algo extremamente difícil e penoso. O mesmo é aceito amplamente para o design da aplicação, mas ainda temos dificuldade de aceitá-lo para qualquer pedaço de código, o baby step.

Duke Nuke Forever: em busca da qualidade técnica máxima

Praticar dojos também ajuda a não ficar impedido nesses instantes e evitar o desperdício uma vez que a prática de baby steps é reforçada o tempo todo.

Podemos buscar a perfeição técnica e de produto, mas não devemos começar com ela: alcança-la é um processo.

Prática: faça revisões arquiteturais regularmente

Sintoma: durante o desenvolvimento de um sistema, a equipe percebe a necessidade de mudar algum aspecto arquitetural. Como a arquitetura é a parte mais difícil de se mudar no software, o custo atrelado também é alto. Após o término do projeto, descobre-se que outras equipes já haviam passado por problemas semelhantes e sabiam que a primeira alternativa era ruim para o sistema.

Ação: sempre que um projeto é concluído, aproveite o espaço de almoço de um dia da semana seguinte para apresentar a evolução do sistema e da arquitetura para todos os interessados.

Momento de descontração.

A revisão não é um momento de busca de aprovação, mas de compartilhar os problemas de alto nível passados pela equipe, por exemplo:

a) entre as 3 ferramentas que suportam serialização em Ruby que utilizamos durante os últimos 6 meses, quais os problemas que cada uma apresentou

b) não era esperado mas a adoção de um estilo arquitetural determinado implicou na perda de escalabilidade

c) a atualização de uma biblioteca após o primeiro release foi compensada na produtividade da equipe após 3 meses, ou simplesmente não compensou e voltamos a utilizar a antiga

d) a adoção da prática de deploy contínuo permitiu disponibilizar 30 novas features por mês para os clientes

Pipeline de deploy contínuo existente desde 2008

A revisão arquitetural permite que o conhecimento adquirido em projetos anteriores possa ser reutilizado em projetos posteriores, uma propriedade coletiva – a arquitetura ou até mesmo o processo – assim como a prática de programação pareada faz o mesmo com menor granularidade: o código.

Em projetos de longa duração é natural que as evoluções continuem acontecendo, portanto faça apresentações regularmente das mudanças arquiteturais.

Prática: Evite adivinhar, faça o que é esperado

Sintoma: frente a uma duas possibilidades que o cliente não deixou claro, é escolhido um caminho e frequentemente descobre-se ser o errado.

Após a entrega de uma funcionalidade, é o cliente quem testará, aprovará e utilizará a mesma no dia a dia. Uma vez que é difícil nos colocarmos em seus pés e pensarmos como eles, assumir a resposta de uma dúvida como a provável escolha do cliente é um risco muito alto que corremos. Por exemplo:

Para integrar com o sistema de billing, é necessário aceitarmos cartões de crédito, débito ou vale?
Em um caso, a resposta é assíncrona, no outro, síncrona.

O time deve evitar assumir respostas: procure o cliente pessoalmente e faça a pergunta, somente então continue a criação da funcionalidade pelo caminho que o cliente pretende utilizar.

Caso ele esteja indisponível, envie um email para uma lista interna. Durante a espera pela resposta sobre qual caminho seguir em determinada história, evite cruzar a linha da certeza e iniciar a parte da história que envolve um “chute”, principalmente quando mudar entre o escolhido pelo time e as outras opções é custoso para o projeto.

Ao invés da adivinhação, prefira começar uma história nova. Quando terminar essa segunda, analise então se a história parada já possui resposta, se o impedimento foi removido ou se deve continuar com uma terceira história.

Caso costume do cliente demorar pouco tempo para responder, por exemplo vinte minutos, ao invés de começar uma nova história, utilize o tempo para melhorar a qualidade do código, refatorando o mesmo.

A resposta poderá vir na forma de um feedback inicial, somente para permitir o andamento da história, até o momento que o responsável estiver livre para a conversa frente a frente, por exemplo:

Tenho certeza que aceitaremos cartões de débito mas não sei sobre crédito ainda.

Uma resposta final e direta também permite a continuação da história.

Outra possível resposta é o cancelamento temporário da história por diversos motivos, como quando o cliente não possuir a informação necessária e prefere postergá-la, outro sistema não está ainda pronto ou o cliente decidir que a mesma deixou de fazer sentido, por exemplo:

A equipe financeira ainda não fechou o contrato com as representantes dos cartões.
Precisamos esperar a resposta para continuar esse trabalho.

Em qualquer uma das finalizações, evitamos adivinhar e durante todo o tempo a equipe entregou valor ao projeto: nem ficou parada nem foi para o caminho errado.

Kanban Yoshima

Nessa apresentação o Rodrigo Yoshima apresentou o Kanban como ele se encaixa no quadro geral das metodologias ágeis que utilizamos hoje em dia.

O vídeo foi gravado durante o evento da Noite Ágil na Caelum em São Paulo.

Deploy Contínuo – Entrega contínua de valor

Desde 2005 ajudo com o desenvolvimento de um produto interno que teve sua segunda versão criada em 2008. Até então utilizávamos práticas de extreme programming, como programação pareada, testes, integração contínua e build automatizado.

Entre 2008 e 2009, tomamos o processo de deploy parcialmente automatizado e levamos a seus extremos. Construimos passo a passo um ambiente de produção que pode ser atualizado a qualquer instante para uma versão nova, além do processo de rollback também ser efetuado de maneira simples.

Evolução do banco de dados, testes de integração, testes rodando em paralelo e testes de end-to-end rodados na Cloud são algumas das práticas que adotamos e que apresentarei nos próximos posts, passo a passo.

Tudo isso não aconteceu do dia para a noite em um projeto que já existia e possuia código legado, mas com o passar do tempo implementamos todos esses passos, com uma equipe que vivia em alteração. Agora já vemos os frutos dentro da empresa: uma nova equipe colocou no ar processo semelhante em menos de 1 mês em um projeto novo, e a repetição desse processo nos mostra que não só sites simples são capazes de efetuar deploy contínuo.

O vídeo a seguir é uma visão geral do que é o deploy contínuo e onde chegaremos com os posts que virão:

Noite Ágil – André Pantalião

Mais um vídeo da Noite Ágil já está disponível. Dessa vez André Pantalião apresenta os problemas enfrentados, resolvidos e em aberto que encontraram ao implantar agile em sua equipe:

Agilidade no mundo real: Brasil 2010

Semana passada aconteceu o Agile Brazil 2010 em Porto Alegre.

O evento trouxe especialistas e relatos de experiências de todos os cantos do Brasil para mostrar o que está acontecendo com o mercado e o futuro caminho a ser trilhado.

A Cecilia Fernandes e eu mostramos como a remoção de práticas do Scrum em favor a princípios do Lean acabaram por tornar uma das equipes internas mais produtiva e capaz de entregar ainda mais valor. Alguns sugerem que chamemos o que fazemos nessa equipe (e em mais uma, menor, de 2 pessoas) de Kanban, e acredito que esteja bem próximo, mas prefiro me segurar ao lema de não nos atrelar a um método específico, mas sim aos princípios.

Em breve algumas palestras e entrevistas estarão online no site do infoq, no blog da Caelum e por aqui.

Como empresa de treinamento é fundamental para nós tentarmos novos caminhos antecipadamente e esses 2 anos de mudanças, idas e vindas de scrum e lean, lean e scrum, além da onipresença de práticas do xp, é o que faz tudo valer a pena.

A seguir, algumas conversas rápidas com o Rafael Rosa, Lucas Cavalcanti e Philip Calçado durante o evento:

Restrições são boas mas restrições são ruins

Junto com a Cecilia Fernandes, semana passada tive a oportunidade de apresentar nossa experiência com lean, o que aprendemos, as dificuldades e as vantagens.

A idéia foi demonstrar como as restrições eram vistas muito tempo atrás no desenvolvimento de software, como quebramos ela ao criar nossos próprios métodos “unified”, como adotamos agile através de xp e scrum e quebramos essas restrições novamente através de Lean. O ponto chave está na regra de que agilidade se baseia na inspeção e adaptação para atingir um objetivo, inclusive do próprio método.

No espírito da noite ágil, proposta pelo André Pantalião, a realidade de algumas equipes foram demonstradas e discutidas, junto com suas visões e problemas. Foi uma ótima oportunidade para muita troca de informações e discussão sobre os assuntos.

Em breve teremos outro encontro da noite ágil em São Paulo, anunciaremos nas listas de agile e no meu twitter.

Dois vídeos já estão disponíveis, “Restrições são boas mas restrições são ruins” e “O papel de QA em equipes ágeis”, incluindo as sessões de discussões e conversas logo após as mesmas:

Em breve teremos as outras duas apresentações online também.

Post no blog da caelum: evite tantas reuniões

Continuando a série de problemas práticos encontrados na maneira de
pensar quando adotamos metodologias ágeis, uma situação que afeta
muito a produtividade de Product Owners e Scrum Masters (ou
líderes/papéis similares em qualquer metodologia) é a falta de
produtividade dos dois devido a quantidade de projetos que lidam.

Este post que escrevi está no blog da Caelum.