Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Eventos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Eventos. Mostrar todas las entradas

miércoles, febrero 16, 2022

Nuestro Scrum empírico de todos los días

Imagen tomada de Pixabay

“El verdadero método de conocimiento es el experimento”.

-          [William Blake. Poeta, pintor y grabador inglés.]

Muchos dicen usar Scrum, dicen usarlo bien. Según los “lineamientos” ágiles, los he escuchado decir. Pero he aquí una observación: la gran mayoría quizás ni lo están haciendo, a pesar de los eventos, las responsabilidades y los artefactos. En general a casi todos les hace falta lo que llamo “el espíritu de Scrum”. Ese que tiene que ver con la teoría del marco de trabajo, con sus pilares y con sus valores.

Me concentraré específicamente en la teoría. En esa que nos dice que Scrum se basa en el empirismo y en el pensamiento Lean. De hecho, mi foco será esto del empirismo. Para empezar, es bueno reconocer que un entorno empírico es aquel en el que la mejora y la dirección están guiadas por los experimentos y la experiencia.

Esta última se basa en lo que ya ha ocurrido, en el pasado. Muchos siguen usando Scrum tratando de predecir lo que va a pasar en el futuro, a veces incluso, en un futuro distante. Nada más alejado de las prácticas erróneas. Mi primera recomendación: usa la experiencia para experimentar con la planificación en el muy corto plazo, la planificación de un sprint; es más, con la planificación de un día de trabajo.

Para hacerlo, haz que tu equipo planifique teniendo en cuenta lo que pasó en el último sprint. Quizás en los tres últimos. Tampoco te vayas tan atrás. Seguramente hay cosas que han cambiado en el entorno. No es lo mismo si hace unas semanas tu equipo estaba disperso por el mundo y apenas si lograbas identificar un icono en una pantalla de alguna de las herramientas favoritas de comunicación, a si en este momento están trabajando con un modelo “híbrido” o presencial del todo. Mientras escribo esto, algunas empresas ya lo están intentando.

Promueve un entorno donde todos en el equipo y los interesados clave, además de los usuarios, esperen lo inesperado. Es lo que sucede cuando trabajas bajo el manto de la incertidumbre y la volatilidad inherentes a los escenarios que enfrentas habitualmente, sin hablar de la complejidad propia del ADN de las iniciativas con las que convives a diario. Es en estos escenarios donde un proceso empírico tiene vigor.

La realidad del Scrum que haces

Photo by Yan Krukov from Pexels
Todo el tiempo escuchas decir:

La mejor duración de sprint es de dos semanas. Pero ¿has experimentado con otra duración? ¿Una mejor, por ejemplo?

En nuestras Daily Scrum seguimos usando las “tres preguntas”. Nos parecen muy buenas. Sí, pero ¿has experimentado con otro tipo de conversaciones?

Nuestra definición de terminado es muy completa. Pero ¿la has mejorado con el tiempo?

En cada sprint implementamos entre 4 y 8 historias de usuario. Pero ¿has experimentado con otros rangos?

Nos funciona bien un equipo de 8 personas. Pero ¿has ensayado con otro tamaño de equipo?

Te haré otras preguntas:

¿Has dejado de usar la velocidad como medida de capacidad para el equipo?

¿Sigues usando puntos de historia para estimar las historias de usuario?

¿Has intentado con tu Product Owner alguna técnica distinta a MoSCoW para ordenar el Product Backlog? ¿Has usado MoSCoW?

¿En realidad todos en el equipo y en el entorno, es decir, interesados clave, patrocinadores y usuarios, entre otros, comparten no solo la misma información sobre lo que está sucediendo, sino el mismo significado de las cosas?

¿Has experimentado o has promovido cambios en la forma como hacen la planificación del sprint, el refinamiento, la revisión o la misma retrospectiva? Sobre esta última, ¿te limitas a los “pasos” generados por Retromat, Fun retrospectives o el muy buen libro sobre el tema de mi gran amigo Jorge Abad, pero nunca has intentado crear tu propia retrospectiva, más adecuada a las necesidades de tu equipo en un momento dado?

Finalmente, ¿te basas y promueves que el equipo y la organización se basen en lo que ya ha sucedido, datos cuantitativos, sobre todo, para tomar decisiones sobre qué hacer y cómo hacerlo en el futuro inmediato?

