Sesión I

Gestión Ágil de Proyectos
Ernesto Calvo
PMP | PMI-RMP | PMI-SP | PMI-ACP
CSP | COBIT | P6 | MCTS | SAFe
 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 de Proyectos
•Aparición de
Problemas más organizaciones:
comunes: •IPMA International
En los años 50, con la Project Management
ejecución de proyectos Desbordamiento de
cronogramas, costos y Association en 1965.
militares.
baja calidad de •PMI Project
entregables. Management
Institute en 1969.
•Prince2 en 1989.
Proyecto
Alcance Exitoso
Costos
Tiempo
¿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
PLANIFICACIÓN ANTICIPACIÓN
AGIL
ADAPTACIÓN
CAMBIO
¿Cuáles son las diferencias entre un
enfoque ágil y un enfoque tradicional de
dirección deproyectos?
TRADICIONAL
Se envía a producción
todo el trabajo
AGIL
Se envía a producción
trabajos parciales
TRADICIONAL
1 líder 1 equipo
AGIL
“N” líderes
TRADICIONAL
cliente
AGIL
Ejecución
El Manifiesto Ágil
Estamos poniendo
Estamos poniendo al
al descubierto
descubierto mejores
mejores métodos
métodos para
para desarrollar
desarrollar
software, haciéndolo
software, haciéndolo yy ayudando
ayudando aa otros
otros aa que
que lo
lo hagan.
hagan. Con
Con este
este
trabajo hemos
trabajo hemos llegado
llegado aa valorar:
valorar:
A los individuos y El software que La colaboración

La respuesta al
su interacción, por funciona, por con el cliente, por
cambio, por
encima de los encima de la encima de la
encima del
procesos y las documentación negociación
seguimiento de
herramientas. exhaustiva. contractual.
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.
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 juntos de forma cotidiana a través del proyecto.
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.
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.
La atención continua a la excelencia técnica enaltece la

agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo

que se hace, es esencial.
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
Desarrollo
Empresas
de Productos
Velocidad Triple restricción
Adaptabilidad Control de cambios
Seguimientode
Generación de valor
un plan
Descripciones Definiciones
abiertas completas
Objetivos de la GestiónÁgil
Reducción del
Valor tiempo de
desarrollo
Agilidad y
Confiabilidad
Flexibilidad
Gestión Predictiva oÁgil
Adaptativa
• Ágil
• Adaptable
Predictiva
• Clásica
• Tradicional
• Formal
¿Cuando usar una u otra?
Cliente • Prioridad del Negocio
• Estabilidad de los requisitos

• Maleabilidad y costosde la materia prima
Proyecto • Criticidad del sistema
• Costo de los prototipos
• Tamañodelequipo
• Cultura de la organización
Organización • Nivel técnico delequipo
• Estrategia de desarrollo: ProcesosoPersonas
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 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 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
Scrum es un proceso ágil que Nospermite rápidamente y en

nos permite centrarnos en repetidas ocasiones
ofrecer el más alto valor al inspeccionar software real de
negocio en el menortiempo trabajo (cada dos semanas o
posible. un mes).
El negocio fija lasprioridades.

Cada dos semanas o un mes,
Los equipos seauto‐organizan
cualquiera puede ver el
a fin de determinar la mejor software real funcionando y
manera de entregar las decidir si liberarlo o seguir
funcionalidades de más alta mejorándolo en otrosprint.
prioridad.
Pilares deScrum
Scrum, se basa en la teoría del control empírico de procesos, emplea
un enfoque iterativo e incremental para optimizar la previsibilidad y
controlar los riesgos
Transparencia
Los aspectos del proceso que Inspección
afectan al resultado, deben ser
visibles para aquellas Se debe inspeccionar con la Adaptación
personas que administran frecuencia suficiente los
dicho resultado. diversos aspectos del Si el inspector determina, a través
proceso para que puedan de la inspección, que uno o más
detectarse variaciones aspectos del proceso están fuera
inaceptables en el mismo. 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.
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
Reunión
24horas
diaria Scrum
Sprint
Objetivo del 2-4 Semanas
Sprint
Sprint
Backlog
Incremento del producto

potencialmente entregable
Product
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 mes calendario.
• La duración constante conduce a un mejor ritmo.
• El producto es diseñado, codificado y
testeado durante el Sprint.
Desarrollo secuencial vsSuperpuesto
Requisitos Diseño Código Test
Enlugar de hacer todo de una cosa ala vez ...
Losequipos Scrum hacen un poco de todo, todo el

tiempo
Framework Scrum
Roles Bloques de Tiempo Artefactos

• Propietario del Producto • Planificación de la • Product backlog
• ScrumMaster Entrega • Sprint backlog
• El Equipo • Planificación del Sprint • Burndown charts
• Sprint
• Revisión del Sprint
• Retrospectiva del Sprint
• Scrum Diario
Framework Scrum

