Dominio de los requisitos de Salesforce: Épicas, historias de usuario y criterios de aceptación

¿Te has preguntado alguna vez qué hace que un proyecto tenga realmente éxito? Imagínate lo siguiente: ¿Cuál es la mejor forma de controlar el progreso o de medir y planificar un proyecto de forma sencilla? Si ha pensado en las historias de usuario, va por buen camino. Sin embargo, en mi experiencia trabajando en proyectos de todos los tamaños, he observado un error común: a menudo no se presta a las historias de usuario la atención que merecen. Los equipos se las saltan y se lanzan directamente a diseñar soluciones o alaban un gran volumen de historias de usuario sin comprender realmente su importancia.

Es desalentador ver cómo se subestiman o sobrevaloran las historias de usuario. La verdad es que muchos pierden la marca en el uso de historias de usuario de la manera correcta y no logran conectar los puntos entre épicas, historias de usuario y criterios de aceptación. Es por eso que estoy escribiendo este artículo – para arrojar luz sobre el potencial bloqueado dentro de los proyectos y cómo la comprensión y el uso de historias de usuario estratégicamente puede hacer toda la diferencia.

Empecemos por examinar los elementos dentro del ámbito de las historias de usuario en un entorno de proyecto. Conectando los puntos, desentrañaremos sus relaciones y obtendremos una comprensión global.

Epics: Puesta en escena

Piensa en un proyecto de implantación como si estuvieras construyendo una casa, y definir las épicas es el paso inicial para sentar las bases de todo lo que viene después. En lugar de abordar todo a la vez, divídelo en diferentes partes o «ámbitos»

Cada ámbito es como un piso de la casa: una zona dedicada a tareas específicas, que llamamos épica en un proyecto. Este enfoque estratégico marca el comienzo, sentando las bases para todo el proyecto y asegurando una base sólida para el trabajo futuro.

El concepto

Una epopeya en el marco de un proyecto pretende establecer el escenario sin profundizar en los detalles. Piense en ella como la escena general que esboza el alcance y la dirección.

Una epopeya proporciona una visión amplia y de alto nivel, ofreciendo una escena guía para los diversos elementos que la componen. Es intencionadamente ligera en detalles, sirviendo como un concepto fundacional que une y dirige los elementos dentro de su ámbito.

Método y enfoque

La creación de epopeyas en un proyecto de Salesforce ofrece varios ángulos, lo que permite flexibilidad en función de los objetivos del proyecto. He aquí dos enfoques destacados que he adoptado a lo largo de los años:

Epics basados en áreas funcionales

Ejemplo: En una implementación de ciclo completo, como el despliegue de Sales Cloud, la elaboración de epopeyas en torno a áreas funcionales como la gestión de clientes potenciales, la gestión de cuentas y contactos, la gestión de oportunidades, la gestión de contratos, la gestión de previsiones y otras áreas clave es una estrategia común. Es como dividir el proyecto en partes diferenciadas, asegurando que cada aspecto crítico recibe la atención que merece.

Epopeyas basadas en personas

Ejemplo: Para iniciativas de optimización de plataformas más desestructuradas, estructurar las epopeyas en torno a personas a veces puede ser más eficaz. Cada persona – gerentes de ventas, representantes de ventas, equipos de marketing y operaciones – se convierte en una epopeya, agrupando desafíos únicos para sus necesidades. Este enfoque asegura una solución a medida, abordando los puntos de dolor específicos de los diferentes roles de usuario.

Aunque estos son enfoques comunes, la belleza reside en la personalización. Hay muchas otras formas de crear epopeyas; la clave es hacerlo teniendo en cuenta las dependencias y la viabilidad, asegurándose de que cada epopeya contribuye eficazmente al éxito del proyecto de Salesforce.

Historias de usuarios: Conceptualizando el propósito

Después de configurar la escena, nos centramos en lo básico dentro de ella, algo así como cuando planificas las habitaciones de una determinada planta. En el mundo de los proyectos, estas habitaciones actúan como espacios en blanco para propósitos específicos.

Piensa en la sala de estar como una historia de usuario: es como tener la idea de crear un lugar para relajarse después del trabajo (la idea), que te haga sentir física y mentalmente a gusto (el propósito). Esta historia de usuario nos da una imagen clara sin enredarnos demasiado en los detalles ‘nimios’.

El concepto

Las historias de usuario son como bloques de construcción en un proyecto, que expresan ideas y su propósito. Piensa en ellas como marcadores de posición: conceptos simples que responden a quién, qué y por qué. Son los narradores que te dan una imagen clara e ideas básicas sin complicarte demasiado. Las historias de usuario son los componentes principales en una imagen más amplia, ayudando a todos a entender la dirección y lo que estamos tratando de lograr.

Las historias de usuario suelen seguir un formato sencillo: «Como [la persona implicada], quiero [la acción prevista] para poder [la motivación subyacente]»

Creo firmemente en mantener las historias de usuario cortas y al grano. Deben construirse intencionadamente, ofreciendo suficiente amplitud para una narrativa completa sin detalles innecesarios. El objetivo es hacerlas extremadamente fáciles de leer, asegurando una clara comprensión de las necesidades y motivaciones del usuario sin abrumar a nadie con excesivas explicaciones.

