Generalidades - SCRUM
- Repaso metodológias ágiles
- Herramientas de SCRUM
- Recomendaciones proyecto en clase
Repaso Metodológias Ágiles
Las metodológias ágiles propone una forma de resolver problemas con los cuales se había peliado durante años. Se puede decir que los proyectos ágiles:
- Se entregan a tiempo
- Entregan software de alta calidad
- El código construído por equipos ágiles es bien construído y altamente mantenible.
- Hace a sus clientes felices
- Los desarrolladores de un equipo ágil trabajan tiempo normal
Repaso Metodológias Ágiles
El principal interés de una metodológia ágil es cambiar la mentalidad del equipo y empezar a incluir prácticas ágiles para que el equipo mejore la forma de construir software.
¿Qué es ágil?
Es un conjunto de métodos y metodológias que ayudan al equipo a pensar de forma más eficiente, trabajar más eficientemente y tomar mejores decisiones. Y estos métodos y metodologías estan dirigidas a las siguientes áreas:
- Administración de proyectos
- Diseño de software y arquitectura
- Mejora de procesos
Lo más importante es que ser ágil, implica una mentalidad donde el equipo por ejemplo pueda tomar decisiones importantes junto, sin necesidad de tener un director que tome las decisiones solo. Porque lo importante es que todas las personas del equipo compartan la misma información.
La historia del movimiento ágil, empieza cuando un grupo de personas se reune para pensar de una manera diferente como resolver los mismos problemas. Lo primero que hacen es publicar un grupo de valores claves que encontraron en común en equipos exitosos, lo llamaron el manifiesto ágil.
- Individuos e interacciones por encima de herramientas y procesos
- Software funcional por encima de documentación comprensible
- Colaboración con el cliente por encima de negociación de contratos
- Responder al cambio por encima de seguir un plan
Hoy sabemos que no hay una única forma de construir software, no hay un único método que podamos usar para resolver problemas para todo el mundo en toda parte. Muchas personas piensan que un desarrollador puede construir software solo con seguir un conjunto de instrucciones, como siguiendo una receta o ensamblando un producto en una línea de producción.
- Mejor comunicación ayuda a los equipos a manejar mejor el cambio
- Planear como un equipo es más importante que sobredocumentar un proyecto y planearlo, sin seguir el cronograma
- Los proyectos de software han sido impredecibles y tenido pobres resultados desde 1960
- Muchos equipos tratan de volverse ágiles, adoptando practicas ágiles conocidas mejorando lo que ya realmente hacen bien ahora.
12 Principos del manifiesto ágil
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
12 Principos del manifiesto ágil
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
12 Principos del manifiesto ágil
- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Historias de Usuario
Sirven para construir características que sus usuarios realmente van a usar, los equipos ágiles empiezan por meterse en la cabeza de los usuarios y tienen en las historias de usuario una herramienta muy efectiva para hacerlo.
- Una historia de usuario es una herramienta demasiado simple
- Es una descripción rápida y simple de una forma específica de como el usuario usará el software
- Esta compuesta por un reglón máximo cuatro
- Debe caber en una hoja de post-it de 3x5
Historias de Usuario
Se recomienda utilizar el siguiente formato para definir las historias de usuario
Definir un título de la historia
Cómo un <Tipo de usuario>, yo quiero <Acción específica que va a realizar> así que <lo que quiero que pase como resultado>
Historias de Usuario
Las historias de usuario son efectivas porque hacen tres cosas obvias
- ¿Quién es el usuario?
- ¿Qué quieren hacer los usuarios?
- ¿Por qué los usuarios lo quieren hacer?
Historias de Usuario
El equipo luego debe validar con el Product Owner la historia de usuario y se debe pegar a lo que dice, de esta forma no se desarrolla una nueva funcionalidad que el usuario no necesita y nunca va a usar.
Cada historia de usuario es simple y esta escrita desde la perspectiva del usuario por tanto es fácil para el Product Owner revisar la historia y decir si es realmente importante. Muchos equipos parten las historias de usuario en tareas y empiezan a estimar cuanto se va a demorar cada una.
Historias de Usuario
Las tareas de cada historia deben ir en la columna "To Do" en el tablero para esperar que alguien pueda trabajar en ella. Cuando el miembro de equipo esta listo para empezar una nueva tarea, seleccionará la siguiente tarea más valiosa que puede realizar, escribe el nombre en la tarea y la mueve a la columna "In Progress" para indicar que tomo la tarea.
Condición de satisfacción
Una forma de estar seguro de lo que se esta construyendo es imaginar como se va a ver cuando este construído. Es muy satisfactorio cuando el desarrollador da un paso al lado y mira lo que esta construyendo y siente que esta terminado. Las condiciones de satisfacción ayuda para saber como se va a ver el software cuando este terminado y saber cuanto falta para terminar.
Condición de satisfacción
Algunos equipos definen una condición de satisfacción por cada historia de usuario, como las cosas que el usuario estará habilitado en hacer con el software una vez la historia sea escrita. Normalmente esta condición se escribe en la parte de átras del post-it.
Condición de satisfacción
Estas condiciones son valiosas para el desarrollador porque ayudan a evitar cantar victoria muy rápido. Le da por tanto al equipo una definición concreta de que significa terminado.
Condiciones de satisfacción- Un usuario puede realizar un comentario
- Un usuario va a ver su avatar al lado del comentario que hace
- Un usuario puede eliminar sus comentarios
- Un comentario puede ser calificado
Story Points y Velocity
Durante la planeación del spring, todo el equipo trabaja junto para estimar cuanto trabajo pueden realizar en el sprint, para poder fijar una meta para el software funcionando que será entregado al final. Una técnica que a mostrado efectividad para los equipos de scrum al estimar cuanto trabajo puede hacer un equipo es usar story points. Por medio de los story points, podemos entender cuanto esfuerzo se necesita para construir una historia de usuario específica, asignandole un puntaje.
Story Points y Velocity
No hay un estandar o regla general sobre como se deben asignar los puntos a cada historia, algunos equipos asignan valores entre 1 y 5 a cada historia. Lo importante es usar una regla consistente entre cada sprint. Algunos equipos usan números de la secuencia de fibonnacci o numeros exponenciales. Finalmente se debe contar cuantos puntos se completan en un sprint y esta sumatoria daría el valor de velocity del proyecto.
Story Points y Velocity
Los equipos tienden a trabajar a una velocidad constante, medida a través de los sprints. Cuando es difíficl predecir cual será la velocidad del proyecto antes de empezar a trabajar con el equipo, se puede usar la velocidad de spring pasados para planear el siguiente. Sin embargo, si un equipo hizo 32 puntos el sprint pasado y 29 en el sprint siguiente no hay garantía que realice 30 puntos en el nuevo sprint.
Story Points y Velocity
No sobrecargue el backlog del sprint. Esta bien dejar espacio en el backlog, pero no esta bien ir más allá de lo que el equipo hizo en el pasado.
Si su equipo tiene una velocidad promedio de 28 puntos por sprint y ya se han llenado 26 historias que realmente requieren ese trabajo, entonces solamente se puede agregar 1 o dos puntos más. Los desarrolladores son muy optimistas por naturaleza, porque son constructores, el equipo se verá tentando a agregar 3 puntos para estar por encima por 1.
Story Points y Velocity
Lo más importante es no caer en la tentación de sobreestimar el sprint porque es una forma de desilusionar al usuario en el siguiente sprint review. ¿Qué pasa la primera vez que el equipo hace esto? es simple, tome la historia de usuaria que considere más valiosa y asignele un valor de 5, busque la más pequeña y asignele 1 punto las historias que se encuentran a mitad de camino asignele un valor arbitrario de tres. Continue llenando las demás historias de usuario. Cuando el equipo ya a superado dos sprints se tendrá historias suficientes para comparar y una buena idea de la velocidad promedio del equipo.
Burndown Charts
Es una forma para que cualquiera pueda ver, de un vistazo, como esta progresando actualmente el sprint cuando se compara con la velocity del sprint pasado.
Burndown Charts
- Se empieza con una gráfica vacía.
- El eje horizontal tiene las fechas, empezando en el primer día del sprint hasta el último día.
- El eje vertical tiene los story points, 20% por encima del total de puntos que hay en el backlog.
- Trace una línea recta (guideline) desde el primer punto hasta el fin del proyecto, zero puntos quedan cuando el sprint esta completo
Burndown Charts
La gráfica muestra el avance ideal del spring, la idea es mantenerse en la línea o por debajo de ella, quemando tareas a un ritmo constante
Burndown Charts
- Tan pronto como la primera historia de usuario esta terminada y movida a la columna "Done", se dibuja un punto con el total de puntos que quedan en el sprint en el día actual
- Mientras se van terminando historias y se "queman" más puntos del backlog, lleno con más días la gráfica.
Burndown Charts
En 3 días se queman 4 puntos de 2 historias de usuario.
Burndown Charts
- Se prodrá descubrir durante el Daily Scrum que más trabajo debe ser agregado.
- A veces el equipo quema más puntos de los que se esperaba y terminan antes como resultado.
- El director de producto puede requiere que se agregue una nueva tarea al sprint.
- La nueva tarea se puede agregar, pero se debe modificar o crear la historia de usuario, estimar los history points y luego modificar la gráfica.
- Es útil agregar una línea extra para mostrar en la gráfica donde fueron agregados los puntos.
- No tenga miedo de escribir notas en la gráfica.
Burndown Charts
Se agregan historias de usuario durante la ejecución del sprint.
Burndown Charts
Cuando vaya acercandose al final del sprint, más y más puntos se íran quemando en la gráfica. Mantenga la atención en el margen entre la línea guía (guideline) y su línea actual de quema de tareas (burndown), porque probablemente tiene muchas historias y debe remover alguna del sprint.
Burndown Charts
Burndown Charts
Hay muchos paquetes de software que le permiten administrar el backlog, historias, puntos de historia y crear gráficos burndown automáticamente. Sin embargo, muchos equipos prefieren hacelo todo a mano, mantener la gráfica burndown en la misma pared. Esto permite que todo el mundo vea exactamente como va el proyecto en cualquier momento. Es especialmente satisfactorio cuando el desarrollador completa una historia de usuario y mueve la tarjeta a la columna "Done".
Trabajo de proyectos en clase con SCRUM
El enfoque academico actual, busca que el estudiante desarrolle proyectos sobre los temas vistos durante el curso y ponga a prueba los conocimientos adquiridos, teniendo en cuenta un alcance técnico y de tiempo que son definidos al empezar el semestre con acompañamiento del docente.
Trabajo de proyectos en clase con SCRUM
Se busca que el estudiante, desarrolle sus proyectos aplicando SCRUM como metodología y teniendo en cuenta las siguientes características
- Debe trabajar en equipo, mínimo 2 personas
- Debe realizar un compromiso, por medio de: PITCH, plan de negocio, que incluya el alcance y los criterios de aceptación
- El equipo define cuando empieza y cuando termina cada Spring, mediante un spring planning del Backlog
Trabajo de proyectos en clase con SCRUM
- En el aula de clase se contará con un espacio semanal 'weekly meetings' donde se deberá responder a las preguntas: ¿Qué se hizo?, ¿Qué se va a hacer?, ¿Qué contratiempos hay?, en un máximo de 5 minutos
- Se debe entregar valor, código funcional, al finalizar cada spring
- Se debe hacer un Spring Review documentado en el foro, donde queden claro "Lo bueno", "No tan bueno" y "A mejorar"
Para tener en cuenta para la evaluación
Se debe guardar todas las evidencias del proyecto: Graficas hechas a mano, historias de usuario, notas adhesivas, fotografías, referentes, etc.
Para facilitar el seguimiento del proyecto se creo el foro holamundo.co para que los estudiantes cuenten con un espacio colaborativo para compartir sus ideas y poder tener retroalimentación del docente y de sus compañeros
Para tener en cuenta para la evaluación
La fecha de entrega del proyecto no se mueve, por tanto en caso de requerir un ajuste en el plan de trabajo se debe contar en los 'weekly meetings'
Si no hay evidencia de ajustes en el plan de springs, se considera como un logro no alcanzado por el estudiante y por tanto la nota del proyecto se ve afectada
Para tener en cuenta para la evaluación
La duración de cada 'weekly meeting' es de 5 minutos cronometrados
Los grupos con muchos equipos tendran 'weekly meetings' en cada clase, dividiendo la cantidad de equipos en cada una de ellas.