La imposibilidad de predecir lo desconocido

Cumplir la fecha de fin de un proyecto seguramente sea algo accidental. Sinceramente no lo sé. No he participado en ningún proyecto (como casi todos los que estamos en desarrollo de software) en que se cumpla la planificación estimada al inicio. Es imposible predecir los que no sabemos. La estimación se basa en el conocimiento y la experiencia.

Muchas veces me han pedido estimar, por ejemplo, la fase de pruebas de un proyecto (incluso en los cuales aún no se había escrito ni la primera línea de código). Existen métodos paramétricos de estimación de software basados en puntos de función o en líneas de código que no están del todo mal, pero personalmente prefiero los métodos basados en la experiencia (o heurísticos).

Los equipos agiles se basan en el “yesterday’s weather” para estimar. Un término que existe ya desde Extreme Programming (XP) y que significa básicamente que la mejor (y más simple) predicción del tiempo que tendremos hoy es conocer que tiempo hizo ayer (la anécdota es interesante y puede encontrarse en muchos sitios en la web).

Es decir, hoy tendrás hecho tanto como lo que has hecho ayer. Si hablamos de equipos agiles debemos traducirlo en iteraciones: para la iteración actual puedes planificar tanto como lo que has planificado en la iteración anterior.

Puntualmente en SCRUM se puede medir el trabajo de cada una de los sprints (iteraciones en SCRUM). Para ello se utilizan puntos de historia. No voy a detallar en este post cómo calcularlos, pero básicamente los puntos de historia miden el trabajo que “cuesta” cada historia de usuario.

Es decir, en la planificación del sprint, el equipo de desarrollo es capaz de definir no solo “cómo” realizar el trabajo, sino “cuánto” trabajo pueden abordar en el próximo sprint en base a los anteriores. A medida que los sprints avancen, se irán obteniendo datos reales para poder medir la velocidad del equipo.

El Product Backlog tendrá la información sobre las historias de usuario pendientes de desarrollar. Si éstas historias están estimadas, la cantidad de puntos de historia que restan para tener una release será un dato conocido por todos. Será posible entonces saber cuántos sprints restan para terminar el proyecto. Como los sprints (como casi todo en SCRUM) son periodos acotados en el tiempo, será posible predecir la fecha de fin de proyecto.

Y lo mejor de todo es que en ningún momento nos olvidamos de la calidad de software. Cada sprint genera un incremento de producto donde cada historia de usuario estará terminada: “done”. Y “done” (hecho) en SCRUM significa que en cada iteración se dispone de una pieza de software evolucionada que cumple no solo con los criterios de aceptación definidos por el Product Owner sino que también cumple la Definición de Hecho (DoD) compartida y generada por el equipo. Es decir, cumple con el acuerdo de todo lo que significa “terminado” para el equipo, por ejemplo:

• Unit Tests con TDD
• Revisión de código
• Pruebas funcionales
• Pruebas de rendimiento
• Test automatizados al 100%
• Integrado
• Documentado
• …

Obviamente debemos tener en cuenta algunos factores que pueden desviar la velocidad del equipo como puede ser la rotación de las personas (algo que no debería suceder, pero pasa….). Y por otro lado, la evolución propia del proyecto que puede (y debe) modificar, eliminar, agregar, dividir, unir, en definitiva “refinar” las historias de usuario de acuerdo al feedback obtenido en cada sprint.

Pero incluso teniendo en cuenta éstas variables que afectan a la estimación, la predicción basada en el conocimiento y la experiencia será la más ajustada. Y, ¿qué estimamos en el primer sprint? En SCRUM se realiza lo que se denomina inception, o sprint 0 (cero). Aquí no se dispone de experiencia pero sí de información y conocimiento. Se debe tener una visión del producto que se desea construir (y del presupuesto) para generar un roadmap. Este roadmap contendrá 3 datos fundamentales:

• Features principales del producto.
• Numero de versión de reléase de cada feature.
• Trimestre en que se planifica la reléase (sí, trimestre).

En los modelos de desarrollo tradicionales, la dificultad en la estimación es mucho mayor, ya que debemos estimar cada fase al inicio. Insisto en que lo mejor es basarse en la experiencia, y en este caso, si disponemos de proyectos anteriores de similares características podemos pensar en realizar alguna predicción, pero si no disponemos del conocimiento y la experiencia… ¿qué hacemos? La respuesta está en ser ágiles.
Después de todo, una de las causas por las que surge el desarrollo ágil es justamente la imposibilidad de cumplir las fechas de fin de proyecto.

Predecir es la clave hoy en día, ¿y cómo predecimos en SOGETI? Mediante el conocimiento y la experiencia que nos brinda la inteligencia artificial aplicada a la Software Quality Assurance y que se llama WiseQA. Puedes echar un vistazo al post de nuestro compañero Albert Tort para conocer más sobre esta solución: Somos predictivos. Somos “Wise”. Sí, “guays”

Autor | Romina Gioacchini – Agile & Innovation Solutions Specialist