Historias de usuarios - Problemas que no se pueden hacer historias de usuarios

Question

Soy de un fondo de XP. Conozco el proceso muy bien y tengo una sólida experiencia de trabajo con él. He encontrado que es la mejor manera de desarrollar software.

Me encuentro en la posición de un médico de proceso y esto crea mucho autoexamen y revalorización de mi propia comprensión.

Una cosa muy común que escucho es que algunos trabajos no se pueden convertir en historias. Yo personalmente no creo esto Las excusas incluyen

1. Es demasiado grande (El desarrollador no tendrá nada que mostrar hasta el final de 5 semanas).
2. es un algoritmo complicado o un concepto abstracto (tomará 5 semanas para escribir y nada que mostrar).

Esta pregunta es para obtener consejos, consejos o sugerencias.

Estoy buscando consejos, consejos y sugerencias sobre cómo abordar estos y otros problemas percibidos similares (y más si puede pensar en ellos).

Voy a marcar la respuesta que tiene la mayor información sobre cómo evitar a los usuarios/desarrolladores que no escriben historias y abordar sus muchas excusas de por qué no (solo he enumerado algunas y hay muchas más).

Answer 1

Así que, básicamente, su pregunta es "¿Qué puedo hacer si la gente dice una tarea es demasiado grande para una historia de usuario, y no pueden ser divididos.

En mi experiencia, casi cualquier problema se puede dividir Pregunte si pueden implementar una versión simplificada, omita las funciones avanzadas, incluso puede usar valores predeterminados en algunos lugares, básicamente cualquier cosa para producir algo que dé resultados significativos (es decir, comprobables) en una iteración.

Recuerde: El punto de una iteración no es entregar una funcionalidad completa, sino solo una funcionalidad útil y comprobable.

Esta división puede ser difícil, pero te obliga a considerar lo que realmente necesitas primero, lo cual es muy valioso. Los desarrolladores pueden quejarse (a menudo yo mismo :-)), pero es realmente necesario. Desglose de grandes tareas en historias de usuario manejables es el corazón de todos los métodos ágiles.

Dicho esto, si la tarea realmente, realmente, realmente no puede ser procesado (pensar algoritmo matemático complejo en un contexto de investigación, que lleva semanas incluso comprender los fundamentos de), entonces su iteración es demasiado corto. La iteración debe ser lo suficientemente larga para producir resultados significativos. Y si la mayoría de tus problemas son tan difíciles que tardan entre 2 y 3 meses en hacer algo, entonces esa es tu longitud de iteración. Pero nunca he visto un proyecto en el que en realidad era el caso ...

Answer 2

El problema de "especificación algorítmica" es común.

Muchas personas prefieren escribir código y realmente no les importa quién es el usuario o lo que hace.

Intento que se concentren al hacer estas preguntas.

1. ¿Qué medida puede tomar la persona? ¿Qué podrían posiblemente hacer con la información? Si tienen alguna responsabilidad, pueden tomar medidas para denegar, aprobar, mantener, rechazar, reprocesar, detener, iniciar, algo. Si el usuario no puede realizar ninguna acción, debe preguntar si realmente son interesados.
2. ¿Qué decisión tienen que tomar? ¿Cómo deciden qué acción (si corresponde) tomar? No podemos automatizar esa decisión, es por eso que personas están en el circuito.
3. ¿Qué información necesita esta persona para tomar la decisión de tomar medidas?

Information-Decision-Action.

Solo escribimos software para preparar información para que las personas tomen decisiones para que puedan tomar medidas.

Si ese no es el enfoque, entonces las historias se saldrán de control. No se supone que

Answer 3

usuarios/desarrolladores que solía escribir historias

a los usuarios escribir historias de usuario. No se supone que te cuenten las historias de los usuarios. Puede esperar que hablen sobre cómo funcionan, los problemas que les molestan y lo que les gustaría tener para facilitar su trabajo diario.

Usted, a su vez, se supone que debe escucharlos y tomar notas. Si permiten, use una grabadora o una cámara. Luego, recupera la información recopilada cuando la reproduce e identifica lo que llama historias de usuarios. Discutes con el equipo y cuando tienes un acuerdo tienes casos de uso para apuntar en tu desarrollo.

El papel de los desarrolladores depende de ti. Si solo codifican, no participan en el proceso. Si en parte actúan como consultores, entonces ayudan a definir las historias de los usuarios.

Answer 4

Por lo general, cuando obtiene "es demasiado grande", lo que realmente dicen es "Solo tengo una vaga idea de cómo debería funcionar esto". Debe trabajar con ellos para definir mejor hasta que sea posible dividirlo en partes lógicas que puedan administrarse más fácilmente.

Answer 5

Éstos son algunos recursos que he recogido a través del tiempo y que pueden ayudar:

• Patterns for Splitting User Stories
• Story Weight Reduction Toolkit
• Twenty Ways to Split Stories
• Ways to split user stories

demasiado grande o demasiado com plicado, siempre hay una manera de poner una historia en la dieta (tal vez no obtendrá el resultado final en una iteración, pero esto no significa que no pueda y, bueno, habrá más de una iteración).

Answer 6

Es básicamente el deber y la responsabilidad del propietario del producto. Y puede haber requisitos/tareas que no puedan dividirse en User Stories. Encontré muchas de tales discusiones en SCrum Master Forums

Answer 7

Si el equipo de desarrollo afirma que la historia es demasiado grande y no cabe dentro del sprint ... tome su opinión y trate de dividir la historia con debe tener y es agradable tener tareas y tratar de dividirlo basado en eso.

verificación de este diagrama de flujo .. puede ser una ayuda: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf