Guía jira Proyecto de Gestión de la Configuración (B) - Configuración de flujo de trabajo

Todavía a esta figura como un principio se ha hablado antes, proyecto creado problemas relacionados con el campo correspondiente, el contenido de interfaz relacionada. El paso siguiente es el contenido más importante y complejo flujo de trabajo relacionado.

Artículos anteriores han introducido la idea de flujo de trabajo, principalmente 02:00:

• Subtareas unidades de la tarea principal del estado de flujo.
• Simplificar y automatizar el campo de flujo y reflujo.

flujo de trabajo general

Workflow Servicio es el principal problema (problema), Jira se encuentra entre el soporte de núcleo. Flujo de trabajo tiene dos conceptos fundamentales: la conversión (de transición) y el estado (Estado) .

Utilizamos un flujo de trabajo sencillo de explicar.
En la figura anterior, para hacerlo, en curso, de tres efectuado indica el estado , también representa los tres colores señalaron que el significado de, azul no se ha iniciado, para el amarillo, verde completado.
Cuando es necesario agregar un nuevo estado en el proceso, tendrá que elegir uno de los tres colores.
La línea que conecta los dos estados, es decir, la conversión, lo que significa que a través de este acto, la pregunta desde el estado 1 a un estado 2.
Estado es el resultado de que, podemos definir el número de operaciones realizadas por los resultados obtenidos por la conversión realizada en el momento de la conversión, la figura flujo de trabajo es operable cuando se selecciona la conversión de contenido.

Figura elegí " Ir en curso " esta conversión, aparece a la derecha cinco opciones, que a su vez explican:

• propiedad
• gatillo
• condición
• validador
• funciones de post-procesamiento

propiedad

Mira un ejemplo

Aquí es el uso del título y la internacionalización de la página Enviar teclas de botón

gatillo

Ojo de Crucilbe y puede estar asociada con la conversión rama y el código se realiza automáticamente CodeReview.

condición

Única condición es satisfecha, la conversión se puede realizar

Algunas de las condiciones contenidas en este documento y Jira plugin viene con una mayor

validador

script de validación similar a la de enviar el formulario, puede llenar para confirmar la validez de la

funciones de post-procesamiento

Después de la ejecución con éxito de la conversión, la costumbre de algunas operaciones.

Nuestros procesos automatizados después de la transformación funciones son promover la necesidad de intervención.
Para todo el mundo para ver un sub-tarea de las funciones de post-procesamiento para activar automáticamente un flujo de trabajo ejemplo:

tipo de flujo de trabajo

Personalizadas de flujo de las necesidades de nuestras necesidades de gestión actuales, diferentes maneras en que cada equipo de gestión, la naturaleza y el tipo de problemas de flujo de trabajo no es lo mismo. Estoy aquí para hacer que el proceso real de la clasificación de la gestión de la I + D en cuatro flujos de trabajo.

• La principal tarea del flujo de trabajo
• flujo de trabajo Subtarea
• flujo de trabajo bug
• flujo de trabajo predeterminado

Este flujo de trabajo de cuatro, que cubre básicamente los procesos relevantes y el papel de trabajo de gestión de I + D.

La tarea principal

El concepto principal tarea incluye la historia (historia) y tareas (Task), la historia es proporcionada normalmente por productos lanzados corresponden al concepto habitual de la demanda (necesidades principalmente funcionales, por supuesto, también pueden contener requisitos no funcionales, pero en general permitirán a los usuarios para percibir ), la tarea suele ser impulsada por el trabajo de desarrollo en marcha (como refactorización de código, el servicio de división, la optimización del rendimiento, el usuario puede no ser consciente del contenido significativo).
La tarea principal es el contenido básico de la obra se resume en un equipo de investigación y desarrollo, por lo que el flujo de trabajo es una necesidad de incluir todas las funciones, productos, diseño, desarrollo, prueba, operación y mantenimiento en el equipo de I + D y así sucesivamente. tareas generales también se ordenan diversas funciones de la circulación, por lo que el flujo de trabajo se puede dividir en estas funciones, cada función se ponen a-hacer, en progreso, completado los tres estados. Que se puede ajustar para completar la siguiente parte de la tarea pendiente, tener en cuenta estos dos estados se pueden combinar en una sola.

subtareas

