¿Cuántos detalles sobre una historia de usuario puede esperar un desarrollador?

El mayor inconveniente del desarrollo ágil que he experimentado es que las personas que no participan en el desarrollo se centran en el mantra de que una historia de usuario (3-10 días de persona ideal) no debe contener más de 1-3 oraciones como:

Como cliente, puedo usar la búsqueda de texto libre para encontrar los productos que estoy buscando.

Al dar esta frase, los gerentes de proyecto esperan que yo, como desarrollador, me comprometa a hacer una estimación y desarrollar la historia. Asumen que el desarrollo ágil significa que oraciones como esta son todo lo que tienen que proporcionar a los desarrolladores.

No los culparé porque la literatura bien conocida sobre el desarrollo ágil crea la impresión de que esto realmente funcionaría. He leído algo así como 2 páginas en lenguaje natural por historia en "Planning XP", pero eso es todo. Debido a que se prefiere el "software de trabajo" sobre la "documentación exhaustiva", este tema parece ser generalmente evitado.

La realidad es, por supuesto, que si el desarrollador tiene la oportunidad de hacerlo, una entrevista con el cliente presenta una larga lista de requisitos que el cliente tiene sobre la historia:

• Necesitamos operadores booleanos como AND y OR.
• Necesitamos búsqueda difusa y todos los términos.
• Necesitamos buscar por palabras individuales, así como por frase.
• No queremos encontrar productos que cumplan los criterios X, Y y Z.
• Queremos ordenar el resultado. Ah, y por cierto, el usuario puede seleccionar los criterios de clasificación en un cuadro combinado con las opciones a, by c.

Entonces ves que no estoy hablando de detalles técnicos o diseño de software o incluso detalles de implementación. Es puro requisito. Cuanto más hablamos, más se da cuenta el cliente de que en realidad hay mucho que decir sobre lo que quiere.

Pero a menudo me encuentro en la situación de que esa información no se proporciona o de manera muy mala. Tampoco es posible que yo haga la entrevista, ni la persona que estaría en condiciones de hacer la entrevista me proporciona un resultado.

A veces, los gerentes incluso presentan detalles técnicos como "queremos la búsqueda de Lucene", pero no quieren pensar si solo quieren encontrar nombres de productos o también descripciones de productos. A veces pienso que son flojos;)

Para mí, este es el tema principal en los proyectos en los que trabajo (aplicación web de comercio electrónico, 500-2000 días de persona por proyecto). He abordado este problema con bastante frecuencia, y los gerentes son conscientes de que la mayoría de los desarrolladores tienen un problema con la situación. Pero creen que los desarrolladores son demasiado "perfeccionistas". Parecen molestos porque los desarrolladores "siempre quieren tener todo lo especificado".

Debido a la falta de números generalmente reconocidos, es difícil discutir. Todo el mundo sabe cuánto debe durar una iteración. Pero nadie puede decir cuántos requisitos se necesitan para estimar y desarrollar una historia.

¿Tienes alguna referencia?

Te estás perdiendo el punto de agilidad un poco. Lo que llama una historia de usuario, lo veo como al menos seis: una búsqueda básica y una para cada uno de sus puntos. Por supuesto, haga suficientes planes para evitar pintarse en una esquina de la que será costoso salir, pero la idea es que proporcione el mínimo necesario para entregar algún valor, y hágalo lo suficientemente rápido como para obtener comentarios rápidos.

Cuando divide una historia así, no solo hace que sea más fácil de estimar, sino que le permite al propietario del producto priorizar de una manera más precisa. Ciertamente, les gusta la capacidad de ordenar los resultados de búsqueda, pero tal vez no sea tan importante como otro elemento en la cartera de pedidos que no está relacionado con la búsqueda.