Errores comunes

Declaraciones sobre-complicadas con explicaciones excesivas

Si estás explicando la acción con instrucciones o la intención con explicaciones, tu historia se vuelve menos legible y mezcla el concepto de criterios de aceptación con las historias de usuario.

Ejemplo: «Como representante de ventas, quiero navegar a la pestaña Oportunidad en la aplicación Salesforce, hacer clic en el botón Nueva oportunidad, rellenar los campos requeridos y, a continuación, hacer clic en el botón Guardar, de modo que se cree un nuevo registro de oportunidad en el sistema y esta oportunidad pueda asociarse a una cuenta existente, contribuyendo al pipeline general.»

Incorporar el diseño técnico al relato

Uno de los errores más comunes en los proyectos de Salesforce es incluir detalles técnicos en las historias de usuario. Las historias de usuario son para usuarios empresariales y representan requisitos conceptuales. Mencionar técnicos específicos mezcla el concepto de diseño de la solución con las historias de usuario.

Ejemplo: «Como agente de soporte, quiero crear un caso en Salesforce con una regla de validación que compruebe si el cliente tiene una membresía para que se mantenga el SLA con los miembros.»

Tener la misma acción y motivación intencionadas

Otro error común es tener la misma acción y motivación pretendidas, lo que indica una falta de descubrimiento adecuado de los puntos de dolor del usuario. Esto hace que las historias de usuario no sean comprobables y dificulta la medición del éxito del proyecto.

Ejemplo: «Como representante de ventas, quiero crear un nuevo lead en Salesforce para que el lead pueda crearse en el sistema.»

Método y Enfoque

Identificar y estructurar de forma eficiente las historias de usuario es crucial para el éxito de la gestión de proyectos. A lo largo de los años, he comprobado que estos enfoques son muy eficaces para organizar las historias de usuario en función de la naturaleza y los requisitos del proyecto:

Enfoque basado en el viaje del usuario

Adecuado para proyectos que implican un proceso de extremo a extremo dentro del alcance. Este enfoque está impulsado por diagramas, con procesos swimlane realizados para cada área funcional (epic). Cada elemento en el diagrama se traduce en una historia de usuario, por lo que es un método visual y organizado. Ideal para proyectos con posibles cambios de proceso en el futuro.

Enfoque basado en listas

Adecuado para proyectos de mejora o de servicios gestionados. Se enumeran los retos a los que se enfrentan las personas o los departamentos funcionales (épica), y cada reto se invierte en una motivación para una historia de usuario. Este método ayuda a formar indicadores de éxito precisos para el proyecto.

Enfoque basado en características

Adecuado para proyectos con mucho trabajo de front-end, como la implementación de Experience Cloud. Las historias se clasifican en partes de front-end y back-end para cada área funcional (épica). Ayuda a organizar las historias de forma lógica, lo que facilita la distribución de tareas entre el equipo en función de sus conjuntos de habilidades.

Criterios de aceptación: Traducir ideas en escenarios detallados

En nuestro ejemplo de la sala de estar, la historia de usuario describe quién (usted) hace qué (relajarse) con qué propósito (relajarse después de un largo día). Ahora, dentro de la historia de usuario, imagine los criterios de aceptación como las instrucciones detalladas: especificando cómo colocar los cojines, ajustar la iluminación y elegir música relajante.

En este escenario, las historias de usuario proporcionan el «qué» y el «por qué» (relajarse en el salón), y los criterios de aceptación dentro de ellas proporcionan el «cómo» (la guía paso a paso). Es como tener una lista de comprobación que vas marcando a medida que creas el ambiente perfecto. Las características cruciales de los criterios de aceptación son que deben ser comprobables y medibles, para garantizar que seguimos los pasos correctos en cada bloque de construcción relajante de nuestro proceso de desarrollo.

El concepto

Los criterios de aceptación son los narradores del proyecto, creando escenarios que nos guían hacia el objetivo de la historia de usuario. Cada escenario proporciona un ángulo único, ofreciendo un camino claro hacia el destino de la historia. Para ser eficaces, los criterios necesitan el contexto adecuado para poder ser probados. Están orientados a la acción y sirven como planos que describen «cómo» se desarrolla la historia. Al centrarse en acciones concretas, los criterios proporcionan un camino claro para el diseño y la comprobación de soluciones. Son los narradores que convierten una idea en una realidad funcional.

Mi estructura favorita es el formato «Dado… Cuándo… Entonces…». Aporta claridad a las pruebas y a la implementación.

• Dado: Piensa en «Dado» como el punto de partida. Es la condición inicial o el contexto antes de que algo suceda.
• Dado: Piensa en «Dado» como el punto de partida
• Cuando: representa la acción o el evento que pone todo en marcha.
• Cuando: representa la acción o el evento que pone todo en marcha
• Entonces: Define el resultado esperado

