SCRUM: Metodologías agiles en Business Intelligence (Cap.1)

Esta serie de artículos, pretende mostrar un poco como fue mi experiencia de conversión, desde el manejo tradicional de los proyectos usando el típico Waterfall (o cascada) a una manera que me resultó muy eficaz en algunos proyectos, como es SCRUM.

¿Pero como es que se dio esta conversión?. Coincidió que en la Empresa en la que estaba (una empresa industrial), decidió encarar un proyectos de prácticas «Lean» en los procesos de las Plantas de Producción.

Como no quería ser menos, en el 2013 empecé a leer, googlear, «youtube-ar», en fin, ponerme al día con las metodologías «Lean» aplicadas al desarrollo de Sistemas, y créanme que valió la pena.

Hay muchas razones por las cuales me atrajo este tipo de metodologías, pero el hecho de pregonar la flexibilidad, la adaptación al cambio y los comentarios acerca que eran ideales para proyectos dónde los equipos son de pocos integrantes, sonó a canto de sirenas a mis oídos.

Claro, por supuesto que mantuve mi escepticismo de Ingeniero en Sistemas, formado en las metodologías tradicionales (ahora me entero que se llaman «prospectivas»), por lo que lo primero que pensé fue: esto es para los que no quieren documentar…

Pero luego de leer y ver varios videos me fui convenciendo de ciertas características que tiene Scrum que tienen mucho sentido.

Arranquemos con lo básico

Scrum es una metodología ágil. Y eso que significa, que se concentra más en que el producto sea lo que pidió el Cliente, que en los formalismos necesarios para lograrlo. Y esto es muy políticamente correcto.

En la facultad y hay mucha bibliografía que apoya este concepto, nos enseñaron que la informática necesita utilizar conceptos relacionados con la Ingeniería, tales como el estudio de factibilidad, la planificación, el diseño, la construcción y la implementación.

Fomenta la documentación de los sistemas informáticos de la misma manera que las otras ingenierías necesitan de los planos y las especificaciones para poder construir edificios, máquinas o circuitos electrónicos. En esta teoría, esta documentación (refiriendonos a los planos, maquetas, prototipos, etc.) es fundamental no solo para acordar con el cliente (o usuario) que lo que se va a fabricar es lo que se pide, sino que luego son fundamentales para revisar que el aparato / edificio o lo que sea se ajuste a dichas especificaciones.

No dá lo mismo que una pieza mecánica tenga un tamaño, dimensiones, y materiales de fabricación que tenga otras, porque luego no va a encajar o simplemente se tratará de otro objeto.

Pero, cuando hablamos de software (o sistemas informáticos), esto no se cumple de una manera tan estricta.

Si una pantalla tiene el botón redondo o cuadrado, la letra es más grande o más chica, si la funcionalidad no cumple exactamente lo que se había pactado, pero quizá permite ejecutar una acción parecida, probablemente funcione igual.

Si una interfaz devuelve los resultados que se espera, la verdad que como está programada, el lenguaje que utilice o la cantidad de lineas de código que tenga, no es tan importante. O al menos no es algo crítico.

Es quizás por esto que convence tanto la metodología Agile. En el año 2001, luego de décadas de avanzar en metodologías que acerque el producto final a lo que pide el Cliente, se reunieron en Utha (Estados Unidos) un grupo de craneos y armaron el manifiesto ágil. Que arranca por acá: