Introduccin a las

Metodologas giles

Ing. Juan Manuel Rojas Ochante

 Agenda

Situacin actual
Metodologas giles
Ejemplos
Conclusiones
 Software Hoy en Da

Mito: los programadores de ahora

ya no programan como los de
antes.

Herramientas ms fciles y
productivas
El software es cada da ms
complejo
 El xito es raro
Fallidos Problemticos Exitosos

2004 15% 51% 34%

2000 23% 49% 28%

Fuente: The Standish Group International, Extreme Chaos, 2004

Se pasan en coste:
45%
Se pasan en tiempo:
63%
No llegan a la funcionalidad:
67%
 El Problema con el Proceso
Predecible
Productivo
Repetible

Complejo
Desconectado
Difcil
 El Software

El software es un producto intangible el cual se logra a

travs de un proceso creativo ya que programar es un
arte, el cual no puede ser sistematizado del todo.

Por qu es importante el Desarrollo de Proyectos de

forma Metodolgica?

El software es cada vez ms complejo y costoso que se

compara con construir un edificio.
 Desarrollo de Software

Las metodologas de desarrollo de software son un

conjunto de mejores prcticas que si no se llevan a
la prctica no sirven de nada.

El factor humano es el recurso ms importante de

cualquier proyecto de software.

Cmo se desarrolla un proyecto de Software?

 Desarrollo de Software

En qu consiste el proceso de desarrollo de software?

Si pensamos que el software de desarrollo de software es

slo programar (que evidentemente es la parte ms
representativa) estamos muy equivocados.

El desarrollo de software consiste en mltiples

actividades.
Proceso de Desarrollo de Sw
 Proceso de Desarrollo de Sw

Por qu este modelo de cascada no funciona para

el desarrollo del software?
Porque los requerimientos de software son
sumamente cambiantes al ser un producto abstracto.
El objetivo de la Ingeniera del Software es lograr la
calidad del software.
La calidad tiene muchas perspectivas.
 Proceso de Desarrollo de Sw

Pressman clasifica las actividades del desarrollo de

software en las siguientes:
Comunicacin
Inicio del Proyecto
Recopilacin de Requerimientos
Planeacin
Estimacin
Itinerario
Seguimiento
 Proceso de Desarrollo de Sw

Modelado
Anlisis
Diseo
Construccin
Cdigo
Prueba
Despliegue:
Entrega
Soporte
Retroalimentacin
 Proceso de Desarrollo de Sw

La etapa de comunicacin es sumamente

importante:
 Metodologas de Software
Las metodologas de software ayudan a lograr la calidad
del software. Puedo lograr la calidad del software sin
usar metodologas?

Ejemplo: necesito hacer un nudo de corbata y no tengo

idea de cmo hacerlo

Cmo podra resolver el problema?

 Metodologas de Software

La solucin ms fcil es realizar outsourcing (que lo

hagan otros).

Sino se puede, se deber realizar en base a tres

formas bsicas de solucin de problemas:
Conocimiento
Experiencia
Sentido Comn
 Problema

Las metodologas son un conjunto de mejores

prcticas que si no se llevan a la prctica o se hacen
a medias es muy difcil que se tenga calidad.

Aun siguiendo las recomendaciones, una

metodologa no garantiza que un producto tenga
calidad.
 Qu es una Metodologa gil?

Las Metodologas giles valoran:

Al individuo y las interacciones en el equipo de desarrollo ms que a
las actividades y las herramientas

Desarrollar software que funciona ms, que conseguir una buena

documentacin Minimalismo respecto del modelado y la
documentacin del sistema

La colaboracin con el cliente ms que la negociacin de un contrato

Responder a los cambios ms que seguir estrictamente una

planificacin
 Por qu surgen las
Metodologas giles?

Dificultad para implantar metodologas tradicionales. Sofisticadas herramientas

CASE y notaciones (UML)

Una solucin a medida para un segmento importante de proyectos de desarrollo

de software

Pugna entre comunidades/gurs

Aceptar el cambio ...

Gestin del Conocimiento

 Costo de los Cambios en SW
Tradicional
Costo
del
cambio

Suposicin AMs

tiempo
 Principios de las AMs

Principios:
1. La prioridad principal es satisfacer al cliente mediante
tempranas y continuas entregas de software que le reporte un
valor

2. Dar la bienvenida a los cambios. Los AMs capturan los cambios

para que el cliente tenga una ventaja competitiva

3. Entregar frecuentemente software que funcione, desde un par

de semanas a un par de meses, con el menor intervalo de
tiempo posible entre una entrega y la siguiente
 Principios de las AMs

4. La gente del negocio y los desarrolladores deben trabajar juntos

a lo largo del proyecto

5. Construir proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para
conseguir el trabajo

6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo

7. El software que funciona es la medida principal de progreso

 El manifiesto gil
http://www.agilemanifesto.org

Estamos descubriendo formas mejores de desarrollar software tanto por

nuestra propia experiencia como ayudando a terceros. A travs de este trabajo
hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentacin extensiva
Colaboracin con el cliente sobre negociacin contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos ms los de la izquierda.
 Manifiesto de las AMs
8. Los procesos giles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante

9. La atencin continua a la calidad tcnica y al buen diseo mejora la

agilidad

10. La simplicidad es esencial

11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos

12. En intervalos regulares, el equipo reflexiona respecto de cmo llegar a

ser ms efectivo, y segn esto ajusta su comportamiento
 Comparacin
Metodologa gil Metodologa No gil
Pocos Artefactos Ms Artefactos

Pocos Roles Ms Roles

No existe un contrato tradicional Existe un contrato prefijado

o al menos es bastante flexible

Cliente es parte del equipo de El cliente interacta con el

