Este documento presenta una introducción a Scrum, incluyendo sus fases (inicio, planificación, implementación, revisión y retrospectiva, lanzamiento), roles (propietario del producto, scrum master, equipo scrum) y cómo escalar scrum a proyectos y portafolios más grandes. También describe conceptos ágiles como el manifiesto ágil y sus principios.

1. SCRUM

2. •BIENVENIDOS
Soy Freddy Vargas
• INGENIERO INFORMATICO ADMINISTRATIVO
• MAESTRÍA EN DIRECCIÓN ESTRATÉGICA EN TECNOLOGÍAS (MDTI)
• MAESTRÍA EN ADMINISTRACIÓN DE EMPRESA (MBA)
• MICROSOFT CERTIFIED TRAINER (MCT)
• MCSE (Microsoft Certified Systems Engineer )
• MCSA (Microsoft Certified Systems administrator )
• ITIL TRAINER CERTIFIED
• SCRUM CERTIFIED
• CIW (Certified Internet Web Professional)
• COMPTIA NETWORK +
• Linkeid : https://www.linkedin.com/in/freddy-julio-vargas-iba%C3%B1ez-6837661/
• Mi correo : frevar1975@Gmail.com /

3. 2
HELLO!
Bienvenidos

4. Temario
4. Fases de Scrum
4.1. Inicio
4.2. Plan y estimación
4.3. Implementación
4.4. Revisión y retrospectiva
4.5. Lanzamiento
5. Escalando Scrum
5.1. Escalabilidad de Scrum
5.2. Scrum in programas y portfolios
5.3. Reuniones de Scrum de Scrums (SoS)
5.4. Transición a Scrum
5.5. Trazo de las funciones tradicionales de
Scrum
5.6. Mantener involucrados a los socios
5.7. Importancia del apoyo ejecutivo
1. Descripción de Agile
1.1. El surgimiento de Agile
1.2. El manifiesto de Agile
1.3. Principios del manifiesto de Agile
1.4. Declaración de interdependencia
1.5. Métodos de Agile
1.6. Agile vs. TM
2. Descripción de Scrum
2.1. Principios de Scrum
2.2. Aspectos de Scrum
2.3. Procesos de Scrum
2.4. Ventajas de Scrum
3. Scrum Roles
3.1. Funciones de Scrum
3.1.1. Propietario del producto
3.1.2. Scrum Master
3.1.3. Equipo de Scrum
3.2. Funciones no central

5. 1. Descripción de
Agile

6. 1. Descripción de Agile
1.1. El surgimiento de Agile
1.2. El manifiesto de Agile
1.3. Principios del manifiesto de Agile
1.4. Declaración de interdependencia
1.5. Métodos de Agile
1.6. Agile vs. PM

7. 1.1 El surgimiento
de Agile

8. Metodologías de desarrollo
Es el entorno que se usa
para estructurar, planificar
y controlar el proceso de
desarrollo de un sistema
de información.
Cada proyecto define que
metodologia usar
deacuerdo a sus fortalezas
y debilidades.
Consiste en:
–Una filosofía de desarrollo de
software.
–Asistir en el proceso de
desarrollo de software.
–Suele estar documentada y
alguna clase de
documentación formal.

9. • Requerimientos fuera de control
• No cumplimiento de los tiempos planificados (desvíos)
• Estimaciones deficientes
• Re trabajo excesivo
• Baja calidad
• Costos excedidos
• Insatisfacción del Cliente
• Insatisfacción de los profesionales participantes
¿Cómo surge?

10. Métodos clásicos

11. Modelos de Procesos
de Desarrollo de Software
12:59
Los modelos de proceso de desarrollo de software han evolucionado de acuerdo a
las necesidades reales, si bien puede ser tentador adoptar las últimas innovaciones
en el modelos de procesos de desarrollo software, vale la pena obtener una
perspectiva de los puntos fuertes y débiles de cada modelo. Un proyecto puede
encontrar que algunos modelos de proceso son más complejo o amplios que lo que
necesitan.

12. Modelos Lineales
12:59
Procesos lineales son más adecuados para proyectos donde hay muy poca
retroalimentación o perfeccionamiento esperado.
Modelos de procesos lineales siguen un
patrón de completar las fases, una por
una, sin retorno a las fases anteriores.
El producto es esencialmente
especificado, diseñado, desarrollado y
puesto en producción sin ninguna
oportunidad de revisar las fases
anteriores.

13. Modelos Lineales
El modelo de cascada es un modelo de proceso
lineal, donde cada fase produce un producto de
trabajo aprobado que será utilizado en la
siguiente fase.
12:59
Modelo Cascada
Requerimientos
Diseño
Implementación
Verificación
Mantenimiento
Ventajas
• Este proceso es fácil de entender,
ello define claramente entregables
e hitos.
• Hace hincapié en la importancia
del análisis antes de diseño, y el
diseño antes implementación.
• Puede adoptarse para de piezas
bien especificadas del producto
que pueden ser externalizados.
Desventajas
•No es muy adaptable a los
cambios.
• No está diseñado para hacer
frente a los cambios a mitad de
camino fácilmente o sin un gran
costo.
• Las pruebas se producen tarde
en el proceso, y defectos finales
encontrados tienden a ser más
difícil y costosos de solucionar.
• El cliente no ve el producto hasta
cerca del final del desarrollo.

14. Modelos Lineales
El modelo V fue creado en respuesta al
problema identificado del modelo cascada; es
decir, se agrega un enfoque más completo en
las pruebas de la producto. La característica y
distintiva del mismo nombre Vmodel son las
dos ramas que convierten una estructura lineal
en una Forma de "V".
12:59
Modelo V (Validación y Verificación)
Permite al equipo de desarrollo
verificar el producto en múltiples niveles en
fases específicas, es una mejora
sobre el modelo de cascada.
Mejora
Ventajas
• Este proceso es fácil de entender,
ello define claramente entregables
e hitos.
• Hace hincapié en la importancia
del análisis antes de diseño, y el
diseño antes implementación.
• Puede adoptarse para piezas
bien especificadas del producto
que pueden ser externalizados.
Desventajas
•No es muy adaptable a los
cambios.
• No está diseñado para hacer
frente a los cambios a mitad de
camino fácilmente o sin un gran
costo.
• Las pruebas se producen tarde
en el proceso, y defectos finales
encontrados tienden a ser más
difícil y costosos de solucionar.
• El cliente no ve el producto hasta
cerca del final del desarrollo.

15. Modelos Lineales
12:59
Modelo V (Validación y Verificación)
Requerimientos
Especificación
Arquitectura
Diseño detallado
Prueba de
aceptación
Prueba del sistema
Prueba de integración
Prueba unitaria
verifica a
verifica a
verifica a
verifica a
Codificación

16. Modelos Lineales
El cliente está involucrado en opinar en
prototipos intermedios del producto
durante el proceso. Como el proceso
avanza linealmente, hay fases que
implican al cliente (sección superior del
diagrama) y fases que implican sólo el
equipo de desarrollo en la sección
inferior.
12:59
Modelo Diente de Sierra (Sawtooth model)
Requerimientos
Análisis
Prototipo 1 Prototipo 2 Aceptación
Diseño Implementación
Prueba
Equipode
Desarrollo
Cliente
Ventajas
• El cliente involucrado aumenta la
probabilidad de que el producto
cumplirá con las necesidades del
cliente.
Desventajas
•Modelo de Diente de Sierra es
todavía un proceso lineal, por lo
que hay un límite la incorporación
de algo más que cambios
incrementales.

17. Modelos Iterativos
12:59
Modelos de procesos iterativos difieren
de los modelos de procesos lineales en
que están diseñados para la repetición
de las etapas del proceso.
La ventaja de los procesos
iterativos es la capacidad de
bucle y volver a fases
anteriores (y sus actividades)
como parte de la proceso.
Cada "back loop" es una
iteración, por lo que se llama
el "Proceso iterativo."
Iteraciones permiten la
retroalimentación del cliente
para ser incorporado en el
proceso.
Son susceptibles a las Prácticas
Agiles, sin embargo, todavía
tienen porciones secuenciales
de reminiscencia de los
modelos de procesos lineales.
Por:CarolinaSandoval

18. Modelos Iterativos
Una versión simplificada del modelo de espiral tiene
cuatro fases: determinar los objetivos, identificar y
resolver los riesgos, desarrollar y probar, y planificar
la siguiente iteración.
Tomado en orden, las cuatro fases representan una
iteración completa.
12:59
Modelo Espiral
Ventajas
• Existe una retroalimentación
cliente
• El cliente puede ver prototipos
del producto mas temprano
Desventajas
• Estimación de trabajo puede
ser más difícil, dependiendo
de la duración del ciclo de
iteración en el modelo de
espiral ; largas iteraciones
pueden introducir más
incertidumbre en las
estimaciones.
• Requiere mucha experiencia
analítica a evaluar los riesgos.

19. Modelos Paralelos
12:59
•El modelo espiral es un
verdadero proceso
iterativo para el
desarrollo de software,
lo que significa que el
producto está
construido en una serie
repetida de fases, y
mejoras de productos
son introducidos en
fases específicas dentro
del ciclo.
• Procesos paralelos
utilizan un estilo
similar de iteración,
productos se
construyen en
iteraciones.
• Sin embargo,
procesos paralelos
permiten una mayor
concurrencia de
actividades y tareas.
Por:CarolinaSandoval

20. Modelos Paralelos
12:59
Modelo de Proceso Unificado
• El modelo de Proceso Unificado es un
modelo iterativo de desarrollo software.
Su estructura básica tiene fases
secuenciales dentro de un ciclo repetible.
• En la mayor parte de la fases del modelo
de Proceso Unificado, el trabajo pasa en
pequeñas iteraciones hasta que la fase es
considerada completa.
• Por lo general, las fases se consideran
completas cuando un hito, un punto
específico e identificable en un proyecto,
es alcanzado.
Tiene cuatro fases:
1. Fase inicial
2. Fase de Elaboración
3. Fase de construcción
4. Fase de Transición

21. Modelos Paralelos
12:59
Modelo de Proceso Unificado
Fase Inicial
Esta primera fase está destinada
a ser corta, tiempo suficiente
para establecer un modelo de
negocio lo suficientemente
fuerte y financieramente
razonable para continuar a las
siguientes fases y desarrollar el
producto.
• Creación de casos básicos de
uso.
• Definir alcance del proyecto
• Estimación de costes y
programación.
• Definir riesgos
• Determinar la vialidad del
proyecto.
• Preparar entorno del
proyecto.
Fase de elaboración
El objetivo de la fase de
elaboración es crear modelos de
diseño y prototipos del
producto, así como para abordar
los riesgos.
Esta fase también es la primera
de las fases a incorporar
pequeñas iteraciones dentro de
la fase.
Además de definir la
arquitectura del sistema,
desarrollar diagramas de casos
de uso y diagramas de clases de
alto nivel, esta fase da la base
sobre la que el desarrollo real
será construido.
• Identificar arquitectura
• Validar arquitectura
• Desarrollar entorno del
• Determinar el equipo
Fase de Construcción
Aquí es donde el producto de
software comienza a tomar
forma.
Dado que el modelo de Proceso
Unificado es un proceso
paralelo, cuando el fase de
construcción comienza, el
trabajo fase de elaboración
todavía continuar.
El producto está construido de
forma iterativa a lo largo de la
fase de construcción hasta que
está listo para ser lanzado.
• Modelar, construir y probar
el sistema
• Desarrollar documentación
de soporte
Fase de Transición
La fase de transición el
diseño del producto se mide
contra las necesidades de los
usuarios.
Al término de la fase de
transición, es posible ciclo se
repita, puede haber una
necesidad de crear nuevas
versiones del producto o
incorporar retroalimentación
de los usuarios como un
medio de influir en los
planes para el desarrollo
posterior.
• Pruebas del sistema
• Pruebas de usuario
• Integración
• Despliegue
Por:CarolinaSandoval

22. Modelos Paralelos
12:59
Modelo de Proceso Unificado
Por:CarolinaSandoval

23. Prototipos
12:59
El desarrollo de productos de software, a través de una serie de prototipos intermedios es una práctica
común en muchos programas los procesos de desarrollo. Hay cinco tipos de prototipos:
Ilustrativos (Illustrative) Exploratorio (Exploratory) Desechable (Throwaway)
Prototipos desechables permiten la
oportunidad de aprender de los errores del
pasado. Esto permite la oportunidad de
construir el producto de software en una
arquitectura más robusta de segunda
generación, en lugar de una primera
generación sistema con parches y
correcciones.
Pueden ser dibujos en una servilleta,
un conjunto de diapositivas de la
presentación de diapositivas, puede
implicar storyboard, o Wireframes,
diagramas, fotografías la esencia de
un prototipo ilustrativo es para
mostrar una idea básica.
La esencia de un prototipo ilustrativo
es para mostrar una idea básica.
La motivación detrás prototipado
exploratorio es que los desarrolladores
de productos quieren estudiar la
viabilidad de una idea de producto.
Es acerca de cuan realizable de
desarrollar es el producto o lo útil puede
ser el producto, antes cometer un mayor
esfuerzo a la idea.
Look and feel

