Metodologias Ágeis de Desenvolvimento (Locaweb)

Obie Fernandez falou na sua palestra no Rails Summit Latin America 2008 sobre porque pareamento é, no mínimo, tão produtivo quanto trabalhar sozinho:

Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

Para ver a transcrição completa da apresentação, acesse o blog do Sylvestre Mergulhão.

Existem vários estudos científicos sobre pareamento. Uma das mais conhecidas estudiosas sobre o assunto é a Laurie Willians. Veja um vídeo que ela fez para mostrar a estudantes as vantagens de programação em pares:

Por meio de um pingback que cita o meu primeiro texto aqui nesse blog, cheguei no post Metodologia: Cascata x Ágil que tem um vídeo bacana comparando metodologia de desenvolvimento em cascata e as metodologias de desenvolvimento ágil. Pode ser uma boa ferramenta de aprensentação das metodologias ágeis:

Quando lemos sobre como funciona a colaboração e o auto-gerenciamento em times que adotaram metodologias ágeis, sobre como tudo funciona de forma democrática, ficamos com a impressão que os desenvolvedores foram os primeiros a abraçar esses conceitos e que o difícil foi fazer a alta gerência aceitar.

Paul Glen, um consultor sobre liderança de geeks que disponibiliza vários artigos sobre o tema, escreveu um artigo entitulado “Sometimes It Takes a Tyrant to Support Collaboration” onde ele explica que muitas vezes a colaboração precisa ser defendida pelo líder em função de alguns tipos de comportamentos que são prejudiciais ao grupo. Ele dá também algumas formas de lidar com esse tipo de comportamento.

Eu gostaria de ir um pouco além e escrever sobre o que, ao meu ver, seriam as causas desses comportamentos inadequados que podem por em risco a colaboração em um time que adotou metodologias ágeis.

Há dois aspectos do trabalho de desenvolvimento de sistemas não colaborativo que tenho visto como sendo as raízes desses comportamentos inadequados:

• falsa sensação de poder: o trabalho técnico isolado dá uma falsa sensação de poder. Se somente uma pessoa sabe fazer determinado trabalho técnico, ela começa a se sentir indispensável e acredita que seu emprego está garantido. Por outro lado, gerentes não gostam de se sentir reféns. É natural que o gerente queira que mais pessoas conheçam o trabalho de outras pessoas do time para que, na ausência de uma dessas pessoas, o time não fique capenga. As metodologias ágeis pressupõem a colaboração, chegando ao ponto de usar a programação pareada. Isso é um risco para aqueles que acham que o fato de só eles saberem determinada parte do sistema é uma garantia de emprego.
• deficiências escondidas: o trabalho técnico isolado dá a oportunidade de esconder deficiências. Um desenvolvedor que tenha alguma deficiência, por não ter seu código revisto por outras pessoas pode facilmente esconder suas deficiências. Esse é outro cenário que um gerente não quer ver. Deficiênciais técnicas podem ser danosas não só do ponto de vista de produtividade, ou seja, algo demorar mais para ser feito do que deveria, mas também do ponto de vista de qualidade, pois código feito por desenvolvedores que escondem deficiências tem um potencial enorme de dar defeito. As metodologias ágeis, por meio da intensa colaboração que deve ser praticada, expõe as deficiências, o que também pode ser uma ameaça para alguns desenvolvedores.

Quando da implementação de metodologia ágil, pode acontecer de uma ou mais pessoas do time se sentirem ameaçadas pelos efeitos da colaboração em função dos aspectos acima e, numa situação como essa, acabarem optando por procurar outro emprego. Esse é um risco conhecido. Ken Schwaber, um dos criadores do Scrum, menciona que é esperado até 20% de turn over quando da implementação de metodologias ágeis. Ele também menciona que até 40% da gerência pode ir embora. Comentarei sobre o que muda na vida de um gerente quando o time adota metodologias ágeis em breve.

Por isso, apesar de soar estranho, às vezes é mesmo necessário ser um ditador para garantir que a colaboração prevaleça em seu time.

Dica do Marty Cagan, da SVPG:

http://www.svpg.com/resources/Agile/Process.html

Talvez você esteja curioso: afinal essas tais de “metologias ágeis de desenvolvimento” funcionam mesmo? Existe alguma pesquisa falando da taxa de sucesso de adoção dessas metodologias? InfoQ.com, uma comunidade online independente focada em mudanças e inovações em desenvolvimento de software, publicou recentemente os resultados da versão de 2008 da Pesquisa de Adoção Ágil.

Essa pesquisa foi feita em 642 empresas e mostra que a taxa de adoção de metodologias ágeis é de 69%. Há vários outros dados interessantes como tamanho dos sprints, escalabilidade e se todos os desenvolvedores ficam no mesmo lugar.

Contudo, um dado que me chamou a atenção é a efetividade das metodologias ágeis se comparadas aos métodos tradicionais de desenvolvimento:

Os resultados acima mostram que vale a pena investir em metodologias ágeis. Todos sairão ganhando!

