archivo

Archivo de la etiqueta: adaptativo

En las relaciones cliente/proveedor, uno de los aspectos que más complicado resulta a la hora de enfocar un proyecto siguiendo un enfoque iterativo incremental lo tenemos en el marco contractual.

Teniendo en cuenta la incertidumbre que existe en el proceso de desarrollo de software y que el objetivo final debería ser cumplir las expectativas de los usuarios a los que va dirigida la aplicación, la situación ideal sería ir facturando por iteración hasta conseguir la versión final del producto.

Es decir, a priori, no tendríamos ni límite presupuestario ni límite de plazos. Muy pocos clientes aceptarían un marco de trabajo como ese, entre otras cosas porque ellos sí que se tienen que ceñir a un presupuesto y en la mayoría de las ocasiones (con mayor o menos flexibilidad) a unos plazos.

Por tanto, va a resultar necesario adaptar los trabajos a un marco limitado en presupuesto y también en plazos, pero resulta absolutamente necesario que el cliente sea consciente de qué es lo que se va ejecutar con ese presupuesto y que el proceso de desarrollo de software es adaptativo, evolutivo y bajo incertidumbre o lo que es lo mismo, que el planteamiento inicial que se haga puede variar (de hecho variará).

Se pueden aplicar diferentes fórmulas para realizar una contrato ágil, en próximos artículos veremos algunas posibilidades.

Han pasado casi tres años desde que escribí una serie de artículos dedicados a la definición de un plan de sistemas de información:

- Plan de sistemas de información I
- Plan de sistemas de información II
- Plan de sistemas de información III
- Plan de sistemas de información IV
- Plan de sistemas de información V
- Plan de sistemas de información VI
- Plan de sistemas de información VII
- Plan de sistemas de información VIII
- Plan de sistemas de información IX

Llevaba pensando un tiempo pensando en escribir un nuevo artículo sobre los planes de sistemas, haciendo hincapié en uno de sus principales problemas: su carácter eminentemente predictivo, basado en un fotografía de la organización en un momento dado, algo que no se ajusta a la realidad de las entidades.

En resumidas cuentas, presenta el mismo problema que las metodologías software basadas en métodos predictivos como el ciclo de vida en cascada, lo que hoy puede ser válido (si es que la especificación realizada es buena, algo que no es sencillo), mañana puede dejar de serlo porque las condiciones de partida han variado sensiblemente.

Finalmente, unas series de tweets que leí ayer a Jon Kern (uno de los padres del manifiesto ágil) sobre gobierno ágil, me animaron a escribir sobre este asunto.

Básicamente Kern expresaba la dificultad de establecer planes de gobierno a largo plazo ante una situación basada en la incertidumbre.

Un plan de sistemas no es más que un plan de gobierno de los sistemas de información de una organización, en la que se estudia una situación inicial, se determina un modelo objetivo al que se quiere llegar y un plan de acción que nos permita llegar desde esa situación inicial al modelo objetivo. Se suelen definir con un período de vigencia de tres o cuatro años.

Como ya recomendaba cuando escribí esos artículos, el tránsito desde la situación actual a una situación que se aproxime a lo que consideramos como ideal (dadas las características de nuestra organización y su contexto), probablemente si la organización no se encuentra lo suficientemente madura a nivel de procesos relacionados con el desarrollo de software y el gobierno TIC, requiera de la realización de varios planes de sistemas de información.

Este enfoque iterativo incremental tiene en esencia fundamentos ágiles, sin embargo, el tiempo que hay entre planes de sistemas, difumina casi todos los atisbos de agilidad que pudieran existir.

Mi recomendación sería en primer lugar, disminuir el período de vigencia de un plan de sistemas, situándolo a lo sumo en dos años y existiendo la posibilidad de que tenga una vigencia anual si existen riesgos ciertos de cambios de contexto o se han producidos cambios no previstos en la organización, procesos, de la organización hacia el exterior, etc… En cualquier caso, tanto si se decide que la vigencia sea de dos años, como de uno, hay que estar abiertos a reorganizar las prioridades si fuera preciso, para poder adaptarnos a cualquier variación de las condiciones iniciales o para ayudar a la organización a conseguir algún objetivo operativo o táctico de mayor trascendencia.

Por otro lado, también recomiendo, ¿por qué no?, plantear desde el principio hacia dónde queremos llegar, pero no con el presente plan de sistemas, sino a nivel estratégico definiendo cuál es la política de sistemas de información que sería deseable tener y realizando ajustes a ese alcance final en cada plan de sistemas, el cual, a su vez pretenderá recorrer parte de ese camino que nos separa de esa meta.

