archivo

Archivos Mensuales: julio 2012

Es cierto que hay muchas variables que influyen sobre tu motivación pero hay una que tiene una especial relevancia (no digo que sea capaz de revertir situaciones imposibles pero que sí es bastante efectiva incluso en contextos que te invitarían a una permanente bajada de brazos) y es sentir que aportamos valor con nuestro trabajo (que mediante nuestro esfuerzo intelectual y físico influimos positivamente en el producto) y que lo que hacemos permite mejorar ya sea un proceso, una herramienta, una organización, un conjunto de personas o el mundo.

Ese sentimiento debe nacer de uno mismo si bien es importante que los gestores ayuden a forjarlo y a consolidarlo algo que no es demasiado habitual ya que generalmente se destacan más los fallos que los aciertos y no se comunica los efectos que el desarrollo produce sobre sus destinatarios (es cierto que no siempre se puede saber con certeza pero también lo es que no se suele prestar demasiada atención a obtener esa información).

Ya que tenemos que ir a trabajar y que pasamos allí un buen número de horas cada día resulta mucho mejor sentirnos importantes y sentir que lo que hacemos vale para algo.

La siguiente cita de Dave Thomas creo que resume perfectamente el contenido de este artículo: “Para motivarte y mantenerte comprometido necesitas estar orgulloso de lo que estás haciendo. Si por el contrario te consideras un trabajador de una línea de ensamblaje cuyo único trabajo es coger una especificación y convertirla en bytes, no vas a tener suficiente interés en lo que estás haciendo como para hacerlo bien”.

Es cierto que hay personas que se sienten encantadas con ser meros ejecutores de tareas, lo respeto, pero mi visión sobre el papel que debe desempeñar cada persona en un proyecto de desarrollo de software va mucho más allá de eso y está en consonancia con el contenido de este artículo.

La comunicación es básica en los proyectos de desarrollo de software y no solo entre los miembros de un equipo (algo que es esencial) sino también entre los stakeholders.

Una vez que se consigue que la comunicación sea fluida (no es tan fácil ya que no solo depende de uno mismo) o por lo menos que exista cuando sea necesario es importante que de vez en cuando haya encuentros cara a cara (cuanto mayor sea la relación que se tenga que tener más frecuentes deberían ser esos encuentros).

Es cierto que el contexto en el que se desarrolla el proyecto condiciona mucho y si tu cliente está a 500 kilómetros o en otro país no es tan sencillo conseguir esa cercanía, lo cual no quita que se busque el mecanismo de comunicación que permita una mayor proximidad dentro de esas condiciones y en el que ambas partes se sientan cómodos.

Y es que la comunicación previene de muchos problemas y también permite resolver otros tantos. Cuando hay un malentendido, un conflicto o un desencuentro lo mejor es hablarlo y hacerlo cuanto antes. A veces, en función del carácter que tenga cada uno es interesante esperar un poco ya que a veces es mejor dar tiempo a reflexionar y ver las cosas desde otras perspectiva. Esperar un poco no es aguardar a que el problema desaparezca porque en este tipo de circunstancias suele quedar un poso que tarde o temprano termina saliendo afuera, sino hablar unas horas o unos días después.

Pero no es solo útil en este tipo de circunstancias, ya que permite armonizar las visión del conjunto sobre el proyecto, resolver dudas y lo más importante desarrollar y consolidar paulatinamente la relación de confianza.

Generalmente muchos problemas en los proyectos no vienen por un exceso en la comunicación sino por su defecto.

La agilidad vista como una orientación al producto exacerbada donde nada ni nadie importa por conseguir un resultado favorable no es agilidad, llamadlo como queráis, pero no agilidad.

Claro que importa obtener un producto que satisfaga las expectativas del usuario además de otras condiciones (mantenibilidad, robustez, etc…) pero no hay un solo camino para conseguirlo aunque generalmente se opte la mayoría de las veces por el más corto y es no tener en cuenta prácticamente nada más que el sistema que se está desarrollando como si fuera un elemento aislado dentro de la organización.

¿Cuál es el resultado de esto? La fragmentación de los sistemas de información y de los datos que gestionan. En el primer caso es una deuda técnica que generalmente nunca se tiene en cuenta pero que es real en el momento en que te pones a pensar en la diversidad de tecnologías que se terminan utilizando, de la compatibilidad con navegadores, servidores de aplicaciones, servidores de bases de datos, etc… En el segundo caso dificulta la realización de consultas integradas de información y os aseguro que los Datamart pueden ayudar a eso pero no hacen milagros.

