Me encuentro en un entorno no ágil donde "historia de usuario" en realidad significa "caso de uso, respaldado por una especificación de requisitos de Excel, un documento de especificación de prueba y algunos wireframes requeridos || maquetas incluidas". Quieren volverse ágiles. Si las voces en el oído del propietario del producto escuchan "historias de usuarios", no lo manejarán bien. "historia de usuario" tiene años de uso indebido aquí.
Pensé que esto sería un google rápido, ya que dudo que sea la primera persona en toparse con esto.
¿Cómo debo manejar el uso no estándar de "historias de usuario"?
Le advierto contra la introducción de nueva terminología, ya que confundirá a las personas que usan User Stories correctamente. A lo sumo, podría tratar de llamarlos "Historias de usuarios ágiles" (o Historias de usuarios de Scrum si está usando Scrum específicamente).
En cambio, le aconsejaría que trate de educar a aquellos que tienen una reacción instintiva sobre cómo se ha usado el término en el pasado, y trate de ayudarlos a comprender lo que significa seguir adelante.
Si no pelea esa batalla ahora, tendrá que lidiar con el impacto de la introducción de terminología no estándar en el futuro. (conseguir nuevas contrataciones que utilicen "Historias de usuarios" correctamente para comprender sus términos, hacer que su gente comprenda cualquier libro/blog/capacitación externo que haga referencia a "Historias de usuarios", tratar con clientes que entienden "Historias de usuarios" pero no saben qué significa su nuevo término, etc.).
No son historias de usuario. Los usuarios son solo un tipo de parte interesada.
Considere los cuadros CAPTCHA como ejemplo.
Como usuario
quiero llenar un cuadro de CAPTCHA
para que... espera, ¿qué? ¡No, no lo hago!
No se hace en beneficio del usuario. Hay un moderador del sitio en alguna parte que necesita esto para no tener que navegar manualmente a través de una tonelada de spam. Del mismo modo, existen algunos requisitos por seguridad, por motivos legales, por auditores, por anunciantes, por rendimiento, por otro sistema de terceros, o porque el sistema heredado con el que estamos hablando es un fastidio.
No estoy de acuerdo con Kyle. A veces se trata de los usuarios, pero a menudo de las partes interesadas cuyos objetivos deben cumplirse para que los usuarios obtengan algo. Los proyectos internos casi siempre tratan de brindar beneficios a otros usuarios y partes interesadas. Los he estado llamando "Historias de partes interesadas" durante un tiempo (aunque no son historias) y descubrí que este término ayuda a los equipos a reconocer quiénes son las partes interesadas reales. Por lo general, terminan refiriéndose a ellos como "historias", lo cual está bien para mí.
En mi experiencia, la pretensión de que las historias deben centrarse en los usuarios tiende a hacer que las necesidades de otras partes interesadas se rechacen o se traten solo como "Historias técnicas" que luego deben entregarse junto con otros como ciudadanos de segunda clase.
Pensar en el impacto comercial y las partes interesadas reales que necesitan dar su opinión puede ayudar mucho a abordar el riesgo del proyecto.
Por lo tanto, recomiendo que una historia sea una porción de una característica creada para obtener comentarios o ganar confianza, con el foco en la parte interesada a la que le importa. Me gusta la plantilla de inyección de características:
Para <lograr un objetivo>
Como <parte interesada que lo quiere>
quiero que < algunos usuarios hagan > < algo >.
Si no tiene la confianza de las partes interesadas, ofrézcales algo para demostrarles que puede progresar y gane su confianza. Si tienes su confianza, muéstrales algo que probablemente necesite sus comentarios. Probablemente será algo nuevo que no se haya probado antes (o que no haya sido probado por mucha gente).
Si haces eso, no importa cómo los llames. Pero preferiría que no involucrara el término "usuario" a menos que realmente lo signifique.
Es posible que desee considerar usar solo 'caso' ya que las personas en su empresa están familiarizadas con el término, pero solo redefinen lo que constituye un caso.
"Estamos cambiando la forma en que especificamos los casos" podría ser una venta más fácil que "dejaremos de hacer casos y haremos x".
Si cree que realmente necesita cambiar la terminología utilizada, uno de los siguientes podría funcionar.
Es cierto que la mayoría de estos se utilizan en algunos contextos ágiles, pero son tan generales que debería estar bien.
desafiar la gravedad