archivo

Archivo de la etiqueta: evolutivo

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.

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

Seguir

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

Únete a otros 3.225 seguidores