Cómo modelar la preparación de historias para problemas que se abordan en varios proyectos

9

En nuestra empresa, varios equipos trabajarán en diferentes componentes de varios proyectos al mismo tiempo. Por ejemplo, un equipo puede hacer que los tipos específicos de software (o hardware) para algunos proyectos, otro equipo, otro tipo específico de software. Usamos proyectos de Jira para albergar problemas para proyectos específicos y tableros de Jira para sprints para diferentes equipos.

Nos enfrentamos al problema de evitar la duplicación de código en todos los proyectos, y hemos desarrollado un conjunto de bibliotecas principales que usamos en esos proyectos. Mientras trabaja en un proyecto, algunos desarrolladores se darán cuenta de que una pieza de código que han escrito es de mayor interés y debe extraerse en una biblioteca central, o que algún código central que están utilizando tiene un error, necesita más parametrización o un nueva característica ... lo que sea.

Por lo tanto, crean un problema de la biblioteca central que entra en la cartera del proyecto central. Todos estos problemas se revisan, priorizan y estiman en una reunión de la biblioteca central (una vez por semana), y se abordarán de acuerdo con su prioridad (junto con problemas específicos del proyecto) en algunos sprints futuros.

La priorización se realiza ordenando los problemas, y ponemos una sortedetiqueta en los problemas ordenados (para que podamos buscar los que no están ordenados). Luego, colocamos manualmente un problema por componente principal en la parte superior de la cartera de pedidos para que se aborden primero. Cuando algún equipo pone un problema de este tipo en su sprint, tienen que arrastrar manualmente otro elemento a la parte superior de la cartera de pedidos.

Esto es bastante propenso a errores. Básicamente, lo que tenemos son los estados de problemas adicionales "ordenados" y "estimados" entre "abierto" y "en progreso". Reflejar esto a través de la sortedetiqueta y su posición en el tablero es bastante engorroso y propenso a errores. (Por ejemplo, si alguien mueve un problema en algún sprint arriba y abajo, esto se reflejará en el tablero central, revolviendo en silencio el orden de los problemas que el equipo podría haber decidido en una extensa discusión semanas antes).

Entonces, ¿cuál sería una mejor manera de implementar esto?

— sbi
fuente

2

Parece demasiada sobrecarga diplomática solo para agregar una función a una biblioteca. En nuestra compañía de 50 desarrolladores (software médico), todavía permitimos que los desarrolladores solo envíen código a cada una de nuestras bibliotecas internas si lo consideran apropiado. Es revisado después, por supuesto. ¿Tal vez pueda considerar trabajar con un flujo de solicitud de extracción pero una reunión? No. Eso nunca va a funcionar.

— Teimpz

@Teimpz: Por supuesto, todos ingresarán a las bibliotecas internas y, por supuesto, se revisará cada código. Sin embargo, el orden en que se abordan los problemas centrales (que no son necesarios para algún proyecto actual) es decidido por todos los equipos. Eso funciona bastante bien, solo que Jira no parece soportarlo bien.

— sbi

La sobrecarga parece bastante, pero dado que el núcleo se usa tanto, estaría dispuesto a aceptar un poco de sobrecarga para asegurarme de que nada salga mal. Sin embargo, una reunión parece mucho. Lo vería como cualquier otra tarea, pero la comunicación adicional (revisiones, conversaciones) sería importante.

— Erdrik Ironrose

2

Si desea seguir esto en JIRA, lo seguiría como si fuera una tarea nueva.

Así por ejemplo:

Digamos que tienes la historia CORE-75: Foo the Bar .

Una vez que se decide qué equipo tomará la tarea, pueden crear una nueva tarea: APOYO-123: Foo the Bar en Core .

Luego puede bloquear CORE-75 con SUPPORT-123 . Una vez que SUPPORT-123 haya finalizado, puede volver a CORE-75 . Puede fusionar las revisiones o revisar el código dos veces (una vez por el equipo designado, una vez por un equipo más específico del núcleo).