Algo del Scrum que deberías estar haciendo

Photo by fauxels from Pexels

¿Y por qué todo este cuestionamiento?

Bueno, precisamente porque Scrum es útil en un entorno donde la experimentación debe(ría) estar a la orden del día. Como dije al principio, a eso se refieren Schwaber y Sutherland cuando dicen que Scrum se basa, además del pensamiento Lean, en el empirismo. Este último “afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado”.

Por ejemplo, no te desgastes mucho, ni entretengas a tu equipo haciendo estimaciones, aunque sean “ágiles”, en el primer sprint. Simplemente empieza. Al final del primer sprint tendrás un dato verificable de cuánto hizo el equipo. De inmediato, en el segundo sprint, toma la decisión de que la velocidad del equipo sea justamente el número de puntos que acaban de lograr en el sprint anterior. De hecho, esto es un patrón Scrum conocido como El clima de ayer.

Ahora bien, los experimentos no tienen que proponer cambios sustanciales a lo que se está haciendo. Puedes usar mejoramiento continuo de un paso a la vez, crea una expectativa de experimentación y mejora bastante baja, de tal forma que para nadie sea una carga impositiva sino más bien un camino a transitar, desafiante pero divertido. Eso sí, primero enséñales a todos a mejorar, a proponer esos experimentos que tanto quieres.

Por ejemplo, enséñales a prepararse para una Daily Scrum.

Puedo contar por centenares las reuniones diarias a las que he asistido con personas que van muy mal preparadas a la misma. Todo el tiempo están titubeando, desenfocados, desmotivados y mirando el reloj a que simplemente terminen los infames 15 minutos de la reunión porque saben que eso sí lo van a respetar. Una de las principales razones que he encontrado para que esto suceda es que es una sesión subvalorada, a la que le dan poca o ninguna importancia, porque no terminan de entender qué significa la inspección y adaptación como pilares esenciales de un entorno empírico.

Lo he resuelto con entrenamiento, preparación y acompañamiento. Además de crear todo un movimiento cultural alrededor del evento:

1.    Al principio del sprint fijas una táctica o técnica para llevar a cabo la reunión.

2.    Les enseñas a todos en el equipo cómo será, haces una simulación. Llevas a cabo conversaciones de mejora para que cada uno llegue a conocer muy bien los detalles.

3.    Antes de las primeras sesiones, te aseguras de que todos efectivamente estén preparados. Indagas si necesitan ayuda para estarlo. Les proporcionas la ayuda que necesitan.

4.    Durante el evento estás atento a cómo lo llevan a cabo para, a continuación de este, mantener otras conversaciones de mejora y perfeccionar en consecuencia.

5.    Indaga cómo se sienten, qué les hace falta, qué quieren proponer.

6.    Precisamente sobre este último asunto, lo más importante es, enséñales a mejorar ese paso a la vez. Por ejemplo, enséñales con ejemplos claros a que cada vez digan más con menos palabras. Pero sin atribularlos.

Por sobre todas las cosas, siempre ten en cuenta lo que sucedió los días anteriores. Y haz que ellos en el equipo también lo tengan presente. No puedes encontrar nada de eso que sucedió en un cuerpo de conocimiento, mucho menos en la guía de Scrum. De hecho, Scrum se basa en la inteligencia colectiva de las personas que lo usan. Y es precisamente esa diversidad de perspectivas, una de las formas cómo enfrentamos la complejidad que nos rodea, lo que posibilita que encontremos soluciones más acertadas o apropiadas a los problemas que nos desafían cotidianamente.

Quieres saber más

Para saber más del Scrum que deberías estar haciendo, te invito a mi próximo curso para Scrum Masters. Encuentras toda la información de este en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

Mientras tanto:

Para saber más de cómo mejorar la Daily Scrum:

http://www.gazafatonarioit.com/2022/01/como-ayudar-tu-equipo-mejorar-su-daily.html

https://luchosalazar.com/2021/04/23/daily-scrum-kaizen/

Para saber más sobre el clima de ayer y otros patrones Scrum:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/


Nuevo curso: Scrum Master

