Metodologías ágiles para el desarrollo de aplicaciones basadas en procesos de negocio como servicio (BPMaaS): (I) Scrum

El nuevo paradigma de desarrollo de aplicaciones basadas en procesos de negocio como servicio (BPMaaS), alineada con la guía para la prestación de aplicaciones en modo servicio de laAGE [1], actúa como motor principal para la transformación digital de las organizaciones a través del desarrollo de aplicaciones modernas utilizando metodologías ágiles.

Este artículo pretende poner el foco en el estado del arte de las metodologías ágiles actualmente existentes para la gestión de proyectos de este nuevo paradigma de desarrollo de software y alinear el ciclo de vida de estas aplicaciones como servicio (BPMSasS) a las capacidades de gestión y seguridad de los servicios CIS/TIC de forma centralizada y transversal a toda la organización, para desarrollar aplicaciones modernas utilizando metodologías ágiles que cierren la brecha entre negocio y TI.

Metodología para el desarrollo ágil de las BPMaaS que debe fundamentarse en el manifiesto para el desarrollo de software ágil [2]: 

“Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo.
A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software de trabajo sobre documentación completa.
Colaboración del cliente sobre negociación de contrato.
Responder al cambio sobre seguir un plan.
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda que faciliten la gestión de proyectos.”

Manifiesto que sigue los siguientes doce principios [3]:

“1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.”

A continuación se realiza un recorrido por las buenas prácticas y metodologías ágiles existentes en el estado del arte del desarrollo de aplicaciones BPMaaS como son: Scrum, BPM: RAD^® (Rapid Analysis & Design) y la metodología de Playbacks de IBM .

(I) Metodología Scrum

Scrum es un framework o marco de trabajo para el desarrollo ágil de software enfocado en satisfacer las necesidades del cliente en el menor tiempo posible y donde equipos multidisciplinares formados por personal de negocio y de TI colaboran y se autogestionan para fijar el alcance, los requisitos y abordar el desarrollo e implementación a través de un ciclo de vida de desarrollo iterativo e incremental donde en periodos cortos de tiempo denominados sprint (2-4 semanas) se entrega el software funcionando o se decide si es necesario mejorarlo en el siguiente sprint [4].

Los roles que participan en el ciclo de vida de Scrum son los siguientes [5]:

a) Patrocinador (Sponsor): Orienta al dueño del producto y está interesado en el valor generado y el coste incurrido.

b) Dueño del producto (Product owner): Es el conocedor del proceso a automatizar, determina “qué se hará”. Decide las fechas y el contenido de los entregables, actualiza las funcionalidades y prioridades entre cada sprint. Representa a las partes interesadas o stakeholders y maneja sus expectativas.

c) Equipo de desarrollo (Development team): Equipo que determina cómo se hará el trabajo y que se auto-organizará para conseguirlo. Está compuesto por expertos en procesos, en datos, en integración de aplicaciones y en infraestructuras de TI.

d) Facilitador (Scrum Master): Líder del equipo y responsable de resolver cualquier problema que pueda surgir en el proyecto.

En el ciclo de vida de Scrum se debe tener en cuenta los siguientes conceptos y artefactos [4]:

1. Product backlog o Cartera de Proyectos BPMaaS. Depósito de datos que contiene la lista unificada y priorizada de funcionalidades de negocio a alto nivel o procesos candidatos a automatizar.

Product backlog o lista unificada y priorizada de procesos candidatos a automatizar (elaboración propia)

2. Sprint backlog o pila del sprint. Se toma de la cartera de proyectos BPMaaS o product backlog el proceso identificado y priorizado y se divide en funcionalidades más pequeñas priorizadas para que el equipo de desarrollo las aborde en el próximo sprint. Incluye la estimación del esfuerzo pendiente de realizar, no es un compromiso firme sino un pronóstico ya que el único compromiso de un sprint es su caja de tiempo o timebox (1). Para identificar estas funcionalidades se utilizará la técnica de las historias de usuario que según Max Rehkoff se puede resumir en [7]:

“una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.

[…]Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura: “Como [perfil], [quiero] [para].”

Sprint backlog (elaboración propia)

3. Reunión diaria de seguimiento (Daily scrum meeting). Reunión diaria de 15 minutos de duración para monitorizar el ritmo de avance del sprint, sirve para detectar lo antes posible las desviaciones que pudieran comprometer la fecha final prevista de entrega del sprint. Como herramienta para medir el esfuerzo que falta por hacer se utiliza el gráfico de avance o burndown chart.