Recuerdo que uno de nuestros principios es el de simplificar la gestión de las operaciones de investigación y desarrollo, los titulares de mandatos reales no necesitan comprender la complejidad general del diseño y un funcionamiento simple lógica será capaz de conducir el proceso general hacia adelante. Eso es confiar en el concepto de sub-tareas.
En nuestro equipo de I + D, todos los elementos específicos del personal sólo pueden ser realizadas con un tipo de registro es subtareas. campo de subtareas Streamline, debe contener sólo el contenido. El proceso es simple, sólo es necesario incluir a-do, en curso, completó. Puesto que el defecto se va a ejecutar después de que el nuevo sub-tarea, por lo que las operaciones normales sólo pueden contener dos actos, en curso y terminados. Con los paquetes de arte etiquetados antes, y conmutando el estado de finalización es simple, es posible empujar el estado de flujo principal cambie sus roles.

Error

Bug es una forma importante de I + D de Gestión de Calidad, insecto de la garantía de la calidad general del partido presentación, el destinatario está más desarrollada, que podría ser el producto. Error en el proceso de flujo de trabajo, el proceso es bastante clara, es centrarse en resolver y verificar el insecto, la transferencia propuesta entre el receptor. Queremos optimizar el punto de que la gente puede darse cuenta de proceso de conversión automática, sin asignación manual.

defecto

Al momento de escribir el código tendrá que seleccionar una rama tiempo de ciclo predeterminado, siempre que la opción por defecto es el más simple de cosas por hacer, en curso, se puede completar, o incluso sólo tiene que hacer y que esté terminado, podemos confirmar la situación real.

Diseñador de flujo de trabajo

Diseño de flujo de trabajo no es un requisito previo importante es que el grupo de usuarios se divide, para la distinción entre las funciones.
Los siguientes cuatro anteriormente se describirá en detalle el flujo de trabajo implica algunos ajustes o lugares guión tratar de poner un ejemplo claro o codificado.

La tarea principal

Flujo de trabajo tarea principal para cubrir todos los papeles, es un primer vistazo mayoría de los estados en la figura.

Este proceso en 11 estados, comenzó como un valor predeterminado al-do (hacer), el siguiente podemos ver realmente, basado en los roles divididos en varios bloques, el extremo derecho es el producto, seguido por la siguiente a la izquierda diseño de interfaz de usuario, desarrollo, prueba, y en última instancia completa.
Aquí hay algunos puntos de diseño y podemos hablar acerca de:

1. Estado TODO se puede convertir en un papel de cualquier estado.
   Debido a las diferentes circunstancias en diferentes Historia o de tareas, el papel de la participación real es la diferencia, si limitamos el flujo de todos los caracteres deben tener procesos pueden no ser tan flexible. Por lo que cada función realizada en el estado de todo se puede convertir directamente de TODO terminado, pero el estado de finalización sólo puede ser convertida de en curso.
2. Todas las conversiones se nombran en un formato uniforme.
   La conversión puede ver todos los dos tipos principales de prefijos: Ir y completado , respectivamente, correspondientes a los avances que hacer, y el progreso hasta la finalización. La razón de esto, en primer lugar, al nombrar a un modelo unificado es relativamente simple no creo que un montón de nombres, debido a que el mismo esquema, el mismo estado puede tener múltiples estados se puede llegar, con el fin de facilitar los flujos de trabajo automatizados de seguimiento están diseñados para que podamos útil (esta frase más adelante en el flujo de trabajo de sub-tareas que pueden ser bien explicado).
3. Las diferentes etapas de pre-nodos de diferentes
   productos es la etapa inicial, un comienzo debe ser las necesidades de productos para ordenar y organizar la creación de prototipos y el diseño.
   Frente I son productos diseñados generalmente, pero también inician independientemente algunos requisitos (tales como diseño de UI reconstrucción de revisión, etc.)
   fase de investigación y desarrollo, pre-nodos también pueden ser la interfaz de usuario del producto, ya que el proceso normal es prototipo acabado a producto para el diseño, la interfaz de usuario diseño de la investigación hecho para desarrollar juntos. Por supuesto, también es posible entregar el producto directamente sin necesidad de I + D adicional para desarrollar el diseño. Por lo que el diseño puede ser utilizado como entrada y producto de la investigación y el desarrollo.
   Introduzca la prueba debe ser desarrollado, porque no se han desarrollado para cambiar el sistema, sólo tiene que ser probado.
   El nodo final, en la mayoría de los casos, los resultados deben ser publicados en línea después de la prueba confirmó garantía, un pequeño número de casos, la prueba puede no ser capaz de verificar la confirmación inmediatamente después de la liberación de desarrollo.

