Objetivo 

Modelar la forma en la que se responde a los requisitos cambiantes del negocio, asegurando que los cambios se registran y se evalúan con el objetivo de dar valor reduciendo al mínimo el número de incidencias y las interrupciones del servicio.

Alcance

Este proceso se aplica a la gestión de los cambios en los productos o aplicativos centralizados que se gestionan en la STIC. Dichos productos siempre deben estar dados de alta en el sistema de gestión de la configuración (CMS) como elementos de configuración software de tipo aplicación.

Existen dos metodologías en la STIC para gestionar los cambios en los aplicativos centralizados:

• Metodología en cascada
• Metodología ágil

Roles

Independientemente de la metodología que se use, los roles que intervienen en este proceso son:

Flujo del proceso

Gestión de la demanda

El primer paso consiste en gestionar la demanda que crean los usuarios en formas de mejoras. Todas esas mejoras llegan al Responsable funcional quien debe seleccionar entre aquellas que aportan valor a su producto y aquellas que no lo aportan, bien porque no vayan de acuerdo con la estrategia seguida por la STIC o simplemente porque aún siendo interesante, se le haya podido ocurrir antes a otro usuario. Por tanto, es necesario "aprobar" aquellas mejoras que aportan valor y clasificaras en urgencia para que se acometan con mayor o menor premura.

El proceso consta de los siguientes pasos:

• Primer paso (Responsable de  producto y/o Responsable funcional): determinar las mejoras viables y rechazar tanto las no viables como las repetidas y aquellas que entran en el sistema como mejoras y que realmente no lo son.
• Segundo paso (Responsable de producto y/o Responsable funcional): ordenar la demanda aprobada por la urgencia con la que necesita ser acometida.
• Tercer paso (Responsable de producto): Acometer el desarrollo de las mejoras más urgentes y tener como objetivo la implantación de aquellas incidencias que están a la espera de ser solucionadas por parte del usuario. Llegados a este tercer paso, es cuando se distinguen dos formas de gestionar los productos:
  • Metodología en cascada: creación de versiones
  • Metodología ágil: descomposición en historias de usuario y creación de sprints

Metodología en cascada

La unidad de gestión es la VERSIÓN, entendida como un contenedor de alcance que hay que desarrollar e implantar en un tiempo determinado, con un coste asignado y con una calidad máxima.

El alcance de una versión está determinado por MEJORAS (lo lógico es incluir aquellas más urgentes) que hay que desarrollar por parte del Proveedor e INCIDENCIAS que constituyen errores de la versión del producto en producción que necesitan para ser corregidos una modificación del código y por tanto una implantación.

Veremos más adelante que también pueden formar parte del alcance de una versión fallos que se hayan encontrado en versiones anteriores antes de estar en Producción y que, por necesidades del negocio, no hayan podido ser corregidos en la versión en la que se han detectado y se haya decidido corregirlos en versiones posteriores. Estas incidencias detectadas en entornos no productivos se denominan No Conformidades y pueden por tanto, formar parte del alcance de una versión.

La versión necesita para poder comenzar tener al menos una mejora/incidencia/no conformidad en su alcance. Normalmente para que una versión se comience debe ser aprobada por el Responsable de área correspondiente, aunque existe la opción de que esa aprobación esté delegada en el Responsable de producto.

Una vez que la versión ha comenzado, el Responsable de producto va creando órdenes de trabajo al proveedor para completar las diferentes fases del ciclo de vida: requisitos, análisis, diseño, construcción e implantación.

Estas órdenes tienen establecidos una serie de entregables obligatorios que deben ser aportados por el proveedor y revisados y aceptados por el Responsable de producto.

Además, el Responsable de producto debe aceptar y justificar, si procede, las posibles desviaciones en coste y plazo de ejecución de cada una de esas órdenes de trabajo.

Cada mejora que se desarrolla puede ser validada antes de su subida a Producción. Cualquier fallo o defecto detectado pasa a registrarse como una No Conformidad, que deberá ser solucionada por el Proveedor, y que, como hemos comentado antes, puede formar parte del alcance de una versión.  

Hay dos tipos de órdenes de trabajo:

• Órdenes de trabajo con crédito disponible: el Responsable de Producto es quien determina el techo de coste o esfuerzo en HBS requerido para la orden. El Proveedor se limita a, teniendo ese techo de coste asignado, planificar las fechas en las que va a hacer el trabajo. Hay diferentes tipos de órdenes de trabajo con crédito disponible:
  • OTEVS (Estudio de viabilidad del sistema). Son las únicas órdenes de trabajo que pueden crearse con la versión sin haber comenzado, incluso pueden crearse para más de una versión. Sus incurridos no se tienen en cuenta en el cómputo de las HBS de la versión.
  • OTR (Requisitos)
  • OTInmediata
  • OTEquipo (para equipos dedicados que trabajan con esta metodología)
  • PST (Petición soporte Transición): son peticiones de ayuda del área de Proyectos al Proveedor de sistemas
• Órdenes de trabajo con estimación: como su propio nombre indica, es necesario que el Proveedor estime el coste/esfuerzo de la orden y que planifique las fechas en las que podrá ser realizada. Esa estimación deberá ser aprobada por el Responsable de producto, y será realizada por el Proveedor tantas veces hasta que sea finalmente aprobada. Hay diferentes tipos de órdenes de trabajo con estimación:
  • OTA (Análisis)
  • OTD (Diseño)
  • OTC (Construcción)
  • OTAD (Análisis y diseño)
  • OTADC (Análisis, diseño y construcción)
  • OTImpl (Implantación)
    
    

