¿Cómo visualizar y administrar las dependencias de tareas?

A menudo tengo la necesidad de lograr un objetivo específico (por ejemplo, entregar una funcionalidad de software). Al comienzo del trabajo, identifico el objetivo y puedo enumerar algunas tareas necesarias para lograr el resultado deseado. Para cada una de las tareas identificadas, es posible que pueda dividirlas en subtareas. Sin embargo, por lo general, las tareas (en diferentes niveles de detalle) necesarias para lograr el objetivo se descubren a medida que avanza el trabajo. Entonces, por ejemplo, es posible que se necesite algo de investigación (una tarea en sí misma) para determinar el mejor enfoque para una parte particular del trabajo antes de que se puedan identificar las tareas de trabajo reales.

En la forma más básica, puedo representar la jerarquía de tareas compuestas utilizando, por ejemplo, una lista con sangría, aunque existen dificultades para representar también restricciones de ordenación arbitrarias. Alternativamente, puedo usar Microsoft Project para mostrar la jerarquía de tareas y el orden de las tareas.

Sin embargo, ambos enfoques son bastante 'listas'. Me preguntaba qué métodos existen que me permitirían representar las tareas y sus relaciones en un diagrama, tal vez mostrando los nodos como tareas y las relaciones (por ejemplo, composición, orden) como líneas.

Buena pregunta, pero se parece demasiado a una pregunta de lista de compras . Es posible que desee reformular ligeramente para evitar pedir una lista de cosas.
Gracias @Sarov, eliminé una pregunta. Esperemos que sea un poco más centrado.
La frase "Me preguntaba qué herramientas existen" la convierte en una pregunta de la lista de compras .
Ah, sí, ya veo. Como esta es realmente la pregunta para la que quiero una respuesta, supongo que este no es el foro adecuado para esto. Sin embargo, veo que corro el riesgo de ser penalizado si elimino una pregunta respondida.
¿Te refieres al qué o al cómo? Generalmente administro las dependencias entre los elementos del backlog, pero dejo que el equipo descubra las dependencias de las tareas.
Me refiero tanto al qué como al cómo. Usando qué y cómo como sustantivos, cada cómo se puede descomponer aún más en cómo (entonces, en este contexto, el cómo descompuesto es un qué). El principio es aplicable a cualquier nivel, ya sea que una persona describa o no lo que hace como que define el qué, mientras que otros definen el cómo. Presumiblemente, sus qué son solo descomposiciones de "cómo" de un qué más grande. Suena todo muy confuso y probablemente haya mejores términos para estos (por ejemplo, tareas y subtareas), pero espero que entiendas lo que quiero decir.
Dado que etiquetó su pregunta con "ágil", tengo que intervenir aquí. Si su gráfico de dependencia es tan complejo, está haciendo mal la planificación ágil. Es posible que desee repensar su metodología y granularidad, y dejar que el equipo administre las dependencias dentro de cada iteración.
¿Qué está mal con la vista del diagrama de red en MS Project? (aunque estoy de acuerdo en que esta es tanto una pregunta de lista de compras como una pregunta anti-ágil)

Respuestas (5)

TL;RD

Respete el cuadro de tiempo y haga una "planificación justo a tiempo". No haga tanta descomposición por adelantado y, en cambio, confíe en la entrega iterativa para proporcionarle un diseño emergente.

Análisis

Desde un punto de vista de planificación ágil, está haciendo algo fundamentalmente incorrecto si su trabajo pendiente requiere gráficos de dependencia complejos. En particular, eres:

  1. no aprovechar el concepto de finas porciones verticales de funcionalidad para ofrecer de forma incremental; o
  2. estás tratando de hacer demasiada descomposición por adelantado.

Los marcos de trabajo ágiles no están diseñados para trabajos que requieren un diseño y una especificación inicial pesados. Están destinados a diseños incrementales, iterativos y emergentes. Aprovecha eso. Debe adoptar la entrega incremental e iterativa y el diseño emergente si desea tener éxito con una metodología ágil .

Recomendaciones

Metodología del proyecto

Si usted es el gerente del proyecto, necesita refinar su metodología. Específicamente, debe volver a trabajar en su cartera de productos para que no intente hacer tanta descomposición inicial que toda su cartera esté llena de tareas.

Idealmente, su cartera de pedidos estará llena de epopeyas y temas cohesivos , y solo el trabajo para las próximas iteraciones se descompondrá en historias de usuarios relativamente independientes. Las historias de usuario deben seguir el mnemotécnico INVEST , de modo que no tenga que lidiar con un gráfico de dependencia complejo.

Solo debe definir tareas para la iteración actual. Si bien las tareas ciertamente pueden tener dependencias, una función que se ha diseñado correctamente para una sola iteración no debería tener tantas tareas que sea necesario un gráfico de dependencia complejo.

A veces, es posible que necesite un pico de historia en un cuadro de tiempo para ayudar a refinar, descomponer o planificar el trabajo por delante, ¡pero no se espera que ese trabajo encaje en la iteración actual! Si descubre tareas nuevas o no planificadas durante una iteración, programe el trabajo para una iteración futura siempre que sea posible. De lo contrario, es posible que deba detener la iteración actual y volver a planificar. ¡Así es como funcionan fundamentalmente las metodologías iterativas!

