CASO // AGILE-CLICKS-01  ·  Recorrido practico  ·  1 sesion Especializacion en Gerencia de Proyectos · UniMinuto · Buenaventura

Construir lo que entrega valor.

Un recorrido practico desde el primer dibujo hasta un producto jugable 1 vs 1. Seis conceptos de agilidad aplicados a un caso unico: una app de clicks que va naciendo en tus manos, iteracion a iteracion. Al final de esta pagina hay un producto funcional, no una promesa.

Caso App de clicks 1 vs 1 · 15 segundos
Modo Recorrido + producto jugable
Conceptos 06 — modelo, prototipo, PMV, requisitos, backlog/pila, tablero
Salida esperada Producto funcional al final de la pagina

00Arranque Pregunta de la sesion

Toda discusion sobre agilidad termina en la misma pregunta: ¿como sabe un usuario que el producto le entrega valor? No por la cantidad de horas que costo. No por las paginas del informe. El usuario lo sabe cuando puede usarlo y resolver algo que antes no podia. Esta pagina responde la pregunta construyendo, ante tus ojos, un producto desde cero.

Wireframe de cohete: apertura del recorrido
PREGUNTA DEL CASO

Que pasa si en lugar de planear todo, construimos lo minimo que ya entrega valor?

Si la respuesta es "nada", el proyecto seguira siendo cascada. Si la respuesta es "todo cambia", los seis conceptos de esta pagina son el sistema operativo de esa respuesta.

Bloque 00 ArranqueLa pregunta del caso. Por que importan estos seis conceptos juntos. Inicio
Modulo 01 Valor para el usuarioConceptos 01 y 02. Requisitos del producto y modelos de baja, media y alta fidelidad. C01 · C02
Modulo 02 Construir lo que valeConceptos 03 y 04. El prototipo demuestra la idea. El PMV entrega valor real. C03 · C04
Modulo 03 Trabajo ordenadoConceptos 05 y 06. Pila, backlog y tablero: como se ordena lo pendiente por valor. C05 · C06
Modulo 04 Entrega finalLa historia HU-05 abre la competencia. El producto se vuelve jugable 1 vs 1. Producto
Cierre Recap + ruta + ejercicioLos seis conceptos en una vista. Como aplicarlo en tu propio proyecto esta semana. Compromiso
Modulo 01 Valor para el usuario Conceptos 01 y 02
Wireframe de mano con post-it: apertura del modulo de requisitos
ABRE MODULO

Antes de construir, escuchamos. Antes de codear, dibujamos.

No hay producto sin alguien para quien construirlo, ni dibujo bueno sin haber descartado tres dibujos malos. Los dos primeros conceptos vacunan contra el error mas caro de la industria: construir lo equivocado, perfectamente.

01Recoleccion de requisitos

Lo primero no es codigo. Es saber que hace falta.

Punto de partida
"Si no puedo describir lo que el producto tiene que ser y lo que tiene que hacer en menos de una pagina, no estoy listo para construirlo." Principio operativo · Agilidad practica
Idea Caracteristicas y funcionalidades.

Caracteristicas (C) = como debe SER el producto. Cualidades: una pantalla, sobrio, portatil. Funcionalidades (F) = que tiene que HACER. Acciones: contar, mostrar, declarar.

Sin esa lista, todo lo que sigue es decoracion. No hay forma de saber cuando el producto esta terminado si no se sabe que tiene que hacer.

Sin C+F, no hay criterio de cierre.
Caso practico · App de clicks 5 caracteristicas, 5 funcionalidades.

Caracteristicas:

  • Una sola pantalla, sin instalacion.
  • Funciona en computador y celular.
  • Para dos jugadores en el mismo dispositivo.
  • Partidas cortas, no mas de 15 segundos.
  • Visualmente sobrio, sin distraer.

Funcionalidades:

  • Contar los toques de cada jugador.
  • Mostrar el cronometro corriendo.
  • Avisar quien gana cuando termina.
  • Permitir reiniciar la partida.
  • Dar feedback visual al tocar.
Plan ejecutable · 5C · 5F
Ejemplo de uso Cualquier producto que no sea trivial.

Antes de pintar Figmas o programar nada, sientate 30 minutos con quien va a usar el producto y lista C y F. Esa lista vive en el backlog del proyecto, no en un Word que nadie abre.

Aplica igual en software, en un curso virtual, en un servicio publico o en un evento. Sin C+F escrito, cada persona del equipo construye un producto distinto en su cabeza.

