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

15

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 utilizar 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 con una estimación y desarrolle la historia. Asumen que un desarrollo ágil significa que las oraciones como esta son todo lo que tienen que proporcionar a los desarrolladores.

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

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

  
  • Necesitamos operadores booleanos como AND y OR.
  •   
  • Necesitamos una búsqueda aproximada y todos los términos.
  •   
  • Necesitamos buscar por palabras individuales y por frase.
  •   
  • No queremos encontrar productos que cumplan con 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, b y c.
  •   

Así que ya ves que no estoy hablando de detalles técnicos, diseño de software o incluso detalles de implementación. Son requisitos puros. Cuanto más hablamos, más se da cuenta el cliente de que en realidad hay mucho que decir sobre lo que quieren.

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

A veces, los gerentes incluso presentan detalles técnicos como "queremos que Lucene busque", pero no quieren pensar si solo buscan nombres de productos o también descripciones de productos. A veces pienso que son simplemente perezosos;)

Para mí, este es el principal problema en los proyectos en los que trabajo (aplicación web de e-business, 500-2000 días / persona por proyecto). He abordado este problema con la frecuencia suficiente, 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 de que los desarrolladores "siempre quieran tener todo lo especificado".

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

¿Tienes alguna referencia?

    
pregunta Wolfgang 09.05.2012 - 20:54

4 respuestas

8

Te estás perdiendo el punto de agilidad un poco. Lo que llama una historia de usuario, veo como al menos seis: una búsqueda básica y una para cada uno de sus puntos clave. De todos modos, haga planes suficientes para evitar pintarse en un rincón del que sea costoso salir, pero la idea general es que proporcione el mínimo necesario para entregar algo de valor y hágalo con la rapidez necesaria para obtener una respuesta rápida.

Al dividir una historia de esta manera, no solo hace que sea más fácil de estimar, sino que también permite al propietario del producto priorizar de una manera más detallada. Ciertamente, les gusta la capacidad de ordenar los resultados de la búsqueda, pero tal vez no sea tan importante como otro elemento del registro que no está relacionado con la búsqueda.

Además, sobre la idea de que los programadores necesiten todo lo especificado, intente verlo desde el punto de vista del cliente. Muchas veces, es como si fueras a comprar un auto, y el vendedor te pregunta qué color quieres para la perilla del limpiaparabrisas. Muchos de los detalles que podemos encontrar importantes son completamente irrelevantes desde el punto de vista del cliente. He trabajado donde los requisitos están muy sobre especificados, y créeme, no es muy divertido. El tipo de latitud de la que se está quejando, a muchos programadores les encantaría tener.

    
respondido por el Karl Bielefeldt 09.05.2012 - 21:31
6

Parece que el primer problema es que no debe 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 historia a menudo se ejecutan algo 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 - Entiendes esto, y puedes hacerlo rápidamente con poco riesgo de rebasamiento. 3 - Entiendes esto, pero puede haber una sorpresa o dos. 5 - Esto va a ser un poco de investigación, 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 cabrá en un sprint. Hay riesgo masivo. etc.

En general, cualquier historia de usuario que tenga un 8 o más debe dividirse 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 debes estimar el tiempo una vez que hayas aceptado la historia en el sprint, pero incluso así, hay menos énfasis en esto. La idea es que una vez que su equipo se acostumbre al proceso de señalar, puede medir su producción aproximada por sprint en puntos de historia y planificar de esa manera. No quieres planear en un plazo más corto que el sprint. La idea aquí es que si se desglosan las tareas correctamente para que las múltiples historias encajen en un sprint y estén en el rango de puntos de 1-5 historias, significa que están lo suficientemente definidas.

Además, parece que los PM de su empresa no entienden lo que 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 de forma inequívoca cómo se puede mostrar que se ha completado este almacenamiento. Idealmente, esto debería ser algo que sus muchachos de control de calidad hayan dicho "sí, podemos probar eso". Lo importante es que los PM deben entender que una historia de usuario está completa cuando el software cumple con los "criterios de salida". "Pero no queríamos eso" no lo corta. 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 PMs" aquí. Tienen que aprender que las historias vagas dan como resultado grandes puntos de historia, y que si definieron la historia de forma ambigua para obtener lo que quieren, tienen que hacerlo de nuevo.

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

Esto no es jugar al sistema ... esto es perfectamente válido. Si no sabes si es "A" o "B", estimas en función de cuál es el mayor estimado para cubrir tu trasero.

    
respondido por el Steven Burnap 09.05.2012 - 22:11
1

En mi experiencia, muchos de los cambios o proyectos en los que estoy trabajando tienen que ver con esto. Custom X quiere algo y tienen una idea de lo que quieren, pero solo te 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 cumplir con las demandas de los clientes y filtrar la información necesaria, al mismo tiempo que predice lo que REALMENTE va a querer el cliente o lo que realmente necesita.

Diga que un cliente (para mí) desea que una sección de nuestra aplicación web le devuelva una lista de todos los números de teléfono. Nunca especifican si significan físicos, lógicos, asignados a una persona o una 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 tendría que hacerle al cliente, como usted. Pero, como dices, eso no es posible. Es por eso que tener un buen departamento de servicios al cliente que conozca el producto y el cliente es invaluable.

Cuando ese tipo de llamada llega a los representantes de nuestros clientes, pueden explicarlo con el cliente, sabiendo lo que necesitan para pedirles 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 que pueden decir sí o no a algo sin siquiera preguntar al cliente.

Claro, tendrá muchos casos en los que el cliente seguirá necesitando algo más que usted y los servicios del cliente no pudieron ver, pero eso siempre va a suceder. Su objetivo, y el objetivo de los servicios al cliente, debe ser minimizar el tiempo de demora entre el desarrollo de algo y su devolución por parte 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 para mí donde estoy, pero tener una buena línea de comunicación y confianza con los representantes de sus clientes casi siempre lo ayudará por grado, y reducirá su frustración y aumentará la satisfacción del cliente. Además, puede dar un marco de tiempo más fácil para sus proyectos en lugar de encogerse de hombros y decir "No sé todo el alcance del proyecto, así que no sé cuánto tiempo tomará". Estamos teniendo 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 constante.

    
respondido por el CrystalBlue 09.05.2012 - 21:34
1

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.

  • Buscar productos
  • Ordenar resultado
  • Filtrar los resultados de la 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.

  • Buscar productos
    1. Tarea 1: Cambios en la base de datos
    2. Tarea 2: cambios del lado del servidor
    3. Tarea 3: Cambios en el front end

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 el trabajo pueda comenzar. 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 del curso):

Mesa de ayuda - > Propietario del producto - > Gerente de producto - > Líderes de departamento (desarrolladores senior, qa leads, etc.) - > Desarrolladores

Una vez que todos los actores relevantes han contribuido al proceso de análisis, podemos estimar cuánto tiempo nos llevará entregar la historia. El proceso de estimación que seguimos se basa en la velocidad y la experiencia de los desarrolladores individuales.

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

    
respondido por el CodeART 09.05.2012 - 21:07

Lea otras preguntas en las etiquetas