En el contexto del desarrollo de un sistema que representa una tienda de productos (pueden ser libros, artículos de regalo, comida para perros…), vamos a ver cómo abordamos el desarrollo del requisito "crudo" (sin cocinar) Hacer el CRUD de Productos (las típicas operaciones de altas, bajas, modificaciones y listados).
Para ello, lo primero que vamos a hacer es desagrupar las diferentes operaciones (alta, baja, modificación y listados) y tratar de ponerlas en forma de historia de usuario (usando el formato "como rol quiero funcionalidad para objetivo). De esta manera podremos discutir con los expertos del dominio para ir averiguando los detalles de las funcionalidades a implementar. Además, podremos averiguar también qué cosas NO necesitan ser implementadas. Y de paso, podremos ir priorizando según el valor de negocio que tiene cada una de las funcionalidades, lo que nos ayudará a planificar nuestras iteraciones.
Altas
Como administrador del catálogo de productos
Quiero dar de alta un producto cualquiera
Para tenerlo disponible en el catálogo y ponerlo a disposición de los visitantes.
De esta US ya vemos que nos salen dos roles que vamos a necesitar: el administrador del catálogo de productos y los visitantes. Debemos ir tomando nota de esto porque, desde el punto de vista del diseño, son relevantes puesto que implican la necesidad de implementar un control de acceso.
También vemos que hay una funcionalidad relacionada: la visualización de los productos por parte de los visitantes. Yo pienso que el orden correcto a la hora de implementar el sistema es comenzar por los listados, en contra de la costumbre de comenzar por las altas. Si preguntamos al cliente "qué tiene más valor de negocio para él", seguro que nos contesta que "poner los productos a disposición de los clientes": a él no le importa realmente cómo se hayan introducido en el sistema.
Volveremos a esto más tarde. De momento vamos escribir la US que nos permitirá visualizar los productos.
Listados
Como visitante de la tienda
Quiero ver todos los productos del catálogo
Para conocer sus características.
Lenguaje ubícuo
Bueno, es una US muy sencilla: consiste en pintar en la pantalla la tabla de productos. MAL. Si comenzamos a manejar conceptos como pantalla o tabla de productos en una etapa tan temprana de la definición del proyecto nos podemos encontrar con que perdemos la perspectiva del negocio que queremos resolver. Tranquilos, ya tendremos tiempo de hablar de pantallas, botones, desplegables, incluso radio-buttons. Eso sí, nunca, repito, nunca deberíamos hablar con los clientes sobre el modelo de datos y las tablas que lo soportan. En mi opinión, debemos obligarnos a usar el lenguaje de negocio e ir, junto con el cliente, formando un "lenguaje ubícuo" común y que permita a todos los miembros del equipo tener una visión común del sistema.
Desarrollo incremental
Que la US sea tan sencilla es bueno porque siempre es mejor comenzar sencillo y luego ir añadiendo complejidades que no al contrario: comenzar complejo y luego ir simplificando. Es lo que se conoce como desarrollo incremental.
En esta historia NO vemos ni procesos de registro de usuarios, ni agrupación de productos por categoría, ni búsquedas por campos, ni ordenaciones, ni entramos en detalle sobre cuáles son las características de un producto. Mi consejo es: no entrad en profundidad aún, pero confirmad con el cliente que no vais a cubrir esas posibles expectativas en la primera iteración. Si no lo nombráis podría quedar en el aire dos interpretaciones diferentes de la misma historia: una muy sencilla (la de los técnicos) y otra muy compleja (la del cliente). Y esto, obviamente, no es bueno. Es mejor exponerlo y acordar el ámbito de la funcionalidad, intentando ir siempre a lo esencial, a lo que aporte valor de negocio inmediato para el cliente.
Pudiera ser que para el cliente fuera imprescindible que en la primera iteración se pudieran ver ya imágenes de los productos y el precio de los mismos. Si esto fuera así, reescribimos la US para que quede bien claro.
Como visitante de la tienda
Quiero ver todos los productos del catálogo
Para conocer sus características: nombre, breve descripción, precio y una imágen del mismo.
- ¿Sólo una imagen? ¿O más de una?
- ¡Ah! ¡Qué buena idea! No se me había ocurrido. Sí, también lo quiero. Varias imágenes.
- ¿Es imprescindible para la primera iteración?
- Bueno, no, pero estaría muy bien.
- Entonces, mejor escribamos otra US para eso.
Como visitante de la tienda
Quiero ver varias imágenes para los productos en el catálogo
Para conocer mejor los productos.
Como véis, del diálogo constructivo con el cliente nos han salido dos historias de usuario que podremos abordar por separado, posiblemente en iteraciones diferentes, con lo que las expectativas sobre el producto quedan más claras para todo el equipo (donde incluímos al cliente, por supuesto).
Valor de negocio
Llegados a este punto hay que tomar una decisión crítica (entre todos): ¿qué es más importante, ser capaz de filtrar los productos por algún criterio (funcionalidad de búsquedas), dar de baja un producto (funcionalidad de dar de baja) o modificar las características de un producto (funcionalidad de modificar). Es difícil dar un criterio porque dependerá de las necesidades del cliente, por eso es MUY importante discutirlo con él y que sea él el que priorice. Probablemente para nosotros sea más importante dar de baja, pero quizás al cliente le parezca más importante que los visitantes de la tienda puedan buscar los productos por algún criterio (quizás una categoría, cosa en la que no había pensado antes). O viceversa. :-)
A efectos prácticos, nosotros vamos a suponer que el cliente ha decidido que prefiere poder modificar, luego buscar y por último dar de baja.
Modificaciones
Una posible redacción de la historia de usuario a partir de la que implementaríamos las modificaciones de productos sería:
Como administrador del catálogo de productos
Quiero modificar cualquier característica de un producto dado
Para corregir algún posible error o un cambio en el producto (p.ej. el precio o la imagen).
Obviamente, para esto es necesario algún tipo de funcionalidad de búsqueda. Hay quien deja la historia de usuario tal cual y asume que ésta incluye esa funcionalidad de búsqueda (algunos hablan del patrón master-detail). Yo prefiero discutirlo con el cliente y extraer de ahí dos historias. ¡Cuidado! Ambas deben aportar algún valor de negocio. Por eso yo dejo la anterior tal y como la redactamos, pero añado otra específica para la localización del producto.
Como administrador del catálogo de productos
Quiero localizar un producto y ver el detalle del mismo
Para comprobar todas sus características.
Esencia de una entidad
Algo que me gustaría comentar llegados a este punto son las características esenciales de un producto. Deberíamos preguntar al cliente cómo se identifica a un producto unívocamente dentro del catálogo y si, una vez asignadas estas características esenciales, es posible cambiarlas. Hay gente que prefiere exponer los IDs empleados como claves primarias en la base de datos. A mi no me gusta esta práctica y prefiero orientar la discusión hacia el lenguaje de negocio, donde es posible que exista un identificador, un código de producto, un código de barras… algo que, en definitiva, ellos ya usen para identificar a un producto. Si no existe, tendremos que inventarlo, pero no me parece una buena práctica hacerlo coincidir con "mecanismos técnicos".
Otra cosa que podemos discutir aquí es qué características de un producto podrá ver un administrador del catálogo de productos que quedarán ocultas a ojos de un visitante.
Modificación = Baja + Alta
Una mala práctica creo que es el considerar que una modificación es una baja y a continuación un alta. Bueno, creo que esto sólo es lícito si en el negocio del cliente lo hacen exactamente así. Buscar un ejemplo para esto.
Registros de operaciones
Y finalmente, hay otro asunto que debería ser discutido: los registros de operaciones (audit logs). Normalmente todos los clientes quieren que quede constancia de quién y cuándo hizo cualquier modificación. Esto, dicho así en general, es un criterio tan amplio que puede requerir docenas de reuniones hasta poner a todo el mundo de acuerdo. Yo, personalmente, si la arquitectura de nuestra sistema no nos permite implementar esto fácilmente, optaría por identificar los casos más relevantes para el cliente, implementarlos ad hoc y negociar con el cliente el crear una infraestructura que permita generalizar estos casos para reducir el coste de desarrollo y mantenimiento del resto. Porque lo que es seguro es que habrá más.
En nuestro caso, dado que los clientes no realizan operaciones (de momento) sino sólo consultas, y que los administradores son pocos, cualificados y, muy importante, confiamos en ellos, no vamos a desarrollar ninguna historia de usuario para registrar sus actividades, pero no lo descartemos para el futuro. Debemos estar siempre alerta con este tema porque tarde o temprano sale a la luz y es conveniente estar preparado y no dejarlo para cuando sea demasiado tarde puesto que, cuando se decide abordar, es crítico.
Búsquedas
Antes de seguir me gustaría distinguir entre localizaciones y filtrados. Para mi no es lo mismo.
- Localización
- el objetivo es encontrar un objeto en particular.
- Filtrado
- el objetivo es segmentar (o incluso "ir segmentando") el total de los objetos, empleando para ello criterios basados en el valor de una o varias características.
Por supuesto, entre el negro y el blanco está el gris. Hay búsquedas como la siguiente que depende de la intención del usuario puede servir para una cosa u otra.
Poner un ejemplo de búsqueda alfabética por nombre, p.ej. Una imagen sería aun mejor.
Bajas
Aquí quiero hablar de la diferencia entre eliminar (para siempre) y dar de baja (marcar como inactivo). También habrá que tener en cuenta las razones por las que se da de baja un producto (p.ej. porque queda obsoleto, porque pasa a llamarse de otra manera ¿sería una modificación? o incluso porque se ha "fusionado" con otro). Esto son operaciones, cuyos eventos deberían ser registrados e incluso se podría querer deshacer…
