Scrum
Curso de Platzi - SCRUM
Agile
Es la habilidad para crear productos y responder al cambio. - Es un conjunto de marcos de trabajo y metodologías.
Enfocado en personas - Equipos pequeños - Iteraciones
Principios del Manifiesto Agile
Individuos e interacciones sobre procesos - Herramientas Software funcionando sobre documentación extensiva - Colaboración con el cliente sobre negociación contractual - Respuesta ante el cambio sobre seguir un plan
1. Satisfacción al cliente: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. [Entregas tempranas y continuas con valor]
2. Cambios: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Software funcional: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Colaboradores: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Individuos motivados: 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.
6. Comunicación cara a cara: 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.
7. Progreso: El software funcionando es la medida principal de progreso.
8. Desarrollo sostenible: Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. Mejora continua: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. Simplicidad: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Auto-organización: Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. Auto-aprendizaje: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
SCRUM
es un marco de trabajo por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregan productos del máximo valor posible, productiva y creativa.
Pilares:
Transparencia
inspección
Adaptación
Valores:
Compromiso
Coraje
Enfoque
Apertura
Respeto
Componentes de Scrum
Equipo
El equipo de Scrum es auto organizado y multifuncional.
a) Product Owner (Dueño del producto). Responsable de maximizar el valor del producto b) Scrum Master. Responsable de promover y apoyar Scrum. c) Development Team (Equipo de desarrollo). Profesionales que realizan el trabajo de entregar un incremento de producto “Terminado”.
Eventos
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
a) Sprint. Es el corazón de Scrum donde se crea un incremento del producto. b) Sprint planning (Planificación de Sprint). Ceremonia para definir qué se hará durante el sprint. c) Daily stand-up (Scrum Diario). Reunión diaria de todo el equipo de desarrollo. d) Sprint review (Revisión de Sprint). Es donde se muestra el incremento desarrollado durante el sprint. e) Sprint retrospective (Retrospectiva de Sprint). Oportunidad para aplicar mejora continua.
Artefactos
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidad para la inspección y adaptación. Son aquellos elementos que definen que quiere el cliente, pero son visibles para todas las personas que trabajan en el proyecto.
a) Product Backlog (Lista del producto ). Es una lista ordenada de todo lo que se conoce que es necesario en el producto. b) Sprint Backlog (Lista de pendientes del Sprint). Elementos de la lista de producto seleccionados para el sprint.
Equipo SCRUM
Producto owner / Scrum Master / Develop Team
Entregas --> Iterativas e incremental = Entregar valor
EVITAR dependencias [minimizar] IMPORTANTE La organización sea en base a funcionalidad o componente.
Arma tu equipo con todos los profesionales que necesitas
Conforma tu equipo pequeño y flexible de 3 a 9 personas
Asegura de tener todos los roles (product owner, scrum master, team)
Mantén tus sesiones diarias de máximo 15 minutos con un objetivo especifico
Dueño del Producto o Product Owner
Maximizar el valor del producto / Priorizar
Es el representante del cliente.
Expresa claramente los elementos de la lista del producto
Dar prioridad a los elementos de la lista del producto
Optimizar el valor del trabajo del equipo
Asegura que la lista del producto sea visible, transparente y clara.
Asegura que el equipo de desarrollo conozca los elementos de la lista del producto
Desiciones => en base al contenido y priorización de la lista del producto
Scrum Master
Guía de scrum / ayuda ( -Teoría - Practicas de scrum - valores)
Líder * servicio del equipo de desarrollo y fuera del equipo
Al servicio del Scrum Master
Asegura que los objetivos, el alcance y el dominio del producto sean entendidos por todo el equipo
Entender y practicar agilidad
Facilitar los eventos scrum según se requiera o necesite
Al servicio del Equipo de Desarrollo
Guiar al equipo de desarrollo en ser auto organizado y multifuncional
Ayudar al equipo de desarrollo a crear productos de alto valor
Eliminar impedimentos para el progreso del Equipo de desarrollo
Al servicio de toda la Organización
Liderar y guiar a la organización en la adopción de scrum
Trabajar con otros scrum masters para incrementar la efectividad de la aplicación de scrum
La base del equipo de desarrollo
Auto organizado
Multifuncional
No tiene títulos
No hay sub equipos
No se puede modificar el equipo hasta terminar el sprint
Artefactos de Scrum
Las épicas y el backlog del producto
La lista es dinámica, constantemente cambiante para las necesidades del producto las cuales sean adecuadas, competitivas y útiles.
La lista del producto es un artefacto vivo, contiene elementos llamados historias de usuario
Todas las historias de usuario se pueden agrupar en elementos mas grandes llamadas Epicas
Las Epicas contienen funcionalidades o módulos del producto, pueden llevarse más de un spring.
¿Qué nos cuentan las Historias de Usuario?
Son elementos mas específicos de la lista del producto, contiene la vision del usuario sobre la funcionalidad.
HISTORIA <> REQUERIMIENTO
Titulo | Descripción | Puntos | Criterios de aceptación
Como <rol>
Quiero <acción>
Para <beneficio>
Historias Completadas
Elementos requeridos para clasificar una historia esta lista. ej:
Funcionalidad (Criterios de aceptación)
Código subido a Git
Pruebas Creadas
Documentación
Invirtiendo tiempo en Historias
Las tres C's
Cards | Conversation | Confirmation
I - independiente
N - negociable
V - valiosa
E - estimable
S - small
T - testeable
Estimar historias de usuario
Puntos <> horas <> días = Estimado, no estan relacionados con ninguna forma de medicion.
Complejidad
Cantidad de trabajo
Conocimientos necesarios
Incertidumbre
se puede usar el llamado poker de planeación, Fibonacci modificad o 2n
VELOCIDAD: es el total de puntos de las historias de usuario completadas por el equipo durante un sprint
CAPACIDAD: total de historias de usuario que se pueden completar en un sprint futuro.
¿Por dónde comenzar? Prioridades y backlog del sprint
Backlog del sprint = Elementos de la lista del producto que serán trabajadas durante el sprint.
= Incrementa valor al desarrollo
Stories => to do => In progress => Testing => Done
Lista de pendientes del sprint
Plan detallado para que todo el equipo sea capaz de comprenderlo en los dalily.
El equipo nuevo dueño, puede decidir si aceptan agregar mas elementos o sacar si fuera necesario. consenso.
Definiendo Prioridades
Valor ara el cliente
Urgencia
Riesgo y Oportunidad
Esfuerzo
Midiendo el avance del proyecto
Revisa en cualquier momento el avance, revisa el cumplimiento del objetivo del sprint
Gráficas
Burn down chart (trabajo pendiente) puntas
Burn up chart (trabajo completado)
(flujo acumulado)
El sprint
Periodo de tiempo determinado (1-4) semanas que se crea un incremento de producto.
Planeación
Scrum diario
trabajo de Desarrollo
Revision del sprint
Retrospectiva
El sprint debe tener un objetivo claro | El product Owner tiene la autoridad de cancelar el sprint, poco común.
Planeando el sprint
Debe de estar presente todo el equipo. No debe de durar mas de 8 horas(sprint 4 semanas)
El scrum master se encarga de organizar todo.
Qué puede entregarse al final del Sprint?
Elementos prioritarios de la lista de Prod.
Un objetivo
se necesita saber la capacidad del equipo y velocidad de la ultima iteración.
Como se va a lograr?
Se mueve los elementos de la lista del Producto (backlog) => Lisa de Pendientes del sprint.
Producto owner aclara dudas.
Pueden tener invitados (clientes, usuario)
Elementos - Estimación - Capacidad - Objetivos
Daily stand-up
Es una reunion diaria de no más de 15 minutos del equipo. Se utiliza para planear las próximas 24 horas de trabajo.
Scrum master ayuda a programar todo, en el mismo lugar a la misma hora. Pueden participar otras personas.
Tres preguntas:
Qué hice ayer? Qué hare hoy? Tengo algún impedimento?
El scrum master ayuda a resolver impedimentos.
Refinando historias
Sessions de refinamiento, al menos una vez cada sprint a mitad como recomendación.
Participa el product owner y opcional el scrum master.
Objetivo es tomar las funcionalidades a trabajar en el siguiente sprint.
Mostrando y aprendiendo: demos y retrospectivas
Sprint Review
Ocurre al final del sprint en ella se muestran avances del producto. Fomenta la retroalimentación rápida. Es facilitada por el scrum master, no debe de durar más de 4 horas. Se muestra el producto no presentaciones.
Retrospectiva:
Participa solo el equipo, debe ser positiva y productiva no para culpar a nadie. No debe de durar más de 3 horas, es facilitada por el scrum master y participa todo el equipo de scrum.
Herramientas | Relaciones | Personas | Procesos
Qué hicimos bien? Que no hicimos tan bien? Qué podemos mejorar?
Se desarrolla un plan de acción.
Escalabilidad de equipos
Scrum of scrums e una reunion donde frecuentemente se encuentran uno o dos representantes, permite coordinar esfuerzos entre los distintos equipos.
Última actualización
