archivo

Archivos Mensuales: febrero 2013

El segundo escenario suele ser el más habitual y es la base para el fracaso de muchos proyectos de desarrollo de software, independientemente del enfoque a utilizar, si bien los enfoques evolutivos ofrecen la posibilidad de desarrollar el software por incrementos y si el área usuaria se muestra flexible (y la agenda da alguna oportunidad) es posible conseguir una solución razonable con el presupuesto y plazos definidos.

¿Qué agenda se puede gestionar si las condiciones iniciales son imaginarias? Solo es posible hacer algo en el caso de que el cliente entienda esta situación y no se cierre en banda al llave en mano. Si lo hace perderá el proveedor, pero también el cliente, porque pocos proyectos alcanzan un éxito real en esas condiciones.

También podría ser, porque también pasa, que las condiciones iniciales estén muy por encima de lo que requiera el proyecto, este escenario es más favorable que el anterior (por no decir que un chollo para el proveedor si te toca trabajar en estas condiciones), pero no arregla el problema de fondo, tal vez el proyecto sea muy rentable y el cliente quede satisfecho, pero el desarrollo de software es algo lo suficientemente serio como para esperar a ver si la moneda cae cara o cruz.

Recuerdo de artículos míos recomendando que el presupuesto fuera holgado, teniendo en cuenta esta situación de incertidumbre inicial, sin embargo, la solución no pasa por ahí, sino que pasa por la definición de presupuestos objetivos y por la predisposición a modificarlos si las circunstancias del proyecto lo aconsejan.

Cuando hablo de presupuesto objetivo lo hago desde la perspectiva de que se base al menos en una visión sólida del producto, para lo cual no es necesario hacer un análisis completo y en detalle del sistema de información, teniendo en cuenta que ese presupuesto objetivo obedece a una visión inicial (aunque sólida) del producto y que después habrá cambios que afectarán a las condiciones de la agenda.

Anuncios

Cuando el usuario quiera cambiar cosas deberá negociar y en esa negociación suelen quedar tocados tanto desarrolladores como usuarios, los primeros porque el esfuerzo a realizar tras el cambio será mayor, ya que el cumplimiento de la agenda recaerá sobre sus espaldas y los segundos porque no podrán llevar al producto todos los cambios que entienden que son necesarios (el valor del producto está fuertemente limitado por el valor teórico del producto en su especificación) y tendrán, probablemente, un producto de mayor deuda técnica (se descuidará la calidad del desarrollo como consecuencia de incrementar el ritmo de trabajo y del más que probable overtime que tengan dedicar) y con una peor ejecución funcional porque se habrá dedicado menos tiempo (si es que se ha dedicado alguno) a la detección y corrección de incidencias y deficiencias funcionales.

Pero, ¿dónde comienza la gestión de agenda?, ¿antes o después de tener el catálogo de requisitos?. La respuesta natural a la pregunta es que poca agenda puedes gestionar si no sabes lo que vas a hacer y en base a ellos se ha definido un presupuesto y unos plazos equilibrados.

Sin embargo, nos encontramos con dos escenarios:

1) Definición de agenda, una vez definido el alcance inicial del proyecto.

2) Definición de agenda, sin tener una versión inicial del catálogo de requisitos y por tanto, con una estimación del presupuesto y plazos un tanto irreal.

El primer escenario es en el que realmente tendría sentido la gestión de la agenda ya que se da por conocido el sistema que hay que desarrollar y para ello se ha dedicado un presupuesto y previsto unos plazos. Sin embargo, al final, el problema sigue siendo el mismo, porque cuándo surjan modificaciones en los requisitos tocará negociar para mantener la agenda y en caso de desacuerdo el perjudicado en primera instancia será el producto final, en segunda instancia todo el resto de implicados.

En el artículo de mañana analizaremos el segundo escenario que, por desgracia, suele ser el más habitual.

Es cierto que llegado el momento puedes abrir la mano y permitir cambios en las especificaciones, pudiendo negociar el intercambio de requisitos, pero la verdad es que no suele dar buenos resultados por diversas razones: el intercambio no es real (generalmente las tareas que entran suponen más esfuerzo que las que salen, si es que sale alguna), se cambian requisitos sobre visiones abstractas del producto por lo que se siguen realizando a ciegas independientemente de que la visión tenga menos niebla que al principio y además, cambiar de enfoque en determinadas funcionalidades, con el producto avanzado tiene un coste alto.

Esto último también se puede producir en un desarrollo iterativo incremental, lo que lo diferencia es que en muchos casos, la detección del problema se habrá realizado en etapas más tempranas (en el caso de que no sea un cambio de enfoque por cambios en el proceso) ya que los usuarios estarán interactuando con el producto mucho antes.

