¿Qué tal JIRA como herramienta para apoyar la gestión de proyectos ágiles?

Propietario del Producto ante la pila de producto

Hemos ido probando distintas herramientas y hasta el momento ninguna cubre el ciclo completo incluyendo proyecto y fase de mantenimiento, desde la gestión de la construcción con Scrum, los planes de pruebas con sus criterios de aceptación y las incidencias. En esta ocasión hemos probado JIRA que promete tener todas las herramientas necesarias de forma integrada. Si visitamos la página JIRA Agile podemos leer:

"JIRA Software es una herramienta ágil de gestión de proyectos compatible con cualquier metodología ágil, ya sea Scrum, Kanban o la tuya propia. Desde tableros hasta informes ágiles, puedes planificar, supervisar y gestionar todos los proyectos de desarrollo de software ágil con una sola herramienta. Elige una metodología para ver cómo JIRA Software puede hacer que tu equipo publique software de calidad con mayor rapidez".

Y si vamos al apartado de Scrum:

"Scrum es una metodología ágil con la que se diseñan productos en una serie de iteraciones de longitud fija. Hay cuatro pilares que conforman la estructura de esta metodología: la planificación de sprints, los stand ups (también llamadas scrums diarios), los sprints y las retrospectivas. Saliéndose de lo común, JIRA Software viene con una completa serie de herramientas ágiles que harán que tu equipo de scrum lleve a cabo estos eventos con facilidad".

Entre las características del producto se puede leer:

• Gestión de release planning
• Gestión fácil de la pila de producto con drag&drop
• Gestion de la planificación de sprint
• Gestión del scrum diario
• Tablero de scrum con drag&drop
• Basa la medida del esfuerzo en puntos de historia

De entre los informes ágiles incluye:

• Diagrama de evolución
• Informe de sprint (burndown)
• Gráfico de velocidad
• Diagrama de flujo acumulado
• Informe de epic
• Gráfico de control
• Evolución de epics
• Evolución de publicaciones
• Informe de versión

Pantallazo con la lista de informes ágiles y un par de ejemplos

Lo que no me gusta:

• Se hace patente el origen de JIRA como gestor de tareas, las historias de usuario son task y las tareas sub-tasks. Pero esto es sólo una cuestión estética que sin duda Atlassian acabará mejorando.
• El tablero de scrum, aunque está muy bien resuelto, es poco colorido (tengo que admitir que no cargamos fotos o avatares de los miembros del equipo), y se corta con más de 4-6 historias de usuario y por tanto requiere de scroll. Esto reduce la visión agregada del mismo y reduce la visión del todo y del avance del sprint.

Tablero Scrum muy funcional pero poco llamativo para una gestión visual

Lo que me gusta:

• Historias de usuario no finalizadas en el sprint las lleva de vuelta, junto a sus tareas, a la pila de producto. Es exactamente como debe de ser, si no hay entrega no debe de contar. A más de un equipo novel le extrañará este comportamiento y se producirá la oportunidad para formarles y hacerles comprender el guiado por valor de negocio. Cuando se abra un nuevo sprint y se incluya la historia recuperará las tareas y los puntos hechos contarán para el nuevo sprint.
• Me encanta que JIRA trabaje por defecto con puntos de historia, para cambiar a horas ideales hay que ir a un rincón de la configuración que está algo escondido. :-)
• La gestión a nivel de release permite ver el estado completo, con trazabilidad a las incidencias, a los datos de desarrollo y a los impedimentos.
• Incluye un potente motor de workflow que permite ajustar el flujo de JIRA al del equipo/compañía, permitiendo crear estados y transiciones de flujo personalizadas para cada tipo de elemento: incidencias, historias de usuario, epics, tareas...
• Los tableros de scrum de JIRA son muy funcionales y muy intuitivos. Se pueden personalizar en vertical para encajar estados con el flujo de trabajo del equipo, y en horizontal para añadir carriles para separar epics, roles, productos/proyectos, etc.

A la izquierda: Los sprints se montan arrastrando historias desde la pila de producto
A la derecha: Arriba, la pila de producto y el detalle de una historia, abajo el detalle de una tarea

