¿Cómo surge?

Metodologías ágiles de
desarrollo de software
Se entiende como Desarrollo ágil
de Software a un paradigma de
Desarrollo de Software basado en
procesos ágiles.
Procesos ágiles de
desarrollo
Intentan evitar los tortuosos y
burocráticos caminos de las
metodologías tradicionales
enfocándose en la gente y los
resultados
Manifiesto por el Desarrollo Ágil de
Software

 Individuos e interacciones sobre procesos y

herramientas
 Software que funciona sobre documentación
exhaustiva
 Colaboración con el cliente sobre negociación
de contratos
 Responder ante el cambio sobre seguimiento
de un plan
SCRUM
La palabra SCRUM
procede del vocabulario
del rugby y significa
melé; es decir, que los
compañeros del equipo
se amontonan, forman
una piña y empujan
todos en la misma
dirección.
 Scrum(1)
 Scrum es un proceso iterativo e incremental
que puede ser utilizado para
 desarrollar cualquier producto o administrar
cualquier trabajo. Sus principales
 atributos son:
 Un enfoque orientado a que los equipos
desarrollen sistemas y productos de manera
 iterativa e incremental cuando los requerimientos
cambian de manera rápida
 Un proceso que controla el caos de conflictos de
intereses y necesidades
 Scrum(2)
 Una manera de mejorar las comunicaciones y
maximizar la cooperación
 Una manera de maximizar la productividad
 Escalable a múltiples proyectos y toda la
organización
 Una forma que todos se sientan bien con su
trabajo, entendiendo que cada uno con sus
 contribuciones hizo lo mejor que podía hacer
 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
 Diferencias entre
metodologías(2)
Metodologías Ágiles Metodologías tradicionales

 El cliente interactúa con el equipo  El cliente es parte del equipo de

de desarrollo desarrollo mediante reuniones
 Grupos grandes y posiblemente
 Grupos pequeños (<10 distribuidos
integrantes) y trabajando en el
 Más artefactos
mismo sitio
 Más roles
 Pocos artefactos  La arquitectura del software es
 Pocos roles esencial y se
 Menos énfasis en la arquitectura  expresa mediante modelos
del software
 Financiación del proyecto
 Define funcionalidad requerida
 Retorno de la inversión del proyecto
 Lanzamiento del proyecto
 Toma las decisiones de priorización
 Representa a todos los interesados en el producto final
 Auto - gestionado
 Auto – organizado
 Multifuncional
 Transforman los requerimientos en funcionalidad en cada incremento
 Formación y entrenamiento de procesos
 Incorporación de Scrum en la cultura del equipo
 Garantía de cumplimiento de roles y responsabilidades
 Remueve impedimentos
 Facilitador
 Asegura que se cumpla Scrum
Product Owner
Representa los intereses del cliente
dentro de la empresa.

Es el nexo entre el cliente y el

equipo.

Tiene la visión global del producto buscado.

Es el encargado de armar y priorizar el Product

Backlog (Lista priorizada de requerimientos).
 Pila del sprint Nueva
funcionalidad

Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades

• Product Owner
(modificar cuidando la
inversión).
Pila de producto • Stakeholders
-- Requisitos priorizados. (usuario, soporte
-- Listado con los requisitos técnico,
del sistema. administradores,etc )
 Listado con los requisitos del sistema.
 Listado de todas las a implementar.
 Es dinámico.
 Mientras exista un producto, el Product Backlog también existe.
sprint
 Sprint Planning Meeting
(Reunion de planeamiento del
Sprint)
 Sprint Planning
 Los Sprints duran, idealmente, menos de
un mes.
 Se seleccionan los requerimientos del
Product Backlog que entrarán en el sprint.
 Se hace un listado de todas las tareas
necesarias para terminar el sprint backlog,
indicando el esfuerzo de cada una.
 Se asignan responsables a las tareas
Se divide en 2 partes y son:

 Las primeras cuatro horas se dedican

al Product Owner
 Las segundas cuatro horas el equipo
planea su propio Sprint
 Gestión ágil de proyectos: Scrum

Pila del sprint (Sprint Backlog)

Trabajo o tareas determinadas por el equipo para
realizar en un sprint y lograr al final del mismo un
incremento de la funcionalidad.
Se recomienda que las tareas reflejadas tengan una
duración comprendida entre las 4 y las 16 horas de
trabajo.
Las de mayor duración deben intentar
descomponerse en sub-tareas de ese rango de
tiempo.

24
 Gestión ágil de proyectos: Scrum

Sprint

Es el periodo de tiempo durante el que se desarrolla un incremento de

funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeñas “carreras”.

 Duración máxima: 30 días.

 Durante el sprint no se puede modificar el trabajo que se ha acordado en
el Backlog.
 Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede
hacer el Scrum Master si decide que no es viable por alguna de las
razones siguientes:
 La tecnología acordada no funciona.
 Las circunstancias del negocio han cambiado.
 El equipo ha tenido interferencias.

26
El Sprint
Al final del Sprint, se realiza una
reunión de revisión de Sprint,
llamada Sprint Review
Fin del sprint: Sprint review
4 horas

 Reunión donde se presenta al product

owner y a los implicados todas las
funcionalidades implementadas.

 ElProduct owner trata con los asistentes y

con el team las posibles modificaciones en
la pila de producto.

 Alfinal de la reunión se interroga

individualmente a todos los asistentes para
recabar impresiones, sugerencias de
cambio y mejora, y su relevancia.
Después del Sprint review y
antes de la proxima Sprint
planning meeting, el
ScrumMaster convoca a una
Sprint retrospective del Sprint
con el Team.
Sprint retrospective
3 horas

 ElScrumMaster hace que el Team revise,

su proceso de desarrollo Scrum, para
hacerlo más eficaz y eficiente para el
próximo Sprint.

 ElScrumMaster no proporciona
respuestas, sino que ayuda al equipo a
encontrar la mejor forma de trabajar con
Scrum.

En conjunto, Sprint planning meeting, Daily Scrum, Sprint

review, y el Sprint retrospective, constituyen la inspección
empírica y prácticas de la adaptación del Scrum.
Pila de producto: son la funcionalidad del sistema priorizada
SPRINT
Sala de Desarrollo
 El manifiesto Ágil y su incidencia en el
desarrollo de software

• En febrero de 2001, tras una reunión celebrada en

Utah-EEUU, nace el término “ágil” aplicado al
desarrollo de software. En esta reunión participan un
grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores e impulsores de
metodologías de software.

• El punto de partida fue el Manifiesto Ágil, un

documento que resume la filosofía “ágil”.

• Según el Manifiesto se valora:

• Al individuo y las interacciones del equipo de
desarrollo sobre el proceso y las herramientas.

• Es más importante construir un buen equipo.

• Desarrollar software que funciona más que
conseguir una buena documentación.

• “No producir documentos a menos que sean

necesarios de forma inmediata para tomar un
decisión importante”.
• La colaboración con el cliente más que la
negociación de un contrato.
• Se propone que exista una interacción constante
entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la
marcha del proyecto y asegure su éxito.
• Responder a los cambios más que seguir
estrictamente un plan.
• Se debe ser hábil en responder a los cambios y a los
fracasos, la planificación no debe ser estricta sino
flexible y abierta.