En muchas ocasiones, considerar algo como una pérdida de tiempo es una cuestión de percepción, es decir, para alguien puede serlo, para otros no (y en medio, toda una escala de grises).

En otros casos, no hay lugar a la interpretación, se trata de pérdidas de tiempo.

Comentan Tom DeMarco y Tim Lister que: “El mayor pecado de la gestión es hacer perder el tiempo a la gente”, esto unido a su reflexión sobre los días de trabajo que se pierden, nos debe hacer pensar sobre algunas decisiones que provocan pérdidas de tiempo (a las que habría que añadir todos los malos hábitos productivos que tengamos a nivel de organización e individual).

Una mala selección de prioridades suponen una pérdida de tiempo, ya que estamos dedicando nuestro esfuerzo y atención (enfoque) a una serie de tareas y funcionalidades que no son críticas, dejando de lado otras que sí lo son. Sobre esto, se podría pensar que al fin y al cabo son cosas que tarde o temprano habría que hacer, sin embargo, la incertidumbre de los proyectos y las limitaciones presupuestarias y de tiempo no aseguran que lo que hemos dejado para después se pueda llegar a hacer, por lo que lo mejor es empezar siempre por lo que realmente es importante y trascendente. A esto, habría que sumar el hecho de lo que se deja de ganar o producir por realizar más tarde las tareas y funcionalidades que realmente tienen un impacto.

Una mala selección de funcionalidades también suponen una pérdida de tiempo. Es importante matizar esto.

El desarrollo de software es de naturaleza evolutiva, donde la aproximación a la solución que satisfaga a las expectativas de los usuarios se llega generalmente (que no siempre) mediante aproximaciones iterativas e incrementales. Bajo esta perspectiva, basada en el feedback del usuario (y de todos los stakeholders en cada iteración), no acertar en la definición de una funcionalidad forma parte en sí de la propia naturaleza del desarrollo y por tanto no se debería considerar una pérdida de tiempo. También es importante matizar esto.

El desarrollo iterativo incremental no es lo mismo que un ensayo y error a ciegas, sino que cada intento debe tener una intención y debe ser resultado de un proceso previo de reflexión. Claro que se puede fallar, claro que pueden ser necesarios ajustes, sin embargo, no se trata de probar por probar porque en este caso sí que estamos perdiendo el tiempo y capacidad para desarrollar otras funcionalidades prioritarias, ya que estamos invirtiendo el esfuerzo en dar vueltas sobre lo mismo.

Es importante también un enfoque minimalista en el desarrollo, evitando funcionalidades que finalmente no se van a utilizar o que van a tener un uso residual. El desarrollo de estas utilidades, también supone una importante pérdida de tiempo (y no solo eso, un lastre para el resto del proceso de desarrollo y el mantenimiento).

El cambio forma parte de nosotros, de nuestro entorno. ¿Por qué no va a afectar el cambio al desarrollo de software?. Las ideas sobre la persistencia de las condiciones del proyecto, base de las metodologías clásicas se esfuman al poco tiempo de empezar a trabajar en este negocio, si bien, estamos tan de lleno trabajando de esa manera que los árboles, a veces, nos impiden ver el bosque.

En nuestros proyectos, nos han cambiado requisitos, temprano y tarde, se han ido responsables funcionales que han sido los que han tomado las decisiones sobre lo que el sistema debe hacer, han cambiado los procesos, poco o mucho, nos han modificado las prioridades, etc… No se trata de luchar contra esto, sino de adaptarnos a trabajar sobre un entorno que puede variar.

Adaptarnos a un entorno que se adapta es un factor esencial a tener en cuenta a la hora de afrontar un proyecto de desarrollo de software, porque las condiciones y las cosas cambian. Ya lo decía una de las figuras más relevantes en la gestión de procesos y de la calidad, como es William Edwards Deming: “No es necesario cambiar, la supervivencia no es obligatoria.”.

Muchas veces, cuando pienso en las desviaciones entre lo esperado y lo que realmente se produce en los proyectos de desarrollo de software y llego a la conclusión de que son inherentes al mismo proceso de desarrollo tengo la sensación de que debo estar equivocado, que tal vez es el resultado de mi experiencia en mi contexto laboral y que es posible que fuera no reine la entropía.

Por eso, cuando leo citas o artículos donde personajes relevantes de este negocio, investigadores o profesores universitarios y llegan a las mismas conclusiones, me tranquiliza, no por el hecho de que veamos la cosa de la misma manera, sino porque confirma que el desarrollo es como es y que tenemos que adaptar nuestra forma de trabajar a esta singularidad.

