Técnicas y Herramientas

Ágiles
Metodología SCRUM
Análisis de Brechas(GAP)

▪ Técnica para comparar dos entidades, por lo general, el

estado actual y futuro de una empresa.
▪ Durante la evaluación de necesidades, el análisis de
brechas se realiza al examinar las diferencias entre los
estados actuales y futuros.
▪ Se realiza comparando las capacidades requeridas con las
capacidades existentes e identificando la diferencia o
"brecha"
Análisis de Brechas(GAP)
Problema / Visión del Proyecto

La cooperativa no tiene como tomar decisiones

asertivas en sus procesos core como captaciones,
Problema colocaciones, tasas y moras
Desarrollar un cuadro de mando integral y reportes
que permita la toma de decisiones asertivas en sus
Visión del procesos core como captaciones, colocaciones, tasas y
Proyecto moras
Análisis de Personas (PERSONA ANALYSIS)
Una persona es un personaje ficticio creado para representar a
un individuo o grupo de partes interesadas, denominado clase
de usuario.
Para una clase individual, una persona puede incluir cualquier
número de características descriptivas que el equipo considere
que vale la pena capturar, por ejemplo, un nombre, narrativa,
objetivos, comportamientos, motivaciones, pasatiempos,
entorno, demografía y / o habilidades.
La narrativa de la persona, si se incluye, cuenta una historia
sobre la clase de usuario.
Análisis de Personas (PERSONA ANALYSIS)
El objetivo es analizar la información de uso o extraer los
requisitos de las partes interesadas para determinar cómo
una clase de usuario interactúa con una solución.
Una persona puede variar en tamaño desde un párrafo de
resumen hasta una descripción de una a dos páginas,
dependiendo de las características que el equipo acepte
capturar.
A diferencia de una parte interesada, una persona puede o
no tener interés en el resultado del proyecto y puede ser
un usuario sin influencia sobre la solución.
Análisis de Personas (PERSONA ANALYSIS)
Técnica : Diagramas de Estructura
Wireframe
Prototipos de baja
fidelidad.
Es una forma rápida y
barata de conseguir
retroalimentación de
los interesados.
Mapeo de Historias
• Técnica que se utiliza para secuenciar historias de usuarios, según su
valor comercial y el orden en el que los usuarios suelen realizarlas,
para que los equipos puedan llegar a un entendimiento compartido
de lo que se construirá.
• Los mapas de historias ayudan a comunicar las características y los
componentes del producto que el equipo de productos será
responsable de entregar.
• Las historias escritas durante el desarrollo de la hoja de ruta del
producto normalmente se escriben en un nivel alto y pueden existir
como épicas.
Mapeo de Historias
Hoja de ruta del producto
• Proporciona una vista de alto nivel de las características
del producto, junto con la secuencia en la que se
construirán y entregarán las características.
• Se utiliza para comunicar cómo un producto se
desarrollará y madurará con el tiempo.
• Las hojas de ruta del producto incluyen información
sobre la visión del producto y la evolución del producto a
lo largo de su ciclo de vida.
Hoja de ruta del producto
• Los mapas de productos se utilizan como una herramienta
de planificación para comprender un producto y cómo
seguirá respaldando la estrategia de la organización a
medida que se refina y mejore.
• Las hojas de ruta de los productos deben estar alineadas
con los objetivos e hitos identificados como parte del
esfuerzo de planificación estratégica.
Hoja de ruta del producto
▪ Incluyen y documentan varios elementos clave, incluidos
los siguientes:
▪ Información de la estrategia.
▪ Portafolio.
▪ Programa.
▪ Iniciativas.
▪ Visión del producto.
▪ Criterios de éxito.
▪ Las fuerzas del mercado.
▪ Lanzamientos de productos.
▪ Características.
▪ Líneas de tiempo
Hoja de ruta del producto
Las características se clasifican
como "backbone", "Walking
Skeleton" u "opcional".
El backbone consta de
características esenciales para
que el producto funcione.
El Walking Skeleton consiste en
características mínimas que son
funcionales.
Las funciones opcionales
restantes se priorizan y se
agregan a la lista.
Hoja de ruta del producto
Hoja de ruta del producto
Jerarquía Requerimientos
 Épicas
• Podría ser simplemente una gran historia de usuario que puede abarcar
varias iteraciones. Tales epopeyas tendrán estimaciones de alto nivel (y, por
lo tanto, con un menor nivel de precisión), pero son útiles para la
planificación de la liberación. Para el propósito de la implementación y la
planificación del sprint, las épicas se desglosan en historias.
• Por ejemplo, en el contexto del sistema de administración de bibliotecas en
línea:
• Epic # 1 - Como usuario de la biblioteca, debería poder buscar y tomar
prestados libros.
• Epic # 2: como administrador de la biblioteca, debería poder crear informes
de libros, prestatarios y solicitudes pendientes.
• Las épicas pueden ser compuestas (que comprenden múltiples historias
cortas) o complejas (una que es inherentemente grande y no se puede
descomponer fácilmente en historias más cortas).
 Característica
• Representa una funcionalidad de alto nivel requerida por la empresa. Al igual que
las épicas, las características también deben dividirse en fragmentos manejables,
como historias que pueden abarcar varias iteraciones para ser entregadas.
• A veces, las compañías basadas en productos pueden ver características o una
colección de características que podrían agruparse, enviarse y venderse a los
clientes por separado.
• Por ejemplo, continuando con el ejemplo anterior, algunas características podrían
ser:
• Característica # 1: no permitir que un usuario tome prestados más de dos libros a la
vez y se conserve por un tiempo máximo de 3 semanas.
• Característica # 2 - Imponer una multa si el libro no se devuelve dentro de la fecha
de vencimiento.
• En términos de jerarquía, no hay prescripción de si la épica o la característica
estarán en el nivel primario y, por lo tanto, ambas variaciones se ven
comúnmente.
Épicas Característica
 Temas