La gestión de proyectos basados en enfoques clásicos o predictivos es en realidad una gestión del desgaste porque el cumplimiento de la agenda implicará falta de flexibilidad una vez que el análisis inicial se ha completado.

En ese triángulo que forman: alcance, coste y plazos, la modificación de uno de los vértices impacta sobre el resto salvo que exista un margen suficiente que por otra parte casi nunca existe o casi nunca es suficiente. Si no existiendo ese margen se modifica el alcance (o el esfuerzo para conseguir los objetivos, ya que lo mismo el alcance es similar pero la modificación de requisitos sobre componentes construidos hace que sea necesario un esfuerzo mayor ya que el ya invertido hay que contarlo) y se quieren mantener costes y plazos, el primer afectado será la calidad final del producto.

El enfoque clásico o en cascada del desarrollo de software es un modelo de carácter predictivo. Se realiza un análisis del sistema a desarrollar o de los módulos a evolucionar (alcance), se estiman costes y plazos y se trata de gestionar esta agenda (lo que se denomina triángulo de hierro) durante el resto del proceso de desarrollo.

Resulta razonable que pueda funcionar, sin embargo, es un modelo basado en la estabilidad del contexto y en la rigidez de los requisitos y ahí es dónde empieza a tener problemas porque una vez sentadas las bases, lo que cobra prioridad es el cumplimiento de la agenda ya que se entiende que el producto está definido.

La realidad es que los requisitos van a cambiar, conforme vaya avanzando el desarrollo del producto el usuario se dará cuenta de que determinadas especificaciones no son buenas o son mejorables, que se le ha olvidado tal o cual gestión o que las prioridades indicadas tienen que modificarse.

No se trata de que el desarrollador (analista o el componente del equipo que haya hecho ese trabajo) o el usuario lo hayan hecho mejor o peor (por supuesto que un buen trabajo permite trabajar en unas condiciones mucho más favorables) sino de algo que es natural en un proyecto de desarrollo de software y es que haya una evolución ya sea del negocio y/o de la percepción que tienen los usuarios con respecto al sistema de información o algo tan simple y tan frecuente (y humano) como que nos hayamos equivocado.

Esto no es algo que yo me esté inventando, ¿en cuántos proyectos has trabajado en los que no se hayan tenido que cambiar algunos de los requisitos iniciales o se hayan tenido que añadir otros nuevos?.

Como la realidad es esta, tenemos que gestionarla: hay un catálogo de requisitos que permanece vivo a lo largo del proceso de desarrollo.

Como esa es la realidad, los enfoques iterativos incrementales son, a mi juicio, la mejor estrategia para afrontarla, teniendo en cuenta pueden existir proyectos, ¿por qué no?, donde el enfoque clásico sea el más apropiado.

Una condición necesaria para conseguir el éxito en un proyecto es crear un equipo. No te centres solo en el equipo de desarrollo sino en el conjunto de equipos que participan activamente en el proyecto.

Si ya es difícil a un grupo de personas hacerlas funcionar como equipo, hacer que diversos grupos con distintos intereses, con diferentes objetivos y que pueden ser incluso de varias organizaciones funcionen como un equipo, es un auténtico reto. Reto que, por supuesto, merece la pena porque de lo contrario el proyecto estará en peligro.

La situación de partida suele ser que cada equipo es como una ciudad estado, con sus muros gigantescos y con sus propias leyes. En algunos casos estarán organizados y en otros reinará el caos (con toda la escala de grises entre un extremo y otro). Este ecosistema es un caldo de cultivo óptimo para el antipatrón “arrojar al otro lado del muro“, ya que cada cual se centrará en su parte concreta del proyecto, olvidándose de que todos dependen del trabajo de los demás. En este contexto la comunicación entre los equipos es poco fluida y generalmente muy procedimentada, lo que pondrá una resistencia importante a la interacción entre las personas y no solo eso, la actitud de los equipos será defensiva, algo que suele tener como efecto que los muros sean cada vez más grandes.

He descrito un panorama extremo, es cierto, porque todos los equipos no tienen por qué tener de partida un comportamiento de ese tipo, pero también resulta algo poco real pensar que de partida todos los equipos van a estar funcionando como uno.

Para tratar de tirar o reducir el tamaño de esos muros es muy importante la tarea de alinear los equipos al objetivo del proyecto, enfocarlos, hacerles entender que su esfuerzo es esencial para sacarlo adelante y que solo se conseguirá el éxito si todos los equipos tienen éxito en la parte del proyecto en la que le toca trabajar.

Esto no se consigue con una charla, se consigue conversando mucho, escuchando más y promoviendo que los trabajos de los equipos sean abiertos, de manera que todos tengan la oportunidad de conocer qué se está haciendo. De esta forma se reducirá la complejidad de la integración resultados ya que se detectarán problemas más temprano y por otro, que se tenga una visión global de los trabajos lo que facilitará el entendimiento de que o todos colaboran o esto no tendrá éxito.

