BarCamp Scrum Col30-2015
-
Upload
julian-r-figueroa -
Category
Technology
-
view
395 -
download
0
Transcript of BarCamp Scrum Col30-2015
Contenidos de la charla
● Tipos de proyectos● Manifiesto ágil● Marco Scrum● Roles● Actividades● Artefactos● Reglas Scrum● Datos Scrum● Pros/Cons/Tips Scrum
40 minutos
“Es un marco de trabajo en el que las personas
pueden hacer frente a problemas complejos
adaptables, mientras que de manera
productiva y creativa entregan productos del
mayor valor posible. Scrum es:
● Ligero
● Fa ́cil de entender
● Difi ́cil de dominar”
Ken Schwaber & Jeff Sutherland
¿Qué es Scrum?
● Simple
● Complicado
● Complejo
● Anárquico
David J. Snowden & Mary E. Boone
Harvard Business Review 2007
Tipos de proyecto
Tipos de proyecto: Definiciones
Simple Complicado Complejo Anárquico
- Caótico
Desorden
Detectar,
categorizar,
responder
Detectar, analizar,
responder
Probar, detectar,
responder
Actuar, detectar,
responder
Encontrar dominio
correcto
Basado en
prácticas
establecidas
Afrontar situación,
investigar opciones
Explorar y aprender
del problema
Actuar en
búsqueda de
estabilización
No actuar dada la
preferencia
personal o método
conocido. Hay que
encontrar el
dominio.Dominio de las
mejores prácticas
Expertos para ganar
“insight”
Ambientes de fallo
seguro para
experimentar
Buscar lo que
funcione, en vez
de LA respuesta
Causa-efecto
claro y evidente
Múltiples opciones
correctas
Explorar,
inspeccionar,
adaptarse
Muchas
decisiones, poco
tiempo
Tipos de proyecto: Ejemplos
Simple Complicado Anárquico
- Caótico
Caótico
Detectar,
categorizar,
responder
Detectar, analizar,
responder
Probar, detectar,
responder
Actuar, detectar,
responder
Call-center, construcción,
comercio franquicias
Mantenimiento de software, minería o
petróleos
Modelos de negocio digitales,
productos nuevos e innovadores
Bolsa de valores, línea de
emergencias
Dominio Complejo: Agile Manifiesto
Estamos descubriendo formas mejores de desarrollar
software, tanto por nuestra propia experiencia como
ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
Personas e interacciones
sobre
procesos y herramientas
Software funcionando documentación
comprensible
Colaboración con clientes negociación de contratos
Responder a los cambios seguir un plan
www.agilemanifesto.org
“Es un marco de trabajo en el que las personas
pueden hacer frente a problemas complejos
adaptables, mientras que de manera
productiva y creativa entregan productos del
mayor valor posible. Scrum es:
● Ligero
● Fa ́cil de entender
● Difi ́cil de dominar”
Ken Schwaber & Jeff Sutherland
¿Qué es Scrum?
“Es un marco de trabajo basado en un
conjunto de valores, principios y pra ́cticas
que suministran los fundamentos para que
cada organizacio ́n le agregue su
implementacio ́n u ́nica.”
Kenneth Rubin, Essential Scrum
¿Qué es Scrum?
● Me ́todo a ́gil ma ́s popular
● Puede complementarse para convivir con otras
metodologi ́as
● Equipos auto-organizados
● Equipos enfocados a resultados
● Adaptacio ́n conti ́nua
● Centrado en personas
● No solamente software
● Valores y pra ́cticas administrativas (SM)
● Te ́cnicas de desarrollo (SD)
¿Qué es Scrum?
¿Por qué Scrum?
● Proyectos de software
● ¿“El cliente siempre tiene la razón”?
● El cliente en verdad muchas veces no sabe lo que
quiere
● Calidad de software
● Rápido testeo
● Rápidos resultados
● Costos reducidos a largo plazo
Scrum: Roles de un Scrum Team (ST)
Nombre del Rol Abreviación Cantidad Recomendaciones
Product Owner PO 1 Conocedor de negocio, parte
del cliente, en contacto
constante con usuarios e
interesados
Scrum Master SM 1 x ST Capacitado en la
metodología, conocimiento
sólido en negocio y tecnología
Scrum Developer
(Development
Team)
SD (DT) 4-9 Equipo auto-organizado y
multidisciplinario
● Centro de empoderamiento de las características del
producto
● Principal responsable por el avance y la entrega
definitiva
● Autoridad primaria en el orden y la importancia de las
características del producto
● El PO colabora constantemente con dudas de negocio
del DT y el SM
Product Owner (PO)
● Lider servil
● Colabora con el entendimiento y la aplicación de los
valores, prácticas y principios de Scrum (agile
approach)
● Remueve obstáculos del equipo de desarrollo y los
protege de interferencias externas
● NO ES UN PROJECT MANAGER, no tiene autoridad
sobre prioridades o métodos de implementación
Scrum Master (SM)
● No hay roles específicos, sino uno
transversal
● Equipo multifuncional
● Auto-organizado para asumir y
auto-asignar tareas definidas en
cada Sprint
● Actitud mosquetero
● Todo el equipo es responsable de
la construcción del producto
● Habilidades “T”
Scrum Developer (SD) → (DT)
Scrum: Artefactos
Nombre del Artefacto Abreviación
Product Backlog PB
Sprint Backlog SB
Potentially Shippable Product
Increment
PSPI - PI
● Lista priorizada y
secuencial de
características o “historias
de usuario”
● Basada en la visión de
producto del PO
● Responsabilidad del PO
● Siempre el trabajo más
valioso va primero, y va
más detallado
Product Backlog (PB)
Sprint Backlog (SB)
● Lista prevista de desarrollo
o ejecución para un (1)
Sprint
● Items primeros en el PB,
con estimación acorde al
Sprint
● Desagregado de los items
del PB en tareas
específicas y asignadas en
el DT
● Items susceptibles de ser
afrontados con KANBAN
Potentially Shippable Product Increment (PSPI - PI)
● Una parte o sección de
producto construida o
“hecha”
● Parte o sección dispuesta a
ser liberada
● La liberación es una
decisión de negocio, no es
imperativo
Scrum: Actividades
Actividad Duración
Sprint 1-4 semanas (4)
Sprint Planning 8 horas
Daily Scrum 15 minutos (indiferente de la
duración del Sprint)
Sprint Execution 4 semanas
Sprint Review 4 horas
Sprint Retrospective 3 horas
Product Backlog Grooming Continuo durante ejecución
Sprint
● Corazón de Scrum
● Cajas de tiempo que tienen un inicio y finales FIJOS
● Generalmente recomendados de una misma duración
(1-4 semanas)
● La finalización de un Sprint es seguida inmediatamente
del inicio del siguiente
Sprint Planning
● Primera actividad
dentro del Sprint
● Reunión de revisión de
PB para llegar a
acuerdos
● PO, SM, DT
● Selección de común
acuerdo de X cantidad
de ítems del PB → SB
● Estimación de ítems
(generalmente horas)
● Ítem > Tareas > Llenar la
capacidad
Daily Scrum
● Revisión de inspección y
adaptación.
● SM, DT, PO (pasivo)
● “Daily stand-up”
● Generalmente:
● ¿Qué logré desde el
último Daily?
● ¿Cuál es mi plan para el
siguiente Daily?
● ¿Qué obstáculos
enfrento?
● Gallinas y cerdos
Sprint Execution
● Ejecución de las tareas dada
su estimación, asignación y
adaptación en los daily
● El equipo debe estar
protegido de interferencias
externas
● El PB y SB deben estar
siempre a la vista, y
actualizado
● El control se hace
generalmente con KANBAN
● Gráfica Burndown
Sprint Review
● Revisión de características internas
(“hecho”)
● Revisión del PSPI
● PO, SM, DT, Clientes, Usuarios,
Interesados
● Centrada en las características
terminadas
● Información bidireccional de avance y
ajuste de la dirección e importancia del
PB restante
● Todos obtienen visibilidad de lo que está
ocurriendo y del estado del proyecto
Sprint Retrospective
● Inspeccionar y adaptar el
proceso
● Reunión interna del ST
para revisar cuán
colaborativo y productivo
es el equipo
● Identificar obstáculos y
comprometerse con
acciones concretas de
mejora
Product Backlog Grooming
● El grooming consiste en el refinamiento, estimación y priorización de los ítems del PB.
● Participación significativa de interesados, SM y DT en cabeza del PO
● Generalmente 10% del tiempo del DT debe estar dispuesto a ayuda del PBGrooming basados en:○ Dependencia técnica○ Restricciones de
recursos
★ Variabilidad e incertidumbre
○ Acoge la variabilidad útil,
desarrollo iterativo e incremental,
reduce incertidumbre
simultáneamente (end, means,
customer)
★ Predicción y adaptación
○ Mantén opciones abiertas, no
puedes lograrlo todo desde el
inicio, favorece la exploración y
adaptación, sé sensible
económicamente
★ Aprendizaje validado (LEAN)
○ Valida en vez de asumir,
aprovecha la retroalimentación
Scrum: Reglas
★ Trabajo en progreso
○ Usa tamaños de carga
económicamente sensibles,
enfócate en trabajo en espera, y
no en trabajadores en espera
★ Progreso
○ Entregado y validado, enfócate
en la entrega centrada en valor,
el progreso ayuda a adaptar y re-
planear
★ Rendimiento
○ Vé rápido pero no te apures,
construye con calidad, emplea
mínima/suficiente
ceremonia/protocolo
Datos Scrum: Adopción
La adopción de Scrum en empresas de software existentes depende de su ubicación en la curva de innovación
Datos Scrum: Modelo de Cambio
Virginia Satir (1991, 1997)
http://stevenmsmith.com/ar-satir-change-model/
Datos Scrum: Adopción
Pregunta Razón Primer Resultado
Causa de fracaso en ágil Filosofía de la compañía o
desacuerdo fundamental cultural
13%
Obstáculos al adoptar ágil Habilidad para cambiar cultura
organizacional
53%
Preocupaciones sobre
adoptar ágil
Falta de planeación anticipada 30%
Resultados (tiempos) en
proyectos ágiles
Más rápida 73%
Beneficios obtenidos Habilidad para cambiar
prioridades
92%
Ayudas para implementación Apoyo de la gerencia 22%
Datos Scrum: PROs
● El cliente obtiene resultados importantes/utilizables
desde etapas tempranas
● Se comienza el proyecto con requerimientos de alto
nivel
● Los cambios se administran de manera natural
● Se mitigan los riesgos del proyecto desde el inicio
● Se gestiona la complejidad al apuntar a la construcción
de aquello que brinda más valor
● Se optimizan los recursos disponibles
● Se minimizan el número de errores y se aumenta la
calidad
Datos Scrum: CONs
● La disponibilidad del cliente e interesados debe ser alta
durante el proyecto
● El PO debe tener disponibilidad de manera continua
(igual que los SD)
● La relación con el cliente es más colaborativa que
contractual (modelo de cambio)
● Es una metodología recomendada para proyectos de
dominio complejo
Scrum: Fuentes Principales
● SEONTI - Scrum Methodology Certification● Essential Scrum - Kenneth S. Rubin● Agile Manifesto