Campos Personalizados en Jira - ¿Crear o no crear? Ese es el dilema
Si sos Administrador de Jira esta es una pregunta que necesariamente deberías hacerte, no porque no sea posible por supuesto, sino porque como administradores apuntamos a la mantenibilidad de nuestra instancia de Jira.
Mis máximas a la hora de trabajar con Campos Personalizados son:
Limita la cantidad de campos que definís.
No dupliques campos.
No dupliques nombres de campos.
Utiliza nombres genéricos.
Evitas errores humanos, completa automáticamente los campos o maneja lista de opciones estándares para el campo cuando sea posible.
Utiliza los contextos responsablemente.
Y ahora te explico porque son importantes, pero comencemos por lo primero:
¿Qué es un Campo Personalizado?
Hay dos tipos de campos en Jira, los Campos del Sistema (System Fields), y los Campos Personalizado (Custom Fields). Los Campos del Sistema son aquellos campos que son parte del paquete de fields propio de cualquier instancia Jira: Resumen, Descripción, Version, Prioridad, Fecha de Vencimiento, etc, estos no pueden ser cambiados significativamente, solo vamos a poder cambiar algunos mínimos aspectos de ellos desde el esquema de configuración de campos, por ejemplo las pantallas en las que aparecen y en todos los casos, menos con Resumen, detallar si son mandatorios u opcionales o si como si se esconden o no en una pantalla. Estos campos no se encuentran disponibles desde la opción Campos Personalizados.
Los Campos Personalizados, son campos que nosotros podemos definir y personalizar su comportamiento. Definimos Campos Personalizados para que nuestro Cliente pueda registrar la información que necesita y luego hacer uso de la misma, organizando, clasificando o generando informes.
Hay Campos Personalizados que son generados automáticamente por Aplicaciones o Productos, y su edición y configuración desde la opción Campos Personalizados va a estar bloqueada (Locked). Pero nuestro foco aquí son los Campos Personalizados sobre los cuales vamos a poder trabajar de manera completa, ósea los Campos Personalizados definidos por nosotros.
¿Cuáles son sus atributos?
Los campos personalizados tienen una serie de atributos que definirán qué datos pueden contener y cómo se presentarán y buscarán. Revisemos estos atributos juntos:
Nombre: Es la etiqueta que se muestra en la pantalla a la izquierda del campo personalizado.
Descripción: Es el texto de ayuda que aparece debajo al campo.
Valor predeterminado: El valor por defecto que puede asumir un campo cuando se solicita por primera vez. Es importante considerar si lo vamos a utilizar o no, ya que podríamos estar registrando información que no sea relevante, pero este tema quizás es parte de otra publicación.
Contexto: Es una opción muy útil de la cual no debemos abusar. Nos permite generar diversas Opciones para un campo dependiendo de la combinación de proyectos - tipos de incidencias. Entonces para un mismo campo personalizado tendremos distintas opciones dependiendo del contexto en el que estemos parados (combinación proyecto y tipo de incidencia)
Esto puede ayudar a limitar la cantidad de campo personalizado reutilizándolos de una manera diferente.
Pantallas: Son las pantallas en las que aparecerá el campo cuando se cree, edite, consulte o transiciones una incidencia.
Plantilla de búsqueda: el mecanismo para hacer que un campo personalizado se pueda buscar a través de la búsqueda básica y la búsqueda avanzada, también responsable de la indexación de los campos personalizados.
Adicionalmente dependiendo del tipo de campo personalizado sobre el que estemos trabajando vamos a tener los siguientes atributos:
Opciones: Solo disponibles para los tipos Lista de Selección, botones radiales y casillas de verificación. Representan los valores entre los que pueden elegir los usuarios. Ejemplo, para el campo severidad podemos tener las opciones: Bloqueante, Grave, Medio, Leve
Filtrado de usuarios: Solo disponible para campos del tipo selector de usuario, nos permite definir el conjunto (grupos o roles) de usuarios entre los que se puede elegir un campo usuario.
Entonces, ¿Cuándo crear un Campos Personalizados?
La teoría acerca de las buenas prácticas en la creación de campos nos dice:
Limita la cantidad de campos, solo deben crearse cuando utilizar un Campo del Sistema no sea una opción apropiada.
La creación de los campos debe estar justificada, agregar campos genera más complejidad en la administración de Jira.
Siempre que sea posible, reutiliza los campos personalizados, por ello es importante que su nombre sea lo más estándar posible para reducir complejidad y simplifica la reporteria.
No dupliques nombres de campos, Jira permite crear campos personalizados con el mismo nombre, he visto instancias de Jira con hasta 10 campos personalizados con el mismo nombre, incluso estos han llegado a compartir el tipo, esto puede causar grandes problemas. Idealmente, estos campos deberían fusionarse, pero si eso no es apropiado, asegúrate de mantener la unicidad de los nombres (osea que no se repitan).
Intenta no dejar margen para el error humano en la carga de la información, elegí el tipo correcto de campos, ya sea número o texto. Para este último caso los campos de Lista de Selección, son preferibles a los campos de texto o etiquetas. De esta forma nos vamos a asegurar que la reportería sea más consistente y la búsqueda en JQL más certera.
¿Cuál es el objetivo?
Teniendo en cuenta estas buenas practicas, al crear campos personalizados deberíamos tener en cuenta dos objetivos:
Objetivo 1: Mantener al mínimo el número de campos personalizados
Usualmente ante la necesidad de un cliente relacionado con agregar un nuevo campo, me hago las siguientes preguntas a modo de checklist:
¿No hay ningún Campo del Sistema que contemple o se adapte a la carga de esta información? Si y solo si esta respuesta es negativa paso a la siguiente.
¿Para qué lo necesita el cliente?
¿Filtrar incidencias de un proyecto, tablero o cola?
¿Es información relevante para para la toma de decisiones? Esto contempla automatizaciones y transiciones, entre otros.
¿Se va a mostrar la información en Reportes o gadgets?
Intenta trabajar estas preguntas con tu Cliente, ya que apuntan a resolver si realmente este campo es necesario, y te permitirá saber si el mismo se va a utilizar o va a convertirse en un campo que nadie sabe porque está en la pantalla. Una vez que decidimos crearlo nuestro siguiente paso es preguntarnos: ¿Existe ya un campo que permita registrar esta información? Si existe, e hicimos bien el trabajo requerido en el Objetivo 2 vamos a estar bien.
Objetivo 2: Mantener nuestros campos personalizados lo más estándares posibles
Hay dos aspectos claves a considerar acá, y que requieren de grandes habilidades por parte de nuestro Administrador de Jira
Unicidad y generalidad del Campos Personalizados
Acá es donde vas a tener que sacar tu “habilidad blanda” a relucir, ya que vas a tener que explicarle a tu cliente la importancia de que el campo sea único y genérico. Ya hablamos de que es necesario comprobar siempre si ya existe un campo con el mismo nombre antes de crearlo, pero ¿porque es importante? si ya existe el campo y agregamos otro igual, las búsquedas JQL pueden resultar un dolor de cabeza. Tampoco crees campos con el mismo nombre que un Campo del Sistema. Por ejemplo, tener dos campos con nombre "Resolución" puede ser confuso. Utilizar un nombre genérico para el campo nos va a ayudar a reutilizarlo. Si el cliente nos pide que generemos un campo que se llame “Categoría del Bug”, podríamos sugerirle generar un campo personalizado que se llame “Categoría”, y lo podríamos utilizar luego en otras circunstancias con un contexto diferente. Lo mismo pasaría si el cliente nos pide generar un campo “Fecha de Fin de la Historia”, en este caso podríamos utilizar el Campo de Sistema “Due Date” o “Fecha de Vencimiento”. Para dar más claridad a la necesidad del cliente, podemos utilizar luego en la opción de Configuración de Campo (Field Configuration) la descripción del campo que provee más información acerca de lo que se espera se cargue en ese campo. El género del campo personalizado también puede ser un tema, por ejemplo, si tengo un tipo de incidencia llamado Requerimiento el mismo puede tener una tipología con las siguientes opciones: Evolutivo, Correctivo. Si otro proyecto quiere la misma tipología, pero para una Historia, nos podría pedir que sus opciones sean: Evolutiva, Correctiva. No hace falta generar dos contextos, podríamos conversar con nuestro cliente y comentarle acerca de las opciones que tenemos.
Utilice todas las funcionalidades asociadas a un Campo Personalizado
Acá entra en juego nuestra “Habilidad dura” o conocimiento técnico acerca de lo que Jira nos permite hacer con un campo personalizado. Lo primero que tendremos que hacer al crearlo es decidir el tipo de campo personalizado que vamos a generar, recordando que no todos los tipos de campos son iguales cuando se trata de informes. Los campos estructurados, como las listas de selección y selección múltiple, son particularmente efectivos, ya que el usuario tiene un número limitado de opciones para elegir y, por lo tanto, existe un conjunto fijo conocido de opciones para buscar y mostrar en sus informes. Por otro lado, los campos de texto están menos estructurados y solo se pueden buscar usando el operador contener (~), lo que significa que son mucho menos útiles en los informes, ya que las personas no siempre ingresan los datos correctamente o como lo espera la consulta JQL utilizada en el informe. Lo mismo podría pasar con las fechas, que selecciono ¿Selector de Fecha o Selector de Fecha y Hora? Depende para que lo vamos a utilizar, usualmente solo utilizo “Selector de Fecha y Hora” cuando este campo se registrara automáticamente y cuando lo voy a utilizar para hacer cálculos precisos de duración. Ejemplo una automatización que calcule la duración entre dos fechas.
Tienes un criterio distinto para implementar lo presentado? Contanos en los comentarios
Es muy común que haya más de una forma de hacer las cosas con las herramientas de Atlassian y nos encantaría descubrir otras formas de resolver las mismas.
Esperamos hayas disfrutado la lectura,
Hasta la próxima.