Software · educacion · servicios · eventos
HU que activa este concepto HU-00Como equipo queremos definir que vamos a construir antes de empezar a codear.
Pieza entregada Lista de 5 caracteristicas + 5 funcionalidades firmada por el equipo.
Valor que llega al usuario Claridad. Nadie va a programar lo que se le ocurra. El producto que se construye es el que se necesita.
02Modelo (baja, media, alta fidelidad)

Dibujar para pensar. Iterar para podar.

Antes del codigo
"Una hora dibujando ahorra una semana de programacion. Quitar un boton en un wireframe cuesta dos minutos; quitarlo despues de programado cuesta dos dias." Heuristica de diseno · UX / agilidad
Idea El modelo es un dibujo. Existe en tres fidelidades.

Baja fidelidad: cajas y trazos rapidos. Sirve para discutir que va en la pantalla, no como se ve. Es el dibujo mas barato del mundo.

Media: proporciones reales, espacios, jerarquias. Alta: detalle visual definitivo, listo para programar.

Iterar el modelo es eliminar tanto como agregar. Si la version siguiente no quita nada, no era una iteracion.

Empieza feo. Termina simple.
Caso practico · App de clicks Tres dibujos. Dos podas.

v0 — Baja fidelidad: el primer impulso. Hay 8 elementos en pantalla: banner publicitario, leaderboard mundial, chat, perfil, share, tendencia, tab bar y confeti. Solo dos sirven: el contador y el boton.

v1 — Media fidelidad: se podan los 6 elementos que no aportan valor. Quedan tres: titulo, contador y boton.

v2 — Alta fidelidad: mismas tres piezas, alineadas a una reticula, con tipografia y proporcion definitiva. Lista para programar.

Plan ejecutable · v0 → v1 → v2
Ejemplo de uso Cuando alguien se enamora del Figma.

El sintoma de mal uso del modelo es discutir colores en baja fidelidad o textos en alta fidelidad. Cada fidelidad tiene una pregunta propia: baja = que va, media = como se acomoda, alta = como se ve definitivo.

Empezar en alta es caro. Quedarse en baja es lento. Pasar por las tres, con disciplina, es lo barato.

Disciplina de fidelidad
HU que activa este concepto HU-01Como equipo queremos ver como se vera la app antes de programar nada.
Pieza entregada Tres wireframes. Cada uno con menos elementos que el anterior.
Valor que llega al usuario Ahorro. Cada elemento podado en wireframe es una semana de codigo que no se gasto en algo que el usuario no necesitaba.
Modulo 02 Construir lo que vale Conceptos 03 y 04
Wireframe de tuerca: apertura del modulo de construccion
ABRE MODULO

De dibujo a producto. Dos pasos no negociables.

El dibujo no se usa. El producto si. Entre ambos hay dos formas distintas de "ya casi": el prototipo prueba que la idea funciona, el PMV demuestra que el producto entrega valor real.

03Prototipo

Una caracteristica, una funcionalidad. Funciona.

Primer codigo
"Un prototipo es un experimento ejecutable. Su trabajo no es estar terminado: es responder con honestidad si la idea principal del producto realmente funciona." Definicion operativa · agilidad practica
Idea Hace una sola cosa. Pero la hace de verdad.

Un prototipo tiene caracteristicas reales (es la cosa, no un dibujo) y al menos una funcionalidad implementada (responde a una accion del usuario).

Lo que no es: no es PMV (le faltan funcionalidades), no es maqueta (es codigo), no es producto final (todavia es un experimento).

Experimento ejecutable.
Caso practico · App de clicks El primer boton que cuenta.

El prototipo de la app es un boton azul que aumenta un contador en uno. Eso es todo. No hay cronometro, no hay segundo jugador, no hay ganador, no hay reinicio.

Pero cuando se toca, el numero sube. Y el equipo aprende algo que el wireframe no podia ensenar: el toque se siente bien. Esa hipotesis ya esta validada y nunca mas se discute.

Plan ejecutable · 1C real · 1F implementada
Ejemplo de uso Cuando una idea suena bien pero nadie sabe si va a funcionar.

Un curso virtual con quizzes: el prototipo es una sola pregunta funcional. El usuario la responde y ve si acerto. No hay catalogo de cursos, ni perfil, ni progreso. Una pregunta.

