Continuamente encontramos publicaciones que incluyen términos como Digitalización, Big Data o Data Science. Y en contextos de negocio, economía, marketing, etc. El motivo es que los negocios cambian cada vez con más rapidez. También ha cambiado la manera en la que se relacionan las personas. Ya sea para colaborar en grupo o, simplemente para adquirir bienes y servicios.
Hace poco escuché que el 20% de la facturación de los restaurantes proviene ya del servicio de comida a domicilio, solicitado típicamente a través de apps. Seguro que los restaurantes han tenido que cambiar sus procesos en poco tiempo para adaptarse. Hay algo todavía más importante: Los propietarios de las apps, e incluso Google con su Android y su Gmail, pueden identificar clientes individuales, geolocalizarlos y analizar sus patrones de compra (hablamos de Data Analytics en general). Con ello podrán conocer mejor los gustos de los clientes, para ajustar convenientemente la oferta, y hasta promocionar otros productos que nada tienen que ver con la restauración. La gestión de proyectos también ha tenido que adaptarse a esta realidad empresarial: Los cambios son muy rápidos, las tecnologías se complican y requieren la colaboración de equipos multidisciplinares, a veces en remoto, el número de datos crece exponencialmente, son poco estructurados y externos a la empresa (por ejemplo opiniones de redes sociales), etc.
La gestión de proyectos tecnológicos durante muchos años ha sido (y sigue siendo) lo que denominamos predictiva, esto es, trata de ofrecer una estimación sobre el alcance, plazo, coste y calidad del proyecto (que suelen implicar restricciones contrapuestas, por ejemplo, más calidad puede suponer un incremento de costes y tiempos). De esta manera, la gestión predictiva observa sobre todo desviaciones reales o previstas sobre la planificación, y toma decisiones correctivas o preventivas con objeto de restablecer el equilibrio. Para poder hacer estimaciones realistas, es necesario que en fases tempranas del proyecto se conozcan con bastante detalle los requisitos y objetivos del mismo. Si bien se puede abordar por fases, la planificación irá cambiando a medida que se conozcan los detalles. La ventaja principal es que a lo largo de todo el proyecto (o al menos durante la fase que se ha planificado en detalle), se puede saber, siempre con cierto margen de error, si se van a cumplir o no las restricciones. La figura del Project Manager es la encargada de tomar decisiones, normalmente consensuadas con diferentes interesados, y de realizar el seguimiento del proyecto. La literatura sobre este tipo de gestión es muy extensa, aunque sin duda la organización PMI (Project Management Institute) y su publicación PMBOK (Project Management Body of Knowledge) son los estándares de referencia básica. PMI ofrece la certificación PMP, que estoy orgulloso de disponer desde 2.009, cuando no era tan conocida en España. También dispongo de la certificación de Scrum Master desde 2.014.
Cualquier método de gestión de proyectos conlleva cierta gestión de cambios y riesgos como pilares básicos. En el caso de gestión predictiva, por ejemplo, los cambios van a alterar alguna de las previsiones sobre alcance, tiempo, coste y calidad. Así pues, se recomienda aplicar alguna política al respecto, para priorizar unos cambios y rechazar otros, y requiere evaluar el impacto sobre la planificación. Puede haber hasta un comité de cambios que gestione los de mayor calado. No gestionar correctamente los cambios, como cuando se introducen cambios de alcance sin ningún tipo de autorización (conocido como scope creep), deviene en retrasos, sobrecostes, y entregables que los usuarios rechazan. Es decir, proyectos que acaban fracasando por no alcanzar sus objetivos. En ocasiones el Project Manager toma decisiones sin contar con su equipo. A veces acapara excesivo poder sobre él mismo. Lógicamente, el equipo técnico acaba viendo al Project Manager como una especie de capataz, que exige el cumplimiento de plazos… Pero que a la vez toma decisiones cuestionables de forma unilateral, incluso de índole técnica. Debo aclarar que el PMBOK no ampara este tipo de gestión, y establece diversos mecanismos para que esto no ocurra. No obstante, la realidad es que el trabajo bajo presión por cumplir restricciones, y un Project Manager con falta de experiencia, o quizás llevado por la cultura empresarial, acaban derivando en lo expuesto anteriormente.
Enlazando con el inicio del artículo, el negocio quiere que los entregables del proyecto reflejen los cambios solicitados lo antes posible, porque el mercado se lo exige. Por otro lado el equipo técnico reclama no ser tratado como simples productores de software (como recursos o máquinas), sino que demanda un ámbito de autoridad sobre la parte técnica, la planificación y el valor para el negocio. En este contexto se acuña el término de “agilidad” o “agile”, así como el de la gestión adaptativa frente a la predictiva. Pero no hay que confundir agilidad con rapidez de producción, el equipo técnico necesita tomarse su tiempo para entregar una solución de suficiente calidad. Si hay muchos cambios, el proyecto se alargará (las restricciones contrapuestas siguen ahí). Agilidad se refiere a aligerar los procesos de gestión, especialmente el de cambios, e incorporarlos como algo no solo inevitable sino positivo para el proyecto. En visiones provenientes de una interpretación extrema e inadecuada del PMBOK, la mayor parte de los cambios se consideraban como riesgos negativos, y por lo tanto a rechazar siempre que fuera posible. Se llegaba incluso a “castigar” al equipo técnico por querer abordar cambios, ya que es como reconocer que se habían cometido errores.
Un proyecto de Ciencia de Datos, sin ir más lejos, tiene buena parte de experimental. De inicio no se sabe muy bien si se encontrará un modelo adecuado, ni lo que puede costar hacerlo. Los usuarios de negocio no son capaces de definir requisitos detallados al principio. Y podemos dar por seguro que, antes de encontrar un buen modelo, tendremos que probar y descartar otros. Los sucesivos refinamientos de modelos ya incluyen el cambio como un elemento fundamental y beneficioso. La figura de un Project Manager obsesionado por cumplir una planificación rígida tiene poco sentido, y en su lugar una figura que ayude a superar momentos de bloqueo emerge como algo más útil. Como contrapartida, son proyectos donde el riesgo de exceder costes y tiempos aumenta, y es algo a asumir. No obstante, son necesarias prácticas para limitar el riesgo, como las que comenté en un artículo anterior. Hemos llegado al punto donde buenas prácticas de gestión ágil como SCRUM nos permiten articular ese enfoque adaptativo. En próximos artículos espero seguir profundizando sobre los beneficios del enfoque adaptativo para los proyectos de Analytics, Big Data, Ciencia de Datos y Business Intelligence. Y cómo Scrum necesita particularizarse en estos casos. Pero, para terminar, quiero aclarar otro punto típico de confusión: El PMBOK permite también gestión adaptativa, y sigue más vigente que nunca. PMI hace tiempo que ofrece certificaciones sobre agilidad. Los enfoques predictivo y adaptativo conviven dentro de los proyectos reales, y se busca un equilibrio entre cumplir con restricciones y responder a los cambios.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
El Sprint es un período de tiempo predeterminado y, en lo posible, de duración constante a lo largo de un proyecto. Las duraciones más habituales son dos o cuatro semanas, pero depende mucho del contexto. Durante el mismo se desarrolla un ciclo completo del resto de eventos (reuniones), más el propio trabajo técnico. Lo que se persigue es entregar un incremento de producto a su finalización, que responda a un objetivo concreto fijado al inicio. Inmediatamente después, comienza el siguiente sprint, de manera que se establece una rutina de entregas periódicas listas para usar, sin que exista tiempo entre sprints. Se puede pensar el sprint como un miniproyecto. Mientras que de un sprint a otro los cambios son bienvenidos, dentro de un sprint se alcanzan unos compromisos muy específicos, y solo se deberían permitir cambios o aclaraciones que no amenacen el objetivo del sprint. Si a lo largo del sprint lo que cambia es el compromiso, como puede ser una bajada en la calidad de los entregables, o funcionalidad imprevista al inicio del sprint, estaremos fallando en lo básico de Scrum. Que el sprint sea de un mes máximo facilita las estimaciones, a la vez que limita los riesgos negativos. Sí que se contemplan casos excepcionales de cancelación de un Sprint en curso, siendo el Product Owner quien tiene la última palabra al respecto. Esto será cuando considere que los objetivos iniciales del sprint ya no son alcanzables, o ya no tienen sentido. No necesariamente hablamos de fracaso, imaginemos simplemente que se decide pasar de una infraestructura propia a otra en la nube, y que no contar con la nueva lo antes posible significará mucho retrabajo posterior. Así pues, se detienen ciertos desarrollos para que se habilite la nueva. En este caso prima el pragmatismo, y no debería castigarse a nadie por una decisión así, ya que seguir con los desarrollos supondría una pérdida futura de valor.
La lección práctica es que dentro de un sprint no se pueden atender cambios importantes de prioridades o de alcance, y es el precio a pagar para cumplir con los compromisos. De esta manera, el equipo técnico puede centrar la mayor parte de su tiempo en las tareas de construcción del producto. Así, hasta cierto punto, se desentiende de otras tareas que no se piensan abordar en el sprint en curso. Las reuniones, aunque parecen muchas, son limitadas, tanto en tiempo como en intervinientes. Recordemos que se buscan equipos autónomos autoorganizados, y que no quieren ser interrumpidos con frecuencia por directivos, usuarios, etc. Que el Product Owner sea una única persona física (en vez de un grupo de usuarios) ayuda mucho a conseguirlo. Con todo ello lo que se pretende es que el equipo aumente la velocidad de desarrollo o implementación, hasta encontrar una velocidad de crucero. Siempre entendiendo que la velocidad hace referencia a producto construido y entregado listo para usar dentro de cada sprint, por lo que no vale entregar por entregar. Por ejemplo, una medida de velocidad basada en el número de líneas de código entregadas no es buena elección. Esto es así porque no se puede correlacionar directamente con el valor del producto, aunque un número inusualmente bajo (o alto) de líneas desarrolladas sí que puede activar una alerta de que en ese sprint ha pasado algo peculiar.
Observemos que los proyectos empiezan a parecerse más a operaciones continuas, sin que por ello se pierda el concepto de producto singular (no estamos fabricando hamburguesas sino productos únicos a medida). Hay quien afirma incluso que para una verdadera agilidad se requiere un sistema de integración continua, que automatiza pruebas y pasos entre entornos, precisamente para que el final del sprint no sea un cuello de botella, y también para que la definición de “hecho” (Done) sea más medible y corporativa. Debo decir que ni el Business Intelligence ni el Big Data son los proyectos más típicos para pensar en una integración continua muy automatizada, aunque solo sea por posibles problemas de calidad de datos. Otra adaptación habitual de los proyectos de Analytics, Data Science, Datawarehouse, etc., es considerar un sprint 0. Dicho sprint se sitúa al inicio del proyecto, y puede durar bastante más tiempo que los sprints normales, con el objetivo de preparar infraestructuras, instalaciones de software, estudiar la propia calidad del dato, entender requisitos no funcionales, etc. Es decir, un sprint donde no se entrega un incremento de producto (desde un punto de vista de usuario), y por esto no se puede medir en los mismos términos, ni tienen sentido todos los eventos. Algunos consideran esto como una especie de trampa, pero yo creo que establecer sprints especiales sin entrega de producto es algo bastante natural en los proyectos analíticos, lo mismo que puede haber sprints cancelados. Todo depende de los objetivos metodológicos que queramos cubrir, y en concreto de cómo queremos medir la velocidad de los equipos, así como el valor del producto. En siguientes entregas trataré sobre las reuniones y artefactos de scrum, intentando siempre ofrecer algún consejo práctico. Si os está gustando el tema permaneced atentos al Blog de datahack.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
Artículos anteriores estuvieron dedicados a la lista de producto (Product Backlog). En esta ocasión quiero comentar sobre el seguimiento dentro del Sprint, algo que también forma parte de la guía de Scrum.
Lo primero que hay que considerar es que las técnicas ágiles están pensadas para simplificar las tareas de gestión. Es así puesto que algunas recaen sobre el equipo de desarrollo, y siempre se prefiere que estén desarrollando antes que reportando el estado del proyecto. Todavía más crítico, el foco del seguimiento se centra en entender lo que queda para conseguir el objetivo del sprint, y en su caso modificar las estimaciones.
Sin embargo, no se pretende analizar cuánto tiempo se ha invertido en lo ya desarrollado, un hecho bastante desconcertante para quienes estén acostumbrados a las metodologías predictivas. Esto es porque Scrum no se pensó especialmente para ahorrar costes de fabricación ni tiempos de desarrollo (al menos no medidos de la forma tradicional), sino para entregar productos más adecuados a las necesidades cambiantes del negocio. Es decir, no debemos asociar ágil con veloz ni con barato, sino con productos de mejor calidad, tanto objetiva como subjetiva, y con mayor capacidad de incorporar cambios sobre la marcha. Por eso tampoco tiene mucho sentido realizar una contabilidad de horas por técnico y tarea, ya que esto inhibe la introducción de cambios, así como el trabajo en equipo.
Enlazando con lo expuesto en el artículo de planificación de sprints que publiqué anteriormente, en proyectos de Big Data, Analytics & Bussiness intelligence es el equipo de desarrollo quien estima lo que es capaz de terminar en un sprint dado, y esto lo hace mediante algún sistema de puntuación para cada ítem que acaba dentro del sprint backlog. Es común acabar convirtiendo la puntuación en horas, pero con el riesgo de caer en la contabilidad clásica de costes.
La utilidad no es tanto la conversión en horas, sino entender que un ítem valorado como 10 puntos requiere el doble de esfuerzo (tiempo supuesta una dedicación del 100%) que uno valorado en 5 puntos. Y también podemos conocer el histórico de puntos entregados en cada sprint, a medida que van sucediendo sus ciclos, para establecer una velocidad media. Esto permite ir afinando más el compromiso de entrega que alcanza el equipo de desarrollo durante la planificación del sprint, y también hacerse una idea de lo que supone el product backlog restante en cuanto a tiempo, entendiendo que es algo que irá evolucionando.
Hay varias técnicas para visualizar en medio de un sprint cómo nos encontramos respecto a la planificación. Sin duda, el artefacto más conocido es el gráfico de burn down. Aquí tenemos un ejemplo de gráfico sencillo:
En el eje horizontal aparecen los días hábiles del sprint en un proyecto de Big Data, en este caso 20, y la línea verde representa la previsión de avance diaria. En el eje vertical en este caso figura el esfuerzo restante en días (agregado para todo el equipo), aunque mi recomendación es representar mejor la valoración en puntos. Al inicio del sprint conocemos la estimación total de los puntos a terminar, e idealmente al final del sprint se habrán entregado todos ellos, por lo que la línea verde es una recta que acaba en cero para el eje vertical.
Mientras, la línea roja representa el avance real, e insisto una vez más, no como tiempo real dedicado sino como valoración de puntos de las tareas terminadas conforme al “definition of done”. La línea roja por encima de la azul nos advierte de un retraso respecto a la planificación. Por ello, es el propio equipo técnico quien debe decidir si es posible acelerar el ritmo de desarrollo, o bien considerar reducir el alcance del sprint en el supuesto de que ello no amenace el objetivo del mismo.
Aunque el gráfico de burn down resulta útil, puede inducir a error de interpretación cuando se realizan cambios de alcance durante el sprint, y ya sabemos que hay que contar con ellos si el objetivo lo requiere. Por eso me parece necesario usar también el gráfico de burn up. En la siguiente imagen se aprecia la diferencia:
Pensemos en un proyecto de Big Data donde a mitad del sprint se ve necesario introducir una nueva tarea no planificada al inicio, o bien se trata de una tarea cuya estimación se ha tenido que aumentar al ir conociendo más detalles funcionales. En el burn down podríamos volver a dibujar la recta planificada, que resultará más inclinada si es que mantenemos las escalas originales. Pero el gráfico no nos dice en qué momento se ha producido este cambio.
Viendo ahora el gráfico de burn up, la línea de trabajo planificado total pasa a ser una recta horizontal al inicio del sprint. Si hay cambios de valoración se van a poder visualizar como saltos en dicha línea. La otra línea ya no es el trabajo pendiente, sino el completado hasta el momento, y se espera que al final del sprint alcance la línea del trabajo planificado total. Si no se alcanza, al menos se puede tener una idea de hasta qué punto ha sido el cambio el que ha provocado esta situación.
La lección práctica es que parte del aprendizaje de Scrum consiste en saber cómo cambia la planificación durante el propio sprint (saltos en la línea horizontal), y planificar los siguientes sprints con suficiente holgura como para absorber este tipo de cambios inevitables. Pero, cuidado, no se trata de abrir la puerta a cualquier cambio dentro del sprint, estos cambios tienen que estar justificados siempre conforme al objetivo, en caso contrario el equipo de desarrollo se va a ir desentendiendo del mismo.
Si habéis seguido todos los artículos anteriores, y queréis profundizar un poco más allá de la guía de Scrum, os sugiero este otro documento más detallado.
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.
Tras haber ido comentando sobre los roles y las reuniones de Scrum, como se puede ver en el artículo anterior, continúo con las definiciones y artefactos que se usan a lo largo de todo el ciclo de Scrum. En concreto, hoy trataré el Product Backlog. Recuerdo que una lectura fundamental para el que se quiera iniciar en este marco de gestión es la guía de Scrum, que he tomado como base para estructurar la presente serie de artículos.
Viene a representar la hoja de ruta del producto, siendo el Product Owner el principal responsable de la misma. En concreto es fundamental que esté convenientemente priorizada según el valor aportado al negocio (posiblemente ponderado conforme a criterios de coste o esfuerzo), ya que en cada sprint se eligen preferentemente los elementos de mayor prioridad para poner el foco en su construcción.
La lista de producto está en continua evolución, hasta que el producto deje de tener sentido de negocio. Así, la visión tradicional de un proyecto cuyas condiciones de finalización son bien conocidas desde el inicio se transforma en una especie de proyecto continuo donde en cada sprint se va decidiendo lo que hacer en el futuro.
Ya podemos imaginar que las métricas típicas para medir el éxito del proyecto (desviaciones entre lo previsto y lo real a lo largo del proyecto completo), no tienen demasiado sentido en un marco tan cambiante y de un futuro muy difuso a largo plazo. Tampoco es sencillo acordar contratos a precio cerrado y fecha de entrega pactada, ya que necesariamente el proveedor tiene que limitar el número de cambios en ese marco. Esto no quiere decir que renunciemos a ciertas medidas, como la de la velocidad del sprint, y sobre todo a la del valor de lo entregado y la consecución del objetivo del sprint, pero el éxito de scrum requiere una gestión muy ligera.
Hay que tener muy claro que Scrum no está especialmente pensado para el ahorro de costes de producción, sino para que los costes (asumidos a lo largo del ciclo de vida del producto) sean convenientemente invertidos en desarrollar un producto valioso. Tampoco es buena idea mantener un sistema de control de tiempos de técnicos y tareas individuales, aunque solo sea porque amenaza el trabajo en equipo con una serie de objetivos comunes.
Otro aspecto crítico es que la lista debe ser única para un producto dado, incluso si participa más de un equipo de scrum. De esta manera resulta ser una verdadera hoja de ruta, en vez de un conjunto de peticiones de usuarios que realizan cada uno de forma independiente. Así el rol del product owner es también el de coordinador de usuarios y otros interesados, elaborando una lista representativa, coherente y priorizada, de las características que debe tener el producto.
Lo habitual es que los elementos más prioritarios aparezcan más desglosados, y por ello con estimaciones (esfuerzo, riesgos, complejidad) más fiables realizadas por el equipo de desarrollo. Recuerdo que esto se va haciendo en las reuniones de refinamiento de la lista de producto, y también en las de la planificación del inicio del sprint, aunque realmente se puede hacer en cualquier momento en que sea necesario.
El desglose tiene que llegar al menos hasta el nivel en el que los elementos pueden implementarse (terminarse) en un único sprint, de otra manera nunca podrían ser elegidos. Se deduce que es mala práctica conformarse con elementos menos desglosados cuando hay que abordar la reunión de planificación del sprint. También al flexibilizar scrum para trabajar con elementos donde se sabe que no se van a poder completar en un único sprint, algo que precisamente menciono por lo común que resulta.
Como lecciones prácticas, quiero aclarar que la lista de producto no es solo una lista de funcionalidades para negocio, aunque sí que la mayor parte del esfuerzo debería recaer sobre las mismas. Pero también tienen cabida tareas técnicas como la reestructuración del código, la formación de equipo, la investigación de nuevas técnicas, la mejora del tiempo de respuesta, etc. Teniendo potestad el equipo técnico para incluir elementos de este tipo dentro de la lista.
Esto es especialmente relevante en el contexto de los proyectos de analítica, Big Data y BI. Debemos contar con los consabidos problemas de calidad de datos. Estos exigen tareas específicas para tratarlos, sin que a veces se pueda poner algo concreto a disposición de los usuarios en un entorno de producción. En cambio, sí que podemos pensar en prototipos, ciertas entidades mejor definidas, etc., donde los usuarios tienen una responsabilidad continua respecto a la validación y las pruebas.
También necesitamos reservar tiempo para la investigación de nuevas tecnologías, porque quizás tengamos que probar varias de ellas, realizar diferentes modelos estadísticos antes de dar con uno suficientemente bueno, etc.
En resumen, no siempre se puede entregar una novedad significativa del producto en cada sprint en términos estrictamente funcionales, y por ello hay que saber buscar un equilibrio entre las entregas frecuentes y los aspectos que tienen más que ver con la calidad técnica.
A veces se considera un sprint especial cada cierto tiempo para abordar tareas que no están estrictamente asociadas a la funcionalidad, incluyendo el sprint 0 del que ya comenté en otro artículo. Pero no conviene tomar decisiones de gestión simplemente para reportar un mejor dato de velocidad. El rey es el producto, y esto incluye necesariamente tareas orientadas a asegurar la calidad del mismo, que podemos considerar prácticamente continuas, aunque puedan parecer un hándicap para la velocidad.
Me viene a la mente el interesante concepto de “deuda técnica”. Sin ser muy riguroso en la definición, diré que entregar software fabricado de manera muy rápida pero sin preocuparse de su calidad, es como haber recibido un préstamo, que nos ha permitido cumplir con un compromiso. Pero luego toca devolver los intereses, pensemos en posibles incidencias que hay que reparar de manera urgente, mantenimientos más costosos, etc. Y si los intereses empiezan a ser inabordables, tendremos que devolver todo el capital, o bien rehacer el código desde cero.
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.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
Avanzando sobre el contenido de la guía de Scrum.
Se trata de una breve reunión de coordinación al principio de cada día, y considero que es un evento especialmente importante para el funcionamiento de Scrum. Son los miembros del equipo de desarrollo del proyecto de Big Data, Analytics o Business Intelligence, que se supone autoorganizado (no es una reunión de reporte a un jefe de proyecto), quienes intervienen en la reunión. Cada miembro responde a tres preguntas clave:
Básicamente es el momento de saber, con cierta autocrítica, si se ha podido conseguir o no el grado de avance esperado, pero centrándose solo en un día. Por ello es fundamental que no se perciba como una reunión de reporte gerencial. Esa circunstancia incentiva el ocultar los posibles problemas o cambios ocurridos.
Hablamos de un punto de alineación entre el estado real del proyecto y el plan vigente. Recordemos, si el objetivo del sprint requiere cambios, es el momento, no habrá penalizaciones por ello. Quizás sea necesaria cierta replanificación, pero no es el objetivo de la reunión diaria. Lo que se recomienda es que haya una reunión posterior, donde se pueda entrar en más detalle, y donde posiblemente haya miembros que no tengan que asistir. De hecho, Scrum entiende que se necesitan más reuniones de las descritas, lo que marca la guía son las reuniones que considera obligatorias.
Para mí es la pregunta clave de un marco de gestión adaptativa. Puede ser que hayan aparecido incidencias inesperadas, que la planificación fuera muy optimista, que exista dependencia entre tareas incompletas, que falten conocimientos técnicos, que surjan malentendidos, etc. Un equipo autoorganizado tiene que aprender a solventar (adaptarse) a este tipo de bloqueos, pero se reconoce la gran dificultad de lograrlo.
En teoría es el Scrum Master quien ayuda a superar posibles bloqueos. Sin embargo, por mi experiencia en data science, y aunque puede ir en contra de los principios ágiles, a veces es necesario que un perfil más directivo priorice ciertas tareas, consiga más recursos, coordine diferentes equipos de Scrum, etc. Siempre que no sea con intención de penalizar errores, ni de realizar microgestión, a mí me parece admisible. Idealmente este perfil directivo no asiste a la reunión diaria, pero se ofrece a colaborar con el equipo después de la misma.
Aunque en la guía se menciona como un proceso continuo, yo creo que tiene entidad suficiente para establecer reuniones específicas. Recordemos que inmediatamente después de finalizar un sprint comienza el siguiente, con la reunión de planificación.
La idea es que durante el sprint actual, sin duda enfocado a trabajar sobre la lista de elementos del sprint en curso, se pueda reservar una pequeña parte del tiempo para trabajar también con la lista de producto (preparando futuros sprints). En concreto estamos hablando de detallar más la lista de producto, reunirse con algún stakeholder si procede, sin duda también con el Product Owner. De esta forma, ir entendiendo mejor las necesidades de los usuarios. Igualmente se pueden anticipar otros prerrequisitos técnicos, como la instalación de una base de datos o de cierto software de Big Data & Analytics, supuesto que sean tareas no abordables por el propio equipo. Así, conseguiremos que la planificación del sprint no se convierta en un punto de bloqueo justo en su inicio.
El foco de esta reunión, al final del sprint, es mostrar el incremento de producto funcionando que se ha conseguido, así como entender qué ha quedado pendiente de hacer para futuros sprints. Idealmente no se basa solo en una demostración de nuevas funcionalidades del producto, sino que se pone a disposición real de los interesados, para que puedan realizar sus propias pruebas del software ya funcionando (es admisible por ejemplo que sea un prototipo y no un paso a producción, lo importante es que los usuarios y el Product Owner puedan manejar el software).
De todas formas la reunión no debe quedar solo en la demostración. También hay que revisar una vez más la lista de producto, conjuntamente con el Product Owner, y entender cómo la repriorización frecuente ayuda de manera efectiva al negocio. De nuevo se requiere autocrítica, si hay funcionalidades que no han sido adecuadas, serán necesario modificarlas en siguientes sprints, evitando penalizaciones por ello.
Refiriéndonos a los proyectos de Analítica, Business Intelligence y Big Data, creo necesarias ciertas matizaciones para esta reunión. En concreto, pienso que requiere más tiempo que en otro tipo de proyectos, y no esperar solo al final del sprint. Está muy bien ofrecer un prototipo a los usuarios, pero también hay que considerar si cuentan con la formación suficiente, o es preferible que estén acompañados de alguien del equipo técnico durante sus revisiones.
El Product Owner tiene que velar por mantener un feedback coordinado de los diferentes interesados, ya que cada uno tendrá sus propias prioridades. Otro riesgo típico es que los interesados no entiendan que están viendo un prototipo con algunas limitaciones, lo que requiere una cierta gestión política del proyecto.
Si en la anterior reunión se pretendía revisar principalmente el producto, en la retrospectiva se quiere evaluar el propio proceso de Scrum. Esta reunión marca el fin del sprint. Es el momento de hablar sobre lo que ha funcionado mejor y peor en el resto de reuniones, y de establecer alguna mejora concreta. Por ejemplo, se ha podido descubrir que la reunión diaria se extiende excesivo tiempo porque se quiere entrar en el detalle de las incidencias, o porque cada día hay alguien diferente que llega tarde a la reunión.
Otros problemas típicos más complejos abordan la dificultad de formalizar qué se considera un trabajo terminado, o cómo repartirse tareas de forma equitativa. Igualmente se pueden tratar temas sobre barreras en la comunicación, posibles malentendidos, etc.
Pero sería un error dedicarse exclusivamente a revisar puntos negativos. También hay que evaluar puntos fuertes, y reconocer lo que sí está funcionando (ej. sustituir correos electrónicos por reuniones cara a cara), para de esta forma afianzar las prácticas más útiles.
Con esta entrada he cubierto ya todos los eventos de Scrum, y anteriormente lo hice sobre los principios ágiles y los roles. En próximos artículos realizaré consideraciones sobre los artefactos y demás conceptos básicos de Scrum. Permaneced atentos al Blog de datahack.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
El Sprint comienza con esta reunión, donde se pretende concretar lo suficiente el alcance del mismo, y a partir de ese momento comprometerse con el mismo sin perder el foco. Por ello hay que responder a dos preguntas fundamentales:
Debo recordar aquí que terminado significa idealmente listo para entregar al usuario. El entregable terminado durante un sprint concreto se denomina incremento de producto. Para poder responder a la pregunta anterior, lo primero que hay que conocer el histórico de entregas en sprints anteriores, sobre todo en los más recientes, para estimar la velocidad del equipo. También hay que tener en cuenta la capacidad de desarrollo prevista del equipo. Esta está condicionada, por ejemplo, por posibles vacaciones y reuniones, y especialmente por trabajar en multiproyectos, lo que anticipo que se desaconseja.
Como es lógico, en los primeros sprints falta información para ofrecer una estimación fundada; pero la idea es que, transcurridos varios, el equipo alcance una velocidad de crucero, que se puede medir y sirve para proyectar en los siguientes.
Por otro lado tiene que estar muy bien formalizada y priorizada la lista de producto, aunque todavía no he comentado sobre la misma. En este punto basta saber que es el Product Owner quien la define, y que prioriza las funcionalidades pendientes que más valor aportarán al negocio. No obstante es el Development Team quien decide cuántos de estos elementos, por orden de prioridad, puede terminar durante el sprint.
Podemos pensar que esta parte de la reunión se alarga mucho, pero se supone que en sprints anteriores se ha celebrado otra reunión específica para ir detallando y estimando la lista de producto. De esta forma la preselección se puede hacer bastante rápida.
La estimación que realiza el equipo de desarrollo suele basarse en puntos asignados a cada elemento de la lista, y que tiene en cuenta la complejidad del desarrollo, posibles riesgos, etc. En función del histórico del proyecto, se puede establecer una media de puntos entregados por sprint, y así se precisa mejor cuántos elementos de la lista son abordables en el actual.
Hay otra matización importante de este apartado, y es que se recomienda formular un objetivo concreto del sprint. Es decir, no se trata de ir implementando elementos deslavazados, sino que el equipo debe comprender cómo esos elementos conjuntamente proporcionan valor al negocio, y por qué son más prioritarios que otros, algo que debe aclarar el Product Owner.
Una vez preseleccionados los elementos de la lista de producto más prioritarios, es necesario establecer un plan de desarrollo o implementación. Esto suele requerir que el Product Owner aclare detalles funcionales que hasta el momento no eran conocidos. También es probable que el equipo de desarrollo ajuste sus estimaciones de puntos a medida que dispone de más información, o por ejemplo advierta algún riesgo que no se había considerado inicialmente. También se pueden incluir elementos menos prioritarios, pero que, por motivos técnicos, o porque convienen al objetivo, se podrían abordar en este sprint. Con todo ello se espera generar la lista de elementos pendientes para el sprint en curso, incluyendo el plan de trabajo asociado.
En este punto, el plan es todavía un tanto genérico, y aborda aspectos como las tecnologías a usar, tareas de alto nivel a llevar a cabo, medidas de calidad o de terminación del trabajo, y cómo se espera dividir el trabajo entre las diferentes personas. Es importante que de la reunión se salga con una secuenciación lógica y completa de todo el sprint, aunque sea de alto nivel.
El plan es competencia directa del equipo de desarrollo. Lejos de ser algo estático (fijado por esta reunión), va evolucionando y entrando a mayor nivel de detalle a lo largo del sprint, y está presente en el resto de reuniones. Más que con un diagrama de Gantt, el grado de avance se visualiza con esos post-its de colores que a todos nos vienen a la mente cuando se habla de agilidad.
Nota personal: El diagrama de Gantt no tiene nada de malo en las prácticas ágiles, lo malo viene cuando se entra en demasiado nivel de detalle de tareas, sabiendo que va a haber cambios diarios.
Ya intuimos que es probable tener que renegociar sobre los elementos de la lista de producto preseleccionados al completar la primera pregunta, algo característico de la agilidad, siempre que no vaya en contra del objetivo. Esto ocurre en la planificación, pero también en el día a día del sprint, donde podemos interpretar que existe cierta replanificación. Y también muy natural para los proyectos de Analítica, Big Data y Business Intelligence, donde los diferentes interesados tienen que ofrecer feedbacks frecuentes de lo que necesitan y de lo que se va entregando. Y donde se van descubriendo aspectos de la calidad y disponibilidad del dato que requieren adaptar las tareas, o lanzar procesos que duran horas.
Podemos apreciar cómo el equipo de desarrollo gana competencias de gestión respecto a la manera tradicional. Pero igualmente crece su responsabilidad ante el resto de interesados. Por ejemplo, si el equipo de desarrollo es muy conservador a la hora de realizar estimaciones, habrá alguien en la organización que pida explicaciones por ello, empezando por el Product Owner.
Sin duda, la dirección de la empresa va a esperar cada vez mayor velocidad percibida, y también hay que demostrar mejoras tangibles frente a las metodologías predictivas. En concreto, volviendo a la analítica, el Big Data y el Business Intelligence, lo primero que hay que evaluar es si los usuarios están usando nuestros productos. Y, lo segundo, si el ritmo de entregas es el adecuado (aunque siempre hay usuarios con un afán desmedido de nuevas funcionalidades, y es el Product Owner quien tiene que gestionarlo).
En último extremo el compromiso del sprint no es una lista de elementos seleccionados de la lista del producto, sino el objetivo fijado en la primera parte de la reunión. El objetivo ayuda a centrar el foco, evitando cambios durante el sprint que claramente pongan el riesgo el mismo. También afianza la idea de colaboración en equipo para conseguir un resultado conjunto. Y a la vez permite cierta flexibilidad sobre elementos concretos, que pueden entrar o salir de la lista de elementos pendientes del Sprint.
Si se quiere contar con flexibilidad ante cambios frecuentes, las renegociaciones también son frecuentes. Aquí es de utilidad el Scrum Master para ayudar a vencer momentos de bloqueo, o para evitar que una parte someta a la otra sistemáticamente.
A la hora de profundizar en los requisitos del producto, es conveniente que el equipo técnico pueda reunirse directamente con otros interesados de negocio. Si hablamos de proyectos de analítica, pasa a ser crítico. El error es pensar que el Product Owner debe conocer todos y cada uno de los requisitos de negocio, y aislar al equipo técnico del resto de la empresa. En realidad la figura es más de coordinador y facilitador de toma de requisitos (por ello se recomienda que sea una única persona).
Sí que debe vigilar que se priorizan los de mayor valor, y resolver conflictos de intereses contrapuestos de los stakeholders, para que el producto sea coherente. También debe evitar cambios en medio del sprint que pongan en riesgo el objetivo, como ya hemos visto. Seguramente un Product Owner se acerca más a la figura clásica de jefe de proyecto de negocio, que el propio Scrum Master, algo que también genera cierta confusión cuando se utiliza Scrum por primera vez.
Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.
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.
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:
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).
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 (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:
Scrum ha establecido principios coherentes con el manifiesto ágil, basados en el empirismo:
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.
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.
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.
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.
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.
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.
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.