SGI gestion de proyectos

De EduWiki
Revisión de 13:31 26 sep 2019 por Cap04c (Discusión | contribuciones) (Herramientas. CLIP y REDMINE)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar

Metodología de la gestión de proyectos y servicios del SGI, Educación

Se describe a continuación como el SGI va a gestionar los proyectos y servicios, y las herramientas que utilizará para ello. Fundamentalmente CLIP y REDMINE.

Introducción

Para poder gestionar todas las peticiones, consultas, incidencias y demandas que se realizan al SGI es imprescindible el uso de herramientas informáticas. Además, al ser un equipo muy grande es imprescindible el uso de herramientas que no sean unipersonales, y que permitan a otros miembros del equipo conocer la situación de las actuaciones que se están realizando.

Hay muchas formas de hacer esto, y lo más difícil es encontrar la forma que nos permita disponer de un sistema integral que lo permita gestionar todo de forma ágil y eficaz.

Distinguimos varios tipos de peticiones que llegan al Servicio de Informática:

  • Incidencias. Aquellos que vienen de fallos que tiene un ordenador, o un programa, y que tienen que ver con el funcionamiento normal del servicio que se está utilizando.
  • Tareas, aquellas actividades que concretas que se encargan al personal del Servicio y que ha de realizar en función de las especificaciones que se le han dado.
  • Peticiones normalizadas, que tienen una documentación asociada y que están perfectamente protocolizadas.
  • Peticiones libres, de distintos sitios que no tienen procedimiento formal.
  • Mejoras, que permiten incorporar una nueva funcionalidad a una aplicación, o hacer algo de otra forma que permita optimizar tiempos y recursos.
  • Quejas, como consecuencia de un mal funcionamiento o una respuesta no satisfactoria del servicio que se está proporcionando.

Para este tipo de peticiones se ha buscado solución con herramientas software, intentando que sea el menor número de herramientas posibles.

Herramientas. CLIP y REDMINE

Se han identificado cuatro herramientas:

  1. CLIP, aplicación para la gestión de incidencias y peticiones.
  2. REDMINE, aplicación para la gestión de peticiones de equipos de trabajo.
  3. Correo electrónico, para comunicación con gestores y técnicos.
  4. Teléfono, para comunicación más informal y directa con gestores y técnicos.

CLIP. Gestión de incidencias y peticiones

Basado en GLPI, CLIP es la herramienta seleccionada para la interacción con los usuarios. De esta forma, CLIP se utilizará para:

  • Para usuarios de servicios ya puestos en marcha
  • Para Servicios ya puestos en marcha

Incidencias de usuarios Incidencias de dueño de producto

Procedimiento

Cualquier usuario puede usar CLIP http://soporte.murciaeduca.es. Al dar de alta la incidencia o petición, se asignan al responsable técnico del del servicio (Scrum Master). El técnico decide si lo tiene que ver el dueño de producto. Si se da de alta redmine, se indica en un seguimiento público indicando: redmine: #número#


Un ciudadano no debe ponerse en contacto con CLIP.
Para ello existen los sistemas de atención al ciudadano.
Quien puede solicitar una incidencia o una tarea puede ser:
En CLIP, cualquier miembro de la Consejería y de los centros (PAS y docentes)
En redmine, solo los miembros del proyecto o del servicio.


Uso de CLIP

CLIP lo deben usar:

  • Usuarios de la Consejería de Educación
  • Personal de centros públicos y concertados
  • Empresas que están dadas de alta en LDAP

Canales de entrada a CLIP

Para qué lo deben usar

  • Para poner incidencias de funcionamiento de cualquier equipo o programa.
  • Para dar de alta problemas
  • Para hacer algún tipo de petición
  • Para pedir un nuevo proyecto o servicio.
  • Para solicitar acceso de alguna persona a alguna aplicación.


CLIP es atendido en primera instancia por personal de nivel 1 altamente cualificado, que analiza, categoriza, prioriza y si puede resuelve la incidencia. En caso de no poder resolverla la escala al siguiente nivel de resolución.

Utilizamos CLIP para contactar directamente con el usuario.
Distinguimos los siguientes tipos de entradas

  • Eventos, directamente de los sistemas
  • Incidencias, cortes del servicio o errores que hay que solucionar cuanto antes.
  • Peticiones deben estar dentro del catálogo de servicios
  • Gestión de accesos A sistemas, con las autorizaciones pertinentes
  • Reclamaciones
  • Quejas

Los usuarios finales que soliciten nuevas funcionalidades, así como modificación de las ya existentes, se recogen en CLIP. Estas nuevas funcionalidades se trasladan al responsable funcional de la aplicación, para que analice si es o no adecuada. En caso de ser adecuada es él y no otra persona quien indica que se realice. La petición en CLIP se le asigna entonces al responsable técnico del proyecto.

