Los elefantes no son jirafas y las historias de usuarios no son requisitos. Tienen características comunes y un contexto común, pero esto no los equipara. Sin embargo, muchos creen que las historias de usuario son una especie de nueva lectura de lo que tradicionalmente se llama requisitos de software; después de todo, debe haber requisitos en un proyecto, ¿verdad? Entonces, responderé: no, y nuevamente no . En primer lugar, estos no son requisitos y, en segundo lugar, los requisitos no son lo que realmente necesitamos. Las historias de usuario son, ante todo, una oportunidad para ver diferentes opciones de implementación, para que luego puedas aprovechar las oportunidades que se te han abierto. Y los requisitos ... es decidir todo de antemano, para que más adelante en esto se empantane.
¿Tiene algún sentido escribir un artículo así? ¿No parece obvio lo anterior? No, creo que declaraciones frecuentes como “requisitos en el backlog” indican que el paradigma del pensamiento sigue siendo el mismo, solo que las señales han cambiado. El documento de requisitos comenzó a llamarse backlog, los requisitos en sí mismos - historias de usuario, y ahora somos "ágiles" ...
Otro signo de posible malentendido es la práctica generalizada de almacenar historias de usuarios en la base de datos con la asignación de un ID único. Es posible que esto se haga solo por conveniencia, pero es posible que sea el resultado de una tendencia persistente a pensar en términos de requisitos.
Pero la práctica de incluir historias de usuarios en un contrato ya es una señal del 100% de que las historias de usuarios se están considerando como requisitos. El problema aquí es que una historia de usuario, por definición, no puede ser tan inequívoca como un requisito, y esto devalúa el contrato. Por supuesto, los requisitos a veces también se pueden interpretar con bastante libertad, pero la propia técnica de redactarlos implica inicialmente la eliminación de la ambigüedad, que no se puede decir sobre las historias de usuario. Además, los requisitos son resistentes a los cambios, ya que se incluyen en los contratos del proyecto. Para cambiar o agregar nuevos requisitos, deben pasar por el CCB . En otras palabras, las partes interesadas primero deben estar de acuerdo y aprobar. Consulte a continuación para obtener más detalles sobre los contratos.
Entonces, ¿qué son las historias de usuarios? Considérelos como una herramienta de planificación. Con la ayuda de las historias de usuario, priorizamos, evaluamos y decidimos en qué sprint se implementará la funcionalidad correspondiente. Todas estas son características típicas de una herramienta de planificación, así que no intente transformarlas en otra cosa.
El poder de las historias de usuario es que dan lugar al diálogo. En lugar de simplemente tomar y transmitir a los colegas una especificación, que es interpretada primero por los desarrolladores y luego por los evaluadores, comenzamos una discusión. Incluimos empleados con diferentes habilidades en comunicación. Y así, para cada nueva función.
Dado que la historia del usuario, como tal, no tiene mucho significado, podemos simplemente descartarla después de la implementación de la funcionalidad correspondiente. Si lo desea, puede mantener estadísticas cuidadosamente sobre el número de historias realizadas, pero esto puede ser bastante limitado.
¿Resulta que no necesitamos requisitos? De hecho, esto no es cierto. Después de todo, de una forma u otra existen limitaciones. Por ejemplo, el equipo médico debe cumplir con las regulaciones de la FDA . ¡Entonces llamémoslas restricciones!
Y, sin embargo, los requisitos describen el Sistema en detalle, ¿quizás haya algún valor en tal descripción para nosotros? Por ejemplo, ¿cómo podemos determinar si algún comportamiento del sistema es un error o no, si no tenemos requisitos formales presentados de una forma u otra? La técnica "Especificación por ejemplo" nos ayudará aquí. Entonces se decidió que se debería implementar alguna funcionalidad. Escribe reglas de negocio y una serie de ejemplos de tal manera que sea: a) fácil de leer; b) realizable. A partir de esta descripción, debe quedar claro lo que debe hacer el sistema. Y también, si algo sale mal como resultado de los cambios, la violación de qué regla comercial fue la causa de esta disfunción.
Como escribí anteriormente, la descripción del error debe ser simple y clara. Los errores son cosas que destruyen información y son malos independientemente de si tenemos una descripción de requisitos que cubre un caso determinado o no.
Contrato
(por Matthias Skarin)
Entonces, ¿qué vamos a usar en lugar de la especificación de requisitos? Después de todo, necesitamos entender si hemos implementado exactamente lo que se necesitaba. Usaremos contratos ágiles. Ágil: los contratos son una oportunidad para ver el bosque por los árboles, le permiten enfocarse en la esencia del proyecto y el logro conjunto del objetivo, cuya implementación satisfará las necesidades de los usuarios.
Ten en cuenta que cuando piensas en el contrato durante el proyecto para comprobar si tu pareja ha violado algo, esto ya significa que algo va mal. El contrato debe generar confianza entre las partes para que sea posible ir más allá de los detalles y no atascarse en ellos.
Resumen
- A pesar de que tanto el elefante como la jirafa tienen cuatro patas, son animales diferentes.
- Las historias de usuario no son requisitos, sino una herramienta de planificación.
- Lo más parecido a los requisitos es la especificación por ejemplo.