24 Dec 2009 ruoso   » (Journeyer)

Differences between agile and traditional methods

Sorry guys, I'm having no time to translate this content, so here follows the original portuguese version, I might come back here later to translate it

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".

Syndicated 2009-11-30 15:53:28 from Daniel Ruoso

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!