Guia para transição ao Desenvolvimento Ágil

Visitando o InfoQ - aliás, ótimo site, assisti a uma apresentação de David Hussman e Tor Stenstad dando um overview da experiência dos dois na migração para Metodologias Ágeis.

Como está em inglês, vou colocar alguns comentários importantes sobre questões pertinentes e úteis:

Transition to Agile

Antes de mais nada, vale salientar um comentário bastante importante: "Não existem balas de prata". Se você está atrás de um checklist que o levará ao clímax do desenvolvimento de software, à panacéia de todos os males mundanos.... bem, vc está enganado...

O projeto tratado na apresentação é de uma empresa grande, segundo Tor, uma das 500 da Fortune, possuidora de um modelo tradicional de desenvolvimento baseado em RUP.

A primeira iniciativa na adoção do desenvolvimento ágil (Iniciado com um projeto piloto - MUITO IMPORTANTE) foi tentar remover mitos relacionados ao Desenvolvimento Ágil, já que muitas pessoas pensam ainda que estejamos tratando de Code and Fix. Inclusive os programadores precisam entender que nossa postura não vai remover todo e qualquer processo dentro da empresa. Para isso, é importante a figura de alguém que já conheça do assunto, com experiência prática em XP, Lean, SCRUM, etc. Assim, evitaremos cair em diversos problemas corriqueiros dentro da implementação de processos de desenvolvimento. Listinha didática:

• Encontre um mentor (pode chamá-lo de consultor, nerd especializado, empresa parceira, programador mais espertinho)


• Remova os mitos


• Ajude a educar as pessoas


• Encontre um projeto piloto. NUNCA tente implacar um processo na empresa toda de uma vez

IMPORTANTE: Escolha a dedo as práticas que você deseja implementar. Não assuma a responsabilidade de implantar todas as técnicas de XP de uma vez só... vai ser problema na certa.

Como proceder:

• Compreenda o ambiente em que a empresa está inserida. É muito importante identificar até onde você pode alcançar no processo. Converse com as pessoas, descubra como elas trabalham. Somente assim essa mudança será o mais indolor possível.
• Começe atacando problemas pontuais, mas pense grande. Tente diminuir o tamanho das iterações, inicie uma conversa sobre teste de software, fale sobre TDD... aos poucos, com a intimidade que as pessoas ganham com a prática, desenvolva novos desafios para a equipe, implante uma nova prática, e construa um ambiente propício a esse aprendizado. Importante é verificar a forma que sua empresa é construida, e assim determinar quais práticas utilizar.
  
• Compartilhe a visão do projeto com TODOS os comprometidos. Muito importante que tanto a área de produto quanto teste, desenvolvimento e vendas tenham a mesma idéia dos objetivos que o projeto se propõe.
• Crie ambientes informativos para todos tenham acesso ao que ocorre no projeto. (Veja a discussão na lista xpRio)
  

Um termo interessante abordado: Living plan
O conceito faz referência à criação de um planejamento (nao um plano) que evolui à medida que o projeto progride no tempo. Este living plan emprega conceitos como:

• Crie um backlog para que você possa ter uma visão clara do quê deve ser implementado de uma forma macro
• Valorize as pessoas! Crie um ambiente onde as pessoas possam falar e ser ouvidas, e que sugestões e problemas identificados por membros de equipe tenham peso real na tomada de decisão
  
• Dimiua o tamanho das iterações para ter o feedback mais rápido de onde exatamente você está
• Utilize o desenvolvimento iterativo
• Faça com que os clientes participem do projeto. Torne-os engajados.
• Defina o que é uma funcionalidade terminada: encontre o real significado de término de uma funcionalidade. Se as premissas da empresa supõe a entrega de documentos, coloque-os na estimativa.
  

Achei interessante a visão que eles deram sobre o cliente:
Qual cliente não gostará de se envolver no desenvolvimento ao descobrir que ele é o responsável por tomar decisões de negócio para o projeto? Imagine-se com o poder de mudar o rumo de todo o projeto a cada mês/semana? Você não gostaria de participar?

Ponto importante: Tenha a coragem de refer o planejamento e todo o processo de desnevolvimento se algo estiver errado. Isto mesmo, utilize o Burndown Chart para a tomada de decisão. Se o gráfico lhe diz que algo está errado, MUDE!

Dicas para líderes

• Participe das reuniões diárias
• Converse com as pessoas, não tenha medo de receber críticas. Demonstre respeito pela opinião das pessoas da equipe e assuma a responsabilidade de mudar, caso algo esteja errado no que você estiver fazendo
• Crie uma comunidade dentro de sua empresa, fomente discussões, práticas, palestras. (Por que não organizar uma sessão de CodingDojo em sua empresa?)

Com vocês, o vídeo (desculpem... nao consegui deixar a apresentação "embebed" no meu site):



Assista a palestra na integra: http://www.infoq.com/presentations/agile-transition-hussman-stenstad