Falando sobre práticas

Hoje em dia podemos dizer que as metodologias ágeis deixaram de ser o futuro para se tornar o presente. A maioria dos escritórios com equipe de desenvolvimento utilizam testes, alguns aderem a programação em par, realizam reuniões mais curtas e mais focadas, não planejam todos as possibilidades existentes.

No entanto não é pondo dois desenvolvedores em um computador, realizando reunião em pé e tendo post-it colados na parede que fazem uma equipe ser ágil, e muito menos render como uma equipe ágil. Aplicar práticas apenas para obter resultados dificilmente vai mostrar algum benefício, pois práticas por si só não motivam pessoas.

Se sua equipe está pondo as práticas em prática mas nunca discutiu quais as motivações de utilizá-las, recomendo rever quais são os reais valores e princípios que guiam o seu time. É fácil aplicar programação em par, mesmo que não seja 100% do tempo, mas e quanto a comunicação, coragem, feedback? Alguma vez sua equipe já discutiu sobre isso? É fácil reclamar do código que algum membro da equipe e fazer piadas interna sobre isso, mas e a Propriedade Coletiva de Código? Todos deveriam ser responsáveis por todo o código, não adianta só git-blame.

Práticas

Práticas por si só são estéreis. A menos que você dê algum propósito, dado por um conjunto de valores, elas não fazem muito sentido. Programação em par, por exemplo, não faz sentido como algo para simplesmente ir fazendo.

Essa citação do grande Vinicius Teles [1], um dos responsáveis pela disseminação do XP no Brasil, define bem a importância dos valores e princípios defendidos pelo XP. Até mesmo uma prática bem concreta, como Programação em Par, pode prejudicar o projeto caso não tenha comunicação ou compartilhamento de conhecimento.

Segundo a wikipedia [2] Prática é a realização de uma teoria, então todas as práticas possuem uma teoria que as sustentam. A vantagem da formalização da teoria em prática é que fica fácil disseminar e aplicar o pensamento ágil em vários cenários, dando à equipe algo concreto para seguir e adotar. As práticas mostram um caminho em direção ao pensamento ágil.

Outro ponto extremamente importante quando se fala sobre práticas é o contexto. Assim como quando se fala de Padrões de Projeto, o contexto pode tornar a aplicação da prática impossível. Por exemplo, uma equipe de dois ou três desenvolvedores talvez não se beneficie tanto de uma reunião diária quanto uma equipe de 10 pessoas. Provavelmente a pequena equipe já se comunique o suficiente durante o dia para não precisar de uma stand-up.

Adaptando práticas

Aplicar práticas em uma equipe sem valores pode ser muito prejudicial, no entanto o outro extremo também é possível. Equipes que realmente acreditam nos valores e princípios acabam por perceber que o contexto não é exatamente o ideal e realizam alterações na maneira trivial da aplicação das práticas, adaptando ao seu contexto.

Um “Modelo de Maturidade XP” que eu vi pela primeira vez por Klaus Wuestefeld, e que eu acredito e defendo é:

Nível 1. Usa todas as práticas
Nível 2. Adapta as práticas
Nível 3. Faz qualquer coisa que funcione

No livro The Art of Agile Development [3], Shore e Warden alertam para o fato de não criar sua própria metodologia quando se está iniciando a adoção de Métodos Ágeis. No começo realmente seguir “by the book” é a melhor maneira de testar se, no seu contexto, a metodologia vai trazer um benefício real.

Depois é preciso mover para o segundo nível. As pessoas são diferentes, não adianta empurrar a prática goela a baixo. Se alguém não gosta de Programar em Par, tente outras alternativas, como revisão de código. Nesse ponto o livro de Shore e Warden é excelente, pois discute várias práticas ágeis e no final apresenta possíveis alternativas para quando não é possível aplicá-las. Com o tempo a sua equipe terá sua versão customizada da metodologia.

Faça qualquer coisa que funcione!

Mas antes tenha certeza de que sua equipe não tem o contexto ideal para aplicação de algumas práticas. Antes de chegar nesse nível lembre dos outros dois. Criar novos métodos exige muita maturidade e coragem da equipe, mas podem trazer um valor que não está descrito em nenhuma palestra ou livro. Se todos estão confiantes em tentar algo novo, vá em frente. E se o resultado for bom (ou não) compartilhe! 🙂

Nos próximos posts eu vou tentar falar um pouco mais sobre algumas práticas que são pouco discutidas pela comunidade, como Trabalho Energizado, Retrospectiva, Sentar Junto, mas que fazem uma enorme diferença na produtividade da equipe.

Referências:

[1] http://improveit.com.br/xp/praticas
[2] http://pt.wikipedia.org/wiki/Prática
[3] The art of agile development, James Shore e Shane Warden. O’Reilly, 2008.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s