Administrar las herramientas de Atlassian no solo consiste satisfacer las necesidades de los equipos, sino también velar por la salud de la instancia. Establecer políticas de administración y configuración es un parte clave de la administración que muchas veces es pasada por alto. En esta publicación busco presentar cuales son algunos de los criterios claves al momento de definirlas y cuál es el impacto que las mismas pueden tener en la escalabilidad de las soluciones. En particular busco destacar los criterios a tener en cuenta sobre los siguientes ítems:
Creación de campos personalizados
Crear campos es necesario para que un proyecto gestione sus actividades correctamente. Sin embargo no establecer lineamientos claros de que tipos de campo deben prevalecer sobre otros así como también las características que deben tener sus nombres pueden llevar a que la cantidad de campos crezca exponencialmente con el paso del tiempo. Incluso cosas tan simples como poner un valor por defecto en un campo puede dificultar tareas a futuro. He visto en múltiples ocasiones está configuración aplicada a contextos globales de los campos,significando que absolutamente todos los tickets de todos los proyectos tenían un valor en ese campo, haciendo la tarea de limpieza de campos en desuso prácticamente imposible.
Para ver otros puntos importantes a definir en los campos personalizados puedes revisar en nuestro artículo previo.
Personalización de flujos y pantallas
Si bien podría parecer que estás políticas podrían ser independientes de las políticas para la creación de campos bajo una primera impresión, nos damos cuenta que no es así cuando vemos en más detalle. De la mano de la creación de campos, vienen por detrás las solicitudes de mostrar los mismos en distintas partes del proceso y bajo ciertas condiciones.
Lo cual claramente puede traducirse a flujos de trabajo (workflows) más complejos que conllevan a tener menos chances de ser reutilizables a futuro en otros proyectos.
Dentro de algunas cosas a destacar podemos mencionar lo siguiente.
Estados con nombres genéricos: Es más común de lo que uno quisiera ver workflows con estados como pendiente de aprobación o pendiente de respuesta cuando a fines prácticos todos son lo mismo a nivel métricas y condiciones. Estos solo hacen más complejos el workflow y minimizan las posibilidades de reuso.
Transiciones únicas: Establecer que las transiciones al mismo estado siempre es la misma y por ende con los mismos campos a mostrar en las pantallas, indistinto del estado de origen del ticket. Debo poder contar con los dedos de las manos las cantidad de casos en dónde el cliente haya podido justificarme porque viniendo de estados distintos la información solicitada debe de ser diferente. Sí bien en una primera instancia no parece tener mayor impacto, al momento de hacer resolución de problemas, son más potenciales puntos de falla a revisar y corregir o bien simplemente a agregar nuevas condiciones al proceso.
Procesos lo más simples posibles o con alto nivel de reuso: Tal vez uno no pueda a nivel administrador justificar que los procesos sean simples pero debe ser parte de los argumentos de negociación para qué los procesos no escalan en complejidad y pueden ser reutilizados por otros proyectos de otras áreas. Cómo esto no siempre es el caso me ha pasado en varias oportunidades de tener que personalizar los procesos a sabiendas de que el mismo iba a tener un alto nivel de reuso en múltiples proyectos de la instancia para así evitar qué las horas de trabajo para satisfacer la demanda de todos los equipos no escalen exponencialmente.
Archivado y borrado de proyectos
Conservar proyectos por los siglos de los siglos no es una buena estrategia para los administradores, ya que hace prácticamente imposible corregir los errores del pasado. Podemos terminar acarreando con Campos en desuso que no se puedan borrar o Estados que no se alinean a los estándares y luego sea más difícil justificar los mismos cuando un usuario final viene a pedir uno qué al igual que este no cumple con el estándar.
A raíz de esto es recomendable establecer un tiempo de inactividad de los proyectos y posterior a eso procederá un archivador con un posterior borrado de los mismos dentro de lo que permita las políticas de la compañía como tal. Es posible que ciertos proyectos por cuestiones de registros no deban ser borrados por cinco o diez años pero no necesariamente todos ellos deben cumplir con dicha Norma y nos abre la posibilidad a mantener solamente lo indispensable y por ende lo más organizada y ordenada la instancia posible.
Estandarización de nombres de los ítems de configuración
Estandarizar nombres es esencial para mantener consistencia a través de toda la configuración de los productos. En muchos casos cuando hay un único administrador esto parece no tener mayor sentido, pero uno debe tener la consideración de que eventualmente uno como administrador podría dejar su puesto o bien se sumará un par para colaborar con la administración y allí sí se abren las posibilidades a qué se pierda la consistencia y por consiguiente sea más difícil la gestión de los productos. Cuando cada uno nombra los ítems configurables a su manera, solo uno entiende qué es lo que significan y el potencial impacto que puede tener si uno modifica el mismo.
Aprobación de cambios
A raíz de la buena práctica de administración de Jira, es importante el reuso de los ítems configurables, Esto hace que potencialmente cada cambio que pide un usuario tenga impacto en mayor cantidad de proyectos en la medida que la instancia como tal crece.
Es por eso que de la mano del reuso de las configuraciones debe ir una política definida quién debe de aprobar cambios que tengan impacto en múltiples proyectos. Claramente también debe de considerarse en qué ocurre si el requerimiento es crítico pero no es aprobado por los respectivos aprobadores. En muchos casos estos puedan ser indicadores de una bifurcación en la configuración de los proyectos lo cual debe trabajarse con sutileza para evitar que cada solicitud se convierta en una nueva bifurcación alejándose así de la buena práctica qué es el reuso de las configuraciones cómo mencionamos inicialmente.
Suma de aplicaciones
De manera similar al punto anterior en donde los cambios de un flujo de trabajo podrían tener un impacto masivo a nivel instancia agregar una aplicación extra es otro de los casos en donde el impacto no solo es a través de toda la plataforma sino que puede conllevar un impacto económico y un esfuerzo adicional para el grupo de administradores de las misma. En estos casos es más difícil tener un único aprobador como en casos anteriores, por lo que la política debería de considerar distintos factores qué ayuden a la definición de cuáles productos serán incorporados a la solución. Dentro de las más importantes a considerar sería el costo del mismo cantidad de usuarios o proyectos que lo requieren y harían uso de él cantidad de funcionalidades disponibles dónde potencialmente un producto satisfaga lo que en otros casos se debería hacerse con dos aplicaciones o más.
Si bien este documento habla de políticas, es probable que en algunos casos más que políticas terminen siendo recomendaciones y lineamientos en donde hasta cierto punto tenga que haber flexibilidad en uno o varios de los ítems mencionados. Claramente mientras menor la flexibilidad sea necesaria aplicar, mayor la facilidad de administrar y mantener los productos. No olvides de documentar todas estas políticas en Confluence o bien alguna otra plataforma donde la información esté disponible y sea pública para que todos los usuarios puedan ver la misma.
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.
Comments