El manifiesto ágil y Scrum para gestionar proyectos de Big Data y BI

El manifiesto ágil y Scrum para gestionar proyectos de Big Data y BI

En un artículo anterior describí el contexto en el que aparecieron las mejores prácticas ágiles, especialmente adecuadas para proyectos de Analítica, Big Data y Business Intelligence. Hoy voy a profundizar en las mismas.

Manifiesto Ágil

Es casi obligado empezar mencionando el manifiesto ágil, una lista de principios en los que se fundamenta Scrum, y otras muchas prácticas ligadas a la implementación de productos informáticos. Me gustaría resumir las ideas principales del manifiesto, y de la llamada gestión adaptativa frente a la predictiva:

La agilidad conlleva simplificar los procesos de gestión, especialmente el de cambios.

Como el valor para el negocio se habilita mediante entregas de producto, es necesario realizar entregas frecuentes e incrementales que reflejen los cambios solicitados lo antes posible. No puede existir burocracia en la gestión porque rompería con el ritmo de entregas. Por ejemplo, tardanza en la toma de decisiones. El objetivo es mantener un ritmo constante de entregas. Además el producto que se entrega tiene que estar listo para ser usado, en otro caso no computa como avance.

(Nota: No necesariamente cada entrega se pone a disposición del usuario, como sería un paso a producción, pero es un producto listo para el usuario en cuanto lo requiera).

El equipo técnico trabaja como un grupo cohesionado

También forma equipo con personal no técnico. Tiene la autoridad para decidir la mejor manera de implementar los productos. También para estimar tiempos de tareas y establecer cierta priorización de las mismas. Es fundamental observar determinadas normas de calidad de implementación, para que la evolución del software no se convierta en un problema, y no debería haber un jefe de proyecto externo quien viniera a establecerlas.

Tampoco esperemos que Scrum nos detalle normas de codificación, o cómo se tienen que probar o versionar los desarrollos, ni qué se considera un prototipo. Esto no forma parte de su ámbito (lo mismo que ocurre con el PMBOK). En general, se trata de buscar soluciones lo más sencillas posibles pero vigilando la calidad del producto en un sentido muy amplio.

Es conveniente reunirse presencialmente con frecuencia, tanto entre los miembros del equipo técnico, como con los usuarios, equipo de negocio, otros equipos técnicos, gestores, etc. Claro está que las reuniones igualmente deben ser ágiles, y nunca caer en “la parálisis por el análisis”.

Scrum

Scrum (marco de gestión y de trabajo en grupo) es el paradigma del manifiesto ágil. Viene a estructurar el mismo para poder pasar de la filosofía a la práctica. Scrum es relativamente sencillo de entender, pero se reconoce la gran dificultad de ponerlo en marcha en proyectos reales, a veces resulta utópico. El punto de partida para introducirse (y certificarse o trabajar dentro del marco) en Scrum es la guía de Scrum. Veamos lo fundamental:

Principios de Scrum

Scrum ha establecido principios coherentes con el manifiesto ágil, basados en el empirismo:

Transparencia:

Necesaria para trabajar en grupo de manera efectiva. En todo momento se puede conocer en qué tareas trabaja el equipo técnico, y qué falta para completarlas. Incluso se llega a definir cómo se sabe si están completas. Igualmente las personas de negocio tienen expectativas claras sobre qué es lo próximo a entregar en un determinado plazo, y si sus cambios están siendo atendidos o no.

Inspección:

Como un equipo tiene autoridad sobre la gestión, requiere que se autoevalúe como grupo con cierta frecuencia, siempre que no se convierta en algo burocrático (no se hace énfasis en la documentación). El ejemplo típico es saber si se están cumpliendo o no las entregas comprometidas, en un compromiso que el propio equipo ha adquirido.

Adaptación:

Si algo impide alcanzar los resultados previstos, lo que se habrá detectado en la inspección, hay que introducir cambios empíricos y ágiles en la manera de hacer las cosas. La novedad es que no existe un Project Manager que venga a imponer dichos cambios. En su lugar, emergen tres roles que se reparten la responsabilidad (equipos autoorganizados). Conjuntamente estos tres roles conforman el Scrum Team.

Roles de Scrum (Scrum team)

Development Team:

La autoridad técnica a la hora de construir productos y soluciones, una vez que ha entendido los aspectos, digamos, funcionales del producto. La responsabilidad es conjunta y no individual. En rigor no puede haber roles diferenciados como los administradores de bases de datos, equipos de test, etc., aunque luego cada miembro pueda desarrollar tareas especializadas. La idea es que la distribución de tareas la realice el propio equipo técnico internamente, pero lo que miden el resto de roles son las entregas de producto. Scrum reconoce que un equipo técnico con más de 9 personas es demasiado grande para este tipo de gestión.

