En prácticamente todos los sitios en los que he estado he encontrado un denominador común en la gestión de tareas de desarrollo a través de los sistemas de gestión como Jira, Redmine o cualquier otro. Este denominador es una falta de detalle en la gestión de las tareas al margen del framework o metodología de trabajo que utilicen ya sea Scrum, Kanban, o una muy particular..
Me voy a referir a la gestión de tareas en términos generales, aunque en el framework como Scrum estas puedan ser una historia de usuario, una épica, una Tarea, una Incidencia o una tarea Técnica y en otros equipos puedan ser una nueva funcionalidad, mejora, un Error, etc.
En este post quiero comentar algunos de los motivos que he escuchado de porqué no se gestionan correctamente las tareas y os comparto algunas de las razones por las que creo que es importante hacerlo correctamente.
¿A qué me refiero con una falta de detalle en la gestión de tareas? He aquí algunos puntos que suelo ver en una tarea mal gestionada.
- Asignación incorrecta de tipología (historia, épica, tarea, incidencia)
- Estados incorrectos de estado.
- Falta o asignación incorrecta de propietarios.
- Asignación incorrecta de prioridad.
- Ausencia total de comentarios
- Ausencia de criterios de aceptación.
- Ausencia de imputación de tiempo.
Motivos por los que no se gestionan bien las tareas
Cuando he preguntado a los líderes de IT o a los desarrolladores, encuentro respuestas como las siguientes:
- No tengo tiempo.
- No hay procedimientos definidos.
- No es necesario.
- Es una pérdida de tiempo
- No sé cómo hacerlo mejor.
No hay tiempo
Es la excusa más generalizada. Estamos perdidos en el día a día y se considera que no hay hueco para documentar una tarea. Muchos desarrolladores se limitan a cerrar la tarea sin más, si es que llegan a hacerlo, sin añadir un comentario, información de pruebas, etc.
No hay procedimientos definidos
En muchos equipos no se ha creado una cultura de gestión de tareas y es normal que los miembros del equipo no lo hagan por iniciativa propia. A veces se cree que una herramienta lo soluciona todo y no es así. Una herramienta requiere además de su funcionalidad, unas reglas de uso para poder sacar el mejor partido de la misma.
No es necesario.
Muchos desarrolladores ven las gestión de tareas como algo sin sustancia, creen que solo tienen que hacer una acción, ejecutarla y cerrarla sin llegar. El título y la descripción ya lo dicen todo y si está cerrada es porque se ha hecho, ese suele ser su planteamiento.
Es una pérdida de tiempo
Algunas personas ven el proceso de gestionar las tareas tedioso y una pérdida de tiempo total. Lo ven como algo burocrático y que no merece la pena. Sienten que necesitan dedicar el tiempo a programar, más que a documentar una tarea.
No sé cómo hacerlo mejor
Esta es otra respuesta típica. Todos sabemos que es una tarea y posiblemente hasta sabemos como escribir una historia (El titulo) y su descripción, pero poco sabemos sobre los procesos de gestión de tareas de desarrollo de software y los posibles ciclos de vida.
¿Qué gano cuando una tarea está bien documentada?
Para mi la buena gestión de tareas de desarrollo está alineado con el grado de madurez del equipo y con los procesos de mejora continua. Algunos de mis pensamientos en esta línea son.
Las tareas bien documentadas son una fuente rica de información para el presente y para el futuro
Diego Acosta
Una tarea bien documentada es una herramienta de comunicación excelente entre los peticionarios y los ejecutores.
Diego Acosta
La buena gestión de una tarea nos ayuda a documentar la historia de un producto
Diego Acosta
A continuación listo parte de la información que nos podría brindar una tarea cuando la vemos en el sprint backlog cuando la documentamos bien.
- Conocer quién o quienes han ejecutado
- Conocer qué prioridad tiene o tenía cuando se ejecutó.
- Conocer el objeto o propósito de la tarea de forma clara
- Conocer el origen, la motivación o el contexto dentro del cual fue solicitada
- Saber qué decisiones se han tomado sobre la misma durante el proceso de desarrollo
- Conocer el alcance y cumplimiento
- Conocer cuales son los criterios de aceptación y sus variaciones si las hubiera.
- Saber si hubo algún problema y su resolución
- Saber si se hubo un cambio el alcance
- Saber si hay alguna tarea relacionada con mas información
- Conocer si forma parte de una tarea más grande
- Saber si está bloqueada y porqué está bloqueada.
- etc.
Una tarea bien documentada aporta conocimiento durante el desarrollo y a futuro. Es una inversión para cualquier desarrollo que tenga previsto un roadmap relevante o que forme parte de un producto.
En la gestión de incidencias y problemas es una fuente de información donde puedes encontrar que se ha hecho para solucionarlo, el análisis del problema y todos las posibles soluciones planteadas y cuáles de ellas funcionaron o no.
Por otro lado, tener un sistema de gestión de tareas bien organizado y trabajado es fuente de indicadores de gestión que pueden ayudar a la mejora continua mediante la medición de ciertos indicadores.
Por ejemplo
- Número de historias que aportan valor se han terminado
- Número de incidencias reportadas
- Tiempo efectivo de desarrollo
- Número de tareas bloqueadas.
- Tiempo medio de resolución
- etc.
Conclusión
Desde mi punto de vista, gestionar una tarea es una labor en la que todos los miembros del equipo deben estar involucrados, desde el Product Owner, Scrum Master y desarrolladores y debe verse como un proceso estandarizado dentro del equipo que debe incorporase mediante ciclos de mejora continua.
Si mejoráis la gestión de las tareas vais a notar un cambio en vuestro día a día y os ayudará a sacar un mejor producto.