Si esa pregunta sola enganchaa al estudiante, el resto del producto tiene sentido. Si no engancha, ningun catalogo va a salvarlo.

Cursos · apps · servicios · campanas
HU que activa este concepto HU-02Como usuario quiero tocar algo y ver que cuenta, para saber si la mecanica del producto me convence.
Pieza entregada Un boton funcional. Cuenta clicks reales.
Valor que llega al usuario Confirmacion. La idea ya no es promesa: es algo que se puede tocar y el equipo ya sabe si vale la pena seguir.
04Producto minimo viable

Minimo no quiere decir incompleto. Quiere decir suficiente para entregar valor.

Primer producto real
"El PMV es la version mas pequena del producto que entrega valor real al usuario y que el equipo puede mejorar con feedback. Si no entrega valor, no era PMV; era prototipo sin terminar." Definicion operativa · Lean / agilidad
Idea Todas las C+F, en su minima expresion.

El PMV tiene todas las caracteristicas y todas las funcionalidades que el producto necesita para entregar valor. "Minimo" se refiere al alcance de cada una, no a cuantas hay.

Le caben mejoras, por eso es minimo. Pero ya cumple su promesa basica, por eso es viable.

Minimo · Viable · Mejorable
Caso practico · App de clicks Un jugador, pero el producto completo.

Despues del prototipo, el equipo construye sobre el boton funcional: + cronometro de 15 segundos, + countdown 3-2-1, + boton de reinicio, + resultado final destacado, + feedback visual al tocar.

El PMV ya tiene 5 funcionalidades de 5 implementadas. Sigue siendo de un jugador, pero ya entrega un valor real: el usuario puede jugar una partida completa, ver su mejor marca y querer mejorarla.

Plan ejecutable · 5C · 5F · 1 jugador
Ejemplo de uso El curso de UniMinuto, version PMV.

En vez de liberar 6 modulos perfectos al final del semestre, el PMV libera el modulo 1 funcionando en la semana 4, con 25 estudiantes piloto. Tiene quiz, video, foro, tarea calificable. Una sola unidad, pero completa.

El feedback de esos 25 estudiantes cambia el modulo 2 antes de producirlo. Se evitan meses de trabajo en una rampa equivocada.

Cursos · apps · politicas publicas
HU que activa este concepto HU-03Como entrenador quiero un cronometro de 15 segundos para correr varias rondas y ver mejorar mi marca.
Pieza entregada PMV de un jugador con las 5 funcionalidades del producto.
Valor que llega al usuario Producto usable. El usuario ya puede entrenarse, ver su mejor marca, querer volver. Si el PMV no genera ese loop, no era viable.
Modulo 03 Trabajo ordenado Conceptos 05 y 06
Wireframe de ojo: apertura del modulo de visibilidad del trabajo
ABRE MODULO

El trabajo invisible es el que se demora.

Hasta aqui hubo un producto creciendo. Pero detras de cada iteracion habia decisiones: que se hace primero, que se posterga, donde esta cada tarea. Los conceptos 05 y 06 son la mecanica que sostiene el ritmo.

05Pila y Backlog

El producto pendiente, ordenado por valor.

Trabajo por hacer
"El backlog no es una lista. Es una decision sostenida en el tiempo sobre que entrega mas valor primero. Cada vez que el equipo lo abre, vuelve a tomar la decision." Heuristica de product backlog · agilidad
Idea Pila distinta de backlog.

Pila = trabajo por hacer. Es solo la lista cruda, sin orden, sin criterio. Es lo pendiente.

Backlog = la logica de fondo del producto. Es la pila ordenada por valor entregado dividido por esfuerzo. Arriba va lo que mas vale por unidad de trabajo. Abajo, lo que puede esperar.

La pila se acumula sola. El backlog se ordena con intencion.

Pila = inventario · Backlog = decision
Caso practico · App de clicks Ocho historias de usuario, ordenadas.

El backlog de la app tiene 8 HU. Lo de arriba es lo que el producto necesita para existir; lo de abajo es lo que se puede mejorar despues sin que el producto deje de entregar valor.

Ojo: HU-08 (sonidos) vive en el backlog largo, no porque sea mala idea, sino porque el producto entrega valor sin ella. La HU-05 (segundo jugador) es la siguiente a tomar porque abre la competencia, que era la promesa del caso.

Plan ejecutable · 8 HU priorizadas
Ejemplo de uso Cuando el equipo se queja de que todo es urgente.