Estados en CLIP y uso de los mismos

Los estados más importantes en CLIP son los siguientes:

  • En curso (Asignada). Es el estado por defecto, el técnico la tiene asignada pero no significa que esté trabajando en ella.
  • En espera. Se pone en este estado cuando se está esperando información del usuario. Hay que acompañarla de un seguimiento público que le indique al usuario lo que se espera de él.
  • En curso (Planificada). Se ha empezado a trabajar en ella.



Puede ser que algún CLIP deba generar una tarea en redmine. Si es así se debe hacer lo siguiente:

  1. Cambiar estado a En curso (Planificada)
  2. Asignar al grupo itil3_redmine
  3. Quitar del grupo en el que esté asignado en CLIP
  4. Dar de alta la tarea o tareas en redmine. En ellas incluir el número de CLIP asociado en el campo correspondiente.
  5. Indicar en CLIP en un seguimiento privado el número de redmine, precedido por una almohadilla para poder buscarlo en un momento determinado. Ejemplo: #1234
  6. Una vez cerradas y validadas todas las tareas, ir a CLIP y dar por resuelto el ticket.

 

 

REDMINE. Gestión de peticiones

Redmine se utiliza para dos tipos de actividades

  • Proyectos, que se planifican en el tiempo, que empiezan y terminan y que normalmente desencadena en un servicio.
  • Servicios, fundamentalmente mejoras, nuevas funcionalidades o errores que implican la realización de tareas y por tanto dedicar tiempo.

Estados

Los estados posibles son

Estado Descripción
Nueva Cuando viene de CLIP o de los miembros del proyecto.
En curso Cuando el técnico se pone a trabajar sobre la incidencia.
Bloqueada No se puede seguir con la petición. Falta información, hay otras prioridades, etc.
Desbloquedada Ya se dispone de toda la información, pero no se ha podido iniciar los trabajos con ella.
Es como si estuviera en estado NUEVA, pero ya se ha trabajado en ella.
Pendiente de validación El técnico ha terminado el trabajo y está pendiente de que alguien lo revise o lo valide.
No validada El trabajo que se ha hecho y se ha revisado no cumple los requisitos o no funciona como se esperaba.
Validada El trabajo que se ha hecho y se ha revisado cumple los requisitos o no funciona como se esperaba.
Terminada El trabajo que se ha hecho se ha finalizado.
Cancelada El trabajo que se ha solicitado se ha considerado no hacerlo.

Tipos de peticiones

Los tipos de peticiones son

Tipo Descripción
Historia de usuario Es una petición del gestor, no demasiado concreta, que es necesario descomponer en tareas. Está asociada más a un requisito o caso de uso.
Una historia de usuario no debe llevar más de un sprint. Si lleva más tiempo hay que descomponerla en historias más simples.

Una historia de usuario normalmente se descompone en tareas.

Tarea Petición concreta que debe hacer un técnico.
Incidencia Para solucionar errores de programación. Se diferencia de la tarea para saber las acciones que realizamos consecuencia de una mala programación previa o de un requisito mal especificado.

Una incidencia puede o no descomponerse en tareas.

Desbloquedada Ya se dispone de toda la información, pero no se ha podido iniciar los trabajos con ella. Es como si estuviera en estado NUEVA, pero ya se ha trabajado en ella.
Incidencia de datos Igual a incidencia, pero que hay que modificar los datos directamente. Debe ser a extinguir y hacer programas que eviten este tipo de incidencias.
Mejora Para historias de usuario que se tienen como posibles actuaciones a realizar y que no tienen fecha concreta ni compromiso de realización.
Debe ser sustituida por historias de usuario



Las peticiones en redmine deben hacerse a proyectos concretos y en los que la persona está autorizada.

Para proyectos y servicios, se dan de alta:

  • Tareas, para nuevos trabajos.
  • Incidencias, para trabajos hechos que hay que modificar por error.
  • Historias de usuario, para nuevas funcionalidades que hay que detallar.

Si hay CLIP, indicarlo en el redmine para llevar trazabilidad.

Criterios para alta en redmine

Criterios para dar de alta un proyecto, un subproyecto o una tarea

  1. Alta de proyecto si es adecuado
  2. Alta de subproyecto si merece la pena. Si no, crear una tarea y poner debajo subtareas.

Uso de Redmine

Redmine lo deben/pueden usar:

  • Técnicos dados de alta en proyectos
  • Asesores de proyectos
  • Asesores Funcionales
  • Cualquiera que esté dado de alta en un proyecto.

