archivo

Archivos diarios: mayo 16, 2012

Muchas personas contrarias a las metodologías o enfoques ágiles utilizan como argumento que la agilidad es una puerta abierta a la entrega de versiones de productos deficientes bajo el amparo de un enfoque evolutivo del desarrollo de software basado en la aproximación sucesiva a la versión final de producto y el feedback o dicho de otro modo: como vendrán nuevas oportunidades de seguir evolucionando el software no me esfuerzo por entregar un buen producto (ya se arreglará o ya se mejorará).

Pues no, no es así. Quien hace eso yo no lo considero agilista (opinión personal), es más puede que no lo considere incluso un buen profesional.

La agilidad requiere desarrollos con intención. La intención es la aproximación a un objetivo tirando a dar, minimizando la especulación. Un desarrollo con intención no se puede sustentar en entregas de calidad deficiente porque de lo contrario la evolución del producto será muy lenta y la capacidad de adaptación al cambio, por tanto, disminuye.

Muchas veces creemos que el proyecto va de una determinada manera y posiblemente estemos próximos a lo que es la situación real del mismo, sin embargo, cuanto mayor sea el número de proyectos en los que participamos y mayor sea su tamaño, complejidad y heterogeneidad, más probabilidad existirá de que nuestra visión no se ajuste a la realidad, ya que por estas circunstancias estaremos cada vez más lejos del día a día del proceso de desarrollo.

Como medida para atacar ese problema tenemos la retrospectiva y análisis de la situación con el equipo de personas que participa en el proyecto, sobre todo el equipo de desarrollo y los usuarios responsables de realizar la definición del sistema. Si tenemos ese instrumento, es conveniente utilizarlo y no especular, ya que no solo detectará puntos de mejora sino que se podrán consensuar cómo llevar a cabo las mismas.

Sobre esto, Ron Jeffries realizó la siguiente reflexión (traducción libre): “Incluso si usted sabe exactamente lo que está sucediendo en su sistema, analice la situación, no especule. Vas a aprender algo, y nueve de cada diez veces, comprobará que no tenía razón”.

Es absolutamente necesario en todo Departamento de Informática de una organización el conocimiento y comunicación de sus objetivos adecuados al contexto y circunstancias en las que se encuentra, de lo contrario, los distintos departamentos que la componen definirán sus propios objetivos o prioridades ajenos a una visión global del servicio que se tiene que ofrecer y dando la espalda a cualquier posibilidad de sinergia.

Y como decía sin olvidar contexto y circunstancias. Lo mismo las posibilidades actuales pasan exclusivamente por dar una buena atención orientada al puesto de trabajo de los usuarios e intentar dar supervivencia a los sistemas de información más críticos o prioritarios de la organización. Si no tenemos en cuenta donde nos encontramos probablemente no consigamos llegar a ningún sitio y enfoquemos los esfuerzos en aspectos secundarios que hagan que nos quedemos con la bolsa vacía.

Y no, no son tan obvios los objetivos de un departamento si no se definen o discuten. Los objetivos deben ser explícitos y recitados casi a modo de mantra por los que se tienen que encargar de alcanzarlos. Darlos por conocidos, sin reflejarlos en ningún sitio, sin hacer un seguimiento medianamente objetivo, es lo mismo que dejar las puertas abiertas al caos, a la definición de prioridades y objetivos singulares y a los reinos de taifas.