Metodología ágil: ¿rápida y sucia o planificar primero?

Pregunta ágil: ¿cree ágilmente en poner las cosas en marcha de la manera "rápida y sucia", o ágil prefiere construir sólidamente desde cero? ¿O no es una pregunta de metodología y más una pregunta que evalúa caso por caso?

Técnicamente estoy "rehaciendo" la base del sistema, después de que ya construí gran parte de la estructura en sí ... no es una cantidad monumental de trabajo ... ágil hubiera querido que especifique primero todo el flujo, lo analice, ajustarlo y luego construir? Siento que de alguna manera es mejor de esta manera ... una vez que instalo un sistema desordenado, veo mejor cómo debe hacerse ... por otro lado, no está tan organizado ... solo tengo curiosidad por saber cuál es el mejor desarrollo la práctica es a este respecto.

Creo que esta pregunta es algo diferente de Ágil y creación de prototipos, ya que no estoy preguntando sobre creación de prototipos y código desechable; Estoy interesado en ágil para el código de grado de producción.

La metodología ágil es el primer plan. Simplemente no es planear todo primero. De hecho, reúne requisitos, diseño, código, prueba, implementación y presente. Simplemente hace todo eso en menos de quince días (más o menos) en la pequeña característica más pequeña que puede implementar y obtener comentarios. Luego, vuelve a hacerlo todo agregando otra función o ajustando una antigua.

La clave es escribir código que acepte cambios para que cuando finalmente vea "cómo debe ir todo el flujo" pueda cambiar el código para hacerlo. De esa manera, cuando "la forma en que debe ir el flujo" (o lo que sea) cambie una vez más, no es traumático.

No puedes escribir rápido y sucio. Rápido y sucio te da un código ridículo. Sé rápido trabajando en pequeño. Manténgase flexible al no difundir conocimiento . Idealmente, cualquier cambio en una sola característica debería afectar solo un lugar en el código.

No puede pasar toneladas de tiempo haciendo nada más que planificar tampoco. Puede planificar, pero necesita poder cambiar el plan. Necesita descubrir rápidamente las razones para cambiar el plan. Cuando la planificación se lleva a cabo sin problemas, sin sorpresas de las que aprender, es cuando la planificación ha continuado durante demasiado tiempo. La planificación y la codificación tienen que ocurrir una cerca de la otra. Si estás aprendiendo, cuanto más antiguo es el plan, más tonto es.

A largo plazo, debe planear ser más inteligente. Escribe código flexible. Entonces, ser más inteligente no lleva al arrepentimiento.

No me gusta que para la mayoría de las personas sea "rápido y sucio" o "gran diseño por adelantado". Ni siquiera consideran que hay otras opciones.

Agile se trata de construir un sistema, donde el cambio, incluso al final del desarrollo, es trivial. Esto se logra mediante la construcción del software en pequeños fragmentos incrementales y bloqueando el comportamiento de esos fragmentos con pruebas automatizadas robustas. Y utilizando la implementación frecuente y automatizada en la producción para validar el valor de esos cambios.

Al tener pruebas automatizadas robustas, resulta trivial cambiar incluso las partes más difíciles de la arquitectura, mediante la refactorización incremental durante períodos de tiempo más largos. Entonces, incluso si se da cuenta de que su arquitectura podría hacerse mejor a la mitad del proyecto, es realmente posible hacer el cambio relativamente rápido.

Algunas personas dicen que "algún diseño por adelantado" es bueno con ágil. Pero si tiene la intención de repetir este diseño posteriormente, aún debe asegurarse de que su cultura de desarrollo produzca un sistema que sea fácil de cambiar. Por lo tanto, "SDUF" no invalida la necesidad de pruebas robustas, refactorización agresiva e implementación continua.

Al incorporar la "facilidad de cambio" en el sistema, no necesita pensar mucho sobre el diseño inicial de su proyecto, ya que eso se puede cambiar más adelante. El enfoque "rápido y sucio", que la mayoría de la gente lo llama "pico", solo se puede usar si estabiliza las características que considera valiosas. Pero no debe dejar piezas de código pirateado en su base de código durante demasiado tiempo, ya que ralentizan el cambio.

Ninguno.

Es "Comienza de manera simple y mejora mientras te mueves".

Rápido y sucio es frágil, pero rápido (si el proyecto es lo suficientemente pequeño y de corta duración).

El plan primero es rígido, pero estable (si el proyecto se completa antes de encontrarse con restricciones financieras o temporales).

Ágil es una alternativa a los 2 anteriores. Se basa en un enfoque iterativo donde las características se completan de una en una, característica por característica, y el conocimiento adquirido al completar estas partes completamente funcionales del programa se utiliza para desarrollar y ajustar el plan a medida que avanza el desarrollo. Hacerlo requiere un poco de planificación por adelantado, necesita al menos suficiente planificación para poder estimar cuánto trabajo requieren las características individuales, pero debido a que Agile espera un cambio, la planificación excesiva conduce al desperdicio.

Una de las características principales de Agile es hacer iteraciones cortas y luego reevaluar. Corres hacia adelante para explorar un nuevo territorio, aprender de él y luego hacer un plan. De esa manera su plan será mejor. Y si fallas (la idea de tu curso no funciona), habrás "fallado rápido", lo cual es bueno.

Entonces tu enfoque está bien. Sin embargo, el peligro es decir: "Bien, funciona, ya terminé. ¿Qué sigue?". No ha terminado, hay muchas esquinas cortadas para enderezar y debe tomarse / tomarse el tiempo para hacerlo correctamente una vez que esté claro que su enfoque produce un sistema funcional y viable. Eso podría ser escribir pruebas, documentos, StyleCop, optimizar, educar a colegas sobre lo que hiciste y cómo lo hiciste, revisarlo, etc.

Para agregar a las respuestas anteriores, un principio clave es YAGNI . Si su diseño y planificación iniciales permiten el siguiente paso, entonces está bien. Pero si permite un paso futuro hipotético que no puede probar es necesario, entonces asuma YAGNI.

Gran parte del diseño, tanto de arriba hacia abajo como de abajo hacia arriba, supone que habrá una reutilización significativa del código. Sin embargo, la experiencia dice que la reutilización de código simplemente no es tan común, porque rara vez se resuelve exactamente el mismo problema. Si necesita resolver una variante de ese problema en el futuro, refactorice su diseño en el futuro para agregar esa variante, pero no lo considere en este momento.

En otras palabras, planifique la tarea inmediata, pero no planifique nada más adelante.