A Charles Darwin se le atribuye una cita en la que indica que: “no es el más fuerte el que sobrevive, tampoco el más inteligente pero sí el que resulta más adaptable al cambio”.

Los profesores Hadar Ziv y Debra J. Richardson son un ejemplo más, dentro del mundo académico, de la opinión de que las predicciones realizadas en el desarrollo de software siempre van a estar condicionadas por el alto grado de incertidumbre que tienen los proyectos y se puede observar en la presente cita, datada en el año 1996 y que resulta perfectamente aplicable hoy día, quince años después: “La incertidumbre es inherente e inevitable en el proceso de desarrollo de software y sus productos”.

La incertidumbre inherente a los proyectos de desarrollo de software requiere que el proceso de desarrollo pueda responder de manera ágil y flexible ante ella. De lo contrario estamos abocados a desarrollos que no se adaptarán a las expectativas del usuario o que para acercarse a las mismas requieran un sobrecoste importante, así como un incumplimiento de los plazos.

¿Qué estoy exagerando? Hace poco os puse los datos publicados por el Cutter Consortium, en el que quedaba patente que la crisis del software sigue sin superarse.

Barry Boehm, uno de los mayores expertos a nivel mundial en estimación de costes software y en la aplicación de estrategias de gestión económica en los proyectos de desarrollo de software, lo manifiesta de manera patente en la siguiente reflexión (traducción libre): “Será importante tener en cuenta a la hora de organizar proyectos en el futuro contar con la agilidad suficiente como para ser capaz de adaptarse a la aparición de nuevas fuentes adicionales de cambios imprevisibles”.

Soy de la opinión de que en el desarrollo de software los requisitos funcionales y de interfaz de usuario deben quedar resueltos antes de empezar a codificar, sin embargo hay ciertos aspectos que no cobran su verdadera forma hasta que uno se enfrenta a su programación, hasta que se siente el código.

Sentir el código, es una cita que leí a Alex Bergonzini en su Twitter y desde luego no le falta razón ya que en la programación se enfoca el problema.

Martin Fowler también le da importancia a sentir el código en su siguiente reflexión (traducción libre): “Cuando te sientas a escribir código, aprendes cosas a las que no puedes llegar en el proceso de modelado… ya que hay un proceso de feedback al que solo puedes llegar desde la ejecución de determinadas funcionalidades y viendo como funcionan”.

El desarrollo de software es adaptativo y todo no se puede prever, a veces hay que experimentar hasta encontrar una solución satisfactoria para el usuario, eso es totalmente compatible con los desarrollos ágiles. Ahora bien, el hecho de que los principios ágiles indiquen que no hay que elevar ninguna funcionalidad a definitiva no quiere decir que todo deba ser consecuencia de la experimentación, porque construir y tirar módulos software además de ser caro puede provocar una desmotivación importante en el equipo de proyecto.

No lo es. El problema consiste en no tener en cuenta la naturaleza adaptativa del proceso de desarrollo de software o que si bien, no se ha tenido en cuenta, no se plantee una renegociación del alcance del proyecto entre cliente o proveedor o se compense económica ese esfuerzo de más que se va a echar.

Lo ideal es que todas las partes tengan en cuenta que el desarrollo de software no es un proceso predictivo, lo que obliga a hacer cambios a lo largo del desarrollo y además pueden ocurrir contingencias que rompan los planteamientos iniciales.

¿Cómo se tiene en cuenta? Pues teniendo en cuenta en el proceso de presupuestar proyectos esta circunstancia. Generalmente se presupuesta pensando en que todo va a ir bien o dando un cierto margen por encima en el caso de que haya incertidumbre. Y lo peor de todo no es eso, sino que por regla general no se tiene previsto que después el producto hay que mantenerlo y que eso ocurrirá siempre (será poco o mucho lo que haya que ir adaptando, pero lo que es cierto es que ocurrirá).

Una vez que los presupuestos tienen en cuenta que un proyecto de desarrollo de software es de naturaleza adaptativa el siguiente paso es aplicar una metodología que se adapte a ello porque si bien con dinero suficiente se reducen los problemas, la utilización de una metodología adecuada permite optimizarlo, lo cual redunda en el beneficio de todas las partes, el cliente porque tendrá más margen de adaptación, el proveedor porque tendrá más controlado el proyecto y el usuario final porque progresivamente tendrá un producto que se aproxime más a sus necesidades.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.207 seguidores