• Sprint
• Scrum Diario
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.
Puede ser un miembro del Equipo, por ejemplo, un desarrollador realizando tareas del
Sprint.
El ScrumMaster nunca debe ser el Propietario del Producto.

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

• Sprint
• Scrum Diario
Planificación de laEntrega
El propósito es establecer un plan y unas metas que los Equipos Scrum y el resto de las organizaciones puedan entender y
comunicar
Las preguntas clásicas son: ¿Cómo podemos convertir la visión en un producto ganador, de la mejor manera posible?
¿Cómo podemos alcanzar o mejorar la satisfacción del cliente deseada y el Retorno de la Inversión?
El plan de entrega establece el objetivo de la entrega, el Product Backlog de mayor prioridad, los principales riesgos, y las
características generales y la funcionalidad que va a contener la entrega.
También establece una fecha probable de entrega, y el coste, que debería mantenerse si no cambia nada.
La organización puede inspeccionar el avance y hacer cambios a este plan de entrega en cada Sprint.
La planificación de entrega es completamente opcional. Si los Equipos Scrum empiezan a trabajar sin esta reunión, la ausencia de los
artefactos generados en ella se revelará en la forma de impedimentos que hay que resolver.
Planificación delSprint
Capacidad del Priorización
Equipo
• Analizar y evaluar el Product Objetivo

Backlog del Sprint
Product Backlog • Seleccionar el objetivo del
Sprint
Condiciones del
Negocio
Planificación
• Decidir como alcanzar el objetivo Sprint
Producto Actual del Sprint (diseño)
Backlog
• Crear el Sprint Backlog (tareas) en
base a los temas del Product Backlog
(user stories / features)
Tecnología • Estimar Sprint Backlog en horas
Planificación del Sprint (1 de2)
Durante Reunión de Planificación del Sprint la iteración es planificada
La reunión se restringe a un bloque de tiempo de ocho horas para un Sprint de un mes.
Consta de dos partes.

•Un bloque de cuatro horas, es cuando 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 Backlog que el Equipo selecciona es una decisión del Equipo. Sólo el
Equipo puede evaluar lo que puede lograr en el próximo Sprint.
Una vez seleccionado el 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 en el Sprint Backlog, ya sea durante
la Reunión de Planificación del Sprint, o sobre la marcha durante el Sprint.
El Equipo también puede 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 comportamiento de un verdadero equipo.
Codificar la capa intermedia (8 hrs)

Visualizar información Codificar la interfaz de usuario (4)
Escribir los casos de prueba (4)
de Clientes VIP Codificar la clase clientes (6)
Actualizar test de performance (4)
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 mantienen constantes durante todo el
Sprint.
Si el Equipo siente que se ha comprometido a demasiado trabajo, se reúne con el Propietario del
Producto para eliminar o reducir el alcance del Product Backlog seleccionado para el Sprint.
Si el Equipo siente que puede tener tiempo de sobra, puede trabajar con el Propietario
del Producto para seleccionar elementos adicionales del Product Backlog.
Un Sprint puede ser cancelado antes de que el bloque de tiempo del Sprint se haya terminado.
Sólo el Propietario del Producto tiene la autoridad para cancelar el Sprint, aunque puede
hacerlo bajo la influencia de los interesados, del Equipo, o del ScrumMaster.
Cuando un Sprint se cancela, cualquier elemento del Product Backlog que haya sido completado y
"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, pueden hablar
– Ayuda a evitar otras reunionesinnecesarias
ScrumDiario
• Todos responden 3 preguntas:
¿Qué hiciste
ayer? 1
¿Qué vas a
hacer hoy? 2
¿Hay
obstáculos en 3
tu camino?
• 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 Propietario del 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ó estos problemas.
El Equipo entonces muestra el trabajo que ha sido completado y responde

preguntas.
El Propietario del Producto a continuación, analiza el Product Backlog en 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 ScrumMaster alienta 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

• Sprint
• Scrum Diario
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
Idealmente cada tema tiene valor para el usuario o el cliente
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.

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 Backlog deben tener los siguientes atributos: una
descripción, una prioridad, y una estimación. La prioridad está guiada por el riesgo,
el valor y la necesidad.
El Product Backlog está ordenado por prioridad. La parte más prioritaria del Product
Backlog determina las actividades de desarrollo que se llevarán a cabo de forma
inmediata.
Las pruebas de aceptación se utilizan a menudo como un atributo má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 8

habitación disponible
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 tareas para 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
eXtreme Programming
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 El software que La colaboración con

