Embed Size (px)
Citation preview
C U R S O P R E S E N C I A L
SCRUM MASTER
Contenido 1. Lean, Agile and Scrum
2. Marco de Referencia SCRUM
3. Scrum Team
1. Product Owner
2. Development Team
3. Scrum Master
4. Scrum Events and Artifacts
1. Sprint and Increment
2. Sprint Planning
1.Producto Backlog
2.Sprint Backlog
3. Definition of Done (DoD)
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective
Presentación Participantes
• Nombre, Puesto • ¿ Cuál es tu experiencia desarrollando software en equipo bajo un enfoque
ágil ?
• ¿Has estudiado o usado métodos de planificación anteriormente?
• ¿Qué entiendes por frameworks ágiles?
• ¿ Qué esperas de este curso ?
Logística
Horario
Descansos
Sanitarios
Teléfonos
Laptops
Enfoque Práctico
Participación Constante
Acuerdos de trabajo
Conceptos obtenido del SCRUM Guide 2016. Ayuda para el examen de Professional Scrum Master I.
Recomendaciones.
Convenciones
Enfoque y Reglas de la Sesión
Objetivos del Curso
• Conocer en que consiste el marco de trabajo (framework) de SCRUM • Entender cuando es más conveniente usar el marco. • Ser capaz de explicar SCRUM al equipo y stakeholders
En resumen el participante:
Entender, Aplicar y Explicar SCRUM
Lean, Agile and Scrum
Soluciones LEAN de Manufactura
• Kanban
• Kaizen
• Lean
• Andon
Deming Robot Toyota
Tom y Mary Poppendieck
Ágil
• Veloz • Adaptable
• Compacto
• En búsqueda de Valor!!!
ENERO FEBRERO MARZO
Todos los roles participan
¿Qué es SCRUM?
Framework de SCRUM
• Product Owner
• Scrum Master
• Development Team
SCRUM Team
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Eventos
• Product backlog
• Sprint backlog
• Incremento***
Artefactos
“Agile Manifesto”
Scrum Mike Beedle Ken Schwaber Jeff Sutherland
We are uncovering better ways of implementing and developing
complex solutions by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working Components over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items
in white, we value the items in yellow more.
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguimiento de un plan
“Agile Manifesto”
Scrum (s): Es un marco de trabajo que permite atender y resolver problemas complejos, proponiendo soluciones creativas y productivas con el fin de entregar productos con el mayor valor posible.
Ligero Fácil de entender Difícil de Dominar
Útil para: Trabajar con req. cambiantes. Donde se necesita obtener resultados pronto. Proyectos en entornos complejos.
SCRUM
Pilares SCRUM
“Transparencia” “Inspección” “Adaptación”
Las Promesas de SCRUM
“Siempre entregar VALOR”
“Nunca entregar después de TIEMPO”
“Permitir constantemente la VISIBILIDAD”
Principios SCRUM
Disciplina Espíritu de equipo Objetivo claro Mismas reglas para todos Diversión Entrega de resultados
Proceso Empírico
“El método empírico-analítico es un modelo de investigación científica, que se basa en
la experimentación y la lógica empírica, que junto a la observación de fenómenos y su análisis estadístico, es el más usado en el campo de
las ciencias sociales y en las ciencias naturales.”
Metodología
Metodología, es el conjunto de métodos, conceptos o procedimientos
basados en principios lógicos para alcanzar un objetivo
Framework
Un framework, es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como
referencia, para enfrentar y resolver nuevos problemas de índole similar.
Procesos
Framework
Método
Metodología
¿Porque SCRUM NO es un proceso?
La agilidad implica una transformación cultural mientras que la metodología implica un proceso
basado en pasos predefinidos.
La metodología no fomenta y por el contrario puede impedir el descubrimiento y empirismo.
¿Porque SCRUM NO es un proceso?
Análisis de Requerimientos
Diseño
Pruebas
Código
Integración
Despliegue
Dr. Winston Royce: Managing the Development of large SW systems
Programación Tradicional
Enero Febrero Marzo Abril Mayo Junio Agosto Sep. Oct. Nov. Dic.
Análisis
Diseño
Pruebas
Código
Integración
Despliegue
Análisis
Diseño
Pruebas
Código
Integración
Despliegue
Análisis
Diseño
Pruebas
Código
Integración
Despliegue
Análisis
Diseño
Pruebas
Código
Integración
Despliegue
Análisis
Diseño
Pruebas
Código
Integración
Despliegue
Programación con Scrum Enero Febrero Marzo Abril Mayo Junio Agosto Sep. Oct. Nov. Dic.
SPRINT SPRINT SPRINT SPRINT SPRINT
SCRUM Team
Framework de SCRUM
• Product Owner
• Scrum Master
• Development Team
SCRUM Team
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Eventos
• Product backlog
• Sprint backlog
• Incremento***
Artefactos
Valores
Transparencia
Respeto profesional
Autoadministración (empowerment)
Compromiso
Entrega de resultados (valor)
Product Owner
Es el representante de todas las personas interesadas en los resultados del proyecto
Decide cuándo tiene sentido implementar o liberar funcionalidad a
los clientes al final de cada Sprint.
Es el encargado principal del: PRODUCTO
Development Team
Es el grupo de personas encargadas principalmente de desarrollar el Proyecto
Scrum Master
Es el encargado principal de vigilar, promover e impulsar la aplicación del Framework
Comprometidos vs Involucrados
Ciclo de Vida SCRUM El desarrollo es iterativo (Sprints) en Scrum, se prioriza cada uno de los desarrollos en base a las necesidades/objetivos del cliente.
Scrum Master - Development Team
Scrum Master
Development Team
Coaching equipos auto organizados
Facilitar eventos Scrum
Facilitar y eliminar impedimentos
Ayudar en la mejor comprensión del marco
Scrum Master - Product Owner
Scrum Master
Sugerir técnicas admón. Product B.
Entender y practicas la agilidad
Ayudar en comunicar visión y objeticos
Product Owner
Técnicas de recolección de req.
Desventajas de roles compartidos
Roles en SCRUM
Instrucciones:
En grupos discutan sobre la siguiente pregunta por 5 minutos y expongan sus opiniones:
¿Por qué consideran que solo son necesarios 3 roles en SCRUM?
Actividad
Product Owner Es el representante (una persona) de todas las personas
interesadas en los resultados del proyecto
Actúa como interlocutor único ante el equipo, con autoridad para tomar decisiones.
Es responsable del valor de negocio del producto (ROI)
Definir los objetivos del producto y proyecto.
Define las funcionalidades del producto.
Decide cuándo tiene sentido implementar o liberar funcionalidad a los clientes al final de cada Sprint.
Es el encargado principal del: PRODUCTO
Development Team
Equipo auto dirigido (self-managed / self-organizing)
Equipo multidisciplinario (cross-functional). Todos pueden colaborar en las diversas actividades.
Tiempo completo en el proyecto.
Realizan sus propias estimaciones.
Consiste entre 3 a 9 personas.
Es el encargado principal de desarrollar el Proyecto =>Producto
DEV TEAM
Tamaño del Dev Team
Instrucciones:
En equipo identifiquen al menos 3 ventajas y 3 desventajas de que el tamaño de un Dev Team sea no menos de 3 y no mas de 9 personas y expongan sus opiniones.
Actividad
Scrum Master
Remover los impedimentos.
Apoyar en las técnicas y prácticas Scrum.
Ayudar a mantener al equipo enfocado.
Apoyar en la comunicación entre el equipo.
Facilitar las reuniones
Proteger al equipo
Es el encargado principal de vigilar, promover e impulsar la aplicación del Framework
SCRUM Events & Products
Framework de SCRUM
• Product Owner
• Scrum Master
• Development Team
SCRUM Team
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Eventos
• Product backlog
• Sprint backlog
• Incremento
Artefactos
Ciclo de Vida SCRUM El desarrollo es iterativo (Sprints) en Scrum, se prioriza cada uno de los desarrollos con base en las necesidades/objetivos del cliente.
Time Box
Un evento no puede durar mas allá de una duración Fija
Sprint
ENERO FEBRERO MARZO
Todos en el SCRUM TEAM participan
Sprint
Duración Fija (se negocia Alcance, no fechas)
promueve la entrega exitosa del objetivo del sprint
Ayuda al Scrum Team a aprender a entregar incrementos valiosos de forma iterativa
No mas de un mes calendario
No tan largo que el riesgo es inaceptable para el Product Owner.
No tan largo que otros eventos de negocio no puedan ser rápidamente
sincronizados con el trabajo de desarrollo.
El propósito de un Sprint es el producir un incremento terminado
(DONE) del producto
Incremento
Funcionalidad adicional en un estado utilizable que complementan las
entregadas en iteraciones previas.
Cancelación del Sprint
¿Cuál de las siguientes opciones es correcta?:
a) Cuando el Product Owner determina que no tiene sentido
terminarlo.
b) Cuando Ventas tienen una nueva oportunidad importante.
c) Cuando está claro al final del Sprint que no todo estará
completado.
d) Cuando el Equipo siente que el trabajo es demasiado duro
¿Quién puede cancelar un sprint?
PRODUCTOS - PRODUCT BACKLOG
Product Backlog
El Product Backlog es una lista ordenada de todo lo que debe contener el producto (Solución).
Cualquiera puede sugerir o añadir elementos al Product Backlog, sólo el Product Owner los valida.
PBI: Producto Backlog Items
El PBI debe ser: Completo Ordenado Poco detallado
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
ALTA PRIORIDAD
BAJA PRIORIDAD
Taller de Requerimientos
Historias de Usuario
Product BackLog
Product Owner
SCRUM Master
Sprints Iteraciones
Artefactos (Tantos como
sea Necesario)
a
Nombre de la Historia de Usuario
Descripción de la función o servicio desde la perspectiva de un rol.
Prioridad Propietario
Esfuerzo Estimado
Categoría
*Notas: Descripciónón de Notas o Comentarios
a
Criterios de Aceptación
Descripción de los Criterios que hacen Válida y/o Completa la Historia de Usuario
*Notas: Descripción de Notas o Comentarios
Historias de Usuario
Historias de Usuario
Es importante redactar de manera corta y concreta la funcionalidad, servicio o capacidad que requiere el cliente utilizando su jerga.
Representan un acuerdo entre el product owner y el dev team
Realizar las siguientes consideraciones:
Criterios INVEST Independiente.- una historia debería ser independiente de otras.
Negociable.- una historia es negociable, no incluye detalles.
Valiosa.- cada historia debe de tener valor.
Estimable.- una historia de usuario deberá ser clara para una posterior
estimación.
Small (pequeña).- generalmente representan un sólo escenario.
Test (comprobable).- una historia necesita ser medible y comprobable.
Identificación de Requerimientos
Instrucciones:
Reunirse en equipos.
1. Leer el caso de estudio.
2. Identificar los requerimientos.
3. Priorizar los requerimientos.
4. Ordenar los requerimientos.
Actividad
Ordenamiento de las HU
El ordenamiento debe ser por valor de negocio y secuencia
**Se puede invitar a los Stakeholders
Técnica: MoSCoW
Must Have – Se debe tener la característica, es crítica!
Should Have – Requerimientos importantes pero NO cruciales para el reléase.
Could Have – Requerimientos deseables pero no necesarios para el reléase.
Wont Have – Los menos críticos para el producto, “agradables” pero prescindibles, a veces incluso no alineados a la estrategia del producto.
Técnica: MosCow
Instrucciones:
Reunirse en equipos.
1. Leer el caso de estudio.
2. Identificar los requerimientos.
3. Priorizar los requerimientos.
4. Ordenar los requerimientos.
Actividad
EVENTOS - SPRINT PLANNING
Product Backlog
Condiciones del Negocio
Tecnología
Producto Actual
Capacidad del Equipo
¿Qué se hará? • Analizar y evaluar el Product
Backlog • Seleccionar el Objetivo del Sprint • Elegir Backlog items
¿Cómo se hará? • Decidir como alcanzar el objetivo
del Sprint • Crear el Sprint Backlog • Estimar Sprint Backlog en horas
Objetivo del Sprint
El trabajo detallado
Sprint Planning Meeting
Sprint Planning Meeting
Dividir la reunión en dos
Time box de 4 horas cada sesión.
En la reunión de planeación se espera tener como resultado lo siguiente:
Definir Meta de Sprint
Definir duración de Sprint
Definir historias del
Sprint
Asistentes:
• Product Owner • Development Team
Sprint Planning Meeting
Product Backlog
Condiciones del Negocio
Tecnología
Producto Actual
Capacidad del Equipo
¿Qué se hará? • Analizar y evaluar el Product
Backlog • Seleccionar el Objetivo del
Sprint • Elegir Backlog items
¿Cómo se hará? • Decidir como alcanzar el
objetivo del Sprint • Crear el Sprint Backlog • Estimar Sprint Backlog en
horas
Objetivo del Sprint
Decidir QUÉ
2 3 4
** Pasos reunión Sprint Planning Meeting 1.
Decidir QUÉ
Criterios PBI PBI Significa “Product Backlog Items” y son un determinado número de elementos del PBI seleccionados por el Development Team considerando los siguientes criterios:
Objetivo del Sprint
¿Por qué vale la pena este esfuerzo?
Será necesario desarrollar una narrativa pensando en futuro que justifique todo el esfuerzo que se hará en el Sprint.
Técnica: Planning Poker
Instrucciones:
Estima el tamaño de las historias de usuario y desarrolla un draft de planeación del 1er sprint basado en la técnica de planning poker
Actividad
Sesión 1 Sprint Planning Meeting
La reunión termina cuando tenemos lo siguiente:
1
2
3
Objetivo del Sprint
PBI Seleccionado
Scrum Team de acuerdo
Sesión 2 Sprint Planning Meeting
Product Backlog
Condiciones del Negocio
Tecnología
Producto Actual
Capacidad del Equipo
¿Qué se hará? • Analizar y evaluar el Product
Backlog • Seleccionar el Objetivo del
Sprint • Elegir Backlog items
¿Cómo se hará? • Decidir como alcanzar el
objetivo del Sprint • Crear el Sprint Backlog • Estimar Sprint Backlog en
horas
El trabajo detallado
Decidir CÓMO
1 2 3
**Pasos reunión Sprint Planning Meeting 2.
PRODUCTOS - SPRINT BACKLOG
Atributos SBL
Atributos del Sprint Backlog:
Sprint Backlog Es en lo que hemos acordado hacer durante el Sprint.
Elementos del PB acordados
QUÉ
No Iniciado En Progreso Completado
CÓMO
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Características Sprint Backlog
1. Contiene el desglose de lo que se tiene que hacer a detalle a partir de las historias que se encuentran en el Product Backlog.
2. Entrega un resultado de valor para el Product Owner durante un tiempo delimitado llamado “Sprint”.
3. No se asignan las tareas a los miembros del equipo.
Detallando Historias en Tareas
H1 H2
H3 H4
T1 T3 T2
Historias
T1 T3 T2 Tareas
Las historias son desglosadas en tareas que pasarán a ser parte del Sprint Backlog.
Detallando Historias en Tareas
Product Owner
H H
H H
Historias:
Responsable
Development Team
T T T
T T T
Tareas:
Responsable
Sprint Backlog
Suma de esfuerzo de las historias debe ser < = Capacidad del Equipo.
Ordenando en función de lo que se realiza primero o es más importante
Delimitación
** Investigar sobre el concepto de WIP = Work in Progress de LEAN
Sprint Backlog
Instrucciones:
Juntarse en equipos.
• Detallar las tareas de las 3 Historias de Usuario mas prioritarias del PB.
• Estimar el esfuerzo.
• Crear el Sprint Backlog. Actividad
Ordenamiento
Deposit Migration
Tool Back Office
Login Withdraw
Back Office User Admin
Más importante Menos importante
Las historias y tareas pueden publicarse en la pared, lo cual hace más interactiva la planeación. El uso del tablero ayuda a que el equipo se sienta más involucrado. Los tableros y elementos que se pegan en la pared tienen la intensión de comunicar y generar Visibilidad en el equipo, se conocen comúnmente como “Radiadores de Información”
Ordenamiento - Cont
Deposit Migration
Tool Back Office
Login Withdraw
Back Office User Admin
Más importante Menos importante
T T
T T
T T
T T T T T
T T
Ordenando Elementos
Instrucciones:
Juntarse en equipos.
• Ordena los elementos del Sprint Backlog.
Actividad
Recomendaciones Se pueden realizar sprint largos hasta de 1 mes. (no
mas de eso)
Las fechas NO se recorren.
El equipo está en modo de aprendizaje
siempre!
El equipo debe ser humilde con sus estimaciones.
El alcance puede variar pero no el tiempo.
Duración:
Sesión 2 Sprint Planning Meeting
La reunión termina cuando tenemos lo siguiente:
1
2
Compromiso del equipo
El Sprint Backlog**
** el SB suficiente para que el Dev Team pueda crear su mejor previsión de lo que realizará, y lo suficiente como para poder trabajar en el Sprint por varios días.
DoD - Criterio de Terminación del Sprint
Se debe de llegar a un acuerdo en cuanto al significado de “Terminado” en el Sprint. Los responsables son el Product Owner y el Development Team
Definition of Done
Cada equipo es responsable de establecer los criterios de aceptación de cuando o cómo se considera que una HU está completamente terminada.
Este conjunto de criterios se les conoce como “Definition of Done” (DoD)
DoD es dinámico y es esperado que conforme el producto vaya evolucionando sprint tras sprint, así también pueda evolucionar el DoD.
En multi-equipos trabajando en el mismo producto cada equipo podrá contar con un DoD pero que en conjunto resulte en un DoD que potencialmente sea implementable.
Un ejemplo de elementos que pueden estar incluidos en DoD:
• Estimar el volúmen Generar Documento de Arquitectura
• Pasar criterios INVEST Hacer pruebas de integración
• Escribir código, Hacer notas del release
• Hacer pruebas unitarias etc.
Definition of Done
Algunas consecuencias de no tener bien definido un DOD:
El Dev Team no sabrá cuántos PBIs podrá hacer en un Sprint
El Product owner no sabrá que revisará en el Sprint Review
El Product owner será incapaz de medir el progreso de sus objetivos
El Dev Team no sabrá el trabajo implicado en completar los PBIs seleccionados
Tablero de Control
Kanban Board
Kanban Board
EVENTOS - DAILY SCRUM
DAILY SCRUM
3 Preguntas importantes:
• ¿Qué hiciste ayer? 1
• ¿Qué vas a hacer hoy? 2
• ¿Qué problemas has tenido? 3
DAILY SCRUM - Cont.
Todos los días en un mismo lugar a una misma hora.
Timeboxing 15 minutos
Se recomienda permanecer de pie durante la sesión.
No es para solución de problemas (Estos pueden anotarse para su posterior solución).
Sólo los miembros del SCRUM TEAM (Development Team, Scrum Master y Product Owner) pueden participar.
Los únicos requeridos en la reunión es el Dev Team.
Características:
DAILY SCRUM - Cont.
Es posible identificar riesgos y sugerencias/acciones para mitigarlos, confrontarlos o evitarlos.
Es importante que las actividades que se hayan hecho o se vayan a realizar se comuniquen a todos los miembros del Dev team.
Es responsabilidad de cada miembro transmitir, responder y clarificar las dudas o comentario que pudiese surgir durante el daily.
Usualmente es útil tener Kanban board físico y/o electrónico durante la reunión y actualizar los avances.
Adicionalmente:
MONITOREO DEL PROGRESO
Seguimiento tradicional vs SCRUM
El seguimiento tradicional en los proyectos se da enfocado al tiempo que ya se ha trabajado. En Scrum se ve el avance mediante el tiempo que queda para terminar. De esta manera tenemos la oportunidad de recalcular el plan de trabajo y la rapidez con que hacemos el trabajo. Así, el equipo puede decidir si trabajar más rápido o más lento para lograr el objetivo de la fecha.
VS
¿Y qué es el BURNDOWN Chart?
Un tipo de gráfica de volumen de trabajo pendiente a lo largo del tiempo que muestra la velocidad a la que se está completando los objetivos/requerimientos.
Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado.
El objetivo principal es estimar y aprender no necesariamente incrementar la velocidad.
El BURNDOWN es..
Gráfica de Burndown
Valor pendiente para completar los requerimientos del producto o proyecto (product burndown chart), realizado a partir del Product Backlog.
Horas pendientes para completar las tareas de la iteración (sprint burndown chart), realizado a partir del Sprint Backlog.
Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:
Gráfica de Burndown
Para nuevos requerimientos la línea de progreso será descendente
La línea de progreso debe ser descendente hasta llegar al eje de las X’s.
Si existen cambios la pendiente variará o podrá valer 0.
Para tener un seguimiento cercano se recomienda actualizarlo diariamente.
Algunas Características:
La Gráfica del BURNDOWN Esta grafica en su eje “X” se refiere al tiempo y representa la duración de un Sprint (Días).
En su eje “Y” se refiere al volumen de tamaño (trabajo) que queda pendiente en un Sprint.
Desviación
La desviación se representa mediante un grafico de avance que se aleja ya sea positiva o negativamente de la diagonal de lo planeado(Ideal).
Sabemos que avanzamos si el número de horas de esfuerzo disminuyen
EVENTOS - SPRINT REVIEW
SPRINT REVIEW
Demostración de producto completado (Sprint Review) Se lleva acabo al final del Sprint
Time box de 4 horas para un Sprint de un mes.
Se presenta el objetivo del Sprint.
La sesión va intencionada a revisar el producto y relacionarlo a la definición de terminado(DoD).
Se revisa el avance logrado (PBDC).
Los involucrados (clientes) deben Inspeccionar el producto.
Mencionar errores solucionados.
Se identifican cambios.
SPRINT REVIEW
El cliente ve un avance temprano del producto y así dar retroalimentación. El equipo puede ver si entendió realmente los requerimientos iniciales. El equipo no esta meses trabajando sin poder mostrar su producto. Se puede identificar de que manera mejorar la comunicación entre el
equipo y el cliente. Se integran nuevos cambios de ser necesario.
Beneficios
EVENTOS - SPRINT RETROSPECTIVE
Sprint Retrospective
Mejorar la comunicación del equipo.
Identificar todas las lecciones aprendidas del Sprint.
Mejorar el proceso.
Obtener el compromiso de todo el equipo.
Incrementar la creatividad del equipo.
Esta reunión es para..
¿Cómo llevar la reunión?
Tiene un Timeboxing de no más de 3 horas.
Se realiza al termino de cada Sprint.
El Scrum Team participa.
El Scrum Master funge como facilitador de la sesión.
Reconocer logros.
Reconocer que se puede mejorar.
NO es una sesión de culpabilidad ni señalamientos.
Planificar hallazgos, ejecutar y dar seguimiento.
¿Cómo llevar la reunión?
¿Qué hicimos bien y como queremos mantenerlo?
¿Qué no hicimos tan bien y qué hacemos para solucionarlo?
Preguntas que nos hacemos en la reunión:
Sprint Retrospective
¿ QUÉ HICIMOS BIEN ? ¿ EN QUÉ PODEMOS MEJORAR ?
Comprendiendo y Practicando todo Instrucciones:
Juntarse en equipos de 3-5 personas.
• Leer el Caso del Desarrollo del prototipo del Juguete (Monstruo).
• Leer las HU (Funciones, Criterios de Aceptación, Valor de Negocio )
• Construir y Desarrollar el Juguete tomando como base lo aprendido al momento. Actividad
Caso de Estudio
Centro de Renta de Películas: “Videorama” Requerimientos 1-2 El centro de renta “Videorama” te ha dado la labor de desarrollar un sistema para automatizar todas
sus operaciones, ya que con gran frecuencia se pierde el control de las películas, y estas se extravían. Es necesario considerar que el centro de renta no tiene mucho presupuesto para el desarrollo o para la compra de equipo físico caro.
Uno de los comentarios que ha hecho el dueño, es que sería bueno que los clientes pudieran
consultar el catálogo de películas y reservarlas desde internet. Esta solicitud se debe a que en fines de semana y en época de vacaciones, la sucursal se satura de clientes, ocasionándoles molestias por las colas que se forman a la hora de rentar/liquidar.
El centro de renta tiene un encargo de anotar las películas que se rentan y son devueltas, así como de
llevar un inventario de las nuevas adquisiciones (nuevas películas). Uno de los procesos que se debe automatizar es la renta de las películas a los clientes.
El centro de renta tiene tres tipos de membresías, “Socio”, “Socio Distinguido” y “VIP”. Los clientes
con membresía “Socio” pueden rentar 1 película y la siguiente es gratuita, esto por un periodo de 3 días, mientras que los “Socios Distinguidos” rentan 3 películas y se llevan 2 gratis a parte de recibir unas palomitas de cortesía. Los clientes “VIP” aparte de compartir las promociones del “Socio Distinguido” tienen derecho a 1 estreno gratis por mes.
Centro de Renta de Películas: “Videorama”
Requerimientos 2-2 Las rentas devueltas fuera de la fecha límite de entrega, generan un cargo a la
cuenta del cliente.
Cada día de retraso, se debe registrar en el sistema de adeudos, se debe además enviar un aviso por correo electrónico indicando tanto el retraso como el adeudo del cliente. Finalmente por cada película no entregada se reduce en uno el número de películas que tiene derecho (6) a rentar al mismo tiempo, durante una semana.
Los clientes con más de 2 adeudos, pierden el derecho de rentar más películas
hasta que liquiden o negocien el adeudo pendiente.
El empleado de la tienda puede ayudar al cliente en la búsqueda y disponibilidad de las películas. La búsqueda se puede realizar por nombre de la película, director o categoría. La búsqueda debe ser rápida (no debe tardar más de 4 segundos).
• Al rentar una o varias películas, el cliente recibe un comprobante indicando los datos de la película y la fecha de devolución. Al regresar las películas rentadas, el cliente recibe un comprobante describiendo las películas que tiene pendientes de devolver, así como la fecha en que cada una de estas deben ser devueltas.
• Las películas podrán ser reservadas a través de internet cuando se encuentren disponibles, es decir, que no se encuentren en préstamo. En caso de que se encuentren rentadas, se mostrará un aviso al cliente indicando la fecha en que la película se encuentre disponible.
• El cliente tiene la opción de indicar al sistema por internet el envío de avisos por email cuando una una película deseada ya se encuentre disponible
• La reservación de la película se mantendrá durante tres días a partir de que haya sido devuelto por el cliente que la tenía.
• Los clientes están dados de alta en el sistema de clientes con toda su información
Centro de Renta de Películas: “Videorama”
Anexos
Historia de SCRUM Fecha Personaje Aportación
1986 Hirotaka Takeuchi e Ikujiro Nonaka
Aproximación holística para desarrollo de nuevos productos comerciales, hacen referencia al rugby como ejemplo de juego en equipo
1991 De Grace y Stahl Wicked Problems, Righteous Solutions (aproximación SCRUM)
90´s Ken Schwaber Advanced Development Methods
90´s Jeff Sutherland Easel Corporation (primero en denominar una aproximación al framework “SCRUM)”.
1995 Sutherland y Schwaber Scrum (producen serie de artículos describiendo SCRUM)
2001
2002
Schwaber y Mike Beedle Ken Schwaber and Mike Cohn
Agile Software Development with SCRUM (describieron la metodología en este libro). SCRUM Alliance
2010 Ken Schwaber Busca combatir las debilidades de SCRUM, al tener diferencias con SCRUM Alliance crea SCRUM ORG.
Release Burndown ya no es parte del Framework
Pigs and Chickens… the lore of Scrum
Se redefine el Sprint Backlog
El compromiso se cambia por previsión
El Team ahora será conocido como Development Team
Ordenado en lugar de priorizado
Product and Sprint Backlog Burndown, se cataloga como técnica
/producto específico para dar seguimiento
Cambios SCRUM 2016
Microsoft Yahoo Google Electronic Arts Hicg Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit
Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Boradcasting OCE
Empresas que han usado SCRUM
• Competitiva • Desarrollo
• Jerárquica • Colaborativa
Criterios de Aplicación SCRUM en una Cultura Org => SHIFT MIND!!!
Conforme a la teoría desarrollada por Abraham Maslow en 1943, las necesidades y expectativas de una persona corresponden a la siguiente jerarquía:
Criterios de Aplicación SCRUM Teoría Maslow
Criterios de Aplicación SCRUM
Épicas, Temas (Features) e HU • Durante los principales eventos y/o momentos de descubrimiento, las HU que se
detecten podrán tener diferentes tamaños, niveles de abstracción y/o prioridades.
SPRINT (2-3)
RELEASE
RELEASES FUTUROS
Historias de Usuario
(días)
Features / Temas (semanas)
Épicas (meses)
+
Det
alle
Épica Tema/Feature HU 1..* 1..*
Algunas Métricas Ágiles útiles
Esfuerzo ideal colectivo sobre unidad de tiempo seleccionada.
Capacidad del equipo:
# tareas plan / (# tareas plan + # tareas no planeadas)
Eficiencia de Planeación:
Tamaño (O Volumen) colectivo logrado sobre la unidad de tiempo seleccionada:
Ejem: En el 1er sprint de 2 semanas se hizo una historia de usuario de 5 puntos otra de 6 puntos y otra de 9 puntos, la velocidad hasta ese momento es de 20 puntos / cada 2 semanas.
Velocidad
CALIDAD EN SCRUM El Testing nos ayuda a validar que lo que se solicito como un requerimiento se este cubriendo en el sistema.
Pruebas de Software común:
Pruebas Unitarias
Pruebas Funcionales
Pruebas de Regresión
Pruebas de Humo
**Las pruebas nos ayudan a conocer la salud del proyecto y a decidir si liberar o no el producto.
CALIDAD EN SCRUM
Estructura de Equipo Tradicional Estructura de Equipo Ágil
Programadores
Analista Tester
Programadores
Analista Tester
Requerimientos
Especificaciones
Código
Pruebas
Despliegue
Testing Tradicional
Tiempo
Cascada
Testing Ágil
sprint 0 sprint 1 sprint 2 sprint 3
A B A B
C
D
A B
C
D
E
F
Ágil:
Iterativo e Incremental
Cada historia es expandida, codificada y probada.
Posible release
después de cada sprint.
Calidad
Realizar menos desarrollo en cada Sprint para incluir pruebas.
Si la calidad es importante en el Sprint:
Siempre es más barato producir menos y hacerlo estable, que hacer mucho pero con menos calidad.
=> DEUDA TÉCNICA !!!!!
Calidad
DEUDA TÉCNICA
Refleja el trabajo de desarrollo extra que surge cuando el código u otra actividad es más fácil de implementar o de ejecutar en lugar de desarrollar o ejecutar la mejor solución. La deuda técnica no atendida incrementa la entropía del software.
Calidad – Deuda Técnica
DEUDA TÉCNICA
• Estructuras de Datos apropiadas • Diseño • Arquitectura • Refactorización • Uso de Patrones de Diseño • Documentación de Código • Estándares de Código
Diferentes aspectos, NO sólo son pruebas funcionales!!!
• Glosarios • Pruebas Unitarias • Pruebas de Carga • Pruebas de Volumen • Análisis de Código • Control de Cambios • Análisis de Desempeño • Análisis de Consumo de
Memoria
Imprudente, Temerario Prudente
Inadvertido, desatento
Deliberado, intencionado, reflexivo
Calidad – Deuda Técnica...posturas
No hay tiempo para diseñar, Es demasiada documentación, eso dejémoslo para después
Debemos salir para el viernes, Aceptemos los riesgos, Registrémoslos, y tomemos nota de los posibles impactos
¿Qué es un microservicio?
Bueno, al menos ahora sabemos como debimos de haberlo hecho
TCO Costo a lo largo del ciclo de
vida del software
Calidad – Deuda Técnica
Deuda Técnica vs
Valor de Negocio
Lo que comúnmente sucede..
Sprint 1 Sprint 2
1.0.0 1.1.0
Usuarios Finales
1.0.1
Propuesta 1
Sprint 1 Pruebas Sprint 2 Pruebas Sprint 3
Tiempo
Se añade un periodo de pruebas entre los Sprints en el que solo se ejecutarían pruebas y correcciones.
Tiempo Extra Tiempo Extra
** No se inicia el siguiente Sprint hasta que no este en producción
Propuesta 2
Sprint 1 Sprint 2 Sprint 3
Tiempo
Se realizan pruebas durante el Sprint pero adicional al final se añade un periodo de pruebas en el que todo el equipo se enfoca en probar y corregir.
Pruebas Todo el equipo
Pruebas Todo el equipo
Pruebas Todo el equipo
Cambios
Costo de continuar el proyecto > valor agregado.
Para detener el Sprint:
El cliente puede incluir cambios al Sprint mientras estos no afecten el alcance del Sprint o elimine elementos del mismo alcance del contrato.
Change For Free:
Cambios normales:
Requerimientos nuevos con valor de negocio se incluyen por el Product Owner al Product Backlog.
