Ágil: ¿qué estamos haciendo mal?

Soy desarrollador de un equipo ágil y tratamos de usar Scrum.

Así que pondré aquí un problema hipotético para ilustrar la situación.

Tenemos una aplicación muy antigua, que utiliza un código JQuery desordenado y de mal mantenimiento. También tenemos partes de la aplicación que usan React, y esas partes son mucho más fáciles de actualizar / mantener. Además de eso, el objetivo de la compañía es crear una aplicación de una sola página para el cliente, en React, por lo que usar JQuery te aleja más de eso.

Cuando hacemos la planificación, siempre buscamos la solución fácil en términos de tiempo de desarrollo, por lo que, por ejemplo, si estamos creando un nuevo diálogo o algo así, usamos el viejo JQuery porque es más rápido y decimos que volvemos más tarde para ordenar y transformar en React, pero eso rara vez sucede.

Obtenemos los requisitos de lo que tenemos que hacer de las historias de los usuarios (que están bien hechas en la OMI, son escasas pero explican lo que estamos haciendo y por qué lo estamos haciendo).

A veces, los requisitos de las nuevas funciones son muy escasos, por lo que, por ejemplo, si un requisito dice "crear un diálogo que cargue toneladas de contenido" pero no dice implementar una función de carga, en la mayoría de los casos, no la implementaremos , a pesar de que todos sabemos que sería mejor para los clientes, con la razón de que esto podría comprometer nuestro objetivo de sprint (aunque personalmente creo que no lo haría).

El resultado es que nuestra base de código es un gran desastre con una capacidad de mantenimiento muy mala, y las nuevas características a veces son muy pequeñas y requieren un sprint completo (algo que podría lograrse en un solo día en una buena base de código) principalmente debido a este desarrollo estrategia, solo ve rápido, haz lo mínimo.

En este caso, ¿qué estamos haciendo mal? ¿Deberíamos abordar las soluciones de una manera más completa para no estar siempre escribiendo código incorrecto y reescribiendo el código que acabamos de escribir la semana pasada? ¿O deberíamos seguir haciendo eso solo asegurándonos de que todo ese código se está reescribiendo? ¿Cuál sería un buen enfoque ágil para este problema?

Esto no tiene nada que ver con Agile o Scrum.

El problema con la "cinta adhesiva ahora y lo arreglaremos más tarde" es que más tarde nunca llega y, mientras tanto, está acumulando una gran cantidad de deuda técnica .

El primer paso para la recuperación es reconocer el problema y dejar de empeorarlo.

Para cada nueva historia de usuario, el equipo debe considerar "¿cuál es la forma correcta de codificar esto?", No "¿cuál es la forma más rápida de hackear esto?" y planifique los sprints en consecuencia.

Para solucionar el problema existente, vea las excelentes respuestas a Heredé 200,000 líneas de código de espagueti. ¿Y ahora qué?

Lo que tienes allí es lo que Martin Fowler llama "scrum flácido".

Si lees correctamente los 12 Principios detrás del Manifiesto Ágil , descubrirás que fallas en la mayoría de ellos.

Entregue software de trabajo con frecuencia, desde un par de semanas hasta un par de meses, con preferencia al menor tiempo.

¿Puedes decir que entregas un software que realmente funciona? ¿O simplemente un software que apenas funciona?

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.

¿Puedes decir que tu proceso es sostenible? ¿Tomas decisiones teniendo en cuenta la sostenibilidad? ¿O elige soluciones que resuelven el problema actual sin tener en cuenta los efectos a largo plazo?

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

El principio verdaderamente mayor. Creo que esto se debe poner en GRANDES LETRAS ROJAS en la página. Aquí es donde más fallas.

A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego ajusta y ajusta su comportamiento en consecuencia.

Y lo más obvio. Si descubre que su comportamiento no está conduciendo a los resultados deseados, debe cambiarlo. Si su equipo no puede ver que tiene problemas, entonces no puede comenzar a solucionarlos.

De tu comentario

¿Cómo prevenir eso en ágil?

Primero, aprendiendo lo ágil que es en realidad. Scrum no es ágil. Algunos dirían que Scrum es el peor de los marcos ágiles, ya que es demasiado fácil llegar a su situación exacta. Debería aprender sobre otros marcos ágiles. El que recomendaría es la programación extrema. Lo que claramente resuelve tus problemas. Las soluciones no son simples (se centran en la excelencia técnica a través de pruebas automatizadas robustas, programación de pares y entrega continua), sino que son altamente efectivas. Como se informó en el informe del estado de DevOps .

