Desarrollo de software. Limitar el valor no debe ser el objetivo

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.

Kent Beck. El miedo como resistencia al éxito.

Es cierto que hay proyectos que entran en unas espirales que hace que prácticamente parezca eterno el tránsito entre su inicio y la puesta en producción de una primera versión del mismo.

Es muy mal síntoma (en términos generales) que un proyecto tarde mucho en poner una primera versión en producción. Es más, de primera mano os puedo decir que no conozco ninguno que tardando demasiado haya sido un éxito.

Tarde significa más tiempo en obtener feedback, más coste para evolucionar el producto (incluso habiendo cuidado la deuda técnica), llegar tarde al momento más adecuado para poner en marcha el producto y la puesta en marcha del sistema con una tecnología muchos meses anterior (incluso años anterior) a la que actualmente se desarrolla en la organización.

Muchas veces son las propias contingencias del proyecto las que llevan a eso pero en otros muchos casos somos los propios desarrolladores (utilizando como excusa esas contingencias o no) los que retrasamos la puesta en producción por ese afán de perfeccionar algo que hasta que no se utilice realmente seguirá siendo abstracto (o si es algo concreto el feedback no tiene la misma fuerza).

Me parece muy interesante la siguiente reflexión de Kent Beck como punto final a este artículo: “Prepárate para el éxito. No te protejas del éxito reteniéndolo. Hazlo lo mejor posible y después asume las consecuencias”.

Desarrollo de software. ¿Es el enfoque iterativo incremental una sucesión de cascadas?

Se puede ver de esa manera pero es tan diferente el enfoque que ambos términos chirrían. Es cierto que cuando te planteas una iteración haces todas las actividades que sean necesarias sobre cada historia de usuario, no obstante la principal diferencia la tenemos en que al plantearse un desarrollo por incrementos, existe la posibilidad de realizar evaluaciones, sobre versiones en funcionamiento, desde el punto de vista del resultado (feedback) y de cómo se hacen las cosas (retrospectiva), las cuales permiten ir incrementando el valor del producto y adaptarse a los cambios que puedan producirse tanto desde el punto de vista del producto como de los métodos y organización del trabajo.

En un enfoque clásico o en cascada pueden existir revisiones intermedias del producto (más comunes) y también se puede obtener feedbacks y realizar retrospectivas (menos comunes), aplicar esas estrategias que podríamos considerar ágiles tienen sus ventajas, sin olvidar que siguen sin solucionar los principales inconveniente del desarrollo en cascada:

- El tiempo de puesta en marcha de versiones efectivas del producto.
- Su orientación al cumplimiento de una agenda: costes y plazos, lo que resta flexibilidad a la hora de realizar cambios sobre las especificaciones iniciales.

Desarrollo de software. Maleabilidad

Siempre es posible desarrollar un software aplicando las mismas técnicas de gestión que para construir un puente, sin embargo estaríamos prescindiendo de una de sus principales características, su maleabilidad, lo que le permite adaptarse al cambio y modificar criterios con un coste asumible (siempre y cuando se tenga la deuda técnica bajo control).

Cuando tienes un puente a medio construir, tomar la decisión de poner un carril más en cada dirección puede ser prácticamente imposible o requerir una inversión muy superior a la que hubiera sido necesaria si se hubiera tenido en cuenta desde el principio.

En el desarrollo de software no es así. Es cierto que el cambio tiene un coste pero no es equiparable al de las construcciones físicas.

Renunciamos a la maleabilidad del software cuando lo importante es el cumplimiento de una agenda, es decir, se prioriza mantener previsiones de costes y plazos sobre la posibilidad de entregar un producto con mayor valor. Hay que analizar cada circunstancia y es posible que no haya otra alternativa que cumplir con la agenda: no es posible dedicar mayor presupuesto al proyecto y/o modificar los plazos, siempre y cuando se entienda que no es posible la cuadratura del círculo: cumplir agendas y tener al producto sometido a continuos cambios de criterio.

Mi apuesta es incrementar el valor del producto que se pone en producción y eso requiere un enfoque iterativo incremental para aprovechar el feedback del usuario. Esto tiene implicaciones presupuestarias que se solucionarían bien teniendo abierto el presupuesto del proyecto o si está cerrado centrarse en que las funcionalidades prioritarias vayan bien (esto último siempre y cuando no nos encontremos en una situación de Death March Project en la cual todo será mucho más complicado).

