taller agil scrum master

Luis Alberto Espinoza Bustamante

SCRUM Master Certified

Área Arquitectura y Calidad

Mes 2 Mes 3 Mes 4 Mes 1

Requerimientos y Análisis

Diseño

Construcción

Pruebas

Plan

Puesta Marcha

Requerimientos

• Fondo Simple • Retrato mujer • Pelirroja • Vista cautivante • Sonrisa delicada

Cambios • Paisaje de fondo • Morena

Product Backlog

Sprint Backlog

Sprint

Reunión diaria

Solucion Funcionando

15 min

4 semanas

Sprint Planning

8 horas

Sprint review 4 horas

Sprint retrospect

4 horas

Release Plan

Vision Statement

Mes 2

Sprint

Solución Funcionando

Mes 3

Sprint

Solución Funcionando

Mes 4

Sprint

Solución Funcionando

Mes 1

Product Backlog

Product Backlog (req. priorizados) 1. Retrato mujer 2. Vista cautivante 3. Sonrisa delicada 4. Fondo Simple 5. Pelirroja

Cambios • Paisaje de fondo • Morena

Cliente no sabe lo que quiere.

Tecnologías Nuevas.

No se sabe como se va a implementar.

No se tiene experiencia en el tipo de implementación.

Proyectos de Innovación.

Constante Cambio Requerimientos.

Mercado Ágil (constante cambio en Mercado). Nuevos Producto, alta competencia, cambio tecnologías.

Importancia Time 2 Market

Proyectos con mucha Incertidumbre.

Proyectos que deben ser Flexibles.

Proyecto Adecuado

Para método

Tradicional

Proyecto Adecuado

para método

Ágil

Empirical Control: decisiones basadas en observación (transparencia, inspección) y adaptación. Avance tangible.

SelfOrganization: los equipos se auto organizan, son crossfunctional.

Colaboration: dentro del equipo y con áreas de negocio (stakeholders)

Priorization: priorización basada en valor de negocio, el mayor valor en menor tiempo.

TimeBoxing: tiempo como restricción, marca un ritmo, y asegura avance.

Iterative: entrega y mejoramiento continuo, asegurando incorporar cambios.

Product Owner: Responsabilidad Gestor Requerimientos

Scrum Master: Responsabilidad líder proyecto

Taller SCRUM Inspección

Ágil (sonar Qube)

Servidor Integrac. Continua

POC JIRA Mejorar

Seguimiento Proyectos

Integración Continua

Mejorar Control Versiones

Sala Reuniones Ágil (Head Quarters)

Mejorar Calidad Soluciones

Mejorar Oportunidad) Entrega Soluciones

S.W.A.T. (Equipo 4 SCRUM)

Mejorar Gestión de Proyectos

Optimizar Metodología. Desarrollo Certific.

SCRUM Master

Epic

User Story

Como Jefe de Proyecto Quiero se asignen tareas instalación Para que agilice paso a pruebas y producción

Instalar Jira

Crear Flujo Task

Criterios Aceptación Debe mostrar

tareas asignadas a DBA

Solo si todas tareas instalación completas se cierra paso

Como (rol usuario) Quiero (funcionalidad deseada) Para que (valor-beneficio)

Criterios Aceptación Verificar que … Debe… Probar…

Requerimiento

INVEST Independiente (encapsulada) Negociable (puede cambiar) Valorizable (valor negocio) Estimable (estimar tamaño) Sostenible (puede manejar) Testeable (puede probar)

Mejorar Gestión de Proyectos

Size 12

Sol01: Gestión Ágil

por qué? JP no revisa entregable

Proyecto con Errores Básicos de Desarrollo

por qué? No tiene tiempo

por qué? Tiene

muchas Responsab.

por qué? Desconoce

Básico Tecnología

Sol02: Capacitar

JP

por qué? JP no tiene

Analista

por qué? ascendieron

a JP

Sol03: Volver

Potenciar Analista en Desarrollo

por qué? proveedor

sin expertise

por qué? JP no conoce

Capacidad proveedor

Sol: Evaluación

Post Mortem

Sol: Evaluación Prueba

Conceptos

Sol04: Evaluación

Previa Prueba Práctica

Sol05: SonarQube

Evaluar Historia

Sol06: Proveedor certificado

Sol07: JP más

Exigente Solicite cambio

En el producto Backlog solo quedan las “User Stories”.

Ahora se deben priorizar según su Valor (Valor de Negocio)

Primero se toman 2 y se identifica la mas importante en términos de su mayor aporte al proyecto.

Luego se toma la siguiente y de abajo hacia arriba se va comparando hasta encontrar su nivel de prioridad.

Como Liquidador Quiero ver la carpeta del Siniestro Para responder oportunamente al Cliente

5

Cada User Story deme ser estimado en su “Size”

El Size se define en puntos de historia (User Point).

Y el Size refleja la complejidad relativa de un Requerimiento.

Para su estimación se usa la técnica del “Scrum Pocker” (técnica bajo “Gamification”).

La ventaja de esta técnica es que se hace cargo de la incertidumbre, por ejemplo cuando se desconoce la tecnología de desarrollo.

https://www.youtube.com/embed/KdyV9okLRlc?autoplay=1&rel=0&wmode=transparent