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.
Recibe nuestra programación mensual de eventos online y la apertura de nuevas convocatorias de cursos
En Datahack Consulting SL trataremos los datos que nos facilites con la finalidad de enviarte información relacionada con tu solicitud sobre nuestros servicios, así como enviarte comunicaciones informativas sobre nuestra actividad. Podrás ejercer los derechos de acceso, rectificación, limitación, oposición, portabilidad, o retirar el consentimiento enviando un email a administracion@datahack.es. También puedes solicitar la tutela de derechos ante la Autoridad de Control (AEPD). Puedes consultar información adicional y detallada sobre protección de datos en nuestra Política de Privacidad.
Llámanos, escríbenos al email o por WhatsApp o inicia un chat en la web y hablamos