desarrollo (adems in-situ) equipo de desarrollo mediante
reuniones
Grupos pequeos (< 10 Grupos grandes
integrantes) y trabajando en el
mismo sitio
Menos nfasis en la arquitectura La arquitectura es esencial
 Limitaciones
Proporcionan una ayuda limitada en equipos de trabajo
dispersos fsicamente
Proporcionan una ayuda limitada en equipos de trabajo
grandes
Consideran una ayuda limitada al tratamiento de
subcontratos
No privilegian la reutilizacin de componentes
Proporcionan una ayuda limitada para desarrollar software
de seguridad crtica
Proporcionan ayuda limitada para desarrollar software
grande y complejo
Dificultad en la utilizacin de herramientas que apoyen el
desarrollo
 Tipos de Proyectos
Grandes
Con requerimientos estables
Tradicionales Aplicaciones crticas
Grandes equipos de desarrollo
Equipo de desarrollo distribudos geogrficamente

Ambientes dinmicos, con equipos de trabajo pequeos y

produciendo aplicaciones no crticas
Agiles Requerimientos desconocidos o inestables, garantizando
un menor riesgo ante la posibilidad de cambio en los
requerimientos
 Principales Metodologas

SCRUM
Crystal Methodologies
Lean Programming
Kanban
DSDM (Dynamic Systems Development Method)
FDD (Feature-Driven Development)
XP (Extreme Programming)
Adaptative Software Development
SCRUM

Es una implementacin de
metodologa gil
Creada por Hirotaka Takeuchi e
Ikujiro Nonaka en 1986
 Principios de SCRUM

Equipo muy simple

Pila de funcionalidades (Backlog)
Reuniones diarias (Scrums)
Iteraciones (Sprints)
 Equipo

Propietario del producto

Da los requerimientos
Financia
Equipo
Autogestionado
Multidisciplinario
Scrum Manager
Supervisa y coordina los roles
Comprueba las tareas
 Backlogs

Listado de requisitos
Recopilado por el propietario del producto
Es una lista dinmica
Se subdivide en los diferentes sprints
 Sprints

Representan iteraciones
Por lo general de un mes
Cada sprint posee una pila extraida del backlog de producto
Los sprints se revisan al final para evaluarlos (retrospectivas)
Cada da se realiza una reunin para realizar el seguimiento del
sprint (SCRUM)
Reuniones cortas (15 minutos)
Slo hablan los implicados
 Qu es XP?

Es una metodologa gil

Diseada para entornos dinmicos
Pensada para equipos pequeos (hasta 10 programadores)
Orientada fuertemente hacia la codificacin
nfasis en la comunicacin informal, verbal
 Historia de XP

Creado por Kent Beck para la plantilla del proyecto C3 en

Chrysler
Kent fue contratado para dirigir el proyecto
Durante el proceso naci una nueva metodologa: eXtreme
Programming (XP)
C3 concluy exitosamente en 1997
 Valores que fomenta XP

Comunicacin

Simplicidad

Retroalimentacin

Coraje
 Roles XP
c2.com/cgi/wiki?ExtremeRoles
Jefe de Proyecto (Manager)
Organiza y gua las
reuniones
Asegura condiciones
Programador (Programmer) adecuadas para el proyecto

Responsable de decisiones tcnicas

Cliente (Customer)
Responsable de construir el sistema Es parte del equipo
Sin distincin entre analistas, Determina qu construir y
diseadores o codificadores cundo

En XP, los programadores disean, Establece las pruebas

funcionales
programan y realizan las pruebas
 ... Roles XP
Encargado de Pruebas
(Tester)
Ayuda al cliente con las
pruebas funcionales
Se asegura de que las
pruebas funcionales se
Entrenador (Coach)
superan Responsable del proceso

Rastreador (Tracker)
Tiende a estar en un
segundo plano a medida que
Metric Man el equipo madura
Observa sin molestar
Conserva datos histricos
 Captura de Requisitos en XP

Historias del Usuario (User-Stories)

Establecen los requisitos del cliente
Trozos de funcionalidad que aportan valor
Se les asignan tareas de programacin con un n de horas de
desarrollo
Las establece el cliente
Son la base para las pruebas funcionales
Modelo de un Proyecto XP
 Qu resultado proveen las
Metodologas giles?
Hay pocos datos concretos del ndice de xito de proyectos
Est teniendo un gran auge
Aumento en el nmero de proyectos
Por qu?
Tiene el apoyo de muchos en la ingeniera de sw
Es un proceso para gente que odia los procesos
Tiene sentido
Poltica? ... Pugna entre comunidades
 Cundo utilizar una
Metodologa gil?

Existe ya un proceso? Si
Reacciona bien a los cambios? Si
Est el equipo contento con l? Si

Mejor esperar
Se estn recogiendo datos
En un futuro se podrn hacer comparaciones sobre lo que es ms
conveniente
 ... Cundo utilizar una
Metodologa gil?

Existe ya un proceso? No
o existe pero no reacciona bien a los cambios
o existe pero el equipo no est contento con l

Una Metodologa gil puede ser una buena

forma de empezar
Fcil de financiar
Mayor aceptacin de los programadores
Mayor control de los clientes
 Conclusiones

Las Metodologas giles surgen como respuesta a problemas reales

Las metodologas tradicionales no son totalmente adecuadas para
todos los desarrollos software, principalmente por su falta de
flexibilidad
Los mtodos giles y los tradicionales no son competidores directos.
Cada uno de ellos tiene su propio segmento de aplicacin o terreno
Algunos aspectos del desarrollo de software se beneficiarn del
enfoque agilista mientras otros obtendrn beneficios de un enfoque
tradicional-predictivo menos gil
Lo importante es saber determinar el tipo de proceso y herramientas
que mejor sirvan a cada proyecto y organizacin