Proyectos de Software

ZUE
Definición de SCRUM:

• Es un proceso ágil que nos permite centrarnos en ofrecer el

más alto valor de negocio en el menor tiempo.

• Nos permite rápidamente y en repetidas ocasiones

inspeccionar software real de trabajo (cada dos semanas o
un mes).

• El negocio fija las prioridades. Los equipos se auto-

organizan a fin de determinar la mejor manera de entregar
las funcionalidades de más alta prioridad.

• Cada dos semanas o un mes, cualquiera puede ver el

software real funcionando y decidir si liberarlo o seguir
mejorándolo en otro sprint.
 Scrum ha sido utilizado para:

• Software comercial • Desarrollo de video juegos

• Desarrollos internos • Software de control satelital
• Desarrollos bajo Contrato • Sitios Web
• Aplicaciones Financieras • Software para Handheld
• Aplicaciones certificadas ISO • Teléfonos portátiles
9001
• Aplicaciones de Network switching
• Sistemas Embebidos
• Aplicaciones de ISV
• Sistemas con requisitos 7x24 y
• Algunas de las más grandes
99.999% de disponibilidad
aplicaciones en uso
El Manifesto Ágil
Una declaración de valores

Individuos
Individuos ee interacciones
interacciones sobre Procesos
Procesos yy herramientas
herramientas

Software
Software que
que funciona
funciona sobre Documentación
Documentación exhaustiva
exhaustiva

Colaboración
Colaboración con
con el
el cliente
cliente sobre Negociación
Negociación de
de contratos
contratos

Responder
Responder ante
ante el
el cambio
cambio sobre Seguimiento
Seguimiento de
de un
un plan
plan
Pasos Básicos de SCRUM:
24 horas

4- Sprint
2-4 semanas
2- Objetivo del Sprint

3- Sprint
5- Producto:
Backlog
Incremento del producto
potencialmente entregable

1- Product Backlog: Conjunto de

Historias o Requerimientos
Desarrollo Secuencial
vs.
Superpuesto

Requisitos Diseño Código Test

En lugar de hacer todo de

una cosa a la vez ...
...los equipos Scrum hacen
un poco de todo todo el
tiempo

Source: “The New New Product Development Game”

by Takeuchi and Nonaka. Harvard Business Review,
January 1986.
Scrum Framework

Roles
• Dueño del producto
• ScrumMaster
• Equipo Reuniones
• Planeación de Sprint
• Reunión diaria de Scrum
• Demostración de Sprint
• Retroalimentacion de
Sprint Artefactos
• Product backlog
• Sprint backlog
• Cuadro de Seguimiento
Dueño del
Producto

• Define las funcionalidades del producto

• Decide sobre las fechas y contenidos de los releases
• Es responsable por la rentabilidad del producto (ROI)
• Prioriza funcionalidades de acuerdo al valor del
mercado/negocio
• Ajusta funcionalidades y prioridades en cada iteración si
es necesario
• Acepta o rechaza los resultados del trabajo del equipo
El ScrumMaster

• Representa a la gestión del proyecto

• Responsable de promover los valores y prácticas de
Scrum
• Remueve impedimentos
• Se asegura de que el equipo es completamente
funcional y productivo
• Permite la estrecha cooperación en todos los roles y
funciones
• Escudo del equipo de interferencias externas
El Equipo

• Típicamente de 5 a 9 personas
• Multi-funcional:
– Programadores, testers, analistas, diseñadores, etc.
• Los miembros deben ser full-time
– Puede haber excepciones (Ej.: Infraestructura, SCM,
etc.)
• Los equipos son auto-organizativos
– Idealmente, no existen títulos pero a veces se utilizan de
acuerdo a la organización
• Solo puede haber cambio de miembros entre los sprints
Preparación para la
Planeación de Sprint:

• La pila de producto debe existir !

• Debe haber una Pila de Producto y un dueño de producto
por producto.
• Todos los elementos importantes deben tener diferentes
ratios de importancia.
• El dueño de producto debe comprender cada historia (no
necesita saber cómo exactamente debe implementarse,
pero debe entender por que la historia está ahí).
Preparación para la
Planeación de Sprint:

NOTA:
Otras personas aparte del Dueño de Producto pueden
añadir sus historias a la Pila de Producto. Pero no pueden
asignarles niveles de importancia, ese es un cometido
exclusivo del dueño del Producto. Tampoco pueden
establecer estimaciones, ese es un cometido exclusivo del
Equipo.
Reunión de Planeación
de Sprint:
• Probablemente la más importante del Scrum.
• El propósito es proporcionar al equipo suficiente
información como para que puedan trabajar.
• Produce:
• Una meta de Sprint.
• Una lista de miembros (y su nivel de dedicación).
• Una Pila de Sprint.
• Una fecha concreta para la Demo de Sprint.
• Un lugar y momento definidos para el Scrum diario.
Por qué debe asistir el
Dueño de Producto

PO
Alcance

Estimación Importancia PO
SM
Por qué la Calidad no es
negociable
• Calidad externa: es lo que perciben los usuarios del
sistema. Una interfaz de usuario lento y poco intuitivo es un
ejemplo de baja calidad externa.
• Calidad interna: aspectos que normalmente no son visibles
al usuario, pero que tienen un profundo efecto en la
mantenibilidad del sistema. Ej.: Consistencia del diseño,
legibilidad del código, refactorización, etc.

Un sistema con alta calidad interna puede, aun así, tener

una baja calidad externa. Pero un sistema con baja calidad
interna rara vez tendrá buena calidad externa. Es difícil
construir algo sobre unos cimientos podridos.
Reunión de Planeación
de Sprint:

Capacidad
Capacidad Sprint Planning Meeting
del
del Equipo
Equipo
Priorización
Product
Product • Analizar y evaluar el Product Backlog Objetivo
Objetivo del
del
• Seleccionar el objetivo del Sprint Sprint
Sprint
Backlog
Backlog

Condiciones
Condiciones
del
del Negocio
Negocio Planificación
• Decidir como alcanzar el objetivo del
Producto Sprint (diseño)
Producto Sprint
Sprint
Actual • Crear el Sprint Backlog (tareas) en
Actual base a los temas del Product Backlog
Backlog
Backlog (user stories / features)
Tecnología • Estimar Sprint Backlog en horas
Tecnología
Reunión diaria de
Scrum
• Parámetros
– Diaria
– Dura 15 minutos
– Participantes de pie.
• No para la solución de problemas
– Todo el mundo está invitado
– Sólo los miembros del equipo, ScrumMaster y Dueño
del Producto, pueden hablar
– Ayuda a evitar otras reuniones innecesarias
Demostración de
Sprint
• El equipo presenta lo realizado durante el sprint
• Normalmente adopta la forma de una demo de las nuevas
características o la arquitectura subyacente
• Informal
– Regla de 2 hs preparación
– No usar diapositivas
• Todo el equipo participa
• Se invita a todo el mundo
 Retroalimentación de
Sprint
• Periódicamente, se echa un vistazo a lo que funciona y lo
que no
• Normalmente 15 a 30 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa
– ScrumMaster
– Product owner
– Equipo
– Posiblemente clientes y otros
 Pila de Producto

• La pila de producto es el corazón del Scrum.

• Lista priorizada de requerimientos o “historias”.
• Se realiza luego de cada sprint
• Todo el equipo participa
– ScrumMaster
– Product owner
– Equipo
– Posiblemente clientes y otros
Decidiendo qué historias
incluir en el Sprint
PILA DE PRODUCTO PILA DE SPRINT 1
¿Cómo puede el Dueño de Producto
alterar las historias que se incluyen en el
Sprint?

PILA DE PRODUCTO

VELOCIDAD ESTIMADA
¿Cómo puede el Dueño de Producto
alterar las historias que se incluyen en el
Sprint?

Repriorizar Cambiar el Alcance

Dividir una Historia

 ¿Cómo decide el equipo qué historias
incluir en el Sprint?

• Estimando a ojo de buen cubero.

• Estimando usando cálculos de velocidad.

1. Decidir la velocidad estimada.
2. Calcular cuántas historias se pueden añadir sin
sobrepasar la velocidad estimada.
Usando cálculos de velocidad
Usando cálculos de velocidad

Digamos que estamos planificando un Sprint de 3 semanas (15 días

laborables) con un equipo de 4 personas. Lisa estará de vacaciones 2 días.
Dave sólo estará disponible al 50% y estará un día de vacaciones.
Poniéndolo todo junto…

DÍAS DISPONIBLES

50 DÍAS-HOMBRE DISPONIBLES
Usando cálculos de velocidad

…50 DÍAS-HOMBRE DISPONIBLES

Es ésta nuestra velocidad estimada?

¡No! Porque nuestra unidad de estimación son puntos de historia lo que, en
nuestro caso, corresponde más o menos a “días-hombre ideales”. Un día-
hombre ideal es un día perfectamente efectivo, sin distracciones, lo cuál es
raro. Lo que es más, debemos tener en cuenta cosas como trabajo no
planificado que se añade al Sprint, gente que se pone enferma, etc.

Así que nuestra velocidad estimada será sin duda menor de 50. ¿Pero cuanto
menor? Para esto usamos el “factor de dedicación”.
Velocidad estimada de este Sprint

(DÍAS-HOMBRE DISPONIBLES) X (FACTOR DE DEDICACIÓN) = VELOCIDAD ESTIMADA

Factor de Dedicación

(VELOCIDAD REAL)
(FACTOR DE DEDICACIÓN) = --------------------------------------------------
(DIAS-HOMBRE DISPONIBLES)

La velocidad real es la suma de las estimaciones iniciales que se

completaron en el último Sprint.

Digamos que en el último Sprint se completaron 18 puntos de historia

utilizando un equipo de 3 personas formado por Tom, Lisa y Sam trabajando
las tres semanas hasta un total de 45 días-hombre. Y ahora estamos
intentando calcular la velocidad del próximo Sprint. Para complicar las cosas,
un nuevo tipo, Dave, se une al equipo para este Sprint. Teniendo en cuenta
las vacaciones y demás asuntos tenemos 50 días-hombre ideales este Sprint.
Factor de Dedicación

(18 PUNTOS HISTORIA)

(40%) = ------------------------------------- 50 DÍAS-HOMBRE X 40% = 20 PUNTOS-HISTORIA
(45 DÍAS-HOMBRE)

COMIENZO DEL SPRINT

19 PUNTOS DE HISTORIA INCLUIDOS EN EL SPRINT

No entran en Sprint
Por qué usamos tarjetas
Historia
Terminado y Estimación
• Definición de “terminado”

• Estimación de tiempos usando planning poker.

Clarificando historias

¿Cómo te aseguras de que el concepto

que tiene el Dueño de Producto sobre una
historia coincida con el concepto del
equipo?

¿O de que cada miembro del equipo tenga

el mismo concepto sobre la historia?
Clarificando historias

• Dividiendo historias en historias más

pequeñas
• Dividiendo las historias en tareas.
Sistema de seguimiento de
errores vs. Pila de Producto

Opciones:

• La corrección de errores se considera algo fuera del Sprint. El

equipo mantiene un factor de dedicación suficientemente bajo (por
ejemplo, el 50%) para asegurar que tienen tiempo suficiente para
arreglar errores

• Tratar los errores como cualquier otra historia.

Cómo comunicamos los Sprint
Cómo comunicamos los Sprint
Cómo hacemos pilas de Sprint
Cómo funciona el tablón de
tareas
Ejemplo 1. Tras el primer Scrum
diario
Ejemplo 2. Tras unos cuantos
días
Cuadro de
Seguimiento
Cómo funciona el diagrama
burn-down
Señales de alarma en el
burn-down
Señales de alarma en el
burn-down
Señales de alarma en el
burn-down
Señales de alarma en el
burn-down
Cómo distribuimos la sala del
equipo
Cómo distribuimos la sala del
equipo
Mejores prácticas

• Sienta al equipo junto !

• Mantén al Dueño de Producto a mano.
• Mantén a los Gerentes y Coach a mano.
Cómo hacemos los Scrum
diarios

• Frente al tablón de tareas.

• 15 minutos.
• Se actualiza el tablón de tareas.
• Cada persona describe:
• Que hice ayer.
• Que voy a hacer hoy.
• Que inconvenientes tengo.
Cómo hacemos los Scrum
diarios
Cómo hacemos la Demo de
Sprint

La demo de Sprint (o revisión de Sprint, como la llaman algunos) es una

parte importante de Scrum que la gente tiende a subestimar.

“Oh, ¿realmente tenemos que hacer una demo? ¡En realidad no hay mucho
que podamos enseñar!”

“¡No tenemos tiempo para montar una &%$# demo!”

“¡No tengo tiempo para asistir a las demo!”

Cómo hacemos
Retrospectivas de Sprint

Lo más importante de las retrospectivas es asegurarse de que tienen lugar.

Es el segundo evento más importante de Scrum (siendo el primero la

reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para
mejorar!

Sin las retrospectivas encontrarás que el equipo sigue cometiendo los

mismos errores una y otra vez.
Cómo hacemos
Retrospectivas de Sprint

• Bien: si hiciéramos el Sprint otra vez, volveríamos a hacer estas cosas igual.
• Mejorable: si hiciéramos otra vez el Sprint, haríamos estas cosas de forma diferente.
• Mejoras: ideas concretas sobre cómo podemos mejorar en el futuro.
Descansos entre Sprints
Descansos entre Sprints
Descansos entre Sprints
Gracias