24. Prototipos
12:59
El desarrollo de productos de software, a través de una serie de prototipos intermedios es una práctica
común en muchos programas los procesos de desarrollo. Hay cinco tipos de prototipos:
Este enfoque es muy similar a los prototipos
incrementales, pero la diferencia se encuentra en el
prototipo de primera generación. En el prototipado
evolutivo, el prototipo de primera generación tiene todas
las características del producto, a pesar de que algunas
características pueden necesitar "evolucionar" o ser
refinado, en el prototipo incremental sólo tiene una
conjunto básico de funciones básicas.
Cuando un producto está construido y lanzado en
incrementos, es un prototipo incremental , trabaja en
etapas, basado en un sistema de "Triage« significa la
evaluación de cada uno de los componentes del sistema y
la asignación de una prioridad. Sobre la base de esa
prioridad, un producto de componentes se añaden de
forma incremental de "más importante" de "menos
importante.«
Prioridades para una serie de características de productos
de software se basa en tres categorías:
• "se debe hacer" (must be done)
• "se debería hacer" (should be done)
• " se podría por hacer " (could be done)
Incremental (Incremental) Evolutiva (Evolutionary)

25. Entrega Continua - Continuous Delivery
12:59
La Entrega Continua aplica la
automatización, de modo que versiones
intermedias del software funcionando
pueden ser más disciplinadas y
frecuentes. Esto permite a los
desarrolladores ofrecer más fácilmente
versiones de un producto continuamente
a medida que se construye.
El objetivo es tener un software
funcionando que se prueba, listo para
correr, y liberable a los demás.
Idealmente, el tiempo de hacer un
cambio de producto para tenerlo valorado
por un usuario final pueden ser cortos y
frecuentes.

26. Entrega Continua - Continuous Delivery
12:59
La Entrega Continua es una metodología de
desarrollo de software que hace uso de un
conjunto de patrones y buenas prácticas,
cuyo objetivo es conseguir una puesta en
producción rápida, frecuente, reproducible y
asumiendo pocos riesgos.
Para apoyar la Entrega Continua,
herramientas automatizadas son usadas para
construir e integrar el código, pruebas de
bajo nivel, paquete del producto en forma
liberable, e instalar o implementarlo en una
prueba ambiente.

27. Entrega Continua - Continuous Delivery
12:59
Entrega Continua asegura que hay un
prototipo listo para ser probado por los
usuarios finales y clientes a final de la
iteración.
El elemento principal de esta metodología de
trabajo es que es necesario que el software
esté siempre disponible para poder ser
instalado en el entorno accesible a los
usuarios en cualquier momento
Principios de la Entrega Continua
• Crear un proceso de
lanzamiento(release) de software
repetible y fiable.
• Automatizar todo lo que sea posible.
• Mantener todo bajo control de
versiones.
• Si duele, hacerlo con más frecuencia.
• Introducir calidad en el sistema.
• ¨Hecho¨ significa lanzado.
• Todo el mundo es responsable del
proceso de entrega.
• Mejora continua.

28. Entrega Continua - Continuous Delivery
12:59
Microsoft Daily Build
Para el Daily Microsoft Build, cada "iteración" de la fase de construcción se presenta en un día, de ahí
la "acumulación diaria", el punto de Microsoft Daily Build es para asegurar que los programadores
están todos sincronizados al principio de cada actividad de compilación.
Para controlar esto, Microsoft utiliza un sistema de integración continua. Todos los desarrolladores
pueden ver fácilmente cómo su trabajo encaja en el producto en su conjunto, y cómo su trabajo
afecta a otros miembros del equipo.
La integración continua no sólo mantiene desarrollador moral alta, sino que también aumenta la
calidad del producto.
La construcción diaria dá a los desarrolladores la capacidad de detectar errores rápidamente antes de
que se conviertan en un problema real.
Una construcción exitosa permite realizar pruebas durante la noche para proceder, con resultados de
la prueba informaron en la mañana.

29. La Historia de las Metodologías ágiles
El desarrollo ágil es un marco conceptual que reconoce las distintas
interacciones y cambios que ocurren en todo desarrollo de software.
Evolucionó a partir de varios métodos. El Término "Ágil" fue definido por el
"Manifiesto Ágil" en 2001. A continuación presentamos una línea de tiempo
con los principales eventos en la historia del movimiento ágil:
1930 - Ciclo PDCA
Walter Shewhart propone el ciclo de "Planear", "Hacer", "Estudiar" y
"Actuar", un concepto que luego fue difundido por Deming.
1940 - Kanban, Sistemas de Producción de Toyota y el Lean Manufacturing
(Manufactura esbelta)
Taiichi Ohno inventa el método Kanban en Toyota. El Lean Manufacturing es
una fuente de inspiración y precursor del movimiento ágil.

30. • 1974 - El Proceso de Desarrollo de Software Adaptativo
Un Paper de E.A. Edmonds presenta el concepto de "Proceso de Desarrollo de Software
Adaptativo" en 1974. Asimismo, también durante los 70, Tom Gild publica conceptos
sobre la Gestión de Proyectos Evolutiva
1992 - Crystal
Alistair Cockbur presenta los Métodos Crystal, el punto de inicio de la evolución de las
metodologías de desarrollo de software que eventualmente resultaron en lo que hoy se
conoce como el movimiento ágil.
Crystal puede ser aplicada en equipos de trabajo de entre 6 y 8 desarrolladores
localizados en la misma área, trabajando en sistemas no críticos para la vida (es decir
los fallos son tolerables).
1993 - Refactorización
Bill Opdyke presenta el concepto de "Refactorización" en su paper titulado "Creando
Superclases Abstractas por medio de la Refactorización".
La Refactorización de código es una técnica para la reestructuración de piezas de
código existente, alterando su estructura interna sin afectar su comportamiento con el
exterior, que se ejecuta para mejorar los atributos no funcionales de un software.

31. 1995 - Programación en Pares (Pair Programming)
Es un concepto que fue simultáneamente ideado, pero de forma independiente por varios autores. Por una
parte Jim Coplien publicó un Paper , que definió la "Programación en Pares" como un patrón de desarrollo de
software. Por otra parte Larry Constantine definió los "duos dinámicos" en su libro "Constantine on
Peopleware" del mismo año.
Este concepto se convirtió en una parte integral de la Programación Extrema.
Se han realizado muchas investigaciones que han demostrado la efectividad de la programación en pares. Sin
embargo, la filosofía no está reflejada en el Manifiesto Ágil.
1995 - Scrum
El método Scrum fue ideado por Ken Schwaber y Jeff Sutherland, quienes lo presentaron en la conferencia
OOPSLA 95 (Object-Oriented Programming, Systems, Languages & Applications) en Austin Texas. Jeff Sutherland
es el Presidente (CEO) de Scrum, Inc y Ken Schawaber es el fundador de Scrum.org.
Mike Beedle fue uno de los pioneros en adoptar Scrum y colaboró con su adopción en muchas organizaciones.
Como se sabe, Scrum es prácticamente el estándar de facto para el desarrollo ágil.

