A partir del vídeo de UniPymes he redactado este pequeño tutorial para aprender en que consiste esta metodología ágil.
En la metodología tradicional de planificación de proyectos, o de cascada, primero se hacen los requerimientos, luego se realiza el diseño, posteriormente se realiza la codificación y finalmente se integra, a partir de ese momento decimos que se ha cumplido el deadline y el producto está acabado. Posteriormente se establece una gestión de mantenimiento.
El problema de estas metodologías es que hay mucha incertidumbre ya que suelen ser proyectos a uno, dos o tres años, por tanto lo que suele suceder es que se tiene que mover el deadline y probablemente el coste (personas dedicadas o recursos) suele variar para que se cumplan el 100% de los requerimientos especificados.
La alternativa se plantea en la metodología ágil, aquí los requerimientos no son fijos (como sucede en la metodología en cascada) pero los recursos (personas) y la fecha de entrega son inamovibles.
Esto ocurre porque en una metodología ágil no hace falta esperar años a entregar el producto, sino que se realizan entregas parciales. Importante que cada entrega sean productos funcionales para que el cliente lo pueda probar y nos pueda dar feedback. Tras ese feedback nosotros podemos abordar un cambio para la siguiente entrega.
Scrum es una metodología de desarrollo Ágil incremental (cada iteración el proyecto se incrementa la cantidad de requerimientos) y es iterativa (existen muchos ciclos de trabajo y entregas, cada vez que vamos realizando las entregas el cliente indica si está de acuerdo o no)
Se usan normalmente equipos de entre 3 y 10 personas.
Los roles son el Stakeholder (los patrocinadores del producto) que son los que ponen el dinero, el Product Owner (que es quien representa a los patrocinadores y el que define que es lo que se requiere del producto). Estos dos roles no forman parte del producto.
El Equipo lo conforman un equipo de ingenieros con una persona que se encarga del control de calidad. Todos estos son liderados por el Scrum Master que se encarga que la metodología se lleve a cabo y se encarga también de gestionar los impedimentos que el equipo pueda tener.
La dinámica de trabajo empieza con el Product Backlog (requerimientos del product Owner del proyecto a uno o dos años). Posteriormente le pedimos al product Owner que priorice todos esos requerimientos de mayor a menor importancia. Con toda esa documentación lo que hacemos es convertirlo en tareas y el equipo le dará más prioridad en las primeras iteraciones a las tareas más importantes.
En base a esa prioridad de tareas cogemos una serie de tareas (sprint Backlog) y definimos una fecha corta de entrega del producto (no más de 30 días). Evidentemente en las primeras iteraciones el producto solo satisface unas pocas especificaciones del Product Owner, pero es importante que tras esos 30 días el product owner pueda probar el producto y dar el feedback oportuno.
Al reducir a pocos días la primera entrega la incertidumbre es muy baja y nos aseguramos que estas tareas se van a poder a terminar en esos días.
Además es importante comentar que todos los días hay una reunión corta del equipo (Scrum Master, Ingenieros y QA), de ese modo se favorece la comunicación. Hablaremos de esto más adelante.
Cada iteración en un proceso ágil es parecida a la de un procreo en cascada pero comprimido ya que la cantidad de tareas a abordar es mucho menor. Cada iteración tiene una planificación, una especificación y un desarrollo que se hace casi en paralelo con las pruebas, es decir, no en necesario esperar al final del desarrollo para ir probando
Cuando se termina la primera iteración se le presenta al Product Owner que da su opinión y posibles cambios. Con esos posibles cambios que han sido previamente convertidos en tareas y las tareas siguientes por orden de prioridad se inicia la segunda iteración. Esta nueva iteración se volverá a planificar, especificar y probar en sucesivas iteraciones hasta que este producto final tenga todos los requerimientos que había solicitado el Product Owner, en otras palabras, el producto se ha terminado por completo.
La gran ventaja de scrum frente a la metodología en cascada es que la gente siempre tiene carga de trabajo media/alta, en cambio en la metodología en cascada los últimos meses el trabajo siempre se acumula y la carga de trabajo es exagerada dando lugar a retrasos o trabajo mal realizado. Otra ventaja es que se ven resultados a corto plazo y eso es reconfortante.
Cada iteración debe estar entre 2 y 4 semanas ya que más cortas entre que nos ponemos con la planificación y la especificación perdemos mucho tiempo y más de 4 semanas perdemos la efectividad del método ágil.
A nivel estructural cada iteración constará de una reunión con el Product Owner, una planificación, un desarrollo y posteriormente con la entrega se realiza una demo y una reunión de retrospectiva donde el equipo se sienta y analiza lo que hizo bien, lo que hizo mal y lo que se puede mejorar para el sprint que viene.
La planificación es mucho más importante de lo que se puede pensar ya que es el momento en que el equipo adquiere el compromiso de terminar las tareas en plazo. Además todos los miembros del equipo (los que tienen más experiencia y menos) estiman el coste en horas de trabajo que va a llevar cada tarea aunque no sea una tarea asignada para ellos.
Es importante mencionar que el Scrum muestra las tareas y cada ingeniero, a priori, elige que tareas quiere realizar y que se compromete a ello. En teoría no es el Scrum Master el que asigna esas tareas aunque muchas veces, en la práctica, el Scrum Master debe decidir cuando hay varias personas que quieren la misma tarea. La filosofía es que si el ingeniero elige la tarea que más le motiva y más controla su nivel de implicación se incrementa mucho más que si le imponen el trabajo.
En el planning de trabajo primero se presenta los requerimientos nuevos, luego se planifica y se elabora el Product Backlog priorizado.
Una vez terminada la planificación y asignación de tareas necesitamos un “Scrum Task Board” con tres columnas (Pendiente, En Progreso y Terminado)
Es muy importante indicar que una tarea no pasa a terminada hasta que no esté el control de calidad pasado. Por tanto es muy importante que todo el equipo entienda qué es una tarea terminada.
El Burndown Chart es quien nos marca como vamos agotando las horas (según se van terminando las tareas) hasta acabar el sprint. En la realidad lo que nos ocurrirá si hemos planificado bien será que la mayoría de tareas se acabarán en la última fase del sprint.
Si nos ocurre que tenemos una sobreestimación entonces para el siguiente quizás es más interesante abordar sprint más cortos y realizar una buena reunión de retrospectiva.
También nos puede ocurrir que intervengamos un sprint sobreestimado y le quitemos tareas. Esto hay que evitar hacerlo y en caso de hacerse solo lo contemplaremos si el producto entregado tiene sentido por si solo, es decir, no tendría sentido entregar una mesa sin dos patas. Puedo decir que no está pintada, pero el producto final tiene que tener sentido por si mismo.
Finalmente aquí tenemos un Burndown subestimado con intervención, tampoco es recomendable ya que el equipo ha ido relajado y hemos tenido que hacer una planificación a medias.
Dentro del equipo tiene especial importancia el serponsable de QA que debe ser lo suficientemente avispado para hacer funcionar la herramienta desde el punto de vista del usuario y desde cualquier uso anormal que un usuario final pueda realizar. Es importante también en los proyectos software que haya una gestión automatizada de pruebas repetitivas para agilizar el trabajo del QA
Es muy recomendable que el QA esté dentro del equipo ya que es capaz de adelantar errores a medida que los ingenieros van acabando tareas dentro del scrum y por tanto en menos tiempo se realiza el test.
La reunión diaria dura 15 min y siempre se realiza en el mismo lugar y a la misma hora donde todos los miembros del equipo tienen que participar a excepción del product owner que realmente no es necesario. En esa reunión diaria se ve el avance de la iteración y se formulan 3 preguntas a cada miembro del equipo. ¿que hiciste ayer? ¿que has hecho hoy? y ¿que impedimentos tienes para realizar tu trabajo?. Esta tercera pregunta es importante porque a menudo ocurre que otro ingeniero resuelva el impedimento de otro miembro del equipo.
Cuando termina el Sprint hay que realizar una reunión de retrospectiva
En esta reunión se evalúan los objetivos cumplidos, se adquiere un compromiso de mejora si no se han cumplido los objetivos y se solucionan problemas que haya podido haber durante el scrum.
Normalmente los gerentes no participan en una reunión de retrospectiva.
Para terminar, indicar que esta metodología es susceptible de adaptarse a cada empresa, que depende del contexto y de la experiencia del equipo para que realmente resulte efectiva.
Español 
English