Por María Gaska
Según el manifiesto ágil de 2001, las metodologías ágiles (MA) surgen de la necesidad de flexibilizar las metodologías tradicionales de desarrollo de software. De estos principios, se desprenden las ventajas de frameworks como Scrum (1995) por su carácter iterativo, flexible, menos burocrático y menos dependiente de grandes cantidades de documentación.
Un punto que destacan las MA, es la gran cantidad de cosas que no sabemos a la hora de desarrollar un producto nuevo y que por lo tanto no podríamos documentar.
Investigando sobre MA se encuentran muchas definiciones pero relativamente poca teoría o estadísticas de uso sobre qué funciona mejor dónde. Siendo de naturaleza tan flexible, lo que esperamos es que un framework como Scrum se implemente diferente en equipos de distinto tamaño, con distintas especializaciones, etc. Por eso me pareció que lo mejor era ir directamente a la fuente y preguntarle a profesionales de ciencia de datos cómo aplican MA y qué aspectos les funcionan y cuáles no.
Experiencias en Machine Learning con metodologías ágiles
Las preguntas que estoy tratando de responder son las siguientes ¿son útiles las metodologías ágiles para productos basados en datos? ¿qué les falta? ¿qué les sobra? Para entender este proceso, consulté a distintos profesionales de la industria que trabajan con MA y les pregunté su opinión y los detalles de la implementación concreta que hacen en sus respectivos equipos.
A todos les pregunté por las herramientas que utilizan (Jira, Trello, etc), las reuniones y la cadencia que implementan y qué consideran que funciona y qué no para proyectos de data science.
Estas fueron las respuestas:
Hernán Escudero
Hernán trabaja en consultoría con datos y por lo tanto aplicó las MA en variedad de proyectos y en distintas industrias.
Entre las herramientas, Hernán destaca ML canvas a la hora de volcar los requerimientos. ML Canvas resulta especialmente útil para ordenar y delimitar responsabilidades.
Herramienta ML Canvas
Para la gestión y seguimiento de tareas, donde lo más común es Jira o Trello, Hernán elige Notion, al que define como Trello con esteroides.
En cuanto a ceremonias y reuniones, destaca que es importante la flexibilidad. Nunca deben convertirse en una carga para las personas que tienen que llevarlas adelante. Al interior de la consultora mantienen una reunión semanal para sincronizar objetivos. De cara al cliente, en muchos casos la daily no es un requisito obligatorio y la cadencia baja normalmente a una reunión cada dos días, más de acuerdo a las necesidades de cada uno.
Respecto de los procesos, encuentra especialmente útil el pensamiento iterativo de las MA. Implementan sprints de dos semanas con un backlog de tareas y redefiniciones. También considera sumamente importante (en un contexto de consultoría) la figura del product owner del lado del cliente para destrabar los blockers que aparecen normalmente durante el desarrollo de un proyecto, específicamente definiciones y orígenes de datos.
Milena Dotta
Milena trabaja en una importante plataforma de e-commerce y servicios financieros. Se autodefine como fanática de las metodologías ágiles y considera que su equipo las implementa con un éxito considerable. Trabaja en prevención de fraude, desarrollando modelos de machine learning.
La organización del equipo está planteada alrededor del producto. En el mismo confluyen ingenieros de backend para el desarrollo de APIs, ingenieros de machine learning que se especializan en la puesta en producción de modelos y científicos de datos enfocados en el entrenamiento y evaluación de los mismos. Si bien existen roles, los límites de cada uno son difusos y todos encaran diversas tareas con flexibilidad en la medida en que son necesarias.
Mientras que la empresa se organiza en Quarters, cada equipo desarrolla su trabajo basado en sprints de dos semanas. Cada sprint involucra tres reuniones que se respetan en todos los casos: una planing, una de cierre y una retrospectiva. En este punto las definiciones de Scrum se respetan estrictamente pero no así en la daily que se celebra cada dos días.
La daily tampoco tiene la función que estrictamente está definida en Scrum, donde se usa generalmente para transmitir información sobre lo que cada uno está haciendo. En la organización de Milena, la comunicación es lo suficiente fluida gracias a los distintos canales de Slack, entonces el foco de la daily es visibilizar los stoppers de cada uno.
En el equipo de Milena, los modelos se implementan en una aplicación con todos los desafíos relacionados a funcionar en tiempo real y de cara al público. En este sentido, trabajan con una versión particular de las metodologías ágiles. Trabajan con tres tipos de tracks: enablers, que permiten incorporar productos nuevos e involucran la definición de reglas y flujos de información, proyectos de modelado (modelos de ML en el sentido más tradicional) y por último los tracks de excelencia y deuda técnica, para mejora continua.
En todos los casos el gran desafío es bajar estas especificaciones a historias de usuario que no se bloqueen entre sí y que permitan paralelizar lo más posible, pero en el segundo caso (desarrollo de modelos) las historias de usuario tienden a ser más exploratorias.
En cuanto a la organización y seguimiento, los proyectos son monitoreados por los propios miembros del equipo que se reparten las responsabilidades horizontalmente, con distintos encargados por tema.
Durante la planning, utilizan story points para asignar “puntos de esfuerzo” a las tareas, que aproximadamente representan un día de trabajo pero podría decirse que son una métrica particular que sólo se aprende a manejar con el tiempo y la experiencia.
Pensando en el largo plazo, el equipo trabaja con OKR (Objectives and Key Results), donde se miden KRs concretos como “bajar el fraude de X% al Y% en la región Z”. También hay objetivos más personales relacionados al desarrollo profesional de cada uno.
Milena destaca que las reuniones retrospectivas son muy útiles para discutir aspectos más soft, como por ejemplo cómo circula la información y cómo se siente cada miembro del equipo llevando adelante las tareas.
Si bien el “costo hundido” de la implementación de las MA es alto y las planing de quarter son un gran esfuerzo e involucran muchas reuniones cruzadas y estimaciones, a la larga favorecen el trabajo en equipo. En cuanto a potenciales riesgos, observa que el buen funcionamiento de las mismas es muy dependiente de quién es la persona que lo coordina ya que al haber tantas reuniones es importante que los miembros del equipo no se salgan del scope de la reunión y se mantengan las formas.
La conclusión es que una vez pagado el costo hundido de implementación y aprendizaje se logra concretar más proyectos en menos tiempo y con los miembros del equipo más relajados.
Leo Córdoba
Leo trabaja en una empresa de producto que ofrece soluciones de pago y analytics para empresas de restaurantes y comida rápida. Desarrolla modelos de machine learning para mejorar los insights que se entregan a los clientes a través de forecasting y detección de anomalías.
En su caso, el área de machine learning es relativamente chica dentro de la empresa y la forma en que se aplican MA no es diferente a la del resto del stack.
Las herramientas más importantes son Jira y Aha!, y para Leo resultan útiles a la hora de dar seguimiento a los proyectos.
Jira Canvas
En cuanto a las reuniones propias de Scrum, la daily se implementa con frecuencia diaria y se usa, siguiendo la definición de Scrum, para comunicar en qué se está trabajando, en qué se va a trabajar mañana y los blockers.
Las sprints en cambio se extienden durante tres semanas en lugar de dos, como propone la metodología tradicional. En cada sprint se celebran una reunión de grooming, una de planning y una de retrospectiva. La grooming funciona como una pre planning donde se empiezan a puntuar tareas y se revisa la viabilidad. En la planning propiamente dicha se define qué tareas entran en el sprint en base a los puntos asignados.
Para dar cuenta de la etapa exploratoria de los proyectos de ML, el equipo utiliza spikes, un tipo de user story orientado a la investigación o experimentación, cuya finalidad es obtener el aprendizaje necesario para implementar la funcionalidad solicitada por el Product Owner. Este tipo de user story es útil para encuadrar las tareas exploratorias pero quita visibilidad a la heterogeneidad de tareas: lectura de papers, EDA, benchmarks, PoCs, etc.
Por el contrario las tareas que no son exploratorias, en su experiencia, quedan bien organizadas con scrum y la metodología ayuda a conseguir los objetivos.
Mauricio Impallari
Mauricio es consultor de tecnología y profesor de la UNaB. Con más de 25 años en la industria, experimentó las metodologías tradicionales y el surgimiento de las MA. Recuerda que antes de las MA era muy frecuente que los proyectos se fueran rápidamente de alcance y costo y que los requerimientos no cambiaran a la velocidad del negocio.
Como herramienta de gestión, si bien hoy usa Trello, su mejor experiencia es con CA Agile Central de Rally Software por la facilitar la creación de user stories, dependencias, etc, siendo en su opinión la herramienta más completa del mercado.
Rally Agile Central
Mauricio cuenta su experiencia con las MA en un contexto de presión extrema, llevando adelante una migración de datos masiva para una empresa de salud durante la pandemia. Teniendo en cuenta la falta de tiempo, usaron una versión muy acotada de Scrum: sin grooming, con un backlog en Trello y las historias categorizadas en verde, amarillo y rojo. Lo que más útil resultó en este caso fue poder asignar tareas con agilidad y ver de manera ordenada las dependencias entre las mismas.
Los sprints fueron semanales, con una reunión de planning. La asignación de puntos de esfuerzo fue unilateral por una cuestión de tiempo, y en cada sprint se celebró una reunión de cierre para entender los problemas que se dieron y poder recalcular estrategias.
Tratándose de una consultoría externa, coincide con Hernán en que el rol del Product Owner del lado del cliente es clave para destrabar los blockers del proyecto.
Entre los desafíos más importantes a la hora de implementar MA en proyectos de ML y datos, Mauricio señala que las personas no conocen bien los conceptos en parte por no tener experiencia en otras áreas de desarrollo.
Otro problema que puede surgir, es que los que gestionan traten de apegarse a las MA demasiado al pie de la letra, sin tener en cuenta las posibilidades del proyecto y del equipo en términos de tiempo y conocimiento. Eso puede salir “muy mal” en su experiencia. Existe el riesgo de que las MA se conviertan en algo demasiado estricto y repitan los errores de las metodologías tradicionales.
Conclusiones
- La ciencia de datos es una disciplina que se acopla a la ingeniería de software tarde y eso influye en la adopción de las MA
- Los proyectos dependen de los datos como insumo, por lo tanto es muy importante el rol del product owner.
- Hay dos etapas en los proyectos de ML, una más exploratoria y experimental y otra más relacionada con la ingeniería tradicional y la integración de los modelos en aplicaciones o procesos batch. Scrum no está especialmente preparado para la primera etapa.
- Es muy importante que los equipos conozcan la metodología, esto no se puede dar por sentado y lleva tiempo.
- Cada uno de los entrevistados usó las definiciones de Scrum de manera diferente. La existencia de sprints con por lo menos una reunión de planning y una de cierre es común a todos.