funciones de post-procesamiento

escenario estado de las tareas principales de la gran cantidad, pero una configuración especial de hecho muy pequeño, yo estoy aquí solamente un post-procesamiento de las características especiales de diseño es el siguiente:
Tenemos centros de investigación y desarrollo y centros de atención al cliente, centros de atención al cliente puede tener algunas sugerencias o clientes externos de errores se puede convertir en tareas de investigación y desarrollo internos. Vamos a utilizar la orden de trabajo asociada a "órdenes de trabajo asociado con" R & D Center Story y centro de asistencia, cuando la aplicación de la I + D interna Story " ir a completar el" estado de cambio asociado a las órdenes de trabajo.
Esta función requiere un plug-in JMWE, proporcionado Transición vinculado cuestiones tales método.

Configuración de aquí es relativamente clara
primera fila seleccionar lo que desea activar las cuestiones relacionadas con la conversión (por nombre o ID), se selecciona el siguiente tipo de enlace.
sección de la pantalla debajo de la transición, lo haremos "gerentes" a "Altavoz", lo que significa que la orden de trabajo ha sido liberado en la línea, que informó de este problema tiene que ver seguimiento posterior hacia arriba.
Hará un comentario final en las órdenes de trabajo correspondientes: proceso interno de I + D se ha completado y publicado.

La principal tarea de resumen

misma tarea principal es una manifestación de los métodos de gestión, con el fin de procesar los diversos papeles en la serie, y puede soportar una mayor perspectiva rápidas tareas relacionadas de seguimiento para promover el proceso de convergencia.
Por lo tanto, la tarea principal es nadie para mantener la normalidad, es decir, nadie va a tomar la iniciativa de las principales tareas de la administración del estado, sólo estamos mirando.

subtareas

Si la tarea principal es compleja y simple (estado son muchos y complejos, pero la lógica detrás de la sencillez), sub-tarea es simple y complejo. ¿Cómo entender esta frase, Echemos un vistazo en el flujo de trabajo de subtareas.

Vistazo a esta tabla básicamente entender, no me ajusté el flujo de trabajo más sencillo, pero el flujo de trabajo sólo tres estados, descartó la única inicial a-do, el estado normal se puede conectar dos. Así subtareas son simples.
A continuación nos fijamos en la complejidad de significado

A partir de este proceso de conversión que se realiza, tenemos un total funciones de post-procesado 15, el sistema viene removidos, tenemos la función de post-procesamiento de nueve personalizado.
Del mismo modo, se reúnen para hablar sobre algunos de los puntos de los cuales el diseño:

1. Subtareas son parte de la tarea principal, por lo que debe ser es un conjunto de subtareas tarea principal de la planta de personal.
   Nuestro diseño, o en el inicio de los nuevos sub-tareas se añadirán a la memoria y de los gestores de tareas padre responsable de campo, nombre de la tabla asociadas al personal a lo largo de la misión que, una comunicación más rápida.

funciones de post-procesamiento

La tarea principal es la de convertir la sub-dos, el tratamiento a realizar, y el proceso hasta su finalización. Todas nuestras funciones de post-procesamiento, tanto en la conversión.

El procesamiento por hacer

Hacer para llevar a cabo en un total de nueve reglas personalizadas miramos juntos:

reglas de fechas

Regla 1 se utiliza para establecer el valor de campo de esta característica, lo que significa que desea hacer clic en la hora de inicio, la fecha de inicio se establecerá la tarea de la hora actual.
El objetivo es mantener la hora de inicio de las tareas parciales en tiempo real, no requiere que el operador ajuste manualmente el tiempo.

resolver resultados

Regla 2 también se utiliza para establecer los valores de campo , que es resolver el resultado de sub-tareas establecidas para la tarea padre.
El propósito es provocar subtareas se puede reflejar en la tarea padre, por lo que se las arregla para averiguar si hay una solución resultados especiales.

responsable

Regla 345 también se utiliza para establecer los valores de campo , que es responsable del mantenimiento del campo.
El objetivo es añadir sub-tareas o las personas encargadas de campo de corriente principal tarea del personal encargado, encargados de la tarea principal campo es el de preservar todos los participantes para identificar rápidamente la gama de personas. Más sub-tareas es aclarar la responsabilidad.

flujo avanza tareas principales

