Resultó ser más largo de lo que había planeado (había comenzado como un comentario), pero espero que la longitud / detalles agregados sean útiles y los encuentre justificados.
Agile no es específico para aplicaciones CRUD
La mayor parte de la literatura sobre ágil parece estar sesgada hacia las aplicaciones comerciales de tipo CRUD donde el usuario es bastante consciente de lo que está sucediendo detrás de escena. (Eso está bien porque la mayor parte del código que se está escribiendo probablemente pertenece a esta clase).
Creo que esto se debe a que es más fácil crear ejemplos de este tipo fáciles de seguir, no realmente porque la metodología esté dirigida a ese tipo de sistemas. Si crea un ejemplo no tan fácil de seguir, corre el riesgo de que el lector se quede atascado al tratar de entender el ejemplo cuando se suponía que su punto era enseñarle al lector acerca de conceptos ágiles.
User Stories! = Requisitos
Para este tipo de aplicación, la relación entre historias de usuario (requisitos) y tareas de desarrollo es en su mayoría sencilla: simplemente divida la historia de usuario en algunas tareas.
Una historia de usuario no es lo mismo que un requisito. Es cierto que puede haber cierta superposición dependiendo de cuán 'alto nivel' sea el requisito, pero generalmente no es lo mismo. Tengo la impresión de que te encuentras con el mismo escollo en el que cayeron muchos de mis ex gerentes: pensar en las historias de los usuarios simplemente como sinónimos de "requisitos", que es similar a cuando los usuarios de SVN intentan hacer la transición a Git, pero siguen pensando en términos de SVN. (Luego se topan con problemas debido a los supuestos de arranque incorrectos).
En mi humilde opinión, una diferencia clave entre los requisitos y las historias de los usuarios es que los requisitos especifican, en detalle, cómo deben comportarse ciertos componentes del sistema; son especificaciones que incluyen entradas, salidas, supuestos / condiciones previas, posibles excepciones planteadas, etc. Se centran en lo que hace el sistema .
OTOH, las historias de usuario se centran en el resultado esperado para el usuario final sin intentar crear una especificación de comportamiento detallada para los componentes del sistema. Se centran en la experiencia del usuario esperada .
Lo que solía hacer, y esta era una práctica que mi equipo adoptó, era dividir las historias de los usuarios en tareas. Sus tareas podrían ser tan específicas o vagas como quisiera / necesitara que fueran, pero estaban destinadas a ser sus indicadores de progreso para el trabajo real realizado para llevar la historia a un estado final.
Ejemplo
Recuerdo más o menos un EE. UU. En el que trabajé hace años, donde los usuarios necesitaban autoasignarse casos de prueba para que todos en el equipo supieran en qué CT estaban trabajando para evitar esfuerzos duplicados; la interfaz de usuario era una aplicación web (n interna). El usuario solo vio un botón, pero la historia se dividió en varias tareas que incluían algunos detalles de implementación técnica, etc.
Visibilidad del usuario
Pero hay otro tipo de aplicación donde la mayor parte del código tiene que lidiar con un procesamiento complejo que no es directamente visible para el usuario.
¿Es posible hacerlo visible para el usuario de alguna manera?
Considera un GPS. Cuando haya perdido su turno, no verá el proceso real de cálculo de ruta, pero el usuario recibirá algunos comentarios útiles (por ejemplo, "Recalculando ...").
Los compiladores pueden mostrar advertencias o errores, o incluir nuevas configuraciones / opciones en la GUI para que los usuarios vean que se ha agregado algo nuevo. Creo que los usuarios de compiladores serían programadores, ¿verdad? ¿No verían soporte para un nuevo estándar agregado?
Si bien el soporte de un nuevo estándar probablemente estaría en el nivel de la función y necesitaría desglosarse en historias de usuarios, ¿se ha asegurado de que, al menos en algunos casos, no esté tratando de usar historias cuando debería usar funciones en su lugar? ?
El análisis de la imagen en un automóvil podría expresarse de tal manera que el usuario sepa que las posibilidades de terminar en un accidente automovilístico se han reducido. Por ejemplo:
Como pasajero en un automóvil sin conductor, necesito la probabilidad de que el vehículo cause un accidente al chocar contra un objeto no reconocido para estar lo más cerca posible de cero, para que pueda viajar con mayor seguridad.
Que EE. UU. Captura, a un alto nivel, cosas que normalmente tendría que especificar utilizando una combinación de requisitos funcionales y no funcionales, incluyendo seguridad, etc.
Sin embargo, un requisito podría ser más sobre el sistema; p.ej:
La función abcen el componente Adebe tener el valor umbral de tolerancia disminuido en el algoritmo de comparación de imágenes para detectar mejor los objetos que se mueven lentamente.
Para mí, esto sería fácilmente una tarea en la historia del usuario que mencioné anteriormente, titulada algo así como: Disminuir la tolerancia en la funciónA.abc y luego incluir otros detalles relevantes en ella.
Para un sistema de simulación de fluidos, incluso podría tener una barra de progreso que proporcione comentarios sobre las tareas en segundo plano que realiza el sistema, si esto tiene sentido. (Siempre hay una manera de informar al usuario de algo, aunque es posible que desee evitar ser spam).
No sé lo suficiente sobre los dominios particulares que ha mencionado para obtener ejemplos mejores y / o más realistas, pero si hay una conclusión aquí es que puede usar diferentes formas para proporcionar comentarios de los usuarios sobre algo menos visible que el sistema podría estar funcionando, es decir, podría haber formas de hacer que las cosas invisibles sean un poco más visibles. (Incluso si todo se reduce a escribir un conjunto de notas de lanzamiento que documente qué tan rápido se debe ahora el rendimiento del sistema debido a sus esfuerzos, etc.)
Relación entre historias y tareas
Aquí puede ser realmente difícil relacionar tareas e historias de usuarios.
Nuestro enfoque consistía en mantener las historias de los usuarios centradas en cuál era la solicitud, por qué se hizo y qué cosas debían ser ciertas para considerar que EE. UU. Estaba "hecho". El cómo siempre se dejó fuera de los EE. UU. Y se dejó a los desarrolladores.
El desarrollador (s) se rompería el problema descrito en los EE.UU. en un conjunto de tareas que se podrían trabajar.
Lo digo como alguien que, en su mayor parte, realizó la programación del lado del servidor, lo que probablemente es tan "invisible" como puede ser para el usuario final.
Dependiendo de lo que tenía que hacer, a veces usaba AJAX para mostrar una simple animación / gif "cargando ..." para que el usuario supiera que tenía que esperar un poco para que se completara algo más, sin tener la impresión equivocada. A veces era tan simple como esto. Una tarea para esto sería apropiada.
Paradigma, práctica y experiencia diferentes
¿Existen técnicas para superar este problema o es algo que tenemos que aceptar y aprovechar al máximo?
Más allá de aceptar el cambio de paradigma, la práctica y la experiencia acumulada, probablemente no hay mucho más que decir. A menudo veía gente tratando de tomar atajos a través del proceso. Aconsejaría en contra de eso, especialmente si estás comenzando. A medida que adquiera más experiencia, puede permitir cierta flexibilidad, pero evite debilitarse.
Dada su redacción anterior, todavía está pensando en las historias como si fueran "requisitos renombrados", lo que creo que es una suposición falsa. Creo que este es un síntoma de un problema más profundo con respecto a las diferencias fundamentales entre los enfoques ágiles y no ágiles.
En segundo lugar, creo que debería aceptar que ágil es un cambio de paradigma en comparación con la cascada, lo que significa que, si bien el proceso tiene objetivos similares, lo hacen de maneras muy diferentes. (Piense en SVN vs Git, si eso ayuda).
Intente mejorar su comprensión actual de las diferencias conceptuales entre los requisitos y las historias de los usuarios y acepte que no son lo mismo.
Aprendiendo de tus Sprints - Retrospectivas
Lo que no puedo enfatizar lo suficiente es la retrospectiva entre Scrum Master y Developers al final de cada sprint. Ese es el lugar donde discuten las cosas que "salieron bien" o "no salieron bien" de una manera honesta / transparente, y qué cambios factibles se implementarán para el próximo sprint para abordar los puntos "no salieron bien" .
Eso nos permitió adaptarnos e incluso aprender de las experiencias de los demás, y antes de darnos cuenta, habíamos mejorado significativamente según lo medido por la consistencia general de la velocidad de nuestro equipo.