Ingeniera de Software

Clase 3:
Metodologas giles
Hugo R. Cordero S.

Clase 1

Objetivos
2

Conocer las metodologas giles y su diferencia con los

mtodos tradicionales
Comprender el concepto de Historias de Usuario y su
formulacin para los proyectos giles
Entender SCRUM y su aplicacin en los proyectos de
desarrollo
Programacin Extrema XP

Temas
3

Metodologas giles
Desarrollo dirigido por un plan vs. desarrollo gil
Administracin de un proyecto gil
Historias de Usuario
SCRUM
Programacin Extrema XP

Metodologas giles
4

Antecedentes
La definicin moderna del desarrollo gil de software
evolucion a mediados de los 90s. como parte de una
reaccin contra los mtodos de peso pesado, muy
estructurados y estrictos, extrados del modelo de desarrollo
en cascada.
El proceso originado del uso del modelo en cascada era
visto como burocrtico, lento e inconsistente con las formas
de desarrollo de software que realmente realizaban un
trabajo eficiente

Metodologas giles
5

Antecedentes
RAD o Rapid Application Development tiende a englobar
tambin la usabilidad, utilidad y la rapidez de ejecucin
Entorno de desarrollo altamente productivo (con prototipos
y herramientas CASE)
Grupos pequeos de programadores
Herramientas
que generaban cdigo tomando como
entradas sintaxis de alto nivel

Metodologas giles
6

Antecedentes
En el 2001, tras una reunin celebrada en Utah, EE.UU. Por
17 crticos de los modelos de desarrollo basado en procesos
nace formalmente el trmino gil aplicado al desarrollo
Los integrantes de la reunin resumieron los principios sobre
los que se basan los mtodos alternativos en cuatro
postulados, lo que ha quedado denominado como
Manifiesto gil

Valores de las metodologas giles

7

Segn el manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo
sobre el proceso y las herramientas
Desarrollar software que funciona ms que conseguir una
buena documentacin
La colaboracin con el cliente ms que la negociacin de un
contrato
Responder a los cambios ms que seguir estrictamente un
plan

Principios de las metodologas giles

8

1. Nuestra prioridad principal es satisfacer al cliente a travs

de entregas de software valioso, de forma temprana y

continua
2. Los cambios a los requisitos son bienvenidos, aun as sean
tardos. Los procesos giles aprovechan el cambio para
otorgar una ventaja competitiva al cliente.
3. Entregar software operativo frecuentemente, en un
perodo entre dos semanas y dos meses, con preferencia a
escalas de tiempo ms cortos.

Principios de las metodologas giles

9

4. Las personas del negocio y los desarrolladores deben

trabajar juntos diariamente a lo largo de todo el

proyecto.
5. Ejecutar proyectos con personas motivadas. Brindar el
ambiente y soporte que ellos necesitan, y la confianza de
que ellos podrn realizar el trabajo requerido.
6. El mtodo ms eficiente y efectivo para transmitir la
informacin hacia el equipo son las conversaciones cara a
cara.

Principios de las metodologas giles

10

7. El software operativo es la principal medicin del avance.

8. Los procesos giles promueven el desarrollo sostenible. Los

patrocinadores, desarrolladores y usuarios deben ser

capaces de mantener el paso constante indefinidamente.
9. Una continua atencin hacia un buen diseo y la
excelencia tcnica mejora la agilidad.
10. a simplicidad como el arte de maximizar la cantidad de
trabajo que no se hace, es esencial.

Principios de las metodologas giles

11

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

los equipos organizados por s mismos.

12. En intervalos regulares, el equipo reflexiona respecto a
cmo trabaja de forma ms efectiva, entonces afina y
ajusta su comportamiento adecuadamente

Qu es una metodologa gil?

12

Agilidad

Capacidad para adaptar el curso del desarrollo a la evolucin de

los requisitos y a las circunstancias del entorno.

La agilidad y el costo del cambio

Los costos aumentan con rapidez y no son pocos el tiempo y el

dinero requeridos para asegurar que se haga el cambio sin efectos
colaterales no intencionados

Qu es una metodologa gil?

13

Consiste en desarrollar una pequea parte del software

que se desea construir. De esta forma, el cliente nos indica si
vamos por el buen camino, estableciendo aquellas partes
que le son ms relevantes y as juntos, nos aseguramos de
que construimos una aplicacin que aadir valor a su
negocio
Minimiza riesgos desarrollando software en cortos lapsos de
tiempo

Qu es una metodologa gil?

