Scrum, un método ágil a utilizar en el curso. Scrum viene de Japón en los años 80, y está basado en las mejores prácticas de las empresas con buenos resultados de rapidez y flexibilidad en la producción de la época. (Entre las empresas están Xerox, Canon, 3M, HP… En el 95, se formaliza OOPSLA con la primera mención de Scrum en el área de software, en el 2002 se funda el ScrumAlliance y en el 2009 se funda scrum.org, estos últimos 2 organismos certifican Scrum. La idea fundamental de scrum es que es mejor tener equipos pequeños y auto organizados, es decir que como equipos debemos organizarnos y cumplir el trabajo, lograr tener miembros de diferentes disciplinas trabajando y cooperando como un solo equipo, con una comunicación transparente. La palabra scrum viene del rugby, que significa melé, en la que los compañeros se amontonan y empujan a la misma dirección. Scrum se forma por cuatro componentes, que también son parte de otros métodos de software. Tiene 3 roles, que es el tipo de trabajo que tiene que hacer cada persona, 4 ceremonias o reuniones, que son las entregas de lo que hay que hacer, decir de qué forma vamos a hacer interactuar los roles, los artefactos y el proceso para lograr los objetivos. 3 artefactos, que son las herramientas o productos que usamos y cosas que generamos (qué vamos a usar, qué vamos a producir para desarrollar el producto?) y 1 proceso que es como coordinamos todo lo demás para poder generar el producto. Como los 3 roles principales en scrum, tenemos: El Product Owner, que es el dueño del producto. El Equipo, que es el dueño del proceso de desarrollo del producto y el Scrum Master que es el facilitador del proceso. A estos tres, se les considera los cerdos. Y otros roles que son los clientes los ejecutivos y los usuarios.. que son los pollos. Cerdos porque ponen el jamón en el proyecto, tienen la prerrogativa de auto organizarse y los pollos simplemente están involucrados. Como núcleo del proceso de Scrum tenemos a un sprint, que es una iteración, un ciclo de desarrollo, etc.. que dura entre 1 y 4 semanas, aunque los equipos buenos duran 1 semana, la idea general es que mientras más corto mejor. Esto nos da un lazo de feedback, para ver cómo nos fue y así podemos corregir rumbo sin perder mucho tiempo de trabajo. Y también nos permite un lazo de feedback diario, de saber cómo nos va y que podemos hacer para cambiar rumbo (si es necesario) para que nos vaya mejor. Si reducimos el lazo de feedback, comparado con el proceso de cascada, probablemente vamos a resolver muchos de los problemas tradicionales de software. La idea es que a lo largo de varios sprints podamos resolver el producto de software, significa que si por ejemplo colocamos sprints cada 3 semanas, podamos tener muchos más lazos de feedback quizás que un proyecto tradicional. Cabe destacar, que los sprint no se alargan, el sprint es cerrado, sea lo que sea que tengamos se muestra en el tiempo de duración que definimos inicialmente. Es control empírico, no es planificar el proyecto completo y tratar de disparar la bala del cañón y pegarle a la primera. Es tomar el misil y con los lazos de feedback, ir corrigiendo el rumbo del proyecto. De los 3 artefactos básicos tenemos el product backlog que básicamente tiene los requisitos, (una lista de deseos para el cliente, pero para nosotros los desarrolladores de software es todo lo que debería ser el producto), el sprint backlog que no es nada más que tomar ítems del product backlog y decidir cuales se van a desarrollar en cada sprint. Y el entregable que es el último artefacto, es el resultado del producto, ejemplo una versión del software potencialmente entregable que se pueda poner en producción, pero no solamente puede ser software, puede ser también documentación, pruebas y cualquier otra cosa, esa cualquier otra cosa es la definición del Done, al cumplir con el checklist. Sirve también para compartir la visión del Done con el cliente, pues puede pasar que para nosotros esté listo el entregable en un sprint y que el cliente no lo considere como listo todavía. Hay dos artefactos más, que oficialmente no son parte de scrum pero que se suelen utilizar. El tablero de Kanban para organizar tareas, y el grafico de Scrum Burn Down que nos muestra que tal vamos a lo largo del proyecto. De las 4 ceremonias que define Scrum: - - - Sprint Planning: Se reúnen los 3 roles y analizan el product backlog, allí deciden que historias de usuario del product backlog se van a hacer en el siguiente sprint. Duración aprox: Una tarde Daily Scrum: Una vez que arranca el Sprint, es una reunión diaria, muy corta, para poder tener una idea diaria de cómo vamos (lazo de feedback diario). Duración aprox: 15 min. Sprint Review: Al final del sprint, se muestra a los clientes lo que hemos hecho y allí se ve si cumple con la definición de Done o no. Duración aprox: 2 horas Retrospectiva: Es sentarse todo el equipo (puede ser con el cliente también) y ver cómo nos fue y si es necesario mejorar, definir criterios claros y rumbos de acción para mejorar. Duración aprox: 2 horas. Así sucesivamente las 4 ceremonias hasta finalizar todos los Sprint. La duración de las ceremonias para sprints de una semana son 24 horas, si son sprints para más de una semana se pueden aumentar proporcionalmente. Ya definiendo los requisitos en Scrum (de que debe hacer el producto), sobre los product backlog y sprint backlog, hay una herramienta para usar que son las historias de usuario, es una narración que describe una funcionalidad del sistema que tiene valor para un usuario. Se recogen en unas sencillas tarjetas (pueden ser fichas de biblioteca) de forma esquemática y en un lenguaje claro y preciso. Se trata de describir en esa ficha aspectos importantes y necesarios para hacer el requisito, quien es el interesado en esa historia, que es lo que se supone que se debe hacer y por qué? Las historias de usuario no tienen que tener necesariamente todo el detalle que se necesita para desarrollar esa funcionalidad, se deben ver más que como documentación extensiva como una especie de recordatorio de la funcionalidad que hay que implementar en el sistema y antes de implementar una funcionalidad en particular, se produce una discusión con el usuario (product owner), se refina y extiende la información de la historia de usuario, esto generalmente sucede en el sprint planning. Como opinión personal del profesor, es posible y útil también escribir un breve documento (no más de 5 páginas) donde se define la visión general del producto (quienes van a usar el producto, la motivación para desarrollar el producto, de que se trata el producto) Para saber cómo ordenar o gestionar los requisitos, podemos ver el product backlog (mantenido y dirigido por el product owner) como una lista de historias de usuarios priorizadas (por el product owner) de todo lo que el cliente desea del producto. Al hacer el planning, se toma las historias de usuarios de mayor prioridad del product backlog y las pasa al sprint backlog, aquí las historias ya tienen suficiente detalles, se han estimado y conversado para hacer el siguiente sprint. Se puede también a través del product backlog planificar a largo plazo, hacer planes y distribuir el trabajo en un conjunto de sprints (Release plan), tomando en cuenta que puede que las cosas se den así como puede que no, no es una medida infalible. Priorizar el valor del negocio, se debe a satisfacer los requerimientos más importantes en el sprint que se está haciendo, se debe garantizar el hacer lo que es realmente importante para el cliente El equipo es el dueño del sprint backlog, y no hay modificaciones durante el desarrollo de ese sprint, el equipo está concentrado en cumplirlo y si hay modificaciones, se priorizan para el siguiente sprint, es decir se llevan al product backlog. En un hipotético caso, puede suceder que se acaben las historias de usuarios, entonces el product owner puede priorizar historias para que el equipo pueda trabajar en otras. La idea es proteger al equipo de los cambios de objetivos y de los cambios a mitad de trabajo. Para saber cómo se estiman y planifican las historias en el backlog, en el sprint planning, debemos tener historias muy detalladas, que potencialmente se seleccionan del backlog, allí decidimos cuales historias se van a introducir en el siguiente sprint. Antes de comenzar el sprint, de ser necesario, el product owner refina las historias de usuario, usando cualquier técnica que considere adecuada. En el curso, hicimos otra dinámica, la cual consistía en repartir a cada uno de los miembros de equipos de trabajo, cartas de acuerdo a la serie de Fibonacci, con una secuencia de números: 1 ,2, 3, 5, 8 y 13, con el fin de estimar más o menos de acuerdo a la dificultad, tiempo de construcción, etc los distintos features o historias de usuarios para construir con legos los product backlog (Empezando por el castillo, luego el Auto, el Avión, la Nave Espacial, Dragón, Perro, Acelerador de Partículas) . La idea es seleccionar una carta, y luego cada uno mostrar la carta ante el equipo, así no se ve influenciada la decisión de cada uno y se podrá llegar a un acuerdo y tomar decisiones de la dificultad del producto por consenso. Cada equipo definió en un tiempo determinado, el estimado de la dificultad relativa de la construcción de un producto respecto a otro, esto no nos define tiempo, si no nos muestra es como nos sentimos con el feature. Ahora con el sprint planning, se definió según orden de prioridad para el cliente, la construcción de los product backlog. En este paso, el equipo se reúne para ver qué es lo que se va añadir para el siguiente sprint en desarrollo y que productos se comprometen a construir. Una vez hecho esto, el equipo debe tomar decisiones y concentrarse en prioridades. Suponiendo que uno de los equipos se comprometió y cumplieron con lo establecido y les sobró tiempo (equipo azul), entonces pudieron avanzar un poco con el siguiente product backlog prioritario, mientras que en el otro equipo (equipo rojo) no terminaron con todos los productos que se comprometieron en el primer sprint, quizás empezaron a hacer algunos pero no los terminaron, y no cumplieron con la velocidad que necesitaban para terminar, lo cual no cumple con la definición de done, aunque tengan todo más claro. Para el equipo que no cumplió con la definición de done (equipo rojo), obviamente tiene el problema mucho más claro, por lo que la dificultad ahora no va a ser como el valor inicial sino será en menor grado. De igual modo, sucedió con el otro equipo (equipo azul) que pudo avanzar con el castillo pero no lo terminó, lo cual la dificultad es menor, pues debido al trabajo ya iniciado en ese sprint, en el sprint que sigue, será más fácil para construirlo. Luego de esto, el equipo se reúne para hacer el segundo sprint y adquirir nuevos compromisos para ver que van a construir, resultando que el equipo azul se comprometió a terminar el castillo (que ya habían empezado) y a otros dos productos que seguían (Dragón y perro), mientras que el equipo rojo se comprometió a hacer 3 productos, el avión y la nave espacial que ya habían empezado y el dragón, lo cual indica que es mucho trabajo que quizás no puedan hacer por la dificultad de los productos; el product owner decidió tratar al dragón por separado, en cuerpo y cabeza, cambiando ahora el panorama, el equipo rojo decidió entonces terminar el avión, la nave espacial y hacer el cuerpo del dragón. Todo esto resultó, que el equipo azul terminara el castillo y el dragón pero no pudo con el perro para este sprint (es decir no cumplía con la definición de donde), mientras que el equipo rojo, cumplió con el avión, la nave espacial y con la cabeza del dragón. En este tercer sprint, el equipo azul reestima al perro, con una dificultad menor por ya haber empezado a trabajar con él en el sprint anterior, este equipo se compromete a terminar el perro y se trata por separado al acelerador de partículas en magnetos y sala de control, comprometiéndose a hacer los magnetos y el equipo rojo se compromete a hacer la cabeza del dragón (a terminarlo), el perro y la sala de control del acelerador de partículas, logrando ambos equipos cumplir con las estimaciones en este sprint, lo que quiere decir que gracias a los dos o tres primeros sprint hechos se puede afinar la velocidad del equipo y así planificar la óptima estimación para la construcción del product backlog. Tal cual como esta dinámica es el trabajo con software que haremos. Hasta ahora, el trabajo se vé con sprints uno tras otro con duración entre 2 y 4 semanas, al final de cada sprint tendremos un producto potencialmente entregable que cumpla con ciertas features (características). Tenemos el product backlog que es global para todo los sprints y que tiene todos los requisitos priorizados, bien organizados y detallados que el cliente desea, se producen los planning que nos permiten pasar ítems del product backlog al sprint backlog, se produce el sprint con una reunión diaria, al final del sprint hacemos un demo (mostramos lo que hicimos) y verificamos que lo que hicimos concuerda con lo que se pidió y que cumple con la definición de done, si está listo, entonces lo marcamos como listo, y si no está listo, lo reestimamos y lo devolvemos al product backlog. La prioridad la define el product owner, luego hacemos una retrospectiva si nos fue mal o nos fue bien, que se debe mantener, que se debe mejorar, y definimos cursos de acción concretos. Este ciclo se repite hasta que el producto backlog este vacío o que el product owner lo decida.