Para concluir mencionar que JIRA es una buena herramienta agile que cubre en gran medida las necesidades de desarrollo y que integra de forma avanzada las herramientas de desarrollo con una experiencia común para todo el equipo scrum e interesados del proyecto.

¿Qué parámetros analizar para determinar si un proyecto es factible?

¿Cuánto cuesta? del Agile Inception Deck de Jonathan Rasmusson

Nuestros clientes suelen estar interesados primordialmente en dos cosas:

• ¿Cuánto va a costar esto?
• ¿Para cuándo va a estar listo?

En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Cúanto cuesta?, en la que hacemos todo lo posible para responder a estas dos preguntas para que puedan decidir si el proyecto vale la pena y mostrarles lo que va a requerir.

Junto con los resultados de las actividades del pack de la incepción Estimar el tamaño y Mostrar la solución, esta actividad nos da la tu oportunidad de mostrar qué tipo de equipo va a ser necesario y en como lograr los objetivos del proyecto.

El equipo A del Agile Inception Deck de Jonathan Rasmusson

En la tabla del equipo A, como en la de la imagen de la izquierda, se muestra el equipo necesario sin el cual el proyecto no puede tener éxito. Con esta tabla se establecen las expectativas en torno al tamaño del equipo, los roles clave, el conjunto de habilidades requeridas y la combinación de habilidades funcionales cruzadas necesarias. Es importante incluir nombres de personas concretas cuando estas son requeridas por su expertise.

Con unos cálculos relativamente simples y a grandes números podemos encontrar el coste aproximado del proyecto y decidir sobre su factibilidad. Los costes derivaran principalmente de los salarios de los miembros del equipo durante el tiempo previsto del proyecto, más costes relativamente menores de recursos y servicios para la puesta en marcha. Un ejemplo de cálculo podría ser:

3 personas X 3,5 meses X 20 días/mes X 8 horas/día X $150/hora ≈ $250K

Si se tratara de un proyecto cerrado con un presupuesto establecido, podemos hacer ese tipo de cálculo para ver si el proyecto es factible dadas las condiciones preestablecidas.

¿Cómo identificar los riesgos principales en la fase de definición del proyecto?

Dinámica colaborativa con post-its para hacer
emerger los riesgos, en rojo el que más preocupa

¿Cuántas veces no nos hemos podido dormir dándole vueltas al estado de un proyecto? Y por buenas razones: pensamos en si nuestros clientes van a cambiar una y otra vez sus requisitos y prioridades, en si las estimaciones no han sido excesivamente optimistas, en que siempre parece que hay más cosas que hacer que lo que tiempo y presupuesto permiten... Y, ¡estos sólo son los riesgos conocidos del proyecto!

Hay mil cosas que pueden ir mal, algunas se pueden gestionar y otras no, algunas se deben de gestionar y otras no. Por ejemplo, no se puede hacer mucho ante el derrumbe de la economía, pero si gestionar dependencias con otros equipos e interesados.

En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Qué nos impide dormir?, una dinámica que nos invita a una discusión sana sobre algunos de los desafíos y riesgos con los que el equipo podría enfrentarse durante el proyecto, cuales simplemente asumir, cuales mitigar y cuales gestionar.

Riesgos que vale la pena gestionar son por ejemplo:

• Gestión del cambio clásica anclada al alcance inicial y no utilizar Scrum con un alcance variable guiado por valor de negocio
• Disponibilidad limitada del Propietario del Producto y usuarios clave
• Equipos con miembros sin dedicación plena al proyecto
• Entornos de desarrollo y test no dedicados o inestables
• Carencia de expertise técnico en la compañía
• Scrum Master influenciado por la inercia de un sistema no ágil
• ...

¿Qué nos impide dormir? del Agile Inception
Deck de Jonathan Rasmusson

Los objetivos de la dinámica son:

• Identificar los riesgos del proyecto
• Establecer cuales se gestionan
• Establecer qué riesgos se mitigan
• Team building & team commitment

Dinámica:

• Se rellena un tablero con los riesgos identificados por los participantes, cada participante en individual, para luego consolidarlos en un tablero
• Para cada riesgo se asignan impacto y probabilidad
• Se priorizan los riesgos y se establecen estrategias
• Finalmente el entregable será un tablero de riesgos como por ejemplo un tablero ROAM:
• RESOLVED: riesgos detectados pero que no eran tales
• OWNED: riesgos sobre los que alguien toma la responsabilidad de gestionarlos
• ACCEPTED: riesgos que simplemente se asumen
• MITIGATED: riesgos para los que se han decidido acciones mitigantes concretas

Se trata de una dinámica muy potente ya que nos da la oportunidad de pedir los recursos necesarios para tener éxito y poder exponer las consecuencias si no se proveen estos recursos.

¿Cómo transmitir la razón por la que se construye un producto?

¿Porqué estamos aquí? del Agile Inception
Deck de Jonathan Rasmusson

Uno de los cuentos de Jorge Bucay para hacer pensar nos narra:

"Éranse una vez dos picapedreros trabajando en una cantera, ambos trabajando mármoles con un pico de acero. Un desconocido se acercó a uno de ellos, uno que tenía mármoles rectangulares con la forma muy bien definida, y le preguntó qué estaba haciendo:

- Ya lo ves, estoy tallando un hermoso mármol
que me han encargado y así ganarme el sueldo.

Luego anduvo un poco más y vio a un segundo picapedrero, este tenía unos mármoles muy bien tallados y pulidos hasta tal punto que se reflejaba su rostro en la superficie, y le preguntó qué estaba haciendo::

- ¡Construyendo una catedral!
Yo formo parte de un equipo que construye una catedral

y yo tallo los mármoles para la pared del crucero."

Es fácil distinguir quién de los dos picapedreros trabajaba más a gusto, aparentemente hacen lo mismo pero no del mismo modo. No lo hacen con el mismo propósito y valores subyacentes, lo que varía es el "para qué" lo hacen.

Ejemplo de tablero resultado de la dinámica

Un equipo, especialmente un equipo de trabajadores de conocimiento en que la motivación y la creatividad son factores clave, no puede construir un gran producto si no sabe para qué lo está construyendo. Para ello quiero presentar la primera dinámica del pack de actividades de la Incepción Ágil llamada ¿Porqué estamos aquí?, dinámica que le dará al equipo el contexto necesario para la toma de decisiones acertadas durante la construcción.

No olvidemos que los equipos toman miles de decisiones durante la construcción de software, y para que estas sean acertadas han entender el objetivo del proyecto, entender el porqué, y estar informados a través de la visión del producto. Los objetivos de la dinámica son:

• Compartir y entender las motivaciones que han llevado a la compañía a emprender el proyecto
• Entender cual de todas las motivaciones es la principal
• Team building & team commitment

Ejemplo de tablero

La dinámica:

• El Propietario del Producto ayuda al sponsor a explicar el modelo de negocio a los asistentes a la reunión, utilizando como hilo conductor el porqué del proyecto
• Se obtiene un tablero con las razones para la realización del proyecto. Una buena técnica consiste en que los asistentes escriban razones en post-its en individual, los consoliden en un tablero y finalmente voten para obtener las razones principales.

Si fuera posible, lo ideal sería llevar al equipo completo a donde está el cliente, y hacer que el equipo entienda lo que realmente necesita este último. Pasar un día en el lugar de trabajo del cliente, y trabajar con las personas que después van a usar el sistema diariamente. Hacer que el equipo se comprometa, que haga preguntas y que se convierta en el cliente.

Mis agradecimientos a mi compañera del equipo OK's Gertru por sus aportaciones siempre de aporte de valor :-)

¿La calidad es negociable?

En Scrum la calidad es build-in, no es una variable - cortesía de Pixabay

Un proyecto no puede ser un éxito sin un alto nivel de "contento" por parte del cliente con el producto que le hayamos entregado. En un proyecto gestionado por metodologías tradicionales es factible negociar bajar la calidad con el objetivo de cumplir con los hitos y la fecha de entrega. Al cliente no le sirve lo perfecto, sino tener el producto a tiempo.

