Inicio arrow Blog arrow Ágiles Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Modelos ágiles de desarrollo
  • A los individuos y su interacción por encima de los procesos y las herramientas

  • El software que funciona, por encima de la documentación exhaustiva.

  • La colaboración con el cliente, por encima de la negociación contractual.

  • La respuesta al cambio, por encima del seguimiento de un plan.

Manifiesto Ágil




Complicagilidad
20.05.2012

 

 

Este artículo está publicado en el nuevo dominio de Navegápolis (.com)

Ésta es su nueva dirección

 
6 lecciones para gestionar Scrum con equipos dispersos
08.01.2012

DistribuidoEnseñar competencias clave para desarrollar proyectos TIC en un mercado global, con equipos dispersados en distintos países, es el objetivo del proyecto GSD de la Univerisidad de Pace de Nueva York.

Cada año pone en marcha, en colaboración con otras universidades (Tailandia, India, Camboya, Senegal...) el desarrollo de un proyecto de software con equipos distribuidos.

Son proyectos que sirven de aprendizaje para los estudiantes y profesionales que participan, y de material de análisis con el que están construyendo y depurando un fondo de conocimiento específico para desarrollo global de software.

En 2009 decidieron por primera vez emplear un marco ágil (Scrum) para gestionar el desarrollo de una aplicación para dispositivos móviles, con equipos separados  (Universidad de Pace - Universidad de Delhi y Escuela Superior Politécnica de Dakar).

 

 Mapa

El mes pasado de publicó el informe del proyecto: "Some Management Principles Learned from Scrum Practices within a Global Software Development Project " que incluye las

6 lecciones aprendidas para la gestión de Scrum distribuido:

Lección 1: Se empieza con mucha voluntad...

Pero es dífícil mantener la motivación y el compromiso con los rituales ágiles previstos.
Sugerencia de gestión: Escribir las motivaciones y compromisos individuales para tenerlos presentes y visibles como banderas a lo largo del proyecto.

Lección 2: No caer en el principio de pareto

Trabajar por separado acentúa la tendencia a enfatizar y consumir mucho esfuerzo en tareas de preparación, aplicando esfuerzo ineficiente (80% de esfuerzo en un 20% del resultado).
Sugerencia de gestión: Conocimiento previo de los conceptos de Scrum, y aplicar pautas y artefactos de gestión simples.

Lección 3: Asignatura difícil: Gestión individual del tiempo

El trabajo distribuido reduce la visibilidad de problemas en miembros del equipo por una mala autogestión del tiempo. Los miembros de equipos separados deben conocer y aplicar de forma disciplinada los principios para la buena gestión del tiempo. Las prácticas de Scrum  para priorizar y estimar las tareas y seguir su evolución de forma cercana y con compromiso de equipo, son especialmente útiles, pero más difíciles de poner en práctica entre personas geográficamente dispersas.
Prácticas aconsejadas:
1.- Periodo de práctica y aprendizaje previo para poner a prueba las habilidades de gestión del tiempo, realizando prácticas de estimación y ejecución de tareas.
2.- Asesoramiento en el análisis y priorización de las tareas pendientes.
3.- Mostrar a los "perfeccionistas" que la perfección es imposible e innecesaria.
4.- Recordar que el tiempo es un recurso valioso.

Lección 4: Ser impasible... ¡mantener un ritmo de trabajo constante!

No olvidar el principio ágil de mantener una velocidad equilibrada, sin fluctuaciones. Sin momentos de estres que queman y desmotivan, ni periodos de procrastinación.

Lección 5: El fin justifica los medios.

El foco del trabajo no es la eficacia o la estética de la codificación. Son puntos técnicos que no deben consumir más foco que el necesario para garantizar el objetivo real: entregar una aplicación operativa.

Lección 6: La capacidad del barril depende de su tabla más corta.

Cada miembro tiene sus debilidades, o tablas más cortas, y sus fortalezas, o tablas largas. La organización del equipo debe conseguir la distribución del trabajo y el resultado combinando y sumando las fortalezas, no las debilidades.


Otros informes del proyecto GSD.

GSD 2007 GSD 2008 GSD 2009 GSD 2010


 
¿Agilidad basada en metodologías?
23.10.2011

