Scrum Master - 2018 - B

Agilidad
Carlos Uriel Ramírez M, I ASM® I VeriSM® I Agile Practitioner I Design Thinker I PMP® | Master en TI
Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® |

VeriSM™
Hola,
soy Carlos Uriel Ramírez.
Entrenador ágil.
Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Las reglas ...

Introduction

!Enamórate del Cliente, no
del producto!

Agilidad ... Es un Mindset para innovar en
sistemas complejos
NO es hacer las cosas más rápido.. Es
generar Valor más temprano.
Si vas a fracasar … hazlo rápido

Taller Mindset. Entregables
...
Titulo del Taller
Tres Valores: Respeto,
Colaboración y Apertura
Por cada valor : tres principios
Grupos de animales que no existan
El animómetro

El Animómetro
0% 25% 50% 75% 100%

El marco Cynefin

El marco Cynefin
Snowden & Bonne
Muchas veces
funcionan
Ensayo Dominio de expertos
Validando
• Experimentar • Detectar
• Detectar • Analizar
• Responder • Responder
Respuesta Rápida Mejores Prácticas
Funcionan
Reactivo
Siempre
• Actuar • Detectar
• Detectar • Clasificar
• Responder • Responder

Ejercicio 1: Lo simple El marco Cynefin
Reto
Ordena los bloques por colores, tan rápido como te sea

posible. Haz un montón por cada una de las piezas
especiales que encuentres. Decide en tu equipo que
piezas quieres tratar como especiales.
Preguntas
• ¿Cuanto tiempo necesitaron para planear?

• ¿Como fue la comunicación? ¿Cuantos líderes y
seguidores había en tu equipo?

Ejercicio 2: Lo complicado El marco Cynefin
Reto
Construye una estructura, tan pronto como te sea

posible, de acuerdo a las siguientes reglas: Por lo
menos 20 bloques de altura, patrón de color consistente
y cada bloque que añadas a la estructura no puede ser
mayor que el anterior.
Preguntas
• ¿Cuáles son las diferencias con el ejercicio simple?

• ¿Cuánto tiempo necesitasteis para planear?
• ¿Como fue la comunicación? ¿Cuántos líderes y
seguidores había en tu equipo?
Ejercicio 3: Lo complejo El marco Cynefin
Reto
Decide en 30 segundos si quieres construir un animal o un vehículo. Después de eso, trabaja
siguiendo las siguientes reglas:
• Como en el ejercicio anterior, hay que construir siguiendo un patrón consistente de color.
• Cada color sólo lo puede tocar un miembro del equipo.
• No pueden hablar.
• Cada minuto, deben cambiar de mesa, llévense el trabajo pero no el material sobrante
Preguntas
• ¿Que diferencias vieron comparadas con el problema simple/complicado?
• ¿Como ha sido la comunicación? ¿Cuantos líderes y seguidores había en tu
equipo?
• ¿Que tipo de retroalimentación tuvieron para conseguir llegar a una solución?
• ¿Habría habido alguna diferencia si hubieran tenido cinco minutos para hablar y
planificar antes de empezar a construir?
Ejercicio 4: El caos El marco Cynefin
Reto
Su producto anterior solo funciona si tiene la mitad del producto de otro equipo,
hay una mitad de tu producto que debes compartir sin desbaratar
• Pueden hablar.
• Tienen 90 segundos
Preguntas
• ¿Que diferencias han visto comparadas con el problema simple/complicado/Complejo

Los proyectos deben
ejecutarse depende de su
contexto
Vs

Manifiesto Ágil
Historia: Se acuñó el término “Métodos Ágiles” para definir métodos que
estaban surgiendo como alternativa a las metodologías
Febrero de 2001, reunión de 17 formales de cascada, a las que consideraban excesivamente
críticos de los modelos de mejora “pesadas” y rígidas por su carácter normativo y fuerte
del desarrollo de software basados dependencia de planificaciones detalladas previas al desarrollo.
en Procesos , para “discutir” sobre
técnicas y procesos para Integrantes de la reunión resumieron los principios sobre los
desarrollar software. que se basan los métodos alternativos en 4 postulados, lo que
ha quedado denominado como MANIFIESTO ÁGIL

4 Valores

Principios Ágiles

Taller de Valores y principios Ágiles
• Se dividen en grupos de 4 personas, discuten los

Valores y los relacionan a los principios en sus mesas
• Colocan un papelógrafo para cada grupo, hacen un
cuadrante y en cada uno escriban un valor.
• Cuestiónense que tanto su empresa cumple cada uno
de los Valores y si ven oportunidad de mejora en un
proceso

The Ball Game

El Scrum

La historia de Scrum se puede rastrear desde 1986 en un artículo
de la Harvard Business Review, “El nuevo juego para el desarrollo
de productos” por Hirotaka Takeuchi y Ikujiro Nonaka.
Este artículo describe como empresas como Honda, Canon y

Fuji-Xerox producen nuevos productos a nivel mundial utilizando
un enfoque escalable y basado en equipos integrales para el
desarrollo de productos.

Scrum no es un acrónimo, sino un término extraído del Rugby, que
se refiere a la manera en cómo se reinicia el juego luego de una
falta o cuando la bola se ha ido fuera del juego
En 1993, Jeff Sutherland y su equipo en Easel Corporation

crearon el proceso de Scrum para ser utilizado en los procesos de
desarrollo de software

“
Scrum es un marco de trabajo por el cual las personas pueden acometer
problemas complejos adaptativos, a la vez que entregar productos del
máximo valor posible productiva y creativamente. Tres pilares soportan
toda la implementación del control de procesos empírico: transparencia,
inspección y adaptación.
” Guía Oficial del Scrum

Ken Schwaber y Jeff Sutherland

“
Valores Scrum
1. Compromiso
2. Coraje
3. Foco
4. Apertura
5. Respeto
Guía Oficial del Scrum
”

“
Pilares Scrum
1. Transparencia
2. Inspección
3. Adaptación
” Guía Oficial del Scrum


Framework

The Scrum cycle

El ciclo Scrum
Las partes Implicadas dan Feedback
Petición de
Feedback a
Incorporando interesados
Feedback
Scrum Diario
Recolección de
Requisitos
Gestión del Planificación del Ejecutar Sprint Review

Backlog Sprint Sprint Sprint Retrospective

Taller Ciclo de vida
Inspeccionar cómo trabajamos
Inspeccione el incremento del Un contenedor para todos los Ordene, corte, aprenda de los
en equipo, encontrar
producto y adapte el Product demás eventos, proporcionando elementos del Product Backlog
experimentos para intentar
Backlog para maximizar el valor un límite de planificación y hasta que estén listos para ser
mejorar las formas de trabajar
de los sprints futuros enfoque arrastrados
Retrospectiva del Sprint Sprint

Inspeccionar el progreso hacia la
Debería responder qué, cómo,
meta de Sprint y adaptar nuestro
por qué Refinamiento del Product
plan para las próximas 24 horas
Revisión del Sprint
Backlog
<4H <3H Reunión Diaria Scrum Planeación del Sprint
<10% <30d <8H <15m
Organice y empareje los eventos, descripciones y tiempos

Roles Scrum

Roles Scrum
Clientes / Usuarios
Scrum Master
Product
Owner
Scrum Team
✓ Programadores
✓ Testers
✓ Analistas Funcionales
✓ Diseñadores

Scrum Master
• Líder Servicial
• El Scrum Máster es un especialista que conoce y comprende Scrum
completamente; ayuda al equipo entrenándolo y asegurándose de que
todos los procesos de Scrum se ponen en práctica correctamente.
• El Scrum Máster se centra en el proceso más que en el contenido

(solución, alcance, etc.)
• Además, el Scrum Máster es también responsable de la eliminar de los
impedimentos; cuando los miembros del equipo tienen un problema, se
lo cuentan al Scrum Máster y este es el encargado de intentar resolverlo.
Por supuesto no si se trata de problemas técnicos, sino de problemas
que tienen que ver con la implementación de Scrum

Product Owner
• El Dueño de Producto es el responsable de maximizar el valor del
producto y el trabajo del Equipo de Desarrollo.
• Sólo hay un Dueño del Producto por proyecto, independientemente que

sea a tiempo completo o tiempo parcial. La persona que ocupa este rol
debe estar orientada a los negocios; por ejemplo un analista de negocios
es un muy buen candidato para desempeñar este rol.
• El Propietario o Dueño del Producto está constantemente en contacto