Si todo es prioridad alta, nada es prioridad alta. La disciplina del backlog es elegir UNA cosa que se hace antes que el resto. Sin orden explicito, el equipo construye lo facil, no lo valioso.

Aplica en producto, en clases, en ONG, en alcaldias. Donde hay multiples partes interesadas, el backlog es el unico arbitro honesto.

Producto · educacion · politica publica
HU Historia de usuario Valor Esfuerzo Prioridad
HU-01 Como entrenador quiero que el contador empiece en cero al cargar la pagina. Alto S P0 · hecho
HU-02 Como entrenador quiero un boton de reinicio para correr varias rondas seguidas. Alto S P0
HU-03 Como entrenador quiero un cronometro de 15 segundos por partida. Alto M P0
HU-04 Como entrenador quiero ver el resultado final destacado al terminar la partida. Medio S P1
HU-05 Como dos jugadores queremos competir en la misma pantalla, lado contra lado. Alto M P0 · proxima
HU-06 Como jugador quiero feedback visual al tocar para sentir que el toque cuenta. Medio S P1
HU-07 Como jugador quiero un countdown 3-2-1 antes de empezar la partida. Bajo S P2
HU-08 Como jugador quisiera efectos de sonido y vibracion al ganar. Bajo L P2 · backlog largo

Pila = las 8 HU sin ordenar · Backlog = las mismas 8 HU ordenadas por valor / esfuerzo

HU que activa este concepto HU-04Como equipo queremos saber que historia se hace primero, sin que decida el que grita mas fuerte.
Pieza entregada Backlog: 8 HU con valor, esfuerzo y prioridad explicitos.
Valor que llega al usuario Predecibilidad. El usuario recibe primero lo que mas le sirve. El equipo construye lo valioso, no lo facil.
06Tablero de trabajo

Hacer visible lo que esta cargando alguien.

Trabajo en marcha
"Lo que no se ve, no se gestiona. El tablero es el contrato visual entre el equipo y la realidad: si una historia no esta en el tablero, no esta pasando." Heuristica de gestion visual · Lean / Kanban
Idea Tres columnas. Una sola pregunta.

El tablero tiene tres columnas: Por hacer, Haciendo, Hecho. Las HU se mueven de una a otra a medida que cambia su estado. La pregunta de fondo del tablero es: quien esta cargando que?

El backlog vive abajo (todo lo pendiente). El tablero solo muestra lo que esta activo. Eso obliga al equipo a no abrir demasiado trabajo a la vez.

Backlog acumula · Tablero limita
Caso practico · App de clicks El tablero del sprint actual.

En este momento del proyecto, el tablero se ve asi: una HU ya esta hecha (el contador empieza en cero), dos HU estan en haciendo (boton de reinicio y cronometro) y tres HU esperan en "Por hacer".

HU-05, HU-07 y HU-08 todavia viven en el backlog. No estan en el tablero porque el equipo aun no las eligio; estan disponibles para el siguiente sprint.

Plan ejecutable · sprint en curso
Ejemplo de uso Cuando nadie sabe que esta haciendo el equipo.

Sin tablero, las reuniones se vuelven preguntas: ¿que esta haciendo cada uno?, ¿como vamos?, ¿quien tiene esto? Con tablero, la reunion empieza con el tablero visible: el estado es publico, no se pregunta.

Esto vale para un equipo de software, una comision de profesores, un grupo en una ONG. Tablero visible, semana ordenada.

Equipos cruzados · proyectos sociales
Por hacer 3
HU-04Resultado final destacado
HU-06Feedback visual al tocar
HU-07Countdown 3-2-1
Haciendo 2
HU-02Boton de reinicio
HU-03Cronometro 15s
Hecho 1
HU-01Contador parte en cero
HU que activa este concepto HU-05Como equipo queremos ver de un vistazo en que esta cada quien y cuanto falta.
Pieza entregada Tablero con 3 columnas y 6 tarjetas activas.
Valor que llega al usuario Ritmo. El equipo termina lo que empieza antes de tomar nuevo trabajo. Menos cosas abiertas, mas cosas entregadas.
Modulo 04 Entrega final La promesa del caso
Wireframe de mano: apertura del modulo de entrega final
ABRE MODULO

La historia que abre la competencia.

El backlog ya tenia esta historia esperando: HU-05. Subirla al tablero y entregarla convierte el PMV de un jugador en el producto que prometia el caso.

07Entrega · HU-05 al tablero Producto jugable

