Maven - Administrando tu vida

Piensa en un mundo en el cual estás solo, tú no estás dependiendo de nadie, no necesitas nada más que a ti mismo. Tú puedes realizar tus tareas y sobrevivir sólo por tu propia cuenta. Si te gusta eso, entonces puedes hacer pocas cosas en tu vida.

Un proyecto Java no está solitario

Construir un proyecto Java puede parecer simple, se necesita compilar las clases java y obtener la funcionalidad en un .jar. No obstante, en otros casos, un proyecto Java es más grande, el cual está usando una gran cantidad de proyectos diferentes de los que depende, es algo más difícil de manejar porque esos proyectos tienen sus propias versiones. Si hay muchos proyectos trabajando juntos, cada uno con sus versiones y cadena de dependencias, entonces es necesario automatizar eso. El tiempo no puede ser desperdiciado en tareas repetitivas, la preocupación está en escribir código. Y se necesita buen código.

¿Los proyectos Java unidos son más fuertes?

Alguien puede decir "Para administrar mi proyecto sin depender de nadie, colocaré todas las clases Java en un único proyecto". Alguien puede hacer esto, y puede hacer lo que quiera, pero violará todas las buenas prácticas y recomendaciones de diseño. Se tendrá un complicado proyecto que nadie será capaz de mantener porque este único proyecto no se encuentra separado en componentes con diferentes propósitos.

Cuando un proyecto más listo es construido usando un poco de sentido común, este proyecto tendrá un propósito y este tiene una responsabilidad. En este caso, hay varios proyectos que trabajan juntos, cada uno sabe los proyectos que necesita para hacer su trabajo. Ellos no están trabajando solos y cuando se necesita arreglar algo o adherir una nueva funcionalidad, entonces será más fácil saber dónde empezar a codificar. Tu diseño tiene sentido ahora.

Controlando la vida de un projecto

Maven puede ayudar cuando hay un proyecto java y tareas repetitivas como el manejo de versiones y su manejo de dependencias, los cuales pueden convertirse en un dolor de cabeza. Los nombres de los proyectos y la versión solamente es especificada una vez, sólo una vez, y el equipo puede preocuparse de codificar u otras actividades más importantes. Así mismo, el proyecto codificado también tiene una versión, entonces puede ser referenciado por otros.

Maven trabaja con repositorios, los cuales contienen los proyectos .jar necesitados y descargados. También pueden existir otros repositorios donde el jar es deployado, los desarrolladores no están trabajando solos, y cada uno tiene que trabajar con la última versión de todos.

Maven usa comandos simples para construir todo un proyecto, esos son repetitivos y siguen  algunos estándares como estructura de las carpetas donde está el código, los test, recursos, etc., los problemas para manejar los proyectos son reducidos.

El código Java es usado para obtener la funcionalidad y el pom xml es usado para manejar el proyecto, ese archivo es lo que entiendo Maven, ese es el proyecto en sí mismo.

Y es más que eso

 Maven usa plugins con diferentes intenciones. Ellos pueden ser usados para correr test, deployar un proyecto en un servidor, generar reportes, etc., hay muchos de éstos y son añadidos más. Incluso es posible hacer tu propio plugin.

Los archetypes permiten construir un proyecto war, ear, o un jar, entre muchos otros, añadiendo Spring, JSF y muchas tecnologías más, solamente usando un comando sencillo. Empezar a codificar en un proyecto rápidamente, viendo sus resultados, es más fácil. En el caso que no se necesita seguir la misma estructura del archetype, es permitido hacer modificaciones en la estructura del proyecto porque el pom generado puede cambiar. 

Como los proyectos, Maven no está trabajando sólo

Existe una comunidad de código abierto que se encuentra integrando Maven con otras tecnologías como Hudson que necesita construir un proyecto y correr sus test automatizados. También usar plugins para deployar automáticamente un proyecto en un servidor y tiene mucho más por ofrecer.

Maven también tiene algunas desventajas, aquí hay algunas de ellas:

• El archivo pom puede ser muy grande. Si el proyecto usa muchas dependencias y plugins, entonces no hay forma de separar las partes. El archivo es más difícil de entender a medida que crece.
• Dos dependencias de un proyecto pueden necesitar la misma dependencia, pero con diferentes versiones. Las dependencias transitivas son más difíciles de manejar.
• Una dependencia que no compila puede necesitar otras dependencias (dependencias transitivas) y es necesario actualizar esta última y compilarla en el caso que se encuentre en construcción también.
• El ciclo de construcción de un proyecto puede ser lento, aunque sus pasos son necesarios. Éste necesita descargar todas las dependencias, compilar, correr los tests, instalar y deployar. Se puede especificar si se quiere ignorar algún paso.