No es sencillo que los equipos se abran a otros, sobre todo si son de organizaciones distintas, para facilitar esto es necesario que la apertura sea bidireccional y en las mismas condiciones, por otro lado hay que estar muy atento para atajar cuanto antes los conflictos que puedan acontecer.

Hay que evitar tener favoritos y tener un trato justo con los equipos. Es posible que un equipo esté desarrollando la parte más crítica del sistema y es posible que eso haga que le dediques mayor atención. Eso es algo lógico y no expresa favoritismo, sino sentido común. El trato justo se mide cuanto ante circunstancias similares tu comportamiento es el mismo con un equipo que con otro y cuando respetas de la misma manera el trabajo, siempre y cuando el mismo merezca ese respeto.

Mantener el equilibrio es complicado porque en el proyecto pasan muchas cosas. Habrá pasos adelante y pasos atrás, siendo estos últimos más largos generalmente que los primeros porque esto de trabajar en equipo funciona si hay confianza y la confianza cuesta mucho conseguirla y es muy sencilla de perder.

Al final, uno puede intentar todo lo posible porque todos los equipos trabajen como uno, para reducir distancias, para ayudar en la resolución de problemas pero sin la voluntad por parte de los mismos y/o sus organizaciones no será posible. Se puede estar un tiempo con el viento en contra, con un equipo o varios equipos que no quieren adaptarse a este esquema de funcionamiento, pero no todo el proyecto, porque habrá quien, con razón, termine por no aguantar esta situación.

Me parece muy interesante la siguiente cita de Martin Fowler: “Cuando aprendes una nueva técnica que incrementa sensiblemente tu productividad, resulta difícil darnos cuenta cuándo no aplicarla”.

Nos pasa a todos que cuando la aplicación de una determinada práctica y estrategia nos produce buenos resultados, queremos empezar a utilizarla en todos los proyectos. Esta idea, en esencia, es la que está detrás de todos los enfoques orientados a procesos: aplicar procedimientos que permitan de manera repetible conseguir unos determinados resultados.

Por ejemplo, cuando empezamos a aplicar prácticas de diversas metodologías o enfoques ágiles y vemos que encajan con la dinámica de un proyecto de desarrollo de software, el paso siguiente es reflexionar cómo podemos aplicarlas en el resto de nuestros proyectos, ¿cuándo sobrepasamos el límite? lo hacemos en el momento en que por encima de las características y el contexto del proyecto lo que nos importa es aplicar el método o las prácticas.

En ese preciso momento empezamos a dejar de ser ágiles y convertirnos en esclavos de procesos, enfoques o prácticas, es decir, en lugar de seguir evolucionando en nuestra forma de entender el software involucionamos hacia nuestro estado de partida.

Lo deseable es que el equipo coja velocidad de crucero desde el primer sprint, sin embargo es algo que resulta muy complicado salvo en aquellos proyectos en los que el equipo esté habituado a trabajar junto y/o con una orientación a sprint, esté perfectamente habituado a la tecnología de desarrollo y en donde las historias de usuario sean de calidad y fácilmente asimilables por los desarrolladores.

Lo más normal es que el equipo pueda asumir menos carga de trabajo al principio y la vaya aumentando conforme los factores anteriores se van asentando, hasta llegar a esa velocidad de crucero, que, ¿por qué no?, podría ir mejorando con el paso del tiempo.

Trabajar con agendas puede implicar un nivel de exigencia alto al equipo desde el primer sprint, un nivel de exigencia que se sitúa por encima de lo que el equipo puede dar en ese momento. Desde mi experiencia os puedo asegurar que no es positivo porque no asegura el adecuado cumplimiento de los compromisos (que esté programada una funcionalidad no es cumplir el compromiso, cumplirlo es que funcione y esté en disposición de pasarse a producción si así se considerase oportuno) y porque el equipo empieza a desgastarse desde muy pronto y eso afecta negativamente a los trabajos teniendo en cuenta que todavía queda mucho proyecto por delante.

¿Qué hacemos? Si se puede intentar adaptar la agenda a lo que el equipo puede dar e incrementar si se puede el equipo o la dedicación de las personas que ya participan en él (si hay personas que puedan incorporarse al equipo en donde su saldo de participación neto: lo que aporta menos lo que el equipo tiene que invertir para conseguir esos resultados es positivo o puede serlo a muy corto plazo y hay trabajo por delante que lo justifique).

Por tanto, es conveniente dejar que el equipo vaya adquiriendo paulatinamente esa velocidad de crucero, no hay que olvidar que tienen que cumplir unos compromisos, que ponen mucho en juego y que por tanto, ellos de manera responsable deben autogestionar la capacidad de trabajo que pueden asumir en cada momento.