Además, con la idea de que los programadores necesitan todo lo especificado, trate de verlo desde el punto de vista del cliente. Muchas veces, es como si fuera a comprar un automóvil, y el vendedor le pregunta qué color quiere para la perilla del limpiaparabrisas. Muchos detalles que podríamos encontrar importantes son completamente irrelevantes desde el punto de vista del cliente. He trabajado donde los requisitos están muy especificados, y confía en mí, no es muy divertido. El tipo de libertad por el que te estás quejando, a muchos programadores les encantaría tener.

Parece que el primer problema es que no debes aplicar estimaciones de tiempo a las historias de los usuarios. Se supone que debes tomar una historia y aplicar "puntos de historia", que son una estimación general de la complejidad desde 1 hasta INFINITY. Los puntos de la historia a menudo se ejecutan como 1,2,3,5,8,13,20 ... (Cada organización tiene sus propias reglas). Generalmente aplican algo como:

1 - Puedes hacerlo mientras duermes y no vale la pena implementarlo. 2 - Entiende esto y puede hacerlo rápidamente con poco riesgo de desbordamiento. 3 - Entiendes esto, pero puede haber una sorpresa o dos. 5 - Esto va a investigar un poco y tiene una pequeña cantidad de riesgo. 8 - Esta es una tarea grande, necesita mucha investigación y puede no encajar en un sprint. 13 - Esto es enorme, y definitivamente no cabe en un sprint. Hay un riesgo masivo. etc.

En general, cualquier historia de usuario que sea un 8 o superior debe desglosarse en historias más pequeñas.

Si no tiene la información para hacer esto, definitivamente debe devolverla al gerente del proyecto y decir que necesita más información.

Realmente solo deberías estimar el tiempo una vez que hayas aceptado la historia en el sprint, pero aun así, hay menos énfasis en esto. La idea es que una vez que su equipo se acostumbre al proceso de apuntar, puede medir su salida aproximada por sprint en los puntos de la historia y planificar de esa manera. No debes planear en una escala de tiempo más corta que el sprint. La idea aquí es que si está desglosando las tareas correctamente para que las múltiples historias encajen en un sprint y estén en el rango de puntos de 1-5, significa que están lo suficientemente bien definidas.

Además, parece que los PM de su empresa no entienden qué es una "historia". Una parte crítica de una "historia de usuario" es el criterio de salida. El criterio de salida es una o dos oraciones cortas que describen inequívocamente cómo se puede demostrar que este almacenamiento se ha completado. Idealmente, esto debería ser algo que sus chicos de control de calidad hayan dicho "sí, podemos probarlo". Lo importante es que los PM deben comprender que una historia de usuario está completa cuando el software cumple con los "criterios de salida". "Pero no queríamos eso" no es suficiente. Si no querían lo que se entregó, pero coincidía con los criterios de salida, tienen que ingresar una nueva historia.

Ciertamente hay un elemento de "entrenamiento de los PM" aquí. Tienen que aprender que las historias vagas resultan en grandes puntos de historia, y que si definieron la historia de manera ambigua para obtener lo que quieren, tienen que volver a hacerlo.

Obviamente, si las partes interesadas no están reuniendo suficiente información, entonces tiene que hacerlo, y si tiene que hacerlo, entonces eso es mucho más trabajo, ¿no? Mucho antes de mis días ágiles, tuve éxito al dar estimaciones muy grandes y decir explícitamente que las estimaciones eran tan grandes para permitir el riesgo causado por la falta de información. Tuve que asumir el peor de los casos para todas las preguntas, y lo estimé con base en este peor de los casos. Descubrí que los gerentes estaban más dispuestos a dar más detalles cuando lo vieron, lo que provocó que las estimaciones cayeran.

Esto no es jugar con el sistema ... esto es perfectamente válido. Si no sabes si es "A" o "B", calculas en base a cuál da la estimación más grande para cubrir tu trasero.

