Guía de validación
Nombre | Rol |
---|---|
Charlie | Dueño de la guía |
Alexis | Autor |
Cristian | Autor |
Establecer las condiciones con las que una user story puede ser aprobada en sus diferentes etapas, tanto por equipo de validación como por stakeholder.
Para hacer una validación se necesita tomar diferentes parámetros que permitan comprobar la factibilidad y la calidad de una user story, para garantizar que no existan defectos y aporte un valor real al usuario de una manera simple y efectiva. Entre una de las estrategias de validación, se recomiendan diferentes prácticas como lo son los think alouds (Consulta el formato de Think Aloud) y las 10 heurísticas de Nielsen para asegurar la correcta usabilidad del sistema.
A continuacion se incluyen las 10 heurísticas en formato de checklist para asegurarse que sean fáciles de usar y rapido de entender.
versión 2.0
Actividades |
---|
1. Visibilidad del estado del sistema:Nielsen propone que todo sistema debe realizar un feedback (o retroalimentación) constante con el usuario para que éste siempre sepa qué está pasando, así si rellenamos un formulario, debería salir alguna notificación avisando de que se ha enviado correctamente o de que hay algún error en algún campo (por poner un ejemplo). |
2. Utilizar el mismo lenguaje que el usuario: Todo sistema usable debe utilizar un lenguaje conocido por el usuario. |
3. Control y libertad para el usuario:El sistema puede ser utilizado por cualquier tipo de usuario y si este realiza una acción de error el sistema debe de darle la opción de deshacer o rehacer. |
4. Consistencia y estándares:El usuario es capaz de entender las acciones o situaciones que puede hacer en el sistema. |
5. Prevención de errores:El sistema es capaz de prevenir errores antes de mostrar mensajes de error. El sistema es capaz de solucionar los errores antes de que el usuario se encuentre con algún mensaje indicando el error. |
6. Minimizar la carga de memoria del usuario:El sistema no requiere que el usuario memorice una gran cantidad de información y por lo tanto debe tener objetos o imágenes que faciliten al usuario su comprensión. |
7. Flexibilidad y eficiencia de uso: El sistema debe reconocer al tipo de usuario y dejar que éste personalice su experiencia de uso. |
8. Diálogos estéticos y diseño minimalista:El sistema debe ser capaz de aportar la mínima información relevante para el usuario sin que éste último pierda de vista el contenido más importante del sitio web. |
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores:Para que el usuario pueda solucionar los errores del sistema éste debe ser capaz de expresarlos en un lenguaje que el usuario reconozca, aportando la información más importante sobre lo que ha ocurrido y proponiendo algún tipo de solución (si la hubiera). |
10. Ayuda y documentación:A pesar de que lo recomendable es que no se necesite una documentación habrán casos en los que sí haga falta, por tanto, la documentación debe estar ubicada en un lugar de fácil acceso para el usuario, escrita en un lenguaje que conozca y de ser posible que no sea muy extensa. Quizás una alternativa a la documentación, dependiendo de los casos, sea una página dedicada exclusivamente a "Preguntas frecuentes". |
Nova Offical Wiki
- [PRO01] Proceso para generar un backlog
- [PRO02] Proceso de auditorías
- [PRO03] Proceso para definir un proceso
- [PRO04] Proceso para institucionalizar procesos, guías o políticas
- [PRO05] Proceso de Daily Meeting
- [PRO06] Proceso de inicio de iteración
- [PRO07] Proceso de cierre de iteración
- [PRO08] Proceso de modificación de línea base
- [PRO09] Proceso de gestión de historias de usuario
- [PRO10] Proceso para desarrollar una historia de usuario - Cannis Majoris
- [PRO11] Proceso de gestión de métricas
- [PRO13] Proceso de gestión de riesgos
- [PRO15] Proceso de acciones correctivas
- [PRO16] Proceso de reporte de estado
- [PRO17] Proceso de asignación de roles
- [PRO18] Proceso de validación
- [PRO20] Proceso de involucramiento de stakeholders
- [PRO21] Proceso para junta con el cliente
- [PRO22] Proceso de Pair Review
- [PRO23] Proceso de toma de decisiones
- [PRO24] Proceso de gestion de cambios a historias de usuario
- [PRO25] Proceso de recolección de requisitos
- [PRO26] Proceso para definir el alcance
- [PRO27] Proceso de SCAMPI
- [PRO28] Proceso de mejora continua
- [PRO29] Proceso de presentaciones
- [PRO30] Proceso de Acompañamiento para Competencia Oral
- [PRO31] Proceso de inspección
- [PRO32] Proceso de desarrollo de historias de usuario - Andrómeda
- [GUI01] Guía de CMMI
- [GUI02] Guía de manejo de configuración
- [GUI03] Guía de versionado
- [GUI04] Guía para institucionalizar procesos, guías y políticas
- [GUI05] Guía para agendar eventos
- [GUI06] Guía de Nova Flow
- [GUI07] Guía para definir un WBS
- [GUI08] Guía de especificación de requisitos
- [GUI09] Guía del ciclo de vida del proyecto
- [GUI10] Guía de petición de cambios a historias de usuario
- [GUI11] Guía de creación de métricas
- [GUI12] Guía de uso de Clockify
- [GUI13] Guía de entorno de verificación
- [GUI14] Guía de determinación de evaluación de decisiones
- [GUI15] Guía para estimar
- [GUI16] Guía de identificación de inconsistencias
- [GUI18] Guía del Program Manager
- [GUI19] Guía del Team Leader
- [GUI20] Guía para juntas de desempeño
- [GUI21] Guía para juntas de seguimiento personal
- [GUI22] Guía del Product Owner
- [GUI24] Guía de identificación de riesgos
- [GUI25] Guía del Team Member
- [GUI26] Guía de Validación de historias de usuario
- [GUI27] Guía para identificar procesos, guías y políticas
- [GUI28] Guía de resolución de conflictos
- [GUI29] Guía de denuncias
- [GUI30] Guía de estrategia técnica
- [GUI31] Guía de exposición oral
- [GUI32] Guía para la identificación de recursos del proyecto
- [GUI33] Guía de verificación y validación de productos
- [GUI34] Guía del Architect Owner
- [GUI35] Guía de Manuales
- [POL02] Política de juntas
- [POL03] Política de Nova WoW
- [POL04] Política de comunicación
- [POL05] Política de elementos de la configuración
- [POL06] Política de líneas base
- [POL07] Política de Configuration Control Board
- [POL09] Política de manejo de datos
- [POL11] Política de gestión de métricas
- [POL18] Política de gestión de habilidades y conocimientos
- [PLA01] Plantilla de proceso
- [PLA02] Plantilla de política
- [PLA03] Plantilla de guía
- [PLA04] Backlog de decisiones
- [PLA05] Backlog de requisitos
- [PLA06] Backlog de métricas
- [PLA07] Hoja de SCAMPI
- [PLA08] Checklist de SCAMPI
- [PLA09] Matriz de riesgos
- [PLA10] Reporte de inspección
- [PLA11] Checklist de institucionalización
- [PLA12] Plan de involucramiento de stakeholders
- [PLA13] Backlog de patrones
- [PLA14] Plan de iteración
- [PLA15] Plan de presentación
- [PLA16] Retrospectiva de la iteración
- [PLA17] Acta de proyecto
- [PLA18] Backlog de PIPs
- [PLA19] Hoja de especificación de requisitos
- [PLA20] Reporte de Pair Review
- [PLA21] Backlog de roles
- [PLA22] Plantilla de auditorías
- [PLA23] Checklist de reporte de estado
- [PLA24] Plantilla para validación con cliente
- [PLA25] Plantilla de minuta de junta