Como configurar un proyecto SCRUM con Redmine y Agile plugin

1. Introducción

Voy a partir de la instalación rápida que había comentado en la entrada anterior Como instalar Redmine y su Agile Plugin utilizando Docker y la interfaz gráfica Kitematic.

Doy por hecho que tenemos un Redmine levantado y funcionando, pero aún no hemos realizado ninguna configuración. Lo que vamos a hacer a continuación es realizar la configuración necesaria par tener un proyecto SCRUM. Será necesario tocar configuración del propio Redmine y del plugin, justo en eso es en lo que se va a centrar esta publicación.

¡Super-importante! Cuando accedamos por primera vez a la Administración del proyecto nos aparecerá la siguiente pantalla:

Si no pulsamos Load the default configuration, tendremos que configurar posteriormente a mano desde cero los roles, trackers, estados y el workflow de trabajo. En este tutorial se usan los elementos de la configuración por defecto aunque se adapten a las necesidades.

Si ya estás familiarizado con Redmine y cuentas con una instancia configurada, te recomiendo saltar directamente a los puntos 3.1 y 3.3.

2. Entorno

Para realizar la instalación y el tutorial he utilizado:

Hardware: MacBook Pro 15″ 2018 – 2,2GHz i7 – 32GB (macOS Mojave 10.14.4)

Software:

• Imagen oficial Redmine 4.0.4
• Redmine Agile Plugin 1.4.12-light
• Google Chrome Version 75.0.3770.100 (Official Build) (64-bit)

3. Configuración

Vamos a empezar a trabajar con el plugin Agile. En mi caso se trata de la version gratuita Light que tiene algunas limitaciones respecto a la versión PRO, podéis consultar el detalle de estas limitaciones aquí.

 

Las funcionalidad que podemos echar de menos bajo mi punto de vista son las siguientes:

• Guardar paneles con columnas y ajustes customizadas, sí, lo confieso, soy muy fan de tocar los paneles y ajustarlos.
• Diagramas de calles horizontales, también conocidos como swimlanes. En equipos con especialistas o proyectos por componentes, son muy útiles.
• Límites del Trabajo en Proceso, el mal llamado WIP (mal llamado por que la traducción directa sería Work In Progress y realmente es un limite que aplicamos a este) para controlar que cerremos cosas y no solo abramos teniendo una falsa sensación de avance.
• Campos de tarjeta adicionales, no voy a entrar en detalle, aunque muchas veces es muy útil por las características de nuestra organización o de nuestro equipo contar con campos específicos.
• Gráficas adicionales: Burnup, Flujo acumulativo, Velocidad, Plazo. Para mí la velocidad y en diagrama de flujo acumulado son dos herramientas muy útiles para ver cómo estamos trabajando y como nos llega la demanda.

3.1 Configuración general del plugin

Como adelantaba unas lineas más arriba, la configuración necesaria podemos diferenciarla en varios bloques, configuración propia del plugin agile, configuración de aspectos generales de Redmine y  configuración y configuración específica del proyecto.

Vamos a comenzar con la configuración del plugin, para ello, desde el menú de la parte superior izquierda vamos a Administration > Agile.

En la pantalla de configuración voy a establecer los siguientes parámetros:

• Agile board items limit: Mantenemos el valor por defecto 500
• Default card fields: Vamos a añadir a los campos por defecto (Tracker y Assignee) los campos, IssueID para poder tener identificada cada tarjeta, Parent task para poder tener relacionada la Épica (en el caso de utilizar historias de usuario) o su Tarea agrupadora (padre) y Story points.
• Estimate units: Es el sistema de estimación para  planificar el trabajo que queremos implementar, seleccionamos Story points en lugar de horas.
• Tracker for story points: Solo tenemos disponible la opción All, así que no hay duda.
• Default chart: Es el informe de referencia que usaremos para el seguimiento de los avances, ya que hemos seleccionado como unidad de estimación los story points, tenemos que marcar aquí Burndown chart (Story points).
• Exclude weekends from ideal work: Para no presentar los fines de semana en las gráficas (asumiendo que nuestro equipo trabaja de lunes a viernes).
• Time entries based charts issues limit: Mantenemos el valor por defecto 1000
• Hide closed issue data: Para que no se muestre la información de las tareas que hayamos finalizado lo marcamos con el check.
• Auto assign on move: Si queremos simplificar un poco la vida a las personas del equipo esta función nos viene muy bien, de forma que cuando transiten una tarea, esta se asignará automaticamente a la persona que la está moviendo, nos ahorramos una operación de asignación.

