¿Cómo puedo realizar un seguimiento colectivo de las interdependencias de las aplicaciones?

Con diferentes equipos entregando diferentes partes de una solución general, se ha vuelto cada vez más difícil reconocer cuándo una versión determinada de una aplicación debe entregarse con otra aplicación y una versión diferente que se ajuste a la solución general. Este mismo escenario surge donde una aplicación de la solución general podría entregarse antes que la otra aplicación, pero no al revés.

Un ejemplo hipotético podría ser que hay 4 aplicaciones que conforman una solución de extremo a extremo que sirve a diferentes bases de usuarios. Con lo que estoy luchando es con una forma de rastrear las dependencias inter/intra en las aplicaciones de una manera simple y digestiva que no requiere una gran cantidad de capacidad intelectual a lo largo de las tareas diarias de los equipos.

Intenté usar herramientas (SpiraTeam) y también miré una matriz simplista dentro de Excel, sin embargo, aún tienen que resolver el problema. También pensé en hacer uso de los números de versión para identificar rápidamente el impacto, sin embargo, eso se volvió engorroso y no mantenible.

Estoy buscando quizás una solución única y/o experiencia previa que no requiera un proceso completo/cambio de paradigma para que esto suceda. ¿Alguien tiene alguna experiencia en el seguimiento efectivo de las aplicaciones interdependientes y, lo que es más importante, los ciclos de lanzamiento de las aplicaciones interdependientes dentro de la empresa?

ACTUALIZAR:

Para elaborar más, las dependencias se encuentran en diferentes capas dentro de las aplicaciones. Un ejemplo sería el front-end de una aplicación determinada, que se comunica con el back-end de la aplicación, que se comunica con otra aplicación más a través de los servicios. En este ejemplo, las entregas deben realizarse en paralelo pero funcionan de forma independiente en versiones de aplicación independientes. Indudablemente, estos se generan debido a las entregas de nivel de función; sin embargo, nuestro paradigma actual de control de versiones no captura explícitamente la función dentro del número de versión en sí, lo que hace que la conexión sea más difícil. El plan es que sea manipulado por todo el equipo, lo que se debe en parte a la interdependencia variable y a que cada propietario, respectivamente, esté más cerca de ese conocimiento e interdependencia. El resultado final es una visualización rápida para identificar que una aplicación dada puede preceder a otra versión o tal vez tienen que ir en paralelo, etc. He explorado una matriz simple dentro de Excel, sin embargo, se sentía engorroso desde la definición de la versión, mantenimiento de versiones , etc. suceden dentro de otra herramienta. El problema con la herramienta es que no permite la interconectividad entre proyectos (aplicaciones), lo que aliviaría este problema en el punto en que creo que debería resolverse.

Esto es lo que hace una herramienta de programación, por ejemplo, Microsoft Project, o algo más sofisticado. A menos que me esté perdiendo algo en tu pregunta...
Quiero algo específico para la versión de la aplicación y el seguimiento de interdependencia según un programa de lanzamiento. No estoy seguro de que Project sea la herramienta adecuada, ya que los usuarios que necesitan señalar la existencia de dependencias o la falta de ellas pueden ser desarrolladores, líderes, etc.
Seguramente es el "mapa" de dependencias lo que es importante, ¿no quién llama las dependencias? MS-Project es bueno para mantener mapas de dependencia entre tareas contra un cronograma nocional. No entiendo su razonamiento de por qué no se puede usar MS-Project.
Para ayudar a proporcionar algo de contexto, ¿qué capa(s) de dependencias está tratando de coordinar entre las aplicaciones? ¿Son dependencias de código de la misma capa, diferentes capas (como back-end y front-end), dependencias a nivel de características, etc.? Además, qué nivel de visibilidad y accesibilidad está buscando, es decir, es algo que un PM o varios PM usarán por sí mismos y mantendrán en una carpeta local la mayor parte del tiempo, o coordinarán su mantenimiento con los líderes técnicos, o será propiedad. y/o manipulado por todo el equipo y ser utilizado como un radiador de información en el área del equipo?
@JeffLindsey He actualizado la pregunta para, con suerte, proporcionar contexto y claridad adicionales.
Creo que la pregunta ahora es más propiamente ingeniería de software que gestión de proyectos. Creo que la administración de la configuración es parte de la solución, y es posible que use técnicas similares a la dependencia de tareas en la programación, pero no creo que haya resuelto este problema hasta que lo haya resuelto con ingeniería de software y requisitos. administración.

Respuestas (4)

Este es un problema de administración de arquitectura/configuración, no uno de PM. Obviamente, hay un impacto de PM, por lo que debe abordarlo.

