Evitar optimizaciones locales en un proyecto ágil

Question

Soy muy positivo con respecto al desarrollo ágil y he trabajado en proyectos ágiles de forma intermitente durante aproximadamente 13 años. Pero tengo una preocupación que nunca he podido abordar. No siempre parece manifestarse, pero me ha mordido un par de veces.

Agile parece ser en cierto sentido un "algoritmo codicioso". Comience con la historia de mayor valor, optimice el sistema para cumplir con precisión esa historia y repita.

Los algoritmos codiciosos reales son propensos a sufrir convergencias a soluciones locales óptimas, mientras que faltan una solución óptima a nivel mundial.

¿Ha sido esta la experiencia de las personas?

¿De verdad es un problema?

En caso afirmativo, ¿qué técnicas utiliza para evitar dichos óptimos locales y, sin embargo, sigue siendo ágil?

Answer 1

Los algoritmos codiciosos reales son propensos a sufrir la convergencia de soluciones locales óptimas, mientras que faltan una solución globalmente óptima.

Esto es válido si la historia y las pautas del usuario técnico de EPIC no están establecidas, junto con la historia de usuario de EPIC comercial normal.

¿Esta es la experiencia de las personas?

En ocasiones sí, ha sido mi experiencia. Un ejemplo fue cuando las historias de usuarios en las que trabajamos se desglosaron demasiado, y la solución fue ampliarlas para obtener una perspectiva más global de nuestros diseños. Y a veces eran diferentes equipos de scrum empresariales en el mismo proyecto, en conflicto con diferentes usos y enfoques del marco técnico.

¿De verdad es un problema?

Es solo un problema si ignora la historia o la guía técnica del usuario de EPIC.

En caso afirmativo, ¿qué técnicas utiliza para evitar esos óptimos locales y, sin embargo, sigue siendo ágil?

Aquí es un enfoque ágil para resolver esto: Durante una rápida planificación de lanzamiento, en vez de dar con una historia de usuario de negocios EPIC, también vienen con una historia de usuario EPIC técnica. La historia del usuario técnico de EPIC tendría la visión del producto desde un punto de vista técnico, en términos de arquitectura técnica, marco de aplicación, estándares de calidad y consideraciones de diseño global, etc. Podrían dividirse en pequeñas historias de usuarios técnicos y contar con un equipo de Scrum. que funciona para lograr que esas historias de usuarios funcionen. Un ejemplo de una historia de usuario podría ser: "Como Gerente de Proyecto Técnico, quiero que todo el proyecto empresarial use marcos A, B, C y codificación según los estándares de codificación X, Y, Z, de modo que haya uniformidad en el desarrollo del proyecto. Si no desea formar un equipo de scrum por separado para esto, simplemente guárdelos como tarjetas de recordatorio junto a los atrasos para que los equipos de desarrollo los usen como pautas.

Como guía de prueba, solíamos tener éxito prueba de integración como un criterio hecho para cada acumulación.Se llevó a cabo una prueba global en un entorno de integración, en todo el software en funcionamiento implementado por todos los equipos de la empresa, para considerarlo factible. Así que, desde el inicio hasta el final de la acumulación, el tema está establecido para el software de trabajo global y no solo para el software de trabajo local.

Finalmente, el desarrollo ágil implica mantener un ojo constante en la calidad, y uno de los problemas de calidad puede ser un diseño incorrecto o demasiado localizado. A medida que se descubra esto, se debe rediseñar dentro de ese retraso acumulado y seguir adelante para otros Atrasos.

Answer 2

He estado en un proyecto que ha tenido este problema y no lo ha solucionado con eficacia.

La calidad local del código, sobre la escala de un paquete, por ejemplo, no era mala. Pero había problemas a mayor escala; cosas como duplicación de lógica (pero no código) entre paquetes, uso de trabajos de recalculación por lotes donde deberíamos utilizar enfoques basados ​​en eventos, dividir el sistema en servicios separados en el lugar equivocado, etc.