OJO: Esto aplica si el equipo es auto organizado, si hay una asignador, lo que hará es entorpecer su tarea).

• Inline comment: Permite editar los campos de nuestra issue/tarea sin tener que abrirla para editar, nos hace más rápido el introducir información.

Recordad pulsar el botón Apply para que se guarden los cambios.

3.2 Configuración general de Redmine

3.2.1 Creación de grupos

Para realizar esta configuración vamos a la sección Administration > Groups > New group. Por defecto nos aparecerán los grupos Anonymous users y Non member users.

Voy a usar una estructura propia de SCRUM, es decir crearemos los grupos:

• Development Team
• Scrum Master
• Product Owner

En la parte superior derecha de la zona de trabajo (espacio blanco, ver imagen anterior) tenemos la opción New group. Lo único que tenemos que hacer es introducir un nombre y pulsar Create (Create and Continue nos permitirá crear varios grupos seguidos). Nos aparecerá un mensaje indicando que se ha creado correctamente y veremos listados los grupos.

3.2.2 Creación de usuarios

El siguiente paso es añadir los usuarios. Se hace desde administración: Administration > Users  > New user.

Introducimos todos los datos, prestando atención a:

• Hide my email address. Si es un proyecto donde acceden personas de diferentes empresas o dominios, tenemos que asegurarnos no estar afectados por ninguna política de privacidad tipo RGPD. Por defecto recomiendo activarla.
• Must change password at next logon. Es una buena práctica que el usuario modifique la clave en su próximo acceso (nos aseguramos de que nadie sabe nuestra clave aunque sea el admin). Es algo que en usuario genéricos no aplicaría, pero este no es el caso.
• Email notifications. Son los avisos que nos va a enviara Redmine según la actividad del proyecto o proyectos en los que estemos trabajando.
  • I don’t want to be notified of changes that I make myself. Activamos esta opción para que Redmine no nos avise de nuestras propias acciones. ¿Si lo acabo de hacer no sabré ya que lo he  hecho? (Tiene casos de aplicación y puede ayudarnos a darnos cuenta de errores que comentemos, pero bajo mi punto de vista es una sobrecarga de información vs el beneficio que aporta).
  • Opciones de notificación:
    • For all events in all my projects. Si pensamos en un equipo de 6 personas trabajando con la herramienta a diario ya podemos pensar en un volumen alto de avisos, si multiplicamos por más personas y/o proyectos… No aconsejo esta opción.
    • Only for things I watch or I’m involved in. Esto implica que si te han mencionado en una tarea vas a recibir notificaciones. Permite no perder comentarios  si alguien necesita de tu ayuda aunque no estés asignado a la tarea o la hayas creado tu. Particularmente me parece que  hay mecanismos mejores para gestionarlos (hablar) y reducir esta carga asíncrona de comunicación. Pero cada uno debe considerar su caso.
    • Only for things I watch or I’m assigned to. Solo si me han asignado una tarea y hay cualquier cambio nos será notificado.
    • Only for things I watch or I am the owner of. Solo si soy el creador de una tarea estaré informado de los cambios.

Mi recomendación es usar la opción «assigned to» y utilizar la opción watch para aquellas tareas que creo personalmente. De esta forma si alguien me asigna algo seré consciente y si creo yo tareas también estaré al tanto de los cambios. En cualquier caso siempre debéis considerar la necesidades y el rol que desempeña el usuario en el proyecto.

Con esto nos quedaría algo así:

Podemos crear tantos usuario como consideremos para nuestro proyecto.

Si desde el listado de usuario hacemos clic en el que acabamos de crear veremos que todos estos cambios afectan únicamente a la pestaña General. Hacemos clic en la pestaña Groups, seleccionamos a que grupo de los que hemos creado queremos que pertenezca este usuario y pulsamos Save. En mi caso voy a asignarlo al grupo de Product Owners.

Veréis que  aún queda otra pestaña Project a la que volveremos una vez hayamos creado nuestro proyecto que puedan trabajar con él.

A nivel de Grupos y Roles decimos que puede hacer de forma general un usuario/grupo, pero el acceso al proyecto determina si pueden hacerlo sobre ese. Aunque un usuario tenga grupos y roles, si no tiene permiso sobre un proyecto determinado no podrá hacer nada.

3.2.3. Creación de Roles y Permisos

Ya tenemos los grupos de usuarios de nuestro proyecto y al menos un usuario para trabajar. Ahora lo importante es decir qué pueden hacer las personas o grupos de personas en nuestro proyecto y para ello tenemos que configurar los Roles. Accedemos desde Administration > Roles and permissions

