A los que se nos suele preguntar sobre las ventajas de SCRUM nos resulta a veces difícil dejar claro sus límites. Centrados como estamos en resaltar sus puntos fuertes y en ilustrar las mejoras que aporta, no debemos olvidar que SCRUM no es una solución mágica para todos los problemas que pueden sobrevenir a un equipo de desarrollo. En las propias presentaciones de SCRUM ya se menciona muchas veces que no es una bala de plata (silver bullet en inglés).
El otro día, en un curso, un alumno me preguntó varias veces sobre un problema muy habitual en el mundo de las tecnologías de la información. Qué hacer cuando se necesita determinar el coste de un proyecto que aún no ha empezado, sea porque hay que venderlo o porque nos lo pide el departamento comercial o la dirección. Proporcionar una estimación inicial del coste de un proyecto (y el compromiso que ello implica) es un tema espinoso y potencialmente muy peligroso cuando no se conoce exactamente lo que se debe realizar.
En el mundo Agile, se estima de forma iterativa y así se evita realizar todas las estimaciones al inicio del proyecto, cuando el riesgo y la incertidumbre es más alta. Porque... ¿Acaso sabemos antes de empezar un proyecto lo que se debe realizar? La respuesta es no, excepto en contadas ocasiones.
Pero, ¿Qué hacer cuando no se puede estimar de forma iterativa, cuando es imprescindible calcular esa cifra porque por ejemplo debemos hacer una oferta? ¿Cómo nos puede ayudar SCRUM en esa situación?
La respuesta no es fácil. Si se han pactado una serie de funcionalidades muy específicas que no se pueden variar y las estimaciones dadas son malas, seguiremos teniendo un problema. SCRUM no es un método de estimación, sino una metodología de desarrollo que asegura que se aporta el máximo valor al cliente a lo largo de una serie de iteraciones. En el caso de que se tenga que presentar al cliente un presupuesto cerrado, SCRUM no te ayuda a calcular el coste de la funcionalidad acordada. Ayuda a que, partiendo de ese presupuesto, se dé al cliente el máximo valor posible.
Como discutimos con mi alumno, en este caso el presupuesto es una restricción. Una restricción previa que nos determinará, por ejemplo, la duración del proyecto. A partir de dicha restricción, ofreceremos el máximo valor al cliente. Es más, gracias a la naturaleza iterativa en la que al final de cada iteración se demuestra el producto al cliente, no sólo aseguramos el máximo valor sino que el cliente puede cambiar de opinión y guiar el desarrollo.
Es importante que el cliente entienda que en ese presupuesto se pactan una serie de funcionalidades (el primer Product Backlog) y que desde el momento en que se empieza el desarrollo, puede guiar su evolución. Puesto que es el mismo cliente el que puede cambiar de opinión y sustituir funcionalidades pactadas a cambio de otras que se ha dado cuenta que son más importantes, cobra importancia que el contrato con dicho cliente permita esta forma de trabajar: un contrato Agile.