Ninguno de estos problemas podría se puede arreglar refactorizando una sola clase o paquete. Como resultado, nunca sucedieron en el curso normal de los eventos. Hicimos refactorizaciones a menor escala: al agregar una función, nos refactorizaríamos en esa área antes de comenzar, y nuevamente después de que termináramos (además de esforzarnos para escribir un buen código mientras íbamos). Pero eso nunca llevó a refactorizar las preocupaciones arquitectónicas más grandes.

Todos éramos conscientes de los problemas, simplemente no teníamos nada en nuestro proceso que nos permitiera repararlos.

Una victoria notable que tuvimos fue donde había duplicación entre dos módulos relacionados lejanamente. Básicamente, había un código para representar una página web que mostraba los resultados de un conjunto de cálculos, y también un trabajo en segundo plano para generar informes que realizaban cálculos similares. El código de cálculo fue compartido, pero el código para configurar los cálculos no; uno fue impulsado por las preferencias de vista del usuario, mientras que el otro fue impulsado por un trabajo de informes configurado. Teníamos una función para implementar que habría implicado agregar un nuevo aspecto a los cálculos, lo que habría significado agregar más elementos a ambos tipos de configuración y luego agregar lógica comercial a ambos conjuntos de códigos de configuración de cálculo. Logramos que el gerente de producto (nuestro proxy de cliente) acordara presupuestar el tiempo suficiente para el trabajo que pudiéramos refactorizar para unir las ideas de las preferencias de vista del usuario y el trabajo de informes configurado, descartando uno de los lados de la duplicación, luego implementar la característica. Esto tomó más tiempo que simplemente implementarlo dos veces, pero el gerente de producto fue lo suficientemente inteligente como para darse cuenta de que esto nos permitiría implementar funciones futuras que abarcan tanto las páginas como los informes más rápidamente.

El mecanismo en el proceso por el cual lo hicimos fue escribir historias para el trabajo de refactorización. Esencialmente, algo así como "Como gerente de producto, quiero que las páginas y los informes usen un código de configuración de cálculo común, de modo que pueda obtener funciones agregadas más rápidamente". Esta no es una historia propiamente dicha, pero encajaba en el sistema e hizo el trabajo.

Creo que si el funcionamiento de este proyecto hubiera sido un poco más saludable, entonces habría habido un flujo constante de historias como esta. Reconoceríamos que teníamos muchas deudas arquitectónicas, y que trabajar para pagarlo tenía un valor, y asignarle una fracción fija de nuestro tiempo, tal vez alrededor del 20% (lo que realmente significaría un par a la vez). Podríamos haber generado funciones/épicas, historias y tareas tal como lo hicimos para el trabajo orientado al cliente. Estos se originarían del equipo mismo, en lugar de los gerentes de producto.

Lamentablemente, no hubo suficiente comunicación y confianza entre las partes de desarrollo y administración de productos que esto era factible; podríamos decir al producto que teníamos un problema, que era importante y que tomaría tanto tiempo arreglarlo, y no podían saber si eso era cierto o no.Como tal, generalmente no estaban dispuestos a programar el horario para hacerlo. Lo triste fue que todos estaban de acuerdo en que había problemas y que sería bueno solucionarlos, simplemente tuvimos un punto muerto por el que realmente lo estábamos haciendo.

Answer 3

En mi experiencia, si está trabajando en un contexto de proyecto con tiempo/requisitos fijos, entonces sí, la mayoría de las veces Agile conduce a óptimos locales.

Pero mi punto es que en un esfuerzo complejo, los requisitos, el equipo mismo e incluso los objetivos cambian. Agile también se trata de abrazar los cambios. Luego, paradójicamente, esta estrategia ambiciosa se presenta como una opción razonable para la optimización global cuando se trata de objetivos en movimiento.