Diccionario ágil: ¿Qué quieren decir cuando hablan en “agile”?
Llegas a una reunión con desarrolladores, o incluso a un café informal con compañeros de trabajo, y de repente empiezan a decir cosas como P. O. (pronunciado “pí ou”), Sprint y demás palabras que no habías escuchado hasta el momento.
No es que nos hayamos vuelto locos: es que las metodologías ágiles han llegado a nuestras vidas. Sin embargo, antes de ello, hubiéramos agradecido tener un pequeño glosario que aunara todos esos términos.
Por eso, hemos decidido dejar este diccionario ágil en el que encontrarás las expresiones típicas de la gestión de proyectos ágiles y que te ayudará a ser el máster del univer… digo, todo un experto.
Glorasario Agile, de la A a la Z
A
Agile o Ágil: Agile es una metodología o, mejor dicho, una filosofía de trabajo bajo la que se aúnan diferentes metodologías o frameworks de gestión de proyectos como Scrum, Kanban, etc.
D
Daily Meeting o Reunión diaria: Este evento es una reunión en la que los miembros del equipo explican qué hicieron la jornada anterior y qué harán ese mismo día para cumplir con la meta del Sprint (Sprint Goal). Además, se expone si se encuentra algún impedimento por el que la meta del sprint no pueda ser alcanzada.
Definition of Done (DoD) o Definición de hecho: La definición de hecho es un conjunto de comportamientos, buenas prácticas y acuerdos mediante los cuales se verificará o demostrará que algo está terminado.
En pocas palabras, es una concepción compartida de qué significa que algo está terminado.
El Definition of Done busca, entre otras cosas, dotar al producto de consistencia técnica, le asegura una buena calidad y una buena adecuación para el cliente.
El DoD evoluciona con las necesidades del ciclo de vida del producto y es definido por todos los miembros del equipo, que lo conocen y lo aceptan para el buen desarrollo del proyecto.
P
Product Backlog o lista de objetivos: El Product Backlog es un listado de nuevas funcionalidades, bugs, tareas de infraestructura u otras actividades, estimadas por el equipo y priorizado según el criterio del Product Owner, teniendo en cuenta conceptos como el valor que le aporta al cliente, necesidades técnicas, oportunidades para el negocio, etc.
Esta lista la crea el Product Owner con el cliente y con la ayuda del equipo, y tiene en cuenta su utilidad, su valor y el retorno de la inversión.
Product Owner (P.O) o Propietario del producto: Este rol del equipo Scrum se encarga de que el trabajo del equipo tenga el máximo valor y el mayor retorno de inversión posible.
Trabaja dentro del equipo para maximizar el valor del trabajo del mismo.
S
Scrum Master o Facilitador: este rol del equipo Scrum sirve al equipo y a la organización con el fin de ayudar a un rendimiento óptimo a través de la autogestión, la inspección, la adaptación y la transparencia. En su misión está la ayuda en la aplicación de las metodologías ágiles, removiendo o ayudando a remover impedimentos. Además, toma el rol de facilitador en las reuniones para que estas sean eficaces y eficientes.
Por último, ayuda a los clientes y al resto de stackholders a integrarse en el equipo para alcanzar los objetivos en cada Sprint.
Sprint: un sprint es el periodo de tiempo en el que se trabaja para conseguir unos objetivos.
La duración de un sprint debe ser como máximo de cuatro semanas y al finalizarlo, se debe poder entregar una parte funcional del software.
Sprint Planning o planificación de la iteración: En esta reunión se planifican las tareas que se van a llevar a cabo. Se divide en dos partes:
En la primera parte, se analiza el qué: El product owner explica el objetivo del sprint y los elementos del Product Backlog que llevarán a conseguirlos.
El equipo de desarrollo estudia la lista, hace las preguntas pertinentes y decide cuantos de los elementos van a entrar en el Sprint, conociendo previamente que capacidad tienen.
En la segunda parte, se analiza el cómo: el equipo desarrollador diseña la táctica que llevará a cabo para conseguir los resultados.
Esto implica hacer una lista de tareas (el Sprint Backlog) y un plan para completarlas, según la definición de hecho (DoD). El equipo de desarrollo se auto-organizará tanto durante la planificación como durante el sprint para completar las tareas.
Sprint retrospective meeting o retrospectiva o retro: la retrospectiva es una reunión que se realiza a final de cada Sprint.
En ella, el equipo analizará cómo ha ido el último sprint en cuanto a personas, relaciones, procesos y herramientas, y qué impedimentos han encontrado.
Al finalizar la reunión, el equipo debe haber identificado que mejoras se implementarán durante el siguiente Sprint.
Sprint Review: Una Sprint Review es una reunión informal que se realiza al finalizar un Sprint. En ella, se analiza el incremento funcional, es decir, qué se ha conseguido con este Sprint. Tras ello, se adapta el Product Backlog si fuese necesario.
El cliente y el equipo colaboran en analizar lo que se hizo en el Sprint y se identifica las siguientes cosas que ayudarán a optimizar el valor del producto.
El resultado de la Review es un Product Backlog revisado y priorizado.
Stackholder o personas interesadas: el stackholder de un proyecto son aquellas personas que están interesadas de alguna manera con el proyecto y que no forman parte directamente del equipo de desarrollo. Estos pueden ser clientes, comerciales, accionistas, etc.
U
User story o historias de usuario: todo proyecto se divide en diferentes historias de usuario independientes las unas de las otras, y en las que se define una funcionalidad de la herramienta.
Como ves, cada una de estas palabras o expresiones tienen un significado muy ligado a lo que supone un desarrollo ágil.
Sin embargo, cada vez es más común oírlo en contextos alejados del desarrollo informático, pues cada vez más departamentos incluyen los beneficios de la filosofía ágil en su día a día.