Pasa otro fin de semana de revisión (introspección le daría demasiada seriedad y entidad al asunto) sobre posibles cambios o mejoras en la forma de trabajar (pensando siempre como freelancer).

Otro de los ajustes que implementé en estos meses fue la normalización en la configuración de los proyectos en Jira. Si bien el post está centrado en la configuración de la herramienta, no se trata sobre la misma.

Desde hace ya uno o dos años (sinceramente no lo recuerdo) en Jira se agregó un nuevo tipo de proyectos, llamado Next-gen (en contraposición de los classic projects). En caso de no conocer este tipo de proyectos, aquí la documentación oficial.

Además de agregar o cambiar alguna funcionalidad, parte de la promesa era la simplicidad en la gestión de los proyectos. En Jira es muy fácil complicar el workflow de trabajo dada la cantidad de opciones que posee, y si bien en algunos casos puede ser útil y necesario, también es fácil caer rendido ante el reino de la burocracia y hacer que un proyecto se parezca a un laberinto.

Como mi instancia de Jira lleva ya unos varios años, en algún punto comencé a tener un zoológico de tipos de proyecto bastante variado. El post es un recuento de los ajustes que apliqué para estandarizarlos (y ver qué pasa en un tiempo).

Luego de migrar cada proyecto al nuevo formato, lo primero que hice fue definir qué funcionalidades usaría. La lista se redujo a:

Y ahora, lo más importante, lo que ha quedado fuera del menú:

El Roadmap no me sirve porque no voy a trabajar con épicas y el Backlog, si bien podría ser usado, me genera un efecto no deseado: me quedan issues escondidos en el backlog y el proceso de visualizarlos me agrega burocracia.

Como no uso Backlog, los Sprints no tienen sentido. Luego, los Reportes y las Estimaciones tampoco son de uso diario, ya que no voy a medir efectividad del equipo y no va a haber tanta estimación para medir esfuerzo ya que suelen ser los deadlines los que rigen nuestro universo (aunque ya habrá tiempo para escribir sobre los aciertos, y más nada sobre los desaciertos, de las estimaciones).

Ahora, dentro de un proyecto, por defecto tenemos (en los de tipo Next-gen) tres posibles estados para un issue cualquiera:

  • To-do
  • In progress
  • Done

En esto hice un pequeño cambio y agregué dos estados/columnas.

  • Backlog
  • To-do
  • In progress
  • Blocked
  • Done

Y la definición del workflow no tiene nada raro.

Básicamente, de cualquier estado puedo ir a cualquier estado, sin restricción (ya voy a volver sobre esto).

Los ajustes finales son sobre los tipos de issue y los campos de esos issues. Al comienzo usaba esta configuración.

Pero rápidamente entré en conflicto con el uso de Story y Task (y eventualmente con las Subtasks). Trabajando solo, ya sea con un trabajo remunerado, un producto propio, un proyecto open source o el mismo blog, ¿tiene sentido armar todos estos tipos de issues si varios de los personajes asociados no están presentes?

Me cansé de leer al respecto y de seguir discusiones e intercambios sobre cuándo usar cada tipo. Al fin de cuentas, primó la regla máxima: ajustar a lo necesario y lo posible aquello que determinan los distintos frameworks (tratando de no caer en la creación de un dragón de varias cabezas).

La configuración resultó en la siguiente:

El motivo por el cual quité del menú las Epicas y las Stories es para evitar esa burocracia de la que hablaba antes. Normalmente, como freelancer, uno es el que toma, analiza, ejecuta y testea el requerimiento (se que hay casos en donde puede haber una tercerización de una tarea, pero no es la regla). Eso me llevó a quedarme sólo con los Bugs para cuando se presente uno, las Tareas (porque casi todo será algo accionable) y las Subtareas para cuando deba atomizar o reducir alguna tarea más grande.

Antes mencioné también que el workflow no tenía restricciones o pasos obligatorios. El motivo es, creo, pragmático. Cuando tengo tareas que resolver, van a estar o entre las seleccionadas para trabajar en esta nueva etapa/medida de tiempo a definir (sino quedan en la columna backlog), van a estar siendo trabajadas, y van a pasar a Done si todo se resolvió o quedarán en Blocked si algo me lo impide.

Sumado a esto, usando filtros, puedo identificar fácilmente si tengo tareas que necesitan de algo adicional para poder cerrarse. Vale agregar que los comentarios en las tareas son fundamentales para no perder el rastro (bueno, eso aplica para los freelancers como para los equipos numerosos, ¿no?).

¿Qué me falta agregar?. Los campos de los isssues.

A lo que viene por defecto, le agrego Priority, Time tracking y Due date (posiblemente deba quitar lo de Assignee ya que por defecto los campos se asignan a mi… ya veré más adelante).

Habiendo organizado todos los proyectos de la misma manera y usando los filtros más básicos, he podido armarme un dashboard para tener presente los temas del día.

Está claro que no intenta ser algo visual en términos de gráficos sino el listado agrupado de temas a resolver.

El tema de los indicadores visuales y los objetivos (hola OKR y hola SMART) es también, junto a las estimaciones (y voy a sumar a la gestión del repositorio); motivo para unos cuantos posts, charlas e intercambios.

Seguramente algo de esto habrá durante la próxima revisión.