archivo

Archivo de la etiqueta: adaptabilidad

No hay competencia posible porque el desarrollo de software es inherentemente de naturaleza evolutiva.

El ciclo de vida en cascada es incertidumbre en muchos factores: cumplimiento de las expectativas del usuario, en el índole económico, en los plazos, etc…

¿Acaso no presentan incertidumbre las metodologías ágiles? No es que no las presenten, todo desarrollo de software la tiene, la diferencia está en que en estos casos, si una solución (la correspondiente a una iteración) no cumple las expectativas parcial o completamente, se tardará una iteración en volver a presentar una nueva alternativa al usuario.

¿Acaso no pueden presentar problemas económicos los proyectos que siguen metodologías ágiles? También lo pueden presentar, pero sobre todo dependerá de que el cliente comprenda las reglas del juego, que entienda que una iteración nueva donde se evolucione una funcionalidad repercute en la cuenta del proyecto y que afinar una solución forma parte del propio desarrollo de software. Además, el planteamiento iterativo incremental permite que se pueda disfrutar desde etapas muy tempranas de versiones utilizables por el usuario y válidas en un entorno de producción (o al menos esqueletos andantes con los que puedan ir haciéndose una idea de la forma que está adquiriendo el producto).

¿Y los plazos? En este caso, los plazos son los especificados en cada iteración y se difumina en cierto modo el hecho de tener un producto acabado en un tiempo determinado, porque, ¿qué es un software completamente terminado?.

No quiero decir, aunque lo parezca, que las metodologías ágiles sean la piedra filosofal del desarrollo de software. No lo son porque, entre otras cosas, por encima de las metodologías y los procesos, están las personas que al final son las que hacen buenos o malos los proyectos, además la aplicación de una metodología por sí misma no implica nada, requiere ser bien ejecutada en todos los ámbitos, tanto en la gestión como en el apartado técnico.

Uno de los problemas de los desarrollos siguiendo el ciclo de vida clásico o en cascada es que se tiende a entregar versiones completas de un sistema de información invirtiendo prácticamente todo el presupuesto del proyecto en conseguirla.

¿Problema? Tenemos una aplicación con muchas funcionalidades (cuando no muchos subsistemas) y sobre la cual el usuario empezará a reportar mejoras y correcciones, con el objeto de adaptar el sistema a sus expectativas. Esto no sería problema si estuviera contemplado en el presupuesto, pero lo más normal es que no lo esté y estaremos en una situación de poner en marcha un sistema casi sin recursos, lo que imposibilitará materializar el feedback del usuario.

Esta situación la tendremos incluso con un análisis óptimo del sistema y esto es así porque la naturaleza del software no es predictiva sino adaptativa o evolutiva. Un buen analista conseguirá reducir el margen de error entre la predicción y lo que el usuario realmente quiere (teniendo en cuenta además las contingencias propias de cualquier desarrollo, como que por ejemplo a mitad de la partida cambien las reglas del juego).

Por ese motivo lo mejor es aplicar un enfoque ágil, con una visión iterativa e incremental del sistema, de esa forma un buen trabajo de análisis es más efectivo, se reduce el tiempo en el que pueden ocurrir circunstancias que afecten al desarrollo y permite enfocar los esfuerzos en aspectos concretos del sistema. Es más, soy partidario de que incluso si se prevé que la primera versión del producto se extienda demasiado, se entreguen esqueletos andantes, sobre todo si existe voluntad de los usuarios en participar activamente en el proceso de desarrollo.

De esta forma, con la puesta en marcha paulatina de funcionalidades se puede controlar la existencia de muchos frentes abiertos, ya que la prioridad debe ser que cada módulo liberado del sistema esté acorde a las expectativas del usuario.

Cuando existen muchos frentes abiertos la sensación (y la realidad) es que las circunstancias controlan el proyecto en lugar de ser tú quien lo maneja. Apagar fuegos soluciona problemas a muy corto plazo, pero difícilmente ofrece una solución a futuro.

El prototipado es una técnica aplicable a prácticamente cualquier metodología de desarrollo ya que no es más que concretar en un entregable, que puede ir desde una serie de imágenes (para mostrar como sería el diseño de un formulario) hasta un producto software, las ideas que el usuario va lanzando sobre lo que quiere que la aplicación haga.

En ciertos tipos de ciclos de vida como el clásico o en cascada este tipo de técnica tiene mucho interés porque independientemente de que estas metodologías sean predictivas y no adaptativas, sí que resulta conveniente que por lo menos, de inicio, la diferencia entre lo que el usuario espera y lo que el analista interpreta sea la menor posible.

En metodologías evolutivas como lo son, por ejemplo, RUP o el conjunto de metodologías ágiles, cuando las iteraciones son cortas, la importancia del prototipado disminuye, si bien sigue resultando un instrumento muy útil cuando se trata de abstraer a un programa de ordenador un aspecto de negocio complejo o para intentar obtener la información más precisa posible del usuario, cuando este no tiene muy claro lo que quiere o no lo sabe explicar de manera adecuada.

Sobre el prototipado Larry Bernstein realiza la siguiente reflexión: “El prototipado reduce el tiempo de desarrollo y el coste en un 40%”.