Lo que usted describe es, al menos en mi experiencia, un patrón emergente bastante común de equipos que intentan "ser ágiles". Está abierto a debate si esto es realmente parte de Agile en sí mismo o una implementación errónea común del mismo, está en contra del manifiesto / principios ágiles o una consecuencia inherente del mismo, y así sucesivamente. Solo desde un punto de vista empírico y basándome en mi propia pequeña muestra de experiencia (y las personas con las que hablo), si un equipo es ágil, parece tener una probabilidad mayor que la media de encontrarse con este patrón. Dejémoslo así y centrémonos en su ejemplo concreto.

Hay dos aspectos separados de lo que describe:

• Falta de comprensión / visión común y, por lo tanto, no es eficiente
• Cómo medir el éxito / progreso y el costo total

Ir por el camino equivocado o correr en círculos

En mi experiencia, la razón principal para que esto suceda es que, en un intento de producir código rápidamente, los equipos rechazan activamente los casos de uso o requisitos que ya conocen o que podrían descubrir fácilmente. Piénselo de esta manera: hace 10-20 años, las personas intentaron escribir especificaciones gigantes y pensar en todo de antemano y con frecuencia fallaron. O tardaron demasiado o pasaron por alto algo. Uno de los aprendizajes del pasado es que en el desarrollo de software hay cosas que no puedes saber y las cosas cambian mucho, de ahí la idea de iterar rápidamente y producir algo de salida sensible rápidamente. Lo cual es un muy buen principio. Pero hoy, estamos en el otro extremo: "No me importa esto porque es parte del próximo sprint" o "No presento ese error, lo soluciono cuando vuelve a aparecer".

1. Reúna todos los casos de uso de alto nivel , requisitos, dependencias y restricciones que pueda encontrar. Póngalo en una wiki para que todos los interesados ​​y desarrolladores puedan verlos. Agréguelos cuando surja algo nuevo. Hable con sus accionistas y usuarios. Use esto como una lista de verificación mientras desarrolla para evitar la implementación de cosas que no contribuyen al producto final o son soluciones / hacks que resuelven un problema pero causan tres nuevos.
2. Formular un concepto de alto nivel . No me refiero al diseño de interfaces o clases, sino que esbozo el bosquejo del problema. ¿Cuáles son los principales elementos, mecanismos e interacciones en la solución final? En su caso, debería ser obvio cuando se utiliza la solución jquery-workaround como un paso intermedio y cuando solo causa trabajo adicional.
3. Valide su concepto utilizando la lista que recopiló. ¿Hay algún problema obvio en ello? ¿Tiene sentido? ¿Hay formas más eficientes de lograr el mismo valor de usuario sin causar deudas tecnológicas a largo plazo?

No te excedas. Solo necesita algo para que todos en el equipo (incluidos los que no son desarrolladores) tengan un entendimiento común sobre cuál es el mejor camino hacia su MVP. Todos deberían estar de acuerdo en que no hay descuidos obvios y que realmente podría funcionar. En general, esto ayuda a evitar caer en callejones sin salida o tener que rehacer lo mismo varias veces. Agile puede ayudarlo a lidiar mejor con lo inesperado, no es un argumento para ignorar lo que se sabe.

Tenga en cuenta la falacia del costo hundido : si comienza con una arquitectura o tipo de base de datos, la mayoría de las personas dudan en cambiarla a mitad del proyecto. Por lo tanto, es una buena idea invertir algo de tiempo en tener una "mejor conjetura" antes de comenzar a implementar cosas. Los desarrolladores tienen una tendencia a querer escribir código rápidamente. Pero a menudo tener un par de simulacros, prototipos en vivo, capturas de pantalla, estructura alámbrica, etc. permite una iteración aún más rápida que escribir código. Solo tenga en cuenta que cada línea de código escrita o incluso las pruebas unitarias hacen que sea más difícil cambiar su concepto general nuevamente.

Medición del éxito

Un aspecto completamente separado es cómo mides el progreso. Digamos que el objetivo de su proyecto es construir una torre de 1 m de altura utilizando cosas que se encuentran por ahí. Construir un castillo de naipes puede ser una solución totalmente válida si, por ejemplo, el tiempo de comercialización es más importante que la estabilidad. Si su objetivo es construir algo que dure, usar Lego hubiera sido mejor. El punto es: lo que se considera un truco y qué solución elegante depende completamente de cómo se mide el éxito del proyecto .

Su ejemplo de "carga" es bastante bueno. Tuve cosas como esta en el pasado donde todos (incluyendo ventas, PO, usuarios) acordaron que era molesto. Pero no tuvo impacto en el éxito del producto y no causó deuda a largo plazo. Así que lo descartamos porque había cosas más valiosas que hacer con los recursos de desarrollo.

Mi consejo aquí es:

1. Guarde todo, incluso pequeños errores, como tickets en su sistema de tickets . Tome una decisión activa sobre lo que está dentro del alcance del proyecto y lo que no. Cree hitos o filtre de otro modo su cartera de pedidos para que siempre tenga una lista "completa" de todo lo que aún debe hacerse.
2. Tenga un orden estricto de importancia y un punto de corte claro donde el proyecto pueda considerarse un éxito. ¿Qué nivel de estabilidad / calidad de código / documentación necesita realmente el producto final? Intente pasar cada día de trabajo lo mejor posible eligiendo desde la parte superior. Cuando trabaje en un boleto, intente resolverlo completamente sin introducir nuevos boletos (a menos que tenga sentido posponer las cosas debido a la menor prioridad). Cada compromiso debe llevarlo hacia su objetivo final, no hacia los lados o hacia atrás. Pero para enfatizarlo de nuevo: ¡a veces un truco que produce trabajo adicional más adelante puede ser positivo para el proyecto!
3. Use su PO / usuarios para calcular el valor del usuario, pero también haga que sus desarrolladores calculen el costo tecnológico . Los no desarrolladores generalmente no pueden juzgar cuál es el verdadero costo a largo plazo (¡no solo el costo de implementación!), Así que ayúdenlos. Tenga en cuenta el problema de la rana hirviendo: muchos problemas pequeños e irrelevantes pueden con el tiempo detener al equipo. Intente cuantificar qué tan eficiente puede trabajar su equipo.
4. Esté atento a la meta general / costos. En lugar de pensar de sprint en sprint, más bien tenga una mentalidad de "¿podemos nosotros como equipo hacer todo lo necesario hasta el final del proyecto" . Los sprints son solo una forma de descomponer las cosas y tener puntos de control.
5. En lugar de querer mostrar algo temprano, trace su curso en el camino más rápido hacia un producto mínimo viable que pueda proporcionarle al usuario. Aún así, su estrategia general debería permitir resultados verificables en el medio.

Entonces, cuando alguien hace algo que no se ajusta a su objetivo de implementación final, idealmente no considere la historia como hecha. Si es beneficioso cerrar la historia (por ejemplo, para obtener comentarios de los clientes), abra inmediatamente una nueva historia / error para abordar las deficiencias. ¡Haga transparente que tomar atajos no reduzca los costos, solo los oculta o los retrasa!

El truco aquí es discutir con el costo total del proyecto: si, por ejemplo, una OP presiona para tomar atajos para establecer una fecha límite, ¡cuantifique la cantidad de trabajo que debe hacerse después para considerar el proyecto realizado!

También tenga cuidado con la optimización basada en criterios : si su equipo se mide por la cantidad de historias que pueden mostrar en una revisión de sprint, la mejor manera de lograr un buen "puntaje" es dividir cada historia en diez pequeñas. Si se mide por la cantidad de pruebas unitarias escritas, tenderá a escribir muchas innecesarias. No cuente historias, más bien tenga una medida de cuánto funciona la funcionalidad necesaria del usuario, qué tan grande es el costo de la deuda tecnológica que se resolverá dentro del alcance del proyecto, etc.

Resumen

Para reducirlo: ir rápido y mínimo es un buen enfoque. El problema está en interpretar "rápido" y "mínimo". Uno siempre debe considerar el costo a largo plazo (a menos que tenga un proyecto donde esto sea irrelevante). El uso de un atajo que solo toma 1 día pero produce una deuda tecnológica de 1 mes después de la fecha de envío le cuesta a su compañía más que una solución que tomó 1 semana. Inmediatamente comenzar a escribir las pruebas parece rápido, pero no si su concepto es defectuoso y consolidan un enfoque equivocado.

Y tenga en cuenta lo que significa "a largo plazo" en su caso: conozco a más de una empresa que fracasó al intentar escribir un código excelente y, por lo tanto, se envió demasiado tarde. Una buena arquitectura o un código limpio, desde la perspectiva de la empresa, solo es valioso si el costo para lograrlo es menor que el costo de no tenerlo.