Product Owner:

Responsable de priorizar las funcionalidades requeridas por el producto, para maximizar el valor para el negocio. Será por ejemplo quien vaya introduciendo los posibles cambios, y quien explique con suficiente detalle lo que se pide, para que el equipo técnico consiga entenderlo. Una vez que parte del producto está disponible, tiene autoridad para decidir si responde o no a lo solicitado. No obstante, si se trata de cambios, no los hace pasar por incidencias de no conformidad. Aclaro que hablar de funcionalidades y de disconformidades no es ortodoxo en lenguaje Scrum, pero no quiero complicar este apartado ahora.

Scrum Master:

Como conocedor del marco, es un facilitador para el resto de roles, asegurando que no se pierden los beneficios de Scrum por malas interpretaciones. También se puede ver como un formador cuando trata con equipos con poca experiencia, ya que Scrum utiliza sus propios artefactos y eventos. Suele estar presente en las reuniones periódicas que requieren la inspección y la adaptación. No obstante, su rol no es tomar decisiones como asignar tareas a individuos, priorizarlas, probar el producto, etc. En su lugar, ayuda a buscar el consenso cuando existen discrepancias entre individuos. Dentro de su autoridad se encuentra el decidir si se está o no siguiendo el proceso completo de Scrum.

Mi enfoque particular

Podemos observar que un Scrum Master responde al concepto de “coach”, tan extendido en el mundo empresarial. Sin embargo, debemos huir de quien prometa resultados a muy corto plazo. Tampoco es lo mismo agilidad que rapidez, ya que los equipos invierten cierto tiempo en procesos empíricos de mejora continua. Introducir un cambio cultural paulatino requiere personas con amplia experiencia empresarial, acostumbrados al trabajo en grupo y que procuran flexibilizar los marcos de gestión. Saben cómo no caer en el dogmatismo, a la vez que establecen cierta exigencia formal, lo que siempre se ha llamado “tener mano izquierda”.

En este punto tengo que parafrasear a Groucho Marx: “Estos son mis principios ágiles. Pero, si no le gustan, aquí tengo otros”. Sé que los puristas de Scrum no van a quedar muy contentos, pero yo creo que el empirismo obliga a realizar adaptaciones de Scrum, no todas ellas amparadas por la Guía de Scrum. Esto es lo que se conoce como “ScrumBut”, y reconozco que lo hago cuando lo creo oportuno. Sin ir más lejos, las diferencias entre un proyecto de Data Science de carácter experimental, frente a la implementación de un ERP, ya obliga a ciertas adaptaciones del marco.

Como veis, cualquier marco de gestión o metodología no están exentos de polémica, y en diferentes empresas se aplican de manera dispar. Espero poder escribir sobre ello en futuros artículos. No obstante, en el próximo comentaré sobre las diferentes reuniones y artefactos de Scrum, para completar la visión general.


José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de DataHack.

2 comentarios de “El manifiesto ágil y Scrum para gestionar proyectos de Big Data y BI

  1. Justo González Blázquez dice:

    Hola.
    Yo que vengo del mundo waterfall, principalmente, y de trabajar para clientes que quieren el producto esperado en el tiempo estipulado y sin tener sobrecostes, supongo que para esta gestión empírica de los proyectos es imprescindible un cambio cultural, y opino que este cambio se tendría que hacer de un modo empírico, tendrá que haber ensayo-error, pero ¿como se puede gestionar la presión que imponen las cuatros restricciones (A, T, C y Q) sin querer abordar el cambio cultural? Se me antoja complicado, ¿no?

    • José Julio López Santos dice:

      Justo existe este problema que dices. El verdadero reto de gestión es el del cambio cultural, más allá de las dificultades que conlleva cualquier cambio tecnológico importante. Si nos vamos al caso más puro de scrum, solo hay previsiones ajustadas de lo que va a suceder en el siguiente sprint (recordemos que no más de un mes). Por esto mismo no se pretende poner el foco en posibles sobrecostes a lo largo de un proyecto, sino en entregar lo más valioso que se pueda para el negocio dentro de esos costes ya asumidos, lo mismo que se puede asumir el coste del alquiler de un edificio. Esto no significa que el valor producido vaya a compensar necesariamente los costes, y por ello hablamos de proyectos que pueden tener más riesgos negativos que otros convencionales, pero también más oportunidades.

      En resumen, parte de la gestión del cambio cultural estriba en flexibilizar las restricciones clásicas, sin tampoco abandonarlas ya que son un hecho relevante, y es imprescindible que haya un esponsor del negocio o de la dirección que lo entienda, lo asuma, y ayude a divulgarlo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *