archivo

Archivo de la etiqueta: ágil

No se trata de improvisar, sino de ser flexible. Muchas veces los problemas en las arquitecturas y en el desarrollo de software son difíciles de resolver en tiempo de definición. No es cuestión de programar mediante prueba y error, de programar por permutación, siempre es conveniente reflexionar sobre la solución a aplicar tratando de reducir el nivel de abstracción con el que inicialmente se enfoca la solución.

Me parece muy interesante la siguiente reflexión de Christopher Alexander, Sara Ishikawa y Murray Silverstein en su libro “A Pattern Language”: “Todas esas decisiones de diseño detallado que nunca pueden ser resueltas con antelación en el papel, se pueden hacer durante el proceso de construcción”.

Esta cita está por encima de las metodologías o marcos de trabajo, es una forma de entender el desarrollo de software, de tratar de ser flexible y ser consciente de que no todo puede o debe ser predecible.

Ron Jeffries, Ann Anderson y Chet Hendrickson en el libro “Extreme Programming Installed” hacen la siguiente reflexión: “Si tu cliente sabe ahora exactamente lo que quiere, y si en el momento en que haya terminado todavía va a querer lo mismo, puede ser la primera vez en la historia del software que esto ha sucedido. Probablemente habrá un premio para ti en algún sitio”.

Está bien que estos autores lo pongan en su libro pero probablemente tu propia experiencia te hará llegar a la misma conclusión.

La aparición de la agilidad y métodos de trabajo potencialmente ágiles (siempre os digo que realmente lo que la hacen ágil o no es la actitud de las personas en el proyecto) no fue un capricho, sino una respuesta a unos métodos de trabajo que no respondían a una realidad que se repetía de manera insistente en los proyectos de desarrollo de software y que se basaba generalmente en el ciclo de vida tradicional.

Pero las metodologías, marcos o estrategias de desarrollo son solo herramientas, es necesario entender el fundamento del enfoque iterativo incremental y se puede resumir perfectamente en la cita en la que se basa este artículo.

Los usuarios pueden tener claro lo que tienen (cosa que está por ver) e incluso que el contexto del proyecto se pueda mantener de forma más o menos estable y no influya excesivamente en la línea de desarrollo del producto pero lo más probable es que los usuarios vayan haciendo ajustes en su visión del producto conforme se trabaja con más detalle en el mismo y conforme van viendo versiones del producto mientras se está desarrollando o mientras se entregan sprints y eso es debido a que es muy difícil abstraer lo que se cree que se quiere, a algo concreto.

Si pese a que sois desarrolladores habéis sido usuarios (incluso vuestros propios usuarios) os habréis encontrado muy probablemente con situaciones en la que vuestra idea inicial del desarrollo ha sufrido cambios sensibles.

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.

Si se fija al final del sprint una demo o una entrega es necesario dedicar tiempo al testing cuando se hayan finalizado las tareas fijadas en la iteración (previamente los mismos desarrolladores han debido probar el código que han hecho y si hay equipo de testing han debido colaborar en esas tareas conforme se va trabajando) además de otras tareas como puede ser la propia preparación de la entrega (si hay paso a producción o si la instalación en un entorno de demo lo hace un equipo distinto).

Esto quiere decir que la fecha final de los trabajos de desarrollo en la iteración debe ser anterior a la fecha de finalización del sprint. Otra posibilidad es considerar esas tareas de testing como una actividad más dentro de la pila de sprint. El tiempo que se debe dedicar a esta actividad no debe ser exclusivamente el necesario para hacer el testing sino que hay que prever un tiempo para corregir incidencias, ese tiempo lo determinará el equipo en función de la deuda técnica, de la complejidad de las funcionalidades desarrolladas en el sprint y del estado actual del equipo de proyecto (si ha habido cambios en el equipo existirán más posibilidades de que se hayan producido incidencias).

En cualquiera de los dos casos se reduce la cantidad de trabajo que se puede abordar en la iteración pero siempre será mejor eso que entregar software deficiente porque supondrá una resistencia para la próxima (o próximas) iteraciones.

He mantenido muchísimas conversaciones con defensores de enfoques clásicos de desarrollo de software sobre este asunto y siempre es lo mismo, que se basan casi siempre en que no hay motivos por los cuales un sistema de software deba seguir una metodología o unos procesos diferentes que para construir un edificio y que no pensar eso es no creer en la ingeniería del software.

Prácticamente toda mi experiencia laboral se ha centrado en enfoques clásicos por lo que tengo criterio para tener una opinión totalmente contraria a eso. No hablo de teorías, hablo de realidades.

Y la realidad es que el software es flexible, es adaptable, es evolucionable y para que funcione tienes que programar hasta el más mínimo detalle. Un edificio no es flexible por lo que su posible adaptación (estructural) es mucho más compleja y costosa y no requiere tanto nivel de detalle para poder ser utilizado.

Precisamente por eso los procesos para la construcción son más rígidos y los cambios sobre las especificaciones iniciales son más por motivos técnicos que funcionales.

Si el software tiene esas características, ¿por qué ignorarlas?, ¿por qué aplicar un planteamiento predictivo (planos) cuando es posible aplicar un planteamiento evolutivo?, es más, ¿por qué utilizar un enfoque predictivo si la propia realidad del proyecto aconseja el incremento y la iteración?.

Para Ken Auer y Roy Miller: “Cuando se utiliza un proceso destinado a la construcción de cosas inflexibles como puentes para construir cosas flexibles como el software, no debe sorprender que más tarde el coste del cambio sea mayor”.

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”.

La transformación, al adaptación al cambio, la aplicación de un nuevo enfoque, implica el abandono de un modelo, de una serie de prácticas, de una cierta manera de hacer las cosas.

No se trata de abandonarlo todo, no se trata de empezar de nuevo, sino de saber que el cambio solo viene a través del cambio y que, por tanto, no es posible alcanzarlo si en lugar de mirar adelante, no dejas de mirar atrás. Llévate en tu mochila todo tu conocimiento y experiencias y todo aquello que pienses que te puede resultar de utilidad en el viaje, pero ten en cuenta que su capacidad es limitada y que tendrás que renunciar o prescindir de prácticas o conductas antiguas para dar espacio a lo que viene a sustituirlas.

La agilidad requiere tener esa capacidad. En el proceso de adaptación al cambio tendrás que mirar dentro de ti, dentro de los proyectos en los que has participado y verás cosas que no te gustarán, de errores que cometiste y que te hacen ponerte las manos sobre la cara, debes entender que es parte del proceso y que nadie es infalible y debes comprender que han sido parte del camino que te ha llevado hasta aquí y que te han dado el suficiente conocimiento y madurez para ser mejor.