archivo

Archivo de la etiqueta: analista

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).

Existen muchas formas de modelar la realidad, todas ellas válidas. Sin embargo el hecho de que sea válida no quiere decir que el modelo de datos sea bueno.

Un modelo de datos más complejo de lo necesario será a la larga una fuente de problemas porque aunque esté escondido en las capas más profundas de la aplicación condiciona sin lugar a dudas todo lo demás.

A veces el modelo lo hace complejo el desarrollador, otras muchas veces el usuario que pretende almacenar información o relacionar entidades que después no va a poder mantener. Es conveniente hacerle ver al usuario si efectivamente esa complejidad adicional que va a introducir le va a aportar algún valor y si incluso aportándole van a tener recursos suficientes para mantener los datos actualizados y con calidad.

El desarrollo de software requiere cooperación e interacción, no se trata en este caso de contaminar al usuario sino de hacerle reflexionar sobre la situación, a veces una segunda o tercera pensada evita malgastar esfuerzos presentes y futuros.

Los modelos de datos deben ser lo más simples posibles sin que se pierda información que el usuario necesita (realmete) para su gestión. Si hay que dedicar algo más de tiempo en él es una inversión que al final será amortizada.

Si la finalidad de los productos que desarrollamos es que lo utilicen usuarios es un mal síntoma que buena parte del equipo de proyecto esté alejado de los mismos.

Generalmente son los analistas los que tratan con los usuarios, a veces también lo hacen los jefes de proyecto, mientras que el resto del equipo por arriba y por debajo apenas tiene trato con ellos.

En otros modelos orientados a factorías de software, son aún más las capas que separan a los desarrolladores del cliente.

Sobre esto habrá opiniones de todo tipo, pero desde mi punto de vista, cuando los técnicos solo ven papel (o su equivalente en una herramienta CASE) termina por olvidarse para qué y para quién se desarrolla y eso es un problema importante porque nos robotiza en lugar de humanizarnos y nos convertimos en autómatas que ejecutamos trabajo, que anotamos nuestras horas en el sistema de gestión de incurridos que se utilice y que tratamos de no desviarnos de las previsiones que nos han indicado nuestros superiores, en ese contexto, ¿qué margen le queda al usuario?, ¿qué margen le queda a la calidad del producto?.

En el antipatrón “los arquitectos no programan“, nos encontrábamos con que la organización consideraba que este tipo de perfil era lo suficientemente caro como para que participasen en el proceso de implementación del software, aunque sea como supervisores del trabajo que se está realizando o para resolver diferentes dudas que se encuentren los programadores en aspectos relacionados con el diseño o con la arquitectura.

Otra vertiente de ese antipatrón (que en muchos casos se produce de manera conjunta con la anterior) era el hecho de que los arquitectos prescindan o no den suficiente peso a la opinión de los analistas o programadores que van a tener que realizar el desarrollo.

Este antipatrón es una variante del anterior y se produce en alguna de las siguientes situaciones:

– El arquitecto aplica el antipatrón “arrojar al otro lado del muro“, es decir, ellos hacen lo que entienden que es su trabajo y después que sean los analistas y programadores los que se entiendan con el problema.

– Cuando se decide subcontratar el proceso de construcción, se envían las especificaciones y la arquitectura a utilizar y se vuelve a aplicar el antipatrón “arrojar al otro lado del muro”.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Este antipatrón recibe el nombre de una canción infantil. Os la pongo tal cual:

Oh, The grand old Duke of York,
He had ten thousand men;
He marched them up to the top of the hill,
And he marched them down again.

And when they were up, they were up,
And when they were down, they were down,
And when they were only half-way up,
They were neither up nor down.

Como podréis ver describe simplemente la acción de subir una colina, para después volverla a bajar. Se considera como una metáfora del esfuerzo invertido de manera gratuita o innecesaria.

No obstante, este antipatrón, aunque en el fondo haga referencia a un esfuerzo de esas características, quiere hacer hincapié sobre todo en una de sus posibles causas.

De igual manera que roles de carácter funcional resultan de mucha utilidad como nexo de unión (que no intermediario) entre usuarios y equipo de proyecto, también es necesario destacar la figura de los arquitectos software y a más bajo nivel los analistas orgánicos.

En el caso de los primeros existe una visión más abstracta del comportamiento funcional del sistema de información y en el de los segundos existe una visión más abstracta de la arquitectura de la aplicación, en ambas situaciones se ve el bosque y no los árboles.

Es frecuente encontrarnos con proyectos donde alguno de los dos perfiles no interviene (cuando no los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las especificaciones del usuario.

Esto suele provocar (de ahí la analogía con la metáfora de la canción de “El gran viejo Duque de York”) que determinadas decisiones, al tener una visión demasiado a bajo nivel de la aplicación, no busquen la solución más óptima y obligue a hacer esfuerzo de más o incluso a un esfuerzo innecesario.

Por tanto, lo que viene a decir este antipatrón es que equipos de proyecto descompensados entre visiones más abstractas y más concretas pierden productividad.

Watts Humphrey es considerado por muchos como el padre de la calidad del software y una de las figuras clave en el campo de la ingeniería del software. Me parece interesante que un personaje tan relevante de nuestro negocio resuma en la siguiente reflexión una buena parte de lo que es el proceso de desarrollo, la gestión de requisitos y el papel de los usuarios en todo esto (traducción libre):

“Cuando programamos, transformamos un problema que prácticamente no comprendemos en un conjunto preciso de instrucciones que pueden ser ejecutadas por un ordenador.

Cuando pensamos que comprendemos los requisitos del programa, estamos inevitablemente equivocados.

Cuando no entendemos completamente un problema, debemos estudiarlo hasta comprenderlo.

Solo cuando nosotros verdaderamente comprendemos un problema podremos desarrollar un producto superior que trate el problema.

Lo que los usuarios piensan lo querrán cambiar tan pronto como vean que estamos desarrollando”.

Requisitos, usuarios, la propia evolución del equipo de proyecto, son parte de la incertidumbre del proceso de desarrollo, de la incertidumbre de los proyectos de desarrollo de software.

Es importante tener buenos analistas que permitan extraer el mayor conocimiento posible del negocio y de las expectativas del usuario, ya que de esta manera ahorraremos esfuerzo, no obstante, el conocimiento real del negocio y de lo que quiere el usuario llega más tarde, cuando tenemos el producto o parte de él en producción y el usuario se da cuenta realmente de lo que quiere y cómo lo quiere.