Gráficos de dependencia

Hay muchas metodologías para la representación gráfica de dependencias. Uno de los más útiles en el espacio de desarrollo de software es el Método Mikado . Ayuda al equipo o desarrollador a trabajar hacia atrás desde el objetivo hasta el estado actual, identificando dependencias y refactorizaciones a través de un gráfico dirigido . Sin embargo, en última instancia, el gráfico es un medio para un fin y no un objetivo en sí mismo.

Si no está haciendo software, otras técnicas pueden ayudarlo a resolver dependencias y ordenar su gráfico. Libros enteros están repletos de teoría y práctica sobre cómo generar dichos gráficos, por lo que una lista exhaustiva estaría fuera del alcance.

Sin embargo, en las metodologías ágiles, el trabajo programado para la iteración rara vez necesita el nivel de representación gráfica que parece estar solicitando. Si bien es muy útil para definir la ruta crítica en las refactorizaciones, el trabajo no programado tiene un nivel demasiado alto para crear un gráfico de este tipo, mientras que el trabajo programado debería ser demasiado obvio para necesitarlo.

Gracias, es muy interesante, especialmente el Método Mikado. Usé la etiqueta ágil porque la forma en que tiendo a trabajar es iterativa, dejando las decisiones en el punto en el que deben tomarse. No creo que haya sugerido una gran descomposición inicial de tareas en mi publicación original. Realmente me interesaba lo contrario. La capacidad de planificar de forma incremental solo lo suficiente para poner el trabajo actual en contexto y poder modificar el plan a medida que avanza el trabajo.
De todos estos, el método Mikado parece el más apropiado para el software. "el gráfico es un medio para un fin, y no un objetivo en sí mismo" - ¡esto es cierto para todas las técnicas de planificación, en mi opinión!

Prácticamente podría construirlo integrando Excel / MS Project, SharePoint y PowerPoint. Aunque es doloroso de construir, vale la pena, ya que se puede personalizar según sus necesidades.

Sin embargo, parece que existe una herramienta de este tipo que podría aportar un efecto visual para la gestión de tareas.

  1. http://itsm360.net/task-management/ Desde la asignación hasta el cierre, puede visualizar la secuencia completa. Puede encontrar más detalles sobre este producto en su sitio web.
Desde un primer vistazo al sitio web, esto parece otra tarjeta y un enfoque basado en listas. No es el tipo de cosas en las que estaba pensando. Gracias de cualquier manera.

Hay dos enfoques clásicos para visualizar requisitos/tareas y sus dependencias.

  1. Método del Diagrama de Preferencia

  2. Gráfico de gantt

Estoy bastante seguro de que encontrará algunas herramientas para su técnica favorita.

Creo que el método de diagrama de preferencia es posiblemente el más cercano a lo que estoy pensando, gracias.
Bueno, de estos dos de todos modos. El Método Mikado mencionado por @CodeGnome se parece aún más.
@factor, eso es lo que pensé. Si encontró útil esta respuesta, no olvide votarla o incluso aceptar la respuesta. También vale la pena leer meta.stackexchange.com/questions/5234/…
@factor, no sé mucho sobre el Método Mikado, pero por lo que sé, originalmente no está acostumbrado a modelar los requisitos del proyecto.

Dentro de mi aplicación Scrum remota he integrado evaluaciones muy simples, tanto para ProductBacklogItems como para las tareas: A) el riesgo es una combinación de: 1.) complejidad: valor[1,2,3] 2.) innovación: valor [1,2,3] B) las dependencias son en ambas direcciones: 1.) cuánto dependen los demás de esta tarea: valor[1,2,3] 2.) cuánto depende esta tarea de los demás: valor[1 ,2,3] ... además: en caso de que tenga valores más altos dados (un 3 o dos 2): agregue algo de texto en el área de texto sobre cómo desea manejar esto ...

puede visualizar esto con una cuadrícula de 9x9 y hacer que los colores sean verde-amarillo-rojo (como un semáforo).

Hice la aplicación (la solución Scrum remota CYBR-SUITE (CYSU)) disponible a través de Sourceforge en este momento: https://sourceforge.net/projects/cybr/

Se ejecuta en docker a través de docker-compose: "todo" lo que necesita es un VPS con 2 GB de RAM y un kernel de Linux (además de docker y docker-compose, por supuesto ... consulte README.md para ver una instalación paso a paso). .)

Img a continuación es una captura de pantalla que muestra la valoración/evaluación de ProductBacklogItem, pero es muy similar para las tareas.esta imagen es del elemento ya que yo, como PO, no he agregado las tareas de DevTeams en él, pero las tareas tienen los mismos campos para la evaluación/evaluación de riesgo y dependencias

Solo debo decir esto: "Microsoft Project®" es el rey de esa colina, y por muy buenas razones". Es excelente para administrar dependencias entre tareas. El producto nació de un conjunto de macros de Microsoft Excel que Microsoft Corporation fue utilizando para sus propios fines... y se nota. Nunca he encontrado ningún producto de software en el mundo de código abierto que se le acerque. Compre una copia y apréndalo muy bien.

¿Cómo visualizar y administrar las dependencias de tareas?
RespuestasAquíPolítica de privacidad1y, 0v