Para simplificar os recomiendo que exista un rol asociado a cada uno de los grupos que habéis creado (para no empezar de cero, he modificado los tres roles por defecto que trae Redmine renombrandolos), de esta forma es más sencillo gestionar posteriormente la configuración:

Muchos pensaréis que esto es obvio, pero prefiero comentarlo para los menos acostumbrados. Si usamos grupos, asociamos los usuarios a estos, y los permisos los aplicamos sobre un grupo, de esta forma todos los miembros obtienen la misma configuración sin que tengamos que gestionar uno a uno. Pensad en grupos de 20-30 personas, sería una locura.

Cada uno de los roles tiene asociados unos permisos de Redmine. Podemos verlos en detalle pulsando en uno de los roles, en mi caso el de Product Owner. Podemos ver que hay tres bloques bien diferenciados que podemos configurar:

Cómo entrar en detalle de todas las configuraciones sería demasiado extenso, voy indicar únicamente aquellas que considero interesantes o aquellas que es necesario activar para un proyecto agile.

• Role:
  • Issues can be assigned to this role, este check indica si es un role al que se pueden asignar tareas o no. (ej, podemos tener una persona de la organización que pueda acceder al proyecto a ver cosas, pero no queremos que se le asignen tareas). En nuestro caso al Product Owner sí que va a poder asignarse  tareas
  • • Issues visibility, All non private issues, de esta forma podrá ver todos los issues del proyecto.
    • Time logs visibility, vamos
      • All time entries
    • Users visibility,
      • Members of visible projects

• Permissions: Dejamos la configuración que muestra las siguientes imágenes.

• Issue tracking: Antes de configurar este punto es necesario establecer los «trackers» del proyecto, es decir los tipos de issues que queremos utilizar. Pulsamos Save antes de hacer nada para no perder los cambios de configuración. Ahora vamos a Administration > Trackers. Por defecto habrá 3 tipos, Errores, Tareas y Soporte.

Aunque no sea específico de SCRUM voy a usar un esquema de Historias de usuario (podemos emplear esquemas para productos/proyectos mucho mas complejos como este o utiliza simplemente de tareas, pero quería diferenciarlo un poco de un proyecto estándar), por lo que tengo que modificar estos tipos. Voy a emplear los tipos:  Épica,  Historia, y Subtarea, y conceptualmente podemos considerarlos en tres niveles jerárquicos diferentes (de mayor a menor).

Hacemos clic en el tracker Errores y modificamos la configuración para que quede así (recordad pulsar Save al terminar):

Repetimos la operación para los otros dos tipos de tareas con las siguientes configuraciones.

Ahora que hemos terminado volvemos a Administration > Roles and permissions y seleccionamos de nuevo el usuario que estábamos editando (Producto Owner en mi caso). Nos desplazamos hasta la parte inferior donde está la sección issue tracking y marcamos los permisos sobre estos tipos de tareas de la siguiente manera:

En mi caso no quiero que las subtareas sean funcionales, y quiero que sean únicamente técnicas por lo que no le he otorgado permisos al Producto Owner para poder gestionarlas, aunque si para poder verlas y hacer comentarios sobre ellas por si el equipo de desarrollo los necesita.

3.2.4. Issues statuses

Los estados podemos decir que es la situación en la que se encuentra un trabajo a lo largo del tiempo hasta que se termina, vamos su ciclo de vida. Este ciclo es muy peculiar para cada equipo, y en  mi caso no voy a hacer grandes cambios al dee por defecto que trae los estados: Nueva, En curso, Resuelta, Comentarios, Cerrada y Rechazada. El único que voy a modificar es Comentarios, y lo voy a sustituir por Blocked (sí, a sabiendas que esto rompe el flujo del panel Kanban) porque quiero reflejar el caso de un equipo con un elevado grado de dependencias.

NOTA: Lo importante de esta configuración es el check issue closed, que establecerá cuando se han terminado las actividades relacionadas con esa tarea. Tanto al añadir nuevos estados con la función New status, como al editar haciendo clic un estado existen, recordad tras realizar cambios pulsar en Save.

3.2.5. Workflows

Esta sección no la vamos a modificar para no alargar en exceso el tutorial, en ella podemos ajustar dos aspectos interesante. Las transiciones entre estados que puede hacer un rol (podemos no dejar que el equipo de desarrollo de por finalizado el trabajo sin que lo vea el Product Owner, para ello no permitiríamos la transición de Resuelta a Cerrada para el Role de Development Team).