En los proyectos en los que he trabajado, he encontrado que lo siguiente ayuda mucho:

  1. Línea de base de su código de trabajo. (¿Qué versiones de las 4 aplicaciones funcionan bien juntas?)
  2. Bloquee las interfaces/recursos compartidos entre las aplicaciones. No es un congelamiento de código, pero asegúrese de que todos los equipos examinen cuidadosamente cualquier cambio, no solo los dos que interactúan, porque...
  3. Haga una lluvia de ideas sobre sus casos extremos. Tuve un problema en el que un mensaje xml creado en Java se enviaba a un programa de socket C, los nodos vacíos se llenaban con valores nulos y el programa C truncaba el mensaje. En este caso, ambos equipos pensaron que sabían qué esperar/proporcionar, pero se perdieron un caso extremo que dependía de la interfaz Java/DB. Java pidió algo, la base de datos no lo tenía, por lo que proporcionó un valor nulo.
  4. Cuando obtenga una nueva versión de una de las aplicaciones, haga una prueba de regresión completa con ella y las otras aplicaciones. Haga un lanzamiento limitado con él, si es posible, y luego actualice sus líneas de base para incluir la nueva versión de la aplicación.

TL; DR

Piense en técnicas, no en herramientas. Las recomendaciones de herramientas siempre están fuera de tema en PMSE. Sin embargo, existen varias técnicas que pueden ser valiosas desde la perspectiva de la gestión de proyectos.

En general, tiene dos enfoques principales:

  1. Descomposición.

    Una matriz de trazabilidad o un gráfico de dependencia pueden ser útiles para descomponer tareas.

  2. Verticalidad.

    Cuando las funciones están demasiado entrelazadas para descomponerse en dependencias lineales, debe tratarlas como secciones verticales de trabajo.

Técnicas potenciales

Aquí hay algunas técnicas potenciales que pueden proporcionar proyectos o desgloses de programación de granularidad suficiente:

  1. Cree una matriz de trazabilidad , que es útil para vincular requisitos complejos.
  2. Desarrolle un diagrama de Mikado , que es esencialmente un gráfico acíclico dirigido de dependencias.
  3. Siga un enfoque de "características cortadas verticalmente", en el que una característica de pila completa se describe en términos de funcionalidad, pero la implementación se deja a discreción del equipo multifuncional que la crea. (Nota: este es el enfoque utilizado por la mayoría de los equipos de desarrollo ágil).

Ciertamente, también hay otros enfoques, pero las técnicas aún caen en última instancia en las categorías de descomposición o verticalidad. Si no puede avanzar en ninguna de las categorías, entonces podría ser útil dar un paso atrás y repensar por qué su proyecto está tan estrechamente vinculado.

Los requisitos excesivamente acoplados son un problema común en los proyectos, pero la causa raíz suele ser una falla de diseño o planificación en lugar de un problema técnico irresoluble. Sin embargo, su millaje puede variar.

¿Parece que sus dependencias son básicamente módulos o capas dentro de una sola aplicación?

A decir verdad, no soy un gran admirador de las herramientas digitales "más pesadas", pero creo que si está buscando algo que vincule de forma nativa los conjuntos de cambios al control de versiones con dependencias y miembros del equipo o proyectos, tendrá que buscar en algo como JIRA modificado o MSProject/TFS como han sugerido los demás.

Personalmente, he tenido éxito simplemente centrándome en una visibilidad extremadamente alta sobre la funcionalidad de una herramienta específica: es muy difícil no coordinarse bien cuando el trabajo pendiente/fragmentación de sprints, el progreso, los riesgos actuales y los elementos de dependencia de cada grupo son cartas en una gran pared en el equipo. (s) área. :)

Algunas de las otras respuestas brindan algunas buenas sugerencias desde el punto de vista de la gestión de proyectos. Sin embargo, según mi experiencia, la gestión de dependencias de proyectos debería ser solo complementaria. La mayor parte del trabajo pesado en esta área debería ser a nivel técnico.

Debido a que esta es la placa PM, no quiero entrar en demasiados detalles, pero podría llevar esto al equipo y, si no están seguros de cómo lograrlo, hay otras placas de intercambio de pila excelentes para la programación que podrían brindarle amplia información sobre estos temas.

Las dos áreas en particular que tendrán el mayor impacto son:

Repositorio de código: el uso efectivo de un repositorio de código, especialmente con un buen conjunto de pruebas unitarias, puede crear compilaciones en las que sabe que todas las piezas funcionan juntas correctamente sin quitarle demasiado tiempo a los ciclos de desarrollo del equipo.

Principios orientados a objetos: trato de no ser dogmático sobre esto, pero permanecer en el espíritu de la programación orientada a objetos (me gusta señalar a las personas los principios SOLID como un comienzo) ayuda mucho a desacoplar partes de la aplicación y permitir que la aplicación crezca sin pedirle al PM que controle cada pequeño paso adelante.

Por supuesto, a algunos equipos realmente no les gusta que un gerente de proyecto les diga que mejoren las prácticas técnicas, por lo que es posible que deba abordar eso con delicadeza.

¿Cómo puedo realizar un seguimiento colectivo de las interdependencias de las aplicaciones?
RespuestasAquíPolítica de privacidad1y, 0v