archivo

Archivo de la etiqueta: intención

La intención es la realización de acciones como resultado de una reflexión previa basada en hechos objetivos que pretende mejorar el producto (incrementar su valor) en cada iteración.

Conforme nos salimos de esta definición más nos acercamos al extremo opuesto, la prueba y error (no necesariamente malo porque habrá circunstancias donde se tenga que optar por esa estrategia).

La intención, por tanto, es tomar decisiones con una cierta base y si se acierta con ellas el ratio valor/número de iteraciones crecerá.

La intención se nutre del feedback, de nuestro background profesional y de nuestra interpretación del contexto actual y de su posible evolución.

La intención no supone conocer de antemano el éxito o el fracaso de la aplicación de las acciones, ya que de lo contrario estaríamos hablando de certezas, pero sí supone tratar de jugar con las mejores cartas ya que así existirán más posibilidades de acertar.

No contamos con presupuestos ilimitados y se quieren resultados acordes a la inversión realizada, más pronto que tarde, si no se desarrolla con intención, empezará a no existir un equilibrio entre coste y consecución de objetivos, conforme la distancia entre ambos se haga más grande más posibilidad hay de que existan conflictos entre usuarios y desarrolladores, entre cliente y proveedores, los cuales, a su vez crean resistencias que complicarán más, si cabe, el proyecto.

Como desarrolladores somos reacios a la realización de cambios y no es que seamos así genéticamente sino por el hecho de que se nos ha formado y después hemos trabajado en proyectos en donde nuestra capacidad de ser flexibles estaba muy limitada por el cumplimiento de una agenda de costes y plazos (mucho más lo primero que lo segundo).

Cuando se enfoca un proyecto con presupuestos inmovilistas y sobre todo, carentes de toda aproximación a la realidad no se puede pretender que acojamos los cambios dando aplausos porque lo que el presupuesto no cubre (hasta cierto límite, claro está) lo tendremos que cubrir con nuestro trabajo.

No se trata de trabajar con presupuestos ilimitados, sino de desarrollar con intención (que es lo mismo que tratar de desarrollar de manera eficiente) y de determinar cuándo el valor del producto es suficiente y cuándo deja de ser rentable el crecimiento del valor con respecto a la inversión que se está realizando.

Con esta visión del desarrollo del software el cambio resulta bienvenido ya que se entiende que a través de él se consigue dotar al producto de un mayor valor (como consecuencia de que cada vez se ajustará más al contexto existente y a las expectativas de los usuarios).

Ahora bien, el cambio debe hacerse con intención (evitando en lo posible las circunstancias de prueba y error) y con un sistema en los que los cambios se puedan realizar con agilidad (deuda técnica acorde a las características del sistema que se desarrolla, arquitectura y modelo de datos escalable, etc…).

Cuando uno se acostumbra a este esquema de trabajo se acepta el cambio como una parte más del proceso de desarrollo de software y efectivamente se cumple la siguiente reflexión de Ken Auer y Roy Miller: “La única manera de deshacerte de tu miedo a los cambios en el código es hacerlos una y otra vez”.

Algunos de los lectores habituales de este blog se preguntarán: “en un proyecto de desarrollo de software, ¿no tenemos que estar siempre atentos (alertas) a la necesidad de adaptarnos al cambio?, ¿no es la rápida capacidad de adaptación una ventaja competitiva?, ¿por qué haces un planteamiento tan rígido?”.

Por este motivo me he decido a darle una segunda parte al artículo publicado ayer.

Una organización siempre tiene que estar atenta a la oportunidad y a los movimientos del mercado. Llegar antes que los demás, si se aprovecha adecuadamente, te puede hacer ganar mucho dinero. Llegar un poco tarde te puede convertir en algo insignificante.

Esto es evidente y en nada contradice con lo comentado ayer. ¿Qué quise decir? Algo tan simple como que el desarrollo de software no hace milagros y que la agilidad es efectividad e intención. Una cosa es que un proceso tenga que cambiar para adaptarse a un nuevo contexto o para adelantarse o coger ventaja a la competencia y que eso pueda suceder en cualquier momento (cuando surge la oportunidad) y otra que tengamos que partir con unas condiciones que se sabe que no llevan a ningún sitio.

Para competir tienes que funcionar bien, si organizativamente eres un desastre difícilmente puedes competir con alguien, salvo que tengas un gran producto y/o unos grandes clientes (que en ningún caso van a ser eternos).

El software debe ir después de ese trabajo de reingeniería y a partir de ahí crecer (y cambiar, si es necesario) juntos. Si lo haces antes puede suponer una resistencia ya que tienes que repartir el enfoque entre los cambios organizativos y el desarrollo de software (perderá siempre el proyecto) y el coste será mayor.

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Mary Poppendieck realiza la siguiente reflexión: “No tome decisiones irreversibles demasiado pronto, retrasa las decisiones de diseño todo lo que sea posible, de manera que cuando las tengas que tomar, lo hagas con la mejor información disponible para hacerlas correctamente”.

Tiene razón, pero lo que pide es difícil. Requiere que el Product Owner tenga una visión sólida del producto, conozca bien el negocio y tenga el apoyo por parte del equipo de desarrollo sobre qué funcionalidades una vez construidas son más costosas de modificar.

Poppendieck, lo que recomienda es que se desarrolle con intención, sabiendo lo que se hace, para de esta forma reducir el número de iteraciones. Aún así, la especulación a veces es inevitable porque el responsable funcional no tendrá claro siempre si la solución que propone es la mejor o qué reacción va a tener el conjunto de usuarios ante las mismas.

El objetivo es conseguir cada vez un mayor valor para el producto con una inversión ajustada a ese incremento. A veces tendremos más éxito que otras, porque equivocar nos equivocaremos ya que el desarrollo del producto es evolutivo y en él nos daremos cuenta no solo de nuevas funcionalidades que son necesarias, sino de algunas ya implementadas que son mejorables.

Por ello, siguiendo las recomendaciones de Poppendieck, el desarrollo debería comenzar por lo más prioritario y dentro de ello por lo que se tenga más claro en ese momento, si se tienen dudas sobre una funcionalidad y se prevé un coste de modificación alto (por sí misma o por su impacto sobre terceros desarrollos), mejor esperar, si se puede, un poco más.

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.

Llega un momento en la evolución de un producto o en un proyecto de desarrollo de software donde echamos en falta todo ese esfuerzo que no se ha aprovechado de manera adecuada, ¿por qué? lo necesitamos ahora o prevemos que lo vamos a necesitar pronto y ya ha desaparecido.

Una de las causas que hacen que el aprovechamiento del esfuerzo no sea óptimo es trabajar con historias de usuario, requisitos o especificaciones que no están claros y en los que existe una probabilidad importante que la solución implementada requiera ser modificada de manera sensible más adelante.

Es mejor invertir el esfuerzo en aquellas tareas donde el retorno de la inversión sea más probable, en donde el efecto sobre el valor del producto sea más inmediato.

Lo que no esté claro debe tratar de solventarse hasta donde se pueda ya que de esta manera se desarrollará con una mayor intención y los ajustes posteriores serán de menor entidad.

Tampoco podemos estar paralizando indefinidamente el desarrollo de una funcionalidad que sea crítica o importante para el sistema pero sí podemos esperar hasta el último momento posible para tratar de que esté lo mejor definida posible.