Esto es realmente lo que está haciendo de todos modos: considere la biblioteca principal como su propio producto / cliente, no vaya a la mitad.

— Erdrik Ironrose
fuente

Eso parece engorroso, pero sí, funcionaría. Entonces +1de mi parte.

— sbi

0

Un enfoque es que el equipo cree un nuevo problema para su sprint que se vincule con el problema principal de la biblioteca. Es como si estuviera haciendo una subtarea para una tarea pero en todos los ámbitos / atrasos.

Otro enfoque es solo rastrear esto por separado fuera de JIRA. Exporte la cartera de pedidos existente como CSV u hoja de cálculo y organícela.

Al separar los problemas de JIRA, tiene flexibilidad para definir la prioridad en la reunión de planificación y no tiene que preocuparse por el algoritmo de clasificación de JIRA en los tableros y tampoco tendrá que usar etiquetas.

En la reunión de planificación de priorización para la biblioteca central, puede crear una lista corta de tareas para completar para la biblioteca central y quien sea responsable / responsable de la biblioteca central puede asegurarse de que estas tareas sean iniciadas por los diferentes equipos del proyecto y completadas.

— Rudolf Olah
fuente

-2

Existe la opinión de que las bibliotecas principales que encapsulan una gran cantidad de funcionalidades comunes, pero no relacionadas, son una "cosa mala" (tm)

Hay algunas razones para esto.

Toman dependencias y códigos que no necesita
Cambiarlos provoca cambios en todas las aplicaciones
Ningún 'propietario' único

En su caso, creo que su división de tareas por la aplicación a la que se realizaría el cambio es la raíz del problema. Una especie de ley inversa de Conway.

Creo que la mejor solución para usted sería alejarse de tener 'Bibliotecas principales' Las bibliotecas deberían tener un conjunto específico (pequeño) de funcionalidad agrupada lógicamente. Debería ser posible completarlos. es decir, JsonParser, LogWriter, etc., rara vez debería tener sentido agregar una nueva función.

Sin embargo, suponiendo que esta sería una tarea larga y difícil, como solución secundaria, simplemente mantendría las tareas principales de la biblioteca con el equipo que necesita la funcionalidad. es decir.

Tarea: agregar la función X al producto Y

Dev: hmm, parte del código para la función X debería ir en una biblioteca compartida. Lo pondré allí como parte de esta tarea

— Ewan
fuente

Esto parece extraño Para empezar: ¿Cuál crees que es la diferencia entre lo que llamas "bibliotecas con un pequeño conjunto específico de funcionalidades agrupadas lógicamente" y lo que llamamos "bibliotecas principales"? (Por cierto: parece que me he perdido la notificación de esta respuesta. Perdón por responder tan tarde.)

— sbi

Creo que esta es la cita más destacada para mí: "un fragmento de código que han escrito es de mayor interés y debe extraerse en una biblioteca central". Si sus proyectos compartidos son 'bibliotecas' completas de funciones, entonces nunca necesitará agregarles una función.

— Ewan

No entiendo tu argumento. ¿Por qué algún código no se beneficiaría del mantenimiento? ¿Y sus clientes nunca solicitan nuevas funciones, lo que lleva a escribir un nuevo código? ¿Y cómo sabe que el código es de interés común, aparte de que se le asigne otro proyecto con un requisito ya interesado?

— sbi

Digamos que tu biblioteca es Json.Net. Tiene un propósito serializar objetos para json y revertir. seguro que es posible que deba corregir un error o agregar compatibilidad con los genéricos, pero el conjunto de características generales nunca cambia. Nunca está en la posición en la que, por ejemplo, un cliente le pide que implemente 'la capacidad de cancelar pedidos' o lo que sea y piensa, 'lo agregaré a Json.Net'

— Ewan