• Analogía del Rugby - Equipos Autogestionados
• Los involucrados son quienes toman las decisiones
• Que hacer
SCRUM • Cómo hacer
• Scrum Como Marco de referencia fue fundado por
• Ken Schwaber
• Jeff Sutherland
• Cuando se hablo por primera vez de scrum
El concepto de Scrum tiene su origen en un estudio de 1986 [1] sobre los nuevos procesos de desarrollo utilizados en
productos exitosos en Japón y los Estados Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de
Honda, ordenadores de HP y otros).
Los equipos que desarrollaron estos productos partían de requisitos muy generales, así como novedosos, y debían salir al
mercado en mucho menos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguían patrones
de ejecución de proyecto muy similares.
En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la
colaboración entre los jugadores de Rugby y su formación de Scrum
• Cuando se creo el primer equipo de scrum
La primera vez que se usó Scrum fue en 1992 en la empresa Easel Corporation, si bien el verdadero origen de la aplicación
de Scrum al mundo del software está en el libro «Wicked problems, righteous solutions», de de Grace y Sathl, del año 90,
inspirados por famoso artículo de Takeuchi y Nonaka del 86
En 1993 se realizó el primer Scrum para desarrollo de software [2]
Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron, ejecutaron y documentaron el primer Scrum para
desarrollo ágil de software en 1993, utilizando el estudio de gestión de equipos de Takeuchi y Nonaka como base
Scrum
En 1986 dos expertos en gestión japoneses, Hirotaka Takeuchi e Ikujiro Nonaka, publicaron un artículo en la Harvard Business Review titulado New New
Product Development Game. Este paper versaba sobre un nuevo enfoque mejorado de desarrollo de productos comerciales.
Como inspiración usaron los procedimientos de varias empresas que destacaban especialmente entre su competencia, concretamente Fuji-Xerox, Canon,
Honda, Nec, Epson, Brother, 3M y Hewlett-Packard.
En ese artículo, Takeuchi y Nonaka utilizaron como símil de un equipo de desarrollo cohesionado la típica formación en melé de los equipos de rugby,
donde los jugadores hacen piña para avanzar frente al equipo contrario y obtener el balón
El primer artículo sobre Scrum se presentó al taller (workshop en inglés) Business Object Design and Implementation Workshop celebrado durante la
conferencia OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) en 1995. Ojo que no se presentó a la propia OOPSLA y este
artículo no sale en sus actas oficiales. En este taller, los artículos tenían una extensión de 2-3 páginas
Después del taller, los organizadores les pidieron a sus participantes que escribieran versiones ampliadas, y así, el artículo de 3 páginas de Scrum se
convirtió el 5 de abril de 1996 en el artículo de 23 páginas que aparece en el libro del taller y que está colgado en la red.
Aunque ese artículo se envió en 1996, hasta 1997 no publicaron el libro con los artículos extendidos del workshop de 1995.
Esto quiere decir que para citar correctamente el artículo, hay que usar la referencia del libro de 1997.
No se encuentran publicadas actas con los artículos originales de 1995. Hubiera sido interesante ver cómo explican Scrum en un artículo de 2-3 páginas.
Como curiosidad, el artículo lo firma solo Mr. Ken Schwaber, pero uno de los organizadores del workshop y editor del libro de artículos fue Mr. Jeff
Sutherland.
El enlace del taller: [Link]
Manifiesto Ágil: (2001)
Aparecen los conceptos
En 2001 un grupo de personas muy relevantes en lo que empezaba a ser el desarrollo ágil escribieron los valores
fundamentales de los procesos ágiles [4]
Relación entre:
Lean : es una estrategia de gestión y producción que se caracteriza por Maximizar el valor para el cliente mientras
se reduce el desperdicio. Comenzó siendo una técnica de fabricación de una marca japones de coche Toyota
convirtiendo a Japón en líder mundial en la industria automovilística. En los últimos años las técnica Lean se han
adaptado al software naciendo así el Lean Software Develpoment.
Ágil: Mentalidad con valores y principios
Scrum: Marco de referencia para manejar tareas complejas
(desperdicio, desigualdad y sobrecarga)
MUDA: Un desperdicio es todo aquello que consume recursos o Cualquier actividad que no agregue valor:
Generado por MURA y MURI
Ejemplo: Documentacion Excesiva
El más famoso de los tres males de la fabricación es el desperdicio (muda) Esto se divide comúnmente en los famosos
siete tipos de desechos:
[Link]
[Link]
[Link]
[Link] de procesamiento
[Link] y retrabajo
[Link]
[Link]ón (la peor)
Por supuesto, desde que Toyota desarrolló el concepto, se han agregado muchos tipos adicionales de desechos.
MURA: Algo que esta desigual , inconsistencia, imprevistos o tiempos muertos, Mura crea MUDA
Es cualquier tipo de irregularidad.
Aunque a menudo se usa principalmente para el flujo de material, también es un problema en muchos otros casos fuera
del flujo de material.
La siguiente es una lista de ejemplos en los que pueden ocurrir irregularidades y causar problemas:
• Demanda desigual del cliente
• Cambios de inventario: de demasiado a muy poco
• Velocidad de producción desigual o cantidades de producción cambiantes
• Calidad desigual de las piezas buenas (sin embargo, si la pieza falla o debe desecharse, es un desperdicio)
• Ritmo de trabajo irregular o irregular
• Formación desigual de los trabajadores.
• Distribución desigual de la carga de trabajo.
MURI: Sobre carga causado por MURA , Irracional, Excesivo, cosas demasiado dificiles. – demasiadas tareas a un
recurso o equipo (stress), Cuellos de botella
El enfoque principal aquí está en las personas.
Sin embargo, también puede aplicarse a materiales, máquinas y organizaciones. Aquí están algunos ejemplos:
•Personas
• Trabajando demasiadas horas (y sí, a menudo soy culpable de eso)
• Levantamiento pesado
• Postura inadecuada o ergonomía inadecuada
• ruido
• Tareas demasiado difíciles
• Tareas demasiado fáciles (que pueden ser aburridas o mentales)
• Estrés excesivo
• Cualquier cosa que conduzca a quemarse, desgastarse o lesiones por esfuerzo repetitivo
• Falta de entrenamiento
• Humillación, pero posiblemente también alabanzas excesivas.
• Tareas peligrosas, sucias y difíciles (3K en japonés)
•Organizaciones
• Exigir que el proveedor entregue lo que queremos cuando lo deseemos sin proporcionar una señal buena y estable de nuestro lado
• Abusar de su poder de mercado para vencer a proveedores o clientes (creo que esta tentación puede ser difícil de evitar para muchas
empresas en el mundo occidental)
•Maquinas y materiales
• Empujar máquinas y herramientas al límite de sus capacidades, lo que lleva a un mayor desgaste
• Omitir mantenimiento (puede omitir un cambio de aceite en su automóvil, pero no le gustará)
• Maltrato de materiales; mi. g., almacenamiento de piezas en condiciones inadecuadas
• Cargar un vehículo o contenedor más allá de sus límites de peso
Modelo de Aprendizaje – Arte marcial – Etapas de aprendizaje
SHU : Aplicar las regla sin modificación
HA: Romper la regla para ver lo que funciona
RI : Definir nuevas reglas
Ejemplo: Onboarding
Valores del Agilismo
Individuos e Software que Colaboración Responder al
Fuentes que lo Interacciones funciona con el cliente Cambio
expliquen par
amas contexto Procesos Y Documentación Negociación Seguimiento a
herramientas Exhaustiva de Contratos un plan
Individuos e interacciones sobre procesos y
herramientas
• Esto no quiere decir que en la agilidad no existen procesos y
herramientas, sino que se privilegia a las personas y las relaciones
entre ellas.
• En enfoques ágiles, son las personas quienes definen qué
herramientas y procesos usarán para interactuar, y no al revés, las
herramientas y procesos no están predefinidos antes de conformar
un grupo de personas.
• La comunicación cara a cara es más valiosa que si se realiza a través
de herramientas como teléfonos, correos o chats.
Software funcionando sobre documentación extensiva
• No somos enemigos de la documentación, siempre y cuando aporte valor. La
definición de valor a nivel de documentación, quiere decir que lo que se documenta
es extremadamente importante para la toma de decisiones, no por la falsa seguridad
de querer asegurar la historia del proyecto “por si se requiere en un futuro”.
• Se evitan los documentos que se utilizan como medios de comunicación, o como
evidencia de la comunicación. En su lugar se debe buscar una comunicación más
fluida y personal.
• Lo más importante siempre debe ser el producto funcionando por encima de
manuales y extensos documentos de requisitos.
• La medida de progreso en las metodologías ágiles es el producto utilizable y no
documentos o evidencias intermedias que se usan para llegar a ese producto
Colaboración con el cliente sobre negociación contractual.
• No significa que no puedan existir contratos, pero la relación con nuestros clientes o
usuarios no se debe basar en documentos sino en un contexto de confianza y
colaboración.
• Según The Chaos Report en 1994, una de las principales causas en las metodologías
tradicionales de que el 84% de proyectos fueran cancelados o desafiantes se debía a
falta de involucramiento de los usuarios del sistema.
• En un entorno de confianza entre usuarios y equipo de desarrollo, no es necesario
trabajar bajo contratos porque se entiende que los cambios que se soliciten se
hacen por un bien común. No hay intenciones ocultas que se deban evitar bajo
conversaciones por escrito
Respuesta ante el cambio sobre seguir un plan
• Existe un mito muy popular entorno al agilismo, donde se afirma que no se
planea. De hecho, la planeación para definir una hoja de ruta, alinearse como
equipo e identificar riesgos que se pueden prevenir, es un ejercicio positivo que
aporta valor.
• El plan que se defina, debe ser lo suficientemente flexible para que se puedan
incorporar cambios y replantear el resto del proyecto, a partir del feedback y las
lecciones aprendidas que se adquieren en la medida que se realizan
incrementos del producto.
Principios
A partir de los 4 valores anteriores, se generan los siguientes 12 principios del desarrollo de software ágil.
[Link] mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
[Link] que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio
para proporcionar ventaja competitiva al cliente.
[Link] software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo
más corto posible.
[Link] responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
[Link] 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.
[Link] 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.
[Link] software funcionando es la medida principal de progreso.
[Link] procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces
de mantener un ritmo constante de forma indefinida.
[Link] atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
[Link] simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
[Link] mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.
Propósito:
Mostrar el trabajo Restante / tiempo usado por
el equipo para su propia gestión
50
Puntos de historia del Sprint
40
30
20
10
Espejo que muestra el rendimiento del equipo/ que cerro y que no
1 2 3 4 5 6 7 8 9 10
Días del Sprint
Iteraccion SPRINT Proyecto
Responsable Team Desarrollo PO
Actualizado Daily Final de cada
Sprint 3 12
D 5 8 2
20
Que es un PBI, cual es dif con las tareas del día a día, donde se gerencia las tareas quien las gerencia, donde se gerencian los PBI
product backlog item son los elementos que componen del Product Backlog.
Estos elementos pueden variar desde especificaciones y requisitos, hasta casos de uso, épicas, historias
de usuarios, o incluso errores, bugs, o tareas de investigación de tiempo determinado.
[Link]
refinamiento-del-backlog
Cambio de Perspectiva – Chaos report – Tasa de Éxito de Proyectos
39% Exitoso: cuando cumple la triple restricción Tiempo, costo y alcance. 2 de cada 5
proyectos son exitosos
43% Parcialmente Exitoso: Sobrecostos, sobretiempo, Alcance no alcanzado
completamente
18% Falla: Proyectos cancelados
36% de los requerimientos cambian en un año, nuevos requerimientos, nuevas
tecnologías, nuevas legislaciones
20% uso de funcionalidad
Sprint -> Iterativo e Incremental
Algo que desde el inicio puede ser usado por el cliente
El Sprint esta protegido:
• Tiene una duración y el equipo se compromete a realizar una tarea,
• no se realizan cambios,
• los objetivos de calidad no disminuyen
• El alcance puede ser clarificado y renegociado entre el PO y el ED en la medida que va
aprendiendo mas
• Encajar el tiempo – TimeBoxing
• La duración del sprint es de 1 a 4 semanas,
• Si una tarea no se cumple en el sprint se deja para el siguiente
Definición de terminado
Solo lo que esta completamente terminado agrega valor
Valores de Scrum
• Compromiso: Comprometidos con el trabajo que hacemos, para que el tema de autoorganizado pueda funcionar
• Apertura: hablar cuando algo no funciona, retroalimentación de forma respetuosa
• Foco: Enfocados en el objetivo
• Coraje:
Visiona general del equipo Scrum
Roles
PO: define y prioriza los ítems que se definen y priorizan en el BL
Fechas de lanzamientos
Responsable de la rentabilidad del producto
SM: Facilita procesod escrum en el proceso y equipo
Elimina los impedimentos del equipo, efectividad del equipo
Equipo de desarrollo: responsable para entregar el valor de incremento del sprint es responsable de como trabaja el
sprint 3 a 9 personas
PO
Necesita :
Autoridad: para que pueda tomar las decisiones sobre la prioridad de los requisitos
Conocimiento: del producto y de las necesidades del cliente
Disponibilidad: que tenga tiempo
Tiene 2 frentes:
Cliente: entender al cliente
Equipo: Aclararle las dudas al equipo
Es responsable de :
• Encaminar el éxito del producto
• Crear la visión del producto
• Crea y mantiene el producto Backlog
• Colabora con el equipo
• Colabora con los stakeholders
• Participa en las reuniones de sprints
Es dueño de que:
• Pasar la otra mitad trabajando cerca del equipo
• Pasar la mitad de su tiempo con el cliente
• Tener una visión atractiva del producto que se pueda ejecutar
• Construir un mapa para desarrollar su visión
• Construir el Backlog
Autoridad para:
Expresar claramente los puntos del backlog
Backlog ordenado Ordenar los puntos para alcanzar metas y las misiones de una mejor manera
Valor Optimizado :Optimizar el valor que desempeña el equipo de desarrollo del [Link] valor para el cliente priorizado arriba y lo de menos valor abajo
Visible y Transparente. La información debe ser accesible para todos los integrantes
Entendida. Todos los integrantes entienden los puntos del backlog
SM
• Debe actuar como un agente de cambio
• Sirve al PO y al equipo
• Remover impedimentos
• Entrena al PO y al equipo
• Protege al equipo de perder el foco
• Guía y Protege el equipo
• El scrum Master es el dueño del proceso
• Facilita la retrospectiva
• Facilita la planeación del Sprint
• Facilita el scrum diario
Liderar sin autoridad (credibilidad)
2 frentes:
Confianza
• Ser confiable: lo que dice es lo que hace
• Valorar a las personas: respeto y apreciación por las personas
• Valorar el trabajo del equipo : respeto y apreciación por el trabajo realizado
Competencia
• Dar ejemplo
• Conocimiento: Amplio conocimiento del proceso Scrum
• Experiencia:
ED
• Autoorganizarse y es responsable como equipo
• Al final del sprint debe entregar el incremento del producto
• Administra el sprint backlog
• Rastrea el progreso del spring con el springbacklog
• Participa en las reuniones del sprint(planeación, revisión, daily y retrospectiva)
Autoridad
• Tiene el poder de tomar cualquier decisión requerida para alcanzar el éxito
• Tiene el poder de solicitar cualquier recurso que necesite (incluyendo entrenamiento adicional)
Trabajo en equipo
• De 3 a 9 personas
• Colaborativo
• Multifuncional
• Autoorganizado
• Auto Administrado (cuantos elementos van a trabajar y como lo logran)
Artefactos
Product backlog
• Única fuente del alcance del proyecto – única fuente de requerimientos
• Contiene todo lo necesario para cumplir con la visión del producto
• Lista ordenada de características, funciones, requerimientos, mejoras y arreglos
• Nunca está completo
• Constante cambio para identificar las necesidades del producto – Dinámico
• Repriorizado constantemente
PBI: Product Backlog Item
• Los PBI son ordenados por valor del negocio
• Los PBI son evaluados verticalmente
• EL PO es la autoridad en el orden del PB
• La mayoría de los equipos SCRUM utilizan las HU como PBI
Historias de usuario
• Es un requerimiento del producto
• Tiene un valor agregado visible para el cliente
• Cuando se implementa una HU se desarrolla una nueva característica que el cliente puede usar
• No es una descripción detallada
Como
Quiero
Para
Conversación
• Cuando una nota no es suficiente debe ser discutida
• PO debe resolver las preguntas del ED
Todas las preguntas deben ser escritas en notas
Criterios de Aceptación
• Deben ser desarrollados por el evaluador
• El equipo y el PO desarrollan los CA juntos
• Los CA son importantes para el evaluador y para el ED
• Los CA pueden cambiar
Estimación con puntos de Fiboacci
Puntos de la historia
Estimar basado en:
• Esfuerzo
• Riesgo
• Complejidad
• Incertidumbre
Medidas relativas: La H1 es mas compleja que la H2
Sin unidad – usar escala de orden aproximada de magnitud
Como Estimar
• Usando una historia de referencia, escoger la mas pequeña
• Estimar el tamaño relativo de las demás historias
• Luego compartirlas con el equipo
Spring Backlog Incremento
Reuniones Planeación 8h ED,PO,SM,STH
Daily 15m ED, SM
SPRINT REVIEW 4h ED,PO,SM,STH
RETROSPECTVA 3h ED, SM, PO
Refinamiento 10% Sprint ED, PO
Release Cuando sea necesario ED,PO,SM,STH
Planeación del Sprint
Reuniones
Scrum Diario
Participa el PO, DE y SM
Reuniones
Scrum Diario
Participa el PO, DE y SM
Reuniones
Participa el PO, DE y SM
Bases de SCRUM - Proceso empírico
Experto
Control de proceso definido
Marco Cynefin
4 tipos de trabajo:
Trabajo sencillo: cocinar huevo,
Trabajo complicado: definir la situación -> analizamos -> plan (métodos tradicionales
Trabajo complejo : No podemos definir desde el inicio los detalles o comportamientos del
proyecto
Es aplicable scrum por el grado de incertidumbre
Pablo Enrique Diego Felipe Trujillo
Sprenger María Fernanda
Magariños
Gonzalo Falcone Director Ejecutivo de
Desarrollo de
David Aguirre Johana Osorio
Director Ejecutivo de Head de Inversiones y Directora de Talento
Directora Ejecutiva de Distribución y Cliente Negocios
Productos Humano
Soporte de Negocios SURA IM Jefe de los Gerentes
CEO de SURA IM Generales
JUAN CORTES Catalina Trujillo
Director, Head Regional de Otálvaro
Operaciones y Tecnología en
SURA IM| Estratégica y
Soporte de Negocio
ESTEBAN LOPEZ Gabriel – PM - Tercero
Gerente General Gestión del portafolio de manera
WILLIAM SILVA (CEO) Fiduciaria integral
Gerente de Operaciones Sura IM
Región Colombia - Perú
Líder del. programa
AGILE COACH ??
• Soluciones empresariales – Tesorería Corporativa EDUARDO BOTERO
PO DE CELULAS
• Onboarding Digital Program Manager - 3 Años
Ideación y Estructuración
MANUEL GALEANO Catalina Herrera
Procesos
JORGE IGNACIO TRUJILLO : Plataforma para gestión de portafolios, No hay equipos, debe terminar ideación y
estructuración
Tecnología - Nestor
CARLOS SUAREZ: CRM
Proveedores Externos
ALEJANDRA BAHENA: Riesgos
Pablo Enrique Diego Felipe Trujillo
Sprenger María Fernanda
Magariños
Gonzalo Falcone Director Ejecutivo de
Desarrollo de
David Aguirre Johana Osorio
Director Ejecutivo de Head de Inversiones y Directora de Talento
Directora Ejecutiva de Distribución y Cliente Negocios
Productos Humano
Soporte de Negocios SURA IM Jefe de los Gerentes
CEO de SURA IM Generales
JUAN CORTES
Director, Head Regional de
Operaciones y Tecnología en
SURA IM|
ESTEBAN LOPEZ
Gerente General Gabriel – PM - Tercero
(CEO) Fiduciaria Gestión del portafolio de manera
integral
WILLIAM SILVA
Gerente de Operaciones Sura IM Catalina Trujillo
Región Colombia - Perú Otálvaro
Estratégica y AGILE COACH ??
Líder del. programa Soporte de Negocio
EDUARDO BOTERO
• Soluciones empresariales – Tesorería Corporativa Program Manager - 3 Años
PO DE CELULAS
• Onboarding Digital
Ideación y Estructuración
Catalina Herrera
MANUEL GALEANO Procesos
JORGE IGNACIO TRUJILLO : Plataforma para gestión de portafolios, No hay equipos, debe terminar ideación y
estructuración
Tecnología - Nestor
CARLOS SUAREZ: CRM
Proveedores Externos
ALEJANDRA BAHENA: Riesgos