metodologíasPasar de desarrollo secuencial y planificación global con requisitos cerrados, a un marco iterativo e incremental con requisitos abiertos no es agilidad. Agilidad también supone preferir la pericia y el criterio de las personas al conocimiento estuchado en los procesos y la tecnología.

 

Ingeniería concurrente

Trabajar sin procesos ni gestión predictiva, pero sin conocer tampoco ni principios ni prácticas prácticas ágiles tampoco es agilidad.

 
Piezas de un Campo de Scrum
09.10.2011

PiezasSi falta alguna de estas piezas el ecosistema para un Campo de Scrum estará cojo. Cuando más evidente es más rozamiento produce, e incluso lo puede hacer inviable.

 

 

Piezas de un Campo de Scrum

 

 
Scrum como patrón pedagógico para el aprendizaje basado en proyectos
01.10.2011

formaciónNo es fácil trabajar en un marco de Scrum con un equipo distribuido y es precisamente el tema que analiza Sergio Yazyi en su trabajo de Fin de Master en las TIC en Educación de la Universidad de Salamanca "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido ".

El trabajo emplea para su análisis el taller de Open Knowledge Scrum de Scrum Manager en el que participó el año pasado, que fué dirigido por Claudia Ruata.

El documento compone una visión general y análisis, objetivo y riguroso tanto del aprendizaje basado en proyectos como de los retos del trabajo con equipos distribuidos.

"El aprendizaje basado en proyectos se presenta en varias disciplinas como una estrategia pedagógica óptima para ejercitar conocimientos a la vez que desarrollar habilidades, afrontando situaciones similares a las del mundo real no sólo en términos individuales sino también en la acción coordinada, al mismo tiempo que ofrece un escenario para facilitar la incorporación transparente de la tecnología dentro del proceso de trabajo, por sus virtudes para alcanzar el logro de los objetivos."

"En contextos donde los requisitos son estables, esto ha funcionado bien. Sin embargo, con la aceleración en el ritmo de evolución tecnológica de las últimas décadas, la aplicación de este enfoque en escenarios donde los cambios frecuentes no sólo son inevitables sino incluso deseables, y donde la capacidad de predecir el resultado y el momento es menos importante que garantizar la producción de valor genuino en el
proceso, el modelo tradicional en cascada, predictivo, se ha revelado insuficiente. En particular, en la industria del software se ha vuelto evidente que cuando las definiciones de los requisitos son más dinámicas, inciertas o inestables, este modo de desarrollar produce sistemáticamente  retrasos, altos costos para los proyectos e insatisfacción en el cliente
"

Entre las conclusiones del trabajo una particularmente interesante, que apunta una nueva dimensión de Scrum: en la formación.

"Se podría incluso considerar Scrum dentro del aprendizaje basado en proyectos como un verdadero patrón pedagógico, que sintetiza en un conjunto de reglas simples, los principios y buenas prácticas para permitir a un grupo de trabajo transformarse en un verdadero equipo de alto rendimiento, en contextos de incertidumbre e interdisciplinariedad."

... continúa en: "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido" 




 
Scrum es lo fácil... ¿o no?
18.09.2011

escultorLa agilidad es lo fácil y la ingeniería de procesos (ISO 12207, ISO 15504, CMMI...) lo difícil.

El marco de trabajo Scrum se explica en media docena de páginas y para conocer las veintitantas áreas de procesos, objetivos y prácticas, específicas y genéricas de un modelo como CMMI,  hacen falta cientos.

Hace unos años, cuando CMMI hablaba sin miedo a perder mercado por la competencia de la agilidad, una implantación para un nivel 2 de madurez, entre pitos y flautas se te iba a más de un año de trabajo y bastantes miles de euros en formación al grupo de evaluación y en minutas de expertos consultores encorbatados. Aparecieron entonces unos chicos que tras años intentando hacer software con esos procesos los habían mandado a la porra, y descubierto otras formas que funcionaban mejor; y tras ellos otros que andaban buscando en qué podían decir que eran expertos, y esto parecía fácil.

Así que teniamos lo difícil y caro: CMMI y lo fácil y barato: Agilidad.... ¿o no?

