Para los que no conocíais el nombre, los Mockups son una “cooliana” manera de llamar a aquello que el que más y el que hemos ha tenido que hacer, o interpretar, alguna vez: un boceto de las pantallas de la futura aplicación.
Los Mockups son un soporte gráfico a los requisitos, si bien, de manera general, el término refiere a «maquetado».
Aunque la idea es de toda la vida (en el campo de los casos de uso, o de los requisitos tradicionales, esto está muy trillado), el término Mockups se está escuchando cada vez más en proyectos ágiles, ya que es una herramienta que complementa a las historias de usuario (te dejo un post sobre historias de usuario).
En muchos proyectos, junto con las historias de usuario y el product backlog, los Mockups se están convirtiendo en una herramienta complementaria para el product owner.
Por lo general, complementar las historias de usuario y el product backlog con los Mockups suele dar buenos resultados, con dos consideraciones:
– Que los aspectos gráficos no hagan perder el enfoque funcional, o que las historias de usuario sigan siendo la pieza clave, y el Mockups un complemento, no al revés.
– Que no sean un motivo de generación de documentación que no aporta valor, conllevando, además, un coste en mantenimiento de “papel”. Recuerda, documentación sí, pero documentación útil, simple e inteligente.
Si utilizáis un tablero Scrum físico, en la pared, y vais a utilizar Mockups, sería interesante darle una pensada a cómo complementar las historias con los Mockups, para que el tablero siga siendo práctico y manejable.
Como ya comentamos cuando hablamos de los mapas de historias, hay muchas maneras de montar un tablero Scrum, que en este caso n el que estamos van desde lo más básico, pegar junto a la historia de usuario el Mockups, hasta, si fuese necesario, tableros más complejos con columnas dedicadas sólo a los Mockups.
En lo que refiere a herramientas para pintar Mockups, lo que más he visto ha sido el powerpoint, cómo no, y lo que más me he encontrado en mi transitar por el mundo, en los que no usan powerpoint, es Balsamiq mockups, opción altamente recomendable frente al powerpoint. En cualquier caso, si quieres una comparación de herramientas, aquí te dejo una que es bastante buena.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
El mundo de la «agilidad» nunca me dejará de sorprender. Ahora resulta que las técnicas de prototipado que los mayores del lugar llevamos usando toda la vida (ya lo dice Javier)como una de las mejores formas de eliminar riesgos de no aceptación por parte de los usuarios de nuestros desarrollos y como una de las mejores forma de comunicar a los diseñadores/usuarios lo qué se quiere hacer se le llama Mockups.
Desde mi punto de vista, para hacer una descripción funcional de una aplicación de complejidad media/alta (no sencilla)no es suficiente con las historias de usuario. Yo creo que es necesario hacer en paralelo y por cada iteración (perdón sprint):
* un modelo de casos de uso (diagrama de contexto, tabla actores, diagrama/s de casos de uso y plantillas de texto de los casos de uso usando bien el concepto de patrones de casos de uso). Este modelo puede describir los CU con distinto nivel de detalle según sea necesario (como dice cockburn en su famoso libro de CU).
* La GUI (es decir bocetos de pantallas e informes junto con sus diagrama de navegación). (Ahora se llaman Mockups).
* Modelo conceptual de datos (bocetos con las principales entidades de negocio (no ficheros) relacionadas entre si y con la información (no campos) de que se compone).
Sólo es mi opinión de viejo informático.
Muy buen comentario Vicente.
Un día terminaré un post que tengo a medias sobre si nos vamos a volver a inventar la ingeniería del software 🙂
Javier, la verdad que yo hace un par de años comence con la complementación de Mockups, primero fue a los casos de uso y luego cuando entramos de lleno con la agilidad los aplicamos para complementar las User Stories. Por otro lado, tocando el post sobre la encuesta de las herramientas que has hecho y viendo que la herramienta para la gestión de tareas mas usada es JIRA, quería comentarles que esta herramienta trae incorporada una herramientas para crear mockups y anexarlas a las User Stories.
Bueno la verdad que esto ayuda a no tener que especificar todo un proceso y hace mas agil la documentación de procesos de negocios y por supuesto ayuda al entendimiento del desarrollador al momento de tomar una User Storie para desarrollar.
Gracias Matías,
Sabes cuál es el módulo de Jira de Mockups?
Saludos
Hola Javier.
El módulo para los mockups de JIRA esta en una aplicación adjunta llamada Bamboo y en esta se encuentra el aplicativo on line Balsamiq Mockups el cual se puede usar desde la interfaz de JIRA, es decir, crear las mockups y asignarlas a las User Stories. Sin embargo lo mejor es con la licencia de JIRA descargar el Balsamiq de escritorio y hacer las mockups, guardarlas localmente y luego subirlas a JIRA asociándolas a las User Stories correspondientes.
Saludos
El título ya deja cojo el árticulo porque un mockup no necesariamente
Debe estar orientado a interfaz de usuario final, es decir, puedes hacer
Un mockup de un sistema con el que te vas a integrar finalmente siendo este
Un componente digamos de backend como por ejemplo un service bus.
Sobre lo que dice dice Vicente, no hace falta tanta documentación, con un solution description que
Describa los flujos por funcionalidad y unos test definidos por caso de uso sería suficiente
Hola José. De los tres documentos que yo cito: CU con un nivel de detalle ajustado a la complejidad (lo sencillo no se profundiza), un borrador de pantallas y un modelo conceptual de datos ¿cual de ellos sobra para proyectos medios/altos (más de 6 meses de desarrollo con equipos de al menos 6 personas), no para los sencillos ni los mantenimientos evolutivos.
Por otra parte, qué es eso de «solutión descriptión»(¿descripción de la solución?), ¿podría ser algo parecido a los distintos tipos de escenarios de un CU?¿O quizás te refieres a los antiguos DFD diagramas de flujo de datos?.
Un cariñoso saludo José.
Hola, interesante lo de los mockups y alguna vez lo he aplicado para dar un mayor entendimiento al requerimiento por parte del usuario. Sin embargo, quisiera saber en que etapa de un proyecto ágil se crean los mockups.
Salufos
En mi posición de diseñador he preferido lanzarme al ruedo con HTML de una vez, colocando este en un servidor y cediendo el acceso a los usuarios para recibir la lluvia de opiniones u observaciones y así priorizarlas según las necesidades funcionales o requisitos, en muchos casos realizando ajustes en vivo durante las mesas de trabajo.
De esta manera adelanto algo el código final entregando a los desarrolladores algo más practico para iniciar y es 100% portable.
Dougals Castro.