¿Cómo se puede aplicar ágil a las aplicaciones que implican un procesamiento complejo?

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).

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.

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. Ejemplos serían:

• Compiladores
• Sistemas de análisis de imágenes de automóviles sin conductor.
• Sistemas de simulación de flujo de fluidos

Aquí puede ser realmente difícil relacionar tareas e historias de usuarios. ¿Existen técnicas para superar este problema o es algo que tenemos que aceptar y aprovechar al máximo?

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.

Los principios ágiles ciertamente se pueden aplicar en estos casos. ¿Cómo?

• Los compiladores pueden tener nuevas características de lenguaje agregadas más adelante en historias de usuarios separadas
• Los sistemas de análisis de imágenes pueden tener nuevas características agregadas como diferentes clasificaciones de imágenes
• Los sistemas de simulación de flujo de fluidos pueden tener en cuenta diferentes aspectos del modelo en sus simulaciones

No tienes que comer todo el elefante de una mordida. Agile solo le pide que demuestre que ha limpiado su plato antes de la próxima porción de elefante.

Me parece que las personas que se adhieren estrictamente a las historias de los usuarios simplemente se involucrarán en un ejercicio muy tonto de encontrar formas descabelladas en las que los cambios técnicos de fondo afecten al usuario (sin que el usuario lo sepa, por supuesto, porque son solo algunos ingenuos usuario y usted está hablando de cambios complejos en su línea de análisis de datos o algo por el estilo) o simplemente estarán completamente perdidos por "¿cómo podemos organizar este trabajo?!"

Creo que la solución obvia es ser más pragmático. Si el trabajo es de naturaleza muy técnica y no tiene un impacto particularmente notable en el usuario, no pierda el sueño tratando de explicar cómo lo hace. Simplemente elija una forma obvia y simple en la que pueda beneficiar a los usuarios y luego oriente la historia en torno a los detalles necesarios para que los desarrolladores hagan su trabajo. Me resulta increíblemente frustrante cuando una OP insiste en no tener información técnica en la historia cuando es absolutamente necesario. Simplemente no es una visión muy holística de lo que realmente es ese artefacto (la historia). Como piensan que existe solo para ellos, en la mayoría de los casos también es importante para los ingenieros.

Para la mayoría de estas tareas técnicas, hay algo de poca importancia con respecto al impacto del usuario, ya sea mejorar la eficiencia para que las entregas futuras sean más rápidas, mejorando el rendimiento y la confiabilidad, etc. No son realmente lo que las personas tienden a pensar cuando piensan en "historias de usuarios", pero si la empresa quiere entender por qué asumiría una deuda técnica o algo por el estilo, entonces estas explicaciones suelen ser las más sencillas de proporcionar.

tl; dr no dejes que un scrumnazi te haga la vida más difícil simplemente porque es demasiado cuadrado para adaptarse. Ser adaptativo es un concepto central de ágil después de todo. La estricta adherencia a Scrum o Agile generalmente vuela en la cara o el pragmatismo y la practicidad (lo que realmente funciona mejor).

Creo que el problema es dar a las historias de los usuarios un significado que no tienen. Scrum usa el término PBI, o elemento de la cartera de productos, que creo que es infinitamente mejor. Los PBI a menudo seguirán un formato de historia de usuario, por ejemplo, puede tener un PBI como "Los suscriptores deberían poder ver sus detalles de suscripción", pero también podría tener un PBI como "Crear un procedimiento almacenado para obtener detalles del suscriptor" ".

Las historias de usuarios son una herramienta . Le ayudan a formar descripciones de características y requisitos basados ​​en ponerse en el lugar de un usuario. Pero, así como una llave inglesa es inútil cuando necesita colgar una imagen, hay momentos en los que es posible que no necesite una historia de usuario.

Dicho esto, muchos equipos en realidad solo juegan rápido y suelto con la parte de "usuario". Es posible que tengan "historias de usuario" como "Como desarrollador, necesito poder llamar a un procedimiento almacenado para obtener detalles del suscriptor", esencialmente una "historia de desarrollador" por así decirlo. Esta es una opción igualmente válida, pero personalmente, le digo que siempre que pueda describir lo que debe hacerse y proponer un conjunto de criterios de aceptación, apenas importa si tiene una historia de usuario real detrás o no.

Este tipo de aplicaciones son exactamente aquellas en las que existe una experiencia diferente y se desarrollará aún más. Los miembros del equipo tendrán una educación diferente, diferentes proyectos de pasatiempos y diferentes experiencias laborales pasadas, diferentes habilidades. Además, si alguien desarrolla un código en particular, se puede esperar que el desarrollador sea quien mejor conozca el código. Por lo tanto, podría tener sentido dar más tareas de desarrollo que involucren el mismo código al mismo desarrollador.

En el proceso ágil más popular, Scrum, hay planificación de póker donde cada tarea tiene asignado un nivel de dificultad. El nivel de dificultad no depende de la persona que realiza esa tarea de acuerdo con el proceso. Luego, durante el sprint, las personas se consideran homogéneas, por lo que se espera que cada persona pueda elegir cada tarea e implementarla. En proyectos simples como CRUD, esta suposición es válida. Pero en proyectos muy complejos y difíciles, ciertamente no.

No usaría un proceso ágil para este tipo de proyectos. Su mejor opción es evitar cualquier proceso formal y simplemente usar una buena gestión de proyectos. Al decidir quién implementa una característica en particular, considere quién tiene las mejores habilidades necesarias para esta característica y el mejor conocimiento del código existente. No se necesita ningún proceso para esto. Probablemente desee escribir buenos documentos de diseño para todas las funciones y mantenerlos actualizados. Tenga en cuenta que aquí no estoy promocionando un modelo similar a una cascada: los documentos de diseño no se escribirán todos al comienzo del proyecto; en su lugar, escribirá nuevos documentos de diseño a medida que se necesiten nuevas funciones.