Sesión I

Vista previa del material en texto

Gestión Ágil de Proyectos
Ernesto Calvo
PMP | PMI-RMP | PMI-SP | PMI-ACP
CSP | COBIT | P6 | MCTS | SAFe
Gestión Ágil de Proyectos
 I. Introducción
 II. Métodos Ágiles de Dirección de Proyectos
 III. Envío Basado en Valor
 IV. Gestión de los Interesados
 V. Impulsando el Desempeño del Equipo
 VI. Planificación Adaptativa
 VII. Identificación y Resolución de Problemas
 VIII. Mejora Continua
I. Introducción a
métodos Ágiles
Agenda
• Origen de la Dirección de Proyectos
• ¿Qué es un método ágil?
• ¿Cuáles son las diferencias entre un enfoque
tradicional y un enfoque ágil de dirección de
proyectos?
• El manifiesto Ágil
• Los principios del Manifiesto
• Gestión Ágil del Proyecto, ¿Cuándo usarla?
Origen de la Dirección deProyectos
En los años 50, con la 
ejecución de proyectos 
militares.
Problemas más
comunes: 
Desbordamiento de 
cronogramas, costos y 
baja calidad de 
entregables.
•Aparición de 
organizaciones:
•IPMA International 
Project Management 
Association en 1965.
•PMI Project 
Management 
Institute en 1969.
•Prince2 en 1989.
Proyecto 
Exitoso
Tiempo
Costos
Alcance
¿Qué es un metodo ágil?
Es un método de basado en el desarrollo iterativo e
incremental, donde los requisitos y soluciones
evolucionan mediante la colaboración de grupos auto
dirigidos y multidiciplinarios.
¿Cuáles son las diferencias entre un enfoque ágil y 
un enfoque tradicional de dirección deproyectos?
TRADICIONAL
AGIL
PLANIFICACIÓN
CAMBIO
ANTICIPACIÓN
ADAPTACIÓN
¿Cuáles son las diferencias entre un 
enfoque ágil y un enfoque tradicional de 
dirección deproyectos?
TRADICIONAL
AGIL
Se envía a producción 
todo el trabajo
Se envía a producción 
trabajos parciales
¿Cuáles son las diferencias entre un enfoque ágil y 
un enfoque tradicional de dirección deproyectos?
TRADICIONAL
AGIL
1 líder
“N” líderes
1 equipo
¿Cuáles son las diferencias entre un enfoque ágil y 
un enfoque tradicional de dirección deproyectos?
TRADICIONAL
AGIL
cliente
Ejecución
El Manifiesto Ágil
Estamos poniendo al descubierto mejores métodos para desarrollar 
software, haciéndolo y ayudando a otros a que lo hagan. Con este
trabajo hemos llegado a valorar:
Estamos poniendo al descubierto mejores métodos para desarrollar 
software, haciéndolo y ayudando a otros a que lo hagan. Con este
trabajo hemos llegado a valorar:
A los individuos y 
su interacción, por 
encima de los 
procesos y las 
herramientas.
El software que 
funciona, por 
encima de la 
documentación 
exhaustiva.
La colaboración
con el cliente, por 
encima de la 
negociación 
contractual.
La respuesta al 
cambio, por
encima del 
seguimiento de 
un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda
Principios delManifiesto
Nuestra principal prioridad es satisfacer al cliente a través 
de la entrega temprana y continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan
tarde al desarrollo. Los procesos ágiles se doblegan al
cambio como ventaja competitiva para el cliente.
Principios delManifiesto
Entregar con frecuencia software que funcione, en periodos 
de un par de semanas hasta un par de meses, con
preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben 
trabajar juntosde forma cotidiana a través del proyecto.
Principios delManifiesto
Construcción de proyectos en torno a individuos motivados,
dándoles la oportunidad y el respaldo que necesitan y
procurándoles confianza para que realicen la tarea.
La forma más eficiente y efectiva de comunicar información de 
ida y vuelta dentro de un equipo de desarrollo es mediante la 
conversación cara a cara.
Principios delManifiesto
El software que funciona es la principal medida del progreso
Los procesos ágiles promueven el desarrollo sostenido. Los 
patrocinadores, desarrolladores y usuarios deben mantener 
un ritmo constante de forma indefinida.
Principios delManifiesto
La atención continua a la excelencia técnica enaltece la
agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo 
que sehace, es esencial.
Principios delManifiesto
Las mejores arquitecturas, requisitos y diseños emergen de 
equipos que se auto-organizan
En intervalos regulares, el equipo reflexiona sobre la forma de 
ser más efectivo y ajusta su conducta en consecuencia
Gestión Ágil deProyectos
Empresas
Desarrollo 
deProductos
Control de cambios
Velocidad
Adaptabilidad
Generación de valor
Descripciones 
abiertas
Triple restricción
Seguimiento de 
un plan
Definiciones 
completas
Valor
Reducción del 
tiempo de 
desarrollo
Agilidad y 
Flexibilidad
Confiabilidad
Objetivos de la GestiónÁgil
Gestión Predictiva oÁgil
Adaptativa
• Ágil
• Adaptable
Predictiva
• Clásica
• Tradicional
• Formal
¿Cuando usar una u otra?
Cliente • Prioridad delNegocio
Proyecto
• Estabilidad de los requisitos
• Maleabilidad y costos de la materia prima
• Criticidad del sistema
• Costo de los prototipos
• Tamaño delequipo
Organización
• Cultura de la organización
• Nivel técnico delequipo
• Estrategia de desarrollo: Procesos oPersonas
Pregunta 2: The end result of an Agile development is:
A. A product of a professional quality which fits the business need
B. A product of almost as good a quality as a Waterfall development
C. A product which is barely sufficient for its purpose and deliberately not maintainable
D. A technically-perfect, re-factored solution
Pregunta 1: Which of these principles is not mentioned in the Agile Manifesto?
A. Working software
B. Sustainable development
C. Simplicity
D. Contract arbitration
Pregunta 3: How should work be allocated to the team in an Agile project?
A. The Team Leader (Scrum Master) should allocate specific tasks to individuals
B. Tasks should be randomly allocated to team members, using Planning Poker
C. Team members should self-select tasks appropriate to their skills
D. The most complex tasks should be allocated by the Team Leader (Scrum Master)
Pregunta 4: When handling team dynamics, the Agile Leader should …
A Empower the team members, within appropriate limits
B. Encourage an environment of competition and personal advantage
C. Give clear directives to the team about what they should do and how
D. Expect team members to be proactive and each work to their own priorities and objectives
Pregunta 5: The Agile approach to documentation is:
A. Do no documentation because it is a waste of time
B. Do sufficient documentation to prove you have done a good job
C. Do the necessary documentation to support the development and use of the product
D. Do more documentation than usual, because Agile is risky
Pregunta 6: The Agile way is:
A. To produce working product of the right quality, early and incrementally
B. To produce working product after documentation has been signed off
C. To produce simple prototypes early, but no finished product until the end of the project
D. To produce products without technical integrity, but re-engineer later
II. Metodos
Ágiles de Dirección de
Proyectos
Agenda
• Scrum
• Extreme Programming (XP)
• Lean Software Development
• Kanban Development
• Feature Driven Development (FDD)
• Diynamic Systems Development Method 
(DSDM)
• Crystal
Scrum
Resumen Ejecutivo
Scrumes un proceso ágil que 
nos permite centrarnos en 
ofrecer el más alto valor al 
negocio en el menortiempo 
posible.
Nospermite rápidamente y en 
repetidas ocasiones 
inspeccionar software real de 
trabajo (cada dos semanas o 
un mes).
El negocio fija lasprioridades. 
Los equipos seauto‐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 otrosprint.
Pilares deScrum
Los aspectos delproceso que 
afectan al resultado, deben ser 
visibles para aquellas 
personas que administran 
dicho resultado.
Inspección
Se debe inspeccionar con la 
frecuencia suficiente los 
diversos aspectos del 
proceso para que puedan 
detectarse variaciones 
inaceptables en el mismo.
Adaptación
Si el inspector determina, a través 
de la inspección, que uno o más 
aspectos del proceso están fuera 
de los límites aceptables, y que el 
producto resultante será 
inaceptable, debe ajustar el 
proceso o el material procesado.
El ajuste debe realizarse lo más 
rápidamente posible para 
minimizar una desviación mayor.
Scrum, se basa en la teoría del control empírico de procesos, emplea
un enfoque iterativo e incrementalpara optimizar la previsibilidad y
controlar los riesgos
Transparencia
Características
• Equipos auto‐organizados.
• El producto avanza en una seriede
«Sprints» de dos semanas a un mes de duración.
• Los requisitos son capturadoscomo 
elementos de una lista de «Product Backlog».
• No hay prácticas de ingenieríaprescritas.
Scrum
Sprint
2-4 Semanas
24horas
Product
Objetivo del 
Sprint
Sprint 
Backlog
Incremento del producto 
potencialmente entregable
Reunión 
diaria Scrum
Sprint
• En Scrum los proyectos avanzan en una serie de 
“Sprints”, análogo a las iteraciones en XP.
• La duración típica es 2–4 semanas o a lo mucho 
un mescalendario.
• La duración constante conduce a unmejor ritmo.
• El producto es diseñado, codificadoy 
testeado durante el Sprint.
Desarrollo secuencial vsSuperpuesto
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
Framework Scrum
Roles
•Propietario del Producto
•ScrumMaster
•ElEquipo
Bloques de Tiempo
•Planificación de la 
Entrega
•Planificación del Sprint
•Sprint
•Revisión del Sprint
•Retrospectiva del Sprint
•Scrum Diario
Artefactos
•Productbacklog
•Sprintbacklog
•Burndowncharts
Framework Scrum
Roles
•Propietario del Producto
•ScrumMaster
•ElEquipo
Bloques de Tiempo
•Planificación de la 
Entrega
•Planificación del Sprint
•Sprint
•Revisión del Sprint
•Retrospectiva del Sprint
•Scrum Diario
Artefactos
•Productbacklog
•Sprintbacklog
•Burndowncharts
Propietario del Producto (1 de2)
Responsable de maximizar el valor del trabajo realizado por el Equipo Scrum.
Define las funcionalidades del producto
Decide sobre las flechas 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
Propietario del Producto (2 de2)
El propietario del producto puede ser un miembro del equipo, que también participe en 
las tareas de desarrollo.
Esta responsabilidad adicional puede disminuir la capacidad del Propietario del Producto 
de trabajar con los interesados del proyecto o producto.
El propietario del producto no puede ser nunca el ScrumMaster.
Mantiene el Product Backlog y asegura la visibilidad del mismo para todos.
Para desarrollo comercial, el Propietario del Producto podría ser el gerente de 
producto.
Para los desarrollos, el Propietario del Producto podría ser el gerente de la 
función empresarial que se esté automatizando.
El Propietario del Producto es una persona, no un comité.
ScrumMaster (1 de2)
Representa a la «gestión» del proyecto.
Responsable de promover los valores y prácticas de Scrum.
Responsable de asegurar que el proceso es comprendido y seguido. 
Su rol principal es de remover 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.
ScrumMaster (2 de2)
Trabaja con los clientes y la gerencia para identificar y nombrar al Propietario del 
Producto
Explica al Propietario del Producto cómo hacer su trabajo
El Product Owner debe gestionar para optimizar el valor utilizando Scrum. Si no se cumple, la 
responsabilidad podría recaer en el ScrumMaster.
El ScrumMaster nunca debe ser el Propietario del Producto.
Puede ser un miembro del Equipo, por ejemplo, un desarrollador realizando tareas del 
Sprint.
El Equipo (1 de2)
Convierten el Product Backlog en incrementos de funcionalidad potencialmente entregables en 
cada Sprint.
Típicamente de 5 a 9 personas.
Multi-funcional, con las habilidades necesarias para crear un incremento de trabajo: 
Programadores, testers, analistas, diseñadores, etc.
Los miembros deben ser full-time, puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
Los equipos son auto-organizativos.
Solo puede haber cambio de miembros entre los sprintsm (Recomendable).
Formado por personas con los conocimientos para convertir los requerimientos en un incremento 
utilizable del producto al final del Sprint.
El Equipo (2 de2)
A menudo tienen habilidades especializadas, como la programación, el control de calidad, el análisis de 
negocio, la arquitectura, el diseño de la interfaz de usuario o el diseño de bases de datos.
Sin embargo, las habilidades que el miembro del Equipo comparte - es decir, la habilidad de tratar con 
un requisito y convertirlo en un producto utilizable - tienden a ser más importantes que aquellas que 
no comparte.
Las personas que se niegan a escribir código, ya que son arquitectos o diseñadores, no 
se ajustan bien a los Equipos.
No hay títulos en los Equipos, y no hay excepciones a esta regla. Los equipos tampoco contienen sub-
Equipos dedicados a áreas particulares, como pruebas o análisis de negocio.
La composición del Equipo puede cambiar al final de un Sprint. Cada vez que se cambian los miembros del 
Equipo, la productividad obtenida de la auto-organización se ve disminuida.
Por esta razón se debe tener cuidado al cambiar la composición del equipo.
Framework Scrum
Roles
•Propietario del Producto
•ScrumMaster
•ElEquipo
Bloques de Tiempo
•Planificación de la 
Entrega
•Planificación del Sprint
•Sprint
•Revisión del Sprint
•Retrospectiva del Sprint
•Scrum Diario
Artefactos
•Productbacklog
•Sprintbacklog
•Burndowncharts
Planificación de laEntrega
El propósito es establecerun plan y unas metas que los EquiposScrum y el resto de las organizacionespuedan entender y 
comunicar
Las preguntas clásicas son: ¿Cómo podemosconvertir la visión en un producto ganador,de la mejormanera posible?
¿Cómo podemos alcanzaro mejorar la satisfaccióndel clientedeseada y el Retorno de la Inversión?
El plan de entrega estableceel objetivode la entrega,el Product Backlog de mayor prioridad, los principales riesgos, y las
característicasgenerales y la funcionalidadque va a contener la entrega.
Tambiénestableceuna fechaprobablede entrega,y el coste,que deberíamantenerse si no cambianada.
La organizaciónpuede inspeccionar el avance y hacer cambios a este plan de entregaen cadaSprint.
La planificaciónde entregaes completamenteopcional.Si los Equipos Scrum empiezana trabajarsin esta reunión, la ausencia de los
artefactosgenerados en ella se revelaráen la forma de impedimentosque hay que resolver.
Planificación delSprint
Objetivo 
del Sprint
Sprint 
Backlog
Condiciones del 
Negocio
Capacidad del 
Equipo
Product Backlog
Tecnología
Producto Actual
• Analizar y evaluar el Product 
Backlog
• Seleccionar el objetivo del 
Sprint
Priorización
• Decidir como alcanzar el objetivo 
del Sprint (diseño)
• Crear el Sprint Backlog (tareas) en 
base a los temas del Product Backlog 
(user stories / features)
• Estimar Sprint Backlog en horas
Planificación
Planificación del Sprint (1 de2)
DuranteReunión de Planificación del Sprint la iteración es planificada
La reunión se restringea un bloque de tiempo de ocho horas para un Sprint de un mes.
Consta de dos partes.
•Un bloque de cuatro horas, escuando se decide lo que se hará durante el Sprint.
•Cuatro horas, para que el equipo determine cómo se va a convertir esta funcionalidad en un incremento del producto.
La cantidad de Backlogque el Equipo seleccionaes una decisión del Equipo. Sólo el
Equipo puede evaluar lo que puede lograr en el próximo Sprint.
Una vez seleccionadoel Product Backlog, se define un Objetivo para el Sprint(meta que se 
alcanzará mediante la implementación del Product Backlog), el Objetivo del Sprint es un 
subconjunto del objetivo de laentrega.
Las Tareas se deben descomponer para que se puedan completar en menos de un día.
Planificación del Sprint (2 de2)
El Equipo se organiza para asignar y realizar el trabajo contenido enel Sprint Backlog, ya sea durante 
la Reunión de Planificación del Sprint, o sobre la marchadurante el Sprint.
El Equipo tambiénpuede invitar a otras personas a estar presentes, con el fin de proporcionar 
asesoramiento técnico o dedominio.
En esta reunión, un Equipo nuevo a menudo se da cuenta de que, o bien se hundirá, o saldrá a 
flote como un equipo, noindividualmente.
El Equipo se da cuenta de que debe apoyarse en sí mismo. Al aceptar esto, comienza a auto‐ 
organizarse para llegar a tener las características y el comportamientode un verdaderoequipo.
Codificar la capa intermedia (8 hrs) 
Codificar la interfaz de usuario (4) 
Escribir los casos de prueba (4) 
Codificar la clase clientes (6) 
Actualizar test de performance (4)
Visualizar información 
de Clientes VIP
Sprint (1 de2)
Es el corazón deScrum.
Los Sprints están limitados en bloques de tiempo, es una iteración de un mes de duración o menos.
La duración de cada sprint se mantiene constante a lo largo de todo el esfuerzo de desarrollo
Durante el Sprint, el ScrumMaster asegura que no se realizan cambios que afecten el Objetivo
del Sprint
Todos los Sprint utilizan el mismo marco de referencia de Scrum
Proporcionan un incremento de funcionalidad potencialmente utilizable al producto final
Cada Sprint se inicia inmediatamente después del anterior
Sprint (2 de2)
Tanto la composición del Equipo como los objetivos de calidad se mantienenconstantesdurante todo el 
Sprint.
Si el Equipo siente que se ha comprometidoa demasiado trabajo, se reúne con el Propietariodel 
Productopara eliminaro reducir el alcance del ProductBacklogseleccionado para el Sprint.
Si el Equipo siente que puede tener tiempo de sobra, puede trabajarcon el Propietario
del Productopara seleccionarelementos adicionalesdel ProductBacklog.
Un Sprint puede ser cancelado antes de que el bloquede tiempo del Sprint se haya terminado. 
Sólo el Propietario del Producto tiene la autoridad para cancelar el Sprint, aunque puede 
hacerlobajo la influencia de los interesados, del Equipo, o del ScrumMaster.
Cuando un Sprint se cancela, cualquierelementodel ProductBacklogque haya sido completadoy 
"hecho", es revisado. Estos elementos son aceptados si representan un incremento potencialmente
entregable.
Las cancelaciones de Sprints son a menudo traumáticas para el equipo, y muy poco frecuentes.
DailyScrum
• Parámetros
– Diaria
– Dura 15 minutos
– Parados
• Nopara la solución de problemas
– Todo el mundo estáinvitado
– Sólo los miembros del equipo, ScrumMaster y 
Product Owner, puedenhablar
– Ayuda a evitar otras reunionesinnecesarias
ScrumDiario
• Todos responden 3preguntas:
¿Qué hiciste 
ayer?
¿Qué vas a 
hacer hoy?
¿Hay 
obstáculos en 
tu camino?
1
2
3
• Los Scrums Diarios mejoran las comunicaciones, eliminan otras reuniones, identifican y eliminan los
impedimentos al desarrollo, destacan y promueven la rápida toma de decisiones y mejoran el nivel de 
conocimiento de los proyectos.
•El ScrumMaster se asegura de que el Equipo mantiene la reunión. El Equipo es responsable de conducir el 
Scrum Diario.
Revisión del Sprint (1 de2)
Se realiza al final del Sprint.
Esta es una reunión restringida a un bloque de tiempo de cuatro horas para un Sprint de un mes.
Durante la Revisión de Sprint, el Equipo Scrum y las partes interesadas debaten
sobre lo que se acaba de hacer.
El equipo presenta lo realizado durante el sprint.
Normalmente adopta la forma de una demo de las nuevas características o la
arquitectura subyacente.
Se trata de una reunión informal, en la que la presentación de la funcionalidad está
destinada a fomentar la colaboración para determinar qué hacer a continuación.
Todo el equipo participa.
Revisión del Sprint (2 de2)
El Propietariodel Producto identifica lo que se ha hecho y lo que no se ha hecho.
El Equipo analiza lo que salió bien durante el Sprint y cuáles son los problemas
que encontró, y cómo resolvió estosproblemas.
El Equipo entonces muestrael trabajoque ha sido completadoy responde
preguntas.
El Propietariodel Producto a continuación, analiza el Product Backlogen su estado
actual.
Retrospectiva delSprint
Después de la Revisión del Sprint, y antes de la próxima Reunión de Planificación de Sprint, 
el Equipo Scrum mantiene una reunión Retrospectiva del Sprint
Es una reunión restringida a un bloque de tiempo de tres horas para Sprints de un mes
En esta reunión, el ScrumMasteralienta al Equipo Scrum a revisar, en el marco de proceso 
y prácticas de Scrum, su proceso de desarrollo, para que sea más eficaz y agradable para 
el próximo Sprint.
El propósito de la Retrospectiva es inspeccionar cómo fue el último Sprint en lo que 
respecta a las personas, relaciones, procesos y herramientas.
Al final de la Retrospectiva del Sprint, el Equipo Scrum debería haber identificado 
acciones concretas de mejora que se implementarán en el próximo Sprint.
Estos cambios se convierten en la adaptación derivada de la inspección empírica.
Todo el equipo participa
•ScrumMaster, Product owner, Equipo, Posiblemente clientes y otros
Framework Scrum
Roles
• Propietario del Producto
• ScrumMaster
• El Equipo
Bloques de Tiempo
• Planificación de la 
Entrega
• Planificación del Sprint
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
Artefactos
• Product backlog
• Sprint backlog
• Burndown charts
Product Backlog (1 de2)
Los requisitos para el producto, que los Equipos están elaborando, están listados en el Product Backlog.
Lista priorizada de todo lo que podría ser necesario en el producto.
Una lista de todos los trabajos deseados en el proyecto 
El Propietario del Producto es responsable del Product Backlog, de su contenido, disponibilidad 
y priorización.
Repriorizada al comienzo de cada Sprint
El Product Backlog nunca está completo.
Idealmente cada tema tiene valor para el usuario o el cliente
Product Backlog (2 de2)
El Product Backlog es dinámico, ya que cambia constantemente para identificar qué necesita
el producto para seradecuado, competitivo y útil.
Mientras existe un producto, el Product Backlog también existe.
Los elementos del Product Backlogdeben tener los siguientes atributos: una
descripción, una prioridad, y una estimación. La prioridadestá guiada por el riesgo,
el valor y la necesidad.
El Product Backlogestá ordenado por prioridad. La parte más prioritariadel Product
Backlog determina las actividadesde desarrolloque se llevarán a cabo de forma
inmediata.
Las pruebas de aceptación se utilizan a menudo como un atributomás del Product Backlog.
Ejemplo de un ProductBacklog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de una reserva. 3
Como un empleado de hotel, puedo ejecutar informes de los ingresos por 
habitación disponible
8
Mejorar el manejo de excepciones 8
... 30
... 50
Objetivo delSprint
• Una breve declaración de cual será el foco del 
trabajo durante el sprint.
• Por ejemplo:
– Permitir mantener actualizados los datos de los 
clientes.
– Administrar paramétricamente las reglas de 
negocio del producto de créditoshipotecarios.
SprintBacklog
Lista de tareaspara convertir el Product Backlog correspondiente a un Sprint, en un 
incremento del producto potencialmente entregable
Los individuos eligen las tareas 
El trabajo nunca es asignado
La estimación del trabajo restante es actualizada diariamente
Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog
El trabajo para el Sprint emerge
Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de 
tiempo y subdividirla luego.
Escalabilidad
Normalmente los equipos son de 7 ± 2 personas
•La escalabilidad proviene de equipos de equipos
Factores a tener cuenta
•Tipo de aplicación
•Tamaño del equipo
•Dispersión del equipo
•Duración del proyecto
Scrum se ha utilizado en múltiples proyectos de más de 500 personas
Expansión a través de Scrum
de Scrums
eXtremeProgramming
ManifiestoÁgil
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo
y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y 
su interacción,por 
encima de los 
procesos y las 
herramientas.
El software que 
funciona, por 
encima de la 
documentación 
exhaustiva.
La colaboración con 
el cliente, por 
encima de la 
negociación 
contractual.
La respuesta al 
cambio, por encima 
del seguimiento de 
un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda
Introducción
Método más popular 
entre losmetodos
ágiles
El más transgresor dela 
ortodoxia basada en 
procesos.
Creado por Kent Beck
Todo en el software cambia. Los requisitos cambian. El diseño 
cambia. El negocio cambia. La tecnología cambia. El equipo 
cambia. Los miembros del equipo cambian. El problema no es el 
cambio en sí mismo, puesto que sabemos que el cambio va a 
suceder; el problema es la incapacidad de adaptarnos a dicho 
cambio cuando éste tiene lugar.
Es posible desarrollar software de gran calidad a pesar, o incluso como 
consecuencia del cambio continuo.
Su principal asunción es que con un poco de planificación, un poco de codificación y 
unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o 
equivocado, evitando así tener que echar marcha atrás demasiado tarde.
Valores que inspiranXP
Simplicidad
Base de la 
programación 
extrema
Agiliza el 
desarrollo y 
facilitar el 
mantenimiento
Mantener el 
código simple a 
medida que 
crece
Documentación 
del código
Nomenclatura 
de las variables, 
métodos y 
clases
Desarrollo solo 
el sistema que 
realmente se 
necesita
Implica resolver 
en cada 
momento solo 
las necesidades 
actuales
Valores que inspiranXP
Comunicación
Base de la 
programación 
extrema
Si el código es 
complejo hay que 
esforzarse para 
hacerlo
El código 
autodocumentado 
es mas fiable que 
los comentarios
Programación por 
parejas
Comunicación 
directa y continua 
a clientes y 
desarrolladores
El cliente se 
integra en el 
equipo para 
establecer 
prioridades y 
resolver dudas
Valores que inspiranXP
Retroalimentación
Opinión del cliente 
en tiempo real
Ciclos muy cortos 
tras los cuales se 
muestran 
resultados
El código también 
es una fuente de 
retroalimentación
Desarrollo 
incremental, con 
entregas y pruebas 
frecuentes y 
continuas
Los fallos se 
localizan muy 
pronto
La planificación no 
evidencia errores, 
que se evidencian 
al desarrollar
Valores que inspiranXP
Coraje
Utilizar la 
programación 
por parejas
Implementar las 
características 
presentes
Tomar 
decisiones 
dificiles
Reparar un error 
cuando se 
detecta
Mejorar el 
código siempre 
que tras el 
feedback e 
iteraciones
Tratar con el 
cliente los 
desajustes de 
agendas para 
decidir cambios 
en entregas
Valores que inspiranXP
Respeto
Los miembros del 
equipo se respetan 
los unos a otros
Los miembros se 
respetan su trabajo 
porque siempre 
buscan, calidad, 
optimización, 
eficiencia
Los programadores 
no realizan cambios 
que hacen que las 
pruebas existentes 
fallen o que demore 
el trabajo de sus 
compañeros
Los miembros del 
equipo respetan el 
trabajo del resto no 
haciendo menos a 
otros
Ciclo deVida
Exploración
Planificación de 
la Entrega
Iteraciones
Producción
Mantenimiento
Muerte del 
proyecto
Prácticas deXP
• Conjunto de actividades simples que guían los diferentes aspectos del desarrollo para seguir 
el proceso.
El juego dela 
planificación
Liberaciones 
pequeñas
Diseñosimple
Metáforas
Pruebas 
Unitarias
Refactorización
Programación 
en parejas
Propiedad 
colectivadel 
código
Integración 
continua
Ritmo 
sostenible
Disponibilidad 
del cliente
Estándaresde 
programación
Roles enXP
RolesEntrenador (Coach)
Cliente (Customer)
Programador 
(Programmer)
Encargado de 
seguimiento 
(Tracker)
Encargado de 
pruebas (Tester)
Gestor (Big Boss)
Lean Software Development
Lean SoftwareDevelopment
• Lean Software Development no es un método ágil
pero los valores Lean y ágiles están muy alineados.
• Lean es un conjunto de principios que han sido
tomados de los métodos de producción y aplicados al
desarrollo desoftware
Lean SoftwareDevelopment
Los 7 
principios 
básicos:
Lean
Eliminar 
desperdicios
Apoderar al 
equipo
Entregar 
rapido
Optimizar el 
conjunto
Construir 
calidad 
interna
Aplazar 
decisiones
Maximizar el 
aprendizaje
Pregunta 1: El Product Owner...
a) Preside el Sprint Planning Meeting.
b) Participa en la reunión de cierre del Sprint.
c) Ninguna de las anteriores.
d) Participa en la Daily Scrum o reunión diaria.
Pregunta 2: ¿Cuál es la secuencia más común en un ciclo de vida de Scrum?
a) Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
b) Daily Scrum, Sprint Planning, Sprint Retrospective, Sprint Review.
c) Ninguna.
d) Sprint Planning, Daily Scrum, Sprint Retrospective, Sprint Review.
Pregunta 3: ¿Cuáles son los artefactos en Scrum?
a) Product Increment, Product Backlog y User Story.
b) Product Backlog, Sprint Backlog y Product Increment.
c) Sprint Backlog, Product Increment y Sprint.
Pregunta 4: ¿Cuál es la principal diferencia entre el Product Backlog y el Sprint Backlog?
a) El Product Backlog es igual a Sprint Backlog.
b) El Sprint Backlog es un subconjunto del Product Backlog.
c) El Product Backlog es un subconjunto del Sprint Backlog.
d) El Sprint Backlog es la responsabilidad del Product Owner.
Pregunta 5: The working culture of an Agile team is …
A. Collective
B. Collaborative
C. Connective
D. Contemplative
Pregunta 6: Which of the following is NOT a characteristic which makes it easier to adopt 
Agile methodologies?
A) Urgency to deliver
B) Volatile requirements
C) Management support
D) Consistent resources