En Agilidad la calidad no puede ser una variable, los métodos ágiles priorizan los objetivos del proyecto en función del valor de negocio. A diferencia de las metodologías tradicionales siempre se trabaja con calidad, y para llegar a fechas se prescinde de funcionalidades que aporten poco valor de negocio, de aquellas que están al final de la pila de producto.

Recordemos el noveno principio del Manifiesto Ágil:

La atención continua a la excelencia técnica enaltece la Agilidad

Una técnica que nos garantiza la calidad es la comprobación continua, cuanto más nos ayudemos de este tipo de técnicas menos costoso será garantizar la calidad. Por ejemplo, es mucho más barato llevar las pruebas automatizables a un sistema de pruebas automatizadas y focalizar a los testers en las pruebas más complejas, que hacer que todas las pruebas las ejecuten personas. Con este ejemplo ganamos en dos aspectos, lo automatizable siempre resulta más barato y los testers aplicaran sus habilidades allí donde de verdad hay valor que lo haga una persona.

Otras técnicas para construir productos con calidad interna, necesarias para poder tener un ritmo sostenible de construcción iterativa e incremental, para evitar la deuda técnica y construir con escalabilidad y mantenibilidad nos las traen las prácticas de ingeniería de XP (eXtreme Programming):

• Estándares de codificación
• Pair programming
• Peer review
• Arquitecturas flexibles
• TDD (Test Driven Development)
• BDD (Behavior Driven Development)
• ATDD (Acceptance Test Driven Development)
• Refactorización
• Pruebas automatizadas
• Integración continua

Pero lo que realmente hace que construyamos productos excelentes y con gran calidad, es el marco de Scrum en si. Sus ciclos, los sprints, hacen que entre sprint y sprint tengamos inspección y adaptación, lo que quiere decir que tenemos puntos de feedback, puntos de aprendizaje y puntos mejora en cada sprint. La calidad es un resultado natural del marco, no hay que hacer una gestión específica, sólo aplicar correctamente el marco.

Me gusta dar como ejemplo el móvil actual y las prestaciones que da, este es el resultado de un centenar de iteraciones y, si lo pensamos bien el, móvil es un producto más que excelente, es increíble y alucinante. Con el software y Scrum pasa los mismo, a base de iteraciones bien guiadas por negocio llegamos al mejor producto posible en tiempos y costes establecidos.

¿Qué tipos de coaches ágiles existen?

Con el asentamiento de la Agilidad en las compañías se han creado nuevos perfiles profesionales, si miramos ofertas de trabajo nos encontramos con nuevos perfiles de coaches ágiles que a veces resultan confusos.

Lyssa Adkins, del Agile Coaching Institute, nos habla de tres niveles de coaches ágiles:

• Facilitador de equipos ágiles: facilitada prácticas de colaboración en un equipo a la vez. En este grupo se encuentra el Scrum Master.
• Coach ágil: hace coaching a más de un equipo, mentoriza y desarrolla coaches y aconseja a gerentes y directivos.
• Enterprise Agile Coach: Hace coaching a la compañía en su conjunto para el correcto uso de la Agilidad. Desarrolla a líderes, pone el foco en la cultura y cataliza el cambio.

¿No son excesivos los costes de tener a todo el equipo presente en las reuniones de Scrum?

Equipo completo reunido ante un tablero

Observo una y otra vez un error muy común que consiste en poner únicamente el foco en los costes de algo, obviando lo que nos dice la Agilidad, hay que mirar también cuales son los costes por no hacerlo.

Si calculamos los costes de tener a todos los miembros del equipo de Scrum en las diferentes reuniones, podemos llegar a priori a la conclusión que dedicar a todas esas personas dos días de cada diez, en caso de sprints de dos semanas, puramente a reuniones, puede resultar un coste innecesario. Pero recordemos el lema que dice:

"Piensa dos veces
y codifica bien a la primera"

A veces he oído a algún cliente o gerente de consultora sentenciar: "¡Es mejor que dediquen ese tiempo a codificar, que para eso se les paga!". Suelo contestar que con esas reuniones nos aseguramos de que los equipos construyan a la primera lo correcto, con esas reuniones comprenden lo que han de construir. Y les pregunto: ¿Cuál sería el coste si los desarrolladores no construyen lo correcto a la primera? y, si son conscientes de que tal como muestran las estadísticas del Standish Group, que estudian miles de proyectos de todo el mundo al año, desde mantenimientos pequeños hasta gigantescos proyectos de reingeniería, ¡alrededor de un 80% de lineas de código nunca llegan a producción por malentendidos, retrabajo, etc!