Es un hecho: la notoriedad de las prácticas ágiles para el desarrollo de productos ha crecido y sigue creciendo, hasta el punto de convertirse en ese oscuro objeto del deseo de las organizaciones, grandes y pequeñas, que han estado adoptándolos en distintos niveles. Típicamente, los enfoques de adopción se implementan vía Transformaciones Ágiles y la historia ha mostrado resultados mixtos: éxitos y fracasos de estas iniciativas de cambio. Las tácticas usadas y los métodos específicos seleccionados para la adopción varían ampliamente dependiendo del contexto.

Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Scrum ayuda a poner de manifiesto o en práctica los valores y principios que definen el pensamiento ágil y Lean a través de una serie de lineamientos simples pero efectivos que habilitan a las personas y equipos para ser más productivos mientras mantienen la energía y la motivación al hacer su trabajo.

Este curso permitirá al asistente adquirir y dominar los conceptos necesarios y suficientes para poner en uso el marco de trabajo Scrum y prácticas relacionadas en iniciativas de todo tipo. El curso contribuye a que los equipos y las organizaciones den un paso más en el mejoramiento continuo como corporaciones de alto desempeño y empiecen a mirar la transformación digital como una opción capital en tiempos de alta incertidumbre y complejidad.

Prerrequisitos del curso:

Este taller no tiene ningún prerrequisito. Sin embargo, se recomienda ampliamente:

·       Leer la guía de Scrum (http://www.scrumguides.org/download.html). Aquí la encuentran en original inglés y en muchos otros idiomas, incluyendo español. Buscar la línea “Spanish (South/Latin American) (November 2020))” y hacer clic allí para descargar.

·       Leer el Manifiesto Ágil (http://agilemanifesto.org/iso/es/manifesto.html)

Objetivos del curso:

Al finalizar este curso, el participante estará en capacidad de:

·       Conocer, interiorizar, practicar y empezar a promover los Valores y Principios del Manifiesto Ágil, qué significa ser Ágil y de qué se trata la Filosofía Ágil.

·       Adquirir el conocimiento básico de las prácticas Ágiles para desarrollo de productos y los aspectos fundamentales del marco de trabajo Scrum. Incluyendo las responsabilidades, los eventos y los artefactos propuestos por el marco de trabajo.

·       Entender varias técnicas para mitigar la incertidumbre y el riesgo de los proyectos aplicando valores y principios Ágiles.

·       Aplicar el marco de trabajo Scrum para conocer las necesidades en las operaciones específicas de los negocios.

·       Aumentar la transparencia, inspección y adaptación, pilares de Scrum, mediante la vivencia de los cinco valores de Scrum: coraje, foco, franqueza, apertura y compromiso.

Para quién es valioso este curso:

Este curso y certificación son apropiados para cualquier persona interesada en empezar a ejercer como Scrum Master, pero también que busque conocer los principios fundamentales de Scrum, que estén o vayan a participar en iniciativas ágiles con Scrum; también, y para interesados en las iniciativas y proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

·       Gerentes o Líderes de producto

·       Dueños de Producto

·       Mercadeo de productos

·       Analistas del negocio

·       Analistas funcionales

·       Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:

·       Líderes técnicos

·       Gerentes de Proyectos

·       Desarrolladores

·       Arquitectos de software

·       Analistas de Prueba

·       Diseñadores

·       Scrum Masters

·       Desarrolladores Scrum

·       Consultores Comerciales,

·       Consultores de Preventa de Proyectos

·       Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de las prácticas propuestas por Scrum.

Contenido:

1.    Introducción Ágil

2.    Qué es Scrum

3.    Valores de Scrum

4.    Scrum Team

o   Product Owner

o   Developer

o   Scrum Master

5.    Eventos de Scrum

o   Sprint

o   Sprint Planning

o   Daily Scrum

o   Sprint Review

o   Sprint Retrospective

6.    Artefactos de Scrum

o   Product Backlog

o   Sprint Backlog

o   Increment

7.    Otros Conceptos de Scrum

8.    Prepárate para ser el mejor Scrum Master

Formación:

Tipo de Curso: Profesional.

Código de la Certificación: SMPC®.

Examen de Certificación:

El curso incluye el examen de certificación SMPC® por Certiprof.

·       Formato: Opción múltiple

·       Preguntas: 40

·       Idioma: Español/Inglés/Alemán/Portugués

·       Puntaje de aprobación: 32/40 o 80 %

·       Duración: 60 minutos

·       Libro abierto: No

·       Entrega: Este examen está disponible en línea

·       Supervisado: Será a discreción del Partner

Información del próximo curso:

Duración: 15 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1: miércoles 23 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2: jueves 24 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3: lunes 28 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 4: miércoles 30 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 5: jueves 31 de marzo de 2022. 5 p.m. a 8 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$479 precio regular.*

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

Atención: Incluye certificación Scrum Master Professional Certificate. SMPC®

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.


viernes, marzo 13, 2020

Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay
Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

  • El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y
  • El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay
El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 
La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.

jueves, noviembre 21, 2019

La lista de chequeo de Scrum Roosmalen

Clic para ampliar la imagen

Ralph van Roosmalen implementó hace ya algunos años esta herramienta en Microsoft Excel, basado en la ya archifamosa Lista de Chequeo de Henrik Kniberg, de la cual tuve la oportunidad de publicar la versión en español hace ya varios años. La pueden encontrar y descargar en:


Si ya la tienes, vuelve a releer el espíritu que inspiró esta lista de chequeo. No intentes encontrar todas las respuestas allí, es un buen comienzo. La he usado ampliamente de diversas formas en los últimos años y me ha funcionado bastante bien. En retrospectivas y revisiones de distintas implementaciones de Scrum y de prácticas ágiles. Como fuente de aprendizaje para futuros Scrum Master, Dueños de Producto y miembros de equipos Scrum en general. Como parte del crecimiento de las empresas hacia un pensamiento lean-ágil que soporte su cultura organizacional. En fin, las posibilidades son infinitas.

En esta ocasión contacté a Ralph y me autorizó a publicar la traducción al español de su herramienta. Muy útil para presentar información incluso a la alta gerencia, como guía del estado de una implementación Scrum típica. Está enriquecida con gráficos de los aspectos más relevantes del marco de trabajo que finalmente sirven como datos para tomar decisiones acerca de los pasos siguientes durante el cambio en la forma de hacer las cosas.

Clic para ampliar la imagen

Como siempre, el llamado es a experimentar, a cambiar la herramienta una vez que la dominemos, a sacarle el mejor provecho posible. Aquí se las presento. Al final, encuentran el enlace para descargarla. Veamos que dice Ralph en la página de Documentación.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum o para evaluar tu actual implementación de Scrum. Está basada en la Lista de Chequeo de Scrum de Henrik Kniberg[1]. Le he adicionado una sección: Scrum Distribuido.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum pero se aseguraron de que el propósito de la práctica Scrum ha sido cumplido de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la retrospectiva. Como una herramienta de discusión, no como una herramienta de evaluación.
¿Es esta una lista de chequeo oficial?  No. La lista de chequeo refleja principalmente la opinión personal y subjetiva de Henrik acerca de lo que realmente importa en Scrum. Él ha pasado años ayudando a compañías a empezar con Scrum y ha conocido a cientos de otros practicantes, instructores y entrenadores; y ha encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Clic para ampliar la imagen
Para usar la lista de chequeo correctamente, si es posible diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y allí es donde se pone interesante. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo será el comienzo de una discusión! Como se describió en el segundo párrafo, no puedes juzgar una implementación de Scrum basado solo en esta lista de chequeo. Si acaso sea posible juzgar una implementación de Scrum    ;)

Para usar el instrumento, ve a la hoja Entrada de Datos y marca tu  "calificación". Cuando todo esté diligenciado correctamente, todas las cruces rojas serán verdes. Tan simple como eso, como en Scrum. Scrum es mortalmente simple... Sin embargo, implementarlo puede ser muy desafiante ;)

Clic para ampliar la imagen
¿Pensaste que encontraste un error porque la columna "Tu número de madurez de Scrum" siempre es 42 [2]? Correcto y esto no es un error. No puedes capturar una implementación de Scrum en un número, eso es imposible. El hecho de hacer algunos cálculos y mostrar gráficos ya es cuestionable.
¿Por qué no usamos degradados rojos y verdes en las barras de colores? Porque el rojo está relacionado con lo negativo y el verde con lo positivo y no podemos decir que algo es negativo o positivo en tu organización. Así que lo mantenemos neutral, solo azul.

Clic para ampliar la imagen
Si tienes preguntas o comentarios, contáctame en ralph@agilestrides.com.

Referencias




Puedes descargar la herramienta de Ralph aquí:




No dejes de contactarme o de contarme en el foro sobre el uso que le están dando a esta herramienta que seguramente te será de mucha utilidad.