CMMI es complejo, pero no es difícil. La Agilidad es simple, pero no es fácil.

Para tornear figuras con un torno de control numérico hay que conocer y aplicar sin cambiar una coma el manual de operación, y al final las piezas salen perfectas. Puede ser complejo, pero no difícil. Quien lo hace es un operador.

Podría parecer que es más fácil tallarlas porque sólo hace falta un martillo y un cincel, y además asesorar de cuáles son los mejores martillos, y cinceles. Los mejores materiales, técnicas para coger el cincel... y es que cuando se trata de agilidad y confias el resultado no a los procesos y la tecnología, sino a las personas, como dice mi amigo Luis, la cuestión no son las flechas, sino los indios ;-)

 
No me gusta Scrum porque no es capaz de estimar la duración total de un proyecto
31.07.2011

desconfiandoEste es el comentario reciente de una empresa argentina a su proveedor de software, y con el que hace un rato comentaba lo que se le podía responder.
Como este prejuicio es bastante frecuente, comparto en abierto lo que le hubiera dicho, por si os puede interesar como un argumento más para el inventario personal, o como opinión con la que contrastar, los que penséis lo mismo.

Se me ocurre que la cuestión principal, el comentario: "No me gusta Scrum poruqe estas metodologías no permiten estimar la duración total de un proyecto" no es cierta.
Lo cierto es que "estas metodologías" permiten que el plan del proyecto se enriquezca (o no, según quiera el cliente) a cada paso que se va construyendo, porque con ellas no va a estar a ciegas desde el día que lo encarga hasta el día que lo recibe.
El cliente lo va a ir viendo crecer (lo tiene que ir viendo crecer) y puede introducir modificaciones: "Lo que era así mejor hacerlo asá..."

"Estas metodologías" cambian el concepto de proyecto rígido y de construcción opaca para el cliente, de: "esto es lo que hay que hacer y no se cambia nada hasta que esté todo hecho, y lo verá hecho cuando lo terminemos y se lo entreguemos" a proyecto transparente y flexible: va a verlo crecer paso a paso y si al hacerlo descubre algo que sería mejor de otra forma, o algo en lo que no cayó en la cuenta de que le hacía falta, lo puede cambiar y lo tendrá en el siguiente paso.

Por eso no es cierto que no sea posible planificar el proyecto. "Estas metodologías" permiten hacerlo (ver gráfico burn-up como plan de proyecto). Le permiten además que ese plan de proyecto, en forma de pila de producto no sea rígido y pueda alterarlo durante el desarrollo.
No es cierto por tanto que "estas metodologías" no sean capaces de planificar, lo que no son capaces es de adivinar lo que usted cambiará :-)

 

 
Idea: "állbum kanban" como artefacto de registro ágil
13.07.2011

archivoHace ya algún tiempo empecé a no tirar a la papelera las etiquetas con las historias de usuario que retirábamos de la pizarra al cerrar cada sprint.

Todo empezó el día que al limpiar la pizarra tenía en la mano una carpeta de las que empleamos para encartar folletos de publicidad. Son de cartón grueso y de acabado satinado... y surgió de forma instintiva. Fui pegando dentro las etiquetas adhesivas que quitaba de la pizarra.


carpetas

 

Cuando volví al despacho, la cerré... me la quedé mirando y le puse en la solapa derecha una etiqueta con el número dle sprint, la fecha de cierre del sprint y la de despliegue en producción de las historias programadas. la dejé en la estantería.... Mmmm... que interesante.

Acababa de archivar la información de un sprint.

De una forma algo burda diría alguno (me consta que en el equipo hay quien preferiría algo más "tech", y me mira raro porque esto le resulta un poco vergonzante :-)

Bueno. Va como idea. A mi más que burdo me parece simple, y suficiente. ¿Cuántas veces voy a necesitar consultar esta información? y sólo "por si acaso alguna vez", y por las características de seguimiento admisnistrativo que le aplico a este proyecto... no me merece la pena invertir en esta burocracia más de 1 minuto. Por eso lo encuentro  completamente "lean", y os la comento por si a alguno os puede servir directamente o como idea base para hacer algo mejor.

