SCRUM MASTER CERTIFIED

PRE-SCRUM

• PROCESO: secuencia de actividades interrelacionadas que transforman insumos (materia prima) en productos.
• TEOREMA DE PARETO: regla del 80-20, con base al conocimiento empírico: el 80% del esfuerzo en el desarrollo construye el 20% del código.
• PROYECTO: 
• Características
• Se ejecuta una vez
• Recursos ilimitados
• Tiene un inicio/fin bien definidos

• SOLUCIONES SIMPLES EN MANUFACTURA:

• KANBAN: 
• apoyos visuales
• sistema de tarjetas
• KAIZEN: 
• ciclo infinito de mejora continua; toda la función está en el hacer
• Planear => Hacer => Verificar => Actuar
•  LEAN: filosofía de cero desperdicio; en el software se traduce a: 
• Recursos no utilizados
• Defectos
• Re-trabajo
• Atraso
• Incumplimiento
• ANDON: sistema de semáforo

• MANIFIESTO ÁGIL: descubrir formas de mejorar el desarrollo de software. Son 12 principios pero los 4 principales son:

• Individuos e interacciones sobre procesos y herramientas: se traduce a centrarse en las personas que al final son quienes ejecutan los procesos y herramientas
• Software que funciona sobre documentación exhaustiva: se traduce a el objetivo es entregar software funcional.
• Colaboración con el cliente sobre negociación de contratos: es bueno tener contratos pero es aún mejor estar en constante colaboración con el cliente.
• Responder al cambio sobre seguimiento de un plan: la única constante es el cambio, RESPONDE AL CAMBIO

•  DESARROLLO ÁGIL: tratar de dejar los reportes y  mostrar el software funcional. Toda metodología ágil debe ser:

• Flexible
• Debe responder al cambio

• TIPOS DE CULTURAS ORGANIZACIONALES

• Colaborativa: 
• Hay un líder
• Hacer sinergia
• Se hace una mejora continua
• Jerárquica: 
• El del mando es asignado (regularmente)
• Todo es en base al control
• Desarrollo 
• Los que están a cargo funjen como coach
• Filosofía de trabajo es mediante el mentor-ing
• Los errores son tomados como lecciones aprendidas
• Competitiva: 
• El que sobresale es el mejor
• El fin justifica los medios
• Degradación

• MODELO EMPÍRICO: se recomienda cuando es un sistema caótico; los requerimientos son muy cambiantes.

• DEUDA TÉCNICA: consecuencias de un desarrollo apresurado
• ELEVATOR PITCH: responder a lo siguiente

• nombre: <nombre, alias>
• para: <mercado, usuarios finales, clientes>
• que tiene: <necesidades, problemáticas, deseos>
• podemos: <solución, características del producto/servicio>
• a diferencia de: <competidores, as is>
• nosotros: <valor agregado, diferenciadores>

• CANALES de comunicación: crece exponencial mente conforme al numero de participantes:
• Kcanales=n(n-1)/2

SCRUM 

• DEFINICIÓN: 
• Marco de trabajo dentro del cual se pueden atender problemas complejos
• Proponiendo soluciones creativas y productivas con el fin de entregar productos de mayor valor posible.
• Es una estructura con la que podemos empezar; se le pueden agregar más funcionalidades.
• SCRUM se basa en el EMPIRÍSMO 
• El proceso de SCRUM es iterativo; por medio del SPRINT 
• Sirve para problemas complejos 
• SCRUM no es una norma ni un estándar
• SCRUM es:

• LIGERO
• FÁCIL DE ENTENDER
• DIFÍCIL DE DOMINAR

• SCRUM es útil para:

• Trabajar con requerimientos cambiantes
• Donde se necesita obtener resultados pronto.
• Proyectos en entornos complejos

• EMPIRISMO: el conocimiento es en base a la experiencia. Se basa en
• Transparencia (Visibilidad)
• Inspección (Validación y Verificación)
• Adaptación (Mejora continua)
• VALIDACIÓN: ¿es el producto que pidieron?
• VERIFICACIÓN: ¿realmente está funcionando?
• SCRUM se basa en SPRINT's, funciona de manera colaborativa

• ELEMENTOS de SCRUM:

• ROLES de SCRUM: 
• Product Owner
• Scrum Master
• Development Team 
• ARTEFACTOS en SCRUM
• Product Backlog
• Sprint Backlog
• EVENTOS de SCRUM

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

• PRODUCT OWNER:

• Le importa el producto del negocio
• Lo que más le interesa es el producto y cuidar el negocio
• Debe entender el negocio
• Le interesa el ROI
• Cuida cuales son las características del producto
• Puede delegar sus tareas
• Debe tener visión 
• Puede representar a un comité pero NO puede ser un comité.
• Para ser Product Owner se debe reunir los conocimientos: 
• Sobre el producto/negocio
• ROI
• Características del producto (PB)
• Visión
• Empowerment (decisión) 

• DEVELOPMENT TEAM

• Le interesa el proyecto/trabajo
• Deben ser: 
• Auto-organizados
• Hacen las estimaciones
• Son multi-funcionales (al menos en la suma de los skill's sea igual a la realización del trabajo)
• Crean un incremento del producto "terminado" (definition of done)
• A todos los miembros del equipo se le llama DEVELOPER
• El tamaño ideal es mayor o igual a 3 y menor a 9 

• DEFINITION OF DONE: regularmente se ponen de acuerdo el Product Owner y el Scrum Master.

• SCRUM MASTER

• Características
• Es un coach de scrum 
• Es un facilitador de eventos
• No necesariamente tiene que estar en todas las reuniones
• Puede estar en más de un proyecto
• Resuelve impedimentos
• Identifica nuevas interacciones
• Elimina distractores
• Está al servicio de: 
• Product Owner
• Development team
• Organización
• Otros
• No necesariamente es técnico 
• Le interesa el proceso y eficiencia del equipo

• PRODUCT BACKLOG:

• Características
• Contiene todos los PBI (pruduct backlog item o conocidos como historias de usuario).
• Responsabilidad del Product Owner (sobre todo la parte de priorizar las historias de usuario, las puede delegar para que lo redacte otra persona
• Redacción en un lenguaje de negocio/funcional (NO Técnico)
• Tiene que estar "completo" (no literal)
• Siempre tiene que estar ordenado (priorizado) en base al 
• ROI
• Estrategia
• etc.
• Detallado lo necesario
• Cualquiera puede sugerir añadir elementos al product baklog, pero sólo el product owner los valida.

• HISTORIAS DE USUARIO

• Características
• Describe la funcionalidad que será valiosa para un usuario de un sistema o producto de software.
• Escrita en lenguaje NO técnico
• Debe durar menos de 1 Sprint
• Estructura:
• Como: <rol>
• Puedo: <acción>
• Para: <justificación>
• Comprobación: <criterios de aceptación>
• Conversación: <reglas de negocio, requerimientos no funcionales y otras funcionalidades>
• Las escribe el product owner
• Si cumple con las siguientes características es una buena historia de usuario: 
• Independiente
• Negociable
• Valiosa
• Estimable
• Small
• Test

• Puede haber historias de usuario NO técnicas, SÓLO de origen de investigación.
• Una historia de usuario es ÉPICA cuando: 
• Complex
• Unknow
• Risky
• Big
• Valores o métricas para una historia de usuario (beneficio & penalidad son en escala de 1-5, mientras que complejidad puede ser en base a serie fibonacci): 

• Las Épicas pueden ser de dos tipos:
• Compuestas
• Complejas

• Una historia épica son múltiples historias de usuario; por lo tanto hay que DIVIDIRLA

• VN: valor de negocio, se calcula en base a: 
• [(Beneficio*2) + Penalidad]*10
• ROI: retorno de la inversión, se calcula en base a: 
• VN/COMPLEJIDAD
• COMPLEJIDAD: mide que tan complejo es desarrollarlo, se puede medir en base a serie fibonacci (planning poker).

• SPRINT BACKLOG:

• Características
• Responsabilidad del development team
• Plan técnico detallado para crear un IPT
• Sprint backlog item (unidad) es igual a: 
• historias del Sprint + tareas
• Tareas incluye todos los dominios, de preferencia solo sustantivos, estimación en horas de preferencia cada tarea no mayor a 8 horas, para darle flujo al tablero.
• Se tienen que tener definidas las tareas antes de que empiece el SPRINT
•  Con palabras como sustantivos para describir la tarea
• Tareas deben ser menos a 8 horas
• ESFUERZO = TIEMPO

• SPRINT:

• Características
• Es el contenedor de los 4 eventos de scrum
• El objetivo es crear un IPT
• Hay que tener un sprint goal (must)
• El product owner puede cancelarlo
• Cuando el sprint goal es obsoleto
• El valor (costo $) de continuar es mayor al valor esperado.
• Duración del sprint de preferencia menor o igual a 1 mes
• Hay que entregar valor en cada sprint

• SPRINT PLANNIG:

• Características:
• Para ponernos de acuerdo que vamos a entregar al final del sprint.
• ¿CÓMO? lo vamos a hacer
• No es necesario que esté el product owner
• Separar en tareas (y a su vez en horas cada tarea) el esfuerzo
• Estimar el esfuerzo total (la sumatoria de todas las horas de las tareas)
• El esfuerzo total debe ser menor o igual al esfuerzo real. 
• Se puede re-negociar con el product owner si se dan cuenta que la historia de usuario es muy compleja.
• Compromiso por parte del cliente

• Entrada: Product Backlog (ordenado)
• Roles: participando
• Product Owner
• Development Team
• Scrum Master: solo para asegurarse que se lleva a cabo SCRUM
• Stakeholders: para pedir su información/opinión

• Timeboxing: 8 horas para sprints de 1 mes
• Si ya hay historial de sprint's entonces se tiene
• Capacidad
• Velocidad
• la sesión se divide en: 
• ¿QUE? vamos a hacer
• Con base a las historias 
• Hay que negociar las historias de usuario 
• En base a las historias, seleccionadas, se crea el objetivo (sprint goal). 
• Si es necesario que esté el product owner
• Salida

• Sprint Backlog
• Sprint Goal

• BURN DOWN: herramienta para ver el progreso

• Es a nivel de sprint por lo tanto para el sprint N, se tiene el Burn down N
• Para ver el trabajo restante
• En cualquier momento se actualiza
• El Development Team se encarga de actualizarlo
• El burn down con puntos de historia NO es bueno porque complejidad y tiempo NO empatan.
• En el eje de las x's van los días
• En el eje de las y's van las horas (esfuerzo)

• BURN UP: 
• Para visualizar el trabajo conseguido. Mide la velocidad del equipo en base a los SPRINT (historial).

• En el eje de las x's van los SPRINT (ej. SPRINT 1, 2, N)
• En el eje de las y's van los puntos de historia (complejidad, osea fibonacci)

• DAILY SCRUM:

• Entrada: trabajo realizado del día anterior
• Roles: participando; Development Team
• Timeboxing: no más de 15 minutos.
• Preguntas a responder (tomando en cuenta o relacionado con el sprint goal): 
• ¿Qué hice ayer?
• ¿Qué haré hoy?
• ¿Qué problemas hay?
• Salida: sincronización del trabajo
• Todos deben estar de pie, misma hora, mismo lugar, respeto y apertura

• SPRINT REVIEW:

• Entrada: IPT (incremento de producto terminado).
• Roles: participando;
• SCRUM TEAM
• Stakeholders
• Timeboxing: tiempo menor o igual a 4 horas para sprints de 1 mes.
• Se hace demo del IPT resolver preguntas (en base a funcionalidad del demo).
• Nos pueden dar retro-alimentación. 
• Se hace una proyección de los siguientes sprints
• Salida

• un ipt (validado)
• pueden salir cambios

• SPRINT RETROSPECTIVE:

• Puede decirse que para mejora continua
• Entrada: trabajo de todo el sprint
• Roles: participando
• Scrum Team
• Timeboxing: aproximadamente 3 horas para sprint's de 1 mes
• Responder a las siguientes preguntas: 
• ¿Qué hicimos bien? ¿como nos mantenemos?
• ¿En que podemos mejorar? ¿como lo hacemos? 
• Evaluar: a las personas, comunicación, organización, proceso, trabajo, herramientas.
• Salida: acciones correctivas, planes de mejora.

• MÉTRICAS: 
• Velocidad del equipo, es el número de puntos de historia hechos por sprint.

• Complejidad=tamaño (que es igual a puntos de historia)
• Capacidad=esfuerzo/tamaño, que es igual a: 
• Hrs/P.H
• Eficiencia de planeación: 

• #tareas planeadas/(#tareas planeadas + #tareas no planeadas) 
• Estimación de esfuerzo 
• fórmula: 
• ER=F.D * EI
• ejemplo
• F.D: factor de dedicación, en porcentaje
• si no se tiene historial, se puede empezar con 70%
• EI: esfuerzo ideal
• #hrs laborales * días del sprint * #personas
• ej. 8hrs * 10 dias * 5personas= 400 hrs.

• ER: esfuerzo real, es igual a
•  0.70 * 400 = 280 hrs.