Hola de nuevo,

Después de muchos meses de ausencia, reemprendo la actividad con esta entrada, que quiere ser la primera de una serie sobre el desarrollo de proyectos de inteligencia de negocio (desde ahora BI) mediante la metodología SCRUM.

La metodología SCRUM se ha erigido, en los últimos tiempos, como una especie de estándar hacia el que converger en el universo del desarrollo de software. Pero dada la enorme carga de sentido común, experiencia aplicada y sinnúmero de equipos que la ponen en práctica, ha trascendido el mundo del software para adentrarse en multiplicidad de facetas de la vida. No es extraño leer o escuchar que tal o cual empresa de vayaustedasaberqué está aplicando metodología ágil – SCRUM, preferentemente – para sus proyectos. Incluso autónomos y microempresas han empezado a adaptar esta metodología para sus quehaceres diarios, por ejemplo.

La inteligencia de negocio no escapa a la influencia de SCRUM, incluso teniendo en cuenta las particularidades que presentan los proyectos de BI frente a los tradicionales de software ͞convencional͟.

A lo largo de la serie pretendo explicar mi experiencia en la implantación la metodología SCRUM para la gestión de los proyectos de BI: inicios, sprint 0, definición de historias de usuario, gestión del cambio...

Ya metidos en materia, me gustaría empezar por los problemas. ͞Problema͟ es un término que no gusta, pero que, sin embargo, lleva implícito que existe una solución. Si no, no sería un problema. Un proverbio chino dice: ͞Si tiene solución, ¿por qué te preocupas? Y, si no tiene solución, ¿por qué te preocupas?͟.

¿Por qué son difíciles los proyectos de BI?

Todos los proyectos presentan problemas, pero alrededor de la mitad de los proyectos de BI presentan problemas graves que pueden dar al traste con él:

1)      Subestimar la complejidad:

i)        Múltiples fuentes de datos.

ii)       Grandes volúmenes de datos.

iii)     Dependencias de calidad de los datos.

2)      Requerimientos cambiantes, desconocidos o poco explicados.

3)      Alcance excesivo desde el inicio del proyecto.

4)      Estancamiento en el proceso de desarrollo: parálisis por exceso de análisis.

5)      Desaprovechamiento de los integrantes del equipo.

6)      Falta de comunicación o entendimiento entre los patrocinadores del proyecto.

7)      Proyecto demasiado pequeño o con poca visibilidad.

Podría pensarse que la solución a cada uno de estos problemas es individual y desconectada de la solución del resto. Pero no es descabellado llegar a la conclusión de que la conexión entre las soluciones a los puntos anteriores puede encontrarse en una metodología, en un procedimiento que intente unificar la respuesta a cada problema enumerado anteriormente.

Podría plantearme no empezar ningún desarrollo sin antes no haber solucionado la calidad de los datos del entorno de pruebas o localizar exactamente los orígenes de datos. Tampoco sin tener listas la serie de tareas de las que dependen otras. No saldrás a hacer senderismo por la montaña sin haber preparado la mochila con visión, mirando lejos.

Los expertos – experto es aquella persona que ha tenido que solucionar todos los problemas sobre una cuestión concreta – en gestión de proyectos han identificado al menos esa serie de problemas que se enumeran más arriba. En la serie de entradas que empiezan aquí voy a intentar sostener que SCRUM puede ser la metodología que aúne las soluciones a aquellos puntos.

Espero que os guste.

Josep Manel Santos