Ya no suelo entrar en que además con Scrum construimos guiados por valor de negocio, lo que nos asegura que mediante estas reuniones el equipo está trabajando en todo momento en lo que más valor aporta. Recordemos que negocio sabe lo que quiere, no lo que necesita, eso madura durante el camino y se materializa en cambios necesarios y deseables.

Pero entremos más a fondo, ¿qué puede ocurrir si no hacemos esas reuniones?

• Escasa colaboración entre negocio y equipo de desarrollo.
• Comunicación pobre de las necesidades de negocio.
• No se identifican los malentendidos, con lo que estos emergen en etapas tardías del proyecto y sus consecuencias pueden generar incidencias y deuda técnica.
• Desarrollo por capas horizontales, diseñamos pensando en el todo, lo que nos lleva a batches largos de trabajo perdiendo así la entrega frecuente de valor de los ciclos cortos.
• Fases largas de testing y de resolución de incidencias, con lo que alargamos los batches ya de por sí largos.
• Resistencia al cambio, con lo que los ciclos de absorción de cambios también son largos y dolorosos.
• Miembros de equipo focalizados en sus tareas, lo que implica poca colaboración y poca creatividad.
• Finalmente una baja motivación, las reuniones de Scrum hacen que todos sientan que participan del proyecto y que aportan. Recordemos que el propósito es una de las motivaciones intrínsecas más fuertes.

Curvas que son ejemplo de como se pueden comportar ambos costes
estas pueden variar en función del proyecto y la madurez ágil del equipo

Visto todo esto, vemos que sin reuniones trabajamos con batches largos (usualmente hasta final de proyecto o el siguiente hito), lo que produce grandes colas en el flujo de construcción, lo que a su vez produce tiempos de entrega largos, y desde la perspectiva de negocio un time-to-market bajo que puede minimizar seriamente la competitividad de la compañía.

A parte de los costes directos del tiempo dedicado a las reuniones, lo vemos en el gráfico de la derecha en la curva de color rojo oscuro, hemos de tener en cuenta el coste de la demora, en verde, que representa el coste que supone la espera en la entrega de una funcionalidad de valor. Si acometemos un proyecto abarcando el todo desde el principio, y no hacemos reuniones periódicas, perdemos oportunidades de mercado ya que no hay entrega hasta el final, perdemos los ciclos de aprendizaje que nos permiten mejorar el producto y la forma de trabajar así como también perdemos la absorción de los cambios, cambios que siempre implican un aumento del valor de negocio. En la parte de la derecha el coste de la demora vuelve a subir porque en ese caso hipotético los equipos dedicarían su tiempo a reunirse y sus entregas serían muy escasas.

La curva naranja nos muestra el coste total, podemos ver claramente que el coste menor se produce con un nivel de tiempo dedicado a reuniones de entre el 15% y el 25%, tiempo que es coherente con los eventos de Scrum.

Un alumno de uno de mis cursos de Scrum me habló convencido de la imposibilidad de hacer pair programming en su compañía, por los costes elevados que supone. De nuevo hay que preguntarse por los costes de no hacerlo.

Poner a dos personas en un solo ordenador es más costoso que poner a una sola, es de lógica, pero de lógica financiera. Si pensamos en productividad veremos que una persona ante un ordenador tiene 1 de productividad, y cuando hacemos pair programming bien hecho, integramos equipo, unificamos formas de trabajar, creamos base de conocimiento, se producen buenas ideas por colisión de ideas individuales... y todo eso hace que la productividad suela situarse entre el 4 y 6. Desde este punto de vista, el punto de vista de productividad y la lógica de los equipos técnicos, ¿pair programming tiene más costes? ¿o más bien es menos costoso?

¿Es más costoso hacer las reuniones de Scrum? o ¿es más costoso no hacerlas? - cortesía de Pixabay