14

Las metodologas giles de desarrollo estn especialmente

indicadas en proyectos con requisitos poco definidos o
cambiantes
Capacidad de respuesta a cambios de requisitos a lo largo
del desarrollo
Entrega continua y en plazos breves de software funcional

15

Las metodologas giles y la

documentacin

Aunque el manifiesto gil no rechaza el que se documente

en los proyectos, s antepone otras muchas cosas frente a
documentar, y muchos proyectos han interpretado esto como
que en un proyecto gil no se debe escribir ningn
documento.
Esto es un error y muchos proyectos con los aos han sufrido
mucho este problema, e incluso se han visto imposibilitados
a la hora de cambiar de proveedor de desarrollo software.
Documentar de manera gil, pero documentar.

16

Desarrollo dirigido por un plan vs.

Desarrollo gil

Desarrollo basado en un Plan

Desarrollo gil

17

Desarrollo dirigido por un plan vs.

Desarrollo gil

Est bastante aceptado y documentado, que el desarrollo

gil es ms idneo en proyectos con cambios considerables
La realidad en las empresas parece que refleja posturas
ms moderadas, hbridas y orientadas por la necesidad,
negocio y mejor prctica para cada organizacin
Existen dos tipos de organizaciones: las flexibles (poco
jerrquicas, poco burocrticas, etc.) y las rgidas todo lo
contrario, siendo una de las principales razones para no
migrar de mtodos formales a giles la cultura rgida de
la organizacin.

18

Desarrollo dirigido por un plan vs.

Desarrollo gil
Segn el tipo de organizacin y el tipo de proyecto
Los
mtodos formales son ms apropiados para
organizaciones rgidas con proyectos estables
Los mtodos giles son ms apropiados en organizaciones
flexibles con proyectos cambiantes
Los mtodos iterativos-formales son ms apropiados para
organizaciones rgidas con proyectos cambiantes, y
Los mtodos giles optimizados o con algo de diseo
upfront son ms apropiados en organizaciones flexibles
con proyectos estables

19

Desarrollo dirigido por un plan vs.

Desarrollo gil
En recomendado un proceso gil cuando:
Requiere entregas pequeas de software, con ciclos rpidos.
Puede ser cooperativo. Cliente y desarrolladores pueden
trabajan juntos constantemente con una cercana
comunicacin.
Es sencillo. El mtodo en s mismo es simple, fcil de
aprender y modificar.
Se necesita que sea adaptable. Permite realizar cambios
de ltimo momento.

20

Desarrollo dirigido por un plan vs.

Desarrollo gil
No es recomendado un proceso gil en:
Aplicaciones
distribuidas. Las pruebas unitarias son
complicadas de aplicar entre componentes. Sera necesario
construir una arquitectura de pruebas para probar
directamente los componentes
Aplicaciones que requieren seguir un diseo estricto. Por
ejemplo: sistemas operativos, software de telecomunicaciones.
Aplicaciones que requieren una documentacin exhaustiva. Por
ejemplo: sistemas militares, mdicos o industriales.

21

Desarrollo dirigido por un plan vs.

Desarrollo gil
No es recomendado un proceso gil en:
Proyectos muy grandes. La comunicacin entre los miembros
del equipo es difcil de conseguir.
Proyectos escritos en lenguajes no orientados a objetos.
Lenguajes como C, Pascal, Cobol o Fortran hacen imposible
tcnicas como la refactorizacin.

22

Desarrollo dirigido por un plan vs.

Desarrollo gil
Tabla comparativa

Administracin de un proyecto gil

23

nfasis en clientes y productos

Valor para los clientes a travs de productos innovadores,
nfasis en:

Entregar valor a los clientes

Emplear entregas iterativas y basadas en caractersticas funcionales
Promover la excelencia tcnica

Los procesos confiables se enfocan en las salidas, no en las

entradas
Los procesos confiables permiten producir productos
orientados a satisfacer necesidades de los clientes

Administracin de un proyecto gil

24

Liderazgo colaborativo
Los equipos son responsables de su rendimiento, de que
resultados alcanzan y del uso de slidos principios de
ingeniera
Los reportes peridicos, o ms bien las entregas continuas
de funcionalidad incremental, ayudan a la comunidad del
proyecto a determinar que adaptaciones realizar
No renuncia al control, s valora la responsabilidad y revisa
la definicin de qu controlar

Administracin de un proyecto gil

25

Marco de trabajo auto-organizado