Agora que já sabemos o que são as metodologias e vamos começar a aprender seus detalhes, pode acontecer de sermos pegos de surpresa pelo nosso chefe, ou mesmo por um cliente, nos perguntando “mas o que são essas tais de metodologias ágeis que vocês tanto falam?”.

No blog da Agile Chronicles eles nos oferecem um discurso de elevador para ajudar a responder. Suponha que você esteja pegando um elevador e tenha que explicar para alguém durante essa viagem de elevador o que são as metodologias ágeis. Deve dar uns 30 segundos para toda a explicação.

Então aqui vai:

Metodologias Ágeis de Desenvolvimento são basicamente 3 coisas:

1. um conjunto de melhores práticas de engenharia de software que permitem a entrega de software de alta qualidade;
2. um processo de gestão de projetos que encorajam avaliação e adaptação frequente;
3. uma filosofia de liderança que encoraja o trabalho em equipe e a responsabilidade do time.

O sucesso na economia atual requer que respondamos sempre prontamente às mudanças de mercado. Os processo ágeis permitem que nossas equipes atendam às demandas de nossos clientes, demandas essas que sempre sofrem mudanças, ao mesmo tempo que cria um ambiente onde os melhores desenvolvedores querem trabalhar.

A Locaweb vem usando metodologias ágeis de desenvolvimento há quase um ano e o resultado tem sido tão positivo que decidimos compartilhar nosso conhecimento e nossas experiências com desenvolvimento ágil com todos os desenvolvedores parceiros da Locaweb.

Vamos trazer periodicamente dicas e informações sobre metodologias ágeis de desenvolvimento, que hoje são usadas por empresas de todo o mundo, sempre com muito sucesso. Algumas empresas adeptas à agilidade são Yahoo, eBay, Amazon, entre outras, além de inúmeras empresas de desenvolvimento que fazem sistemas sob medida para clientes. Aliás, as metodologias ágeis de desenvolvimento nasceram nesse ambiente de desenvolvimento de sistema sob medida e só depois foram adaptadas para empresas que desenvolvem sistemas para serem usados por muitas pessoas, como Yahoo, eBay, Amazon e a própria Locaweb.

Nesse primeiro post vamos expor as razões que podem levar alguém a pensar em mudar sua metodologia de desenvolvimento.

As metodologias ágeis são uma possível resposta a algumas ânsias muito comuns em projetos de desenvolvimento de sistemas e sites:

• ao apresentar o sistema pronto para o cliente ele diz que não era exatamente isso o que ele tinha em mente;
• cliente muda os requisitos várias vezes durante o projeto;
• cliente pergunta toda semana quanto tempo falta para ficar pronto;
• para cumprir prazo, só cortando funcionalidades;
• para cumprir o prazo, só sacrificando a qualidade.

Em um projeto tradicional de desenvolvimento de sistemas temos 5 grandes fases:

• Definição: nessa fase são definidos os requisitos do projeto. Normalmente isso é feito a partir de conversas com o cliente para levantar todas as suas necessidades;
• Projeto: com os requisitos em mãos, começamos a desenhar as telas, as estruturas de dados e os planos de testes;
• Codificação: é a fase “mão na massa”, quando a programação é de fato feita;
• Testes: para garantir que a codificação tenha sido feita apropriadamente;
• Implementação: é o momento de colocar o sistema em produção.

Essa metodologia de desenvolvimento é conhecida como “cascata” (waterfall em inglês), pois cada fase depende da fase anterior para acontecer. Uma conseqüência desse método de desenvolvimento em “cascata” é que quanto mais avançado estiver o desenvolvimento de sistema, maior será o custo de alterar o projeto, custo esse que pode vir de diferentes formas, tais como corte de funcionalidades, corte de qualidade de desenvolvimento, aumento de prazos e conseqüente aumento de valores.

Mas qual é o problema com as metodologias tradicionais de desenvolvimento?

Elas supõem que o futuro é bem definido e conhecido e, consequentemente, que os requisitos não mudarão ao longo da vida do projeto. Os projetos de desenvolvimento de sistemas e sites podem levar meses e é difícil garantir que nada mude nesse período em relação aos requisitos que levaram à necessidade desse sistema ou site.

Quando se supõe que o futuro é bem definido e que os requisitos não mudarão, não haverá necessidade de interação entre o cliente e a equipe de desenvolvimento. Contudo, sempre pode acontecer de o cliente aparecer com uma necessidade de mudança do projeto e , após isso acontecer algumas vezes, é natural implementar contratos entre cliente e desenvolvedor visando salvaguardar os requisitos. São documentos, processos e controles de horas que garantem que se algo mudar na especificação do projeto, alguém vai pagar por essa mudança, que sempre é vista como algo negativo para o projeto.

E por que tem que ser assim? Não seria possível ter um custo de mudança que não crescesse muito ao longo do projeto? Afinal, mudanças em projetos são inevitáveis pois o mundo à nossa volta está em constante mudança.

As metodologias ágeis de desenvolvimento surgiram exatamente para permitir maior flexibilidade no processo de desenvolvimento de sistemas e minimizar o custo de mudanças ao longo dos projetos.

No próximo post falaremos sobre os princípios que norteiam o desenvolvimento ágil de sistemas. Fiquem ligados!