He estado utilizando una metodología ágil (SCRUM) durante aproximadamente tres años y veo ciertas ventajas, especialmente en la retroalimentación a corto plazo en muchos niveles (de clientes que tienen acceso temprano a funciones implementadas, de probadores que pueden probar características como tan pronto como se implementen, de otros desarrolladores que pueden proporcionar comentarios muy tempranos sobre el nuevo código a través de la revisión, etc.
Por otro lado, tengo dos problemas abiertos, el primero de los cuales trataré de explicar en esta pregunta.
Problema: dificultad para obtener un buen diseño
Intento refactorizar tan pronto como el código se vuelve desordenado, escribo pruebas unitarias tanto como puedo (lo que ayuda a prevenir errores en general y cuando refactoriza en particular). Por otro lado, desarrollar algunas características complejas en pequeños incrementos, con compromisos diarios y repensar continuamente el código cuando se desestructura, no me permite producir un diseño realmente bueno.
El único módulo bien diseñado que pude producir recientemente lo obtuve adoptando un enfoque diferente: analicé el problema durante unos días (en realidad, tuve el problema en mi mente durante un par de meses antes de comenzar a trabajar en serio ), esbocé un diseño bastante detallado de todas las clases involucradas y sus relaciones durante un par de días más, y luego me encerré en mi oficina y escribí todo el código trabajando sin interrupción durante aproximadamente tres semanas. El resultado fue lo mejor que he producido en mucho tiempo, con muy pocos errores que fueron bastante fáciles de localizar y corregir, y con un diseño muy claro, que no ha requerido ningún cambio relevante desde entonces.
Entonces, hasta ahora, me resultó mucho más efectivo obtener una imagen general de lo que quiero hacer de antemano que comenzar a escribir código en pequeños incrementos con la esperanza de que la gran imagen surja mágicamente en el proceso. Con mi mejor esfuerzo, el enfoque de desarrollo de incrementos pequeños siempre me ha llevado a un peor diseño.
Pregunta : ¿Alguien ha tenido una experiencia similar? ¿Estoy aplicando SCRUM de forma incorrecta o a qué debo prestar atención si deseo desarrollar en pequeños incrementos y aún así terminar con un software bien diseñado? ¿O debería programar una historia de usuario de diseño antes de comenzar la codificación real? ¿Se considera esto una buena práctica, al menos para características que son más complejas que el promedio?
EDITAR NOTA
Soy consciente del hecho de que un buen diseño no es algo absoluto y no tiene un valor en sí mismo, sino que depende del contexto, y que uno debe apuntar a un diseño que sea lo suficientemente bueno para el problema en cuestión.
Por ejemplo, no me importa (demasiado) el buen diseño si tengo que implementar un componente simple que (1) debe estar listo lo antes posible, (2) se va a usar solo una vez, (3) no utilizado por otras partes del sistema (YAGNI).
Me importa el buen diseño cuando un componente (1) se usará varias veces y en varias versiones diferentes de un producto, (2) debe mantenerse y ampliarse con el tiempo, (3) tiene muchos otros componentes dependiendo de él .
The only well-designed module I could produce recently I obtained by taking a different approach-- Usted contestó su propia pregunta. Todavía necesita un diseño inicial; no se puede esperar que un buen diseño simplemente crezca orgánicamente de la refactorización. No funciona de esa manera.