¡Espero que ayude!

Estrictamente desde una perspectiva scrum, parece que lo que estás haciendo mal es que no estás trabajando con el cliente. Debe trabajar junto con el cliente para comprender lo que necesita y no solo lo que quiere . ¿Necesitan una serie de soluciones rápidas o necesitan un sistema estable y sostenible que les sirva a largo plazo? Eso puede ser difícil de determinar, pero la calidad es un requisito tan importante como un color de fondo o un punto de referencia de rendimiento. El cliente debe ser consciente de que la estabilidad y la capacidad de mantenimiento no son gratuitas, y deben ser incorporadas al producto.

Si dicen que es lo primero, no está haciendo nada malo, suponiendo que les esté explicando en las revisiones de sprint que está cortando esquinas de ingeniería para cumplir sus objetivos.

Si dicen que es lo último, entonces lo que estás haciendo mal es que no les estás dando lo que quieren.

Una de las piedras angulares de Scrum es la transparencia. Si estás haciendo scrum, deberías estar haciendo revisiones de sprint con el cliente. En esas revisiones, ¿le está diciendo al cliente que está cortando esquinas para entregar software más rápido? Si no, deberías estarlo. Debe ser 100% claro con sus clientes sobre las ramificaciones de sus elecciones de diseño, para darles la oportunidad de tomar una decisión informada sobre si está entregando su software con un nivel de calidad adecuado.

Ewan tiene razón. La razón por la que a la gerencia le gusta scrum es porque pueden exigir características en estilo staccato y obtener resultados rápidamente. Hasta que el desorden resultante sea el problema de alguien más.

Ahora que tengo su atención, déjenme explicarlo. No es Scrum como tal. Es la configuración típica de un gerente de producto fuerte y un equipo de desarrollo débil que no puede establecer estimaciones razonables y realistas porque sienten la presión. Por lo tanto, elaboran estimaciones muy optimistas y se sumergen en problemas, cortando esquinas para entregar a tiempo.

En scrum, usted (como desarrollador) puede hacer su propia planificación. Nadie te dice que entregues alguna función en x días. Si alguien le dice que entregue en x días, no está haciendo Scrum.

Cualquiera que sea el problema que deba solucionarse, solicite su tiempo. ¿Crees que necesitas tiempo para reelaborar algo primero? Incorpóralo en tu presupuesto. ¿Puedes permitirte hacer eso?

Examinemos lo que está haciendo, dejando a un lado a Agile por un momento.

Cuando hacemos la planificación, siempre buscamos la solución fácil en términos de tiempo de desarrollo, así que, por ejemplo, si estamos creando un nuevo diálogo o algo así, usamos el viejo jquery porque es más rápido y decimos que volveremos más tarde a ordenar y transformar en reaccionar, pero eso rara vez sucede.

Esto se llama "Tomar deudas técnicas". Martin Fowler describió el "Cuadrante de la deuda técnica" en una publicación de blog suya a lo largo de los dos ejes: "Imprudente contra Prudente" y "Deliberado contra Inadvertido".

Decide explícitamente usar la tecnología antigua conocida jquery que lo aleja más de uno de sus objetivos expresos (es decir, una aplicación de una sola página). Haces esto para entregar "rápidamente". Esto es deliberado.

Lo que este cálculo de "rápidamente" no incluye es el tiempo que necesita para implementar la funcionalidad para reaccionar después. Usted elige una alternativa que solo tiene desventajas sobre la alternativa que sabe que es la correcta (es decir, tomarse el tiempo para implementar la función en reaccionar) basándose en una evaluación de que la velocidad es esencial. Esto es imprudente.

Martin Fowler suma este tipo de deuda en "No tenemos tiempo para el diseño". Esa es una opción apropiada en un entorno en el que no espera mantener el código o incluso espera codificar durante más de unos pocos días. Pero su proyecto es un proyecto de larga duración que implica explícitamente el mantenimiento de sus clientes.

Lo que estás haciendo está mal en el nivel más básico. ¡Es mala ingeniería !

Usted asumió una deuda técnica, ignorando que esta deuda debe pagarse y cobra intereses. Y siguió haciendo eso hasta que la tasa de interés de su deuda comenzó a cerrarse en su trabajo disponible durante su sprint.

