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

12

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?

Frank Puffer
fuente
66
No es el votante negativo, pero supongo que es porque la pregunta se basa en una premisa falsa. Los sistemas complejos IMO son aún más adecuados para un desarrollo de estilo ágil en virtud del hecho de que son más complejos. Cuanto más complejo sea el sistema, más probable es que tenga requisitos emergentes. Agile SwDev fue creado para manejar mejor los requisitos emergentes.
RubberDuck
44
@RubberDuck: "Asumiré que es porque la pregunta se basa en una premisa falsa": OMI, esto motivaría una respuesta en la que se explica la premisa falsa, no un voto negativo.
Giorgio
Si el uso comprende la lógica o no es totalmente irrelevante para el proceso ágil. Depende del equipo asignar una historia de usuario a una implementación Y estimar cuánto tiempo llevará eso. Si es complicado y / o requiere mucho trabajo, el equipo puede dividir la historia en otras más pequeñas. El tipo de lógica no importa.
Martin Maat
2
"La mayor parte de la literatura sobre ágil parece estar sesgada hacia las aplicaciones comerciales de tipo CRUD" - Y la mayoría de la literatura sobre Java parece estar sesgada hacia la impresión de la cadena "Hello World" en la consola (o computación alternativa del enésimo número de Fibonacci). Eso no significa que sea lo único para lo que Java es bueno. La razón es la misma en ambos casos: es difícil explicar ejemplos realistas en una publicación de blog o tutorial. [Nota: este es un comentario hiperbólico que intenta ilustrar la base de la premisa falsa.]
Jörg W Mittag
1
Agile no requiere tareas ni historias de usuarios. Puede usar cualquier forma de especificación que desee. Todo el punto es la flexibilidad.
Frank Hileman

Respuestas:

9

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.

code_dredd
fuente
"User Stories! = Requisitos": no quise decir que los dos son sinónimos. No todos los requisitos son una historia de usuario. Pero sí creo que todas las historias de usuarios son requisitos. Veo los requisitos como una estructura jerárquica donde las historias de los usuarios son un nivel específico de detalle. ¿Estarías de acuerdo?
Frank Puffer
@FrankPuffer Creo que ver historias de usuarios como si tuvieran un nivel diferente en una jerarquía de requisitos es básicamente mezclar diferentes conceptos. En el lado ágil, una jerarquía se parece más a: Temas >> Epics >> Features >> User Stories >> Tasks . Los requisitos generalmente se dividen en requisitos funcionales y no funcionales en el enfoque de cascada más tradicional, pero no he encontrado una jerarquía real; Dicho esto, no me sorprendería si alguien dividiera recursivamente un requisito en requisitos "sub" más pequeños. En cualquier caso, estás mezclando diferentes conceptos.
code_dredd
Los sistemas de gestión de requisitos como PTC Integrity tratan los requisitos como una jerarquía. Esto puede ser una ventaja al asignar requisitos a un documento de especificación.
Frank Puffer
@FrankPuffer Sí, por eso dije que no me sorprendería. Dicho esto, me pregunto si mi respuesta te ha aclarado algo. ¿Fue útil la analogía SVN vs Git? (Se supone que está familiarizado con ambos sistemas, lo que parecía razonable en un contexto de desarrollo de software)
Code_dredd
Ok, leí mal el "would" como "would". Y sí, encuentro su respuesta muy útil y probablemente la acepte. Probablemente solo necesite algo de tiempo para acostumbrarme a la idea de no considerar las historias de los usuarios como requisitos.
Frank Puffer
4

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.

