jueves, 24 de agosto de 2023

Jira: Odiemos a Jira

 "¡Hey, parece que está de moda criticar a JIRA! 

Normalmente, no suelo ser el tipo de persona que defiende a capa y espada una tecnología en particular, ni siquiera si la adoro. Sin embargo, creo que es importante odiar las cosas por las razones correctas. Si es que, a fin de cuentas, JIRA sigue siendo simplemente la mejor herramienta para rastrear tareas personalizadas con flujos de trabajo a medida, y además permite realizar búsquedas y reportes súper potentes sobre ellas. Ahí está la clave: "a medida". Sí, hay un montón de plataformas que cobran lo mismo o menos que JIRA y te ofrecen un espacio chulo para tus proyectos, pero generalmente se les olvida una de las funciones de personalización o búsqueda que mencioné antes.

Pero, entonces… ¿Por qué se suele odiar a Jira?

Las razones más comunes que escucho para odiar a JIRA son:

  • Es demasiado complicado.
  • Paso más tiempo haciendo seguimiento de tickets que trabajando.


Odian al micromanagement

Si crees que JIRA es demasiado enredado, es porque alguien que lo configuró metió más estados en el flujo, más flujos, más validaciones, pos-funciones, pantallas y campos de los que realmente necesitas para tu trabajo. 

Una búsqueda rápida de "flujo de trabajo complicado en JIRA" nos da esta imagen de idalko.com, parece ser un grupo que ayuda a la gente con sus procesos empresariales. Esta es su manera de cómo NO se hace un flujo de trabajo.


Si tu flujo es así, no odias a JIRA, odias a tu gerente que metió todo eso para saber en qué están en cada momento del día o a tu organización que es muy burocrática y complicada, con procesos enredados y alguien configuró el enriedo de tu organización. 

A ver, JIRA es una herramienta genial para armar flujos como ese, pero no puede impedir que la gente lo use mal. JIRA es tan complicado como tú lo configures. Viene con flujos de trabajo bien sencillos y muy pocos campos en la página. En 5 minutos puedes estar listo para seguir tareas que van desde "Abierto" a "En progreso" y luego a "Cerrado". 

¡Vamos, eso no es pedir mucho! Cualquiera debería poder dar esa cantidad de información sobre su tarea. Aunque esto es útil para metodologías como GTD o para simples tareas, cuando trabajamos con software y con marcos de trabajo como Scrum o Kanban esa simplicidad es algo contraproducente y escueta. También he trabajado en empresas donde equipos tienen flujos y estados super simples y pasan un año y siguen sin hacer testing, demorándose en subir a producción meses y con pésimas prácticas de ingeniería de software. El flujo de trabajo debe servir para coordinarse y para entender el trabajo y mejorar. Según Scrum debe servir para transparencia, inspección, adaptación y mejorar. Y en Kanban debes reflejar tu flujo real de trabajo para encontrar cuellos de botella y mejorarlo. Lo difícil es encontrar un punto medio y simple.

Odian a sus no-gerente

El otro problema común es el no-gerente, el "gerente" que no habla contigo y no sabe mucho sobre lo que estás haciendo. Solo quieren echar un ojo a un tablero, ver todas las luces verdes y contarle a sus jefes que todo está bien. Este tipo de gerente te pide estimaciones detalladas de tiempo (deadline), 15 pasos en el flujo de trabajo y actualizaciones diarias. Claro, JIRA es una herramienta que puede hacer todo esto, pero no significa que deba hacerse. JIRA no reemplaza la necesidad de gerentes hábiles y líderes de equipo que realmente sepan qué está pasando, que confíen en sus equipos, que generen claridad, empoderamiento y faciliten el proceso.

Odian a cualquier gerente (a la transparencia)

Seamos sinceros: quizás no sea tu gerente, quizás seas tú. En algunos proyectos en los que he trabajado, el seguimiento de tareas no es precisamente bienvenido, pero también rechazan la agilidad (Agile).

Hay gente que prefiere que le asignen tareas, tener mucho tiempo para hacerlas, a su ritmo lento, y asegurarse de que nadie más sepa cómo hacer su trabajo, no sea que los reemplacen. 

