archivo

Archivo de la etiqueta: ciclo de vida iterativo incremental

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.

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

Si se orienta el desarrollo a sprints (hay que tener en cuenta que el enfoque iterativo incremental es en sí un concepto más amplio) es, entre otros motivos, para conseguir un ritmo sostenible en el desarrollo.

Por eso cada sprint requiere tener preparada de antemano la materia prima, es decir, todos los inputs que necesita para poder ser completado, de lo contrario se tendrá que invertir tiempo en él para obtener esa materia prima, con el riesgo de producirse bloqueos por falta de esas entradas, lo que lo hará menos productivo y menos predecible en cuanto al cumplimiento de los compromisos.

Nos quejamos muchas veces y con razón de la falta de medios económicos para llevar a cabo el proyecto (acorde a las expectativas puestas en él y los plazos) y también de la falta de colaboración del área usuaria. Sobre esto último pocas veces nos paramos a pensar en los motivos que hacen que los usuarios no colaboren.

Uno de ellos puede ser precisamente la falta de medios para proporcionarnos la información y entregables que, una vez interpretados, conforman la materia prima de cada sprint. Es decir, muchas veces el product owner quiere pero no puede.

Se sobreentiende que quien contrata el trabajo ha tenido en cuenta esa carga de trabajo adicional (que en función del tipo de proyecto puede ser muy grande para las personas implicadas), sin embargo no es lo normal, ya que se piensa que con apoyos puntuales es suficiente, creyendo que el equipo de proyecto puede con todo y no, no puede, y si me apuráis, no debe, porque la carga de especificación del sistema debe recaer en el área usuaria.

Las consecuencias de esto es que determinadas tareas del sprint no estarán lo suficientemente definidas y eso hace mucho daño a esta dinámica de trabajo, tanto que nos deberíamos plantear, probablemente, objetivos menos ambiciosos.

Os indico a continuación algunas alternativas y aunque soy de la opinión de intentar reconducir la situación, no siempre va a ser posible:

– Adecuar la capacidad del equipo de proyecto a la carga del área usuaria. De nada vale tener una maquinaria capaz de producir x productos al día si solo entra material para producir x/4 productos.

– Plantear un enfoque iterativo incremental con fases de definición (con el nivel de detalle suficiente para el proyecto y la iteración) entre sprints. En este caso es más impredecible la duración de la fase de análisis pero más predecible la construcción.

– No plantear sprints propiamente dichos y aplicar estrategias de gestión del flujo de trabajo y del WIP (Work in progress), como por ejemplo, definiendo límites en el número de elementos terminados y no pasados a producción o dejando ese aspecto abierto y limitando el número de tareas en fase de análisis.

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

– La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

– Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

– Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

– Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

– No estima quien va a realizar el trabajo.

– La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

No hay mejor formar de gestionar las expectativas del área funcional o del cliente que evitando las sorpresas. Es como jugar a las cartas conociendo las del resto de jugadores y eso debería ser un proyecto de desarrollo de software, un conjunto de personas, equipos y organizaciones que trabajan con respecto a los demás de forma transparente (y esto es perfectamente compatible con los intereses particulares o de empresa que puedan existir).

En los proyectos en los que trabajo tengo como objetivo minimizar las sorpresas, gestionando de esta forma las expectativas del área usuaria desde el mismo momento en que puede haber un cambio en las mismas. Casi nunca gusta que acortes alcances pero te aseguro que es mucho mejor negociar en esas circunstancias que cuando, sin margen de reacción, no cumples los compromisos con el usuario.

La confianza es fundamental en el desarrollo de software y más en proyectos con la intensidad que requieren los enfoques iterativos incrementales, por ese motivo es absolutamente necesario gestionar las expectativas, modularlas a la realidad del proyecto.

Ocultar el estado real del proyecto o de un sprint no sirve para nada porque al final, más pronto o más tarde se termina descubriendo el pastel, tal vez todo salga a la luz después de haber terminado los trabajos, pero esa huida hacia adelante termina pasando factura si quieres volver a seguir trabajando con ese cliente.

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.