Canales de entrada a redmine

Para qué lo deben usar

  • Para dar de alta historias de usuario
  • Para dar de alta tareas asociadas a técnicos
  • Para solicitar cambios a proyectos en soporte.
  • Para dar nuevas necesidades a un nuevo proyecto.

Asignación de historias de usuario y de tareas

  • Las peticiones en redmine deben ser asignadas a los técnicos para su realización.
  • Las peticiones asignadas a un técnico no se cambian a un gestor para pedir información o validar. Las mantiene el técnico y pone como seguidor para que esté informado a quien deba validarlo.
Estado Asignada Significado
Nueva Sin asignar No se hace nada. Pendiente de que el responsable asigne la tarea.

Toda tarea que se vaya a dar de alta se debe asignar inicialmente al responsable técnico del proyecto.

Nueva Asignada Debe realizarla quien la tiene asignada. Todavía no se está trabajando en ella.
En curso Asignada Se está trabajando en ella.
Bloqueada Asignada No se cambia el técnico. Se pone como seguidor al responsable o a quien debe proporcionar información. En caso de bloqueo por otra razón se debe indicar el motivo.
Pte. Validación Asignada No se cambia el técnico. Se pone como seguidor al responsable o a quien debe validarla

Acuerdos de nivel de Servicio para las peticiones

Debemos tener unos criterios de nivel de servicio En principio serán los siguientes:

  • Una petición debe tener obligatoriamente una fecha de vencimiento.
  • Una petición debe tener obligatoriamente una estimación de tiempo.
  • Todas las tareas han de finalizarse antes de la fecha de vencimiento.

En cuanto a estados:

Estado Tiempo máximo Significado
Nueva Sin tiempo Puede estar el tiempo que sea necesario


Es conveniente revisarlas para ver las que se pueden poner a realizar.
Es imprescindible poner la fecha de vencimiento, o la fecha de inicio.
Pueden ser ideas que se apuntan para una nueva convocatoria para el año siguiente y que no queremos que se nos olvide.

En curso 1 mes Las tareas en curso no pueden estar más de un mes, si es así es porque nos hemos equivocado en la definición de la misma y hay que partirla.
Bloqueada 1 mes Al ser un estado que se utiliza para varios temas, es conveniente utilizar el sentido común. El objetivo es conocer las tareas en las que se ha trabajado y no se ha podido seguir. Es conveniente por lo menos revisar esas tareas al menos una vez al mes con objeto de ver si se cumplen todavía los criterios por los que se bloqueó. Puede ser porque hubiera otras prioridades, Toda tarea que dependa de personal interno y que se encuentre en este estado, en caso de que no se nos proporcione información se pasa a cancelada. No se debe realizar trabajo adicional al servicio que tiene bloqueado un trabajo.
Desbloqueada 1 mes Una vez desbloqueada hay que ponerse a trabajar con ella en cuanto sea posible, en el actual o en el siguiente sprint.
Pendiente validación 1 mes Una vez que alguien ha terminado un trabajo que se le ha encargado es imprescindible validarlo cuanto antes. Varias razones: lo tiene fresco en caso de que no se valide, y se puede dedicar a otra cosa con la mente limpia pensando que el trabajo ha sido finalizado


Es posible poner en producción algo que esté pendiente de validación, ya que hay en algunas ocasiones que solo se puede comprobar el funcionamiento en producción. No debe ser la norma.

Correo Electrónico

Para aclaraciones y comunicaciones diarias. Se pasan a la herramienta las conclusiones. Evitarlo, preferible la comunicación oral.

Definiciones

Dejamos a continuación una serie de definiciones que permitan delimitar los conceptos.

Aplicación

Conjunto de programas que cubren una funcionalidad.

Módulo

Conjunto de programas que cubren una funcionalidad asociado a una entidad.

Entidad

Conjunto de elementos que pueden ser considerados como una unidad. Tiene sustantividad propia. Ejemplos: alumnos, facturas, centros, convenios, profesores, calificaciones...

Proyecto

Proyecto es todo esfuerzo temporal (que tiene un principio y un fin) y que tiene como resultado un producto, servicio, o un cambio en alguno de los existentes. Un proyecto tiene un ciclo de vida:

  • Inicio
  • Planificación
  • Ejecución
  • Seguimiento y control
  • Cierre

Un proyecto tiene varias fases.
Una fase en un proyecto no es un grupo de procesos de dirección de proyectos, sino un ciclo de vida completo.

Servicio

Según ITIL, un servicio es un medio para entregar valor a los clientes facilitándoles un resultado deseado sin la necesidad de que estos asuman los costes y riesgos específicos asociados. El objetivo de un servicio es satisfacer una necesidad sin asumir directamente las capacidades y recursos necesarios para ello.

