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