Implica conseguir la gente correcta
Articular la visin del producto, sus lmites y los roles en el
proyecto
Promover la interaccin y flujo de informacin entre equipos
Facilitar la toma de decisin participativa
Insistir en la responsabilidad

26

Ventajas de las metodologas

giles

Rpida respuesta a cambios de requisitos a lo largo del

desarrollo.
Entrega continua y en plazos cortos de software funcional.
Trabajo conjunto entre el cliente y el equipo de desarrollo.
Minimiza los costos frente a cambios.
Mejora continua de los procesos y el equipo de desarrollo.
Evita malentendidos de requerimientos entre el cliente y el
equipo.
Cada componente del producto final ha sido probado y
satisface los requerimientos.

Metodologas giles
27

Programacin Extrema (XP)

SCRUM
Crystal
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)
Lean Development (LD)

Historias de Usuario
28

Es la tcnica utilizada para especificar los requisitos del

software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las caractersticas que el sistema debe
poseer, sean funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinmico y
flexible. Cada historia de usuario debe ser lo suficientemente
comprensible y delimitada.
Se puede definir como el recordatorio de una conversacin
con el cliente.

Historias de Usuario
29

Para efectos de planificacin, las historias pueden ser de una

a tres semanas de tiempo de programacin
Las historias de usuario son descompuestas en tareas de
programacin y asignadas a los programadores para ser
implementadas durante una iteracin.
Existen varias plantillas sugeridas pero no existe un consenso
al respecto. En muchos casos slo se propone utilizar un
nombre y una descripcin o slo una descripcin, ms quizs
una estimacin de esfuerzo en das.

Historias de Usuario
30

Estructura bsica de una historia de usuario

Historias de Usuario
31

Debe haber al menos una historia por cada caracterstica

importante, y se sugiere realizar una o dos historias por
programador por mes.
Si se tienen menos, probablemente sea conveniente dividir
las historias, si se tienen ms lo mejor es disminuir el detalle
y agruparlas.
Regla bsica para escribir una historia de usuario:

Historias de Usuario
32

Al comienzo de cada iteracin estarn registrados los

cambios en las historias de usuario y segn eso se
planificar la siguiente iteracin
Un cuadro resumen de historias de usuario sera

Historias de Usuario
33

Formato de historia de usuario en la documentacin

Historias de Usuario
34

Principio INVEST
Independiente

Negociable

La historia de usuario no debe depender de otra historia ya que

esto facilitar la priorizacin de las mismas. Si por alguna razn la
historia de usuario es dependiente se recomienda fusionarlas
La historia de usuario puede cambiar y evolucionar a lo largo de la
ejecucin del proyecto, incluso podra dejar de tenerse en cuenta si
as el cliente lo desea

Valiosa

La historia de usuario debe brindar valor al proyecto y al usuario

final.

Historias de Usuario
35

Principio INVEST
Estimable

Pequea (Small)

La historia de usuario debe tener el tiempo que sta tomar en

implementarse
La historia de usuario debe ser pequea y concisa. Si una historia
de usuario es muy grande sta se debe dividir en otras historias
ms pequeas, esto con el fin de poder tener un mejor control sobre
ellas.

Testeable

La historia de usuario debe poderse probar en un proceso de

calidad

SCRUM
36

Desarrollada por Ken Schwaber, Jeff Sutherland y Mike

Beedle. Define un marco para la gestin de proyectos, que
se ha utilizado con xito durante los ltimos 10 aos.
Est especialmente indicada para proyectos con un rpido
cambio de requisitos.
La palabra scrum procede del rugby, donde designa al
acto de preparar el avance del equipo en unidad para
ganar el baln.

SCRUM
37

Es una metodologa gil que define un marco de trabajo para

la gestin y desarrollo de software basada en un proceso
iterativo e incremental.
Sus principales caractersticas se pueden resumir en dos:

Se basa en iteraciones, denominadas Sprints, con una duracin de

no ms de 30 das. El resultado de cada Sprint es un incremento
ejecutable que se muestra al cliente.
La segunda caracterstica importante son las reuniones a lo largo
del proyecto. Una reunin diaria de 15 minutos del equipo de
desarrollo para coordinacin e integracin.

SCRUM - Marco de trabajo

38

SCRUM - Roles
39

Product Owner

Es el responsable oficial del proyecto, gestin, control y visibilidad

de la lista de acumulacin o lista de retraso del producto. Toma las
decisiones finales de las tareas asignadas al registro. Representa la
voz del cliente

Scrum Mster o facilitador

