Ágil: ¿qué estamos haciendo mal?

22

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?

Gabriel Slomka
fuente
21
"El resultado es que nuestra base de código es un gran desastre con muy poca capacidad de mantenimiento, principalmente debido a esta estrategia de desarrollo, simplemente ve rápido, haz lo mínimo". - Parece que ya tienes una buena idea del problema, pero no estoy seguro de que realmente tenga mucho que ver con Agile. Puede obtener codificación de cinta adhesiva sin importar la metodología que utilice.
Nathanael
¿Cómo prevenir eso en ágil? La gente entiende lo incremental como la grabación de pato y luego la fijación.
Gabriel Slomka
77
"La gente entiende lo incremental como grabar pato y luego arreglarlo". - eso ciertamente no es lo que es el scrum. Si la "gente" piensa eso, no entienden el scrum.
Bryan Oakley
99
Para citar a Eric Lippert: si te metiste en un agujero, lo primero que debes salir es: deja de cavar.
Doc Brown
55
¿Su equipo sigue la "regla del boy scout" (deje un lugar siempre en mejor estado que cuando ingresó)? Comience con eso. Además, las revisiones de código, las pruebas de escritura y la refactorización regular también son técnicas útiles.
Doc Brown

Respuestas:

56

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é?

Dan Pichelman
fuente
Además, creo que la mayoría de los problemas como este son causados ​​por no tener un gerente experimentado que sepa cómo resolver estos problemas y, en su lugar, reemplace al gerente con metodologías con nombre que uno lee en línea. Una ventaja de esto es que ahora el método tiene la culpa en lugar del administrador.
Rob
1
La respuesta es simplemente esto. Bien puesto y muy preciso. SCRUM es solo una forma de trabajar, si decides trabajar con cinta adhesiva en lugar de cinta adhesiva, eso depende de ti.
coteyr
Obtienes lo que incentivas. Si mantiene a las personas bajo una presión constante en la fecha límite (sprints de Scrum), está incentivando a las personas a tomar atajos. Así se acumula la deuda tecnológica.
Michael B
22

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 .

Eufórico
fuente
66
"Algunos dirían que Scrum ... es demasiado fácil para alcanzar su situación exacta". . No creo que sea cierto en absoluto. Hacer un scrum incorrecto puede llevar a esta situación exacta, pero el scrum en sí no admite la solución más barata posible, a menos que eso sea exactamente lo que el cliente quiere.
Bryan Oakley
1
@BryanOakley Lo que quiero decir es que si el proceso no prescribe hacer X, entonces la gente no hará X. Y Scrum no prescribe ninguna práctica que reduzca la deuda técnica. Todo lo contrario, como si PO solo definiera el trabajo a realizar, entonces no se eliminará ninguna deuda técnica. Como PO no tiene ninguna razón para preocuparse por eso. La deuda técnica es solo responsabilidad del equipo.
Eufórico
2
"Scrum no prescribe ninguna práctica que reduzca la deuda técnica". - ni prescribe ninguna práctica que aumente la deuda técnica.
Bryan Oakley
2
@BryanOakley El punto de la deuda técnica es que es un estado natural que aumenta. Y se debe trabajar para disminuirlo. Dejado solo, crecerá incontrolablemente.
Eufórico
44
Si el PO es el único que recibe información sobre lo que entra en el sprint, el PO está desempeñando mal su papel. Es su trabajo decidir qué es lo más importante hablando con todos los involucrados en el proceso de producción, y eso incluye al resto de su equipo.
Erik
9

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!

AlexK
fuente
"Piénselo de esta manera: hace 10-20 años, la gente intentaba escribir especificaciones gigantes y pensar en todo de antemano y a menudo fallaba": estado en el negocio desde los años noventa y, bueno, no, no trabajamos así . Decir que esto es solo un lugar común de marketing para contrastar ágilmente con un pasado mítico en el que las personas se equivocaban al planificar demasiado. No planificar demasiado y producir un prototipo temprano fueron algunas de las primeras lecciones que aprendí alrededor de 1998 más o menos. El movimiento ágil consiste en parte en usar palabras nuevas para prácticas bien conocidas y comercializarlas como nuevas.
Giorgio
Por supuesto, depende de las propias experiencias. De hecho, estaba en algunos proyectos con grandes y conservadores fabricantes de automóviles y no creerías cuán detalladas eran las especificaciones antes de que se escribiera una sola línea de código. Por mucho que lo que describí fue un extremo, hay bastantes compañías hoy en día que no hacen ningún inicio adecuado (que nunca experimenté en aquellos días). Hay y siempre hubo ejemplos de cada punto en el espectro entre esos dos extremos. Pero al menos veo que la tendencia general ha cambiado notablemente hacia el final "sin inicio".
AlexK
7

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.

Bryan Oakley
fuente
3
Cuando trabaje con el cliente, asegúrese de descubrir lo que necesita , no lo que dice que quiere. Casi cualquier cliente elegirá la solución más barata y rápida para cada problema, es el trabajo del equipo de ingeniería descubrir cuál es la opción más barata que aún cubre todas las cosas que realmente necesitan.
Erik
1
@Erik: excelente comentario. Es por eso que originalmente escribí _ "para comprender qué necesitan" en lugar de "... quieren". Sin embargo, puedo ver que eso no se enfatiza mucho. Agregaré un poco más de énfasis y explicación. Gracias por el comentario.
Bryan Oakley
5

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?

Martin Maat
fuente
3

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.

Vogel612
fuente
2

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

Andy tiene
fuente
-1

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.

Ewan
fuente
"Este tipo de metodología está diseñada para ofrecer características a las especificaciones y lo más rápido posible". Definitivamente, ese no es el objetivo de Scrum. La forma en que lo expresaste, no está claro si eso es lo que quisiste decir o no.
Bryan Oakley
lo siento, supongo que se trata de ofrecer funciones más avanzadas y tardías.
Ewan
No en realidad no. Scrum se trata de trabajar con el cliente para entregar software de alta calidad de una manera iterativa y altamente visible. Scrum no dice nada acerca de ofrecer características de baja calidad en lugar de hacer una ingeniería adecuada.
Bryan Oakley
2
si me perdonas una crítica, pareces tener una idea muy firme sobre de qué se trata el scrum. Pero si reviso la guía y otras declaraciones 'oficiales' hoy, todo parece muy flojo. Creo que sería difícil encontrar una declaración que haga una declaración clara sobre el asunto
Ewan
1
@Erik piensan que es un desastre porque quieren usar reaccionar. El equipo de desarrollo no puede decidir refactorizar todo por su cuenta. El cliente se negaría a pagar el sprint.
Ewan