En mi experiencia, muchos de los cambios o proyectos en los que estoy trabajando lidian con esto. Custom X quiere algo y tienen una idea de lo que quieren, pero solo le dan un pequeño correo electrónico de requisitos. Esto se debe principalmente a que el cliente no sabe "exactamente" lo que quiere. Es por eso que la mayor parte del trabajo de nuestro departamento de servicio al cliente es desarrollar esas demandas de los clientes y filtrar la información necesaria, al tiempo que predice lo que el cliente REALMENTE va a querer o lo que realmente necesita.

Digamos que un cliente (para mí) quiere que una sección de nuestra aplicación web les devuelva una lista de todos los números de teléfono. Nunca especifican si se refieren a físicos, lógicos, asignados a una persona o ubicación, etc. Simplemente quieren todos los números de teléfono. Como desarrollador, puedo sentarme allí y pensar en una docena o más de preguntas que necesitaría hacerle al cliente, al igual que usted. Pero, como dices, eso no es posible. Es por eso que tener un buen departamento de servicios al cliente que conoce el producto y el cliente es invaluable.

Cuando ese tipo de llamada llega a los representantes de nuestros clientes, pueden elaborarlo con el cliente, sabiendo lo que necesitan hacerles para que respondan las preguntas correctas. También tienen la previsión de saber lo que el cliente ha pedido en el pasado y saben lo suficiente sobre los sistemas que desarrollamos para poder decir sí o no a algo sin siquiera preguntarle al cliente.

Claro, tendrá muchos casos en los que el cliente aún necesitará algo más que tanto usted como los servicios al cliente se perdieron, pero eso siempre va a suceder. Su objetivo, y el objetivo de los servicios al cliente, debe ser minimizar el tiempo de retraso entre el desarrollo de algo y la recuperación del cliente con los cambios que deben realizarse. Y esto se reduce a la comunicación y la capacitación con los servicios de sus clientes.

Tal vez no sea tan factible para usted como donde estoy yo, pero tener una buena línea de comunicación y confianza con los representantes de sus clientes casi siempre lo ayudará gradualmente, y reducirá su frustración y aumentará la satisfacción del cliente. Además, puede dar más fácilmente un marco de tiempo para sus proyectos en lugar de encogerse de hombros y decir "No conozco el alcance completo del proyecto, así que no sé cuánto tiempo llevará". Tenemos el mismo problema aquí, y una mejor comunicación y capacitación es lo que nos ayuda a crear plazos razonables y cumplirlos de manera consistente.

Cliente

Quiero buscar productos

Gerente de producto He analizado la historia del cliente y se me ocurrieron los siguientes requisitos. Cada requisito se ha registrado como una historia de usuario separada.

• Busca productos
• Ordenar resultado
• Filtrar resultados de búsqueda

Desarrollador He recibido historias de usuarios de un gerente de producto. He analizado cada historia de usuario y se me ocurrió una lista de tareas para cada historia de usuario.

• Busca productos
  1. Tarea 1: cambios en la base de datos
  2. Tarea 2: cambios del lado del servidor
  3. Tarea 3: cambios frontales

El cliente, el gerente de producto y el desarrollador son todos los interesados ​​en este proceso. Todos deben contribuir al proceso de análisis antes de que pueda comenzar el trabajo. Tenga en cuenta que este es un ejemplo muy simplificado.

Nuestras historias de usuario se analizan y refinan en el siguiente orden (con algunas variaciones, por supuesto):

Mesa de ayuda -> Propietario del producto -> Product Manager -> Responsables de departamento (desarrolladores senior, qa leads, etc.) -> Desarrolladores

Una vez que todas las partes interesadas relevantes hayan contribuido al proceso de análisis, podemos estimar cuánto tiempo nos llevará presentar la historia. El proceso de estimación que seguimos se basa en la velocidad y la experiencia de los desarrolladores individuales.

No digo que esta sea una forma correcta de hacer las cosas, pero funciona muy bien dentro de nuestra organización.