archivo

Archivos diarios: septiembre 15, 2012

Comenta Jim Highsmith en el libro “Agile Software Development Ecosystems”: “Los planes son hipótesis a contrastar en lugar de predicciones a realizar”.

Resume la diferencia básica entre un enfoque evolutivo y un enfoque clásico.

El enfoque evolutivo está basado en iterar nuevas versiones del producto y mediante el feedback del usuario determinar en qué se ha fallado y en qué se ha acertado (por el momento) de manera que la siguiente versión sea mejor y más completa (con las nuevas tareas incluidas en el sprint), sin embargo en el enfoque clásico se espera que el proyecto transcurra linealmente porque todos los planteamientos iniciales serán igualmente válidos al final del proyecto.

Sé que la descripción que he realizado del enfoque clásico es demasiado ortodoxa y que todos los que desarrollan según este tipo de metodologías saben que no es así y que hay cambios prácticamente en todas las fases del proyecto o lo que es lo mismo, la predicción es imperfecta. Sin embargo aunque esto suceda el planteamiento en el proyecto seguirá siendo rígido (con determinadas concesiones al usuario) y alejado de un feedback sobre un producto real.

La deuda técnica condiciona el coste que tienen las tareas de evolución o mantenimiento de un software. Desde ese punto de vista todo software que sea susceptible de ser evolucionado debe tratar de mantener una deuda técnica acorde a las características del proyecto que se desarrolla y de su contexto (si los recursos para un proyecto son insuficientes la deuda técnica se verá impactada).

Ahora bien, si se trata de un desarrollo de usar y tirar, por regla general aquellas utilidades de pequeño tamaño que se hacen de manera específica para cumplir un objetivo concreto. Por ejemplo, hacer una migración o una explotación de datos no requieren un control de la deuda técnica si bien, siempre es recomendable intentar hacerlo de la mejor manera posible y si tenemos buenas prácticas de programacion, ¿por qué no aplicarlas?. ¿Qué no tendría sentido? Dedicar más tiempo del necesario para realizar ese desarrollo y por supuesto dedicar tiempo a refactorizar la solución.