Y por otro lado también podemos controlar los permisos sobre los campos de una tarea, limitando el acceso a algunos de ellos.

Hay algunas secciones más de configuración como Campos personalizados y Enumeraciones, pero en mi caso me quedaré con la configuración estándar de estos.

Sí queréis profundizar en los aspectos de configuración os recomiendo leer la documentación oficial que está muy bien, la única «pega» es que está en inglés.

3.3 Configuración de un nuevo proyecto

Para crear un nuevo proyecto nos vamos a la opción Projects, a la izquierda en el menú superior.

En la parte superior derecha del área de trabajo veremos una funcionalidad New project, hacemos clic en ella.

Se cargará la pestaña de configuración Projects introduciremos los datos que nos pide como obligatorios y estableceremos las siguientes opciones:

• Desactivar Time tracking
• Desactivar Gantt
• Descativar Forums
• Activar Agile: Esto es fundamental, sino el proyecto será un proyecto tradicional de Redmine. Ya tendremos nuestro  proyecto creado.

Ahora vamos a personalizar nuestro proyecto, veremos que se carga un menú de segundo nivel con las siguientes opciones:

Members, desde donde podemos definir qué miembros y roles de Redmine podrán trabajar con nuestro proyecto. Pulsamos la opción New member y en la capa modal seleccionamos los grupos y roles de SCRUM que habíamos creado.

Issue tracking, Aquí establecemos que tipos de tareas queremos seguir. Por defecto aparece marcado Historias, pero activamos también el resto. No vamos a marcar ningún asignado por defecto a las tareas (cada miembro del equipo irá cogiendo), y tampoco establecemos una versión por defecto.

Versions, lo fundamental es saber que las versiones son las que nos van a permitir gestionar los sprints de SCRUM. Aquí ya dependerá del modo de trabajo del equipo, podemos tener una numeración de versión software «tradicional» o podemos tener un identificar de agrupación funcional, yo me he inclinado por este último y he creado los siguientes:

En este caso como Redmine gestiona Sprints no va a ser un versionado ajustado a una realidad, ya que es muy difícil que cada sprint podamos cumplir con tener un MVP, MMP, MMR… Si queréis conocer más detalles sobre agrupadores funcionales podéis consultar en este enlace que he mencionado anteriormente.

La configuración de ejemplo para la versión MPV o MVP podría ser:

No vamos a tocar la configuración de las secciones Issue categories y Repositories.

3.5 Trabajar con el proyecto

3.5.1 Crear issues

Lo primero que vamos a hacer es entrar en nuestro proyecto. Desde el menú de la cabecera accedemos a Projects > Proyecto SCRUM > Issues

Aquí vamos a crear una Épica, tres historias en las que subdivida y tres tareas para nuestra primera historia. Lo del 3 ha sido casualidad =)

Hacemos clic en New issue en la parte superior derecha de la zona de trabajo. a la hora de crear el issue tenemos que tener en cuenta el tipo, es decir el tracker. Vamos a crear la primera de tipo Épica como se muestra en la imagen siguiente.

Ahora vamos a crear una Historia que pertenezca a esta Épica. Repetimos el proceso anterior, pero al crearla, nos aseguramos que el campo Parent task lo rellenamos con la referencia a su Épica, podemos hacerlo con el numérico sí lo sabemos o usando el campo de búsqueda introduciendo el título de la épica.

Repetimos el proceso con alguna historia y podremos ver en el listado de issues cómo van apareciendo.

Si accedemos a la Épica, vemos como nos aparecen las historias asociadas como subtareas aun sin ser trackers de tipo subtarea.

Vamos a pasar al ultimo nivel, la creación de las subtareas, para ello abrimos la historia que hemos creado, en mi caso la Historia 2. Para añadir una subtarea, hacemos clic en la parte derecha del bloque Subtasks en la opción Add.

La opción Add nos abrirá una pantalla de creación de issue como las que hemos visto donde poder dar de alta la subtask. Podemos ver que ya tiene asociada la Parent task de forma automática.

OJO: Tenéis que prestar atención al campo Tracker, ya que mantiene la selección por defecto que hay en el proyecto, en mi caso Historia, si no lo ajustas no te va a crear Subtareas, sino Historias.

Según vayamos creando las subtareas, irán apareciendo en el bloque de Subtasks de la Historia.

Nuestra pantalla de issues debería tener un aspecto más o menos como este:

3.5.2 Crear el sprint