32. 1997 - Desarrollo guiado por funcionalidades / Feature Driven Development (FDD)
El método FDD fue inicialmente ideado por Jeff De Luca. En él se definen mejores prácticas
como son: Modelado de objetos de dominio, Desarrollo por funcionalidades, Propiedad
individual de las clases (Código), Equipos de trabajo por funcionalidad, Inspecciones,
Gestión de Configuración, Compilaciones regulares (periódicas) y visibilidad del avance y
resultados.
El Proceso FDD fue explicado por medio de la publicación del libro "Modelado Java a
Colores con UML: Componentes y Procesos Empresariales", cuyos coautores son Jeff De
Luca y Peter Coad.
1999 Desarrollo de Software Adaptativo
Jim Highsmith formalizó el concepto de Desarrollo de Software Adaptativo y público su
libro del mismo nombre. La idea creció y evolucionó hacia las metodologías de Desarrollo
Rápido de Aplicaciones (RAD). La metodología propone un ciclo de vida de 3 fases:
Especulación, Colaboración y Aprendizaje.
•

33. 1999 - Programación Extrema / Extreme Programming (XP)
Mientras trabajaba en Chrysler, Kent Beck desarrolla el concepto de Programación
Extrema, publicando el método en 1999 en un libro titulado "Extreme
Programming Explained". Como parte de la Programación Extrema, también
formuló los conceptos de Historias de Usuario y Planificación de Releases. La
metodología especifica buenas prácticas para la planificación, gestión, diseño,
codificación y pruebas.
Ward Cunningham y Ron Jeffries colaboraron con Beck al escribir el libro sobre XP,
a los tres se les considera los fundadores de la Programación Extrema.
1999 - Integración Continua
Kent Beck definió este concepto también, pero fue un paper de Martin Fowler el
que lo popularizó.

34. 2001 - El Manifiesto Ágil
Bob Martin, reúne a otros 16 líderes del movimiento ágil, para escribir el "Manifiesto Ágil",
que engloba las metodologías que hasta ese momento se les conocía como "Metodologías
de Desarrollo de Software de peso liviano".
2002 - Desarrollo guiado por pruebas / Test Driven Development (TDD)
El concepto se originó el enfoque de "Probar primero" asociado a la Programación Extrema
(XP). Luego tomo mayor con la publicación del libro "Desarrollo guiado por pruebas: Por
ejemplos" (Test Driven Development: By Example), escrito por Kent Beck.
Luego Kent Beck escribe otros libros sobre el tema como "Rediscovering Test-Driven
Development".
2002 - Planning Poker
También en 2002 nace la técnica de Planning Poker, ideada por James Greening y escrita en
un Paper.

36. El surgimiento de Agile
El manifiesto Ágil surge el 17 de febrero del 2001, cuando se
reunieron diecisiete críticos del desarrollo de software, y
acuñaron el término “metodología Ágil” para definir los
métodos que estaban surgiendo como alternativa a las
metodologías formales.
El manifiesto Ágil está conformado por 12 principios
asociados a 4 aspectos o pilares.
REF: http://agilemanifesto.org/iso/es/manifesto.html

37. Metodología Ágil
• Los métodos Ágiles son estrategias de desarrollo
de software que promueven prácticas que son
adaptativas en vez de predictivas, centradas en la
gente o en los equipos, iterativas, orientadas
hacia prestaciones y hacia la entrega, de
comunicación intensiva, y que requieren que el
negocio se involucre en forma directa.

38. • En febrero de 2001, tras una reunión celebrada
en Utah-EEUU, nace el término “ágil” aplicado al
desarrollo de software.
• Participan un grupo de 17 expertos de la industria
del software, incluyendo algunos de los creadores
o impulsores de metodologías de software.

39. Quienes firmaron?
Kent Beck
Mike Beedle
Arie van
Bennekum
Alistair Cockburn
Ward
Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C.
Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

40. • Su objetivo fue esbozar los valores y principios que
deberían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que puedan
surgir a lo largo del proyecto.
• Se pretendía ofrecer una alternativa a los procesos de
desarrollo de software tradicionales, caracterizados por ser
rígidos y dirigidos por la documentación que se genera en
cada una de las actividades desarrolladas.

41. • Tras esta reunión se creó The Agile Alliance3, una
organización, sin ánimo de lucro, dedicada a promover
los conceptos relacionados con el desarrollo ágil de
software y ayudar a las organizaciones para que
adopten dichos conceptos.
• El punto de partida es fue el Manifiesto Ágil, un
documento que resume la filosofía “ágil”.

42. ¿Qué es agilidad?
“Agilidad es la capacidad de
crear y responder al cambio con
el fin de obtener ganancias en
un entorno empresarial
turbulento”
“La agilidad es la capacidad de
equilibrar la flexibilidad y
estabilidad”

43. • En cualquier tipo de disciplina de gestión, ser ágil es una
cualidad, por lo tanto esto debe ser una meta que se debe
tratar de alcanzar.
• La gestión de proyectos Agile especialmente, implica la
adaptabilidad durante la creación de un producto, servicio
o cualquier otro resultado.

44. ¿Por qué metodologías
ágiles?
El 80% de todos los proyectos
emplearán Métodos Ágiles en los
próximos años (Gartner).
Casi tres cuartas partes (71%) de
las organizaciones informan que
utilizan enfoques ágiles a veces, a
menudo o siempre. (Fuente:
Project Management Institute)

45. BENEFICIOS DE IMPLEMENTAR METODOLOGÍAS ÁGILES
Gracias a la flexibilidad y capacidad de adaptación de las
mismas, son muchos los beneficios de incorporar
metodologías ágiles a la gestión de las organizaciones. Aquí
te contamos los principales:
1.Reducción de costos.
2.Rapidez en la entrega de proyectos.
3. Trabajo en equipo y compromiso de todos los miembros del equipo de trabajo.
4. Mayor calidad en el trabajo y en el producto final (ya sea producto o servicio).

47. Diferencias entre metodologías
Metodologías Ágiles
• Basadas en heurísticas
provenientes de prácticas de
producción de código
• Especialmente preparados
para cambios durante el
proyecto
• Impuestas internamente (por
el equipo)
• Proceso mucho más
controlado, con numerosas
políticas/normas
• No existe contrato tradicional
o al menos es bastante flexible
Metodologías tradicionales
• Basadas en normas
provenientes de estándares
• Seguidos por el entorno de
desarrollo
• Cierta resistencia a los
cambios
• Impuestas externamente
• Proceso menos controlado,
con pocos principios
• Existe un contrato prefijado

