Implantación de la política Agile en proyectos y servicios TIC

Para la aplicación de las directrices enunciadas en el apartado anterior, el IMI ha desarrollado una metodología Agile basada en Scrum y adaptada a sus funciones como responsable de las TIC del Ayuntamiento de Barcelona.

Criterios básicos y estructurales

El IMI llevará a cabo los proyectos de manera alineada con la estructura organizativa del Ayuntamiento de Barcelona.

Aunque es viable combinar desarrollos ágiles y proyectos con metodologías tradicionales (enfoque “bimodal”), es más difícil gestionar las dependencias de los desarrollos con diferentes ciclos de vida y con otros roles externos. Por este motivo, se recomienda que la gestión de los proyectos de las unidades del Ayuntamiento (áreas, sectores y distritos) se haga en modo ágil o en modo tradicional, pero no combinando ambos modelos.

Además, dentro de una unidad municipal en la que se llevan a cabo todos los desarrollos en modo ágil, puede ser difícil absorber los picos de demandas sin sobredimensionar la capacidad de los equipos ágiles o sin alargar en exceso los tiempos de respuesta. En este caso, puede ser conveniente contratar proyectos tradicionales en paralelo.

Metodología Scrum@IMI

Los proyectos determinados como ágiles seguirán la metodología de desarrollo ágil de aplicaciones del IMI, denominada Scrum@IMI. Está basada en el marco de trabajo Scrum y tiene en cuenta prácticas de ingeniería provenientes de otros modelos, como DevOps.

Esta metodología se soportará bajo el uso de una plataforma ALM (application lifecycle management) con herramientas que incluirán, entre otros, los siguientes aspectos:

  • Planificación del desarrollo (releases, sprints, paquetes de trabajo, defectos, etcétera).

  • Repositorios de documentación, código y binarios.

  • Gestión de requisitos y pruebas.

  • Automatización de las pruebas unitarias y funcionales.

  • Integración y despliegue continuos.

  • Control de la calidad del código.

Su uso será obligatorio por parte del adjudicatario sin que le suponga un coste adicional en licencias.

Toda la documentación que se genere internamente en el desarrollo deberá gestionarse con las herramientas que se determinen al inicio del proyecto, preferentemente en formato wiki.

Las características principales previstas para esta metodología se comentan según su ciclo de vida en los apartados siguientes.

Los eventos (actividades e hitos) habituales de la metodología Scrum@IMI incluyen los siguientes pasos:

Evento Objetivos

Sprint

Ciclo de desarrollo, con una duración de dos a cuatro semanas, en el que se entrega una parte del sistema (incluidos todos los subproductos, como documentación y pruebas). El cliente puede optar por publicar o no el incremento entregado por el proveedor.

Planificación de sprint

Determinar, entre el product owner y el equipo de desarrollo la parte del producto que se hará durante el sprint.

Daily Meeting

El equipo de desarrollo monitoriza la ejecución del sprint y realiza las correcciones adecuadas. En caso de desviación, se avisa al product owner y al scrum master.

Revisión de sprint

El equipo scrum, con los actores externos invitados, examina el resultado del sprint y revisa el plan para los sprints siguientes.

Retrospectiva de sprint

El equipo scrum examina su funcionamiento propio y planifica mejoras concretas.

Roles y responsabilidades

La implementación de los roles de Scrum en el IMI se hace respetando al máximo los objetivos y las responsabilidades estándar de los roles, a la vez que se adaptan al contexto del IMI, que provee servicios complejos de gestión de TIC para el Ayuntamiento de Barcelona.

Los roles principales son los siguientes:

  • Product owner (Ajuntamiento)

  • Proxy product owner (IMI)

  • Scrum master (IMI o proveedor)

  • Equipo de Desarrollo (proveedor)

Product owner (Ayuntamiento)

El product owner (PO) es el rol que tiene como objetivo maximizar el valor entregado a los usuarios. Las mejores implementaciones del rol son aquellas en las que el PO está cerca de donde se toman las decisiones “de negocio”, razón por la cual con este rol se apodera a alguna persona clave de los sectores y las gerencias del Ayuntamiento. Este apoderamiento le permitirá poder conocer con transparencia y frecuencia el estado de los desarrollos, para poder controlarlo y tomar decisiones informadas.

El PO del Ayuntamiento típicamente tiene una alta carga de trabajo y muchos interlocutores con quienes trabajar. Esto hace que pueda tener poca dedicación a las actividades habituales del PO, como gestionar y desglosar el backlog del producto y dedicar tiempo al equipo de desarrollo. Por estos motivos, será frecuente que los PO tengan un rol asistente en el IMI, llamado proxy product owner. Esto, en ningún caso, debe restarle transparencia en las actividades del equipo ni en la capacidad de decisión.

Proxy product owner (IMI)

El proxy product owner (PPO) no es un rol estándar de Scrum, pero sí un patrón en situaciones en las que es difícil encontrar a un PO que tenga a la vez visión y capacidad de decisión desde el punto de vista de negocio, o bien también por razones de proximidad al equipo de desarrollo y de disponibilidad para estructurar y priorizar el backlog detalladamente. En el contexto del Ayuntamiento y del IMI, será frecuente que el IMI aporte este rol.

Equipo de desarrollo (Proveedor) El equipo de desarrollo, formado por un grupo de tres a nueve miembros (preferiblemente con perfiles polivalentes), lleva a cabo todas las actividades necesarias referentes al desarrollo del proyecto, con el objetivo principal de la mejora continua. Para hacerlo, el equipo interacciona con todos los roles del IMI necesarios, de los cuales el PO y el PPO serán los interlocutores principales con respecto al trabajo que se debe hacer, y el scrum master les servirá de guía metodológica y también de orientación organizativa dentro del IMI.

Scrum master (IMI / proveedor)

El scrum master (SM) tiene la misión de enseñar Scrum y utilizar el marco de trabajo para mejorar el valor y la efectividad del desarrollo del equipo. . En el contexto del IMI, esto lo consigue haciendo de guía de la metodología, llevando a cabo el seguimiento y los controles del rendimiento del equipo o bien, si hace falta, haciendo un entrenamiento individual a algún miembro del equipo. Adicionalmente, la figura del SM ayudará a hacer que el equipo se integre en torno al IMI y al Ayuntamiento, especialmente con los departamentos transversales.

Actividades

A continuación, identificamos los objetivos y el contenido de las actividades principales de la metodología Agile del IMI. En caso de se deba profundizar más detalladamente en alguna de estas actividades, se puede consultar la documentación proporcionada por el IMI en la wiki “espai Agile”.

Actividad: Planificación de entregas

La actividad de planificación de entregas se hace previamente a la construcción del producto, pero se puede planificar de nuevo durante esta actividad cuando se considere necesario. Su objetivo es actualizar y controlar la planificación de los sprints y las entregas, de manera consensuada entre todo el equipo scrum, con el liderazgo del product owner y del proxy product owner. El resultado de esta actividad es el plan de desarrollo, basado en la propuesta del adjudicatario a su oferta, y tendrá que ser conforme a los requisitos especificados en el pliego.

Actividad: Refinamiento del Backlog

La actividad de refinamiento del backlog se hace durante el desarrollo del producto y la lideran los roles de product owner y proxy product owner. Su objetivo es analizar funcional y técnicamente los paquetes de trabajo del backlog del producto.

Durante esta actividad se espera una alta interacción con las personas usuarias y otros roles del IMI. Es recomendable elaborar maquetas estáticas o prototipos dinámicos que incluyan las funcionalidades más importantes del sistema para que el usuario pueda validarlas.

Actividad: Sprint

El objetivo de esta actividad es la construcción del incremento del sistema, representado por el sprint backlog, correspondiente a las prioridades de negocio y técnica que consensúen el product owner y el proxy product owner con el equipo de desarrollo. Al final del sprint, el PO y el PPO son los responsables de hacer la validación y la aceptación formal de los paquetes de trabajo que formen el incremento, siempre con la asistencia del scrum master.

El incumplimiento por parte del adjudicatario al entregar los incrementos realizados al final del sprint podrá ser objeto de aplicación de sanciones por parte del IMI, tal como se detalla en la cláusula “Penalizaciones del pliego administrativo”.

Actividad: Transición

El objetivo de esta actividad es la entrega y la puesta en producción de los paquetes de trabajo que determine el product owner de manera alineada con las necesidades del usuario y otros actores del IMI, como los grupos de operaciones y de servicio de asistencia al usuario. Esta entrega puede ser puntual y bajo demanda durante el sprint (por ejemplo, para solucionar una incidencia urgente), o se puede hacer al final del sprint.

La aceptación de la actividad de transición está condicionada a la validación y aprobación, por parte del proxy product owner, del IMI. En caso de cambios de versiones significativos, la aceptación formal del proyecto se hará en una reunión del comité de dirección del proyecto. El hecho de no alcanzar los objetivos de esta actividad supondrá parar el proyecto.

Actividad: Operación

El objetivo de esta actividad, que será de interés para el adjudicatario en el caso de que el alcance de los servicios contratados incluya el apoyo al usuario, es dar apoyo de nivel 2 y 3 (conceptos de ITIL) al grupo de Servicio de Atención al Usuario (SAU) y a la Dirección de Operaciones.

El proxy product owner actuará como “responsable del servicio” cuando deba priorizar las incidencias identificadas y escaladas por los grupos de SAU y Operaciones y darles seguimiento. La sección de Apoyo a Usuarios describe los protocolos y los acuerdos de nivel de servicio (ANS) que determinan la prestación de este servicio.

Los equipos de trabajo y su gestión

El modelo scrum se puede implementar con equipos contratados de dos maneras: equipos para el desarrollo de nuevos proyectos y equipos de mantenimiento de aplicaciones (AM). A continuación, se pueden ver las diferencias que tienen en el contexto Agile.

Los equipos multidisciplinares deberían tener competencias para poder llevar a cabo las siguientes acciones:

  • Diseñar y construir un servicio digital.

  • Operar y mantener un servicio digital.

Las competencias que se necesitan cambiarán durante el ciclo de vida del servicio y podrán recibir el apoyo de roles adicionales.

Todo el equipo y, en especial, los diseñadores, los investigadores de usuario y los desarrolladores deben trabajar juntos para diseñar, construir y probar y entregar el producto.

Equipos para proyectos nuevos

Los equipos para proyectos nuevos se deben contratar con un alcance del servicio definido antes de iniciar el desarrollo. La definición del contrato requiere una conceptualización previa del sistema que se quiere construir, que se desarrollará conjuntamente entre el PO del Ayuntamiento y el PPO del IMI. Esta conceptualización debe incluir la creación de los siguientes elementos:

  • • Un backlog inicial que defina el alcance del desarrollo en forma de ítems o paquetes de trabajo.

  • • Un plan de entregas que identifique las entregas que se harán y qué sprints forman parte de las mismas.

Equipo de mantenimiento de aplicaciones (AM)

Los equipos de mantenimiento (AM) estarán contratados a priori e irán recibiendo peticiones de diversos tipos (correctivas, evolutivas y perfectivas), que se acumularán en el backlog. Las peticiones urgentes se atenderán cuanto antes mejor, siguiendo los objetivos del ANS. El resto de peticiones se planificarán para que se atiendan en sprints, probablemente de una duración más corta (por ejemplo, una semana) que los equipos de proyecto, ya que los paquetes habitualmente serán más pequeños e independientes.

3. Coexistencia entre los equipos de proyecto y los AM

La coexistencia entre los equipos scrum para desarrollar nuevos productos y los equipos scrum que los mantienen tendrá diversas casuísticas dependiendo del grado de libertad de los contratos con los proveedores y de la opción que consideren más oportuna el proxy product owner y el scrum master. Las opciones, en orden de más a menos ideal, son las siguientes:

  • El equipo de producto tiene integrados los miembros del AM, de manera estable, para trabajar conjuntamente en las mismas aplicaciones.

  • El equipo AM dispone de una dedicación temporal asignada para trabajar en el equipo de producto y preparar la transferencia de la aplicación una vez entregada al IMI.

  • El equipo AM no tiene una dedicación asignada para trabajar durante el desarrollo de la aplicación, pero tiene los incrementos frecuentes y los “hechos” para ir preparando la transferencia, y también podría participar puntualmente en las revisiones de los sprints.

Ejecución de proyectos

Los proyectos Agile gestionados por el IMI se deben ejecutar conforme a los principios siguientes, reflejados en el contrato correspondiente con los proveedores:

  1. Se seguirán las recomendaciones y las directrices metodológicas ágiles del IMI, como PPO, presentadas en el pliego y dentro del espacio Agile del IMI, así como las que sean contextuales y que transmita el scrum master, que observará un principio general de respeto a la autogestión del equipo.

  2. Habrá que tener disponible, al final de cada sprint, un entregable o incremento de producto pactado (software de incremento) que cumpla con los mínimos de calidad definidos en el espacio Agile. En caso de que sea imposible entregar todos los contenidos planificados, prevalecerá la calidad sobre la cantidad.

  3. Habrá que ser transparente con el scrum master (y eventualmente con el PPO) ante los posibles problemas internos del equipo, así como ante los impedimentos externos, para buscar conjuntamente las mejores soluciones a los problemas puntuales y estructurales del desarrollo.

  4. El proveedor utilizará las herramientas corporativas, así como las normas metodológicas mínimas que favorezcan la interoperabilidad entre equipos, como el idioma, la estructura y el nivel de detalle de la documentación del código y otros apoyos documentales.

  5. El equipo responsable de los niveles 2 y 3 de la gestión de incidencias del servicio deberá tener conocimientos mínimos de sistemas y trabajar con el IMI de la manera más integrada posible. En un futuro se prevé que, en función de las capacidades de automatización del despliegue de la plataforma usada, el equipo podrá desplegar el sistema de manera autónoma en los entornos de preproducción y producción.