Resulta muy tentador comenzar una primera iteración prácticamente desde que se ha dado el pistoletazo de salida al proyecto.

Depende del proyecto, efectivamente. Si se trata de un nuevo aporte económico a otro ya existente y el equipo ha permanecido más o menos estable (tanto por parte de los desarrolladores como de los usuarios) casi que se puede empezar desde el principio, salvo que la evolución a realizar requiera hacer una revisión de la visión que se tenía del producto hasta la fecha y de lo que se preveía que iba a ser su devenir.

Sin embargo, para nuevos desarrollos, para evoluciones significativas de un sistema o para cambios significativos en el equipo de personas que intervienen en el mismo, es necesario hacer una parada para construir una imagen mental de lo que se quiere y que se traducirá en entradas en la pila de producto (que luego se refinará y mejorará conforme vaya avanzando el desarrollo y todas las partes vayan aprendiendo más y más porque las ideas al materializarse y cobrar forma requerirán ajustes y sugerirán algunos cambios de enfoque).

Esta etapa se llama exploración en XP y me parece acertada su denominación, ya que además, contempla la posibilidad de evaluar la tecnología y productos a utilizar durante el proceso de desarrollo.

Ahora bien, esta etapa no debe eternizarse y no conviene traspasar la frontera entre lo que es saber qué es lo que se quiere y obtener un análisis de requisitos detallado (digo que no conviene porque cada proyecto es diferente y tenemos que estar abierto a excepciones) porque de lo contrario habremos invertido (probablemente) esfuerzo que no va a retornar en beneficios, ya que todos sabemos que en el momento en que el usuario empiece a ver producto construido empezará a modificar las bases establecidas.

Tener una visión del producto es otro factor más para desarrollar con intención ya que permite tanto por parte del usuario como por la nuestra tener en cuenta más factores y esto se consigue viendo el producto y los problemas desde una escala más amplia.

Recomiendo la lectura del artículo: Preparando el primer sprint.

Tanto a los products owners como a los desarrolladores nos encantaría poder hacer y acertar a la primera la funcionalidad completa de un determinado objetivo o módulo que se quiera implementar en una aplicación, pero pocas veces sucede esa circunstancia, ya que resulta muy complicado dar con una solución en la que se haya “traducido” perfectamente una idea abstracta y compleja que el product owner tiene en mente (y además, y por lo general, de manera incompleta y/o que no cuenta con todos los detalles), teniendo en cuenta, además, que, en algunos casos, estas funcionalidades tendrán la suficiente complejidad y/o tamaño como para que no quepan en un sprint.

Tratar de acertar a la primera tiene un riesgo importante, ya que puede dar lugar a que buena parte del esfuerzo invertido quede desaprovechado y a que tengamos un producto con una mayor deuda técnica y, por tanto, más complejo de mantener.

¿Que puede resultar más aconsejable? Tratar de acercarnos a una solución que cumpla las expectativas (no hablo de soluciones ideales) mediante aproximaciones sucesivas.

De esta forma el margen de error es más pequeño y ofrece la posibilidad de realizar ajustes que parten de una base concreta, lo que va a permitir que el feedback sea más efectivo.

Trabajar de esta manera requiere paciencia porque tal vez se tarde más de lo deseable en conseguir una solución completa pero a cambio el resultado obtenido tendrá más probabilidades de adecuarse a las expectativas de los usuarios siempre y claro, el product owner haya acertado en sus decisiones y los desarrolladores hayan construido una solución adecuada teniendo en cuenta también aspectos no funcionales.

Por otro lado, es muy probable que también se desperdicie esfuerzo de esta forma (el feedback dará lugar a modificaciones) pero por regla general será inferior al que se perdería tratando de trabajar sobre la solución completa de manera iterativa o realizando parches que muy probablemente no terminen de satisfacer las expectativas de los usuarios y que terminan siendo muy costosos en comparación con los resultados obtenidos.

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.