48. • El cliente interactúa con el
equipo de desarrollo
• Grupos pequeños (<10
integrantes) y trabajando en el
mismo sitio
• Pocos artefactos
• Pocos roles
• Menos énfasis en la
arquitectura del software
• El cliente es parte del equipo
de desarrollo mediante
reuniones
• Grupos grandes y
posiblemente distribuidos
• Más artefactos
• Más roles
• La arquitectura del software
es esencial y se expresa
mediante modelos
Metodologías Ágiles Metodologías tradicionales

50. Cuándo emplear un enfoque predictivo
El enfoque predictivo es útil cuando se tienen certezas sobre el proyecto y se
conocen las variables y los resultados del mismo. Este enfoque implica
básicamente una única fase conceptualización al inicio, seguida por un largo
período de producción o desarrollo, que termina en la entrega del objeto resultante
del proyecto (producto o servicio).
• Las fases de un enfoque en cascada incluye:
– Conceptualización del proyecto
– Diseño del proyecto
– Ejecución del proyecto
– Evaluación de proyecto
– Entrega del resultado del proyecto
• ¿Cuándo resultaría una opción adecuada?
– El proyecto es familiar para el equipo.
– Es poco probable que el alcance y los parámetros del proyecto cambien
– Existe una detallada documentación sobre el proceso de ejecución del proyecto
– En el contexto del proyecto es preferible la previsibilidad al cambio.
– No hay experiencia en otras metodologías de proyecto.

51. Cuándo emplear un enfoque adaptativo
Las metodologías Ágiles enfatizan la importancia de la retroalimentación incremental en el
proceso de desarrollo del proyecto.
Los proyectos se completan en iteraciones en base a una serie de entregas incrementales en
lugar de un solo producto final.
Como resultado, el alcance del proyecto se modifica fácilmente de acuerdo con las necesidades
cambiantes de la organización. La Agilidad como enfoque de gestión suele ser bien recibida por
los involucrados en el proyecto, ya que la mayoría siente que tales técnicas conducen a una
mejor calidad y productividad, y aumentan el compromiso del equipo.
Aunque los pasos en un enfoque Ágil pueden variar según el método empleado, generalmente
incluyen:
– La ideación y conceptualización del proyecto.
– Producción de un subconjunto de componentes funcionales del proyecto.
– Entrega del subconjunto de componentes para la retroalimentación.
– Implementación de retroalimentación en el diseño del proyecto.
– Producción de otro subconjunto de componentes bajo los parámetros redefinidos.
¿Cuándo resultaría una opción adecuada?
– El objeto del proyecto puede entregarse de manera iterativa e incremental
– Los parámetros del proyecto son evolutivos o indeterminados.
– La organización se adapta fácilmente al cambio.
– El contexto del proyecto es una industria que está cambiando rápidamente.

52. 1.2 El Manifiesto
Agile

53. 1.2 El manifiesto de Agile

54. 1.2 El manifiesto de Agile

55. Individuos e interacciones sobre
procesos y herramientas
Este primer valor nos habla de la importancia que tienen las personas y sus interacciones.
Un ejemplo muy común, contrario a este valor, es mandar correos a la persona que
tenemos a nuestro lado o mandarle mensajes por el chat de la empresa en lugar de la
comunicación cara a cara, directa y efectiva, y que aunque suene impresionante, esto
ocurre realmente todos los días en las organizaciones.
Otro aspecto importante es la importancia que se le da a las motivaciones de las
personas, de los equipos de desarrollo. Anteriormente trabajábamos bajo el esquema de
administración científica en donde solo dábamos órdenes y buscábamos tener un control
absoluto de todo. Hoy en día expertos en administración nos hablan de la importancia de
entender las emociones de los integrantes del equipo, para apoyarlos e influenciarlos
positivamente y así puedan desempeñarse mejor en su trabajo
.
En cuanto a los procesos y herramientas, no significa que no haremos uso de ellos, la clave
es buscar que las herramientas nos ayuden a colaborar en equipo, comunicarnos
efectivamente y a hacer nuestro trabajo más productivo, no buscamos implementar
herramientas que por querer adecuarnos a ellas terminemos realizando procesos
burocráticos que impidan la creatividad y la agilidad.

56. Software que funciona sobre
documentación exhaustiva
La métrica / indicador más valioso en el mundo de la agilidad es el “software
que funciona”. Es de gran importancia contar con algo tangible que pueda
ayudar a los usuarios a tomar decisiones importantes en cuanto a su
producto.
Este indicador también es clave para los equipos desarrollo ya que les da
claridad y elimina ambigüedades gracias al feedback temprano que los
usuarios.
Todo esto a diferencia de la forma tradicional de mostrar avances con
porcentajes, documentos de estatus o grandes listas de requerimientos
firmadas con sangre que realmente nos dicen muy poco de lo que realmente
se está construyendo.
Cabe mencionar que no vamos a dejar de documentar, de hecho se habla de
documentación “exhaustiva”, así que tenemos que identificar la
documentación que realmente nos de valor durante el desarrollo del
producto.

57. Colaboración con el cliente sobre
negociación de contratos
Punto controversial en donde las áreas de sistemas se cuidan porque
“el cliente no sabe lo que quiere” y las áreas del negocio se cuidan
porque “sistemas es lento y hace las cosas sin calidad”.
Necesitamos comenzar a derribar los muros entre el negocio y
sistemas y comenzar a colaborar como un mismo equipo en donde la
persona de la idea es parte del equipo de desarrollo y trabajan juntos
para poder lograr generar valor al negocio.
En este valor se hace mucho hincapié en la colaboración más que en la
negociación, primero conversemos y veamos cómo podemos trabajar
juntos y posterior negociemos sobre lo que incluirá el producto pero
de forma colaborativa.

58. Responder al cambio sobre
seguimiento a un plan
Si queremos sobrevivir en este mundo VUCA (Volátil, Incierto, Complejo y Ambiguo) en el que
vivimos es de suma importancia adaptarnos a los cambios.
La tecnología cambia todos los días, el mercado, los competidores, las necesidades,
prácticamente todo está en constante cambio y es por esto que debemos estar abiertos a
cambiar y a tratar de dejar de controlarlo todo.
En el mundo de software hablamos de que hay una gran incertidumbre y complejidad lo cual
hace una realidad el tener que trabajar de forma empírica aprendiendo sobre la marcha y
adaptando nuestro producto conforme avanzamos y descubrimos cosas nuevas.
El manifiesto nos incentiva a ajustar nuestro alcance incluso a mitad / final del proceso de
desarrollo y a “no” buscar seguir un plan ciegamente tratando de mantener las fechas y los
alcances originales.
Es importante recalcar que para vivir la agilidad e implementar marcos o metodologías agiles,
lo primero que tenemos que hacer es trabajar en el Mindset ágil de la gente, por lo cual el
primer paso es conocer estos valores, vivirlos uno mismo e incentivar a que los demás los
vivan y sean parte de su trabajo diario.