• Los temas son un conjunto de historias de usuarios relacionadas que se
combinan para acelerar la estimación, las publicaciones de planificación
o la planificación financiera (a nivel de patrocinador).
• El tema podría basarse en la persona (tipo de usuario) o en algunos
requisitos no funcionales como usabilidad, movilidad, rendimiento y
escalabilidad.
• Un ejemplo de un tema podría ser que el sistema utiliza un inicio de
sesión único de modo que el usuario y su tipo (prestatario o
bibliotecario) se identifiquen durante toda la sesión del navegador y no
sea necesario que el usuario inicie sesión una y otra vez para realizar
diferentes acciones.
 Historias de Usuarios
• A nivel de iteración, son las historias las que se utilizan como unidades para la
estimación, planificación e implementación.
• Las historias pueden pertenecer a un solo tema. Siguiendo el ejemplo anterior, las
historias relevantes para Epic # 1 y Feature # 1 podrían ser
• Historia # 1 - Como usuario de la biblioteca, debería poder buscar libros por el
nombre del libro o su autor.
• Historia # 2 - Como usuario de la biblioteca, debería poder navegar a través de la
lista de libros en el resultado de búsqueda y poder encontrar más detalles haciendo
clic en ellos.
• Historia # 3 - Dado que tengo menos de 2 libros reservados a mi nombre, cuando
hago clic en el botón "Pedir prestado", debería poder reservar el libro y recibir una
confirmación por correo electrónico.
• Historia # 4: Dado que han transcurrido 2 semanas desde que tomé prestado un
libro, espero recibir un recordatorio de la biblioteca 3 días antes de la fecha de
vencimiento para poder devolver el libro o solicitar una extensión.
 Tareas y subtareas
• Para implementar la historia, todas las cosas que un desarrollador tiene
que hacer se llama tarea.
• Una tarea podría ser algo de naturaleza técnica, como crear una tabla
en la base de datos, crear un elemento de menú, analizar un archivo
XML entrante, agregar lógica empresarial con solo presionar un botón o
conectar dos sistemas a través de una cola de mensajes.
• El proceso de descomponer las epopeyas en características,
características en historias de usuarios e historias de usuarios en
tareas también se denomina descomposición basada en valores.
Historia de Usuarios / Lista de Pendientes
User Stories/ Backlogs
• Las 3Cs para escribir Historias de Usuario
(Ron Jeffries):
• Card: se escriben en tarjetas con
anotaciones.
• Conversation: se conversan, detallan y
validan con el cliente.
• Confirmation: se escriben criterios de
aceptación para confirmar que la historia
se desarrolle correctamente.
Historia de Usuarios / Lista de Pendientes
User Stories/ Backlogs
Historia de Usuarios / Lista de Pendientes
User Stories/ Backlogs
Técnica: Historia de Usuarios
Características de Historia de Usuarios Efectivas
SMART Stories
Análisis KANO
▪ Técnica utilizada para modelar y analizar las
características del producto considerando las
características desde el punto de vista del cliente.
▪ Se puede usar para ayudar a un equipo de producto a
comprender el nivel de importancia de las características
que se consideran para el estado futuro.
▪ El eje vertical se usa para medir el grado de satisfacción
del cliente que proporcionará la característica, y el eje
horizontal muestra qué tan bien se espera que el producto
satisfaga o entregue la característica.
Análisis KANO
Se agrupan en una de cinco categorías
▪ Básico.- proporcionan poca satisfacción
▪ Rendimiento.- Evalúa conscientemente la solución final.
▪ Encantadora .- Las características que diferencian el producto de
los productos de la competencia y que a veces se conocen como
el factor "wow“.
▪ Indiferente.- Características que no satisfacen ni descontentan a
un cliente.
▪ Marcha Atrás.- Características que disminuyen el nivel de
satisfacción
Análisis KANO
MoSCoW
Una técnica que clasifica cada requisito en uno de los
siguientes grupos:
➢Must have (Debe tener) fundamental para el éxito de la
solución
➢Debería tener(Should have) importante, pero el éxito de
la solución no se basa en el requisito
➢Podría tener(Could have) puede omitirse fácilmente sin
afectar la solución
➢No tendrá (Won’t have) no entregado esta vez.
100 puntos o método de votación
acumulativa
• El método de 100 puntos es como una encuesta de opinión para
determinar la prioridad en un ambiente grupal. Cada participante en
el grupo recibe 100 puntos que se distribuirá como votos en la lista de
historias de usuario
• El participante está en su libre albedrío para dar tantos votos o tan
pocos
• Los votos se basan en los elementos que parecen más o menos
importantes en su opinión o perspectiva.
100 puntos o método de votación
acumulativa
Dinero de monopolio
• En muchos sentidos, el dinero del monopolio es similar al método de
100 puntos. Aquí el presupuesto del proyecto se entrega a los
patrocinadores o usuarios en forma de moneda falsa, como en el
popular juego de Monopoly. Luego se les pide a los usuarios que
distribuyan el dinero en las características o funcionalidades del
sistema que son valiosas o importantes para ellos