Cmo surge?

Metodologas 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
burocrticos caminos de las
metodologas tradicionales
enfocndose en la gente y los
resultados
Manifiesto por el Desarrollo gil de
Software

Individuos e interacciones sobre procesos y

herramientas
Software que funciona sobre documentacin
exhaustiva
Colaboracin con el cliente sobre negociacin
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
compaeros del equipo
se amontonan, forman
una pia y empujan
todos en la misma
direccin.
 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 rpida
Un proceso que controla el caos de conflictos de
intereses y necesidades
 Scrum(2)
Una manera de mejorar las comunicaciones y
maximizar la cooperacin
Una manera de maximizar la productividad
Escalable a mltiples proyectos y toda la
organizacin
Una forma que todos se sientan bien con su
trabajo, entendiendo que cada uno con sus
contribuciones hizo lo mejor que poda hacer
 Diferencias entre
metodologas(1)
Metodologas giles
Basadas en heursticas
provenientes de prcticas de
produccin de cdigo
Especialmente preparados para
cambios durante el proyecto
Impuestas internamente (por el
equipo)
Proceso mucho ms controlado,
con numerosas
polticas/normas
No existe contrato tradicional o al
menos es bastante flexible
Metodologas
tradicionales
Basadas en normas provenientes
de estndares
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
metodologas(2)
Metodologas giles Metodologas tradicionales

El cliente interacta con el equipo El cliente es parte del equipo de

de desarrollo desarrollo mediante reuniones
Grupos grandes y posiblemente
Grupos pequeos (<10 distribuidos
integrantes) y trabajando en el
Ms artefactos
mismo sitio
Ms roles
Pocos artefactos La arquitectura del software es
Pocos roles esencial y se
Menos nfasis en la arquitectura expresa mediante modelos
del software
 Financiacin del proyecto
Define funcionalidad requerida
Retorno de la inversin del proyecto
Lanzamiento del proyecto
Toma las decisiones de priorizacin
Representa a todos los interesados en el producto final
 Auto - gestionado
Auto organizado
Multifuncional
Transforman los requerimientos en funcionalidad en cada incremento
 Formacin y entrenamiento de procesos
Incorporacin de Scrum en la cultura del equipo
Garanta 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 visin global del producto buscado.

Es el encargado de armar y priorizar el Product

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

Seleccin de la
Pila de producto
(Product Backlog)
-- Funcionalidades

Product Owner
(modificar cuidando la
inversin).
Pila de producto Stakeholders
-- Requisitos priorizados. (usuario, soporte
-- Listado con los requisitos tcnico,
del sistema. administradores,etc )
 Listado con los requisitos del sistema.
Listado de todas las a implementar.
Es dinmico.
Mientras exista un producto, el Product Backlog tambin 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 entrarn 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
 Gestin 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
duracin comprendida entre las 4 y las 16 horas de
trabajo.
Las de mayor duracin deben intentar
descomponerse en sub-tareas de ese rango de
tiempo.

24
 Gestin gil de proyectos: Scrum

Sprint

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

funcionalidad. Constituye el ncleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeas carreras.

Duracin mxima: 30 das.

Durante el sprint no se puede modificar el trabajo que se ha acordado en
el Backlog.
Slo es posible cambiar el curso de un sprint, abortndolo, y slo lo puede
hacer el Scrum Master si decide que no es viable por alguna de las
razones siguientes:
La tecnologa acordada no funciona.
Las circunstancias del negocio han cambiado.
El equipo ha tenido interferencias.

26
El Sprint
Al final del Sprint, se realiza una
reunin de revisin de Sprint,
llamada Sprint Review
Fin del sprint: Sprint review
4 horas

Reunin 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 reunin se interroga

individualmente a todos los asistentes para
recabar impresiones, sugerencias de
cambio y mejora, y su relevancia.
Despus 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 ms eficaz y eficiente para el
prximo 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 inspeccin
emprica y prcticas de la adaptacin 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 reunin celebrada en

Utah-EEUU, nace el trmino gil aplicado al
desarrollo de software. En esta reunin participan un
grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores e impulsores de
metodologas de software.

El punto de partida fue el Manifiesto gil, un

documento que resume la filosofa gil.

Segn el Manifiesto se valora:

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

Es ms importante construir un buen equipo.

Desarrollar software que funciona ms que
conseguir una buena documentacin.

No producir documentos a menos que sean

necesarios de forma inmediata para tomar un
decisin importante.
 La colaboracin con el cliente ms que la
negociacin de un contrato.
Se propone que exista una interaccin constante
entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la
marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir
estrictamente un plan.
Se debe ser hbil en responder a los cambios y a los
fracasos, la planificacin no debe ser estricta sino
flexible y abierta.