Una vez que se haya finalizado la construcción de las mejoras y llegue el momento de desplegar en un entorno, habrá que tener en cuenta si es la primera versión del producto que se va a desplegar. En este caso, habrá sido necesario construir la plataforma en la que se va a hacer el despliegue. (Ver Proceso de Gestión de plataformas).

Una vez que la plataforma o plataformas en las que hay que realizar el despliegue están construidas, es necesario hacer la petición de lanzamiento para el despliegue en esas plataformas y en los entornos en los que se quiera implantar la versión del producto. (Ver Proceso de Gestión de lanzamientos).

Cuando se hayan hecho todas las posibles implantaciones para una versión, es el Responsable de producto quien considera que la versión está implantada, lo que supondrá la implantación de todas las mejoras, incidencias y no conformidades que constituían el alcance de la versión. Esto no implica que la versión se pueda finalizar, puesto que es posible que queden órdenes de trabajo sin acabar o incluso que fuera necesaria la creación de una orden de trabajo para que el proveedor impartiera formación. Una vez que todas las órdenes de trabajo están cerradas, la versión se puede finalizar.

La implementación de este proceso se hace en JIRA. Accediendo al enlace podrás ver el manual en el que se detallan los tipos de entidades, los estados y las acciones por estado, así como los roles que pueden ejecutarlas.

El proceso de Gestión de productos está ligado al de Gestión del conocimiento, ya que el Responsable de producto debe velar porque todo el conocimiento asociado a su producto sea:

• Centralizado en un único sitio.
• Accesible para todo el que lo necesite con una fácil gestión de acceso.
• Usado como gestor documental para los entregables de las órdenes de trabajo que acomete el proveedor.
• Estructurado de modo similar en todos los productos.
• Integrado con la herramienta en la que se gestiona el producto.

La gestión del conocimiento se hace mediante espacios en CONFLUENCE, de modo que cualquier producto siempre va a tener asociado un espacio en el que se custodie toda la información que afecte a su producto y del que el Responsable de producto va a ser administrador. Todos los espacios tendrán una misma estructura y cada vez que se cree una versión del producto se creará una página dentro del espacio que se actualiza automáticamente con la información de JIRA, estructurada con la información de gestión (OTs de la versión y calendario), alcance y entregables. Cualquier otar información relacionada con la versión se podrá incluir en esa página.  Además, el uso de esta herramienta de gestión de conocimiento permitirá:

• Fomentar el trabajo en equipo en el espacio con posibilidad de edición en línea.
• Estandarizar la entrega de los entregables de las órdenes de trabajo.
• Tener un histórico de versiones de la documentación.
• En el futuro permitirá sustituir los “documentos” por páginas.
• Fomentar la comunicación en base a notificaciones “@usuario”.

Metodología ágil

En esta metodología, las mejoras ya aprobadas (así como las incidencias y las no conformidades) se descomponen en historias de usuario que constituyen el backlog del producto. Esas historias de usuario se priorizan e incluso se les da un peso (bien por puntos de historia o por horas estimadas) y se incluyen en un sprint, entendido como un miniproyecto de no más de un mes (ciclos de ejecución muy cortos -entre una y cuatro semanas), cuyo objetivo es conseguir un incremento de valor en el producto que estamos construyendo.

Una vez que se tienen las historias de usuario, el equipo puede descomponerlas en subtareas que van acometiendo y que pueden visualizarse en JIRA en una pizarra. Una vez que todas las subtareas de una historia de usuario estén cerradas, la historia podrá resolverse y pasar a ser validada.

La gestión de los costes de un sprint se hace mediante una especie de proyecto (en JIRA la entidad se llama subproyecto ágil) al que se da un horizonte temporal y en el que se van sumando los costes de los diferentes sprints creados en el tiempo de ejecución del proyecto. La gestión de costes en un sprint se controla mediante la creación en la reunión de planning de una OTAgil, que es una orden de trabajo de crédito disponible en la que se controlan los costes del equipo durante el tiempo que dure el sprint y que debe estar relacionada con el subproyecto en el que se quieran controlar los costes de ese equipo.

En el manual de JIRA podrás encontrar una guía detallada del las historias de usuario, de las subtareas ágiles y de los errores técnicos así como de la configuración de las pizarras.

En la metodología ágil se contempla el papel de la Oficina de Calidad en cada uno de los sprints. Normalmente el miembro de OCA que está trabajando con el equipo ágil realiza una serie de tareas que van destinadas a verificar todo lo que conlleva la entrega que se hace en el sprint:

Estas tareas son una guía. Hay veces en las que no es necesario realizar todas, mientras que otras, es necesario hacer tareas que no se contemplan en la lista anterior.

Cuando es necesario hacer un despliegue, es necesario crear una versión como las que se crean en la metodología en cascada.

En cuanto a la Gestión del Conocimiento en este tipo de proyectos, se hace de manera ligeramente diferente. En el espacio de cada producto debe haber una página denominada "Metodología ágil" en la que se debe crear una pagina con el "Definition of Done" y "Definition of Ready" siguiendo las plantillas definidas. Además por cada sprint que se cree, será necesario crear una página con la planificación del sprint (plantilla Sprint Planning) y otra de retrospectiva (con la plantilla del mismo nombre) el día que se haga la review. Es aconsejable usar una macro de calendario de CONFLUENCE para controlar la disponibilidad del equipo durante el sprint (vacaciones, formación, dedicaciones parciales, etc.)

Dentro del espacio se deja libertad al equipo para ir colocando prototipos o documentación funcional relativa a las historias de usuario.