Hay una delgada línea para diferenciar lo que es un proyecto de una actuación o tarea que sea importante. Por ejemplo, el desarrollo de un módulo nuevo de una aplicación... No está claro y la bibliografía que hay al respecto lo que indica es que sea la propia organización la que defina los límites entre proyecto y modificacion de un servicio.

En nuestro caso se irá adecuando en función del tipo de actividad a realizar.

Metodología

Utilizaremos la terminología SCRUM


Perfiles de usuarios

Hay varios perfiles de usuarios, los que utiliza SCRUM son los siguientes.

  • Dueño de producto, el responsable funcional del proyecto o del servicio. Es quien vela porque cumpla la funcionalidad.
  • Scrum Master, técnico del equipo que se encarga de velar porque se cumplan los objetivos planteados.
  • Equipo de proyecto, cada uno de los técnicos que intervienen en el proyecto.

Hay otros perfiles si bien están en desuso:

  • Administrador del proyecto: será la persona encargada de la creación y de la configuración del proyecto (para REDMINE).
  • Responsable funcional, el que decide y supervisa los requisitos de negocio. Similiar al dueño de producto.
  • Responsable técnico, el que decide y supervisa los requisitos técnicos.
  • Asesor experto, el que colabora con el responsable funcional y el técnico
  • Técnico, el que realiza las actividades técnicas.
  • Asesor – Consultor: Son las personas que participan en el estudio y en la propuesta de soluciones.

CLIP. Flujo del proceso de gestión de Incidencias y Peticiones

La incidencia/petición la da de alta un usuario en CLIP cuando se da cuenta de que hay algo que no funciona bien o necesita una nueva funcionalidad. El CAU la recibe, la analiza y la pasa al grupo técnico funcional que considera que puede resolverla. No tiene porqué ser un grupo informático, debería ser el grupo de personas que tienen la responsabilidad funcional de la aplicación. El grupo la comprueba, la analiza y si puede resolverla la resuelve. Si considera que es necesaria una actuación, asigna en la incidencia al grupo técnico que puede resolverla y se pone bien como supoervisor o se sigue quedando como técnico. El técnico informático que lo recibe la analiza y si considera que es necesario una actuación:

  • Da de alta en redmine, indicando el número de CLIP,
  • En CLIP indica en un seguimiento el número de redmine con almohadilla delante (#Nºredmine)

Una vez que ha sido resuelto el redmine, se notifica en un seguimiento privado en CLIP para que sea consciente el responsable funcional y pueda comprobar o resolver la incidencia.



Estados de una incidencia en CLIP

  • Nueva
  • En Curso
  • Resuelta
  • Cerrada

 

REDMINE. Flujo Gestión de peticiones

  1. La incidencia/tarea/historia de usuario se anota en el proyecto de negocio asociado al desarrollo del que se tiene la incidencia. Se asigna al responsable técnico.
  2. Se analiza, y se asigna fecha de inicio, fecha de vencimiento, tiempo estimado.
  3. Se desglosa en tareas, que se asignan a los técnicos que han de resolverla.
  4. Se asigna al SPRINT en el que se va a trabajar en ella.

Con ello, se dispone de la carga del técnico para el sprint.

Una vez que ya se inicia el sprint.

  1. El técnico pone la incidencia en curso.
  2. En el caso de necesitar información para seguir con la tarea, debe ponerla en bloqueada. El responsable técnico debe facilitar el desbloqueo de la tarea.
  3. Una vez que ha finalizado, la cambia a pendiente de validación. La debe validar la persona que ha puesto el redmine.

Criterios generales para la gestión de tareas

Los parámetros generales son los siguientes:

  1. Unidad mínima de tiempo se establece en media hora.
  2. Número máximo de tareas en curso asignadas al mismo técnico: Diez.
  3. Esfuerzo máximo para imputar o estimar a una tarea: 20 horas

Y los criterios generales son los siguientes:

  1. Todo aquello que se tarde menos de la unidad mínima de tiempo no es necesario indicarlo, salvo que la incidencia o tarea ya esté introducida.
  2. No se deben tener más del máximo de tareas en curso en el mismo momento asignadas a la misma persona. Si hay más es necesario pasarlas a otro estado ya que es prácticamente seguro de que no se llevan diez temas al mismo tiempo.
  3. Una tarea no puede superar el esfuerzo máximo. Toda tarea superior a esas horas es necesario descomponerla en tareas más pequeñas.
  4. Se ha de imputar diariamente el tiempo dedicado a cada tarea.