archivo

Archivo de la etiqueta: feedback

La iteración favorece la evolución del producto. Mediante el feedback tratamos de aproximarnos cada vez más a la solución que satisfaga las expectativas del usuario, por tanto, en cada iteración se le trata de dar un mayor valor al producto.

En un enfoque clásico o predictivo el feedback se obtiene principalmente en la fase de análisis cuando el producto sigue siendo una idea abstracta en la que se pueden imaginar sus formas pero donde la mayor parte del mismo está cubierto por niebla. Después se pueden realizar ajustes, claro que sí, pero no con agilidad ya que en este tipo de enfoques tiene especial importancia el cumplimiento de la agenda establecida: costes y plazos.

El feedback continuo favorece la evolución del producto de manera que teóricamente en cada iteración vamos adaptando las características del producto al contexto existente y a las expectativas que se tienen puestas en él. Cuanto más real sea el entorno en que se realiza el feedback, cuanto más cerca esté el usuario del producto con mayor intención se realizará la siguiente iteración y más efectivo será el resultado.

Es razonable pensar, por tanto, que en un contexto de evolución rápida del producto existirán más posibilidades de que el mismo tenga éxito.

Hablo de posibilidades, la realidad es otra cosa porque el éxito no se consigue a través del proceso (en este caso iteraciones más o menos frecuentes) sino a través de la correcta y adecuada ejecución de las acciones en el proyecto.

Una de las claves para sacar adelante cualquier trabajo (y un proyecto no es más que un tipo de trabajo más), con su complejidad y sus características inherentes, es dividirlo en una serie de tareas que sean manejables: divide y vencerás.

El enfoque clásico o predictivo supuso el primer avance en ese sentido, si bien lo que hizo fue darle formalidad a lo que carecía de ella porque la división en tareas más simples en el desarrollo de software existe desde sus mismos inicios.

Esa división en procesos, actividades y tareas la podemos ver en Métrica v3, en versiones anteriores, en cualquier otra metodología basada en enfoques clásicos o en las propias definiciones genéricas de esa estrategia.

El inconveniente que se plantea es que divide en partes las actividades pero no el producto. Sobre esa aproximación inicial surgieron nuevas estrategias que tenían como objetivo descomponer el producto en partes y sobre cada una de ellas realizar una división de las actividades. Esto dio lugar a enfoques de tipo teórico como los desarrollos en espiral o más tangibles como los desarrollos iterativos incrementales.

Con este tipo de estrategias se puso en primer plano los conceptos de feedback y retrospectiva: conocimiento adquirido como consecuencia de la experiencia sobre versiones reales del producto (ya sea en producción o no) y la mejora continua de las prácticas y enfoque del proyecto.

El siguiente paso fue hacer que la descomposición del producto fuera en trozos más pequeños definiéndose para ello sprints de duración fija o variable pero que en cualquier caso iban a ser de corta duración. En este contexto el feedback y la retrospectiva ganan en intensidad, se realizan cada poco tiempo y el producto está preparado para adaptarse al cambio.

En esta evolución se ha pasado de la especificación del producto a su visión: se tiene una colección de tareas a realizar que se va modificando conforme avanza el proyecto y solo se estudian en detalle cuando se está preparando la siguiente iteración.

Muchas veces nos encontramos con el término “épica” y no sabemos como encajarlos cuando tradicionalmente estamos acostumbrados a trabajar con historias de usuario.

Cuando estamos trabajando en un sprint, una posible estrategia de desarrollo la tenemos dividiendo todas o algunas de las historias de usuario en tareas, ya sea por cuestión de tamaño, por la posibilidad de dividir el trabajo entre diferentes desarrolladores, etc…

Una épica no es más que un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc… Es decir, se tiene en mente una imagen abstracta de lo que se quiere obtener con la épica (que se desarrollará probablemente en varias iteraciones), pero son las historias de usuario, su implementación en los sprints y el feedback los que terminan de darle finalmente la forma.

Su enunciado es el siguiente: “El proceso de evolución del sistema es consecuencia de un proceso de realimentación (feedback) a diferentes niveles, de manera iterativa y por diferentes actores, y debe ser considerado como tal para conseguir mejoras significativas sobre cualquier base razonable”.

El carácter evolutivo del desarrollo de software lo caracteriza durante todo su ciclo de vida. Es continuo, aunque se materializa mediante incrementos o iteraciones, que pueden ser mediante ciclos más o menos regulares o de forma más discontinua.

En cada evolución se tiene la posibilidad de recabar feedback a diferentes niveles, por ejemplo, calidad estática del código (utilizando algún analizador tipo Sonar), número de defectos que presente al producto, grado de satisfacción del usuario, mejoras o nuevas funcionalidades que quieran incorporar una vez que se han analizado las de la versión que se ha entregado, etc…

Con la información obtenida se pueden plantear diferentes acciones que debidamente priorizadas pueden mejorar la calidad del sistema y que darán lugar a nuevas actuaciones (nuevas evoluciones) sobre el mismo.

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.

Para Fred Brooks: “Incluso la mejor planificación no es tan omnisciente como para hacer las cosas bien a la primera”.

Eso es importante tenerlo en cuenta si pretendes contratar un software llave en mano o si te quieres encerrar en las limitaciones de un análisis de requisitos.

Lo puedes tratar de hacer de la mejor forma posible, con un espíritu de colaboración fantástico con el área usuaria, con estudios de mercado y/o de otros productos similares, con grandes técnicos, pero al final, la realidad y el camino lo marca el software que estás desarrollando y hasta que este no se empieza a utilizar en un contexto real por parte de los usuarios no se obtendrá el feedback necesario para acercar el producto a las expectativas reales que se tienen de él.

Teniendo en cuenta que el desarrollo de software tiene una naturaleza colaborativa (participan personas y se necesita de todas ellas para sacar el trabajo adelante) se entiende que cuanto menor sea la separación (y no hablo de distancia física) entre las diferentes personas que participan en el proyecto, mayor probabilidad de éxito tendremos.

Por eso soy de la opinión de que los desarrolladores deben tratar con los usuarios en todas las etapas o ciclos de desarrollo de un producto. El feedback no solo se trata de palabras sino también de sensaciones y esto último te lo pierdes si no tratas con las personas que van a usar la aplicación. Por mucho que te lo cuenten no es lo mismo.

Es posible que existan proyectos donde la relación entre las partes sea tan mala que tal vez lo mejor sea utilizar intermediarios, en cualquier caso debería tratarse de una situación transitoria porque normalmente la mejor decisión que se puede tomar en estos casos, si no se consigue reconducir, es llegar a un acuerdo para dar por terminada la relación contractual.

Crear barreras e interfaces artificiales entre personas solo originan distancia y ese incremento de la misma afecta inversamente al conocimiento. Deja que el desarrollador tenga su propia perspectiva, deja que los usuarios interaccionen con los desarrolladores, dejan que compartan opiniones, deja que aprendan juntos.

Recordemos que se trata de ir eliminando esa distancia entre lo que los desarrolladores creen que hay que hacer y lo que los usuarios creen que quieren. Las diferentes versiones del producto irán aproximando esas visiones a la del producto que se espera y, como es lógico, es más efectivo si todas las partes contrastan sus perspectivas.