A la vista de que ya el número de carpetas va creciendo se me ocurria que sería posible un "artefacto" como el de la foto para tener un sistema de registro "ágil". ¿Tendría sentido algo así?. (La foto es sólo un prototipo).

 Prototipo album kanban

En casi todas las oficinas hay una encuadernadora. Encuadernando páginas de gramaje algo recio, y mejor si es satinado, se puede tener algo así como un "álbum kanban", un sistema ágil para registrar la información.

Las páginas de este "álbum de sprints" pueden llevar impresa la cabecera que a cada equipo le encaje mejor con su forma de trabajar para anotar: "Nº de sprint", "fecha", "velocidad",  "Versión", "Valor"... etc (para gustos colores y para riñas... talibanismos) :-)

 

 
Proyectos ágiles para la Administración Pública: una de cal y otra de arena
03.07.2011

exito_fracasoencuesta La de arena

las afirmaciones de Alistarir Maughan (Asesor jurídico para la Administración Pública británica de Morrison Foerster):

Estoy dispuesto a aceptar que si todo va bien la agilidad puede reducir el riesgo de fracaso del proyecto. Pero la agilidad simplemente no funciona en el mundo real de proyectos TIC para la Administración. Necesitamos un Richard Dawkins para reventar el mito del evangelio ágil.

Hay razones claras por las que la agilidad no puede funcionar en la contratación con la Administración:

- En el marco ágil se paga por un esfuerzo, pero no por un resultado concreto. Esto no puede funcionar en la Administración.
- Los departamentos se gestionan con presupuestos aprobados y cerrados para obtener resultados concretos.
- La Administración está obligada por ley a seguir reglas de contratación abierta, lo que significa comparar diferentes licitadores sobre una base de igual a igual y decidir la mejor relación calidad-precio. La agilidad no da por adelanteado ni una descripción detallada del resultado, ni un precio cerrado. ¿Cómo cumplir con el requisito legal de que los contratos públicos son justos y abiertos?.
- La administración opera con un modelo de toma de decisiones centralizado hacia arriba, mientras que la agilildad se basa en la autonomía y la delegación de decisiones hacia abajo. Esta es la clave para que pequeños equipos descentralizados puedan reaccionar con rapidez y adaptarse a nuevos escenarios.

Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas.

La de cal

El departamento de trabajo y pensiones brítánico (DWP) ha modificado los contratos que rigen el suministro  del sistema de crédito universal, por dos mil millones de libras añadiendo cláusulas para alentar a los proveedores a usar metodologías ágiles en su desarrollo.
Estas modificaciones intentan asegurar que los proveedores abandonan los métodos convencionales de desarrollo de sistemas, acusados del fracaso de los grandes proyectos TIC.

Las cláusulas incentivan a los integradores de grandes sistemas a adoptar metodologías ágiles con lo que el DWP espera garantizar el buen fin del proyecto en la fecha comprometida de 2013.

vía: ComputerWeekly.com

¿Cuál es tu opinión?

¿Estás de acuerdo con la afirmación de  Alistarir Maughan: "Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas."

Contratos ágiles
La agilidad se basa en la confianza, vale para contratos internos pero no externos.
 

 
 
Documento técnico sobre scrum con equipos distribuidos
21.06.2011

portadaEl documento "Scrum Distribuido" es el resultado del primer taller de investigación (beta) de Open Knowledge Scrum

El estudio ha estado dirigido por José Miguel Vera y Sergio Yazyi, en el que han colaborado como autores junto a  Raúl Herranz, Noel MamoghliEdgar González, Daniel Matulis, Victor Ratón, Miguel Salas, Salvador Arauzo, Felipe Muñoz y Luis Farias .

 El objetivo del documento es ofrrecer una primera información de las implicaciones de Scrum en un contexto distribuido. Para ello parte de las definiciones base, e identifica los retos más relevantes para un equipo distribuido, recopilandoy analizando la información para cada uno, con la propia experiencia profesional,  así como la del trabajo  realizado para la ejecución del estudio, que es precisamente el trabajo de un equipo distribuido.

  • Descarga de Scrum Distribuido.

 Safe Creative #1106149463894
 