La respuesta al
su interacción, por funciona, por el cliente, por
cambio, por encima
encima de los encima de la encima de la
del seguimiento de
procesos y las documentación negociación
un plan.
herramientas. exhaustiva. contractual.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda
Introducción
Método más popular El más transgresor dela
entre los metodos ortodoxia basada en Creado por Kent Beck
ágiles procesos.
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
Base de la
programación
extrema
Implica resolver
Agiliza el
en cada
desarrollo y
momento solo
facilitar el
las necesidades
mantenimiento
actuales
Simplicidad
Desarrollo solo Mantener el
el sistema que código simple a
realmente se medida que
necesita crece
Nomenclatura
de las variables, Documentación
métodos y del código
clases
Base de la
programación
extrema
El cliente se
integra en el Si el código es
equipo para complejo hay que
establecer esforzarse para
prioridades y hacerlo
resolver dudas
Comunicación
Comunicación El código
directa y continua autodocumentado
a clientes y es mas fiable que
desarrolladores los comentarios
Programación por
parejas
Opinión del cliente
en tiempo real
La planificación no Ciclos muy cortos

evidencia errores, tras los cuales se
que se evidencian muestran
al desarrollar resultados
Retroalimentación
Los fallos se El código también

localizan muy es una fuente de
pronto retroalimentación
Desarrollo
incremental, con
entregas y pruebas
frecuentes y
continuas
Utilizar la
programación
por parejas
Tratar con el
cliente los
Implementar las
desajustes de
características
agendas para
presentes
decidir cambios
en entregas
Coraje
Mejorar el
código siempre Tomar
que tras el decisiones
feedback e dificiles
iteraciones
Reparar un error
cuando se
detecta
Los miembros del
equipo se respetan
los unos a otros
Los miembros se
Los miembros del
respetan su trabajo
equipo respetan el
porque siempre
trabajo del resto no
haciendo menos a
Respeto buscan, calidad,
optimización,
otros
eficiencia
Los programadores
no realizan cambios
que hacen que las
pruebas existentes
fallen o que demore
el trabajo de sus
compañeros
Ciclo deVida
Exploración
Muerte del Planificación de

proyecto la Entrega
Mantenimiento Iteraciones
Producción
Prácticas deXP
• Conjunto de actividades simples que guían los diferentes aspectos del desarrollo para seguir
el proceso.
Propiedad
El juego dela Integración
colectivadel
planificación continua
código
Liberaciones Programación Ritmo

pequeñas en parejas sostenible
Diseño simple Refactorización Disponibilidad

del cliente
Metáforas Pruebas Estándares de

Unitarias programación
Roles enXP
Encargado de
Programador
seguimiento
(Programmer)
(Tracker)
Encargado de
Cliente (Customer)
pruebas (Tester)
Entrenador (Coach) Roles 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 de software
Lean SoftwareDevelopment
Eliminar
desperdicios
Los 7
principios
Maximizar el Apoderar al
básicos: aprendizaje equipo
Lean
Aplazar Entregar
decisiones rapido
Construir
Optimizar el
calidad
conjunto
interna
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

Sesión I

Cargado por

Copyright:

Formatos disponibles

Sesión I

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesión I

Cargado por

Copyright:

Formatos disponibles

Gestión Ágil de Proyectos

 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

• Origen de la Dirección de Proyectos

Es un método de basado en el desarrollo iterativo e

A los individuos y El software que La colaboración

Nuestra principal prioridad es satisfacer al cliente a través

Son bienvenidos los requisitos cambiantes, incluso si llegan

Entregar con frecuencia software que funcione, en periodos

Las personas del negocio y los desarrolladores deben

Construcción de proyectos en torno a individuos motivados,

La forma más eficiente y efectiva de comunicar información de

El software que funciona es la principal medida del progreso

Los procesos ágiles promueven el desarrollo sostenido. Los

La atención continua a la excelencia técnica enaltece la

La simplicidad como arte de maximizar la cantidad de trabajo

Las mejores arquitecturas, requisitos y diseños emergen de

En intervalos regulares, el equipo reflexiona sobre la forma de

Velocidad Triple restricción

Adaptabilidad Control de cambios

• Estabilidad de los requisitos

Pregunta 2: The end result of an Agile development is:

A. A product of a professional quality which fits the business need

Pregunta 4: When handling team dynamics, the Agile Leader should …

A Empower the team members, within appropriate limits

A. Do no documentation because it is a waste of time

Pregunta 6: The Agile way is:

A. To produce working product of the right quality, early and incrementally

Scrum es un proceso ágil que Nospermite rápidamente y en

El negocio fija lasprioridades.

Incremento del producto

Requisitos Diseño Código Test

Enlugar de hacer todo de una cosa ala vez ...

Losequipos Scrum hacen un poco de todo, todo el

Roles Bloques de Tiempo Artefactos

Roles Bloques de Tiempo Artefactos

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

El propietario del producto no puede ser nunca el ScrumMaster.

Mantiene el Product Backlog y asegura la visibilidad del mismo para todos.

El Propietario del Producto es una persona, no un comité.

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.

Explica al Propietario del Producto cómo hacer su trabajo

El ScrumMaster nunca debe ser el Propietario del Producto.