SCRUM: Metodologías agiles en Business Intelligence (Cap.1)
Hey!, hay algo más allá de la cascada…
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.
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.
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones | sobre procesos y herramientas Software funcionando | sobre documentación extensiva Colaboración con el cliente | sobre negociación contractual Respuesta ante el cambio | sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.
Todo bárbaro. Pero como se hace para que un proyecto termine algún día? Y cuando se va un programador, como se hace para ver dónde se actualiza una determinada tabla? O quien fué el que pidió que se incluyera una funcionalidad que nadie usa?
Todas esas preguntas son las que trata de organizar la Ingeniería de Software, y desde ese punto de vista el modelo de madurez de software (CMMI) del Software Engineering Institute de la Universidad de Carnegie Mellon. Pero las ventajas de una metodología ágil es tan grande que nada impide que se puedan aplicar ambas. Al menos eso es lo que dice el SEI. (SEI: CMMI and Agile)
Continuará…