La regla 12-15 es el uso de Transición Edición padre (JMWE el add-on) , que es proporcionada por el tapón. La tarea principal es poner en funcionamiento el flujo del proceso.
El objetivo es promover el flujo principal tarea de subtareas de flujo. En este caso sería más complicado, nos fijamos en la implementación específica, la siguiente figura

Aquí estamos divididos en cuatro partes:

• Ajuste el flujo principal tarea del gatillo
• Ajuste los valores de campo
• Añadir un comentario
• Establecer la condición de ejecución

Ajuste el flujo principal tarea de disparo : el papel que queremos abordar aquí en nombre de principios. La premisa aquí se desencadena el flujo principal tarea, o la exigencia de la corriente principal tarea del Estado es el punto de partida de la circulación de destino. Esto significa que si el flujo de trabajo actual es A → B → C, si se espera que la implementación de A → B, que el estado de la tarea principal de corriente debe ser para alcanzar con éxito la A a la B, no sería eficaz. Nuestra convención de nomenclatura donde todos se convierten a un estado de flujo llamado "Go xxx", tal método puede accionar una variedad de circulación en el estado inicial.

Establecer valores de campo : esto ya es un diseño más convencional, este proceso no tiene que establecer el contenido del

Comentario : Todo ejecución de procesos automatizados, añadir automáticamente un comentario junto a la tarea principal es registrada por la que se avance a lo estatal. Trayectoria para más adelante

Establecer las condiciones de ejecución : Este es realmente el núcleo de la función de post-procesamiento de todo ello de acuerdo con el orden, que debe ser capaz de realizar la tarea principal para promover el flujo del proceso suave, que sólo puede ser juzgado por la condición de ejecución. Hay principalmente para determinar el papel del usuario actual por grupo de usuarios, para decidir qué promover la circulación de las tareas principales. Lo siguiente es de diseño, desarrollo, scripts de prueba cuatro subtareas se inician funciones:

• rol de Jefe de Producto

(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm") && issue.getAsString("任务类型") == "")

Esto se determina si el usuario actual es un grupo de usuarios del sistema org-PD-producto-pm palabras (Producto Manager), y no se proporciona sobre todo el tipo de tarea.
Hola a todos a entender grupo de usuarios, el tipo de tarea ¿Qué significa?
Hemos encontrado que debido piso de trabajo Todo el mundo debe convierte en sub-tareas, algunas subtareas son en realidad no avanzan los cambios de estado del proceso. Por ejemplo, la demanda para el gerente de producto de pre-investigación, análisis de viabilidad, la demanda en realidad no avanzó solo, de manera temporal no debe ser la tarea principal de promover el diseño de productos en tal estado. Esta situación se puede remediar mediante el proceso de finalización de la tarea principal de estado, que son otra forma es la creación de un sub-tipo especial de trabajo para avanzar en el proceso para evitar un estado incorrecto. Así formamos un acuerdo interno, una vez que el valor de sub-tareas conjunto tipo de tarea, no va a promover el flujo del proceso.

• papel de diseño de interfaz de usuario

(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui") && issue.getAsString("任务类型") == "")

• papel de I + D

(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder") && issue.getAsString("任务类型") == "")

• puesto de probador

(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa") && issue.getAsString("任务类型") == "")

Proceso hasta su finalización

Aquí hay cinco reglas personalizadas:

flujo avanza tareas principales

Regla 6-10 usando la Edición matriz de transición (JMWE el add-on) , el contenido de lo anterior no se repite
aquí solamente las funciones principales de post-procesamiento, vamos a explicar sobre el desmantelamiento

• Productos completan
  esta parte de la lógica determina en primer lugar si el usuario está operando actualmente la función del producto, si no es ignorado por completo. Si es así, la voluntad ciclo de todas las sub-tareas bajo una tarea de los padres, y se determina si o no el producto es atribuible a la función de la tarea. Si la misión es el tipo de producto, o no se ha completado. Sólo además de la tarea actual, todos los demás productos se hayan completado las tareas, que pasarán a la condición de finalización de la tarea principal de la función correspondiente.

if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm"))){
  return false;
}

boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
  if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-pm")){
    if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
      return false;
    }
  }
}

return result;

• diseño de interfaz de usuario se ha completado

if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui"))){
  return false;
}

boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
  if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-product-ui")){
    if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
      return false;
    }
  }
}

return result;

