Estamos trabajando en un proyecto que (aproximadamente) consta de las siguientes partes:
Nuestro "equipo", por otro lado, consta de varios equipos de un solo hombre, cada persona trabajando en una parte diferente del proyecto.
Estamos usando JIRA+Agile. Hemos creado un solo proyecto en JIRA, y se crea un componente para cada parte mencionada anteriormente. Cada problema se asigna a los componentes correctos. Esto se aplica principalmente a los tipos de problemas de Epics y Story, donde realmente tiene sentido.
Escribimos historias de usuario de tal manera que PO pueda ver claramente lo que se gana al completar esta historia (es decir, permitir que el usuario vea su bandeja de entrada). Tendemos a crear historias que son lo suficientemente granulares para que puedan completarse razonablemente dentro de un sprint. Las tareas de desarrollo reales se crean como subtareas del problema principal de la historia. Estimamos nuestras historias jugando a Planning Poker, a pesar de que diferentes personas pueden tener diferentes cantidades de trabajo involucradas en cada historia, y tiene sentido para nosotros.
Este enfoque también nos permite realizar un seguimiento del progreso de la implementación de funciones nuevas y complejas en todos los componentes (Epics) al dividirlo en Historias discretas y luego crear subtareas para cada tarea que debe realizarse. A medida que se resuelven las tareas, las historias se completan automáticamente, lo cual es agradable y dulce, y en general estamos satisfechos con cómo funciona todo.
Sin embargo... Vamos a construir otra aplicación cliente para una plataforma diferente (parte del mismo proyecto). El trabajo que necesitaremos realizar ya está bien definido en las Historias existentes, ya que la mayor parte de ese trabajo se ha completado en otras aplicaciones cliente para otras plataformas. ¡El problema es que todas esas historias ya están completas! Y, además, la cantidad de puntos de historia para cada Historia se estima hace mucho tiempo...
Una forma es duplicar todas las historias de usuarios, con respecto a las aplicaciones de clientes existentes, redefinirlas un poco para dejar en claro a qué plataforma se dirigen, volver a estimarlas para esa plataforma. Otra forma es básicamente crear una historia de usuario para cada pieza de trabajo que debe realizarse en cada plataforma, PERO, este enfoque romperá todo el proceso desde el punto de vista de PO, dividiendo así la funcionalidad deseada en varias historias (probablemente no igualmente legibles)... Tal vez fue un error crear un proyecto único para todos los componentes? Pero, fue impulsado por el hecho de que las aplicaciones cliente para cada plataforma básicamente se replicarían entre sí al menos en un 90 %, por lo que habría muchos problemas superpuestos y duplicados...
Pregunta: ¿Cuál sería una buena manera de organizar un proyecto de este tipo usando JIRA y Agile, que nos permitiera trabajar de manera similar a como ya lo hacemos, pero que también nos permitiera una mayor flexibilidad al agregar nuevos componentes que básicamente tendrían que replicar? funcionalidad ya implementada en otras aplicaciones cliente?
Gracias por leer ;)
Cree componentes reutilizables y activos de procesos organizacionales
Una forma es duplicar todas las historias de usuarios, con respecto a las aplicaciones de clientes existentes, redefinirlas un poco para dejar en claro a qué plataforma se dirigen, volver a estimarlas para esa plataforma.
Primero, la ley de CodeGnome; no te preocupes por la tecnología (Jira) hasta que hayas decidido qué quieres hacer y cómo quieres hacerlo.
En segundo lugar, si tiene que escribir aplicaciones cliente para múltiples plataformas, no se preocupe por la tecnología hasta que haya decidido qué hacer y cómo hacerlo. Diseñe la arquitectura del servidor del cliente, luego diseñe las capacidades del cliente y luego descompóngalas en requisitos funcionales y no funcionales. Luego planifique cómo lograr esos requisitos para cada plataforma.
¿Observe cómo ha creado automáticamente una clase de referencia para la estimación? Comience a trabajar en la Plataforma 1; cuando calcule la plataforma 2, determine cuánto de la diferencia entre la estimación y el real afectará su estimación para la plataforma 2. Repita para la plataforma N.
Si comienza creando historias de usuario para cada pieza de trabajo, socava el valor de la reutilización.
Como señaló @Mark C. Wallace, primero decida qué quiere hacer y cómo quiere hacerlo. Por ejemplo, en el proceso de creación de la primera aplicación de cliente, su Product Owner podría haber pensado en cómo mejorar los diseños/flujos. Es posible que su equipo de desarrollo haya aprendido algunas cosas sobre lo que no debe hacer. Simplemente copiando las historias, el equipo pierde la oportunidad de pensar de nuevo a la luz de la experiencia y mejorar las cosas.
Sin embargo, después de la debida consideración de lo anterior, si desea copiar historias en masa, parece que hay algunas posibilidades. Hemos configurado tableros Agile de tal manera que podemos extraer historias de múltiples proyectos. En esta configuración, aunque no la he usado, entiendo que puedo clonar/copiar un proyecto JIRA completo usando la interfaz de línea de comandos de Jira (JCLI) .
Chintán Patel