Maven administra la vida de un proyecto. Tiene algunas deficiencias, pero hace su trabajo y lo hace bien.

Retrospectivas ágiles

Los equipos que usan Scrum, o algún derivado de éste, tiene un evento llamado Retrospectiva. La retrospectiva es un rito donde el equipo se reune al final de cada iteración y el  objetivo es mejorar, en la práctica se trata de detectar los puntos fuertes y débiles, luego deciden cómo y qué mejorar. La mejora continua se mantiene, lo que es una base para todo entorno ágil.

Así, los equipos se adaptan y cambian, sobreviviendo en esta industria que privilegia la velocidad y el software a tiempo, siendo las bases para que una empresa pueda mantenerse, superar a otras o encontrar nuevos nichos.

Sin embargo, no se trata de hacer retrospectivas solamente por cumplir con lo que establece Scrum. Algunas situaciones comunes son:

• ¿Qué pasa cuando proponemos cerca de 20 mejoras a realizar? No tengo dudas de que ninguna de esas mejoras se van a realizar, son muchas ideas y es un trabajo arduo medirlas. Son tantas que el equipo no se puede enfocar en alguna.
• ¿Qué hacemos durante la retrospectiva? Tampoco se trata de reunir al equipo y que mencionen lo bueno, lo malo, lo bonito y lo feo. Muchos de los participantes pueden estar pensando en lo que deben entregar, otros en la forma en que perdemos el tiempo, o hasta algunos agradecen estar lejos de su rutina diaria por unos minutos.

Las mencionadas y muchas otras situaciones acontecen durante las retrospectivas. Cuando el equipo siente que es una completa pérdida de tiempo, entonces es mejor no hacerlas. 

A continuación, voy a mencionar algunas bases e ideas para llevar a cabo una retrospectiva:

• Cada equipo tiene necesidades y situaciones diferentes. Algunos equipos tienen mala comunicación, a otros les falta coaching, aprender formas de programar, hacer mejor Stories, o automatizar tests. Las retrospectivas se guían según las necesidades actuales del equipo.
• Hay que tener una planificación de las actividades que se van a realizar, según la cantidad de personas y tiempo. Así como considerar las etapas que pueden ser: presentación, enfocar a las personas hacia la retrospectiva, recolectar datos y situaciones que han pasado durante la iteración, encontrar patrones, proponer ideas, y por último el cierre. El libro Agile Retrospectives (de Esther y Diana) menciona sus posibles fases y detalla varias de las actividades a realizar durante cada una.
• Durante las retrospectivas son sumamente importantes las dinámicas que se manejen. Gracias a ellas podemos encontrar los problemas, patrones y soluciones adecuadas.
• Cuando el equipo encuentra los puntos a mejorar, éste sabe cuáles son los más importantes. Por lo tanto, tiene que priorizarlos y escoger muy pocos (por ejemplo dos). Así, el equipo sabe lo que va y tiene que mejorar, estableciendo responsabilidades según el caso.
• En las retrospectivas trabajamos con personas, por ende, tenemos que considerar sus emociones, energías y actitudes.

Y por último, las retrospectivas pueden ser usadas en cualquier equipo que se dediqué al desarrollo de software u otro tipo de labor, no es requerido el uso de Scrum, sino la voluntad de hacer mejor el trabajo, de ser un mejor equipo.

Me quedo con algunas incognitas: ¿Cómo llevar una retrospectiva en línea? ¿Cómo hacer ver al líder del equipo que las retrospectivas deben ser guíadas de otra forma? ¿Qué actividades escoger según la situación de cada equipo?

Mi Motivación

El software no se puede tocar, pero se puede crear y observar. Algunas veces es apreciable, mientras que en otras dan ganas de gritar y salir corriendo.

El software es más allá de ceros y unos, es la combinación de éstos para crear algo mayor, algo complejo, algo que nadie ha imaginado. Los ceros y unos son algo más básico que los átomos que conforman las moléculas y a su vez, seres más complejos. Los binarios son el inicio y quizás el fin.

El software es visto como arte, es una creación del ser humano. Y sí, puede llegar a ser tan hermosa y hasta tener nada que envidiarle a las más grandes obras. El objetivo mayor es superarlas.

Los ceros y unos van más allá de lo que se ve, porque su creación puede ser realizada por muchas personas. La comunicación y relación entre personas tienen un potencial, y tiene que ser explotarlo.

En fin, los ceros y unos son como hijos. Por eso, ellos son nuestra responsabilidad, podríamos llorar de felicidad por una buena creación y sentirnos orgullosos por el trabajo bien realizado.

Me atrevo a admitirlo, es lo que me mueve.