Tipos de proyecto JIRA en DESARROLLO
Proyecto Jira de tipo usualmente nombrado como GT-AT-nombre_de_grupo_o_unidad
Situación actual
Responden a la estructura “grupo” (ya sea área de negocio, lo que han sido siempre los grupos en ÁTICA, o los servicios/área). Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Uso:
Caso más general: reuniones y otras tareas de gestión que van más allá de un proyecto concreto.
Cuando, aún teniendo que ver con un proyecto u operación concreta, participan en la tarea técnicos de distintos perfiles y que no podrían imputar tiempo en el caso de utilizarse el proyecto Jira concreto.
- Tipo de tareas que admite: En función del grupo, en algunos casos muy limitado y en otros prácticamente todas. Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Propuesta
- Mantener como tipo de proyecto Jira, pero ligado a ámbito de negocio funcional.
- Uso: exclusivamente reuniones y otras tareas de gestión que van más allá de un proyecto concreto.
- Tipo de tareas que admite:
Reunión
Documentación e Informes
Tarea Gestión
Proyecto Jira del tipo usualmente nombrado como DJ-AT-nombre_de_grupo_o_unidad
Situación actual
Responden a la estructura “grupo” y, en principio, deben ser solo “de tránsito” para la entrada de peticiones "externas". La identificación de la aplicación o servicio afectado está en el resumen y/o descripción de la tarea. Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Uso: Alta de peticiones, bien de usuario final o bien de otros técnicos de ÁTICA que no pertenecen al equipo de trabajo. Una vez asignada la tarea a un técnico competente, este debe de cambiar al proyecto JIRA que corresponda en función de la aplicación o servicio de tal forma que no habrá tareas cerradas en DJ-AT-… .
- Tipo de tareas que admite: En algunos casos solo las "rojas" (Incidencia, Incidencia rápida, petición de servicio, petición de cambio con autorización y nueva funcionalidad), otros añaden a las anteriores las de gestión y reuniones y finalmente en otros casos se admiten tareas prácticamente de cualquier tipo. Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Propuesta
- Debe ir ligado a OPERACIÓN, no a GRUPO. Ejemplo: Operación Formación Continua.
- Uso: exclusivamente alta de peticiones, bien de usuario final o bien de otros técnicos de ÁTICA, cuando se desconoce el proyecto JIRA concreto pero sí se identifica el área de negocio/responsable que debe gestionar la tarea.
- Tipo de tareas que admite:
Incidencia
Petición de Servicio
Nueva Funcionalidad
Proyecto Jira del tipo usualmente nombrado como APLICACIÓN/SERVICIO
Situación actual
Se trata de proyectos Jira que identifican aplicaciones/portales/servicios en producción y/o en desarrollo (o ambos cuando se están llevando a cabo proyectos evolutivos). En ocasiones, aglutinan un conjunto de los anteriores. Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Uso: Cualquier tipo de tarea, ya sea con cargo a OPERACIÓN (MANTENIMIENTO O BOLSA) de una aplicación/servicio concreto en producción o con cargo a un nuevo DESARROLLO.
- Tipo de tareas que admite: Salvo alguna excepción de proyectos "especiales", admiten prácticamente toda la tipología de tareas disponible . Ver Tipos de tareas según tipo de proyecto actuales 20240611.docx
Propuesta
- Mantener como tipo de proyecto Jira. Podría analizarse si convendría homogeneizar y que todas respondan al mismo concepto de aplicación/servicio (evitando las que aglutinan), pero seguramente no aporta.
- Uso: tareas de cualquier tipo que van ligadas a una aplicación/servicio concreto, ya sea OPERACIÓN o NUEVO DESARROLLO.
- Tipo de tareas que admite:
Bug
Iniciativa
Épica
Historia
Tarea
Tarea QA
Tarea TestAdaptativo técnico NUEVA
Mejora
Uso de los diferentes tipos de tarea
importante
En el caso de los proyectos Jira del tipo "APLICACIÓN/SERVICIO", dado que la mayoría comprenden aplicaciones/servicios en producción, la interfaz de Jira siempre va a ofrecer todos los tipos de tarea admisibles para dicho tipo de proyecto. Será responsabilidad del técnico elegir la tipología adecuada de acuerdo a la siguiente recomendación, en función de que se trate de OPERACIÓN o de un NUEVO PROYECTO.
Caso OPERACIÓN
| Tipo de tarea | Descripción | Caso OPERACIÓN ¿es BOLSA obligatoria? | Observaciones |
|---|---|---|---|
| El software en producción no funcione como se espera. Si la incidencia implica cambio en el código de la aplicación, se debe generar una tarea relacionada tipo bug. | No | "Incidencia" recoge la entrada. Si no es tema de cambio de código se resuelve por ahí y, si lo es, se creará una tarea enlazada "bug" que se gestionará de forma interna. |
| Cualquier error encontrado de oficio por el equipo de desarrollo durante la construcción de la aplicación o por el propio usuario cuando está en pruebas, o en pre-producción o en producción. El solicitante de la tarea siempre será un técnico. | No | Aplica a OPERACIÓN cuando se trata de una aplicación o servicio en producción. La tarea puede entrar desde el usuario final. En ese caso, habrá una tarea tipo "Incidencia" que recoge la entrada. Si no es tema de cambio de código se resuelve por ahí y, si lo es, se creará una tarea enlazada "bug" que se gestionará de forma interna. Si se inicia de forma interna, se creará directamente como "bug". |
| Petición de información o consejo o solicitud de acceso a algún servicio de TI. Como norma general las peticiones de servicio no conllevan cambio en el código. | No | Algunos ejemplos son la obtención de datos mediante consulta directa a BD, cambio de contraseña, otorgamiento de perfil en una aplicación, consulta sobre el funcionamiento de un servicio, etc. |
| Desarrollo mejorativo/evolutivo solicitado por el usuario. En función de la envergadura, debe tipificarse como Historia (colgando de la correspondiente Iniciativa\Épica). | Si | La obligatoriedad de BOLSA aplica en un PÓRTICO de OPERACIÓN. |
| Conjunto de épicas que conducen a un objetivo común. | Si | La obligatoriedad de BOLSA aplica en un PÓRTICO de OPERACIÓN, aunque estas tareas no deben tener tiempo de trabajo imputado. |
| Grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas (llamadas “historias”). | Si | La obligatoriedad de BOLSA aplica en un PÓRTICO de OPERACIÓN, aunque estas tareas no deben tener tiempo de trabajo imputado. |
| Equivale a un caso de uso o una historia. Se referirá siempre a un requisito funcional, que más adelante podrá ser descompuesto en subtareas, o no, según las necesidades del equipo de desarrollo. | Si | La obligatoriedad de BOLSA aplica en un PÓRTICO de OPERACIÓN. |
| Tarea de desarrollo derivada de una Historia de un sprint, bajo metodología SCRUM. | Si | La obligatoriedad de BOLSA aplica en un PÓRTICO de OPERACIÓN. |
| Tareas consistentes en pruebas de:
correspondientes al proceso "P9. Gestión de la calidad del software" de MEDEA. | No | En caso de que se deriven de un "Adaptativo técnico" o "Mejora" no se marcará BOLSA, pero si se trata de un "Evolutivo/mejorativo" si debe considerarse BOLSA. |
| Son tareas derivadas de "Tareas QA". No debe existir una "Tarea test" aislada del P9, esto es, que no esté asociada (ya sea relacionada o como subtarea externa) a una tarea QA. | No | En caso de ser OPERACIÓN y se deriven de un "Adaptativo técnico" o "Mejora" no se marcará BOLSA, pero si se trata de un "Evolutivo/mejorativo" si debe considerarse BOLSA. |
| Cuando se requiera cambiar el software en respuesta a los cambios en su entorno. Ocurre en situaciones como cambios en el sistema operativo (o su software), la pila tecnológica, dependencias de software, hardware o almacenamiento en la nube. Incluye:
En definitiva "lo que nos viene como impuesto". El solicitante de la tarea siempre será un técnico. | No | No usar cuando se trate de un cambio en el software en respuesta a una demanda (mejorativo/evolutivo) desde la perspectiva funcional. No usar cuando se requiera debido a un mal funcionamiento o error en el propio software. |
| Tareas de mantenimiento "perfectivo" que se centra en características que mejoran la experiencia del usuario a través de mejoras funcionales. Se trata de mejorar el rendimiento del sistema de manera que no sea en respuesta a una falla o problema, sino en respuesta a los comentarios de los clientes. Incluye:
El solicitante de la tarea siempre será un técnico. | No | No debe usarse para nuevas funcionalidades (mejorativo/evolutivo) solicitado por el usuario. En ese caso, se tratará de "Nueva funcionalidad" o bien "Iniciativa\Épica\Historia", en función de la envergadura |
| Reunión cuyo orden del día incluye funcionamiento, desarrollo, avance, uso o cualquier otra cuestión acerca de una aplicación o servicio TI, gestión de equipos de trabajo o seguimiento de la cartera de proyectos. | No | Será OPERACIÓN siempre que no aplique a un nuevo proyecto PÓRTICO concreto. Cuando esté ligada a un desarrollo evolutivo/mejorativo concreto, debe clasificarse como BOLSA. |
| Elaboración de documentos e informes sobre el funcionamiento, desarrollo, avance, uso o cualquier otro tipo de documentación relativa a una aplicación o servicio TI, gestión de equipos de trabajo o seguimiento de la cartera de proyectos. | No | Será OPERACIÓN siempre que no aplique a un nuevo proyecto PÓRTICO concreto. Cuando esté ligada a un desarrollo evolutivo/mejorativo concreto, debe clasificarse como BOLSA. |
| Tarea que consiste en llevar a cabo cualquier tipo de gestión relacionada con una aplicación o servicio TI, la gestión de los RRHH y funcionamiento de los equipos de trabajo o el seguimiento de la cartera de proyectos. Como caso más habitual, se utilizará para imputar tiempo a tareas generales de gestión que se realizan en el día a día y que no conllevan reuniones específicas o elaboración de informes y documentación. La lectura de documentación, gestión del correo electrónico diario y la atención telefónica o presencial por cuestiones sobrevenidas son ejemplos claros. | No | Será OPERACIÓN siempre que no aplique a un nuevo proyecto PÓRTICO concreto. Cuando esté ligada a un desarrollo evolutivo/mejorativo concreto, debe clasificarse como BOLSA. No usar en el caso de "Documentación e Informes" o "Reunión" ya que tienen su propio tipo. Tampoco en el caso de "Formación", aunque sean tareas propiamente de gestión asociadas a ello. |
| Cualquier tarea de entre las siguientes:
| No | Será OPERACIÓN siempre que no aplique a un nuevo proyecto PÓRTICO concreto. Cuando esté ligada a un desarrollo evolutivo/mejorativo concreto, debe clasificarse como BOLSA. |
Caso nuevo PÓRTICO
| Tipo de tarea | Descripción | Observaciones |
|---|---|---|
| Reunión cuyo orden del día incluye funcionamiento, desarrollo, avance, uso o cualquier otra cuestión acerca de una aplicación o servicio TI, gestión de equipos de trabajo o seguimiento de la cartera de proyectos. | Cuando el orden del día se corresponda con un nuevo proyecto PÓRTICO debe asociarse a este, aunque se trate de un evolutivo de una aplicación en producción y que, por tanto, dispondrá de OPERACIÓN. |
| Elaboración de documentos e informes sobre el funcionamiento, desarrollo, avance, uso o cualquier otro tipo de documentación relativa a una aplicación o servicio TI, gestión de equipos de trabajo o seguimiento de la cartera de proyectos. | Cuando se corresponda con un nuevo proyecto PÓRTICO debe asociarse a este, aunque se trate de un evolutivo de una aplicación en producción y que, por tanto, dispondrá de OPERACIÓN. |
| Tarea que consiste en llevar a cabo cualquier tipo de gestión relacionada con una aplicación o servicio TI, la gestión de los RRHH y funcionamiento de los equipos de trabajo o el seguimiento de la cartera de proyectos. Como caso más habitual, se utilizará para imputar tiempo a tareas generales de gestión que se realizan en el día a día y que no conllevan reuniones específicas o elaboración de informes y documentación. La lectura de documentación, gestión del correo electrónico diario y la atención telefónica o presencial por cuestiones sobrevenidas son ejemplos claros. | No usar en el caso de "Documentación e Informes" o "Reunión" ya que tienen su propio tipo. Tampoco en el caso de "Formación", aunque sean tareas propiamente de gestión asociadas a ello. Cuando la tarea se corresponda con un nuevo proyecto PÓRTICO debe asociarse a este, aunque se trate de un evolutivo de una aplicación en producción y que, por tanto, dispondrá de OPERACIÓN. |
| Cualquier tarea de entre las siguientes:
| Cuando la formación se corresponda con un nuevo proyecto PÓRTICO debe asociarse a este, aunque se trate de un evolutivo de una aplicación en producción y que, por tanto, dispondrá de OPERACIÓN. |
| Conjunto de épicas que conducen a un objetivo común. | |
| Grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas (llamadas “historias”). | |
| Equivale a un caso de uso o una historia. Se referirá siempre a un requisito funcional, que más adelante podrá ser descompuesto en subtareas, o no, según las necesidades del equipo de desarrollo. | |
| Tarea de desarrollo derivada de una Historia de un sprint, bajo metodología SCRUM. | |
| Tareas consistentes en pruebas de:
correspondientes al proceso "P9. Gestión de la calidad del software" de MEDEA. | |
| Son tareas derivadas de "Tareas QA". No debe existir una "Tarea test" aislada del P9, esto es, que no esté asociada (ya sea relacionada o como subtarea externa) a una tarea QA. | |
| Cualquier error encontrado de oficio por el equipo de desarrollo durante la construcción de la aplicación o por el propio usuario cuando está en pruebas o en pre-producción. | La tarea puede entrar desde el usuario final. En ese caso, habrá una tarea tipo "Incidencia" que recoge la entrada. Si no es tema de cambio de código se resuelve por ahí y, si lo es, se creará una tarea enlazada "bug" que se gestionará de forma interna. Si se inicia de forma interna, se creará directamente como "bug". |
IMPORTANTE
El tipo de proyecto Jira GT-AT-... ya no será necesario utilizarlo cuando se trate de tareas relacionadas con un nuevo proyecto PÓRTICO, si finalmente se da el VºBº a que cualquier técnico pueda imputar en cualquier proyecto JIRA. GT-AT-... quedará sólo para cuestiones transversales y el tipo de tareas disponibles estará muy limitada: las tres azules (Reunión, Documentación e informes y Gestión).
Observaciones
- Respecto a la nueva tipología de tarea FORMACIÓN, se dan distintos escenarios:
- Tareas de GESTIÓN relacionadas con la formación de los equipos: propuestas de formación, gestión presupuestaria asociada, gestión con posibles docentes/empresas que impartan formación, elección de asistentes, etc...
- Tareas de DOCENTE: preparación clases y documentación, elaboración de tareas y exámenes, corrección y asistencia
- Tareas de ESTUDIANTE: estudio de documentación, realización de tareas y exámenes y asistencia
Para la FORMACIÓN nos remitiremos a lo indicado en UNATIC-1002:2024 - Imputación de la formación en la cartera de proyectos
2 Comentarios
Mercedes Oncina Deltell
Si queremos distinguir los tres escenarios de la formación, o bien se crea un tipo de tarea diferente (las etiquetas ya sabéis que no son de agrado general) para cada tipo o bien, yo propongo dejar el GT-AT-ATICA como ÚNICO proyecto Jira donde esté este tipo de tarea, independientemente de si la formación es para un único servicio.
Estamos ya muy interrelacionados todos, en la mayor parte de la formación seremos mezcla toda ÁTICA-Ticarum con lo que no veo descabellado dejar el GT-AT-ATICA como único proyecto Jira en el que registrar la formación.
Mercedes Oncina Deltell
Tengo una duda importante, con esta propuesta, ¿se pretende crear nuevos GT-AT y DJ-AT? porque los actuales tienen los tipos de tareas que ya conocemos y moverlas es una locura.