Requerimientos en el Software IX-iv – Requerimientos escritos – Story maps

Story Maps

Los Story Maps son usados para organizar los requerimientos y ayudar la estructura del proyecto. Presenta el product backlog de una manera visual con la historias de usuario agrupadas dentro de específicas categorías funcionales. Priorizando las historias de usuario a través de múltiples categorías proveyendo una visión de lo que está siendo desarrollado.

Story Maps se compone de un conjunto de columnas. Cada una de ellas representa una categoría agrupando historias de usuario. Dentro de cada columna las historias de usuario son priorizadas de la más a la menos importante. Esta estructura intenta mostrar la prioritaria historia de usuario para todo el proyecto.

Storymap

Ejemplo:

ejemploStorymap

Requerimientos en el Software IX-iii – Requerimientos escritos – Product Backlog

Product Backlog

El product Backlog es un conjunto de funcionalidades del software que el product manager planea desarrollar para un producto a lo largo del proyecto. Es una forma de organizar el trabajo priorizando y planeando las tareas dentro del proyecto.

Para crear el product backlog:

  1. Después de realizar las historias de uso, las funcionalidades deberán ser plasmadas en una lista. A cada historia de usuario se le deberá asignar un único identificador simple como una secuencia de números o nombres.
  2. Priorizar las historias de uso y funcionalidades. Ayudará al cliente a identificar lo que quiere y sus necesidades. Y ayudará al equipo a identificar qué es lo más importante y a qué habrá que dedicarle más recursos conociendo cuál es el core del proyecto.
  3. Empezar a planificar el proyecto usando prioridades y puntos de referencias.
  4. Historias de usuario son agrupadas en Units of Works para ser completadas en un determinado intervalo de tiempo (sprints).
  5. Product Backlogs es flexible. Un sprint en proceso no debería cambiar pero una vez se le enseñe al cliente este debe evaluar el trabajo hecho y añadir o modificar historias de usuario o requerimientos o cambiar la prioridad de las historias de usuario o requerimientos.

Requerimientos en el Software IX-ii – Requerimientos escritos – Test de Aceptación

Test de Aceptación

Los test de aceptación son usados para verificar si un requerimiento ha sido alcanzado satisfactoriamente.

Ejemplo:

Como cliente quiero ser capaz de pagar con tarjeta de crédito así podré elegir el método más conveniente para realizar un pago.

Para dar como bueno el criterio de aceptación se debe fragmentar en varios pasos que se podrán chequear para dar como aceptable el criterio por ejemplo:

  1. Insertar la tarjeta en un lector de tarjetas.
  2. Insertar el PIN de la tarjeta.
  3. Confirmar que el pago ha sido aceptado.

Este criterio de aceptación será como válido si los tres puntos se cumplen.

Requerimientos en el Software IX-i – Requerimientos escritos – Historias de Uso

Historias de Uso

Las técnicas que hemos visto hasta ahora para expresar los requerimientos han sido las siguientes:

  • Casos de Uso.
  • Mockups.
  • Storyboards.
  • Historias de Uso.

Las Historias de Uso expresan los requerimientos siendo fácil escribir, leer y evaluar.

historiadeuso

Como cliente, quiero ser capaz de identificar qué restricciones tengo en mi dieta, así poder conocer qué puedo pedir cuando compro comida.

Requerimientos en el Software VIII – Storyboards

Storyboards

Storyboards en software son representaciones visuales de una interacción con el producto software.

Existen dos tipos de storyboards ambos sirven de ayuda para discutir e indagar requerimientos entre los clientes y entre el equipo de desarrollo para comprender qué se pretende crear.

Storyboards tipo 1

Tipo comic, describe paso a paso los distintos momentos en los que se interactúa con el producto.

requerimientos8 Storyboards

Usos potenciales:

  • Asegura que todo el equipo de desarrollo sepa de qué se está hablando, centra la atención.
  • Estimula el identificar posibles features que mejoran al producto.
  • Asegura la claridad del objeto de uso del producto.
  • Se puede usar en las demos de marketing.

Storyboards tipo 2

Este segundo tipo de storyboards combina los mockups con el flujo básico de los casos de uso con objeto de mostrar cómo el usuario final interactúa con el interfaz de usuario del producto en detalle.

requerimientos8 Storyboards 2

Usos potenciales:

  • Ayuda al equipo de desarrollo a diseñar los requerimientos.
  • Ayuda a identificar qué podría complicarse en exceso.
  • Asegura al equipo de desarrollo estar atentos a las funcionalidades y el sentir del producto.
  • Sirve de ayuda a la hora de crear los manuales de usuario.

requerimientos8 Storyboards 2b

 

Requerimientos en el Software IV – Comprendiendo al cliente para redactar los requisitos

Comprendiendo al cliente para redactar los requisitos

Eschuchar al cliente

Comprender al cliente realizándole las preguntas adecuadas y escucharle es de vital importancia para poder obtener las verdaderas necesidades del cliente y redactar con ello correctamente los requisitos.

Otras fuentes para obtener requisitos son:

  • Entrevistas con los usuarios finales.
  • Estudios de mercado para ver la viabilidad del producto.
  • Observar cómo un usuario final interactúa con el producto o un mock-up de este.
  • Viendo otros productos similares (estudio de la competencia).

En reuniones con el cliente se le debe ayudar a gestionar las expectativas transmitiéndole:

  • Los objetivos realistas del producto.
  • Tiempos de ejecución.
  • Qué se hará y qué no se hará en el producto.
  • Priorizar los requerimientos. Qué se hará antes y qué después.

En la reunión con el cliente se debe ser asertivo:

  • Abierto a las ideas y perspectivas del cliente.
  • No aceptar las ideas pasivamente, también hay que sugerir ideas y perspectivas pero no forzar agresivamente nuestro punto de vista.
  • Se debe proporcionar al cliente una estructura en la conversación sobre los requerimientos para ayudarle a organizar sus pensamientos.
  • El cliente puede tener un conjunto de ideas pero no conocer qué es técnicamente factible o ser de difícil comprensión para los usuarios finales. Para ello debemos ser capaces de captar el porqué el cliente tiene ese conjunto de ideas y la mejor manera de comprenderlo es preguntar al cliente cómo ven ellos a un usuario final interactuando con el producto y por qué. Para posteriormente proponerles ideas y explicarles porqué ciertas ideas pueden no funcionar explorando las posibles limitaciones en diferentes escenarios.
  • Es de vital importancia que el cliente esté informado y que comprenda sus opciones. Pero al final es él el que debe tomar la decisión de los requisitos que desea que sean cumplidos.

Después de la primera reunión con el cliente:

  • Mostrarle Mock-ups y prototipos producidos desde la primera reunión.
  • Mostrarle la lista de requerimientos con un identificador único para facilitar el hablar de ellos.
  • Preguntarle qué le gusta del producto, qué no le gusta y qué quieren.
  • Revisar con el cliente de nuevo los requerimientos.
  • Preguntarle por la elección del diseño.
  • Que diga abiertamente todo el feedback que desee.

Requerimientos en el Software V – Preguntando al cliente

Preguntando al cliente

Preguntando al cliente

Distintos tipos de preguntas en función de lo que se quiera indagar:

Para averiguar los requerimientos de negocio:

  • ¿Qué problema quiere resolver?
  • ¿Qué le motiva para resolver este problema?
  • ¿Qué cosas haría una aplicación buena que resolviera este problema?
  • ¿Qué cosas haría como mínimo una solución que resolviera esos problemas?
  • ¿Quién usaría esta solución?
  • ¿Qué tipo de usuarios usarían esta solución?
  • ¿En este sector quiénes son las personas de referencia?
  • ¿Hay más proyectos relacionados con este, se harán más soluciones relacionadas?
  • ¿Existen soluciones en el mercado similares?
  • ¿Qué debemos incluir en el alcance del proyecto y qué debemos dejar fuera? ¿Hasta dónde debemos llegar?

Para averiguar las reglas de negocio:

  • ¿Qué normativas debemos cumplir a la hora de desarrollar el producto?

Para averiguar los requerimientos de usuario:

  • ¿Con este producto qué objetivos alcanzará más fácilmente? O sea, ¿Este producto le ayudará a…?
  • ¿Qué problemas esperas solventar con este producto?
  • ¿Cómo describiría el producto? Es un producto que…
  • ¿Qué aspectos del producto le motivan más conseguir?
  • ¿Qué aspectos son más valiosos para los usuarios?
  • ¿Qué aspectos son menos valiosos para los usuarios?

Para averiguar los requerimientos no funcionales o de calidad:

  • Para las distintas partes del producto defina qué calidades alcanzar: eficiencia, seguridad, calidad, diseño, confiabilidad-robustez…

Para averiguar las interfaces externas:

  • ¿A qué eventos el producto debe responder?
  • ¿Con qué se debe comunicar el producto?
  • ¿En qué ambiente el producto será usado?

Para averiguar algunas condiciones excepcionales:

  • ¿Alguna vez alguien querrá…?
  • ¿Podría alguna vez ocurrir que…?
  • ¿Qué pasaría si…?

Para conocer algunas limitaciones:

  • ¿Qué es lo más importante del producto para ti?
  • ¿Cómo juzgarías, o en qué puntos te fijarías para saber que el producto ha sido un éxito?
  • ¿Qué puntos, con qué valores, podemos valorar el éxito del producto?
  • ¿Cómo debería el producto hacer cambiar la manera en la que ahora se hacen las cosas?
  • ¿Hay algo más que deberíamos preguntarte?

Para investigar en más profundidad algunos aspectos:

  • Por favor, ¿Podría ayudarme a comprender por qué… ? por ejemplo: por qué algo es importante, por qué es requerido, por qué es tan prioritario, por qué se hace de esta manera…

Requerimientos en el Software III – Gestión de las expectativas de un cliente

Gestión de las expectativas de un cliente

Espectativas del cliente

Visión y Alzance del proyecto software

Al desarrollar un producto se debe tener una VISIÓN GLOBAL DEL PRODUCTO como el valor o necesidad que cubre del cliente/usuarios finales dentro de un mercado o espacio donde vaya a operar la solución. ¿Cuál es el objetivo del producto? ¿Para qué se ha creado?

Cambios en el producto

Cualquier cambio que se vaya a realizar en el proyecto debe analizarse si afecta a la visión del producto, cosa que no debe ocurrir. El propósito del producto no debe variar.

Alcance o Scope de un producto

El Scope o alcance es lo que un producto realísticamente puede llegar a hacer. Es lo que debe conocer el cliente para gestionar las expectativas de este y jamás prometer lo que no se pueda llegar a hacer.

Para manejar las expectativas del cliente debemos:

  1. Mantener una buena comunicación entre el cliente y el equipo para crear juntos las expectativas.
  2. Dibujar el alcance con el cliente a través de herramientas como diagramas de casos de uso.
  3. Preguntar al cliente por la priorización de los requerimientos para realizar los más importantes para el cliente primero.
  4. Preguntar al cliente constantemente si hemos llegado a lo esperado (en cada paso del desarrollo) para no dedicar exceso de tiempo en requerimientos innecesarios.

Importante: Cada cambio en los requerimientos o en el alcance debería ser aceptado por escrito por el cliente puesto que conllevará a una revisión de tiempos en el desarrollo que deberá conocer y entender el cliente para estar dentro del presupuesto (o número de horas) acordado o si afecta a este.