¿Por qué el camino más corto? Pues porque es el más fácil, no dependo de nada así que quito resistencia al desarrollo del proyecto que bastante tiene ya de manera inherente, además siempre habrá una excusa (porque seguro que hay motivos para ella) para alegar que es la mejor solución porque no es fácil integrarse con terceros sistemas cuando estos están gestionados por otras personas con otros intereses y la existencia de situaciones de bloqueo, de falta de entendimiento y dificultades a nivel técnico o de datos para integrar son riesgos que de alguna u otra manera suelen materializarse cuando tenemos en cuenta estos factores.

¿Cuándo se actúa de manera adecuada? Cuando de la manera más objetiva posible se entiende que lo mejor (haciendo balance entre beneficios e inconvenientes) para el proyecto y para el producto teniendo en cuenta la organización y dentro del contexto actual.

Hace poco tuve la oportunidad de leer una entrevista que se realizó a Andy Hunt y Dave Thomas en el año 2003 que giraba alrededor de conceptos tratados en su libro: “The Pragmatic Programmer” y que me permitió darme cuenta de que el término DRY (Don’t repeat yourself) y que hacían uso en su libro iba más allá de la duplicación de código.

Por ejemplo, en el artículo que escribí denominado: “Desarrollo de software. Martin Fowler. Un buen diseño pasa por reducir o eliminar el código duplicado“, el concepto lo aplicaba en relación al código duplicado, algo que no es erróneo porque forma parte del DRY pero que no representa toda su semántica.

¿A que se refieren con el DRY? Pues a evitar la duplicidad de cualquier componente software o no de un proyecto de desarrollo de software, como dicen estos autores (traducción libre): “Toda pieza de conocimiento (entidad) en un proceso de desarrollo debería tener una única representación” de manera que esto va más allá del código duplicado, extendiéndose a objetos de bases de datos, elementos documentales, funcionalidades, etc…

Todos conocemos las consecuencias de las duplicidades:

– Trabajo de más innecesario que se podría haber utilizado en tareas que requerían un mayor esfuerzo o en otras que hubieran sido de interés como por ejemplo refactorizar, automatizar testing, desarrollo de funcionalidades que no pudieron ser abordadas, etc…

– Mayor esfuerzo para mantener coherentes las duplicidades.

A veces los nuevos contextos no son el de por circunstancias externas (o que tienen una alta influencia desde el exterior) sino que son creados por cambios provocados desde dentro, los cuales nos pueden proporcionar una ventaja competitiva con el resto si somos capaces de ser los primeros y de hacerlo bien.

Esta necesidad de dar una respuesta rápida a estos cambios supuso otro argumento más para pasar de un enfoque clásico al ágil en términos generales y en el desarrollo de software ya que cuando hay que evolucionar hay que hacerlo lo antes posible y eso requiere romper con determinados convencionalismos de manera que en lugar de recrearnos en el proceso o en la metodología el camino pasa a ser: “hay un problema, resolvámoslo, tenemos un objetivo, vamos a por él, hay que cambiar, hagamos lo que haya que hacer, ¡pero ya!”, sin que esto tenga que suponer necesariamente una merma en la calidad del producto final (la que se considere necesaria) como tampoco te asegura dicha calidad aplicar fórmulas clásicas.

Para Dave Thomas la calidad y el desarrollo no son elementos que se deban separar: “La calidad es algo que tu haces todo el tiempo mientras está desarrollando”.

Cuando en nuestra cabeza solo existe el deseo o necesidad de seguir ejecutando trabajo ya sea por presiones de nuestros superiores y/o del cliente y/o porque lo queremos es quitarnos cuanto antes las tareas que tenemos asignadas difícilmente conseguiremos un producto final de calidad (en todos los sentidos, tanto en aspectos técnicos como en funcionales).

La verdad es que es complicado salir de la espiral de las presiones y de los plazos pero si no tenemos una plena conciencia de que tenemos que desarrollar, dentro de nuestras posibilidades y del proyecto, un software con la mayor calidad posible siempre encontraremos una excusa, a veces más fundada y otras casi sin argumento, para limitarnos a ejecutar tareas lo más rápido posible sin centrarnos en que lo importante no es la rapidez sino la efectividad y la misma se obtiene a través de la calidad.

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.