60. 1.3 Principios
Manifiesto Agile

61. Principios del Manifiesto Ágil

63. Principio 1: Nuestra mayor prioridad es satisfacer al
cliente mediante la entrega temprana y continua de
software con valor.
.

64. Principio 1: Nuestra mayor prioridad es satisfacer al
cliente mediante la entrega temprana y continua de
software con valor.
Primero que todo estas personitas deben entender que
entrega temprana no quiere decir exactamente que en una
semana ya vas a tener todo tu software en producción, todo
parte de la base de revisar qué cosas tienen más valor que
otras y así poder ir entregando de forma continua lo que los
clientes necesitan, al dar satisfacción al cliente, lograremos un
feedback temprano, un cliente feliz y por ende, al generar
valor, estaremos recibiendo directamente un beneficio
económico.
Entonces, por favor no pienses que desarrollar un proyecto
teniendo los principios ágiles como base, quiere decir que tu
proyecto saldrá más rápido y más económico.

65. Principió 2:
Aceptamos que los requisitos cambien, incluso en
etapas tardías del desarrollo

66. Principió 2:
Aceptamos que los requisitos cambien, incluso en
etapas tardías del desarrollo
Aquí se debe entender que el hecho de que aceptemos cambios, no
quiere decir que los vamos a realizar en el mismo tiempo que se tenía
previsto para hacer X cosa. Todo parte de que podemos hablar e
implementar cambios para evitar que la competencia nos gane, por lo
tanto no todo va a salir perfecto, un cambio es un cambio y debemos
adaptarnos.
Por favor nunca uses la frase “como eres ágil entonces te puedo
cambiar los requerimientos cuantas veces quiera e igual debes
cumplirme en el tiempo planeado” o “todos los requerimientos
pueden ser ambiguos porque para eso eres ágil”,
Nosotros nos adaptamos porque queremos entregar lo que el cliente
realmente necesita, pero no por esto quiere decir que te puedas
aprovechar de los equipos.

67. Principio 3:
Entregamos software funcional

68. Principio 3:
Entregamos software funcional
El ideal para todos es poder entregar software funcional y que funcione.
Tener cuidado de que como podemos entregar software en dos semanas,
entonces tienen la excusa perfecta para incluir un montón de requerimientos
gigantes, solo porque el equipo de desarrollo es ágil.
Recuerden que los procesos de construcción de software deben cumplir
ciertos pasos o procedimientos para poder entregar software de calidad para
que de verdad te genere valor, y con esto podamos obtener feedback
continuo, poder preguntar cosas como
• ¿vamos bien?,
• ¿qué necesitas?,
• ¿cómo te podemos ayudar?

69. Principio 4:
Los responsables de negocio y los desarrolladores trabajamos
juntos

70. Principio 4:
Los responsables de negocio y los desarrolladores trabajamos
juntos
Para que esto funcione, todas las personas se
deben integrar durante todo el proyecto, al tener
una mayor colaboración se generará directamente
una mayor resolución de problemas, al tener
colaboración, todos van a tener los objetivos
comunes, y si de verdad trabajan juntos van a tener
una mayor confianza.

71. Principio 5:
Los proyectos se desarrollan en torno a individuos motivados.

72. Principio 5:
Los proyectos se desarrollan en torno a individuos motivados.
Los mejores proyectos se desarrollan con individuos
motivados.
Ya está en el pasado eso de controlar la hora de llegada y
la hora de salida, está fuera de base eso de controlar si
van al baño o si gastan tiempo yendo a la tienda.
Eso de controlar que vean videos en youtube durante la
jornada laboral. Si las personas están motivadas van a
rendir más, van a trabajar y ser realmente productivos. Ya
es hora de aprender a darles la confianza que necesitan
para la ejecución del trabajo y apoyarlos cuando lo
necesiten,

73. Principio 6:
El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara

74. Principio 6:
El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara
Hoy en día Whatsapp, Skype, Hangouts, entre otros… se han
convertido en una barrera para la comunicación,
son muy buenas herramientas para otras necesidades de
comunicación, pero , si tienen a la persona cerca (y por cerca se
refiere a que si estas en un primer piso y la otra persona en el
segundo piso), lo mejor es acercarse y hablar con esa persona.
Creo que todos hemos vivido esos chats que tienen un historial
grandísimo y que por lo general se generan malos entendidos
porque cada quien lo lee en el tono que quiere interpretarlo; o
esos emails en los que una persona se demora 30 minutos
redactando y la otra parte muchas veces ni nos contesta.

75. Principio 7:
El software funcionando es la principal medida progreso

76. Principio 7:
El software funcionando es la principal medida progreso
Cuando hablamos de software funcionando es eso, tener la
documentación del proyecto NO quiere decir que ya
llevamos un 30% de avance.
Los papeles no te generan ingresos en producción.
El software funcionando, ES ese sistema que puede lograr
sacar realmente a producción, es el que te genera los
beneficios económicos y por ende, este debe ser el que
marque el progreso en tu proyecto.

77. Principio 8:
Los procesos Ágiles promueven el desarrollo sostenible.
debemos ser capaces de mantener un ritmo constante de
forma indefinida.

78. Principio 8:
Los procesos Ágiles promueven el desarrollo sostenible.
debemos ser capaces de mantener un ritmo constante de
forma indefinida.
Todos sabemos que en los proyectos de software de vez en cuando va a
ocurrir algún imprevisto, pero es diferente que de vez en cuando ocurra
algo a lo cual debamos darle manejo, a que sean esos proyectos en los que
todo el ritmo del proyecto es insostenible.
Por favor no sobrecarguen a los equipos de trabajo, ellos también tienen
vida social, una vida familiar que satisfacer, y al no dejarlos, lo único que va
a pasar es que el proyecto se venga a pique
Si tu equipo te dice que se demora 4 meses el desarrollo de algo, por favor
no cortes de raíz el tiempo a 2 meses, esto lo único que generará es
desánimo, sobreesfuerzo, incumplimiento, mala calidad y un montón de
otras cosas .

79. Principio 9:
La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad

80. Principio 9:
La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad
Si quieres obtener calidad desde el inicio debes permitir al
equipo tres cosas fundamentales, y es por esto que siempre
divido este principio en: (Atención Continua) + (Excelencia
Técnica) + (Buen Diseño) = (Mejora de la Agilidad).
A veces se piensan que el diseño de un software solo se hace
en una fase inicial o en un sprint cero, se tiene que entender
que esto es algo continuo.
La excelencia técnica no solo puede ser durante el desarrollo,
se debe pensar en todos los aspectos y esto es parte de la
agilidad.

81. Principio 10:
La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.

82. Principio 10:
La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
La simplicidad es esencial. La frase de “Menos es Más”, obviamente
sabiéndola usar, lo sencillo se mantiene más fácilmente, debemos enfocarnos
en resolver el problema real.
He visto aplicaciones en que para ciertas cosas terminan creando montones
de tablas en la base de datos y montones de pantallas de gestión, que a la
final nunca se usan.
Personas que llegan a darle mantenimiento a aplicaciones y que tienen que
pasar días de análisis tratando de entender lo que se hizo, cuando realmente
si se hubiera simplificado y hecho con lo esencial serían mejores aplicaciones.
Esto no quiere decir que porque es simple, no funciona o no cumpla con lo
esperado. Por el contrario, las soluciones simples por lo general generarán
más valor que las complejas.

83. Principio 11:
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados

84. Principio 11:
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados
Si en nuestros equipos existgen gente experta, gente que sabe hacer
su trabajo, pues entonces hay que derjalos que sean ellos los que
decidan como hacer las cosas, porque ellos son los que mejor saben
hacerlas.
Hay que evitar y dejar de decir a los equipos de desarrollo (y a las
personas en general) como hacer las cosas, recuerda que estás
tratando con seres humanos, no con máquinas a las cuales solo les das
instrucciones.
Si les otorgas la responsabilidad y la autonomía, van a tener mayor
conciencia y por ende obtendrás un aumento en la motivación, y ya
sabemos que cuando las personas están motivadas ejecutan grandes
proyectos, generan mejores ideas y son estas ideas las que por lo
general te llevarán hacer las mejores aplicaciones.

85. Principio 12:
Mejora Continua

86. Principio 12:
Mejora Continua
La mejora continua es una de los principios mas
usados en equipos de calidad.
No se trata de reinventar la rueda pero si se
trata de reunirse y revisar …..

87. EJEMPLOS DE USO AGIL

88. Zara
Zara aprovecha cuatro veces más sus recursos que la mayoría de marcas
gracias a su sistema ágil, así que no estará de más preguntarse, ¿qué hacen?
Que Ellos lo llaman postponement (su sistema ágil) , nosotros lo podemos
traducir como aplazamiento. Esta técnica consiste en posponer la creación, o
incluso el envío de productos, lo máximo posible y teniendo en cuenta su
récord logístico están en condiciones de hacerlo.
Los productos que fabrica Zara son difíciles de pronosticar; es decir, tienen un
ciclo de vida corto y nunca sabes con exactitud si van a gustar o no. Por lo
tanto, definir si se necesitan mil unidades o un millón es casi imposible. La
solución que ha encontrado Zara es hacer previsiones a la baja, en el caso de
que finalmente falten productos entonces arrancan la rueda de creación y
envío express, que ya tienen bien engrasada, y en menos de 15 días tienen el
problema de stock solucionado.

89. ¿Pero cómo consigue la logística de Zara ser tan eficiente y rápida? La clave está en la
central de Arteixo, en Galicia. Desde ella hay un constante feedback con todas las
tiendas del mundo, las cuales envían a diario información sobre lo que más se ha
vendido y lo que menos.
La clave es el feedback constante que existe entre la sede central de Arteixo (en
Galicia) y todas las tiendas del mundo, las cuales se encargan de mandar información
constantemente sobre qué prendas se venden más. Desde que una tienda pide una
nueva remesa de ropa hasta que la recibe, pasan más o menos 48 horas.
Primero, las tiendas hacen un pedido a la sede central gracias a un sistema
informático. Y después de que los gestores comerciales aprueben el pedido, las
fábricas empiezan a realizar el corte y la confección de las prendas. Se realiza el
hilvanado de la ropa entre España, Marruecos, Camboya y otros países, para luego
volver a mandarla a la sede central. Se realiza un control de calidad, y la ropa ya está
lista para ser enviada desde La Coruña hacia cualquier parte del planeta. Este sistema
de trabajar por encargo y la rapidez de fabricación han sido sin duda las claves para
que el sistema ágil de Inditex sea único en el mundo. .

90. Apple
Steve Jobs habló en más de una ocasión de cómo se gestionaban los equipos en
Apple para conseguir que todo fluyera. En este caso os he recuperado una entrevista
que hizo en 2010 en la que nos cuenta cómo Apple se organiza como una startup y
mediante una metodología ágil.
Según explicaba Jobs, Apple es una empresa “increíblemente colaborativa”. En ella
no hay ningún comité, lo que encuentras son personas al cargo de proyectos: una
persona está al cargo del sistema operativo del iPhone, otra persona está al cargo del
hardware del mac, otra persona está al cargo de la ingeniería del hardware del
iPhone, otra persona está al cargo del marketing mundial, otra persona está al cargo
de operaciones… Apple se organiza como una startup, la mayor startup del mundo.
Todos se reúnen durante 3 horas una vez a la semana y hablan de qué están
haciendo y cómo lo están haciendo. Cada responsable sabe lo que hacen los demás,
para tenerlo en cuenta en su propio trabajo, por lo que hay mucho trabajo en equipo
entre los responsables y ese trabajo se filtra luego hacia abajo, para pasar los
objetivos hacia el resto de los equipos de trabajo de la compañía.

91. • Tal y como contaba Jobs, para que este método funcione, todo depende de
que seas capaz de tener confianza en los demás responsables y
trabajadores; confianza en que van a poder hacer su parte del trabajo a
tiempo y bien, sin tener que estar vigilándolos todo el tiempo. Jobs
destacaba que algo en lo que son realmente buenos en Apple es en tratar
de averiguar cómo dividir las cosas en equipos, para que hubieran distintos
focos y objetivos dentro del conjunto del producto. Al final todos trabajan en
el mismo producto, pero cada uno se ocupa de un ciclo de vida del mismo,
sin perder la visión general, gracias a la colaboración y comunicación. En
cuanto al trabajo de Jobs, él en particular se pasaba el día reuniéndose con
los distintos equipos y trabajando con ellos en ideas y soluciones a
problemas.
• Cuando el entrevistador le pregunta: ¿y la gente está dispuesta a decirte
que estás equivocado? Jobs contesta, “si, tenemos maravillosas
discusiones”, a lo que el entrevistador le replica: “¿y las gana usted todas?”
– “Oh no, ¡Ojalá lo hiciera! No puedes hacer eso, si quieres contratar a
grandes talentos y quieres que se queden contigo, debes dejarles
tomar muchas decisiones y tu debes dejarte guiar por las ideas, no
por la jerarquía. De otra manera la gente no se quedaría”, le contesta
Jobs.