Un equipo ágil necesita 3 sprints para aprender a estimar, pero es lo menos importante.
23.05.2011

 

Este artículo se encuenta ahora en esta página

 
¿Es suficiente un tablero kanban?
06.04.2011

tablero kanban A un equipo ágil le basta con un tablero kanban, pero a menudo se usa junto con alguna herramienta de seguimiento de tareas  por alguna de estas razones: Para elaborar informes, porque no trabaja todo el equipo en el mismo sitio, porque no trabajan en un entorno ágil, por razones administrativas o de documentación, por colaboración con otros equipos (scrum de scrums).

Esta es al menos la conclusión de la tesis de grado presentada el mes pasado por Mascha Kurpicz en la Universidad de Berna: Tool Support for Scrum en la que compara la utilidad y funcionalidaes entre herramientas de seguimiento de tareas y  tableros visuales)

 

Comparación entre Tableros Kanban y Herramientas de gestión

Issue Tracker vs Kanban Board

 


Issue Tracker vs. Kanban Board
 
 
 


Al final de la tesis Mascha Kurpickz propone un prototipo para sincronizar la imagen de un tablero kanban con una hoja de cálculo: Scrum Detector.

 
Excipientes y principios activos de la agilidad
16.03.2011

medicinasExcipientes de la agilidad

Tableros kanban, etiquetas adhesivas, reuniones de pie, gráficos burndown, estimación de póker, product backlog, sprint backlog, gráficos burnup, formatos de historias de usuario, etc.

Principios activos

  • Visión: El proyecto tiene un objetivo definido, conocido y asumido por todos los miembros.
  • Priorización: El criterio de prioridad del cliente define en cada momento los trabajos inmediatos para avanzar hacia el objetivo.
  • Visibilidad: No hay información oculta y en las decisiones se tienen en cuenta las consideraciones y aportaciones del todo el equipo.
  • Competencia: Todos los miembros tienen la competencia profesional necesaria para aportar un trabajo valioso.
  • Respeto: Todos los miembros dan y reciben respeto y valoración.
  • Compromiso: Las personas no anteponen sus intereses propios a los del equipo.
  • Confianza: Todo el equipo tiene confianza real en el desempeño, valor y compromiso de los demás.
  • Coraje: Todos los miembros y el equipo en su conjunto hace frente con decisión y solvencia a las situaciones adversas.
  • Responsabilidad: Cada persona tiene el margen de acutación y decisión necesario para su aportación al proyecto y es responsable de sus decisiones, acciones y omisiones.
  • Ritmo: El desarrollo se realiza con una cadencia de avance objetivo continuo y sostenible.
  • Retroalimentación: De forma periódica el equipo analiza su forma de trabajo y toma decisiones de mejora.


 
Retos culturales para equipos scrum distribuidos
07.03.2011

comunicación interculturalHay dos patrones culturales relativos a la comunicación entre individuos: de "bajo contexto" y de "alto contexto". En las culturas de alto contexto los mensajes dependen de variables del entorno  sin las cuales la comunicación pierde información relevante, porque en la cultura que comparten los interlocutores se interpretan de forma común. Por el contrario en las culturas de bajo contexto los mensajes explícitos incluyen la información significativa y objetiva para su correcta interpretación.

"Una comunicación o mensaje de alto contexto es aquel que supone gran parte de la información implícita en la persona, y se necesita muy poca información explícita en el mensaje verbal. Una comunicación de bajo contexto es justo lo contrario (Hall E.T., Beyond Culture 1989)

Culturas de alto contexto son, por ejemplo, la japonesa, china o coreana; mientras que en el extremo opuesto o de bajo contexto estarían la alemana, suiza o escandinava.

La comunicación en las culturas asiáticas es a menudo indirecta e implícita, e interpretan correctamente los mensajes porque comparten el mismo fondo cultural; sin embargo en las culturas occidentales la comunicación tiende a ser más directa y explícita. Las culturas de alto contexto prefieren los estilos indirectos, y pueden interpretar como conflictiva una comunicación muy directa.

