archivo

Archivo de la etiqueta: evolución

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.

Reinventar la rueda se considera un antipatrón, de hecho siempre se considera como algo improductivo e innecesario.

Dave Parnas lo ve desde un enfoque distinto: “No debemos olvidar que la rueda se reinventa con tanta frecuencia porque es una muy buena idea, yo he aprendido a preocuparme más por la solidez de las ideas que se inventaron una sola vez”.

Esa visión de Parnas está asociada al cambio y a la evolución. Realmente estamos viendo una y otra vez ideas y productos que se han reinventado y que han supuesto una revolución en la sociedad y en nuestras vidas.

¿Cuántas veces se ha reinventado, por ejemplo, los teléfonos móviles o los dispositivos que utilizamos para escuchar música?.

Si se observa con perspectiva y teniendo en cuenta el tiempo, reinventar la rueda va acompañada de la propia evolución, sin embargo si se observa desde el momento presente (y también hay que hacerlo) determinados cambios no tienen sentido porque no aportan nada a la solución actual.

Por tanto, los valores absolutos de si es positivo o negativo reinventar la rueda no son reales ya que, como siempre, dependerá del contexto.

Decía Aristóteles que: “El cambio en todas las cosas es dulce”.

Es dulce si se asimila el cambio, si se entiende que es inevitable porque cada día el mundo sigue girando.

Si no se asimila y se entiende que la situación actual es la adecuada y no va a cambiar es cuando llegan los problemas. Tal vez la situación sea adecuada, confortable, positiva, dulce incluso, y es bueno disfrutarla y sacarle todo el provecho posible, pero se debe estar dispuesto y, sobre todo, preparado, para el cambio.

La tecnología está en continua evolución, las personas también. Las organizaciones deben ser conscientes de eso, quien antes era un competidor insignificante tal vez sea hoy quien te esté quitando el mercado y lo peor no es eso, cada día surge nueva competencia más adaptada al contexto actual.

Los sistemas de información no son ajenos a los cambios, teniendo en cuenta que soportan procesos organizativos y que estos se van a ir modificando. El software tiene sentido si existe un usuario, si el usuario y/o su contexto, cambia, evoluciona y sabemos que es una característica inherente, podemos decir que la necesidad de cambio es también inherente al software.

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

Trabajamos para eso, para desarrollar software que funciona. Pero, ¿de qué se trata eso de que el software funcione?. Cada uno tenemos diferentes perspectivas de las cosas, esta no iba a ser una excepción, por lo que para cada uno el listón puede estar a diferente altura y no necesariamente (dependerá del momento del proyecto, del contexto, de las características del sistema de información, etc…) unos tienen que estar siempre equivocados y otros estar en lo cierto.

Siguiendo un enfoque iterativo incremental vamos a ir liberando diferentes versiones del producto hasta obtener una “versión final” (lo pongo entre comillas porque el software es generalmente objeto de una continua evolución por lo que se puede hablar de versiones finalistas de un proyecto más que versiones finales de un sistema de información).

Independientemente de que desde el primer momento intentemos liberar el mejor software posible (desarrollo con intención) es razonable pensar que en las primeras iteraciones de una aplicación el listón no esté tan alto, sobre todo en aquellos casos donde esas iteraciones no llegan a un entorno de producción o de llegar su uso está limitado a su evaluación y porque la incertidumbre y falta de acoplamiento (al proyecto y entre las personas) en los momentos iniciales hace que se falle más de la cuenta (desarrolladores y usuarios).

No se trata de relajarnos en las primeras iteraciones, no quiero decir eso, sino de entender que no todos los momentos del proyecto son iguales (ni todas las circunstancias). No hay minutos prescindibles en un proyecto porque lo perdido no se recupera y por ese motivo siempre soy partidario de ir con intención siempre sin olvidar y, eso es lo que quiero dejar patente, que como en toda carrera de larga distancia hay que saber regular (y que todas las carreras son diferentes).

Un software que funciona debe satisfacer las expectativas del usuario. Si no satisface sus expectativas tenemos un producto que hace cosas pero no tal y como las quiere el usuario. No se trata de términos absolutos sino que tenemos que tener en cuenta los umbrales, es decir, la liberación de una nueva versión puede que no deje totalmente satisfecho al usuario pero sí supere sus umbrales de satisfacción. Nuestro objetivo será que la “versión final” esté más cerca de la total satisfacción del usuario que de su umbral superior pero eso requerirá mucho trabajo, voluntad por parte de los usuarios para darnos su feedback y diferentes evoluciones del sistema.

