Na formação comparar o que é comparável, mas que tenho visto pouca gente a fazê-lo de forma clara e ausenta de opinião: metodologias ágeis e as abordagem clássicas de gestão de projectos. O prof. Alexandre Rodrigues fez uma analogia não posso deixar de partilhar.
O modelos actuais da gestão de projecto, sejam clássicos (como o normativo do PMI) ou ágeis (como XP ou Scrum) assentam em quatro variáveis: âmbito, custo, tempo e qualidade. O âmbito diz o que é para fazer, o custo afirma quanto vai custar, o tempo serve para definir quando vai estar concluído e a qualidade garante o bom resultado do projecto (i.e. sem defeitos). A alteração de uma variável pode afectar as outras de formanão linear.
Numa abordagem clássica tenta-se controlar o âmbito, ajustando as outras variáveis de acordo como se pretende implementar esse mesmo âmbito. Em fase de proposta acorda-se (i.e. contractualiza-se) o valor das outras três variáveis, de acordo com uma estimativa de quanto vai custar, quando estará pronto e em com que nível de controlo de qualidade. Qualquer alteração ao âmbito requer uma alteração ao contracto. Ou seja, eu peço o orçamento a um pedreiro para me construir um muro de 1m de altura no quintal. O pedreiro diz quanto isso me vai custar, quando estará pronto e sobre que condições de supervisão. Posto isto firma-se o contracto. Se a meio de obra eu decidir que pretendo o muro com altura de 80cm, o pedreiro tem que verificar o impacto que isso tem na obra em curso e apresentar um novo orçamento. Por outro lado, se a obra se atrazar, custar mais que o previsto ou forem feitas menos ispecções (i.e. pode ter mais defeitos), o custo adicional fica a cargo do pedreiro. Pode também acabar a obra mais cedo e assim fica com mais tempo para dedicar a outras obras. Pela perspectiva das metodologias clássicas, o âmbito é fixo e o tempo vai encolhendo ou esticando conforme a execução da obra vai correndo mais depressa ou mais devagar que o esperado. Ou seja, o âmbito pode ser visto como uma caixa onde se coloca ou tira tempo.
As metodologias ágeis assentam na ideia de que o âmbito global do projecto não está fixo. Ou seja, há uma ideia inicial do que é para fazer mas assume-se que a tarefa vá sendo alterada com o decorrer do projecto. Para lidar com este problema o projecto é executado com base em iterações (i.e. sprints em eXtreme Programming). No inicio da iteração define-se um conjunto de tarefas a executar, mas estas vão alterando conforme a iteração vai correndo. Se corre melhor colocam-se mais tarefas, se pior tiram-se as de menor impacto nas regras de negócio. Pode-se até substituir tarefas se o representante do negócio assim o entender. Por exemplo, imagine-se que eu queria à mesma fazer um muro de 1m no perímetro do quintal. Eu acordava com o pedreiro uma primeira iteração em que este iria tentar completar o muro. Se a meio da iteração eu desejasse colocar uma porta de ferro em vez de uma de madeira, o pedreiro não se iria importar, mesmo que isso implicasse tirar a porta que acabou de colocar. Por outro lado, se durante a iteração o pedreiro concluísse que estava a meter menos tijolos por dia do que os inicialmente estimados (i.e. à partes do muro que passam para a próxima iterarão), eu não me importaria e aceitaria o erro na estimativa sem exigir uma alteração contractual. Seguindo a analogia da caixa, na perspectiva das metodologias ágeis o tempo é fixo e o âmbito vai encolhendo ou esticando, conforme a execução da obra vai correndo mais depressa ou mais devagar que o esperado. Ou seja, o tempo pode ser visto como uma caixa onde se coloca ou âmbito.
Há uma diferença entre as abordagens clássicas e ágeis que eu já tinha percebido. Enquanto nas abordagens clássica assume-se que o contracto assenta num projecto a custo fixo, nas abordagens ágeis assume-se um contracto a Time and Materials (não sei traduzir isto). Mas esta analogia da caixa parece-me genial. Apresenta uma nova perspectiva sobre as duas abordagens. Só por isto já valeu a formação... mas valeu também pelo resto do programa.
Abraços,
Tiago Franco