Juntos, crean una forma clara y estructurada de describir lo que queremos que ocurra en un escenario. Estos criterios sirven como brújula, guiando a los equipos de desarrollo y pruebas hacia la realización exitosa de historias de usuario y características. Es como contar una historia sencilla: primero, las cosas son así; después, ocurre algo; y, por último, esto es lo que esperamos ver como resultado.

Característica

Comprender las características de los criterios de aceptación es esencial para su uso efectivo en un proyecto. En mi opinión, los criterios de aceptación son la clave del éxito del desarrollo y las pruebas. Actúan como vínculo vital entre los objetivos de alto nivel del proyecto y el trabajo de base detallado. Cada parte del diseño de la solución comienza con los criterios de aceptación, convirtiendo conceptos abstractos en realidades concretas.

Del mismo modo, los planes de pruebas se derivan directamente de los criterios de aceptación, formando una lista de comprobación detallada para la validación. Debido a su papel central en el éxito del proyecto, crear y utilizar criterios de aceptación requiere un esfuerzo y una atención considerables.

Un error común que hay que evitar es vincular el diseño de la solución y los planes de prueba directamente a las historias de usuario. Esto a menudo conduce a desafíos en el rastreo y puede resultar en diseños o pruebas incompletas. Al centrarse en criterios de aceptación bien definidos, los equipos pueden evitar este escollo y garantizar una conexión perfecta entre los objetivos del proyecto y la implementación detallada.

Relevancia para los objetivos del usuario

Esta característica enfatiza la alineación de los criterios de aceptación con los objetivos del usuario final, asegurando que la funcionalidad implementada sea significativa para los usuarios. Alinear los criterios de aceptación con los objetivos del usuario establece un vínculo directo de vuelta al propósito esbozado en las historias de usuario y contribuye directamente a la definición de hecho (DoD).

Ejemplo: Dado un usuario en la página de restablecimiento de contraseña, cuando el usuario proporciona un nombre de usuario válido y hace clic en «Enviar», entonces un correo electrónico que contiene un enlace seguro de restablecimiento de contraseña debe ser enviado a la dirección de correo electrónico registrada del usuario.

Especificidad

La especificidad en los criterios de aceptación consiste en proporcionar directrices claras y detalladas sobre lo que se debe conseguir. Para mantener la especificidad en los criterios de aceptación, la clave es hacer especial hincapié en el resultado esperado en la parte «entonces». Esto implica proporcionar detalles meticulosos, garantizando la claridad sin dejar lugar a la ambigüedad.

Ejemplo: Dado un objeto personalizado de Salesforce, cuando un usuario crea un nuevo registro, entonces el campo Mes Creado debe calcularse y rellenarse automáticamente en función de los Datos Creados.

Posibilidad de prueba y medición

Esta característica es crucial para crear casos de prueba claros y eficaces, que permitan una evaluación muy objetiva de las características implementadas.

Para lograrlo, es esencial proporcionar instrucciones explícitas para cada acción, sin dejar lugar a confusiones. Al definir claramente los resultados esperados, se convierten en elementos tangibles de la lista de comprobación que pueden verificarse fácilmente, garantizando que se cumplen los criterios. Este enfoque no sólo agiliza el proceso de prueba, sino que también mejora la garantía de calidad general, permitiendo una evaluación sólida y objetiva del producto entregado.

Ejemplo: Dada una regla de validación de Salesforce, cuando un usuario intenta guardar un registro con un campo Email en blanco, el sistema debería mostrar un mensaje de error.

Completitud

La exhaustividad en los criterios de aceptación garantiza una cobertura completa de todos los aspectos dentro de una historia de usuario. Esto incluye una variedad de escenarios, abarcando tanto casos positivos como negativos.

Lograr la exhaustividad implica examinar los resultados tanto desde el punto de vista del éxito como del error. Al definir no sólo los escenarios positivos esperados, sino también considerar los posibles desafíos y desviaciones, los criterios de aceptación sirven como una guía completa para el desarrollo y las pruebas. Este enfoque minimiza el riesgo de pasar por alto funcionalidades críticas, fomentando una comprensión detallada de la historia de usuario y contribuyendo a su implementación con éxito.

Ejemplo: Dado un disparador Apex de Salesforce, cuando un usuario intenta eliminar un registro con registros hijos relacionados, entonces el sistema debería impedir la eliminación y mostrar un mensaje de error.

Resumen: Transformación de conceptos en elementos tangibles

La relación entre epopeyas, historias de usuario y criterios de aceptación puede conceptualizarse como una serie de marcadores de posición anidados. Las epopeyas representan el marcador de posición de más alto nivel, esbozando una amplia escena común. Las historias de usuario, un paso más detalladas, sitúan el propósito en el ámbito de la epopeya. Afinando aún más la narrativa, los criterios de aceptación sirven como marcadores de posición más detallados, definiendo el proceso de descubrimiento de acciones para construir un camino claro hacia el propósito previsto esbozado en las historias de usuario.

En esencia, se trata de una estructura jerárquica en la que cada nivel añade granularidad y especificidad, guiando el proceso de desarrollo desde los temas generales hasta las acciones detalladas necesarias para una implementación satisfactoria.