Como se menciono anteriormente el término
SCRUM tiene su origen en el ámbito del rugby, se trata de una posi-ción entrelazada en círculo que toman los integrantes de ambos equipos.
El pro-pósito del scrum es el de reiniciar el juego, rápida, segura e imparcialmente, después de una infracción menor o de una detención.
SCRUM es una metodología que nace ajena al desarrollo del software, de hecho sus principios fundamentales fueron desarrollados en procesos de reingeniería por Goldratt, Takeuchi y Nonaka en la década de 1980 y no fueron aplicados al proceso de desarrollo de software hasta 1993 por Jeff Sutherland, siendo formalizada con la colaboración de Ken Schwaber en una presentación en OOSPLA 96.Eso lo hace muy versatil para desarrollar proyectos de workflow por ejemplo, pero mi duda es si se puede aplicar de forma eficiente a un proyecto de datawarehouse.
A priori, un buen proyecto para aplicarlo sería el de una "reingenieria de un dwh existente", y tengo precisamente tengo una entre manos, asi que voy a decicar este post a "refrescar" los principios sobre los que se basa SCRUM a ver si lo puedo aplicar o no a este proyecto.
El Scrum se ha desarrollado teniendo como principios fundamentales:
Principio de requisitos indefinidos de Humphrey.
Para un nuevo aplicativo, los requerimientos no serán totalmente conocidos hasta que el usuario no lo haya usado.
Lema de Wegner.
Es imposible definir completamente un sistema iterativo. •
El principio de incertidumbre de Ziv en la ingeniería del software.
La incertidumbre es inherente e inevitable en el proceso de desarrollo de aplicaciones.Podríamos decir que Scrum se basa en cierto “caos controlado”, el proceso del ciclo de desarrollo de Scrum parte del conocimiento de que el proceso de desarrollo fundamental del producto esta totalmente indefinido, es incluso caótico, pero establece ciertos mecanismos para controlar esta indeterminación, manipular lo impredecible y controlar la flexibilidad.
Y aqui nos encontramos con la primera pega, SCRUM es segun sus propios autores un.... "Modelo de desarrollo ágil de productos"
"Producto", un DHW NO es un producto que se pueda acabar como ya dije en el post anterior, asi que quizás no sea tan buena idea lo de SCRUM.
Pero los principios me parecen muy adecuados. Claro si pensamos en el origen de la metodología es obvio que esta orientada a producto así que no se yo hasta que punto voy a poder aprovecharla.
Pero sigamos viendo, ahora me centraré en el ciclo de vida de Scrum. Este es una analogía de la jugada de rugby de la que recibe su nombre. En Scrum el balón ha de disputarse entre ambos equipos, los jugadores de un equipo se reúnen en circulo y deciden que es lo que van ha hacer, luego se posicionan enfrente del otro equipo de forma entrelazada, con el balón en medio, y comienza la jugada en la que no se sabe que va a pasar, ni quien tendrá el balón ni hacia donde se atacará.
El equipo ha de adaptarse rápidamente hacia una jugada ofensiva o defensiva según quien se haya hecho con el balón.
¿Eso me sirve para el rediseño de un DWH?
Uy que pinta un poco mal. Si yo ya tengo claro hacia donde tengo que ir, que estructura tengo que optimizar, que usuarios utilizan el sistema y como lo utilizan.
¿Necesito esa adaptabilidad tan extrema?.
Empiezo a ver que no, pero quiero darle una oportunidad antes de descartarlaEn la metodología Scrum se establecen tres fases : pre-juego, juego y post-juego.
En el pre-juego se definen y/o revisan las funcionalidades que ha de tener el sistema, haciendo la lista de funcionalidades que cuando estén completadas podremos decir que el desarrollo del sistema.
Dicha lista recibe el nombre de Release Backlog .Una vez hecho esto se elige un subconjunto de estas funcionalidades con el que se va a trabajar el próximo mes, llamado Sprint Backlog y entonces comienza la siguiente fase.
En el juego es donde se desarrolla el Sprint, las reglas de esta fase son sencillas, se distribuyen las tareas para cada miembro del equipo, se trabaja duro y se intentan conseguir el objetivo.
Todos los miembros del equipo han de participar en una reunión diaria que en ningún caso deberá exceder los 30 minutos, llamada Sprint-meeting.
En esta reunión cada desarrollador debe dar respuesta a tres preguntas:
• Que hizo desde la última reunión.
• Que dificultades se estan teniendo en el desarrollo de la tarea.
• Que va a hacer hasta la próxima reunión diaria.
Al finalizar el Sprint, pasamos a la fase de post-juego, en ella se evalúa la entrega de funcionalidades del Sprint , se ven las tareas pendientes, se evalúa el progreso del proyecto y se redefine el tiempo de entrega del mismo si fuera necesario.
En este paso se compara las funcionalidades actuales con el Release Backlog y en el caso de no cumplirse se vuelve a la fase de pre-juego para realizar una nueva iteración.
Si por el contrario, sí se cumplen entonces pasamos la creación de la versión final y a la creación de la documentación pertinente.
Pues creo que yo ya lo tengo claro, no me aporta demasiado para una reingenieria de DWH, quizás para un proyecto de DWH nuevo desde cero si que me podría ser útil, pero para una reingeniera de DWH claramente no, porque ya se que funcionalidades ha de dar, y porque no tengo que ir dando pequeñas funcionalidades cada semana, ya que lo tengo bastante mas simple, cuando acabe la reingenieria, desactivaré el antiguo data y conectaré el nuevo data.
Y si todo va bien los usuarios no se darán ni cuenta.
Bueno, para finalizar explicaré los roles básicos de SCRUM así os haceis a una idea, os pongo los 4 principales.
• Scrum Master: Es el responsable de asegurar que el proyecto se es-tá desarrollando según las reglas de la metodología Scrum.
• Product Owner. Es el responsable de la lista de funcionalidades (Re-lease Backlog).
• Scrum Team: Es el equipo responsable la organización y ejecución de cada uno de los Sprints.•
User/Customer: Participan en la creación y revisión de la Release Backlog.
Pero a mi me sigue gustando SCRUM, ya que la forma de trabajar que se adopta es muy colaborativa, un equipo de Scrum tiene entre 7 y 9 miembros, a los que se les incentivará para que adopten soluciones ingeniosas y que aprendan de forma conjunta en un ambiente totalmente cambiable pero controlado parcialmente.
