Scrum y la metodología de desarrollo Agile ofrecen marcos de gestión de proyectos que enfatizan el trabajo en equipo, la responsabilidad de sus miembros y el avance iterativo hacia una meta bien definida. Los tres pilares de Scrum son la transparencia, la inspección y la adaptación.
Recomendamos el uso de Scrum si:
Los requisitos del proyecto cambian y evolucionan
Hacen falta comentarios continuos
No es necesario ajustarse a una fecha de lanzamiento fija
El equipo del proyecto quiere autonomía
Scrum es muy útil para los proyectos que tienen muchas variantes desconocidas o que cambian mucho a lo largo del tiempo. Este método permite tratar los cambios de forma muy eficaz, para acomodar fácilmente nuevas informaciones o características durante el proceso.
Un equipo de Scrum debe tener tres papeles específicos y uno opcional:
Un titular del producto
Un Scrum master
Un equipo de desarrollo
Un cliente (opcional)
Estos tres papeles están en pie de igualdad y todos tienen ciertas responsabilidades.
Papeles y responsabilidades | ||
|---|---|---|
Titular del producto | Representa al cliente y el negocio
| |
Scrum master | Se asegura de que el equipo tiene todo lo que necesita para crear valor. Actúa como líder-servidor del equipo de desarrollo
| |
Equipo de desarrollo | Se centra en la entrega de un software funcional El equipo de desarrollo es interdisciplinario, autogestionado, autoorganizado y dedicado. Esta autonomía es la particularidad de Scrum. Se encuentra en el núcleo del proceso. Lo que surge de este enfoque son lazos fuertes entre el equipo y un entorno de trabajo positivo que permite que la gente se sienta empoderada por su trabajo.
| |
Cliente Opcional, ya que el cliente puede ser el titular del producto | Cuando un proyecto se desarrolla de forma interna, el cliente suele ser el titular del producto. Cuando un proyecto se desarrolla de forma externa, el cliente suele ser responsable de:
|
 |
En la metodología Ágil, los proyectos siguen el ritmo de sus iteraciones. El Scrum master y el titular del producto proponen un contenido para cada una de ellas (es decir, el backlog de la iteración) y definen la lista de elementos del backlog teniendo en cuenta criterios como el valor de negocio, las épicas o la velocidad pasada (es decir, la capacidad de cumplir puntos de historia). Este proceso recibe el nombre de reunión de planificación de la iteración.
A continuación, se habla de esta propuesta con los miembros del equipo. Se revisa la estimación de puntos de historia para que el equipo pueda comprometerse a entregar el backlog de la iteración. Existen varias maneras de llevar a cabo esta reunión, como la técnica del «Planning Poker» (póquer de planificación).
Durante una iteración, el equipo tiene una corta reunión (de Scrum) diaria para hablar sobre el avance y, sobre todo, tratar los problemas y las dificultades técnicas a las que se enfrenta.
Al final de la iteración, todos los elementos completados deben estar listos para su envío (dentro del lanzamiento). También se puede organizar una reunión a posteriori (post mórtem) para hablar sobre los problemas encontrados durante la iteración, revisar la velocidad y hacer mejoras para la siguiente iteración.
El backlog del producto enumera todas las características, funciones, mejoras y correcciones que hay que introducir en el producto en los siguientes lanzamientos. El backlog del producto sustituye los requisitos de especificaciones funcionales de la metodología de Cascada.
El backlog del producto tiene las siguientes características:
Cada entrada debe ofrecer valor al cliente.
Pueden darse cambios durante todo el proyecto.
No conviene describir las tareas de bajo nivel.
Se priorizan todas las entradas para ordenar el backlog del producto.
Se estiman todas las entradas, generalmente con puntos de historia.
El titular del producto debe mantener el backlog del producto de forma constante.
El backlog del producto está compuesto por elementos del backlog.
Un elemento del backlog es una unidad de trabajo bastante pequeña para que un equipo la complete en una iteración. Los elementos del backlog están formados por una o más tareas.
Los elementos del backlog que se introducen en el backlog del producto pueden centrarse en un usuario. En este caso, aparecen en forma de historia de usuario.
Las historias de usuario definen un requisito de forma general. Ofrecen bastante información para que el desarrollador pueda estimar razonablemente el esfuerzo necesario para ponerlo en marcha. Las historias de usuario describen parte de una característica desde el punto de vista de un usuario en unas pocas frases. Reflejan las necesidades de un determinado tipo de usuario y el valor que pueden ofrecer al cliente. Su formato es simple y son fáciles de usar.
«Como <determinada clase de usuario> quiero <poder hacer algo> para <obtener cierto valor o beneficio>»
 |
