Uno de los valores de Agile dice así: “Personas e interacciones sobre procesos y herramientas”. Por encima de todo, las personas y su manera de relacionarse, antes que centrarnos en sus procesos y herramientas. Esto no quita que los procesos y las herramientas sean también importantes solo que menos. No somos muy amantes del mundo digital en lo que se refiere al Sprint Backlog, preferimos un tablero físico. Sin embargo, para el Product Backlgo sí que es interesante tenerlo digital, ya que nos permite medir a nivel de producto, poder visitar a los usuarios y contrastar con ellos lo que vayamos a hacer. Además, en época de coronavirus, toca usar herramientas digitales. Jira es posiblemente uno de los software más extendidos para implantar Scrum y puede ser relevante el saber administrarlo.
Llevo muchos años usando Jira, pero es la primera vez que lo hago como administrador, y esto me ha permitido conocer mejor la herramienta. Desde mi perspectiva, muchas empresas no usan bien Jira para implantar Scrum. Algunas, por desconocimiento de Jira y otras, del propio Scrum. Vamos a dar una serie de pasos para construir un equipo (llamado proyecto en Jira) y configurar algunos elementos básicos para trabajar.
Creando un “proyecto” Jira Scrum
La creación de proyectos Jira es sencilla. Recordemos que en Scrum nos gusta hablar de producto, y no tanto de proyecto. Sin embargo, el concepto de proyecto se asocia a un equipo, es la unidad mínima de organización de un equipo en Jira. Cuando pulsamos en la pantalla de crear proyecto, tendremos que decidir si de nueva generación o uno clásico.
Los de nueva generación nos ahorran mucha configuración, me recuerdan en gran medida a un Trello con forma de Jira. El gran problema es que estos proyectos apenas tienen informes, y parte de la potencia de un equipo Scrum es medir su capacidad de entrega y su time-to-market, por lo que nos decantaremos por uno clásico.
Una vez creado el proyecto, tenemos la opción de elegir un template (en los que tengo, hay uno de Kanban y de Scrum). Si quieres un equipo Scrum, no te preocupes lo explicamos a continuación.
Nada más crear, podemos abrir un board, y ahí seleccionar Scrum o Kanban. Recordemos que podemos crear boards para varios proyectos, o varios en un proyecto. Normalmente los boards se utilizan para generar reportes o para organizar el trabajo. Vamos a apostar por un solo Scrum Board para el resto de configuración.
De esta manera, podemos tener un proyecto Scrum con un board Kanban (u otros que necesitemos).
La diferencia entre ambos es que, en Scrum, tendremos una vista “backlog” y otra, con el Sprint Backlog, además de contar con la opción de introducir Sprints. En Kanban, el trabajo se visualiza en un único vistazo.
Elementos de configuración
Para poder configurar, debemos irnos a la vista de administración, en Jira settings, y veremos muchos elementos.
En Jira existen varios elementos como: IssueTypes, Screens, Fields, Workflows y Permisos que se configuran de manera independiente, pero después se mezclan mediante esquemas. Un esquema es una configuración de los anteriores y permite la reutilización entre varios equipos de elementos similares.
Vamos a estudiar cada uno de ellos por separado, cómo podemos configurarlos para que funcionen a nuestro gusto.
Permisos en Jira Scrum
La configuración de permisos tiene un papel muy relevante y es una configuración que no me gusta como viene planteada de base en Jira. En la zona de configuración y seguridad, podemos definir los roles que queremos tener en nuestro jira.
Podremos crear los que necesitemos, en mi caso solo usaré los tres de Scrum: Product Owner, Scrum Master y Development Team. Quizás, si lo necesito, tenga el rol “stakeholder” como un rol adicional para alguna función que pueda ser interesante.
Después, nos dirigimos a la zona de issues y “Permission Scheme” donde podremos definir nuestros esquemas. Un esquema de permisos define qué acciones pueden hacer según qué roles. Veamos un ejemplo.
¡Cuidado con esta configuración! En mi caso, como entiendo que un equipo Scrum debe usar la transparencia, he asignado muchos permisos a todos los miembros. En muchas empresas, veremos muchas restricciones en algunas acciones, lo que huele a falta de confianza. Una vez más, Jira para hacer Scrum depende de cómo se configure.
Después, en el propio proyecto, asignamos el esquema de permisos que queramos usar
Una vez hecho esto, queda asignar a nuestros usuarios un rol o varios en el proyecto. Para esto, debemos irnos a la zona “People” de nuestro proyecto.
Issues, los ítems de trabajo en Jira para hacer Scrum
En Jira, los issues representan los Items de trabajo de Scrum. Es importante que nos detengamos para analizar qué servicios o trabajos vamos a realizar. Los tipos de issues representan una información importante, ya que les podemos asociar campos, seguridad o workflows diferentes. Por tanto, debemos pensar muy bien qué tipos vamos a necesitar. A la hora de crear un tipo nuevo, deberemos elegir entre tipo estándar o subtarea. Estos segundos se agrupan en uno estándar, y a la hora de visualizarlo, se hace normalmente de manera diferente.
En nuestro caso, hemos creado varios tipos de issues genéricos, en Scrum serían diferentes tipos de PBIs:
- Bug: para errores, habría que definir quién los crea.
- Improvement: mejoras sobre elementos ya existentes de nuestro producto.
- Feature: conjunto de historias de usuario que representan una funcionalidad concreta.
- Document: utilizado por si hay que generar algún tipo de documentación.
- Task: tarea técnica.
- Epic: en nuestro caso, las épicas son contenedores de historias, pero no tienen fin (a diferencia de las features).
- Spike: se utiliza para experimentos, en general no llevan estimación ya que se centran en probar algo que desconocemos.
- Technical Enhancement: la mejora técnica representa todo aquel elemento técnico que tenemos que abordar. En Scrum, solemos conocer este elemento como Deuda Técnica, pero al tener cierta connotación negativa, le hemos cambiado el nombre.
- Story: requisito funcional escrito en forma de historia de usuario.
Lo siguiente que podemos configurar son los IssueTypeSchema, que sirven para agrupar IssueTypes, después se asocian con tu proyecto de manera que esos serán los que se podrán usar. En mi caso, para esta agrupación he añadido todos los elementos.
Por último, en nuestro proyecto tendremos que elegir qué esquema aplicar.
Fields y Screens
Los issuetypes son importantes, pero son tipologías de ítems, ahora toca definir qué información queremos en cada uno de ellos. Para ello, se utilizan los screen, que son pantallas que se asocian con los issueTypes. Un Screen a su vez está compuesto de campos, y podemos crear campos propios (custom fields).
Lo primero es pensar qué información queremos almacenar. Por ejemplo, nosotros vamos a crear dos campos fecha, uno para inicio y otro para fin, de cara a medir el CycleTime (tiempo que tardamos en completar un ítem desde que decidimos abordarlo hasta que está “terminado”).
En los campos custom, encontraremos una amplia gama de opciones, en nuestro caso marcaremos DatePicker.
El siguiente paso es el Field Configurator donde configuramos los campos. Esta parte es muy importante, podemos marcar campos como obligatorios u ocultos. Los campos que trae Jira por defecto también se puede configurar para que no aparezcan.
Por último, tendremos que generar el Field Configurator Schema. Este esquema relaciona issuetypes con diferentes esquemas de campos, de esta manera, podemos tener campos diferentes según el tipo de issueType.
Lo siguiente será configurar nuestras propias screen, cuando creemos una podemos definir los campos que aparecerán, incluso añadir pestañas para estos campos.
Lo siguiente es crearnos esquemas, al igual que con los fields, solo que ahora relacionamos operaciones (crear issue por ejemplo) con las pantallas. Podemos ver unos campos al crear una issue y modificarla.
A continuación, tenemos que relacionar estos esquemas con las IssueTypes. Esta relación permite seleccionar que esquemas y operaciones se usarán según el tipo de issue, así podremos ver cosas diferentes para una story que para un spike.
Con esto, tenemos una configuración total sobre operaciones, información y pantallas. Por último, en nuestro proyecto deberemos añadir esas configuraciones en las opciones de la izquierda.
Workflows en Jira Scrum, una pieza clave
Los worklows son una de las herramientas más potentes de Jira. Nos permite organizar cómo evolucionarán las issues. Los workflows representan esquemas formados por estados y transiciones donde explicamos cómo un issue cualquiera lo recorre, con el workflow schema decidimos qué issueType usará ese workflow, y así podemos asignarlo a un proyecto.
Este esquema es el que estoy usando ahora mismo como básico para los equipos Scrum. El significado de los estados es:
- Request: nos han solicitado algo, o bien hemos decidido que lo haremos.
- Refinement: issues que tenemos que refinar
- Ready: issues listas para ser abordadas en un Sprint
- In progress: aquellas que ya estamos haciendo.
- In review: este estado es para “revisar”, ese concepto cambia según cada equipo, desde peer review de código hasta funcional con el Product Owner o alguien de la organización.
- To deploy: este estado es para preparar la subida.
- Done: hemos finalizado.
Cuando usamos Jira para Scrum, debemos dejar cierto grado de libertad a los equipos para que modelen sus workflow. Cada equipo puede tener necesidades diferentes según su contexto, y lo interesante de este tipo de herramientas es la flexibilidad que ofrece a los equipos.
Como comentamos antes, tenemos que crear un workflowschema donde relacionemos cada issueType con su workflow concreto. Os dejo un ejemplo de cómo asignar diferentes workflows a diferentes tipos:
En el proyecto donde vayamos a usar este workflow, tenemos que añadirlo en el panel de la izquierda.
Funciones extra útiles para usar en el workflow de Jira Scrum
En las transacciones tenemos las “postfunciones” que nos permiten ejecutar acciones cuando una issue se mueve de esta:
Podemos programar una función para que, cuando asignemos una tarea en un estado, se autoasigne a la persona que ha hecho ese movimiento. Así, ayudamos a la autoorganización del equipo.
Otra postfunción útil es la de cerrar completamente una issue terminada. Para eso, en las transiciones que vayan hacia estados finales debemos añadir esta opción:
Si no añadimos esto, tendremos que hacerlo a mano, y podemos alterar nuestras métricas. Podemos crear una función inversa si ocurre la transacción “reopen” cuando abrimos algo que se acabó por algún motivo.
Otra de las postfunciones que he probado es rellenar un campo concreto que me interese en algún punto del proceso. Para poder medir el CycleTime, estoy probando a tener un campo “start” y “finish”, y rellenarlo cuando me interesa para tener este dato. Aun así, aún me queda investigar un poco más los informes para descubrir cómo tener esta información.
Configurar tu tablero Jira para usar Scrum con Jira
Ahora toca configurar nuestro panel visual. Esto es especialmente importante, porque será donde inspeccionaremos y adaptaremos nuestras tareas. Recordemos que la transparencia es un pilar de Scrum, y cómo tal debemos actuar.
La gran diferencia entre Scrum y Kanban en Jira es que en Scrum disponemos de una vista de “backlog”. En Kanban, estará integrado como una columna dentro del board.
En nuestro board, lo primero que debemos configurar es, qué columna corresponde con qué estado.
Es importante que seleccionemos los estados en las columnas correctas. En general, un estado por columna suele ser recomendable, así las transiciones son más fáciles. También es importante que los estados estén asignados a columnas de izquierda a derecha siguiendo el camino de los estados, esto ayuda a la visualización.
Conclusiones
Este artículo es una recopilación de una configuración básica para operar. En el futuro, investigaré cómo hacer informes avanzados y opciones avanzadas con workflows o con addons. Siendo mi primera vez como administrador, quería plasmar todo el aprendizaje y que le pudiera servir a otras personas que empiezan con Jira.
Y tú, ¿qué herramienta digital utilizas?