con el cliente, entiende sus necesidades, y los transforma en elementos
del Backlog de Producto. Después, asigna un “valor de negocio” a cada
item, y ordena el Backlog de Producto en función de este valor. De esta
manera los elementos más importantes estarán siempre en la parte de
arriba de la lista. Esos elementos de la parte superior son lo que se
harán en la siguiente iteración.
Team Developer
• El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de
entregar un Incremento de producto “Terminado” que potencialmente se pueda
poner en producción al final de cada Sprint.
• Solo los miembros del Equipo de Desarrollo participan en la creación del
Incremento.
• La organización es la encargada de estructurar y empoderar a los Equipos de
Desarrollo para que estos organicen y gestionen su propio trabajo.
• Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de
Desarrollo cómo convertir elementos de la Lista del Producto en Incrementos de
funcionalidad potencialmente desplegables
• Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan
con todas las habilidades necesarias para crear un Incremento de producto
• Scrum no reconoce subequipos en los equipos de desarrollo, no importan los
dominios particulares que requieran tenerse en cuenta, como pruebas o análisis
de negocio; no hay excepciones a esta regla; y,
• Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades
especializadas y áreas en las que estén más enfocados, pero la responsabilidad
recae en el Equipo de Desarrollo como un todo
Artefactos Scrum

1. Product Backlog
“
Es la única fuente de requisitos para cualquier cambio a realizarse en el
producto. El Dueño de Producto (Product Owner) es el responsable de la
Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.
”
Schwaber y Sutherland
Creadores del Scrum

2. Sprint Backlog
“
La Lista de Pendientes del Sprint es el
conjunto de elementos de la Lista de
Producto seleccionados para el Sprint, más
un plan para entregar el Incremento de
producto y conseguir el Objetivo del Sprint.
”
Creadores del Scrum

3. Incremento
“
El Incremento es la suma de todos los elementos
de la Lista de Producto completados durante un
Sprint y el valor de los incrementos de todos los
Sprints anteriores. Al final de un Sprint el nuevo
Incremento debe estar “Terminado”, lo cual
significa que está en condiciones de ser utilizado y
que cumple la Definición de “Terminado” del
Equipo Scrum. El incremento debe estar en
condiciones de utilizarse sin importar si el Dueño
de Producto decide liberarlo o no.
”
Creadores del Scrum
Resumen

Eventos Scrum

Sprint
“
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de
un mes o menos durante el cual se crea un incremento de producto
“Terminado” utilizable y potencialmente desplegable.
”
Creadores del Scrum

Daily Scrum
“
Es una reunión diaria de máximo 15 min. que permite informar al equipo
qué se hizo ayer, qué se hará hoy y qué inconvenientes se podrían
presentar para hacer nuestra tarea diaria.
”
Juan Banda
Percella

Sprint Planning
“
El trabajo a realizar durante el Sprint se planifica en la Planificación de
Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo
Scrum completo.
”
Creadores del Scrum

Sprint Planning Meeting
Trabajo Trabajo
con el con el
cliente equipo

Pasos:
El cliente presenta al equipo la lista de

requisitos priorizados del producto o
proyecto.
Trabajo El equipo examina la lista, pregunta al
con el cliente las dudas que le surgen, añade más
condiciones de satisfacción.
cliente
El equipo selecciona los
objetivos/requisitos más prioritarios que
se compromete a completar en la iteración.

Pasos:
El equipo planifica la iteración, elabora la

táctica que le permitirá conseguir el mejor
resultado con el mínimo esfuerzo.
Define las tareas necesarias para poder Trabajo

completar cada objetivo/requisito, creando
la lista de tareas de la iteración. con el
Realiza una estimación conjunta del equipo
esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se autoasigna a

las tareas que puede realizar.

Reto Ágil
La Ciudad Lego

Agile Inception
Todo lo que ocurre (o podría ocurrir)

antes del primer Sprint

Agile Inception
“Es un conjunto de dinámicas orientadas a enfocar a todas las personas involucradas en
un proyecto hacia un mismo objetivo, reduciendo muchas de las incertidumbres,
ayudando a explicitar los riesgos más evidentes y poniendo en común las expectativas
de todos. Publicada en el libro “The Agile Samurai” y en la conferencia “Agile 2011”, se
puede emplear al iniciar cualquier tipo de proyecto”

• Todos los miembros del equipo deben entender la
principal razón del proyecto
• Para ello, antes de iniciar el proyecto, convocas a todo

el equipo y se explica la razón principal del proyecto
1. El foco • Asegúrate que no solo el equipo sepa esa razón sino

que la entienda el trasfondo.
• Comparte la visión de forma visible.
Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™ Agile Inception

• Se condensa la visión de cómo resolver el problema
que nos convocó
• El "Elevator Pitch" es un término que viene del mundo

del marketing de los años 60 -70
2. El Elevator • La idea es tener un argumento tan bien preparado y

condensado, que puede usarse para "vender“ una idea
Pitch
• Utilizamos esta estructura porque destaca una serie de
elementos que nos resultan útiles discutir.

2. Elevator pitch
Técnica de Marketing
• Se prepara el Pitch con un time

Pitch box de 5 a 10 minutos.
• No se requiere listas extensas de
características. Los detalles van
Para [ cliente | público ] que tiene la después.
[ necesidad | oportunidad ] este
[ nombre producto ] es un [ tipo de producto ]
• Se otorga a los participantes un
tiempo máximo de 20 -30
que [ beneficio | razón de compra ]. segundos para exponer.
A diferencia de [ principal competidor | alternativa]
• Esta actividad finaliza con una
discusión abierta y una
nuestro producto [ diferencial competitivo ] reelaboración de propuestas.
• Se obtiene una sola frase
consolidada, o unas pocas
alternativas principales
3. Product Visión Board
Nombre del proyecto Frase representativa
Grupo de Usuarios Necesidades Funcionalidades

Valor
- Clientes del Producto
(Procesos)
¿Qué valor le genera al

negocio la
¿Cuáles son las Características de tu satisfacción de la
¿Quiénes van a necesidades de tu producto que necesidad del grupo
usar el producto, grupo de usuarios? satisfacen las de usuarios a través
quienes pagarán necesidades del producto?
por el?

4. Product Scope Board
Product Scope Board → PBL
Personas Que va Diseño Técnico Riesgos

dentro del
+
producto
(Alcance)
Interés
Que NO va
dentro del
producto
- Poder +

User Story Mapping
A. En el nivel más alto aparecen las

historias de usuario Épicas. Estas se
ordenarán de izquierda a derecha
siguiendo el flujo de trabajo o la
secuencia de uso del usuario.
B. Para desarrollar el siguiente nivel

hay que tomar en consideración la
secuencia o el flujo de actividades
que seguiría el usuario para
completar la Épicas. De nuevo las
temáticas aparecen ordenadas de
izquierda a derecha en función del
tiempo.
C. Finalmente, cada una de las

Temáticas se descomponen en
historias de usuario estándar;
aquellas que pueden llevarse a
cabo durante un sprint
User Story Mapping

Historias de Usuario
“
Una manera simple de describir una funcionalidad o atributo del
producto que aporta valor al usuario o al negocio.
Es aconsejable usar el formato:

Como [rol] quiero [funcionalidad] para
[beneficio]
”
Mike Cohn
Mountain goat software

Historias de usuario
Independiente. No superpone funcionalidades. Pueden
INVEST planificarse y desarrollarse en cualquier orden.
Negociable. No es un contrato. Pueden incrementarse o

eliminarse a lo largo del proyecto.
Valorable. Debe ser valorable por el Product Owner y las

debe considerar importantes.
Estimable. Debe ser estimable. Revisar el tamaño,

conocimiento funcional y técnico.
Pequeña. Debe ser pequeña para poder ser estimada por el
equipo.
Verificable. Debe ser verificada a través de criterios de
aceptación.

Título de la historia Usuario de la historia
Descripción de la historia Criterio de aceptaciòn
Estimación de la historia

Lista de Eventos Comumnity Manager
Criterios de aceptaciòn
Necesito crear un listado de
eventos confirmados para no
superponer eventos • Mostrar nombre, ciudad y país
• Muestra solo eventos futuros
• Ordenados por fechas
ascendentes
20

Planning Pocker
James Greening
Mide:
History points
Complejidad
Esfuerzo
Riesgo
Fórmula:
Velocidad del equipo =
Story Points / Iteración
Horas / Puntos
App: Planning Poker

Pasos:
El cliente presenta al equipo la lista de

requisitos priorizados del producto o
proyecto.
Trabajo El equipo examina la lista, pregunta al
con el cliente las dudas que le surgen, añade más
condiciones de satisfacción.
cliente
El equipo selecciona los
objetivos/requisitos más prioritarios que
se compromete a completar en la iteración.

Pasos:
El equipo planifica la iteración, elabora la

táctica que le permitirá conseguir el mejor
resultado con el mínimo esfuerzo.
Define las tareas necesarias para poder Trabajo

completar cada objetivo/requisito, creando
la lista de tareas de la iteración. con el
Realiza una estimación conjunta del equipo
esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se autoasigna a

las tareas que puede realizar.

Capacity Analysis
Análisis de Capacidad
Total de Horas por persona:
80 80 80 80 70 80 80 80
Compromisos
Planning
51 51 Buffer
71 61
46 66
76 66 Pasos:
4 4
SM espera ofrecimiento del
4 team
4 4 Se planifica desde la
4 4 4 capacidad del team
Si no es tan grande, aumenta

25 0 15 25 20 10 15 10
historias
A B C D E F G H
Sprint Review
“
Al final del Sprint se lleva a cabo una Revisión de Sprint para
inspeccionar el Incremento y adaptar la Lista de Producto si fuese
necesario.
”
Creadores del Scrum

Sprint Review Meeting
Técnica
Introduccion (SM)
Agenda/ Duración /Técnicas
Clouse (SM) Bussines (PO)

Razón del proyecto que estamos
Breve cierre
haciendo
Technical (Team)
Presentar Producto Funcional
Cumple función “of done”

Sprint Retrospective
“
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de
inspeccionarse a sí mismo y de crear un plan de mejoras que sean
abordadas durante el siguiente Sprint.
”
Creadores del Scrum

Sprint Restrospective
Técnica
Preparar el escenario
SM prepara el ambiente (3 - 5 min)
Cierre Reunir datos

SM limpia la pared – toma fotos Team escribe en Post- it (5 min)
( 3- 5 min)
Decidir qué hacer Generar estadísticas

Team decide qué hacer ( 3- 5 min) Se leen los post it y hay una breve
discusión (<10 min)

Técnica 1
- +

Técnica 2

Scaled Agile

VeriSM™ Fuente: ANÁLISIS: STATE OF AGILE REPORT 11
Scrum de Scrum

VeriSM™
VeriSM™
Nexus®

VeriSM™
VeriSM™
SAFe 4.5®

VeriSM™
VeriSM™
Large Scale Scrum®

VeriSM™
VeriSM™
Scrum Master
Carlos Uriel Ramírez M, I ASM® I VeriSM® I Agile Practitioner I Design Thinker I PMP® | Master en TI

VeriSM™

Scrum Master - 2018 - B

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Scrum Master - 2018 - B

Cargado por

Copyright:

Formatos disponibles

Agilidad

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® |

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Si vas a fracasar … hazlo rápido

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

0% 25% 50% 75% 100%

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Respuesta Rápida Mejores Prácticas

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Ordena los bloques por colores, tan rápido como te sea

• ¿Cuanto tiempo necesitaron para planear?

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Construye una estructura, tan pronto como te sea

• ¿Cuáles son las diferencias con el ejercicio simple?

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

• Se dividen en grupos de 4 personas, discuten los

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Este artículo describe como empresas como Honda, Canon y

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

En 1993, Jeff Sutherland y su equipo en Easel Corporation

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

” Guía Oficial del Scrum

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

” Guía Oficial del Scrum

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Gestión del Planificación del Ejecutar Sprint Review

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Retrospectiva del Sprint Sprint

<4H <3H Reunión Diaria Scrum Planeación del Sprint

<10% <30d <8H <15m

Organice y empareje los eventos, descripciones y tiempos

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

• El Scrum Máster se centra en el proceso más que en el contenido

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

• Sólo hay un Dueño del Producto por proyecto, independientemente que

• El Propietario o Dueño del Producto está constantemente en contacto

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™

El cliente presenta al equipo la lista de

Carlos Uriel Ramírez M, Master Ti | ASM® | SPOC® | VeriSM™