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.

Cuando se trata de evolucionar un producto sin consolidar ese avance tenemos que plantearnos si efectivamente se trata de tierra ganada.

Una cosa es la experimentación, otra el desarrollo iterativo incremental o la incertidumbre y otras bien distinta es dar pasos rápidos que lo que van dejando atŕas es tierra quemada.

Experimentar es necesario, es una de las bases del desarrollo de software, realmente es lo que se hace cuando se implementa lo que creemos que hemos entendido de lo que cree que quiere el usuario. Esa diferencia se va paliando a través del feedback, salvo que se piense que se va a acertar a la primera, algo poco probable por muy buena voluntad que pongan las partes.

El desarrollo iterativo incremental refleja esa evolución del producto, tratando de consolidar lo ya realizado a la par de que se van incluyendo nuevas funcionalidades. No es tan importante el concepto como la aplicación de un enfoque adecuado, siendo recomendable pensar en pasar de estados más simples a otros más complejos.

La incertidumbre es lo que rodea al desarrollo de software y también a los negocios. Se está sometido a tantos factores que el contexto puede cambiar de manera lo suficientemente sensible como para que impacte en el proyecto. No se trata de huir de la incertidumbre sino de entenderla como algo inherente, por lo que se trata siempre de estar adaptado al cambio.

Dar pasos rápidos con el objeto de obtener un feedback necesario para obtener una orientación del producto es una buena estrategia. El problema es cuando se confunde ir rápido con la toma de atajos. A veces viene bien cogerlos pero cuando dejan de ser una excepción tenemos en un problema porque probablemente estemos sacrificando estabilidad y deuda técnica (capacidad, a fin de cuentas de adaptación al cambio) por más funcionalidad, que por otro lado hay que ver si es necesaria y que nos restará capacidad de maniobra en el caso de que sea necesario cambiar de enfoque.

Por todo eso, resulta necesario analizar si efectivamente los pasos que se van dando en el proyecto dejan tierra ganada.

La idea que tienen los product owners o los responsables funcionales del software que quieren no es más que algo abstracto, es más, hasta que el producto empiece a materializarse y cobrar una cierta entidad es más acertado decir que su idea inicial es lo que creen que quieren porque hasta que no se empiece a experimentar no saldrán a la superficie comportamientos y funcionalidades deseados pero que estaban ocultos o el caso contrario, comportamientos y funcionalidades que se creían efectivos y útiles y que no son ninguna de esas dos cosas.

De ahí la conveniencia de aplicar desarrollo iterativo incremental y con más razón en aquellos casos donde el sistema se prevea complejo y/o los responsables funcionales no terminen de verlo claro.

Pero desarrollo iterativo incremental es una idea muy general, si definimos ciclos largos hemos fraccionado algo el problema pero probablemente será insuficiente y será mayor la cantidad de desperdicio generado.

También es cuestión de enfoque, mejor siempre partir de soluciones simples consolidadas y validadas para a partir de ahí crecer hacia otras más complejas.

¿Se trata de obtener una versión rápida a toda costa? Versión rápida a toda costa es algo demasiado general, sí que resulta interesante cuanto antes obtener un feedback del usuario pero también que el desperdicio generado sea el menor posible (por lo que los ciclos de desarrollo deben hacerse con intención, de no hacerse así estaremos haciendo desarrollo por permutación y eso tiene un coste importante) y que no perdamos de vista que para seguir generando nuevas versiones es necesario que las modificaciones a realizar sobre el producto se puedan hacer en unos plazos razonables, por lo que en el momento en el que la deuda técnica supere unos determinados umbrales perderemos esa capacidad de respuesta rápida o por lo menos no tan rápida, efectiva y económica como sería deseable.

Tal vez al principio consideres que lo más importante es desarrollar una versión aunque sea prototípica para verificar si el producto va por el camino deseado y que determinados factores como la calidad del código son secundarios. Al final es algo que tendrás que valorar tú en base al contexto en el que estás desarrollando.

Es cierto que hay determinadas metodologías que recomiendan que los sprints tengan una duración que se encuentre comprendida en un intervalo de tiempo reducido. Estoy de acuerdo con ellas en que las iteraciones deben ser de corta duración, sobre esa base, mi visión personal es la siguiente:

– Cada proyecto se desarrolla en unas circunstancias y un contexto diferente. Una duración de sprint que resulta adecuada para uno puede no serlo para otro.

– Lo ideal podría ser aplicar sprints de duración fija pero en la realidad resulta complicado ajustarlo de esa manera ya que hay que tener en cuenta diversos factores: falta de disponibilidad en unas fechas concretas del product owner, la necesidad de tener un sprint algo más largo para incluir una funcionalidad esencial, la necesidad de un sprint más corto para solo incluir determinados ajustes, etc… No hay que cerrar las puertas, ni mucho menos a definir sprints de tamaño variable (eso sí, cada sprint tendrá su fecha de inicio y de fin que deberá ser respetada) por mucho que eso se considere poco ortodoxo en la teoría.

Sprints de corta duración permiten dar una rápida respuesta al cambio y obtener feedback cada poco tiempo, esa rápida respuesta no solo es consecuencia de que disminuya el tiempo necesario para llegar a producción sino también por el hecho de que se reduce tiempo de espera para trabajar sobre una funcionalidad no contemplada en el sprint (el tiempo de espera medio es la mitad de la duración de la iteración).

Ahora bien, sprints cortos requieren que el proceso de paso a producción sea rápido porque de lo contrario parte de las ventaja (sino toda) de las iteraciones cortas se quedan en nada. Esta situación no es posible en todas las organizaciones.

Sprints más largos se adaptan mejor a ese inconveniente y admiten más carga de trabajo (proporcional al tiempo).

Ambas soluciones tienen sus ventajas e inconvenientes pero podemos jugar con ellas en función de las necesidades que tenga el proyecto en cada momento, ya que no es ágil cerrarnos en banda a una duración determinada porque estaríamos priorizando la metodología a las necesidades del proyecto y del producto.