Este artículo va dirigido a todos aquellos que se están iniciando en el mundo de la programación, tú que has decidido embarcarte en este mundo de lógica y matemáticas. En algún momento, mas vale pronto que tarde, decidirás abordar tu primer proyecto de software, seguramente sea un proyecto personal para aprender. Precisamente por este motivo debes conocer el método o los métodos que debes seguir para crear ese proyecto, esa aplicación. En este artículo no te voy a dar las pautas para su realización, ni las palabras mágicas que hagan que tu proyecto se finalice con éxito, te voy a contar mi experiencia de cómo lo he hecho yo hasta hace unos años y cuál es la tendencia actual. Algo que me hubiera gustado haber leído cuando comencé, que me lo hubieran enseñado desde el principio.
Equivocadamente, la producción o construcción de software está ligada al mundo industrial. Esto es debido a que hace ya mucho tiempo, en una galaxia lejana…., bueno, en nuestra galaxia y hace aproximadamente uno 50 años, se empezaron a plantear cómo se debía producir el software. En aquella época, años 60, empezaban a tener los primeros problemas con la programación y había que organizarse. Como era algo muy novedoso se decidió aplicar las mismas técnicas del mundo industrial al mundo del software, si funcionaba en un sector ¿por qué no iba a ser valido para el sector del software? Entonces comenzó a gestarse el Método Tradicional también llamado, Ciclo en Cascada o Método Secuencial Lineal. Este método nos ha acompañado hasta nuestros tiempos y seguirá eternamente con nosotros. Es importante conocerlo, ya que mucho software está creado mediante este método y lo más importante, hay que conocer sus debilidades para corregirlas.
El Ciclo en Cascada consiste en producir software como si fuera una cadena de producción. Tenemos diferentes fases consecutivas, comenzando por la primera fase, iremos finalizando cada una de ellas sin pasar a la siguiente fase hasta que no se haya terminado la anterior, igual que en el mundo industrial, como si se construye un coche o cualquier tipo de máquina. Las fases de este método son:
- Análisis de requisitos
- Diseño del sistema
- Desarrollo del producto
- Realización de pruebas
- Implantación en el cliente
- Mantenimiento
No te voy a detallar cada una de las fases, hay mucha literatura escrita a este respecto, pero si que quiero que entiendas que este método es muy poco flexible. Imagínate que estás en un proyecto, tienes un cliente y sigues el Ciclo en Cascada. El cliente interviene en la primera fase, donde se hace una reunión y se define claramente el problema y los requisitos del proyecto. A partir de este momento el cliente se desentiende hasta la fase de implantación. Esto quiere decir que no interviene en la fase de diseño, de desarrollo y de pruebas pero, ¿cuánto tiempo abarcan estas fases? Pues créeme, en muchas ocasiones pasan meses y años, imagínate lo que puede cambiar el mundo y la empresa a quien va dirigido el proyecto, puede que ni exista cuando termines.
Otro problema es que este método no tiene vuelta atrás es decir, si estamos en la fase de desarrollo no podemos hacer regresar al proyecto a la fase de diseño porque a alguien se le ha olvidado tener en cuenta alguna cosa. En proyectos grandes y medianos lo más común es que haya diferente personal asignado a cada una de las fases o tareas por lo tanto, los programadores no han intervenido en las fases de diseño ni de análisis, es más, la gente que haya intervenido en la fase de diseño probablemente tampoco haya hecho el análisis así que los errores también se transmiten en cascada.
Este método ha sido el más utilizado durante muchos años, en la actualidad muchas empresas siguen utilizándolo aunque poco a poco van surgiendo nuevas metodologías llamadas ágiles. Todo nace en el año 2001 con el Manifiesto Ágil. Un grupo de desarrolladores, cabezas pensantes, se plantearon la idea de hacer software de otra manera. Querían romper la relación con el mundo industrial, abandonar sus métodos y comenzar un camino nuevo. Hacer software no es como hacer un edificio o un puente, el software es algo que puede amoldarse y cambiar cuando se está creando. No es necesario tener unos planos fijos e inalterables para su creación. Cuando se construye un edificio, si al arquitecto se le olvida que el edificio tiene un sótano y está a medio construir, es imposible corregir el error si no derribas el edificio. En el software es posible tener en cuenta estos imprevistos si comienzas de una manera ordenada y estructurada, pudiendo alterar las funcionalidades, introducir mejoras y corregir errores en mitad del proyecto.
Pero entonces ¿en qué consiste las metodologías ágiles? Aunque no soy un experto en la materia, si que me he estado informando sobre el tema e intento, en la medida de lo posible, aplicar esta filosofía a la hora de desarrollar software. El primer contacto con la agilidad lo tuve hace más de cuatro años, descubrí que había otras formas de hacer las cosas, una manera mejor que no solo repercute en la consecución de hacer un producto bueno y mantenible, hacía que yo me sintiera mejor por el trabajo bien hecho. Agilidad no tiene una definición, no tiene unas fases, no es rígido, es simplemente una manera de trabajar. Tiene unos principios básicos que se detallan en el Manifiesto Ágil.
Gracias a la agilidad, pasamos de un ciclo en cascada a un ciclo iterativo. Lo que se pretende con este método es acortar los tiempos de entrega del producto creando prototipos intermedios que se entregan al cliente para que los pruebe. Pongamos un ejemplo, nos llega el cliente, tenemos la reunión y se define claramente el problema que queremos resolver y los requisitos. En el método antiguo con todo esto empezábamos a diseñar y a crear, con el método iterativo lo que se hace es, coger los requisitos más importantes, 2 o 3, y comenzar con ellos sin tener en cuenta nada más. Se trabaja durante un periodo breve de tiempo creando un prototipo que se entrega. El cliente lo prueba dando su opinión (feedback). Con esta información se trabaja y se añaden nuevos requisitos para la siguiente iteración, el siguiente prototipo, hasta llegar al producto final. En todo momento tenemos contacto con el cliente aportándonos sus conocimientos y sus necesidades. Cuando lleguemos al final del proyecto no habrá que hacer nada más que la implantación ya que en todo momento el cliente ha tenido contacto con el producto.
El ciclo ágil se basa en el ciclo iterativo pero intenta acortar los tiempos de creación de prototipos. Además introduce nuevos conceptos como refactorización, la refinación del producto en cada prototipo, el código limpio, código espagueti y muchos más conceptos que debemos asimilar los programadores de la vieja escuela, conceptos que más que inculcarte una manera de hacer la cosas te hacen entender la profesión de otra manera. Ser programador es algo bastante complejo, tenemos que comprender que estamos elaborando, creando un sistema donde interviene la técnica, la imaginación y la creatividad. Debemos ser muy claros, muy ordenados y que nuestro código pueda sufrir cambios sin que se resienta en las funcionalidades del sistema.
Por lo tanto, tú que te estás iniciando en este mundo, que quieres hacer tus propios proyectos o dedicarte profesionalmente a este sector, empieza ya a trabajar de forma ágil, aprende todo lo que puedas y empieza por el principio. Yo ya he empezado y poco a poco tenemos que hacer que esta profesión deje de formar parte del mundo industrial para conseguir ser unos artesanos del software.