• I + D se completa (hay prueba)
  desarrollado para determinar las condiciones será un poco número especial, habrá un análisis completo de desviar I + D tiene dos ramas, la necesidad de pruebas.
  La lógica es realmente muy simple, está circulando todas las sub-tareas, determinar si existe un grupo de usuarios para probar las sub-tareas, si se ha recurrido a " desarrollado la prueba ," si no es para " desarrollar completa sin pruebas ."

if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder"))){
  return false;
}

boolean result = true;
boolean hasQA = false;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
  if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder")){
    if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
      return false;
    }
  }
  if(!hasQA && (issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
    hasQA = true;
  }
}
if(!hasQA){
  result = false;
}

return result;

• I + D se completa (sin prueba)

if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder"))){
  return false;
}

boolean result = true;
boolean hasQA = false;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
  if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-coder")){
    if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
      return false;
    }
  }
  
  if(!hasQA && (issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
    hasQA = true;
  }
}

if(hasQA){
  result = false;
}

return result;

• La prueba se ha completado

if(!(currentUser in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa"))){
  return false;
}

boolean result = true;
for(int i=0; i<issue.parentObject.subTaskObjects.size;i++){
  if(issue.parentObject.subTaskObjects[i].assignee in ComponentAccessor.getGroupManager().getUsersInGroup("org-pd-qa")){
    if(issue.parentObject.subTaskObjects[i].key != issue.key && issue.parentObject.subTaskObjects[i].getAsString("状态") != "Done"){
      return false;
    }
  }
}

return result;

resumen subtareas

Los principales sub-tareas, es simple y complejo. proceso simple con el fin de mejor equipo en la implementación de detrás del escenario lógica compleja para satisfacer las necesidades de gestión de la administración.

Error

Bug es el desarrollo de defectos de calidad en el proceso de prueba, el proceso no es complicado, principalmente automatizado requisitos de circulación y de control.

Sólo cuatro estados, y sub-tareas en comparación con, de hecho, sólo un estado más "ha sido resuelto." prueba de errores se propone por defecto, después de un nuevo estado es el " para-hacer " la investigación y el desarrollo empezar a procesar se traduce como " en curso ", la I + D se traduce en "después de la finalización se ha resuelto ", la prueba seguirá " ha sido resuelto ," el fallo, si se confirma resolver se convierte en " completa ", si no se resuelve después se convierte en " el progreso ".

funciones de post-procesamiento

Sobre la proa, el hecho más importante es que las funciones de post-procesamiento " en curso " y " resolver " devolución directa y hacia atrás, por lo que nos fijamos en la " resolución de problemas " y " sin resolver " después de tratar con dos conversiones.

Resolver el problema

Debe ser de interés principalmente responsable del tratamiento. Sólo para resolver el resultado es "Done" (otro general no puede ser reproducida, entorno de red anormal, la demanda de este tipo de diseño, etc.) cuando llegamos a la operación actual como una persona responsable. Esto es para confirmar que el desarrollo de la rendición de cuentas, no es en realidad sólo el desarrollo y el proceso de aprobación sólo requiere Bug responsabilidad atribuible a la investigación y el desarrollo.
Los gerentes serán asignados automáticamente al altavoz, evitando así especificar manualmente los gestores de I + D.

irresoluto

importancia de conversión sin resolver es decir, la investigación del insecto sometido a la prueba en realidad no la reparación, la necesidad de volver a la investigación y el desarrollo. Aquí está la necesidad de acumular "para devolver el número de veces que" este campo personalizado,

<%
int i = issue.get("退回次数") >= 0 ?issue.get("退回次数"):0;
i=i+1;
println(i)
%>

Los gerentes también deben ser asignados directamente a la rotación de personal actual sobre el personal de I + D anteriores. Usando el "Asignar al último miembro de función (JMWE add-on)" plug-in proporciona.

El papel del proyecto, tenemos que configurar el proyecto.

Se puede configurar en la configuración del proyecto en este menú.

resumen bug

Bug lógica general de muchos relativamente simple, principalmente para facilitar la transferencia entre la I + D y pruebas, y tratar de asegurar que el personal automatizados asignados a la conversión.

Por defecto de tareas

La tarea por defecto aquí no extenderme normal "de hacer - en curso - acabada" proceso de conocer.

resumen

En este punto, todos los introduce de diseño de flujo de trabajo completo, algunas de las cuales implicó el uso de guiones maravillosos están escritos en idiomas, la parte más difícil es todavía la necesidad de identificar cómo obtener el campo en modo de adquisición en Groovy.

Principalmente a través de aquí para explorar algunas herramientas de ayuda.