4. Gráfico de avance (Burndown chart). Permite monitorizar el avance de un trabajo para alertar lo antes posible de circunstancias que puedan comprometer la fecha de fin prevista. Sobre el eje de abscisas de un plano cartesiano se representa el calendario previsto para realizar el trabajo (unidad de tiempo en días) y sobre el eje de ordenadas se representa la cantidad de trabajo que hay que hacer (la medida de trabajo empleada suele ser en puntos de historia de scrum o en tiempo ideal para realizarlo).

Gráfico de avance o burndown chart (Fuente: [8])

“Los puntos de historia representan un valor que sólo será relevante para el equipo de scrum, y que se usará para estimar el tamaño de una tarea (también llamada ítem, en inglés) en el backlog. Permite al equipo determinar qué tareas pueden realizar en un sprint. El product owner (“dueño del producto” en su traducción literal) podrá ver, por los puntos de la historia, qué tareas fueron relativamente complicadas de hacer por el equipo. Los puntos dan una idea del tamaño y el esfuerzo que se necesita para que las tareas sean realizadas.

El valor de los puntos de la historia se basa en la serie de Fibonacci. En esta serie, el siguiente número es la suma de los dos anteriores; donde los valores 20, 40 y 100 están principalmente para indicar que una tarea o ítem es muy grande. En la práctica, estos ítems suelen dividirse en ítems más pequeños.

Gracias a los puntos de historia, un equipo de scrum puede crear una unidad para ellos mismos y así estimar las historias de los usuarios. Los puntos representan un valor relativo, y pueden ser diferentes para cada equipo.

[…]¿Cómo determinar el punto de historia?
Para determinar el número de puntos de una historia de un usuario, el equipo deberá considerar tres factores:
Dificultad ¿Cuánto esfuerzo requiere completar la historia del usuario, según la definición de hecho?
Complejidad ¿Qué tan complejo es crear la historia del usuario? ¿Es una tarea sencilla o un desafío?
Incertidumbre ¿Cuáles son las posibilidades de encontrar sorpresas que no habíamos previsto de antemano?
Juntos, estos factores determinan el número de puntos en una historia de usuario. Por ejemplo, ¿La complejidad, el riesgo y el esfuerzo son bajos? Entonces la historia también tendrá un punto bajo.
En resumen...
Los puntos de historia son un valor relativo que creas junto con tu equipo de Scrum. Proporcionan una visión del esfuerzo que se necesita para crear una historia de usuario. El propietario del producto podrá, de esta forma, decidir si da prioridad o no a un determinado elemento. Y el equipo sabrá cuántos puntos de historia puede recoger por cada sprint.” [9].

El sprint backlog contiene la lista de tareas priorizadas con la estimación del esfuerzo pendiente de realizar. Así pues, cada día el equipo scrum actualiza el gráfico de avance con el esfuerzo total de todas las tareas pendientes de terminar.

5. Reunión de planificación del sprint (Sprint planning meeting): Reunión para definir el producto a entregar en el incremento del sprint y planificar las tareas a realizar para conseguirlo. Participa todo el equipo scrum: scrum master, el dueño del producto y el equipo de desarrollo. La duración es variable, por lo general para un sprint de un mes no más de ocho horas. El proceso candidato a automatizar se selecciona de la cartera de proyectos BPMaaS o product backlog y se coloca en la pila de sprint.

“La Definición de Hecho (Definition of Done) permite: Tener siempre un producto “potencialmente entregable y usable” al finalizar cada iteración, con el mínimo esfuerzo, no dejar trabajo pendiente para el final, escondido “debajo de la alfombra”, que pueda impedir utilizar los resultados del proyecto lo antes posible.

[…]La Definición de Hecho se acuerda entre el Product Owner (cliente) y el Equipo de desarrollo al principio del proyecto y se puede ir mejorando durante su transcurso (si es necesario precisar más las expectativas en cuanto a calidad global o del proceso de trabajo o, simplemente, tras una Retrospectiva, para ir consiguiendo una mejor calidad del producto final).

[…]La Definición de Hecho en la Planificación de la iteración (Sprint Planning).

La Definición de Hecho tiene un impacto en tareas específicas a realizar por el equipo de desarrollo en cada iteración, por lo que se utiliza como guía para generar tareas en la Planificación de la iteración (Sprint Planning) (además de los criterios de validación de cada objetivo/requisito).

Criterios de Aceptación vs Definición de Hecho.

Cada objetivo/requisito tiene asociados sus criterios de aceptación, los cuales definen cómo se va a probar/demostrar que un objetivo/requisito ha sido conseguido. Se acuerdan entre el Product Owner (cliente) y el Equipo de desarrollo en una conversación que permita reducir la ambigüedad en QUÉ se espera sobre cada requisito / objetivo.