Lo que debe hacer es reducir el nivel de deuda . Habla con tu jefe, habla con tu cliente. Necesitas estar trabajando en la mantenibilidad ayer.

Simplemente deja de usar Agile ...

O, más bien, deja de intentar hacer algo de una manera determinada simplemente porque eso es lo que (tu comprensión de) ágil (o scrum, etc.) dicta. Intentar aplicar una (mala) interpretación de uno de estos términos a un proyecto en la etapa incorrecta puede convertirse rápidamente en el peor curso de acción. Usa tu razón en su lugar.

La razón por la cual su proyecto, y casi todos los demás proyectos en el mundo, es un desastre de código y enfoques divergentes, se debe a la falta de un diseño arquitectónico centralizado y omnisciente (allí, lo dije).

Las razones por las que esto puede faltar son:

• El arquitecto no tiene la experiencia (como sus primeros diez proyectos de pasatiempos)
• El arquitecto no tiene tiempo
• El arquitecto no tiene el poder (el gerente dice que no, o sí, pero solo para algunas partes)
• El equipo tiene fe en alguna metodología de vudú que los salvará (todo se resolverá porque estamos usando Agile)

La solución simple es dejar caer todas estas palabras mágicas y observar la realidad de la situación, que se puede resumir como:

1. El estado del código está impidiendo la capacidad del equipo de entregar a tiempo y sin errores.
2. Cuantas más funciones agreguemos, peor será.
3. Por lo tanto, realmente tiene sentido pausar, reevaluar y (quizás drásticamente) rediseñar partes.

Naturalmente, se preguntará por qué llegó a este estado en primer lugar, con el dedo culpable dando vueltas y vueltas. La respuesta es que esto es inevitable: a medida que su diseño madura, se da cuenta de que debería haberlo hecho de manera diferente, pero no podría haberlo previsto. Además, esta no es una realización por proyecto, sucederá varias veces y debe planificarla.

Dicho esto, hay muchas cosas que los gerentes pueden hacer para exacerbar las cosas:

1. Deathmarching tus desarrolladores a los plazos.
2. Afirmando que los desarrolladores solo pueden registrar el tiempo contra los tickets, sin que existan tickets para "pensar, consolidar y refactorizar la calidad" y tener una generosa asignación de tiempo para ellos.
3. No le da a ninguna persona la propiedad de la arquitectura durante el tiempo suficiente para manejarla
4. No permitir que esa persona haga los cambios que cree que son necesarios

Mirándolo de esta manera, es fácil ver cómo algunas interpretaciones de ágil y scrum realmente lo llevarán por esta ruta aún más rápido.

Un enfoque es crear tickets para cada bit de refactorización. El problema es que a menudo no te das cuenta de que necesitas un gran refactorizador hasta que comienzas a trabajar en un ticket más pequeño, lo que retrasa los plazos, y si el ticket pasa por bucles de aprobación, simplemente ralentiza todo.

Otro enfoque es planificar sprints para utilizar solo el 25-50% de la capacidad de su equipo. Luego, los desarrolladores registran su tiempo en los tickets reales (registran el tiempo que debería haber tomado sin refactorizar) y el tiempo de refactorización (un gran boleto para la semana, sin bucles de aprobación, solo discusión entre los desarrolladores). Si no hay refactorización, puede retirar boletos del sprint de la próxima semana. Ajusta el control deslizante de porcentaje para las próximas semanas a medida que mejora el código subyacente del proyecto.

Entonces, para responder "qué estamos haciendo mal", diría que confía en una metodología sobre el sentido común. Incluso pide un "enfoque ágil para este problema" . Diría que deje caer las palabras y piense en el problema real. Si realmente desea separar varios manifiestos que intentan descifrar si su enfoque final de sentido común realmente cae bajo el disfraz de "ágil" o "scrum", hágalo de todas maneras :-)

No estás haciendo nada malo. Este tipo de metodología está diseñada para ofrecer características a las especificaciones y lo más rápido posible.

Si tiene objetivos secundarios para los que está trabajando, lo mejor es expresarlos como 'requisitos no funcionales' o 'definición de hecho'.

por ejemplo, podría tener un requisito no funcional:

"Todas las funciones nuevas deben estar escritas en React"

y

"Todas las llamadas asincrónicas deben implementar un control de carga y control de errores"

Solo tiene que hacer que su Propietario del producto (o equivalente) acepte que estas son cosas que vale la pena hacer, en lugar de infiltrarlas porque a los desarrolladores les gustan.