Un software que funciona no debe quedarse solo con la parte visible del iceberg. La deuda técnica cuenta y mucho. El usuario no la ve, no la valorará y sin embargo condicionará la mantenibilidad del producto y la disponibilidad del sistema ante futuras evoluciones del mismo. Es posible que haya clientes que no la tengan en cuenta, en cualquier caso soy de la opinión de que los proveedores deben marcar unos estándares de calidad para los sistemas que desarrollan, como elemento diferencial respecto a los que no lo hacen.

Más allá de la deuda técnica se encuentra la mantenibilidad (un concepto más general). Un software que funciona debe ser lo más fácilmente de mantener posible (dentro del contexto en el que se ha realizado el proyecto) y eso va más allá de la deuda técnica pudiendo contemplar elementos documentales si así fuera preciso.

Un software que funciona debe tener también en cuenta aspectos no funcionales. Algunos de ellos están en la parte visible del iceberg (aunque tal vez en la parte de atrás, la que no se ve a simple vista o la que requiere más tiempo para ser descubierta) como por ejemplo el rendimiento o la disponibilidad y otros en la parte no visible como por ejemplo la seguridad.

Me parece muy interesante la siguiente reflexión de Dave Thomas: “Queremos que la gente vea el software como algo más orgánico, como algo más maleable y algo con el que tengas que estar preparado para interactuar con él y mejorarlo todo el tiempo”.

Esta reflexión está relacionada con una cita de Andy Hunt y Dave Thomas de su libro “The Pragmatic Programmer”: “En lugar de a la construcción el software se parece más a la jardinería” y en la justificación de dicha afirmación por parte del propio Dave Thomas (traducción libre): “En los jardines existe la suposición de que va a tener un mantenimiento constante. Todo el mundo dice que quiere un jardín que no requiera mucho mantenimiento pero al final es un jardín es algo con lo que siempre estás interactuando bien sea para mejorarlo o mantenerlo”.

Yo también veo el desarrollo de software así. La realidad demuestra que los procesos que se informatizan están en continua evolución, cambian normativas, se quiere buscar una mejora continua, se quiere ser competitivo. Por otro lado el software por sus características es un elemento que puede ser mantenido y mejorado sin necesidad de interrumpir el funcionamiento normal del sistema, incluso cuando se realizan modificaciones radicales sobre el mismo (salvo en aquellos casos donde el cambio en el proceso sea tan abrupto que haga el sistema inútil de la noche a la mañana, cosa que si bien puede pasar, no es lo más frecuente).

El software va a requerir mantenimiento (o mejor dicho, evolución), por ese motivo hay que pensar en tiempo de desarrollo la estrategia más adecuada para reducir la necesidad y los costes de mantenimiento. Desarrollar dejando eso en segundo plano después cuesta mucho dinero y problemas.

Si decidimos aplicar un enfoque iterativo incremental apoyado o no en una metodología concreta es fundamental que la entrega que se realice en cada sprint sea de la mayor calidad posible ya que de lo contrario el proceso de implantación se resentirá (tardará más de la cuenta y la versión que llegue a producción será menos estable).

A lo anterior habrá que sumar el hecho de que buena parte del siguiente sprint será para corregir errores del anterior. Si no se ha aprendido la lección y el siguiente sprint vuelve a tener demasiados errores, el software no evoluciona a la par de que el proyecto empezará, en términos económicos, a mostrar números no acordes al avance en el mismo, lo cual si no se gestiona adecuadamente por parte de los responsables del proyecto por parte proveedor (que no es otra cosa que ponerle coto a estas entregas deficientes) solo irá a peor (sobre todo si empieza a imputar al cliente el funcionamiento negligente del equipo de proyecto).

Nadie es perfecto, ninguna metodología lo es, los equipos de testing pueden pasar por alto cosas, por lo que habrá errores que lleguen a producción. No se trata de llegar al objetivo de errores cero sino de que las entregas se hagan con la suficiente seriedad de manera que hayan pasado por las revisiones adecuadas antes de entregarse (algunas serán automatizadas y otras realizadas por miembros del equipo).

Si un enfoque evolutivo queda atascado en la corrección continua de incidencias pierde totalmente su esencia y si no se soluciona el problema que lleva a esto la evolución en cada iteración será tan pequeña que el feedback perderá fuerza ya que el producto solo evolucionará a cuentagotas.