El equipo toma la siguiente historia del backlog y la pasa al tablero. Es HU-05: dos jugadores compitiendo en la misma pantalla. La tarjeta azul de abajo es el plan ejecutable que el equipo se compromete a cumplir. Despues, abajo del plan, esta el producto cumpliendolo.

05HU-05 · Plan

Como dos jugadores queremos competir en la misma pantalla, lado contra lado, en una partida de 15 segundos.

Plan ejecutable
Criterios de aceptacion Que tiene que cumplir esta entrega para considerarse hecha.
  • La pantalla se divide en dos zonas iguales, azul a la izquierda y amarilla a la derecha.
  • Cada zona suma los toques de su lado, independientemente.
  • El cronometro corre simultaneo para ambos jugadores.
  • Al terminar, se anuncia ganador o empate, con la diferencia de marcas.
  • Un boton de reinicio prepara la siguiente partida sin recargar.
  • Funciona con tap en movil y con click en desktop.
Tarjeta azul · sprint actual · listo para programar

Aqui esta. Llama al de al lado.

Un solo dispositivo, dos jugadores, 15 segundos. El que mas toque gana. Toca Empezar partida, esperen los tres-dos-uno, y comiencen.

Jugador 1 0 Toca este lado
Jugador 2 0 Toca este lado
15
Listos
Resultado de la partida

Empate

HU activada HU-05Como dos jugadores queremos competir en la misma pantalla en 15 segundos.
Pieza entregada Producto jugable 1 vs 1. Lo que el caso prometia.
Valor que llega al usuario Diversion verificable. El usuario juega ahora mismo. El caso se cerro entregando, no prometiendo.
Curva de valor acumulado

Cuanto valor entrego cada iteracion?

Mira cuando empezo a entregarse valor. El primer wireframe (semana 1) no entrega nada al usuario. El prototipo (semana 4) entrega validacion de la mecanica. El PMV (semana 6) entrega producto usable de un jugador. La HU-05 (semana 8) entrega el producto completo. El equipo entrega valor antes de terminar.

100% 75% 50% 25% 0% v0–v2 PROTO PMV HU-05 ITERACIONES → VALOR ACUMULADO ↑
Cascada (todo al final) Iterativo (valor temprano)

08Cierre Recap · Ruta · Ejercicio

Seis conceptos en una vista

C · 01Recoleccion de requisitosC+F antes de codigo. Sin lista, no hay criterio.
C · 02ModeloBaja, media, alta. Iterar es podar.
C · 03PrototipoUna funcionalidad real. Valida la mecanica.
C · 04PMVTodas las C+F, en su minima expresion. Entrega valor.
C · 05Pila / BacklogPila acumula. Backlog ordena por valor / esfuerzo.
C · 06TableroPor hacer, haciendo, hecho. Lo invisible se demora.

Ruta para activar lo aprendido

No se trata de aplicar los seis conceptos en tu proyecto manana. La promesa es uno: elige el concepto mas debil en tu proyecto actual y activalo esta semana.

  1. Paso · 01

    Escoge un proyecto activo.

    No uno hipotetico. Uno con personas reales esperando algo concreto.

    Sin proyecto, no hay practica.
  2. Paso · 02

    Marca el concepto mas debil.

    El que duele al leerlo: ese. Si no tienes C+F escrito, ese. Si tienes backlog pero no tablero, ese.

    Diagnostico honesto.
  3. Paso · 03

    Define UNA accion concreta.

    Verbo + plazo + responsable. Si no cabe en una linea, no esta listo para experimentar.

    Una linea, un experimento.
  4. Paso · 04

    Mide el valor antes y despues.

    Una senal verificable, no una sensacion. ¿Que entrega tu proyecto hoy? ¿Que entrega despues del cambio?

    Cierre = aprendizaje.
Ejercicio de cierre · 7 minutos

Mi concepto activo

  1. Proyecto: nombre y proposito en una linea.
  2. Concepto elegido: uno entre C01 y C06.
  3. Diagnostico: en una frase, por que en este proyecto este concepto esta debil.
  4. HU activable: una historia de usuario que el concepto desbloquea (formato: Como X quiero Y para Z).
  5. Como vas a saber si entrego valor: una senal verificable, no una sensacion.

Entrega en una sola pagina. Si no cabe en una pagina, no esta listo para experimentar. Esta es la disciplina agil aplicada a la propia disciplina agil.