archivo

Archivo de la etiqueta: hipótesis

Realmente podemos llevarnos horas, días, semanas, meses, discutiendo sobre si la aplicación de una determinada estrategia, enfoque o práctica es adecuada, pero solo se tratará de especulación, muchas hipótesis e ideas.

¿Es humo? Para mi el humo tiene mucho más que ver con hipótesis que solo han tenido en cuenta aspectos teóricos u opiniones personales que no se han contrastado, al menos, con la realidad del contexto en el que se quieren aplicar. Si, por lo menos, las ideas se sustentan en un análisis objetivo, yo no lo llamaría humo, pero no dejan de ser hipótesis sin validar.

Lo queramos llamar humo o no, se trata de mucho tiempo invertido en establecer un conjunto de ideas que lo mismo la realidad se encarga de demostrar que son equivocadas.

Ese tiempo invertido puede suponer dinero (siempre lo es aunque no te suponga un gasto directo), pérdida de oportunidad y/o dificultad de adaptación al cambio si has desarrollado un producto prácticamente finalista.

Jim Highsmith en su libro “Adaptive Software Development” realiza la siguiente reflexión: “El aprendizaje rápido requiere iteraciones: intentar, revisar, repetir”.

Aprender sobre hechos y no trabajar indefinidamente sobre hipótesis es para mi la esencia de la iteración.

Es cierto que la hipótesis dura (para bien, para mal o para regular) hasta que tenemos el resultado definitivo del proyecto en producción ya que hasta que de manera completa no se utiliza en un contexto real no podemos medir con precisión la satisfacción con el producto pero también lo es que la niebla se despeja poco a poco conforme el usuario va probando versiones parciales del mismo (en producción real preferiblemente) y va proporcionando su feedback.

En este proceso no solo aprende el desarrollador sino que también aprende el usuario porque de lo que cree que quiere (que no deja de ser una idea abstracta y a gran escala) a la solución que realmente le satisfaría, hay un largo trecho.

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.