archivo

Archivo de la etiqueta: desarrollo

La respuesta es compleja ya que depende del enfoque que tengas por lo que dar una respuesta en términos absolutos hará que los resultados en muchos casos sean erróneos.

En cualquier caso y con respecto a enfoques clásicos de desarrollo sí que supone una fuerte ruptura si bien la tendencia natural de la mayoría de los que han aplicado ese tipo de enfoque ha sido tender hacia enfoques más flexibles aproximándose a lo que sería un enfoque ágil. De hecho se venían aplicando enfoques ágiles, así como estrategias y metodologías mucho antes de que el Manifiesto Ágil fuera publicado.

¿Por qué una ruptura respecto a los enfoques clásicos? Porque sitúa en primer lugar al producto y a las personas mientras que en los enfoques clásicos todo estaba supeditado al proceso (o por lo menos estaba por encima del producto y las personas).

Según el enfoque clásico, estas son las etapas y los hitos a cumplir en cada una de ellas obteniendo análisis y diseños que después se materializarían mucho más tarde en un producto software (planteamiento más rígido). Hasta la entrega del producto el usuario no realizaba un feedback sobre un elemento no abstracto, hasta entonces lo menos abstracto con lo que había trabajado eran prototipos.

Pero no se trata solo de intentar que el feedback del usuario sea de la mayor calidad posible y cuanto antes, sino que se trata sobre todo de entender la singularidad de los proyectos y de su realización en un contexto concreto que probablemente cambie, lo que hace necesario centrar la atención en el producto y en las personas que intervienen en su definición y construcción, se trata de adaptarnos por tanto al producto que se va a desarrollar dentro del contexto en que se realiza el proyecto, no se trata por tanto de aplicar una metodología o un proceso como un martillo de oro que asegura el éxito en todos los casos sino de adecuar nuestros esquema de trabajo al producto que vamos a desarrollar.

En un entorno con una incertidumbre inherente es fundamental poder adaptarse al cambio y eso implica por un lado no poder estar atado con procesos rígidos (salvo que el contexto del proyecto o la naturaleza del producto que se desarrolla te obligue a ello) y por otro la existencia de una comunicación fluida entre todos los participantes en el proyecto pudiendo realizar, dentro de los márgenes que existan para ello, ajustes sobre condiciones o planificaciones que previamente se han establecido.

El enfoque ágil no es la consecuencia de hacer menos pesados los enfoques clásicos, no se trata de trabajar con procesos más ligeros o entregar menos documentación (no es solo eso), sino que supone un cambio más radical (entre otros): producto sobre proceso, cambio del modelo de comunicación entre las personas y adaptación al cambio.

Hacer predicciones y acertar sobre prácticamente cualquier sector es ciertamente complicado. Si fuera fácil todos alcanzarían el éxito constantemente y no es así.

En un mundo como el de la tecnología que cambia de manera vertiginosa, donde desde cualquier sitio puede aparecer un software o un hardware revolucionario, las predicciones son, si cabe, todavía más complicadas de hacerse realidad.

Ahora bien, Alan Kay, probablemente basado en la experiencia de las empresas en la que ha trabajado y en la labor desarrollada en las mismas (centrado fundamentalmente en la investigación y el desarrollo), realiza una reflexión muy interesante para todos aquellos que quieran hacer realidad sus expectativas: “La mejor manera de predecir el futuro es inventarlo”.

Hace unos meses en una reunión donde se proponía el desarrollo de un gran sistema que gestionaba un proceso importante de mi organización, el cual también existía en el resto de organizaciones que comparten el mismo paraguas institucional, uno de los participantes de la misma dijo que los sistemas centralizados estaban obsoletos, anticuados y que lo que molaba eran los sistemas distribuidos, es decir, que cada entidad de la organización gestionase su instancia del proceso como quisiera y después al final se consolidase la información en el sistema central.

Yo no soy a priori partidario de los sistemas centralizados ni de los sistemas distribuidos, creo que hay que estudiar primero el problema, la infraestructura tecnológica que le puede dar soporte y después buscar la mejor solución.

En el caso del sistema que se debatía en la reunión, la solución sencilla es la construcción de sistemas independientes que alimentasen al gran repositorio central, sin embargo presentaba dos inconvenientes que eran importantes tener en cuenta: Al ser un proceso horizontal en la organización hay muchos subprocesos comunes, esto se hace más patentes si subimos la escala y en lugar de la organización tomamos como referencia la institución, esto implicaba repetir la implementación de un mismo subprocesos en distintos sistemas de información, además si no existe una visión común de los mismos, en cada organización o departamento se le puede dar una solución distintas, con la inseguridad desde el punto de vista jurídico que eso conlleva, el coste de implementación (repetir varias veces la solución a un determinado problema) y de mantenimiento. Otro problema importante es la duplicación de datos en repositorios distintos, lo que puede provocar problemas de coherencia en el caso de que los mecanismos de sincronización no estén debidamente ajustados, tengamos en cuenta que en el caso del sistema que nos ocupa debería tener información alfanumérica, cartográfica y documental (y en gran volumen).

Por todo lo anterior yo defendía una solución centralizada, la cual era más complicada de desarrollar ya que necesitaría de instrumentos normativos que obligase a los distintos departamentos a trabajar de una determinada manera y además requería poner a un mayor número de personas de acuerdo. La solución no obstante sería mixta en algunos aspectos, ya que probablemente por motivos de rendimiento, podría ser recomendable que cada organización o departamento manejasen, como mínimo sus propios repositorios cartográficos y documentales, implementándose por tanto los procedimientos de sincronización oportunos.

¿Qué pasó finalmente? Pues que un proyecto tan ambicioso requería forzosamente una gran inversión económica y en la época en la que estamos no está el horno para muchos bollos. Supongo que algún día se retomará y espero que con una solución centralizada.

Otra característica que viene acompañando a la producción industrializada de software es la deslocalización de los recursos humanos necesarios para realizar el proceso de desarrollo de software.

La deslocalización, desde mi punto de vista, busca:

– Mano de obra más barata que en centros de desarrollo de software con más competencia en el mercado, como por ejemplo Madrid, Barcelona, Sevilla, etc…
– Ir directamente a la fuente del talento. La existencia de menos competencia en el mercado, hace que el talento de la región donde se sitúa el centro de desarrollo de software vaya en casi su totalidad a éste.
– Apoyo institucional. La deslocalización genera trabajo en las zonas en que se instalan estos centros de desarrollo de software.

La deslocalización es positiva en cuanto a que:

– Es una fuente importante de trabajo en las provincias en las que se instalan.
– Contribuye al desarrollo tecnológico de la región.
– Evita la marcha de una buena parte del talento tecnológico.

Sin embargo, es negativa, si el fin último que se busca es la mano de obra barata. Esto dependerá, como es lógico, de cada implantador y de sus objetivos.

Pese a que vaya asociada la deslocalización a la producción industrializada de software no tienen nada que ver, es decir, la deslocalización en sí, no va a mejorar el proceso de desarrollo de software, ya que simplemente es una estrategia empresarial.

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.