Diferenças entre métodos ágeis e tradicionais

| No Comments | No TrackBacks

Hoje recebi um link para um TCC que comparava PMBoK com Scrum...

É interessante esse tema, uma vez que venho debatendo extensamente sobre ele em ambiente de trabalho. Ainda assim, acredito que o TCC em questão deixa de lado um aspecto fundamental na diferença entre as duas metodologias (não, não li tudo, mas foquei principalmente no capítulo que compara e no que tenta compatibilizar).

Acredito que o primeiro equívoco é considerar o PMBoK um "método de desenvolvimento". O PMBoK é simplesmente uma base de conhecimento que estabelece uma nomenclatura e mapeia um conjunto base de processos a serem utilizados no gerenciamento de projetos. Como lá pela página 70 ele mesmo mostra, é completamente possível você aderir ao Scrum enquanto utiliza a nomenclatura e a base de processos do PMBoK.


No entanto entendo que esse não é o fim do debate, uma vez que, na verdade, está-se aqui tentando fazer uma oposição à gestão de projetos tradicional vs a gestão de projetos ágil. Isso nos leva a duas perguntas:


1) O que diferencia os métodos tradicionais dos ágeis?

2) Quando a escolha de um ou outro é mais acertada?


Para a pergunta 1, existem dois pontos, que no meu entender são chaves para mapear a diferença entre os dois projetos.


1) Em métodos tradicionais, entende-se que o projeto tem um produto que só faz sentido na sua totalidade, mesmo que existam alterações no escopo (devidamente documentadas e aprovadas), o projeto só é bem sucedido no final. Em métodos ágeis, parte-se do princípio que um conjunto mínimo das funcionalidades já irá ser de valor para o cliente, de forma que, mesmo que o projeto seja descontinuado depois de um tempo, o cliente já recebeu um valor efetivo. No entanto, é importante entender que não se trata aqui de ter ou não entregas intermediárias, mas sim trata-se de um sucesso progressivo ou se só é sucesso no final.


2) Em métodos ágeis, a medida das entregas está 100% sobre o trabalho realizado, quem faz os orçamentos é o desenvolvedor e o gerente negocia com o cliente *quais* atividades serão desenvolvidas agora, mas a eficiência da equipe não é propriamente um centro da discussão. Isso é importante porque o cliente não tem, nas metodologias ágeis, uma visão completa de quanto vai custar o produto final, enquanto em métodos tradicionais a medida das entregas está 100% sobre o escopo especificado, e, em geral, o valor total do investimento também é conhecido à princípio, de forma que o papel do cliente é validar o escopo, equanto a eficiência da equipe é um problema única e exclusivamente do próprio laboratório.


Acredito que esses dois pontos nos levam para uma solução interessante para a segunda pergunta, vou tentar resumir quais são, na minha opinião, as linhas de corte sobre quando adotar métodos ágeis e quando adotar métodos tradicionais.


1) Se o projeto tem um escopo fechado à princípio e, na visão do cliente, não existe sucesso a não ser que o produto esteja 100% entregue, ir para métodos ágeis significa que você está simplesmente ignorando os riscos do projeto, uma vez que você não consegue ter uma visão clara das linhas de base de escopo e cronograma.


2) Se a remuneração do projeto (mesmo que estejamos falando apenas em termos conceituais) estiver ligada a um escopo previamente planejado em oposição à remuneração pelo trabalho efetivamente realizado (incluindo o custo dos re-trabalhos), ir para métodos ágeis significa que você estará efetivamente dando um tiro no pé, pois você tem um montante a receber para entregar um conjunto específico de funcionalidades e não vai receber a mais só porque você entregou em versões sucessivas que atendem melhor a necessidade real do cliente.


Alguns exemplos onde métodos ágeis dificilmente fazem sentido, imnsho:


1) atendimento a um edital de licitação ou um edital de seleção de uma fonte qualquer de financiamento. Em geral o termo de referência - sejam submetidos por você ou definidos pelo licitante - define um escopo fechado.


2) entregas de primeiras versões de software. Em geral conhece-se um conjunto mínimo de funcionalidades necessária para aquele software ser útil e, em geral, esse escopo mínimo normalmente representa uma quantidade significativa de trabalho e normalmente a expectativa é que os recursos disponíveis para essa primeira entrega sejam definidos à priori.


Em resumo, se eu tivesse que definir a diferença entre os métodos tradicionais e os métodos ágeis em uma frase, eu diria:


"Nos métodos tradicionais o risco deve ser gerenciado pela equipe de desenvolvimento, nos métodos ágeis é pelo cliente".

No TrackBacks

TrackBack URL: http://daniel.ruoso.com/cgi-bin/mt/mt-tb.cgi/201

Leave a comment

About this Entry

This page contains a single entry by Daniel Ruoso published on November 30, 2009 4:51 PM.

PMBoK was the previous entry in this blog.

Relógio Analógico em ASCII is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.