Scrum Master Developer Capitulo 3

www.jbenterprisegroup.com
 Marco de la Guía SBOK
 Aspectos de Scrum
 Organización
 Justificación del Proyecto
 Calidad
 Cambio
 Riesgo
GUÍA SBOK Y SCRUM
Aspectos de SCRUM
Los aspectos de Scrum, pueden ser modificados para cumplir con los
requisitos del proyecto o la organización.
Organización
Justificación
del Proyecto
CalidadCambio
Riesgo

1. Organización
Aspectos de SCRUM
Core Roles
Non - Core
Roles
Equipo Principal SCRUM
(Scrum Core Team)
• Propietario de Producto
(Product Owner)
• Scrum Master
• Equipo Scrum (Scrum Team)
Stakeholders
• Clientes
• Usuarios
• Patrocinador
Vendedores
Cuerpo de Asesoramiento de
SCRUM (SGB)
Propietario de Producto Scrum Master
Equipo Scrum
Equipo Principal Scrum (Scrum Core Team)
 Son en última instancia responsables de cumplir con los objetivos del
proyecto.
 Está formado por el Propietario del Producto, Scrum Master, y el
Equipo Scrum.
 Es importante, tener en cuenta que, de estos tres roles, ningún rol
tiene autoridad sobre los otros.

 Responsable para la maximización del valor del negocio y el trabajo
del Equipo Scrum (Scrum Team).
 Es el único responsable de la gestión de la Lista Priorizada de
Pendientes del Producto (Prioritized Product Backlog), lo cual incluye:
 Expresar claramente los ítems de la Lista Priorizada de Pendientes del
Producto.
 Ordenar los ítems en la Lista Priorizada de Pendientes del Producto para el
logro de objetivos y misión.
 Optimizar el valor del trabajo del equipo Scrum.
 Asegurar que la Lista Priorizada de Pendientes del Producto sea visible,
transparente y claro para todos, y mostrar lo que el equipo Scrum (Scrum
Team) trabajará en las siguientes iteraciones (sprint).
 Asegurar que el equipo Scrum comprenda los ítems en la Lista Priorizada
de Pendientes del Producto en el nivel que sea necesario.
Propietario de Producto (Product Owner)
 Responsable de articular los requisitos del Cliente y de mantener la
Justificación del negocio del proyecto.
 Representa la voz del cliente (Voice of the Customer).
 Podría haber un Propietario de Producto del Programa o un
Propietario de Producto del Portafolio.
 El Propietario del Producto (Product Owner) puede hacer el trabajo o
tener al Equipo Scrum para hacerlo, sin embargo sigue siendo
responsable.
 Es una persona, no un comité.
 Para que el Propietario del Producto tenga éxito, la organización
debería respetar su decisión.
 No es permisible decir al Equipo Scrum trabajar desde un conjunto
diferente de requerimientos, y el Equipo Scrum no está permitido
actuar de esta manera.
Propietario de Producto (Product Owner)

 Es un facilitador que asegura que el Equipo Scrum esté dotado de un
ambiente propicio para completar con éxito el desarrollo del producto.
 Guía, facilita y les enseña prácticas de Scrum a todos los involucrados
en el proyecto.
 Elimina los impedimentos que enfrenta el equipo.
 Asegura que se estén siguiendo los procesos de Scrum.
 El papel de Scrum Master es diferente a la función desempeñada por
el Director de Proyecto en un modelo tradicional, ya que el Scrum
Master sólo funciona como un facilitador y está en el mismo nivel
jerárquico que cualquiera otra persona en el Equipo Scrum.
 También podría haber un Scrum Master de Programa o un Scrum
Master para un Portafolio.
Scrum Master
 Consiste de profesionales, quienes hacen el trabajo para entregar
un incremento potencial de producto (release) “Terminado” al fin
de cada iteración.
 Solamente miembros del Equipo Scrum crean el Incremento.
 Son estructurados y empoderados por la organización para
organizar y gestionar su propio trabajo.
 Son responsables de la comprensión de los requerimientos del
negocio especificados por el Propietario del Producto, la estimación
de Historias de Usuario y la creación final de los Entregables del
Proyecto.
Equipo Scrum (Scrum Team)

1. Organización
Aspectos de SCRUM
1. Organización
Aspectos de SCRUM
PropietariodelProducto
•Experto en Scrum
•Conocimiento de
dominio del negocio
•Excelentes
habilidades de
comunicación
•Conocimiento de
procesos Scrum
•Habilidad para
manejar las
incertidumbres
•Habilidades de
negociación
•Accesible
•Proactivo
•Decisivo
•Pragmático
•Orientado a las
metas
ScrumMaster
•Experto en Scrum
•Servant Leader
•Moderador
•Solucionador de
problemas
•Accesible
•Motivador
•Perceptivo
•Mentor
•Habilidades de
coordinación
•Introspectivas
EquipoScrum
•Conocimiento de
Scrum
•Auto-organización
•Altamente motivado
•Proactivo
•Expertos Técnicos
•Perspectiva
multifuncional
•Buen miembro de
equipo
•Independiente
•Responsable
•Intuitivo
•Orientado a los
objetivos
•Introspectiva
Selección de Personal

1. Organización
Aspectos de SCRUM
Tamaño del Equipo Srum
 Deben poseer todas las habilidades necesarias para llevar a cabo el trabajo del
proyecto.
 Contar con un alto nivel de Colaboración para maximizar la productividad, por lo
que se require una minima coordinación para hacer las cosas.
 El tamaño óptimo de un Equipo Scrum es de 6 a 10 miembros, lo suficientemente
grande para asegurar habiilidades adecuadas, pero lo suficientemente pequeño
para colaborar fácilmente.
 Un beneficio clave de un equipo de 6 a 10 miembros es que la comunicación y la
gestión suelen ser simples y requieren un mínimo esfuerzo.
 Una desventaja es que los equipos pequeños se ven afectados significativamente
por la pérdida de un miembro del equipo.
Aspectos de SCRUM
Modelo de Dinámica de Grupo de Tuckman
 Bruce Tuckman fue el primero en desarrollar este modelo en 1965.
 El modelo de Tuckman explica que mientras el equipo desarrolla madurez,
habilidades y establece relaciones entre sus miembros, el líder va cambiando su
estilo de liderazgo.
 Comenzando con un estilo directivo, moviéndose hacia el coaching, luego
participando y finalizando con delegación casi independiente.
 En 1975 Tuckman revisó con Jensen el modelo y agregó una quinta fase
(Terminación)
Formación (Forming)
Poca claridad en las
funciones y las
responsabilidades de
cada equipo
Estilo de Liderazgo
Directivo
Conflicto (Storming)
Confusión y caos entre
los miembros
Estilo de Liderazgo
Entrenador
Normalización
(Norming)
El equipo trabaja junto
Estilo de Liderazgo
Facilitador
Desempeño
(Performing)
Consistentemente Alta
Productividad
Estilo de Liderazgo
Delegador

Aspectos de SCRUM
Técnicas de Gestión de Conflictos
 Las organizaciones que aplican Scrum fomentan un ambiente abierto y de
diálogo entre los empleados.
 Los conflictos entre los miembros del Equipo Scrum generalmente se resuelven
de forma independiente, con poca o ninguna participación de la gerencia o de
otros fuera del Equipo Scrum.
Competición.
(Yo gano-Tú pierdes)
Colaboración.
(Todos ganan)
Evasión.
(Yo pierdo-Tú pierdes)
Acomodación.
(Tú ganas-Yo pierdo)
Aspectos de SCRUM
Estilos de Liderazgo
• Implica escuchar cuidadosamente, tener empatía, comprometerse al
servicio, tener visión, y compartir el poder y la autoridad con los miembros
del equipo.
• Logran resultados centrándose en las necesidades del equipo.
Servant Leadership
• Están involucrados en la mayor parte de la toma de decisiones, sin
embargo delegan parte de la planificación y de la toma de decisiones a los
miembros del equipo.
• Es apropiado en situaciones en las que el líder está en sintonía con los
detalles de proyectos específicos y cuando el tiempo es limitado.
Delegativo
• Toman decisiones por su cuenta, otorgando poca intervención sobre las
decisiones a tomar.
• Este estilo de liderazgo se debe utilizar solamente en raras ocasiones.
Autocrático

Aspectos de SCRUM
• Le instruye a los miembros del equipo que tareas se requieren, cuando se
deben realizar y la forma en que se deben realizar.
Director
• Presenta instrucciones y luego apoya y supervisa a los miembros del equipo al
escuchar, ayudar, alentar y presentar una perspectiva positiva en tiempos de
incertidumbre.
Entrenador /Soporte
• El equipo se queda en gran parte sin supervisión, por lo que el líder no
interfiere con las actividades laborales diarias.
• A menudo este estilo lleva a un estilo de anarquía.
Dejar pasar (Laissez Faire)
• Imponen tareas y el cumplimiento de los plazos.
Orientado a Tareas
• Confrontan los problemas y demuestran confianza al establecer autoridad
respetuosamente.
Asertivo
Aspectos de SCRUM
El estilo de liderazgo preferido para los proyectos Scrum es Servant Leadership.
Este término fue descrito por primera vez por Robert K. Greenleaf, en un ensayo
titulado The Servant as Leader.
“El servant-leader es primero que nada un servidor… Empieza con el sentimiento
natural de que uno quiere servir, servir primero. Luego la elección consciente lleva a
uno a aspirar a liderar. Esa persona es completamente diferente a aquel que es líder
primero, tal vez debido a la necesidad de mando inusual o de adquirir posesiones
materiales. El líder primero y el Servant-leader son dos tipos extremos. Entre ellos
hay matices y mezclas que forman parte de la infinita variedad de la naturaleza
humana…

Aspectos de SCRUM
La Teoría de Jerarquía de Necesidades de Maslow
 Las necesidades se clasifican en cinco grupos y se disponen jerárquicamente según su
capacidad de motivación.
 Conforme avancemos en la pirámide mayor poder de motivación.
 Cuando una necesidad es satisfecha la siguiente más alta se convierte en
predominante.
Reconocimiento
(aprecio,
reconocimiento,
confianza en si mismo)
Afiliación
(asociación, aceptación, sentimiento
de grupo)
Seguridad
(protección y estabilidad)
Fisiológicas
(respirar, alimento, bebida, etc.)
Sueldo, vacaciones, períodos de
descanso en el trabajo, calefacción,
refrigeración, etc.
Autorrealización
Condiciones de seguridad en el
trabajo, planes de pensiones, etc.
Trabajo en grupo, actividades
patrocinadas por la empresa, etc.
Promoción, títulos, poder, premios,
reconocimientos, etc.
Hacer trabajos creativos, cumplir tareas
desafiantes, desarrollar habilidades, etc.
Aspectos de SCRUM
Teoría X y Teoría Y
 No es probable que los proyectos Scrum tengan éxito si el Scrum Master o el
Propietario del Producto son líderes de la Teoría X.
 Los líderes de proyectos Scrum deben suscribirse a Teoría Y y ver a los
empleados por sus cualidades importantes, a la misma vez que se les ayuda a
desarrollar sus habilidades y a sentirse con poder.
Supuestos Teoría
X
• Las personas son perezosas e
indolentes.
• Las personas rehúyen al
trabajo.
• Las personas evaden las
responsabilidades para sentirse
más seguras.
• Las personas necesitan ser
controladas y dirigidas.
• Las personas son ingenuas y no
poseen iniciativa.
Supuestos Teoría
Y
• Las personas se esfuerzan y les
gusta estar ocupadas.
• El trabajo es una actividad
natural como divertirse o
descansar.
• Las personas buscan y aceptan
responsabilidades y desafíos.
• Las personas pueden
automotivarse y autodirigirse.
• Las personas son creativas y
competentes.

Métodos Ágiles
Lean Kanban
 El concepto de Lean optimiza el sistema de una organización para producir
resultados valiosos sobre la base de sus recursos, necesidades y alternativas,
mientras reduce las pérdidas.
 El fundamento de Lean es que la reducción de la longitud de cada ciclo (es
decir, una iteración) conduce a un aumento de productividad mediante la
reducción de los retrasos.
 Kanban significa “cartel” o “cartelera” y enfatiza el uso de ayudas visuales para
ayudar y realizar un seguimiento de la producción. El concepto fue introducido
por Taiicho Ohno, considerado como el padre de los sistemas Toyota Production
Systems (TPS).
 Lean Kanban integra el uso de los métodos de visualización según lo prescrito
por Kanban junto con los principios de Lean creando así un sistema de gestión
de proceso evolutivo incremental y visual.
Métodos Ágiles
Lean Kanban

Métodos Ágiles
Extreme Programming (XP)
 Se originó en Chrysler Corporation, ganó fuerza en la década de 1990.
 XP hace que sea posible mantener el costo de cambiar el software sin que éste
aumente radicalmente con el tiempo.
 Los atributos claves de XP incluyen el desarrollo gradual, horarios flexibles,
pruebas automatizadas de código, la comunicación verbal, el diseño en
constante evolución, Colaboración cercana y la vinculación de las unidades, de
largo como de corto plazo, de todos los involucrados.
 XP valora la comunicación, la retroalimentación, la simplicidad y el correr
riesgos.
 Los diferentes roles en el enfoque XP incluyen el cliente, desarrolladores,
rastreador y entrenador.
 Prescribe varias prácticas de negocios, codificación, así como eventos y
artefactos para lograr un desarrollo eficaz y eficiente.
Métodos Ágiles
Crystal Methods
 Las metodologías de desarrollo de software Crystal fueron presentadas por
Alistair Cockburn a principios de 1990.
 Los métodos Crystal se centran en las Personajes o Personas, son ligeros y
fáciles de adaptar. Porque la gente es lo primordial, los procesos y las
herramientas de desarrollo no son fijos sino que se ajustan a las necesidades y
características específicas del Proyecto.
 El espectro de color se utiliza para decidir sobre la variante de un proyecto. Los
factores tales como la comodidad, el dinero discrecional, el dinero esencial, y la
vida juegan un papel vital en la determinación del "peso" de la metodología,
que se representa en varios colores del espectro. Crystal se divide en Crystal
Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal
Maroon, Crystal Diamond y Crystal Sapphire.
 Todos los métodos de Crystal tienen cuatro roles – patrocinador, diseñador
principal, desarrolladores y usuario experto. Los métodos Crystal recomiendan
diversas estrategias y técnicas para lograr agilidad. Un ciclo de proyectos
Crystal consta de gráficos, ciclo de entrega y de recapitulación.

Métodos Ágiles
Dynamic Systems Development Methods (DSDM)
 El marco Dynamic Systems Development Methods (DSDM) se publicó
inicialmente en 1995 y es administrado por el Consorcio DSDM.
 DSDM establece la calidad y el esfuerzo en términos de costo y el tiempo desde
el principio y ajusta los entregables del proyecto para cumplir con los criterios
establecidos, dando prioridad a las prestaciones en las siguientes categorías: lo
que "deben tener", "deberían tener", "podrían tener", y "no tendrán"
(mediante la técnica Priorización MoSCoW).
 DSDM es un método orientado al sistema con seis distintas fases de pre-
proyecto; Viabilidad; Fundamentos; Exploración e Ingeniería; Despliegue y
Evaluación de Beneficios.
Métodos Ágiles
Feature Driven Development (FDD)
 Feature Driven Development (FDD) fue presentado por Jeff De Luca en 1997 y
opera bajo el principio de la realización de un proyecto donde éste se separa en
pequeñas funciones valoradas por el cliente que pueden ser entregadas en
menos de dos semanas.
 FDD tiene dos principios - el desarrollo de software es una actividad humana y
el desarrollo de software es una funcionalidad valorada por el cliente.

Métodos Ágiles
Test Driven Development (TDD)
 También conocido como Test-First Development, Test Driven Development fue
presentado por Kent Beck, uno de los creadores de Extreme Programming (XP).
 Test Driven Development es un método de desarrollo de software que consiste
en escribir primero un código de prueba automatizado y en el desarrollo de la
menor cantidad de códigos necesarios para luego pasar la prueba.
Métodos Ágiles
Test Driven Development (TDD)
 También conocido como Test-First Development, Test Driven Development fue
presentado por Kent Beck, uno de los creadores de Extreme Programming (XP).
 Test Driven Development es un método de desarrollo de software que consiste
en escribir primero un código de prueba automatizado y en el desarrollo de la
menor cantidad de códigos necesarios para luego pasar la prueba.
 El Proyecto se divide en características pequeñas de valor para el cliente que
deben ser desarrolladas en el ciclo de desarrollo más corto posible.
 Las pruebas se escriben basadas en los requisitos y especificaciones de los
clientes. Las pruebas diseñadas en la fase precedente se utilizan para diseñar y
escribir el código de producción.
 TDD se puede clasificar en dos niveles: Acceptance TDD (ATDD) que requiere
una prueba de aceptación específica y Developer TDD (DTDD) que tiene que
ver con escribir sólo una prueba de desarrollador.

Métodos Ágiles
Adaptive Software Development (ASD)
 Adaptive Software Development (ASD) surgió a partir de la rápida labor de
desarrollo de aplicaciones por Jim Highsmith y Sam Bayer. Los aspectos más
destacados de los ASD son Adaptación constantes de los procesos de trabajo,
el suministro de soluciones a los problemas que surgen en los grandes
Proyectos, y el desarrollo incremental iterativo con prototipos continuos.
 Al ser un enfoque de desarrollo impulsado por el riesgo y tolerante de los
cambios, ASD indica que un plan no puede admitir las incertidumbres y
Riesgos, ya que eso sería indicativo de un plan deficiente.
 ASD se basa en las funciones y es impulsado por los objetivos. La primera fase
del desarrollo de ASD es Especular (a diferencia de Planificar), seguido por las
fases Colaborar y Aprender.
Métodos Ágiles
Agile Unified Process (AUP)
 Agile Unified Process (AUP) evolucionó del proceso llamado Rational Unified
Process de IBM. Desarrollado por Scott Ambler, AUP combina técnicas ágiles de
la industria ya probadas como Test Driven Development (TDD), Agile Modeling,
gestión del cambio ágil y la base de datos Refactoring para ofrecer un
Producto de trabajo de la mejor calidad.
 AUP modela sus procesos y técnicas basado en los valores de Simplicidad,
Agilidad, Personalización, Auto-organización, Independencia de las
herramientas, y se centra en actividades de alto valor. Los principios y valores
AUP se ponen en acción en las fases de Inicio, Elaboración, Construcción y
Transición.

Métodos Ágiles
Domain-Driven Design (DDD)
 Domain-Driven Design se trata de un enfoque de desarrollo ágil con la intención
de manejar diseños complejos con aplicación vinculada a un modelo en
evolución.
 Fue concebido por Eric Evans en el año 2004 y gira en torno al diseño de un
dominio básico. "Dominio" se define como un área de actividad a la que el
usuario aplica un Programa a o funcionalidad.
Ejercicio
La propuesta es trabajar con el siguiente ejemplo de requerimiento de
usuario de biblioteca y escribir las historias de usuario.
• Se quiere desarrollar un sistema sencillo de control de préstamos en una
biblioteca.
• El sistema debe admitir el alta y la baja de socios y de libros.
• Los socios pueden pedir libros en préstamo, pero no se pueden tener más
de tres libros en préstamo en un momento determinado.
• Los libros se han de devolver antes de un mes de la fecha del préstamo.
Cada vez que un socio devuelve un libro después de la fecha de la
devolución, se penaliza reduciendo en una unidad el número de libros que
puede tener simultáneamente.
• Cuando llega a cero el socio se da de baja automáticamente.

Ejercicio
Historia: Préstamo de libro
ID: 5
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro,
indicando su número de socio y la referencia del libro, siempre y cuando no tengan
ya tres libros en préstamo en ese momento.
Importancia: 300
Cómo probarlo:
Introducir un número de socio incorrecto y comprobar que se indica error
Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica
error
Introducir un libro del que no hay ejemplares y comprobar que se indica un error
Introducir todos los datos correctos y comprobar que el número de ejemplares
disponibles del libro disminuye y el número de préstamos del socio aumenta en
uno.
Historia Importancia Descripción
Alta libros 600 Dar de alta un libro en el sistema
Baja libros 250 Dar de baja un libro del sistema
Alta socio 500 Dar de alta un socio en el sistema
Baja socio 300 Dar de baja un socio del sistema
Pedir libro 350 Pedir prestado un libro
Devolver libro 340 Devolver un libro
Penalización socio 330 Penalizar al socio por retrasarse en la
devolución
Baja automática 320 Dar de baja automáticamente de socio
Iniciar sesión en el
sistema
550 Iniciar una sesión de usuario en el sistema
Cerrar sesión 500 Terminar sesión con el sistema
Alta usuario 450 Dar de alta un nuevo usuario en el sistema
Baja usuario 400 Dar de baja un usuario del sistema
Ejercicio

2. Justificación del negocio
Aspectos de SCRUM
Ciclo de Vida del Proyecto
Justificación del Negocio se prepara antes de iniciar un proyecto y se verifica de
forma continua durante todo el ciclo de vida del proyecto.
Aspectos de SCRUM
Técnicas de Estimación del Valor del Proyecto
Return On Investment (ROI), Net Present Value (NPV), Internal Rate of Return (IRR)
Return on Investment (ROI)
 Evalúa los ingresos netos que se esperan obtener a partir de un proyecto.
 Se calcula restando los costos o inversions estimadas de un proyecto de su
ingreso, y dividiendo esto (beneficio neto) por los costos previstos, con el fin de
obtener una tasa de retorno.

Aspectos de SCRUM
Net Present Value (NPV)
 Es un método para determiner el valor neto actual de un futuro beneficio
económico, dada una inflación prevista o tasa de interés.
 El NPV es el ingreso total esperado o los ingresos de un Proyecto, menos el costo
total previsto del Proyecto, teniendo en cuenta el valor temporal del dinero.
Aspectos de SCRUM
Internal Rate of Return (IRR)
 Es una tasa de descuento de una inversión en la que el valor presente de los
flujos de efectivo se hace igual al valor presente de los flujos de salida de
efectivo para evaluar la tasa de rentabilidad de un proyecto.

Aspectos de SCRUM
Técnicas de Planificación de Valor
Value Stream Mapping, Priorización basada en el valor del cliente
Value Stream Mapping
 Utiliza diagramas de flujo, para ilustrar el flujo de información necesaria para
completar un proceso.
 Esta técnica se puede utilizar para simplificar un proceso, ayudando a determinar
elementos que no añaden valor.
Aspectos de SCRUM
Prorización basada en el valor del Cliente
 Le otorga primordial importancia al Cliente y se esfuerza por poner en práctica
User Stories con el valor más alto primero.
 Estos User Stories con alto valor se idnetifican y se colocan en la parte superior
del Priorizited Product Backlog

Aspectos de SCRUM
Simples Schemes
 Implica etiquetar como prioridad “1”, “2”, “3” o “Alto”, “Medio” y “Bajo”
y así sucesivamente.
 Puede llegar a ser problemático porque a menudo hay una tendencia a
etiquetar todo como proridad “1” o “Alto”
 Incluso los métodos de priorización como “alto”, “medio” y “bajo”
pueden encontrarse con dificultades similares.
Aspectos de SCRUM
MoSCoW Priorization

Aspectos de SCRUM
Monopoly Money
Consiste en darle al Cliente “Monopoly Money” o “dinero falso” igual a la
cantidad de presupuesto del proyecto y pedirle que lo distribuya entre los
User Stories bajo consideración.
Aspectos de SCRUM
100 Point Method
Fue desarrollado por Dean Leffingwell y Don Widrig (2003). Se trata de
darle al cliente 100 puntos que puede usar para votar por las
características que considera más importantes.

Aspectos de SCRUM
Kano Analysis
Aspectos de SCRUM
Kano Analysis
Fue desarrollado por Nonaki Kano (1984) y consiste en clasificar las
características o requisites en cuatro categorías en function de las
preferencias del cliente:
 Los que complacen o deleitan (Delighters). Características nuevas o de
gran valor para el cliente.
 Satisfactores (Satisfiers). Características que le ofrecen valor al cliente.
 Insatisfactores (Dissatisfiers). Características de los cuales, si no
están presente, es probable al cliente no les gusta el producto, pero no
afectan el nivel de satisfacción si están presentes.
 Indiferente (Indifferent). Características que no afectarán al cliente de
ninguna manera y deben ser eliminadas.

Aspectos de SCRUM
Priorización relativa
 Una simple lista de los User Stories en el orden de prioridad es un método eficaz
para determiner los deseados User Stories para cada iteración o version del
producto o servicio.
 Definir las Características Mínimas del Mercado (Minimum Mareketable Features –
MMF), es importante en este proceso.
Aspectos de SCRUM
Story Mapping
 Técnica para proporcionar un esquema visual del producto y sus componentes
claves.
 Story Mapping, formulada por primera vez por Jeff Patton (2005), es
comúnmente utilizado para ilustrar la trayectoria del product.

Aspectos de SCRUM
Justificación continuo de valor
Análisis de Valor Ganado
Aspectos de SCRUM
Justificación continuo de valor
Cumulative Flow Diagram (CFD)
 Herramienta útil para la elaboración de informes y el seguimiento de los
resultados del proyecto.
 Se utilzia generalmente para proprocionar un estado de mayor nivel de la
totalidad del proyecto y no para actualizaciones diarias de Sprints individuales.

Aspectos de SCRUM
Cumulative Flow Diagram (CFD)
Aspectos de SCRUM
Confirmación de realización de beneficios
Prototipos, simulaciones y demostraciones
 Técnica común para confirmer valor.
 En el desarrollo de productos, esta experiencia del Cliente ha llegado a ser
conocida como IKIWISI (I’ll Know It When I See It).
 A través de demostraciones o el acceso a las iteraciones tempranas, Clientes
pueden también evaluar en qué medida el equipo ha sabido interpretar y
cumplido con sus expectativas.

3. Calidad
Aspectos de SCRUM
Definición de Calidad
 En Scrum se define la Calidad como la capacidad del producto o productos
entregables completados para cumplir los Criterios de Aceptación y alcanzar el
valor del negocio que espera el cliente.
 El ámbito de aplicación y requisites de calidad para un proyecto se determinan
tomando en cuenta varios factores:
 La necesidad del negocio que el proyecto cumplirá
 La capacidad y la Buena disposición de la organización para cumplir con las
necesidades del negocio
 Las necesidades futuras y actuales de la audiencia.
3. Calidad
Aspectos de SCRUM
Criterios de Aceptación
 Son componentes objetivos por los cuales se juzga la funcionalidad de un User
Story.
 Cada User Story estará asociado con los User Story Acceptance Criteria.
 Los criterios de aceptación son desarrollados por el Propietario del Producto, de
acuerdo a su conocimiento experto del requisito del cliente.
 Los criterios de aceptación deben describur explícitamente las condiciones que
los User Stories deben satisfacer.
 Los criterios de aceptación son específicos para cada User Story y no son
sustitutos de la lista de requisitos.
 Es importante para un Propietario del Producto señalar que las User Stories que
cumplen con la mayoría de los Criterios de Aceptación, pero no todos, no pueden
ser aceptados como Done.

3. Calidad
Aspectos de SCRUM
Criterios de Aceptación Mínimo
 Una unidad de negocio de alto nivel puede anunciar un Criterio de Aceptación
mínimo y obligatorio, lo cual luego se puede convertir en parte de lso Criterios de
Aceptación para cualquier User Story de esa unidad de negocio.
3. Calidad
Aspectos de SCRUM
Criterios de Aceptación

3. Calidad
Aspectos de SCRUM
Definición de Done (Terminado)
 Hay una diferencia fundamental entre Done Criteria y Acceptance Criteria.
Mientras que los Acceptance Criteria son únicos para los User Stories
individuales, Done Criteria es un conunto de reglas que se aplican a todos los
User Stories en un determinado Sprint.
 Los Done Criteria generales podría incluir cualquiera de los siguientes:
 Fueron repasados por otros miembros del equipo
 Se complete la prueba de unidad del User Story
 Llevar a cabo pruebas de Quality Assurance
 Finalización de toda la documentación relacionada con los User Stories
 Todos los issues están arreglados
 La demostración exitosa a los Socios y/o representantes de la empresa
 Al igual que con los Acceptance Criteria, todas las condiciones de los Done
Criteria se deben cumplir para que el User Story sea considerado como Done.
3. Calidad
Aspectos de SCRUM
Gestión de Calidad en Scrum
 Planificación de Calidad
 Control de Calidad
 Aseguramiento de Calidad

3. Calidad
Aspectos de SCRUM
 Planificación de Calidad
 Un beneficio clave es la reducción de Technical Debt (Deuda Técnica), que
es la deuda de diseño o deuda de código, se refiere al trabajo que los
equipos priorizan como inferior, omiten o no se completan a medida que
trabajan hacia la creación de los entregables principals asociados con el
producto del proyecto.
 Technical Debt se acumula y se debe pagar en el futuro. Algunas causas:
 Prueba inadecuada o incomplete
 Documentación incorrecta o incomplete
 Pobre intercambio de conocimiento del negocio y el conocimiento del proceso
entre Socios y equipos del proyecto.
 En los proyectos, cualquier Technical Debt no llegará más allá de un
Sprint, porque debe haber Acceptance y Done Criteria que estén
claramente definidos.
3. Calidad
Aspectos de SCRUM
 Plan – Do – Check – Act Cycle
 Conocido como el Deming o Shewhart Cycle. Fue desarrollado por el Dr.
W. Edwards Deming, considerado el padre de control de calidad moderna
y el Dr. Walter A. Shewhart.

4. Cambios
Aspectos de SCRUM
4. Cambios
Aspectos de SCRUM

5. Riesgos
Aspectos de SCRUM
Procedimiento de Gestión de Riesgos
 Identificación de Riesgos
• Repasar las lecciones aprendidas de Retrospectiva del Sprint o de procesos de
Retrospectiva del proyecto
• Checklist de Riesgos
• Tormenta de Ideas
• Risk Breakdown Structure (RBS)
 Evaluación de Riesgos
• Reunión de Riesgos
• Ärbol de Probabilidades
• Análisis de Pareto
• Matriz Impacto Probabilidad
• Valor Monetario Esperado (EMV)
 Prorización de Riesgos
 Mitigación de Riesgos
 Comunicación de los riesgos
5. Riesgos
Aspectos de SCRUM
Risk Burndown Chart

Preguntas?

Scrum Master Developer Capitulo 3

Más contenido relacionado

La actualidad más candente (20)

Similar a Scrum Master Developer Capitulo 3 (20)

Último (20)

Scrum Master Developer Capitulo 3