naranja confitada
fuente
Aún así, creo que quedarán una o más historias de usuario que requieren muchas funciones básicas. A menudo no caben en un solo sprint. ¿Cómo debería ser manejado?
Frank Puffer
1
Usted mide el éxito con aplicaciones ejecutables que los clientes pueden probar, ver o tocar. Si ese es el caso, entrégueles un juguete que genere la sensación de progreso de esa manera. Por ejemplo, probablemente no puedas lanzar un auto sin conductor en el primer sprint, pero puedes hacer una demostración de cómo tu algo reconoce a las personas. Más tarde, cómo reconoce señales y animales. Más tarde, cómo mide distancias, tamaños, etc. El auto sin conductor está muy, muy lejos en un sprint remoto que quién sabe si alguna vez sucederá.
Laiv
2
@Laiv: Eso sería bueno, pero no estoy seguro si funciona. En parctice, después de los primeros sprints, el software no podrá hacer nada con lo que el cliente pueda relacionarse. Tendrá progreso técnico pero será difícil, si no imposible, comunicarlo al cliente.
Frank Puffer
2
¿Por qué? ¿Porque fue escrito en Stone por alguien ajeno a tu proyecto? Espero que Agile se adapte a mis necesidades, no de otra manera. Si digo que puedo enseñarte a patinar en 4 semanas y una vez el 5 sigues fallando en pararte, ¿eso significa que no estás aprendiendo a patinar? ¿O solo eso te llevará un poco más de tiempo? El manifiesto ágil no fue escrito en piedra ni las reglas de Scrum son los Mandamientos de Tendencia.
Laiv
2
El objetivo de los sprints es hacer que su cliente forme parte de sus iteraciones. Para comunicarse con ellos utilizando el código entregado. No planes y promesas. Requiere que te concentres en resolver el problema. No requiere que lo primero que entregue esté escrito en piedra. Requiere que demuestres que vales la pena pagar cada sprint.
candied_orange
1

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

evanmcdonnal
fuente
Estoy totalmente de ser flexible, pero francamente el usuario no se preocupa particularmente por los detalles técnicos, siempre y cuando sus historias se satisfagan. No tiene que ser "estrictamente ágil" para tener buenos requisitos; y por buenos requisitos, me refiero a los requisitos que van acompañados de una prueba de aceptación que demuestra inequívocamente que se cumple el requisito. Las personas que están "haciendo ejercicios muy tontos" obviamente lo están haciendo mal, pero eso no significa que estén siguiendo alguna noción de "scrum estricto".
Robert Harvey
@RobertHarvey Estoy de acuerdo en que los detalles técnicos son irrelevantes para el usuario, pero mi punto es que los artefactos que contienen historias de usuarios tienen un propósito más amplio que simplemente comunicar cómo funcionan las cosas para el usuario (o al menos deberían). ¿Cómo se hacen cumplir los requisitos relacionados con la arquitectura, la extensibilidad, el rendimiento, etc. si escriben historias puramente de usuario? Adoptar un enfoque de 'historia de usuario' puro incentiva a los desarrolladores a escribir código de baja calidad. Y no son los usuarios los que leen las 'historias de usuarios', sus desarrolladores y qa, es una tontería excluir deliberadamente información relevante porque es técnica.
evanmcdonnal
0

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.

Chris Pratt
fuente
1
No estoy de acuerdo con esto, excepto en casos muy extraños y raros. En Scrum, el CÓMO es competencia del equipo de desarrollo, no del propietario del producto. Sin embargo, el propietario del producto debe ser responsable de los PBI. Entonces, un PBI como "crear un procedimiento almacenado" le quita al equipo de desarrollo el derecho de elegir el CÓMO. Los PBI, ya sea que tengan una historia de usuario o no, deben explicar cuál es el valor comercial para hacer el PBI. Crear un procedimiento almacenado no se trata de valor comercial, se trata de detalles de implementación.
RibaldEddie
Ese no es el punto. Eso fue solo un ejemplo. Podrías simplemente cambiar el "procedimiento almacenado" a algo genérico como "un camino". El punto es que no necesariamente tiene que ser una historia de usuario.
Chris Pratt
El objetivo de un ejemplo es ser un ejemplo. Si su ejemplo "no es el punto", ¿cuál es el punto del ejemplo?
RibaldEddie
-3

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.

juhist
fuente
55
No está realmente relacionado con mi pregunta, pero siempre es peligroso dejar que el que tenga las mejores habilidades implemente una función. Impide la difusión del conocimiento dentro del equipo. Si se requiere mantenimiento y el experto ha abandonado el equipo o no está disponible temporalmente, tendrá problemas.
Frank Puffer
@FrankPuffer Para algunos de los tipos de sistemas que usted enumeró, por ejemplo, autos sin conductor, si el experto abandona el equipo, usted está en problemas. Período. Si bien probablemente no sea el caso que la codificación deba centralizarse, también es completamente irracional suponer una "difusión de conocimiento" adecuada para permitir el reemplazo del experto en una escala de tiempo razonablemente corta. Estas son personas que habrán pasado más de una década investigando el problema, y ​​presumiblemente están cerca de la parte superior de su campo en él. Probablemente necesitará varias personas como esta con diferentes habilidades. Tales proyectos son inherentemente riesgosos.
Derek Elkins dejó SE