viernes, 4 de julio de 2014

¿Se pueden calcular las horas/hombre de un proyecto bajo Scrum y calcular el precio final?

Scrum es un marco ágil y flexible para trabajar en entornos inestables o entornos con una alta variabilidad como suelen ser los proyectos de TI. Se aplica en escenarios donde el cliente conoce la visión de su producto pero no puede detallar cómo será el producto final, por tanto no tiene sentido hablar de un proyecto cerrado en alcance que se pueda evaluar en horas.

Bajo Scrum se va iterando y dirigiendo el proyecto por aquellas funcionalidades donde el valor de negocio es máximo en cada momento. Una y otra vez se ajusta el proyecto a la experiencia aprendida adquirida, a las variaciones del mercado y a las oportunidades emergentes, en definitiva lo que hace que la compañía sea más competitiva. El final del proyecto lo marca el cliente con la limitación de su presupuesto. Por tanto, lo que se fija en un proyecto bajo Scrum son los costes, y estos a su vez, fijan el tiempo, ya que un sprint es valorable (los recursos y el tiempo son conocidos). Se podrán hacer tantos sprints como lo permita el presupuesto.

En proyectos ágiles se utiliza lo que se denomina la contratación ágil, donde el cliente lo que contrata es un número de sprints. Una imagen que ayuda a comprender mejor este concepto es la imagen del triángulo de hierro, que muestra metodología tradicional (cascada) versus ágil.
El triángulo de hierro
En las metodologías tradicionales lo único que es fijo es el alcance, y aunque se establezcan el tiempo y el precio en el contrato, el tiempo siempre es estimado y por tanto los costes también lo son.

En los proyectos ágiles tanto el tiempo como los costes son fijos y lo que es variable es el alcance. Esto puede dar a entender que puede que no se cumpla con toda la funcionalidad, pero si se prioriza correctamente, las funcionalidades más importantes, incluso las sobrevenidas por variaciones del mercado, estarán completas y funcionando correctamente, se garantiza la construcción del mejor producto para un presupuesto dado.


Podemos decir que los proyectos bajo esta perspectiva son proyectos que están time-boxed. Imaginemos que a un departamento determinado se le aprueba un proyecto cuyo límite es una duración de 6 meses, solo puede construir durante esos 6 meses. Ese enfoque tiene consecuencias deseables directas, dado el tiempo limitado el departamento, o Propietario del Producto del mismo, sentirán la presión del tiempo limitado, se espabilaran para liderar su proyecto y priorizarán las funcionalidades que deseen construir guiados por valor de negocio

No hay comentarios:

Publicar un comentario