Sin embargo, escribir historias de usuario no es obligatorio. Los elementos del backlog pueden introducirse con un par de palabras clave o frases cortas, siempre que el equipo del proyecto y los interesados puedan entenderlos.
 |
El titular del producto, el Scrum master o todo el equipo del proyecto deben asistir a la reunión de planificación de la iteración. Si el equipo lo considera necesario, puede invitar a interesados externos, pero la mayoría de las empresas no lo hacen.
Durante la reunión de planificación de la iteración, el titular del producto describe las características con mayor prioridad para el equipo en función de la meta de la iteración. Luego se definen los elementos del backlog en los que se va a trabajar durante la iteración tras solicitarlos y estimarlos.
Una iteración es un ciclo de desarrollo continuo enmarcado en el tiempo. Dentro de una iteración, el equipo debe completar y preparar para revisión cierta cantidad de trabajo. Este término se usa principalmente en la metodología Scrum. El término genérico del enfoque de Agile es iteración (lo que utiliza Sciforma).
La duración media de una iteración suele ser entre 2 y 4 semanas.
Cuando se usa la metodología de Scrum, las estimaciones de trabajo no se hacen en horas sino en puntos de historia.
Los puntos de historia son una unidad de medida que permite expresar la estimación del esfuerzo global necesario para implementar un elemento del backlog o cualquier otra actividad en su totalidad. Cuando se hace una estimación con puntos de historia, cada elemento del backlog recibe un valor de puntos.
Para ayudar a estimar los puntos de historia se suelen usar escalas como la siguiente:
Los números de la secuencia de Fibonacci (0,5, 1, 2, 3, 5, 8, 13, 21…)
Una sucesión lineal de números (1, 2, 3, 4, 5, 6, 7, 8…); lo que usa Sciforma
Como este ejercicio se puede hacer de manera colaborativa, algunas empresas usan técnicas como el Póquer de planificación («Planning Poker»).
El titular del producto presenta los elementos del backlog que hay que estimar. Los miembros del equipo hacen preguntas y el titular del producto les da más detalles.
Cada miembro del equipo recibe una baraja y elige en privado la carta que representa su estimación.
Cuando todos los miembros del equipo han realizado su estimación, revelan sus cartas al mismo tiempo. Si todas las estimaciones coinciden, se elige un nuevo elemento del backlog y se repite el proceso. Cuando las estimaciones son distintas, los miembros del equipo debaten hasta que llegan a un acuerdo.
Una vez que se hayan estimado los elementos del backlog, los puntos de historia tienen que comprarse con la velocidad del equipo.
La velocidad del equipo se basa en los puntos de historia completados realmente; suele calcularse haciendo la media de los puntos de historia completados en todas las iteraciones previas. La velocidad del equipo permite programar cuántos elementos del backlog puede planear y completar el equipo durante la siguiente iteración.
Sin embargo, para saber los elementos del backlog que se pueden gestionar en la siguiente iteración, hay que tener en cuenta la capacidad del equipo del proyecto. La capacidad es la disponibilidad que tiene el equipo para la iteración. Así, puede variar si los miembros del equipo están de vacaciones, enfermos, etc.
El backlog de la iteración es un subconjunto del backlog del producto. El backlog de la iteración viene del backlog del producto y contiene los elementos del backlog que se pueden completar durante la iteración.
A diferencia del backlog del producto, el backlog de la iteración no cambia durante el periodo de la iteración. De hecho, al final de su etapa de planificación, los elementos del backlog y los pasos para completarlos se congelan mientras dura la iteración. Si al final de la iteración quedan elementos del backlog sin completar, se vuelven a añadir al backlog del producto y se gestionan en la siguiente iteración.
A alto nivel, un proyecto puede empezar como épicas, apartados o características que se dividen en elementos del backlog.
En caso de necesidad, las tareas permiten desglosar aún más los elementos del backlog. Son la unidad más pequeña para seguir el trabajo. Cada tarea debe ser completada por un miembro del equipo. Generalmente, cada elemento del backlog tiene varias tareas asociadas. Como los equipos están formados por expertos en varias materias que cumplen varias funciones, tener varias tareas en un elemento del backlog permite que los miembros del equipo trabajen en paralelo en las áreas que dominan.
En consecuencia, desglosar los elementos del backlog en tareas ayuda al equipo a determinar cómo hacer frente al trabajo. Al utilizar este nivel de detalle, se descubre cualquier posible imprevisto.
El objetivo de las reuniones diarias de Scrum (también conocidas como «Daily Stand-up Meetings») es informar rápidamente a todo el equipo de lo que sucede. Las reuniones deben durar menos de 15 minutos y están animadas por el Scrum master, que hace tres (3) preguntas a cada miembro del equipo.
¿Qué hicisteis ayer?
El Scrum master sabe las tareas que se han «completado» y si las tareas en curso avanzan de la manera esperada. Si las estimaciones se expanden o se descubren nuevas tareas, habrá que cambiar el diagrama de avance.
¿Qué vais a hacer hoy?
Esta pregunta sustituye a los diagramas de GANTT. Las dependencias cambian de forma constante. Contestar a esta pregunta permite revisar la estrategia del proyecto de forma diaria, reorientando el equipo en función de los cambios de dependencia que surgen de la pregunta anterior.
¿Hay algo que os bloquea u os impide hacer vuestro trabajo?
Esta pregunta permite crear una lista de impedimentos que se asignan al equipo o se transfieren al nivel superior. Una de las principales responsabilidades del Scrum master es gestionar, priorizar y asegurarse de que el backlog de impedimentos va desapareciendo.
El panel de tareas es una representación visual del avance del equipo de proyecto durante una iteración. Presenta una instantánea del backlog de la iteración actual y permite que todos vean qué tareas y elementos del backlog quedan por comenzar, cómo avanzan los que están en curso y cuáles se han completado.
El panel de tareas se actualiza cada día durante la reunión diaria de Scrum.
 |