Jim Highsmith. El aprendizaje es la esencia de la iteración

Jim Highsmith en su libro “Adaptive Software Development” realiza la siguiente reflexión: “El aprendizaje rápido requiere iteraciones: intentar, revisar, repetir”.

Aprender sobre hechos y no trabajar indefinidamente sobre hipótesis es para mi la esencia de la iteración.

Es cierto que la hipótesis dura (para bien, para mal o para regular) hasta que tenemos el resultado definitivo del proyecto en producción ya que hasta que de manera completa no se utiliza en un contexto real no podemos medir con precisión la satisfacción con el producto pero también lo es que la niebla se despeja poco a poco conforme el usuario va probando versiones parciales del mismo (en producción real preferiblemente) y va proporcionando su feedback.

En este proceso no solo aprende el desarrollador sino que también aprende el usuario porque de lo que cree que quiere (que no deja de ser una idea abstracta y a gran escala) a la solución que realmente le satisfaría, hay un largo trecho.

Desarrollo de software. ¿Por qué es mejor tener esa visión más global del negocio?

Sin esa visión global estás construyendo el sistema a base de retales de manera que funcionalidades que podrían tener una solución general, la tienen de manera particular y eso de lugar a más pantallas, más tablas, más código. Si el sistema es grande y se produce muchas veces este problema estamos haciendo un sistema más complejo, con un mayor coste, más difícil de mantener y más complicado de administrar (a nivel de aplicación).

Como decía en el artículo de ayer, no se trata de hacer un análisis completo del sistema, no me refiero a eso, sino a tener una visión global de qué es lo que se quiere hacer, no se requiere por tanto la formalidad de un análisis de un ciclo de vida clásico y tampoco seguir sus etapas.

Se puede analizar y empezar a construir, así vamos obteniendo feedback del usuario que nos será de mucha utilidad porque esa visión global que nos la da el usuario y el estudio de sistemas de información que viniera utilizando antes para ese mismo proceso (u otro similar existente en otra organización) sigue estando basada en un concepción abstracta del sistema y hasta que el usuario no empieza a ver cosas tangibles no saldrán a la luz comportamientos y funcionalidades que formaban parte de sus expectativas pero que todavía no habían salido a la superficie.

Pete McBreen. Iteración y feedback como estrategia para mejorar el producto

Comenta Pete McBreen que: “Con un ciclo corto de feedback es fácil aprender qué funciona y qué no”.

Los usuarios no tienen claro que es lo que quieren hasta fases muy avanzadas del proyecto. Al principio del mismo tienen ideas generales (por mucho que digan que lo tienen clarísimo ya que una cosa es la teoría y otra la realidad) relacionadas con el problema que quiere solucionar o con el proceso que quiere informatizar.

Si esperamos demasiado, si el paso a producción se eterniza o si el usuario no tiene posibilidad de trabajar con el sistema que se está desarrollando nos encontraremos con que su feedback vendrá muy tarde precisamente cuando el presupuesto esté prácticamente agotado y cuando el coste el cambio sea importante. No me invento nada, lo hemos vivido (y vivimos) prácticamente todos.

Hay que intentar conseguir ese feedback cuanto antes, tiene más intención si el sistema está en producción (aunque sea solo con una parte del sistema en funcionamiento) ya que ahí se puede apreciar el impacto real que tiene en el negocio, es decir, se puede ver qué ha funcionado y qué no.

Si son necesarias varias iteraciones para tener pasar el producto a producción (aunque sea parcialmente) utilicemos otras estrategias (que requerirán una colaboración y un compromiso fuerte del usuario) para obtener ese feedback al final de cada iteración.

Diferencia entre el ciclo de vida iterativo y el ciclo de vida iterativo incremental

En un ciclo de vida iterativo (o en un enfoque iterativo), se trabaja sobre un conjunto de funcionalidades y se perfeccionan, sin incluir nuevas funcionalidades.

En el ciclo de vida iterativo incremental se van añadiendo funcionalidades.

En el enfoque iterativo existe feedback, se pueden realizar retrospectivas, pero se trabaja sobre componentes, subsistemas o productos completos.

Se puede considerar que el enfoque iterativo podría ser una siguiente fase a la cascada: “tengo una primera versión del producto, vamos a mejorarlo”.

Es un modelo eminentemente teórico porque incluso en modelos que prevén unos requisitos (posteriores funcionalidades) estables, como el clásico, hay variaciones sobre las especificaciones iniciales.

Desarrollo de software. La visión del producto es necesaria pero no requiere una especificación detallada del sistema

Recuerdo un día en el que charlaba con otra persona sobre las bondades e inconvenientes de las metodologías clásicas y los enfoques ágiles. Me decía que en su organización se había perdido mucho dinero en proyectos desarrollados con metodologías ágiles, antes de preguntarle más detalles, le pregunté que cuánto dinero habían perdido con las cascadas y obtuve el silencio por respuesta.

Dado que por ahí no iba a conseguir avanzar mucho, decidí cuestionarle sobre cómo se habían aplicado las metodologías ágiles y la verdad es que tampoco supo darme mucha más información, en base a lo que me decía interpreté que se aplicaron ciclos de vidas iterativos incrementales con sprints de corta y media duración.

Le comenté que la aplicación de ese ciclo de vida era un primer paso pero que no era suficiente para considerar el enfoque cómo ágil ya que no solo se trataba de aplicar una metodología concreta, sino que detrás debe haber una base conceptual asimilada por buena parte de los intervinientes.

Le pregunté que por qué creía que esos proyectos fracasaron y la respuesta fue que se desarrollaba sin tener una visión clara del sistema a desarrollar, lo que hacía que en cada iteración se tuviera que rehacer buena parte de lo desarrollado en la anterior.

Antes de indicarle mi diagnóstico (y advertirle que para poder ser más preciso necesitaría más información y hablar con más personas), siguió hablando y me comentó que el problema era debido a que no se había hecho un estudio exhaustivo de lo que se quería y eso se obtenía a partir de un catálogo de requisitos.

Le dije que no se necesita llegar a tanto para tener una visión del producto y que el catálogo de requisitos es solo una ilusión, un traslado a un documento de una visión abstracta de lo que se quiere, que probablemente se encuentra lejos de la solución concreta que los usuarios necesitan y que la aproximación a la misma se conseguía a través del feedback.

Es cierto que se necesita tener una visión de lo que se quiere hacer para poder desarrollar con la mayor intención posible pero también que el feedback es inevitable y necesario.

Dave Thomas. Todo es mantenimiento

El desarrollo de software es un continuo adelante y detrás no solo fruto del feedback o del cambios en las especificaciones sino también como parte del proceso de construcción. ¿Quién no tiene que corregir errores?, ¿quién no mejora una sección del código que no termina de convencerle?, ¿quién no tiene que realizar ajustes como consecuencia de evolución solicitada por el área usuaria?.

Este tema lo traté en artículo: “¿Qué es el mantenimiento?” y lo vuelvo a hacer ahora porque realmente el hecho de que en el desarrollo de software la frontera entre la construcción y el mantenimiento sea tan débil (por no decir inexistente) me parece muy interesante ya que refleja un aspecto inherente al desarrollo de software como es su naturaleza evolutiva, es decir, el sistema se desarrolla poco a poco y con el paso del tiempo va adquiriendo forma, en todo ese proceso hay evolución y no solo por los aspectos funcionales (o no funcionales) que se van añadiendo, modificando o eliminando sino porque en ese proceso el software también cambia y no necesariamente para cambiar una funcionalidad (refactorización, corrección de incidencias, etc…).

Esta naturaleza evolutiva junto a otra característica inherente al proceso de desarrollo como es la incertidumbre ponen de manifiesto que el software estará sometido a cambios a lo largo del proyecto (por muy diversas causas) y que será necesario habilitar los mecanismos necesarios para que la adaptación a los mismos se realice lo antes posible.

Me gusta el enfoque que Dave Thomas da sobre este tema (traducción libre): “Si nos fijamos en el tiempo que pasamos programando, escribimos un poco y luego volvemos atrás y hacemos un cambio. O volvemos atrás y corregimos una incidencia. O lo tiras todo o lo reemplazas por otra cosa”.