Algo parecido sucede con la valoración del tiempo. Hay culturas (monocrónicas) que lo valoran de forma cuantificable y objetiva como si fuera dinero. Otras (policrónicas) lo entienden como un fluir continuo e interminable desde el pasado hacia el futuro. Estas últimas estructuran menos el tiempo y la planificación de las actividades, al revés de lo que suelen considerar correcto las culturas monocrónicas, que prefieren planificaciones y focos de trabajo definidos.

La impuntualidad, las interrupciones, la gestión simultánea de varias tareas, las pausas en las comunicaciones por correo, etc. se consideran de forma diferente en cada cultura.

Estos factores pueden suponer retos a la comunicación de equipos ágiles distribuidos y multiculturales, y como cada vez hay más organizaciones que combinan la operativa ágil, basada en la comunicación directa de las personas, con la deslocalización de equipos, me ha parecido curioso el informe de  Hasit D. Yaggahavita: "Challenges in Applying Scrum Methodology on Culturally Distributed Teams" donde analiza estas variables, desde su experiencia como ingeniero en una software factory en Sri Lanka (Eurocenter)

Retos equipos distribuidos

 

 

 
Los cambios de requisitos son bienvenidos con Scrum, pero ¿a qué precio?
16.02.2011

comparandoLa gestión de proyectos predictiva afirma que la forma más eficiente de hacer un trabajo es hacerlo bien a la primera. ¿Es más eficiente la gestión de proyectos predictiva que la gesitón de proyectos ágil?.

La ingeniería de software tradicional necesita requisitos detallados y estables.
Para la gestión de requisitos tradicional, (una de las cinco áreas de conocimiento de la ingeniería de requisitos según SWEBOK) cada modificación de requisitos es una "incidencia". Un torpedo contra el éxito del proyecto que requiere un estudio de impacto y medidas de reparación.

Sin embargo , los requisitos genéricos y los cambios durante el desarrollo son las premisas del desarrollo ágil, que afirma cosas como "Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente".

La clave de esta aparente contradicción está en los ciclos de vida empleados por unos y por otros: El desarrollo secuencial o en cascada necesita requisitos detallados y estables, algo que no sucede si se usan modelos iterativos.

requisitos: secuencial vs ágil
Requirements Management in an Agile-Scrum


Pero... todo tiene su precio. La agilidad se adapta al cambio y da más valor a la visión del producto, en cada modificación que va descubriendo mientras lo construye... pero claro, los cambios de requisitos repercuten en la eficiencia del equipo y en la calidad entregada.
 Porque es evidente que "La forma más eficiente de hacer un trabajo es hacerlo bien a la primera".
¿Sí?.
¿Alguien lo ha comprobado, o simplemente se da por supuesto porque parece obvio?.

Esto es lo que se plantearon los profesores de la Universidad de San Marcos en Texas Elizabeth Oyeyipo y Carl Mueller, y para comprobarlo han realizado un estudio con 33 alumnos de Ingeniería de Software, formando 8 equipos de 4 ó 5 programadores y cuyos resultados publica la Universidad en el reciente informe "Requirements Management in an Agile Scrum "

Los 8 equipos construyeron el mismo sistema con el mismo product backlog y trabajando con el mismo propietario de producto: un programa de gestión de agendas.

Siete equipos trabajaron con Scrum, admitiendo al propietario de producto realizar cambios en el backlog de requisitos durante la ejecución del proyecto.
Un equipo se empleó como referencia para contrastar los datos, de forma que usó un ciclo de desarrollo iterativo (4 iteraciones en lugar de los 4 sprints)  pero sin modificar los requisitos, para analizar las diferencias de eficiencia y calidad.
Las métricas empleadas en el estudio han sido 29, agrupadas en 4 categorías: Esfuerzo del equipo, Funcionalidad producida, Impacto de los cambios de requisitos y calidad entregada.


resultados esfuerzo
(El grupo I trabajaba con Scrum y el II no)

El estudio concluye que los grupos trabajando con Scrum permitiendo cambios en el backlog entregaron más calidad, más funcionalidades e invirtieron menos horas que los que trabajaron con iteraciones sin permitir cambios.

 
<< Inicio < Anterior 1 2 3 4 5 6 7 8 9 Siguiente > Fin >>

Resultados 1 - 15 de 128
Advertisement





Artículos relacionados

Registrado en Safe Creative