Un diagrama de avance es una representación gráfica del trabajo que queda por hacer en relación con el tiempo.
 |
El eje X del diagrama siempre indica el tiempo (normalmente en días).
El eje Y representa el trabajo restante por completar en la iteración. Puede estar representado por las tareas restantes (en número de tareas) o por el esfuerzo restante (en puntos de historia/horas).
La línea de avance indica cómo progresa el equipo durante la iteración. Se actualiza cada día con las nuevas estimaciones restantes. A medida que la iteración avanza, la línea indica si el equipo se mantiene al día o si hace falta tomar medidas correctivas.
La línea de referencia es una línea diagonal que desciende desde la izquierda a la derecha del diagrama. La línea de avance de la iteración debería acercarse lo máximo posible a la referencia. Si el equipo puede completar todas las historias con regularidad a lo largo de la iteración, la línea de avance tendrá el mismo aspecto que la línea de referencia.
Si la línea de avance de la iteración está por encima de la línea de referencia, el equipo del proyecto lleva retraso y ya debería haber completado más trabajo.
Si la línea de avance de la iteración y la línea de referencia se superponen, el equipo del proyecto conseguirá completar todo el trabajo si mantiene su velocidad.
Si la línea de avance de la iteración está por debajo de la línea de referencia, el equipo del proyecto lleva adelanto y debería completar todo el trabajo antes de la fecha de fin de la iteración. En este caso, el equipo del proyecto puede añadir nuevos elementos del backlog a la iteración para mantenerse ocupado hasta la fecha de fin de la iteración.
Al final de la iteración, el titular del producto invita al equipo del proyecto y los principales interesados a la reunión de revisión de la iteración. Durante esta reunión, se hace una demostración para inspeccionar el resultado y que todos puedan compartir sus comentarios sobre el trabajo realizado.
El objetivo de la revisión de la iteración no es realizar una actualización de estado o una presentación para los interesados. Es reunir y procesar los comentarios del incremento real.
La agenda típica de una reunión de revisión de la iteración puede ser como sigue:
El titular del producto explica los elementos del backlog que se han «completado» y los que no.
El equipo del proyecto cuenta lo que fue bien durante la iteración, los problemas que encontraron y cómo los resolvieron.
El equipo del proyecto demuestra el trabajo que ha sido «completado» y responde a las preguntas sobre el incremento.
El titular del producto comenta la situación del backlog del producto y, si es necesario, proyecta objetivos y fechas de entrega en función del avance en ese momento.
Todo el grupo colabora en lo que viene a continuación, así que la revisión de la iteración ofrece una contribución valiosa a los siguientes backlogs de la iteración.
El análisis retrospectivo de la iteración se produce después de la revisión de la iteración y antes de la planificación de la siguiente iteración. En esta reunión se habla de la iteración que se acaba de entregar, así que están presentes el equipo del proyecto, el Scrum master y el titular del producto.
El objetivo de la retrospectiva es que los miembros del equipo hablen entre ellos de cómo fueron las cosas durante la última iteración para mejorar la forma de alcanzar los objetivos del proyecto y aumentar la productividad. Todos los miembros del equipo comentan los fallos y las mejoras venideras y hacen el seguimiento de las lecciones aprendidas.
El análisis retrospectivo de la iteración puede compararse a la reunión «post mórtem» (a posteriori) de la metodología de Cascada. Sin embargo, como tiene lugar al final de cada iteración y no al final del proyecto, se pueden hacer ajustes del proceso de forma más frecuente y se pueden implementar pequeñas mejoras de forma habitual.
Una organización ágil puede responder rápidamente a los cambios del entorno del mercado. Una organización muy ágil reaccionará correctamente a la llegada de nuevos competidores, los avances tecnológicos rápidos y los cambios inesperados de las condiciones generales del mercado.
¿Qué no es un equipo ágil?
Un equipo ágil no es solamente un equipo de proyecto formado por distintas personas con distintas especialidades empresariales, como un grupo de trabajo (o equipo de trabajo).
Un equipo ágil no está formado únicamente por recursos desarrolladores. Tampoco es un equipo de matriz.
¿Qué es un equipo ágil?
Un equipo ágil es un grupo multifuncional de gente independiente, hasta tal punto que el grupo puede entregar el producto (o la siguiente iteración) sin necesidad de involucrar personas o habilidades externas.
 |
Un equipo ágil es un grupo entregado de gente que no pasa de un producto a otro solo porque otro trabajo se considera más prioritario.
Un equipo ágil se autoorganiza. En consecuencia, tiene la responsabilidad y la autoridad para crear una estructura interna funcional sustituyendo, reentrenando o reorganizando los miembros del equipo como sea necesario.
Un equipo ágil se autogestiona. Los miembros del equipo son responsables por la planificación, la ejecución, el control y la gestión de sus actividades sin supervisión o con una cantidad reducida.
Hay que recordar que Agile es un enfoque y un estado de espíritu adaptativo. Cada empresa debe adaptar su organización para que sus proyectos funcionen.
El modelo de datos de Sciforma se ha diseñado para adaptarse a las necesidades y los requisitos de nuestros clientes.
 |
Las historias, los defectos, las tareas y los asuntos se gestionan como elementos del backlog.
Esto facilita el avance del proyecto, sobre todo cuando se usa el panel de tareas, ya que todos los elementos del backlog se gestionan al mismo nivel.
Además, los elementos del backlog pueden tener adjunta una lista de control. Esos elementos pueden convertirse en tareas. En ese caso, se creará una conexión entre el elemento del backlog y la tarea recién creada.