Los criterios de aceptación de los objetivos/requisitos a trabajar en una iteración se recogen en la Planificación de la iteración (Sprint Planning) (o antes, si fuese necesario, para empezar a preparar la información que se utilizará en el desarrollo del objetivo-requisito).

Notar pues que el concepto de “Definición de Hecho”, transversal a todos los temas (objetivos), es diferente del concepto de “Criterios de Aceptación”, que afecta a cada tema (objetivo) en particular.

En cada iteración, el equipo revisa los criterios de aceptación de cada objetivo / requisito finalizado (y el cumplimiento de la Definición de Hecho general) antes de su aceptación por el Product Owner. Es decir, tanto el Product Owner como el equipo de desarrollo utilizan los criterios de aceptación (y la definición de hecho) como checklist para aceptar cada tema y darlo por hecho.” [10].

6. Reunión de revisión del sprint (Sprint review). Reunión tras finalizar la demostración del sprint para conocer la retroalimentación o  “feedback” de las partes interesadas o stakeholders y en su caso adaptar el incremento del sprint.

7. Reunión de retrospectiva del sprint (Sprint retrospective): Reunión interna del equipo scrum al final de cada sprint para buscar oportunidades de mejora en la siguiente iteración.

Metodología Scrum adaptada al desarrollo de las aplicaciones BPMaaS (elaboración propia)

A modo de conclusión, una metodología para el desarrollo de aplicaciones BPMaaS debería tener en cuenta las siguientes buenas prácticas:

• Fijar el alcance, los requisitos y abordar el desarrollo e implementación a través de un ciclo de vida de desarrollo iterativo e incremental con periodos cortos de tiempo denominados sprint (2-4 semanas) para entregar software funcionando o decidir si es necesario mejorarlo en el siguiente sprint.
• Disponer de un depósito de datos que contenga la lista unificada y priorizada de procesos de negocio candidatos a automatizar (product backlog).
• Dividir en funcionalidades más pequeñas y priorizadas el proceso de negocio candidato a automatizar para que el equipo de desarrollo las aborde en el próximo sprint. Incluye la estimación del esfuerzo pendiente de realizar, no es un compromiso firme sino un pronóstico ya que el único compromiso de un sprint es su caja de tiempo o timebox.
• Realizar diariamente una reunión de seguimiento utilizando el gráfico de avance o burndown chart para detectar lo antes posible posibles desviaciones que puedan comprometer la fecha final prevista de entrega del sprint.
• Definir los criterios de aceptación de cada historia de usuario por parte del dueño del proceso de negocio.

---

(1) “La técnica del timebox consiste en fijar el tiempo máximo para conseguir unos objetivos, tomar una decisión o realizar unas tareas, y hacer lo mejor que podamos en ese intervalo” [6]. 

Bibliografía:

[1] Dirección de Tecnologías de la Información y las Comunicaciones, Guía para la prestación de aplicaciones en modo servicio, 1^a edición. Subdirección General de Información, Documentación y Publicaciones, 2016.

[2] “Manifiesto para el desarrollo ágil de software.” https://agilemanifesto.org/ (accessed Nov. 14, 2021).

[3] K. Beck, “Principios del Manifiesto Ágil,” agilemanifesto.org, 2001. https://agilemanifesto.org/iso/es/principles.html (accessed Nov. 14, 2021).

[4]    “Cómo funciona Scrum – Proyectos Ágiles,” 2018. https://proyectosagiles.org/como-funciona-scrum/ (accessed Dec. 12, 2020).

[5]    “Base de conocimiento – Proyectos Ágiles.” https://proyectosagiles.org/base-conocimiento-agil/#fundamentos-scrum (accessed Dec. 25, 2020).

[6]    “Timebox – Proyectos Ágiles.” https://proyectosagiles.org/timebox/ (accessed Dec. 25, 2020).

[7]    “Historias de usuario | Ejemplos y plantilla | Atlassian.” https://www.atlassian.com/es/agile/project-management/user-stories (accessed Jan. 03, 2021).

[8]    “Gráfico de avance - Scrum Manager BoK.” https://www.scrummanager.net/bok/index.php?title=Gráfico_de_avance (accessed Dec. 25, 2020).

[9]    “SCRUM y los puntos de historia, ¿Cómo funcionan? | Incentro.” https://www.incentro.com/es-es/blog/stories/scrum-puntos-de-historia-como-funcionan/ (accessed Dec. 12, 2020).

[10]    “Definición de Hecho (Definition of Done) – Proyectos Ágiles.” https://proyectosagiles.org/definicion-de-hecho-definition-of-done/ (accessed Dec. 12, 2020).