92. Facebook
En Facebook tienen una rutina que suelen llevar a cabo. Cuando se establece un
nuevo proyecto, se reúne a un equipo de personas que lo llevarán a cabo, unas 6 o
7, dependiendo de la magnitud del proyecto.
Estas personas son elegidas según las habilidades necesarias para hacer el
proyecto, así que en muchas ocasiones proceden de departamentos diferentes, con
distintos backgrounds, etc. En vez de coordinar el proyecto por mails, chats o hacer
una reunión a la semana para establecer quién hace qué y que cada uno se vaya a
hacerlo a su puesto de trabajo, lo que se hace es juntar a todo el equipo en una
sala, a parte del resto de la oficina, y trabajan allí hasta que se ha finalizado el
proyecto.
También pueden reunirse una o dos veces a la semana para dedicar todo el día al
proyecto. En esa sala cuentan con todo el material necesario y trabajan cada uno en
la parte del proyecto en la que son expertos. El hecho de estar todos juntos les
permite hablar y comunicarse directamente, estar al tanto de los cambios que se
van produciendo en tiempo real y tener siempre presente el trabajo de los demás
compañeros, que al final, no deja de ser el trabajo del resto de la cadena de
creación del proyecto.

93. PayPal
En PayPal los objetivos se revisan cada día y todos los equipos
involucrados echan un vistazo y discuten sobre qué van a hacer,
qué han hecho y qué aprendieron el día anterior.
En el caso de PayPal se combina el código con el contenido. El
producto final es una página web que comunica un servicio,
pero todo su servicio es inmaterial, no se puede tocar.
El trabajo más difícil es el de unir la parte técnica; el código, con
la comunicación; lo que la gente puede ver. El proceso que
siguen les permite tener constante comunicación de unos
equipos a otros y conocer los objetivos generales de la
empresa.
•

97. 1.4 Declaración de
Interdependencia

98. 1.4 Declaración de Interdependencia
La Declaración de interdependencia en la gestión de
proyectos fue escrita a principios del 2005 por un grupo
de 15 líderes de proyectos como un suplemento al
“Manifiesto Ágil”.
Enumera seis valores de gestión necesarios para
reforzar una mentalidad de desarrollo ágil,
particularmente en la gestión de proyectos complejos e
inciertos.

99. 1.4 Declaracion de Interdependecia
1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo
de valor.
2. Ofrecemos resultados fiables mediante la participación del cliente en las
iteraciones frecuentes, donde también son responsables por el trabajo.
3. Asumimos que habrá incertidumbre y las superamos a través de
iteraciones, anticipación y adaptación.
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las
personas son la fuente máxima de valor y creamos un entorno en el que
puedan tener un impacto positivo.
5. Aumentamos el rendimiento a través de la rendición de cuentas por
parte del grupo en cuestión de resultados y eficacia del equipo,
responsabilidades que todos comparten.
6. Mejoramos la eficacia y la fiabilidad a través de estrategias
situacionalmente específicas, procesos y prácticas.

100. 1.4 Métodos de
Agiles

101. Desarrollo ágil de software es
un conjunto de métodos en
el que las necesidades y
soluciones evolucionan a
través de la colaboración
entre equipos multifunción
y auto-organizados.
Concepto

102. Promueve la planificación adaptativa, desarrollo
evolutivo, entrega temprana y mejora continua,
promoviendo una respuesta rápida y flexible a los
cambios.
Es un marco conceptual que se centra en la distribución
de software de trabajo con la mínima cantidad de
trabajo.
Marco

103. 2.5. Métodos ágiles
Algunos frameworks y métodos de desarrollo de
software:
- Adaptive Software Development (ASD)
- Agile Modeling
- Agile Unified Process (AUP)
- Crystal Methods (Crystal Clear)
- Disciplined Agile Delivery
- Dynamic Systems Development Method
(DSDM)

104. 2.5. Métodos ágiles
Algunos frameworks y métodos de desarrollo de
software:
- Extreme Programming (XP)
- Feature Driven Development
- Lean Software Development
- Kanban
- Scrum

105. 105“tg-tatiana-oquendo”, http://tg-tatiana-oquendo.googlecode.com/svn/trunk/, agosto 2013

106. 1.6 Agile vs. Métodos
tradicionales

107. Diferencias entre
metodologías(1)
Metodologías Ágiles
• Basadas en heurísticas provenientes
de prácticas de producción de código
• Especialmente preparados para
cambios durante el proyecto
• Impuestas internamente (por el
equipo)
• Proceso mucho más controlado, con
numerosas
• políticas/normas
• No existe contrato tradicional o al
menos es bastante flexible
Metodologías tradicionales
• Basadas en normas provenientes de
estándares
• Seguidos por el entorno de desarrollo
• Cierta resistencia a los cambios
• Impuestas externamente
• Proceso menos controlado, con pocos
principios
• Existe un contrato prefijado

108. Diferencias entre
metodologías(2)
Metodologías Ágiles
• El cliente interactúa con el equipo de
desarrollo
• Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio
• Pocos artefactos
• Pocos roles
• Menos énfasis en la arquitectura del
software
Metodologías tradicionales
• El cliente es parte del equipo de
desarrollo mediante reuniones
• Grupos grandes y posiblemente
distribuidos
• Más artefactos
• Más roles
• La arquitectura del software es
esencial y se
• expresa mediante modelos

111. Pros y Contras de Agile
Pros
• Extremadamente flexibles
• Las soluciones se
elaboran rápidamente
• Resultados más rápidos e
utilizables
• Satisfacción del cliente
• Tiempo de respuesta más
rápido.
Contras
• La comunicación debe ser clara
y exacta, y puede no funcionar
si el cliente ni siquiera sabe lo
que quiere.
• No es adecuada para proyectos
más pequeños.
• Como sistema, podría ser fácil
revisar las prácticas
tradicionales.
• Costos y precios variables.

112. Pros y Contra de Métodos tradicionales
Pros
• Objetivos claros
• Adecuado para
proyectos más
pequeños
• Sin necesidad de
equipos especializados
o recursos
Contras
• Resultados más
lentos
• No hay lugar para
cambios
• Costos elevados si el
proyecto debe
reiniciarse

113. Conclusion
Conclusión
El tipo de gestión de proyecto que uno elige
depende únicamente del tipo de trabajo que
tenga. Ninguna gestión de proyectos es mejor que
la otra y los proyectos deben evaluarse a fondo
antes de comenzar para obtener resultados
efectivos y manejables.