El desarrollo de software está muy lejos de conseguir el éxito a través de la utilización de una bola de cristal. Las metodologías clásicas como el ciclo de vida en cascada, donde existe mucho tiempo desde que se concibe el proyecto hasta que entra en producción presupone que los cambios que se van a producir desde la aprobación del análisis hasta la implantación van a ser mínimos, algo que todos sabemos que dista mucho de ser real.

Todos hemos sido, somos y seremos víctimas de los desarrollos en cascada porque en muchas ocasiones estamos obligados a afrontar los proyectos de esa forma. Es una pena porque la naturaleza del desarrollo de software es adaptativa de manera que mediante aproximaciones sucesivas si se trabaja de manera adecuada y los usuarios colaboran, cada vez el producto resultante estará más próximo a las expectativas del usuario, manteniendo unos umbrales de calidad por encima del mínimo exigible.

Sobre este aspecto, David Lorge Parnas, realiza la siguiente reflexión (traducción libre): “La imagen de un desarrollador obteniendo el diseño de un software a partir de un conjunto de requisitos racional y sin errores es muy irreal. Ningún sistema ha sido construido de esa manera y probablemente nunca se construirán. Incluso el desarrollo de programas pequeños que se muestran en libros y artículos son irreales, ya que son revisados y pulidos hasta que el autor nos muestra lo que el desearía haber hecho y no lo que realmente hizo”.

Siempre estaré en contra de proyectos de desarrollo de software donde el presupuesto para realizarlo sea claramente inferior al necesario. Esto ha hecho mucho daño a nuestra profesión como también lo ha hecho proponer sistemáticamente ofertas muy por debajo del precio de mercado.

Mientras exista mayoritariamente crisis del software, con el máximo exponente en los Death March Project, nos costará darle a nuestro trabajo el valor que realmente tiene.

Los presupuestos en los proyectos deben ser holgados y esa holgura depende de la propia naturaleza de las tareas a realizar y del contexto en el que se desarrollen las mismas.

Al fin y al cabo los proyectos tienen siempre un coste de mantenimiento, la holgura es simplemente deslizar parte de ese presupuesto de mantenimiento al propio de desarrollo de manera que se pueda evolucionar el producto de manera adecuada, adaptándolo paulatinamente a las necesidades del usuario.

Pero, ¿cuándo un presupuesto es excesivo? Cuando la cantidad de trabajo que se realiza con él es inferior al acabado y calidad que debería tener el proyecto software en el contexto en que se ha realizado. Esto implica que podemos tener presupuestos excesivos incluso en proyectos donde el mismo es muy ajustado o incluso por debajo de lo necesario.

Más dinero no implica hacer las cosas mejor, la Ley de Parkinson es una muestra reveladora de lo que pasa cuando existe mucho presupuesto y no se enfoca adecuadamente el trabajo a realizar.

David (Dave) Lorge Parnas es un profesional canadiense pionero en el campo de la ingeniería del software de la cual ha sido un ferviente defensor a lo largo de su carrera. Ha recibido numerosos premios a lo largo de su carrera y ha sido profesor en universidades de diferentes países del mundo.

El desarrollo de software se realiza para organizaciones que están en continuo movimiento: puede cambiar el mercado, los procesos, los usuarios, los responsables técnicos, etc…, a lo que hay que sumar que se intentan abstraer procesos que se realizan en el mundo real a un programa de ordenador y no es nada fácil ese proceso porque los que definen el sistema no tienen claro, por regla general, lo que quieren realmente (tienen una idea, pero hasta que no la ven reflejada, no terminan por matizarla).

La naturaleza del software es adaptativa, mediante aproximaciones y evoluciones se consiguen alcanzar productos que satisfacen las necesidades del usuario, a través del feedback que se obtiene de los mismos una vez que hacen uso del sistema. Los principios ágiles definen ese marco (que también se tiene en cuenta en metodologías del proceso unificado como RUP), si bien, nuestra propia experiencia personal nos dirigirá de alguna u otra forma y de forma paulatina hacia enfoques iterativos e incrementales en lugar de ciclos de vida clásico o en cascada.

Dave Parnas, sobre este tema realiza la siguiente reflexión (traducción libre): “Por regla general, los sistemas software no funcionan adecuadamente hasta que han sido utilizados y han fallado repetidamente en entornos reales”.

El desarrollo siguiendo los principios ágiles tiene como objetivo principal conseguir la satisfacción del usuario a través del cumplimiento de sus expectativas.

El modelado de un proceso suele resultar complejo en el sentido de que se están informatizando unas dinámicas de trabajo que hasta ahora se realizaban utilizando otros instrumentos (incluyendo productos informáticos como por ejemplo soluciones ofimáticas para realizar determinadas tareas).

Resulta muy complicado en la mayoría de los casos acertar a la primera con una solución que satisfaga al usuario y sea productiva. La solución más adecuada se consigue a través del feedback.

Las metodologías unificadas como RUP o las ágiles tienen en cuenta esta dinámica de funcionamiento como algo natural en el desarrollo de software ya que tiene una naturaleza adaptativa y no predictiva (que es el enfoque que siguen las metodologías tradicionales, como el ciclo de vida clásico o en cascada).

Aceptar esta realidad no es perder el tiempo ya que lo que hace es aproximarte más hacia el objetivo. Perder el tiempo es desarrollar funcionalidades que no se van a utilizar o realizar documentación que no tiene ningún tipo de utilidad.