Responsable del proceso Scrum, de cumplir la meta y resolver los

problemas. As como tambin de asegurarse que el proyecto se
lleve a cabo de acuerdo con las prcticas, valores y reglas de
Scrum y que progrese segn lo previsto

SCRUM - Roles
40

Team

Responsable de transformar las historias de usuario de la iteracin

en un incremento de la funcionalidad del software
El equipo tiene la responsabilidad de entregar el producto.
Generalmente son equipos de 3 a 9 personas con las habilidades
transversales necesarias para realizar el trabajo.

Customer

Se refiere a las personas que hacen posible

el proyecto y para quienes el proyecto
producir un beneficio acordado. Participa
directamente durante las pruebas del Sprint.

SCRUM - Elementos
41

Product Backlog

Son los requerimientos priorizados y revisados llamados tambin la

pila de producto. Este es una forma de registrar y organizar el
trabajo pendiente para el producto (actividades y requerimientos)

Sprint

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

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

SCRUM - Elementos
42

Sprint Backlog

Lista de tareas determinadas por el equipo para realizar en un

Sprint. Se determinan durante el planeamiento del Sprint.
Se realiza la estimacin y se actualiza da a da.

SCRUM - Elementos
43

Scrum diario

Se asume que el proceso es complejo y que es necesario

inspeccionarlo frecuentemente, por eso se realiza una reunin diaria
de seguimiento
Se actualiza el Sprint Backlog con la nueva informacin.

Burn down chart

Es una grfica mostrada pblicamente que mide la cantidad de

requisitos en el Backlog del proyecto pendientes al comienzo de
cada Sprint. Dibujando una lnea que
conecte los puntos de todos los Sprints
completados, podremos ver el progreso
del proyecto.

SCRUM - Sprint
44

Es el perodo en el cual se lleva

a cabo el trabajo en s.
Al inicio se lleva a cabo la
reunin de planificacin del
sprint, en donde se selecciona
que trabajo se har
Al final de cada sprint, el equipo
deber presentar los avances
logrados y el resultado obtenido
es un producto potencialmente
entregable al cliente.

SCRUM Sprint
45

Es recomendado que la duracin de los sprints sea constante y

definida por el equipo con base en su propia experiencia.
Asimismo se recomienda no agregar objetivos al sprint o sprint
backlog a menos que la falta de estos objetivos amenace al
xito del proyecto. La constancia permite la concentracin y
mejora la productividad del equipo de trabajo

SCRUM
46

En resumen:

SCRUM Sntomas de desviacin

47

Prdida del ritmo. Sntoma: Los sprint no duran siempre lo

mismo.
El Scrum Master asigna el trabajo. Sntoma: El trabajo es
principalmente asignado por el Scrum Master sin tener en
cuenta al equipo.
Las reuniones diarias son para el Scrum Master. Sntoma: Las
reuniones diarias sirven solo para poner al corriente al
Scrum Master.

XP eXtreme Programming
48

Es una metodologa gil centrada en potenciar las relaciones

interpersonales como clave para el xito en desarrollo de
software, promoviendo el trabajo en equipo, preocupndose
por el aprendizaje de los desarrolladores, y propiciando un
mejor clima de trabajo.
El objetivo principal de XP es entregar un software de calidad
controlado por las necesidades del cliente.
XP se basa en retroalimentacin continua entre el cliente y el
equipo de desarrollo, comunicacin fluida entre todos los
participantes, simplicidad en las soluciones implementadas y
valor para enfrentar los cambios

XP eXtreme Programming
49

Proceso
El cliente define el valor de negocio a implementar
El programador estima el esfuerzo necesario para su
implementacin
El cliente selecciona qu construir, de acuerdo con sus
prioridades y las restricciones de tiempo
El programador construye ese valor de negocio.
Vuelve al paso inicial.

XP eXtreme Programming
50

Proceso
Es un proceso iterativo

Roles XP
51

Cliente

Encargado de pruebas (Tester)

Escribe las historias de usuario y las pruebas funcionales para validar su

implementacin. Adems, asigna la prioridad a las historias de usuario y
decide cules se implementan en cada iteracin centrndose en aportar
mayor valor al negocio.
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas
regularmente, difunde los resultados en el equipo y es responsable de las
herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker)

Proporciona retroalimentacin al equipo. Verifica el grado de acierto

entre las estimaciones realizadas y el tiempo real dedicado, para mejorar
futuras estimaciones. Realiza el seguimiento del progreso de cada
iteracin.

Roles XP
52

Programador

Entrenador (Coach)

Es responsable del proceso global. Debe proveer guas al equipo de forma

que se apliquen las prcticas XP y se siga el proceso correctamente

Consultor

Escribe las pruebas unitarias y produce el cdigo del sistema

Es un miembro externo del equipo con un conocimiento especfico en algn

tema necesario para el proyecto, en el que puedan surgir problemas

Gestor (Big boss)

Es el vnculo entre clientes y programadores, ayuda a que el equipo

trabaje efectivamente creando las condiciones adecuadas. Su labor
esencial es de coordinacin.

Principios XP
53

Principios XP
54

Entregas pequeas

Diseo simple

Producir rpidamente versiones del sistema que sean operativas, aunque

no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye
un resultado de valor para el negocio. Una entrega no debera tardar ms
3 meses

Se debe disear la solucin ms simple que pueda funcionar y ser

implementada en un momento determinado del proyecto

Pruebas

La produccin de cdigo est dirigida por las pruebas unitarias. stas son
establecidas por el cliente antes de escribirse el cdigo y son ejecutadas
constantemente ante cada modificacin del sistema

Principios XP
55

Integracin continua

Cliente in-situ

El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ste
es uno de los principales factores de xito del proyecto XP.

Estndares de programacin

Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el
sistema puede llegar a ser integrado y construido varias veces en un mismo da

Enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo

cual es indispensable que se sigan ciertos estndares de programacin para
mantener el cdigo legible.

Refactorizacin (Refactoring)

Es una actividad constante de reestructuracin del cdigo con el objetivo de

remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms
flexible

Programacin de pares
56

Toda la produccin de cdigo debe realizarse con trabajo en

parejas de programadores
En la programacin de pares, una persona est programando
y la otra est pensando por adelantado, anticipando
problemas y ocupndose de la estrategia
El mejor modo para programar en pareja es que ambas
personas se sienten una al lado de la otra enfrente al monitor
de una estacin de trabajo
La persona que est manejando el teclado piensa de un modo
tctico, mientras que el acompaante lo
hace de un modo estratgico y global.

Programacin de pares
57

Como toda tcnica, se recomienda la implantacin de la

prctica de forma gradual, ya que pueden existir miembros
del equipo de desarrollo que se rehsen a emparejarse.
Entre las ventajas estn:

Reduce la cantidad de defectos

Mejora la calidad del diseo
Comparte el conocimiento en el equipo
Apoya la auto-disciplina
Disminuye las distracciones

Herramientas XP
58

Historias de usuarios

Casos de prueba de aceptacin

Son tarjetas que se elaboran para realizar las pruebas de cada

historia de usuario

Tarea de ingeniera

Son tarjetas fsicas en las cuales se anota una descripcin de una

funcionalidad del sistema, en una oracin.

Son tarjetas que se elaboran para ayudar y simplificar la

programacin de una historia de usuario.

Tarjetas CRC

Describen las clases utilizadas en la programacin de una historia.

Resumen
59

Las metodologas giles ofrecen una solucin casi a

medida para una gran cantidad de proyectos
Las metodologas giles se caracterizan por su sencillez,
tanto en su aprendizaje como en su aplicacin; sin
embargo, gozan tanto de ventajas como de
inconvenientes
Las metodologas giles permiten a los pequeos grupos
de desarrollo concentrarse en la tarea de construir
software fomentando prcticas de fcil adopcin y en un
entorno ordenado que permiten que los proyectos
finalicen exitosamente
A pesar de las crticas que sufren, son usadas por muchas
grandes empresas y se han utilizando en grandes
sistemas, lo que hace prever que estas metodologas han
llegado para quedarse

Preguntas?
60

Cundo es recomendable usar una

metodologa gil?

Referencias
61

Ingeniera de Software: Un enfoque prctico (7ma edicin) Roger S.

Pressman

Ingeniera de Software. Un enfoque desde la gua SWEBOK (1ra. edic.)

Salvador Snchez, Miguel ngel Sicilia, Daniel Rodrguez

Captulo 2: Modelos y procesos

Ingeniera del Software (9na edicin) Ian Sommerville

Captulo 3: Desarrollo gil

Captulo 3: Desarrollo gil de software

Links:

http://www.slideshare.net/profetiacademico/metodologias-agiles-9395911

http://www.comunidadesmicrosoft.org/blogs/angel-karl/los-12-principiosde-las-metodolog-giles

https://www.scrum.org/resources/what-is-scrum/

http://scrummethodology.com/