Ahora que ya tenemos nuestras primeras issues lo que tenemos que hacer es crear el Sprint para la iteración de trabajo. Recordad que habíamos dicho que esto se hacía a través de las versiones. Para ello vamos a Projects > Proyecto SCRUM > Settings > Versions.

Lo único que tenemos que hacer es dar la «fecha de finalización del sprint» a cada versión, indicando una fecha en el campo Due date. Yo he tomado las 3 versiones que había creado antes y he establecido fechas de finalización con un decalaje de 2 semanas tomando este tiempo como la duración del sprint.

3.5.3 Visualización del sprint en el panel

Ya tenemos issues y sprints, ahora lo que necesitamos es que hacer nuestro sprint planning es decir, qué trabajo se compromete el equipo para la iteración. Para ello asociamos la versión a las issues. Vamos a Projects > Proyecto SCRUM > Issues.

Editamos las historias que queremos que formen parte del sprint y les asociamos el Target version  que se corresponde con el sprint. Y aprovechamos también para dar los story points correspondientes.

Como siempre acordaros de finalizar la acción para que se guarden los cambios, en este caso con Submit. Yo he asociado dos historias a mi primer sprint, y tengo como tentativa una tercera para que entre en el siguiente.

Ya podemos ir a la sección Agile dentro del proyecto, donde podremos ver nuestro panel Kanban (a más de uno le va a «cortocircuitar» esto =) ) para el seguimiento de nuestra iteración de SCRUM.

Como podéis ver, todas las issues están en el lateral izquierdo, en la columna Nueva. Si recordáis esta era la configuración que habíamos mantenido en nuestro proyecto para las nuevas issues, por defecto entraban en el estado Nueva.

Ahora mismo en esta visualización tenemos varias cosas mezcladas, Épicas, Historias y Tareas. Si queremos, para simplificar un poco vamos a visualizar solo las Épicas y las Historias (aquí ya «feel free» para determinar que queréis ver vosotros).

Justo encima del panel, encontraréis la sección Filters, y a la derecha la opción Add filter. Aparecerá un desplegable desde el que seleccionar qué concepto queréis filtrar, seleccionamos Tracker.

Ahora configuramos ese filtro para que nos muestre todo lo que no sean subtareas.

Ya tenemos nuestro panel listo y podemos empezar a transitar las issues, voy a desactivar el filtro y comenzaré a mover tareas. Para moverlas solo es necesario arrastrar cada tarjeta a la columna correspondiente.

 

3.5.4 Visualización del Roadmap/Calendario

Adicionalmente al panel ágil, tenemos dos visualizaciones interesantes:

Roadmap, que es una visualización por hitos, donde vemos las versiones/sprints como hitos y el avance de las tareas asociadas.

Calendario, en la que se muestran las fechas de finalización de los sprints (versiones) y podemos navegar directamente para ver qué tareas integran un sprint concreto.

 

3.5.5 Burndown chart

Desde la sección Agile del proyecto seleccionamos en la parte superior derecha de la área de trabajo la opción Charts, donde es posible visualizar el Burndown chart del proyecto.

Tenemos que ajustarlo un poco si lo que queremos es ver el avance del sprint. Para ello en Filters, usamos el desplegable Add filter para seleccionar Target version y poder seleccionar así el sprint que queremos revisar. En mi caso he seleccionado el primero que había llamado MPV.

En Options, modificamos el valor Units para que presente Story points en lugar de issues.

3.6 Conclusiones y consideraciones

Con esto ya tenemos un juego básico de funcionalidad para nuestros proyectos SCRUM.

Redmine es una herramienta no muy potente a nivel visual, pero sí es relativamente intuitiva en su configuración, sin una cantidad de funciones desmesurada que generen una curva de aprendizaje muy grande. Como punto de entrada gratuito es una buena propuesta.

No lo he comentado hasta el momento, pero para una gran cantidad de los ajustes que hemos hecho es necesario contar con los permisos de administrador de Redmine. Si con el rol que tenéis en la actualidad no podéis hacer los ajustes tendréis que hablar con la persona que administre la herramienta.

Para mi gusto, la Versión PRO es casi obligatoria, por lo que si empezáis a ver que se os queda pequeña la funcionalidad, os recomiendo que probéis esta versión antes de plantearos cambiar a herramientas más complejas.

Hay más posibilidades de configuración y visualización, ya es cuestión de que «juguéis» con las opciones hasta adaptarla a vuestras necesidades. Espero que os haya parecido interesante y os ayude a tomar contacto con esta herramienta.