Angel Lozano

En primer lugar, el contexto y las preguntas:

Actualmente lidero un grupo de personas expertas en el ecosistema Agile, somos Eva Fonseca, Juanjo Vallina y yo mismo. Trabajamos para la consultora Gfi y además somos miembros de la Comunidad 233, una comunidad formada por expertos en Agilidad.

El cliente para el que trabajamos nos ha pedido opinión sobre cómo resolver unas dudas, están empezando a usar Scrum para gestionar varios proyectos de desarrollo de software.

En este caso se trata de ver cómo plantear las Tareas técnicas que van en el Product Backlog. El cliente nos pide algo de categorización y que no que sean del todo libres, no quiere que sea muy cerrado pero tampoco totalmente libre. Dependiendo del tipo de tarea técnica, pueden ser resueltas por equipos independientes o por el propio equipo Scrum. Son tareas que no están asociadas directamente a una historia de usuario concreta sino a todo el conjunto.

Decidimos montar una encuesta que añadiera a nuestras propias experiencias, las de un grupo de personas expertas que están utilizado Scrum en diferentes ambientes. Los encuestados han sido:

• Pau Mugarra, José Enrique Mateo, Sonia Montagud, Javier Garzás, Jesús H. Corrochano, Jesús Escribano, Rubén de Heras, Eva Fonseca, Juanjo Vallina, Julio César Pérez Arqués, Arturo Bermudez, Miguel J. Ruiz Santaella.

Las preguntas que les hemos hecho:

• ¿Contemplas Tareas Técnicas?, ¿dentro del Product Backlog o en otra lista? ¿las pasas al Sprint Backlog? ¿las gestiona el Product Owner? ¿las categorizas o las distingues de alguna manera si tienes diferentes actores involucrados?

Ahora, las respuestas:

Algunas de las respuestas que hemos tenido son estas:

• Todas las tareas que afectan a un proyecto se deben incluir como sub-tareas de las historias, no puede haber nada que no esté colgando de una historia. Si hubiera áreas externas se podrían llevar fuera del Product Backlog y sin categorizarlas. Las define el Development Team y las gestiona el Scrum Master
• Existen pero no se categorizan las Tareas Técnicas. Se ponen títulos que sean descriptivos. Se llevan dentro del Product Backlog pero diferenciándolas de las Historias de Usuario. Las define el DT (que al ser proyectos de arquitectura, son los expertos técnicos). Las gestiona el Scrum Master. El Producto Owner acepta que se incluyan en el PB.
• Sí se usan Tareas Técnicas, se introducen en el PB con 0 puntos historia. No se categorizan pero sí se describen bien. Se referencian a los equipos externos que las realizarán. No entran nunca en el sprint backlog, ya que aquí sólo entra lo que el equipo puede realizar por sí mismo.
• Tareas Técnicas categorizadas mediante componentes en Jira. Se llevan dentro del Product Backlog del equipo de producto que identifica la necesidad, además de existir un equipo cross para algunas disciplinas con tablero propio al que trabajan en innovación tecnológica para toda la línea de productos. Las definen los expertos en las disciplinas. Las gestiona el Product Owner Cross o del equipo de producto correspondiente, incluyéndolas en el PB. Se utilizan sub-tareas Jira para dividir las historias en tareas simples sin ningún tipo de categoría, buscando que el título sea lo más descriptivo posible, consiguiendo con la dinámica que los nombres queden como nomenclatura.
• El catálogo que se maneja es el siguiente: Épica (que se llama feature), Historia de usuario, historia técnica, Errores y Organizacional (workshops, documentos de formación, aquello relacionado con una necesidad del equipo de desarrollo, etc). Todas están en el backlog y en todas tienen definido un DoD y unos criterios de aceptación. en los sprint planning se dividen estos elementos en sub-tareas. Las sub-tareas no están categorizadas nunca en ningún tipo, simplemente son sub-tareas. Al final hay historias técnicas que si el PO no incluye, son bloqueantes para seguir con otras historias de usuario.

Por último, las conclusiones:

La primera conclusión, la más inmediata, es que Scrum no es una metodologia, es realmente un framework, cada organización, cada equipo, lo utiliza según su necesidad, lo adapta a cómo mejor entiende que puede gestionar sus trabajos.

Otra conclusión, si queremos llegar a la agilidad en estado puro, debemos tender a que todas las tareas que afectan a un proyecto se deben incluir como sub-tareas de las historias, no puede haber nada que no esté colgando de una historia. Todo el trabajo que se tiene que hacer en un proyecto lo hace el equipo y lo tiene registrado en su sprint Backlog.

Otra más, en una compañía que quiere evolucionar hacía la agilidad pero que mantiene unas estructuras no adaptadas, hay que buscar soluciones intermedias antes de llegar al modelo perfecto.

La última, Javier Garzás escribió un artículo muy clarificador “En video y dibujando… Gestión de Proyectos vs Equipos”, en el que nos muestra cómo deberíamos pasar desde un enfoque de proyecto a un enfoque de equipo. Creo que ese es el futuro de la agilidad, olvidarnos del proyecto y tender a que sea un trabajo continuo de los equipos.

Estas conclusiones las podemos considerar como técnicas, pero las hay de otro tipo, las del propio desarrollo de la encuesta, las de pertenecer a una comunidad y compartir intereses y compromiso. Ante la necesidad de una parte de los miembros, el resto se pone a su disposición aportando sus experiencias y conocimientos, de forma desinteresada.

Un buen trabajo de compartir ideas, no va a ser el último.

Nota final: Muchas enhorabuenas a Miguel J. Ruiz por montar el grupo Agile Granada y a Arturo Bermudez por montar el grupo Agile Cádiz. Andalucia cada día es más «Ágil».