02 Abr ¿Cómo definir los requerimientos para mi ERP?
Es habitual que el trabajo diario con tu ERP motive sugerencias de mejoras para ganar en agilidad y automatización. Ahora bien, es muy importante como transmites estos requerimientos a tu partner para no incurrir en desarrollos innecesarios. En este sentido, a lo largo de los años nos hemos encontrado con clientes que, en lugar de expresar una necesidad o un problema a solucionar, intentan brindar una solución.
En TRIANGLE trabajamos con metodología SCRUM y, por este motivo, recomendamos utilizar las historias de usuario en estos escenarios.
¿Qué son las historias de usuario?
Las historias de usuario (user stories en inglés) son descripciones cortas y simples de una funcionalidad/característica/requerimiento contada desde la perspectiva del usuario que desea la nueva capacidad.
Suelen ser una simple frase o una breve descripción de la funcionalidad. Sin entrar en detalles. Esto es así porque si estas user stories no son prioritarias se almacenan en el backlog y se planteará trabajar en ellas en un futuro. Serán el Product Owner (PO) y el equipo quienes priorizarán las historias de usuario a llevar a cabo en función de los objetivos que se busque conseguir en cada sprint.
Con las historias de usuario conseguimos centrarnos en lo que es realmente prioritario para el proyecto sin olvidar otras necesidades.
¿Cómo escribir una buena historia de usuario?
Lo primero que debemos tener en cuenta a la hora de escribir una historia de usuario es el nivel de detalle al que queremos llegar. Existe la posibilidad de escribir una user story que cubra una funcionalidad o requerimiento muy grande. A estas user stories se las conoce como “épicas”. Eso sí, aunque el requerimiento sea épico, tendremos que dividirla en varias historias de usuario más pequeñas para que pueda trabajarse en cada una de ellas individualmente.
No entraremos en el detalle de cómo podemos agregar detalles a las historias de usuarios, ya sea por división del requerimiento o por la adición de condiciones de satisfacción. Nos centraremos en cómo escribir una buena historia de usuario.
Lo fundamental que siempre debes tener en mente es la siguiente estructura:
Como <tipo de usuario>, quiero <algún objetivo> para <algún motivo>
- Como: define el rol o la persona que va a beneficiarse de esta funcionalidad.
- Quiero: define la acción u objetivo a conseguir. En este punto es esencial que describas qué es lo que el usuario quiere hacer. Como ya hemos mencionado anteriormente, no debes incluir el cómo. El cómo será el partner quien lo aporte con su know how.
- Para: define el motivo por el cual el usuario necesita este cambio. Permite entender qué busca realmente el usuario.
Por ejemplo, en el contexto de Dynamics NAV / Business Central podríamos decir:
Como | quiero | para
De esta forma, el partner que reciba el requerimiento podrá pensar cuál es la mejor solución para dar respuesta a esta necesidad. Como partners nos interesa entender cuál es la necesidad del usuario, sin tener preconcepciones para buscar así la mejor solución y más innovadora.
Por otro lado, para redactar una buena historia de usuario podemos seguir los criterios que recordamos bajo el acrónimo de INVEST. Si la historia no cumple uno de estos criterios, el equipo debería considerar reformularla o, incluso, dejarla fuera del listado de requerimientos.
- “I” – Independiente: de todas las demás. Para poder facilitar así la priorización.
- “N” – Negociable: el resultado final surge de la colaboración no se trata de un contrato cerrado.
- “V” – Valiosa: es imprescindible que aporte valor al usuario
- “E” – Estimable: en cuanto al abasto del requerimiento.
- “S” – Small (pequeña): para poder llevarse a cabo en un sprint.
- “T” – Testeable: debe poder hacer un test para validar que cumple con las necesidades.
¿Qué existe después de la redacción de una historia de usuario?
Si hemos redactado nuestra user story ya hemos completado el primero de 3 pasos, concretamente el que se conoce como Tarjeta. Este requerimiento conformará el backlog de ideas que el PO y el equipo priorizarán.
Por este motivo, el siguiente paso es la Conversación. Cuando se decide priorizar una historia de usuario es necesaria una conversación entre PO y el equipo para aclarar posibles dudas.
Por último, llega la Confirmación, en la que el PO capturará los criterios a tener en cuenta para asegurar que la historia de usuario cumple con todas las expectativas.