Scrum: metodología ágil al servicio de los adultos mayores en proyecto Delirium

La unión entre ingeniería y medicina ya está declarada. De un simple romance que comprendía un puñado de proyectos, se está formando una promisoria relación que sueña con un centro de ingeniería en salud en Laguna Carén, en una red que aúne médicos e ingenieros a lo largo del territorio y proyectos transcontinentales que rompan con todas las barreras que limiten el crecimiento científico nacional.

En esta osadía, y como en toda relación incipiente, nos vemos enfrentados a tan silvestres ajustes como es el de la jerga, el inmiscuirse en la cultura del otro, hablar desde su lenguaje y mirar con sus ojos la realidad propia y la nueva que se nos ofrece descubrir. Es así como en el proyecto Delirium, quienes nos pidieron nuestro apoyo para postular, nos requirieron lo que ellos entendían como un software. Uno de los astutos postulantes propuso para este software la metodología ágil de desarrollo llamada Scrum. Poco conocida para la mayoría de los ingenieros, totalmente oscura para los médicos, es finalmente la metodología de creación de software que se empezó a implementar, respetando la postulación ganada.

Surgieron dos preguntas al respecto, la primera por los legos de la programación: ¿qué es Scrum? La segunda para los familiarizados con el desarrollo de software: ¿cómo justifican el uso de Scrum para este proyecto? Ambas preguntas encuentran respuesta en esta nota explicativa.

Metodologías de Desarrollo de Software

Partamos desde el comienzo: el desarrollo de software comienza más formalmente en la década de 1960, sí, antes del primer computador personal. En el mundo de los negocios se buscaba desarrollar a gran escala en los grandes conglomerados empresariales. La idea principal era el desarrollo de sistemas de información muy estructuradamente y de forma metódica, respetando etapas de ciclo de vida. Estos sistemas estaban pensados para el procesamiento de datos y rutinas de cálculos complejos para la época. La idea era muy simple, como todo proyecto productivo, de los que se conocían hasta la época, el proyecto de desarrollar un software tendría en general cinco etapas: análisis de requerimientos, una etapa de diseño, otra de desarrollo, una cuarta etapa de pruebas y validación, y el cierre del proyecto como etapa final que consistía en entregar el producto y mantenerlo. Con plazos definidos, extensa documentación y requerimientos inmutables, estos métodos fueron llamados tradicionales, y funcionaron y funcionan bastante bien para una variedad de grandes proyectos de software cuyos resultados disfrutamos hoy. Con sus distintas variaciones, estos métodos adquirieron distintos nombres, dependiendo de la secuencia de sus etapas. De ahí surgen nombres como Metodología Cascada, Espiral, Incremental, Prototipado, etc.

Ya en los ’80 del siglo pasado, surgieron grandes próceres de desarrollo, tales como Nonaka, Takeuchi y Schwaber, a los que no les acomodaba la rigidez de los métodos tradicionales. Lo que ellos buscaban era una forma eficiente de crear soluciones aun no bien definidas, mostrarle algo rápido a sus clientes para bajarles la ansiedad, entrar en diálogo con ellos e iterar con cada conversación para crear finalmente lo que ellos deseaban. Estos científicos educados en la época de las flores buscaban finalmente libertad, un marco amplio donde la creatividad estuviera enfocada más en el desarrollo de un bien útil antes que en cumplir plazos, reglas de grandes corporaciones, presupuestos limitados, y ataduras creadas en un comienzo por los vendedores de tecnología. Es así como nacen las metodologías ágiles, con menos documentación (o una forma distinta de documentar, donde el mismo código bien comentado es un componente esencial), plazos no tan fijos, requerimientos que pueden aparecer o desaparecer en el camino dependiendo de los diálogos con el usuario final, sugerencias del desarrollador y, lo más llamativo, pequeños “productos finales” periódicamente para probar constantemente lo que se está creando.

Existen varias metodologías ágiles, pero, aquí entre nosotros, Scrum es la mejor. Pese a ser la más antigua (1986), es la más popular, la más conocida, la más usada y la más documentada. Por lejos le lleva la delantera a KANBAN, Crystal Clear y DSDM, aunque éstas se sigan ocupando en determinadas compañías.

Scrum

En Scrum hay que aprender 3 cosas: Roles, Artefactos y Procesos. Por cierto, Scrum es fácil de aprender, lo que constituye una de sus ventajas.

Existen 3 Roles: Dueño del proyecto, Scrum Master y Equipo. Es importante en la metodología que no existan más roles que éstos, pues entre menos personas interfieran en el proceso creativo se logra mayor eficiencia. En jerga de esta metodología, se le intenta dar mucho poder a los cerdos y nada a los pollos. Esto viene de una fábula muy común en los libros de Scrum, la parábola de la gallina y el cerdo:

Cuenta la historia que había una gallinita emprendedora que quería montar un restaurante en la granja. Para llevar a cabo su idea necesitaba un socio. Así que se dirigió hacia el animal que más confiabilidad le daba: el cerdito. – Hola Cerdito – le dijo la gallina. Quiero abrir un restaurante en la granja y he pensado que tal vez querrías ser mi socio. – Buena idea – respondió el cerdito. ¿Cómo se llamaría el restaurante? – ¿¡Qué te parece “huevos con tocino”!? – respondió la gallina. El cerdito pensándolo un poco rechazó la oferta: -No gracias. Creo que tú estarías involucrada pero yo tendría que estar entrañablemente comprometido.”

La idea es que las decisiones pasen más por quienes pondrán su esfuerzo en que las cosas funcionen, los que estarán día a día trabajando en las tareas, los que sentirán dolor cuando las cosas no vayan tan bien, los que celebrarán aliviados y felices cuando vean la obra terminada. Ellos han de tener más autoridad que aquellos que raramente van a las reuniones, lanzan unas ocurrencias peregrinas y luego vuelven al tiempo a sorprenderse con resultados. Esto es parte crucial de la filosofía Scrum.

La autoridad debe dársele a quienes están comprometidos, el Scrum Master, el Team y el Project Owner

El Dueño del proyecto es el cliente para todos los efectos. Él debe tener la autoridad para establecer los requisitos, aprobar los cambios y proponer nuevas funcionalidades. El Scrum Master es el director de orquesta, quien debe asegurarse que todos los protocolos y ceremonias de la metodología se respeten. Pues sí, esto no es libertinaje, existen protocolos y ceremonias. Pese a tener más flexibilidad que otras, una metodología de desarrollo de software es tal cuando cumple con cuatro elementos: una filosofía de desarrollo, múltiples herramientas y métodos, una buena documentación y una organización que la sustente. El Scrum Master se esfuerza en que todo esto exista. Además, sirve como puente entre el Dueño del Proyecto y el Equipo de desarrollo, haciendo las veces de intérprete cuando ambos lenguajes no son similares. Por último, está el Equipo de Desarrollo, aquellos que, sujetos a su escritorio, hacen la magia de transformar los sueños en un producto real.

La metodología propone además el uso de Artefactos. Son simples herramientas de planificación y control. Básicamente hay tres:

  1. Backlog del producto: es la lista de los requerimientos del software. Nunca está completo pues es dinámico. Sus registros iniciales corresponden a la primera idea que se tuvo en la planificación, pero pueden ir cambiando. El Dueño del Proyecto es el responsable de los contenidos y su priorización.
  2. Backlog de Sprint: es la lista de los requerimientos del sistema para el mes al que pertenece el Sprint (que es una iteración, como se verá más adelante). De aquí nacen las tareas para el equipo. Cada requerimiento es atendido por tareas de no más de 16 horas de duración estimada, ni menos de 4.
  3. Incremento de funcionalidad: Es la tabla que contiene los requerimientos funcionales y su estado de realización, considerando su documentación correspondiente. Si el Dueño del Proyecto necesita el producto en cualquier momento, puede contar con los requerimientos que están en estado de ’Completado’.

Por último, Scrum propone un gran Proceso que se puede caracterizar como una serie de iteraciones, llamadas Sprint y que por lo general son mensuales, con ceremonias de inicio y término. A continuación, se proponen los hitos más esenciales:

  1. Reunión inicial: En ella se reúnen todos los roles. El objetivo es obtener una visión del producto, aunque sea una idea medianamente vaga. Ésta dará una lista de requerimientos de usuario, llamada Backlog. Luego todo el trabajo es hecho en Sprints.
  2. Reunión de comienzo de Sprint: Nuevamente se reúnen todos los roles para dar inicio a la iteración mensual. Aquí se priorizan las tareas que deben ser trabajadas durante el Sprint que comienza.
  3. Reunión de finalización de Sprint: Todos son convocados para evaluar el Sprint que termina, presentar el desarrollo de los últimos 30 días, desechar o postergar las tareas pendientes y evaluar en general el trabajo realizado. En proyectos grandes, las reuniones de comienzo y la de término del Sprint son distintas, pues podrían llegar a durar 4 y 8 horas respectivamente. Sin embargo, si el proyecto es más pequeño, ¿por qué no hacer las dos de corrido? En el proyecto Delirium se optó por esta opción.
  4. Ceremonia diaria: El Scrum Master junto con su Equipo se juntan al iniciar cada día sólo 15 minutos. En ella cada miembro del equipo dice qué ha estado haciendo, qué va a hacer ese día y que impedimentos o bloqueantes ha encontrado al intentar hacer su trabajo. De esta forma se sincroniza el trabajo de todos los miembros y se planifican reuniones excepcionales que algunos miembros requieran con otros miembros del equipo.
  5. Reunión final: Una vez que el producto está terminado y el Dueño del Proyecto conforme, se entrega el software con toda la documentación (no exhaustiva sino más bien funcional) y se cierra el desarrollo.

    Iteración Scrum

    Esquema del proceso Scrum