Yo creo que siempre habrá trabajo para gente hábil y trabajadora. Las habilidades que necesitas pueden cambiar, pero siempre habrá trabajo por hacer. Enfoca tu tiempo en perfeccionar esas habilidades y en encontrar un buen lugar para trabajar, en lugar de tratar de proteger tu empleo actual escondiendo lo que haces.

Odian Aprender

Hay quienes odian a Jira porque no quieren aprender a usar herramientas nuevas. Probablemente esperaban que JIRA fuera como un botón mágico para manejar tus actividades o desarrollos. Quieren las funciones que ofrece, pero no quieren invertir tiempo en aprender a usar la herramienta. O peor aún, odian aprender y mejorar, y si tienen que dar transparencia de su trabajo y de cómo trabajan pueden quedar en evidencia, de que son persona de mentalidad fija y conformistas de su zona de confort, que puede ser desordenada y poco productiva. Entonces les molesta transparentar su forma de trabajar.

Buscar el equilibrio

Mi consejo es encontrar el punto medio: ni flujos muy simples que no sirven para mejorar ni coordinarse ni flujos super complicados; ni issues con descripción vacía y títulos que no dicen nada, ni issues que sean un documento de requerimiento detallado (exceso de documentación); tampoco ausencia de issues, ni el extremo de estar detallando toda tarea que se hace; ni NO reflejar esfuerzo, ni tampoco estar trackeando todos los días cada hora en que se ha consumido (micromanagement).

Pienso que un flujo de trabajo más simple que sirve para gestión, iniciativas, Scrum y Kanban es el siguiente: 

Para historias de trabajo de desarrollo de software me ha servido algo bien simple como: Backlog, Selected For Development, In Progress, Ready for Accept, Done, Closed. La separación de Done a Closed es para reflejar que puede haber un tiempo de incremento potenciablemente entregable (pasó una definición de terminado) a entregado (listo en producción). Sino el estado Closed es inecesario. O algún flujo semejante como el siguiente.


Cuando configures Jira y lo uses, piensa en lo siguiente:

  • Aplica los valores y principios del manifiesto ágil, de Scrum o Kanban.
  • Los flujos ni tan simples ni complicados, con estados grises al principio (pocos), estados azules en el medio y verdes al final (uno o pocos).
  • En los flujos no agregar validaciones, ni pantallas emergentes ni pos-funciones. Solo alguna si es necesaria.
  • No agregar muchso campos personalizados.

Jira es una plataforma inmensamente poderosa y, con un poco de trabajo y planificación, puedes asegurarte de que esté configurada exactamente como deseas. Como resultado, podrás desbloquear un enorme aumento en la productividad.

Referencia: 

https://jarvispowered.com/you-dont-hate-jira-you-hate-your-manager/

https://www.smartsheet.com/jira-workflow-best-practices




jueves, 3 de agosto de 2023

Retrospective: Check out o feedback final

 

Esta actividad permite identificar si nuestra reunión está causando el efecto esperado o si tiene puntos de mejora. Es una actividad de salida ocurre justo antes de que los participantes salgan de la reunión. Por lo general, recopila información sobre la reunión en sí: qué tan valiosa fue, cuánto se aprendió, qué tan valiosa fue la reunión, cualquier comentario específico o estado de ánimo de salida.

El resultado de la actividad de salida puede contener comentarios valiosos sobre la estructura y el contenido de la reunión. Considéralo cuando planifiques la próxima reunión.

Son actividades muy cortas. Piense en ello como un check-out de hotel efectivo, donde el huésped (participante) abandona el hotel rápidamente, con la sensación de ser escuchado y dando una valiosa retroalimentación al hotel.

A continuación te comparto algunos ejemplos:

¿Qué te pareció?




¿Cómo me voy?


Repeat/Avoid

Ejecutando la actividad:

Pida a los participantes que agreguen sus notas en consecuencia:

* ¿Qué debemos repetir?

* ¿Qué se debe evitar?

Agrupe las notas y discuta.

Esta es una actividad retrospectiva común para la recopilación de datos. Es una alternativa para mantener al equipo comprometido mientras cambia ligeramente el formato.






Referencias: