PROGRAMACION AGIL:

“ SCRUM Y XP ”

Funte: U Mayor.
Practia Consulting
SCRUM

Gestión Ágil de Proyectos

¿Qué Es SCRUM?
 aproximación holística en la cual las fases se solapan de
manera intensa y el proceso completo es realizado por un
equipo con funciones transversales, con el rugby, donde el
equipo entero "actúa como un solo hombre para intentar llegar al
otro lado del campo, pasando el balón de uno a otro".
 SCRUM es una metodología ágil de gestión de proyectos cuyo
objetivo primordial es elevar al máximo la productividad de un
equipo.
 Reduce al máximo la burocracia y actividades no orientadas a
producir software que funcione y produce resultados en periodos
muy breves de tiempo (cada 30 días), por medio de iteraciones o
Sprints.
 Ideal para proyectos con un rápido cambio de requerimientos.
Contexto SCRUM
 Sólo abarca prácticas de gestión sin entrar en las
prácticas de desarrollo como puede hacer XP.
 Delega completamente en el equipo la
responsabilidad de decidir la mejor manera de
trabajar para ser lo más productivos posibles y, le
da gran protagonismo a las reuniones que realicen
a lo largo del proyecto.
 Sus raíces teóricas están en las teorías de la auto-
organización.
 Actores SCRUM

Propietario del producto

Representa a todos los interesados en el
producto final.
Sus áreas de responsabilidad son:
 Financiación del proyecto.
 Retorno de la inversión del proyecto.
 Lanzamiento del proyecto.

Ingeniería De Software Santiago, 16 Diciembre 2005 5/30

Actores SCRUM

Equipo
Responsable de transformar el Backlog de la
iteración en un incremento de la
funcionalidad del software.
 Auto-gestionado.
 Auto-organizado.
 Multi-funcional.
Actores SCRUM

Scrum Master
Responsable del proceso Scrum.
 Formación y entrenamiento del proceso.
 Incorporación de Scrum en la cultura de la
empresa.
 Garantía de cumplimiento de roles y
responsabilidad.
Metodología De Trabajo
 Equipos de entre 6 y 10 personas revisan los
requisitos, la tecnología disponible y evalúan los
conocimientos para colectivamente determinar
como incrementar la funcionalidad.
 Reuniones diarias, antes de empezar a trabajar, con
una duración máxima de 4 hrs.
 Se llevan a cabo hasta que el proyecto este listo
para ser puesto en producción o ser lanzado al
mercado.
Metodología De Trabajo
 En la primera reunión se explica al equipo la forma de trabajo,
especificando que son reuniones cortas para coordinar trabajo y
no para solucionar problemas. Se establecen los criterios para
arreglar los errores por prioridades (base del éxito del
sistema).
 Al inicio de cada iteración se revisa el trabajo pendiente en el
proyecto y se selecciona la parte a la cual se le incrementara
funcionalidad, para al final de la iteración incorporarla al SW y
presentársela a las partes involucradas.
 En cada reunión las preguntas claves a contestar son:
 ¿Qué es lo que se hizo desde la última reunión?

 ¿Qué es lo que se va a hacer hasta la siguiente reunión?

 ¿Cómo se va a llevar a cabo?

Artefactos SCRUM

Sprint
 Es la base del desarrollo Scrum.
 Su duración máxima es de 30 días.
 Se llevan a cabo las tareas pre-establecidas y no se puede
modificar el trabajo acordado en el backlog.
 Sólo el ScrumMaster puede abortar un sprint si lo
considera no viable por alguna de las sgtes. razones:
 Las circunstancias del negocio han cambiado.
 La tecnología acordada no funciona.
 El equipo ha tenido interferencias.
Artefactos SCRUM
Product Backlog
 Crea un listado con los requisitos de los usuarios
o propietarios del sistema para planificar el
proyecto.
 No es una lista completa y definitiva. Es sólo una
estimación inicial de los requisitos.
 Es un documento dinámico que incorpora las
constantes necesidades del sistema y se
mantiene durante todo el ciclo de vida (hasta la
retirada del Sist.).
 Artefactos SCRUM

Sprint Backlog
 Especifica la serie de tareas que se van a
desarrollar según los requisitos señalados.
 Estas tareas tienen una duración de entre 4 y 16
hrs. de trabajo.
 Las de mayor duración intentar descomponerlas
en Sub-Tareas dentro de ese rango de tiempo.
 Al final del sprint se busca un incremento en la
funcionalidad.

Ingeniería De Software Santiago, 16 Diciembre 2005 12/30

Scrum y la
realidad del
software en
Chile

Santiago, 22 de octubre de 2008

A esta altura todos debieran
haber escuchado de Scrum:
 Al menos una vez,
¡está en el título de esta presentación!

 Encuesta Ágil:

 Quienes son Certified Scrum Masters?

 Quiénes usan Scrum en sus empresas?
 Quienes no lo hacen pero están
considerando hacerlo?
 Quienes no quieren usarlo?
14
Repasando Scrum

15
Ciclo de trabajo:
Explicación
 Al inicio del proyecto se establece su factibilidad, visión, valor de
negocio
 Después se listan los requerimientos creando el “Product
Backlog”
 Al principio de cada iteración se seleccionan aquellos
requerimientos que agregan mayor valor
 El equipo los analiza y define tareas para desarrollar cada uno
de ellos, esas tareas conforman el Sprint y se registran en el
Sprint Backlog (durante la reunión de Planificación)
 Al final de cada Sprint hay nueva funcionalidad para probar, la
cual es presentada para revisión por parte de los usuarios y
clientes
 Diariamente se revisa el estado de las tareas para detectar y
remover obstáculos
 Elementos de SCRUM
 Product Backlog
 Sprint
 Planificación
 Revisión

 Sprint Backlog

 SCRUM

 Retrospectiva (Reflexión)

 Roles
 Product Owner

 Scrum Master

 Team

 Valores
 Foco, apertura, coraje y respeto
Del día a día a otro distinto
 Para la gran mayoría, la adopción de Scrum para el trabajo
diario no es algo que vaya a ocurrir de la noche a la mañana
 Para un área típica de desarrollo, hacer el cambio es
relativamente simple
 Convencer al resto de la organización es el reto

 ¿Pero a qué están acostumbrados?

18
Cosas que
Cambiarán al
usar Scrum
Cómo se ven afectadas las prácticas de gestión de
proyectos más difundidas en Chile

19
De la Carta Gantt al Gráfico
de Burndown
 Tal vez el cambio más visible de la incorporación de Scrum, sea
en la presentación del avance del proyecto.
 Examinemos el enfoque tradicional y de Scrum respecto de la
planificación:
 Proyecto de Ejemplo : Administrador de Bibliotecas
 Fecha de Puesta en Producción 10/08/2008
 Miembros del equipo: 4 personas
 Módulos a Desarrollar:
 Adquisición de Libros
 Catálogo
 Reportes
 Administrador de Préstamos
 Administrador de Multas
 Baja y sustitución de ejemplares
20
En la Gantt
 Desglose de los módulos en actividades y tareas
 Se fija el alcance, y se trata de ajustar a las restricciones de
tiempo.

Tiempo
Alcance Fijas Costos
s

Ágil

Tradicional
Variables
Tiempo
s Costos Alcance

21
 En Scrum
 Se estiman, priorizan y distribuyen los módulos solicitados en
bloques temporales fijos (sprints).

2
3 Fecha
4 1 6
de Fin

Sprint 1 Sprint 2 Sprint 3 Sprint 4

1. Adquisición de Libros
2. Catálogo • Desde esa estimación podemos ver
3. Reportes si el alcance puede ser cumplido en
4. Administrador de Préstamos
5. Administrador de Multas los plazos
6. Baja y sustitución de • Revisamos el detalle del primer
ejemplares
Sprint
22
 Planificación del Sprint
 Identificación y estimación de actividades del Sprint
 El máximo de horas a agregar al Sprint es
Horas en el Sprint x Personas en el equipo
 Todo exceso sobre ese número no se ve con posibilidades de éxito.

Actividad Estimación

Generar Pantalla Ppal 4h

Conectar a la BD 2h

Listar préstamos activos 8h

Ingreso de Ejemplares 7h

23
Plazos impuestos
Los muchachos de ventas / producción / gerencia seguirán
imponiendo fechas de entrega del producto terminado sin
haberte preguntado si es posible.

 La diferencia: Priorización del Backlog de Producto.

 Poner metas realistas, y cumplirlas dentro del sprint…. Si fallas, en el
siguiente sprint tienes que ser cuidadoso.
 Revisar optimismo de las estimaciones

 Considerar complejidad de la solución de Software

 Prever un porcentaje del tiempo para resolver “urgencias”

 Tener considerado Testing / Documentación / Análisis

 Tranquilos(as): Todos fallamos en el primer Sprint

24
Reunión de Avance
Seguiremos teniendo que asistir a las clásicas reuniones de avance
semanal, y los niveles jerárquicos superiores seguirán
conformándose con un porcentaje como indicador de avance.

 Al interior del Equipo tendremos reunión diaria en donde se planifican

las actividades a realizar durante el próximo día del proyecto. En esta
ocasión el Scrum master recibe problemas y devuelve soluciones.
 Realizar la reunión diaria de pié, en círculo y en menos de 15 minutos,
puede ser todo un espectáculo para el resto de la organización.
Aprovechen el marketing gratuito que eso genera para educar sobre
Scrum.

25
Jefe de Proyecto o Scrum
Master
Si eres Jefe de Proyectos querrás ser Scrum Master, al resto de la
organización le dará igual, mientras sigas recopilando
requerimientos como antes…

 Ser Scrum Master no es dirigir al equipo hacia donde tú crees que

deben ir, es apoyar al equipo a avanzar hacia donde ellos decidieron ir:
 Removiendo obstáculos que dificulten el avance del proyecto
 Consiguiendo recursos críticos
 Manteniendo actualizadas las estimaciones
 Ayudando a mantener al equipo enfocado
 Bloqueando interrupciones o tareas no planificadas en el Sprint Backlog
 Dirigiendo las actividades propias del método
 Educando activamente a la organización

26
 XP

Programación Extrema

Ingeniería De Software Santiago, 16 Diciembre 2005 15/30

 ¿Qué Es XP?
 Es un proceso ligero, ágil, de bajo riesgo, flexible,
predecible, científico y divertido de desarrollar
software.
 Esta orientado hacia quien produce y usa el
software ( retroalimentación continua cliente y
desarrollador).
 Reduce el costo del cambio en todas las etapas del
ciclo de vida del sistema.
 Combina las que han demostrado ser las mejores
practicas para desarrollar software, y las lleva al
extremo.

Ingeniería De Software Santiago, 16 Diciembre 2005 16/30

 Contexto XP
 Cliente bien definido y en colaboración
constante.
 Los requisitos pueden y van a cambiar
(volátiles).
 Reduce los tiempos de desarrollo
manteniendo la calidad.
 Desarrollo incremental y continuo para
responder a los cambios.
 Grupo pequeño y muy integrado.

Ingeniería De Software Santiago, 16 Diciembre 2005 17/30

 Características XP
 Metodología creada a base de prueba y error.
 Énfasis en el desarrollo del software mas que una
buena documentación.
 Empieza en pequeño y añade funcionalidad con
retroalimentación continua.
 No introduce funcionalidades antes de que sean
necesarias.
 El cliente o el usuario se convierte en miembro del
mismo equipo.

Ingeniería De Software Santiago, 16 Diciembre 2005 18/30

 Características XP

 Su utilidad es medida con cuatro valores:

 Simplicidad en las soluciones
implementadas.
 Comunicación.

 Retroalimentación.

 Coraje (si funciona … mejóralo).

Ingeniería De Software Santiago, 16 Diciembre 2005 19/30

 Roles De XP

 Programador.
 Cliente.
 Encargado de pruebas (Tester).
 Encargado de seguimiento (Tracker).
 Entrenador (Coach).
 Consultor.
 Gestor (Big boss).

Ingeniería De Software Santiago, 16 Diciembre 2005 20/30

 Prácticas De XP
 Desarrollo guiado por pruebas.
 Cliente presente.
 Integración continua.
 Refabricación sin piedad.
 Diseño simple.
 Propiedad colectiva del código y convenciones del
mismo.
 Cubrir una semana de 40 horas, pues los
programadores cansados son menos productivos y
mas propensos a errores.

Ingeniería De Software Santiago, 16 Diciembre 2005 21/30

 Prácticas De XP

Ingeniería De Software Santiago, 16 Diciembre 2005 22/30

 Ciclo De Vida XP

 El ciclo de vida ideal de XP consta de seis

fases:
 Exploración.
 Planificación de la Entrega (Release).
 Iteraciones.
 Producción.
 Mantenimiento.
 Muerte del Proyecto.

Ingeniería De Software Santiago, 16 Diciembre 2005 23/30

 Costo Del Cambio En El Ciclo De
Vida Del Proyecto
 Tradicionalmente, entre
mas tarde aparezca la
necesidad de un cambio, el
costo de implementación
de este se elevara
exponencialmente.
 La programación extrema
mantiene dicho costo en un
nivel prácticamente
independiente con respecto
a la etapa del ciclo de vida.

Ingeniería De Software Santiago, 16 Diciembre 2005 24/30

 Flujo De Un Proyecto XP

Ingeniería De Software Santiago, 16 Diciembre 2005 25/30

 Iteración XP

Ingeniería De Software Santiago, 16 Diciembre 2005 26/30

 Otras Metodologías
Ágiles

Ingeniería De Software Santiago, 16 Diciembre 2005 28/30

  Crystal Methodologies.
 Dynamic Systems Development Method
(DSDM).
 Adaptive Software Development (ASD).
 Feature - Driven Development (FDD).
 Lean Development (LD).

Ingeniería De Software Santiago, 16 Diciembre 2005 29/30