Queda respondida entonces la primera pregunta: ¿Qué es Scrum? Resumidamente, una metodología ágil de desarrollo de software compuesta de roles, procesos y artefactos; todos ellos descritos en los párrafos anteriores.

Justificación de Scrum en el proyecto Delirium

Es legítima la pregunta acerca de la relación entre una metodología de programación ágil y la prevención del Delirium en adultos mayores. Para entender la historia completa hay que ir por partes.

La historia comienza en la facultad de medicina de la Universidad de Chile, donde se unieron tres equipos de investigadores interesados en algo similar: disminuir el delirium en Chile. El delirium es una condición clínica consistente en una aguda disminución de las capacidades cognitivas, una rápida neurodegeneración, producida generalmente en adultos mayores hospitalizados. Las consecuencias son nefastas, pues van desde la pérdida de autonomía hasta una muerte precoz, y hay que considerar el tremendo costo emocional, económico y social que ha de padecer la familia. Este delirium es un descubrimiento relativamente nuevo, con no más de un siglo de antigüedad, pero el tratamiento no farmacológico de éste es una completa novedad a todas luces, sobre todo en nuestro país. Es así como estos investigadores, una potente mezcla de médicos y terapeutas ocupacionales, se unieron para trabajar arduamente en una forma de prevenir esta condición a través de visitas, ejercicios físicos y mentales y manejo ambiental entre otras técnicas. El resultado fue maravilloso. El efecto positivo de este tipo de terapias fue tan concluyente que nació una publicación de alto impacto en una prestigiosa revista internacional. El paso lógico era replicar esta terapia a todo el país y librar a la nación del mal del delirium. Parece sencillo dicho de ese modo. El único problema es que se necesitaría multiplicar por 43 la cantidad de terapeutas ocupacionales dedicados a este tipo de labores para cubrir la demanda en hospitales y clínicas por este tratamiento. Simplemente imposible. Frente a este panorama surgió la novedosa idea, acorde al nuevo siglo en que nos adentramos, de que una Tablet pudiese suplir este rol. Así, tal cual. Una Tablet que le diga al adulto mayor hospitalizado la fecha y la hora, el lugar donde se encuentra y porqué está allí. Un software que le haga preguntas de ingenio, que refresque su capacidad cognitiva, que lo haga acordarse de tantas cosas que ha aprendido y vivido en su vida. Con este aparato podrá también hacer ejercicios guiados para que sus músculos no se atrofien y para que no desarrolle escaras. En fin, una compañía constante, un suplente a bajo costo de un terapeuta ocupacional que vele por su salud y bienestar previniendo el delirium.

El Delirium ataca entre un 10 y 14% de los adultos mayores que se someten a cirugía general.

Ahora se entiende porqué se necesita desarrollar un software. Pero ¿por qué Scrum? Porque pese a que se cuenta con un tratamiento tipo que funciona, no se sabe qué se le puede pedir a la herramienta y qué no. Ni siquiera se sabe bien si los adultos mayores podrán ocupar esta Tablet con todas las funcionalidades que esta pudiera ofrecer. Es por ello que durante este año 2017 en que se está desarrollando la herramienta, los dueños del proyecto guiarán focus groups y realizarán pruebas con las funcionalidades creadas, para saber qué servicios tiene que ofrecer y cuáles no. Es decir, se cumplen con las características para una metodología ágil, pues se necesita un pequeño producto final periódicamente para los clientes y los requisitos no están bien definidos desde un comienzo. Dado que se necesita una metodología ágil, se escoge Scrum. ¿Por qué no otra? Simplemente porque Scrum es genial. Pero para fundamentar aún más, ya se ha ocupado en el WIC y ha funcionado bien, la documentación es la más abundante y ha sido fácil de transmitir para todas las partes. Finalmente sigue siendo un medio, pues el fin ulterior es poder impactar positivamente en la vida de tantas personas que anhelan poder seguir disfrutando de la sabiduría de nuestros adultos mayores y mejorarles su calidad de vida. Para ellos, para nuestros padres y abuelos que tanto nos han dado, todo nuestro mejor esfuerzo.

Publicado en Artículos y etiquetado , , , .

Un comentario

  1. En los tiempos actuales es de suma importancia el diálogo interdisciplinario y se hace más relevante cuando los avances del conocimiento y la investigación van en la dirección de resolver problemas sociales que nos afectan hoy en día. Teniendo en consideración el aumento de la esperanza de vida y entre ellos un número importante de la población adulta mayor en quienes se expresa el deterioro de sus capacidades. Me parece bastante novedoso realizar intervenciones sin suministrar fármacos, siendo el software una alternativa importante para acompañar los procesos de Delirium en la población.
    Felicitaciones y ahora a seguir desarrollando esta herramienta.

Deja un comentario

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