| Tabla de contenidos |
|---|
1. Definición de proyecto transversal
Un proyecto transversal es aquel en el que participan y por tanto involucra a varios grupos de trabajo de ATICA.
| Advertencia | ||
|---|---|---|
| ||
Este tipo de proyectos puede implicar la participación de grupos de trabajo de los dos servicios de ATICA: Infraestructuras y Desarrollo. Por tanto, es importante planificar y estimar el trabajo de TODOS los participantes. |
2. Particularidades en la planificación
En los proyectos pertenecientes a un solo grupo, durante la fase de Planificación del Proyecto, el Responsable técnico establecerá la hoja de ruta de Releases a desarrollar, y las épicas de cada uno. Las dependencias son fáciles de gestionar en este escenario.
Sin embargo, en los proyectos transversales se establecen dependencias entre Grupos, que pueden ser de diferente naturaleza, dependiendo del proyecto.
Vamos a distinguir a continuación los dos escenarios más habituales, aunque es posible escenarios mixtos u otros aún no detectados en el futuro.
2.1. Proyectos en los que participan en el desarrollo dos o más grupos
Este escenario abarca aquellos proyectos en los que en el desarrollo participarán dos o más grupos, en el sentido que se va a construir una misma aplicación / producto, pero se ha dividido su arquitectura en diferentes módulos, de manera que es posible abordar la construcción de cada uno de estos módulos por grupos separados.
En estos casos, en la planificación se reflejará el trabajo de cada grupo, creando las épicas pertinentes de las Releases en el proyecto JIRA asociado el grupo correspondiente.
| Info | ||
|---|---|---|
| ||
Ver la Gestión de versiones y épicas y la Gestión de tareas en JIRA. |
2.2. Proyectos con dependencias entre aplicaciones y/o servicios de distintos grupos
Este escenario supone que para alcanzar alguna de las Releases en la planificación, es necesario el desarrollo y obtención de Releases o desarrollos de otros grupos. Por ejemplo, para alcanzar una versión funcional de una aplicación que se quiere construir, que sea necesario añadir una operación a la API de una aplicación de otro grupo.
Esto debe contemplarse en la planificación, y al igual que en caso anterior, se deben crear las épicas pertinentes de las Release en el proyecto JIRA asociado al grupo que las va a abordar.
| Info | ||
|---|---|---|
| ||
Ver la Gestión de versiones y épicas y la Gestión de tareas en JIRA. |
También deben reflejarse las posibles dependencias existentes entre los desarrollos de los grupos. Para ello, se propone utilizar la macro incluida con Confluence: Planificador hoja de Ruta, que permite dibujar un diagrama de Gantt sencillo y las dependencias. En cualquier caso, también son admisibles otros tipos de diagramas que muestren esas dependencias temporales en su desarrollo, como un diagrama de Gantt clásico.