Frameworks Ágiles para la Plataforma JEE


Frameworks Ágiles en la Plataforma JEE

Por: Ing. José Amadeo Martin Díaz Díaz
Twitter: @jamdiazdiaz

No soy mucho de escribir artículos, así que espero realmente que pueda transmitir adecuadamente el mensaje sobre los Frameworks Ágiles para la plataforma JEE.
En mis 12 años de experiencia profesional he sido analista programador, arquitecto, coordinador y Gerente en diversos proyectos para la plataforma JEE.  Utilizo el lenguaje Java desde que salí de la universidad la PUCP (1).
Si bien Java no se caracteriza por ser un lenguaje dinámico, sino más bien verboso y lleno de clases e interfaces que aprender, es hoy por hoy el lenguaje escogido por muchas organizaciones gubernamentales y privadas. “Al cesar lo que es del cesar”.
Sumado a esto tenemos diversos IDEs o entornos de desarrollo (NetBeans (2), Eclipse (3), Intellij Idea (4)), Contenedores de Servlets (Ahí tenemos al popular Tomcat (5)), Servidores de Aplicaciones para escoger (JBoss (6), WebSphere (7), GlassFish (8), WebLogic (9),  tc-server (10), etc), APIs, Middlewares, Enterprise Server Bus (Mule (11), Apache Service Mix (12)), Messaging como Rabbit MQ (13),  Frameworks de persistencia (Hibernate (14), Mybatis (15), JPA (16)), Frameworks Web (Spring MVC (17), Tapestry (18), wickets (19), struts 2 (20), JSF 2.0 (21)), y podemos seguir nombrando más categorías ubicadas en el segmento open source y/o comercial.

En definitiva hay muchos caminos que seguir, y supuestamente las empresas que deberían apoyarnos Oracle (22), IBM (23), RedHat (24) y ahora VMWare (25) en su mayor parte no se destacan por innovar, casi la mayoría de estándares que tenemos hoy vienen de iniciativas open source. Gracias a Hibernate y Spring podemos para “muestra un botón” dar como resultado el estándar compuesto por EJB 3 (26) y JPA.
El camino que esperamos no es difícil de pensar o desear. Ellos deberían seguir las actividades más productivas y eso volverlo estándar. No sacar un estándar que finalmente solo una muestra de la comunidad Java utiliza.  “Otro botón” el muy conocido Java Server Faces.  Que hoy por hoy aún no es adoptado en todas las organizaciones y se utiliza más en ambiente intranet y por evitar la complejidad del modelo request – response.
Los años pasan y no solo las metodologías están pidiendo cambios. Por muchos años hemos llevado proyectos siguiendo los lineamientos de RUP (27), PMI (28) y hemos seguido el esquema Análisis, Diseño, Construcción, Implantación, Soporte Post Implantación. Este modelo que suena a “Cascada” (29) funciona muy bien para proyectos predecibles, similares, pero, para crear nuevos productos o para proyectos de mucho tiempo puede convertirse en una relación en el que ni el cliente ni el proveedor al final se quieren ver. Creo que esto es entendible. ¿Quiénes fueron nuestros primeros profesores de software?, pues Ingenieros Civiles e Industriales. Ellos pues siguen dicho proceso. Nosotros necesitamos algo diferente.


Las metodologías ágiles entonces como Scrum (30), Kanban (31), XP (32) ya están causando muchos cambios e impacto en las organizaciones de a pocos. Lamentablemente y como pasa siempre en nuestro País, nos enteramos o adoptamos algo cuando ya en nuestros vecinos Argentina, Chile, Colombia, Brasil, por mencionar algunos ya vienen tras cuatro años practicando y aplicando.
Hoy por hoy también invito al lector a revisar sobre Lean Software (33) pues esto les permitirá ver que no siempre hay que estar pegado al estándar si es que este no nos permite marcar la diferencia. "Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez".
Estas metodologías tienen un común denominador y que es parte del manifiesto ágil (34) que dio lugar a todo: Dar importancia al equipo, las personas, sus interacciones; al software como nuestro objetivo final, el cual debe funcionar y no depositar nuestra confianza en sólo herramientas, o documentación exhaustiva, a dar valor en resumen a lo que es estrictamente necesario; trabajar en un esquema basado en iteraciones o ciclos cortos para obtener un mejor feedback del cliente, lo cual implica no tener un contrato en el cual el cliente y el proveedor no tengan una relación win-to-win. El punto es tener a las dos partes como ganadoras. Entonces tenemos que poder responder al cambio, por lo cual los cronogramas Gantt se van a la basura. Cronogramas que nunca han reflejado la verdad y solo dan aproximaciones. Entiéndase bien: No se puede predecir el futuro.
Ante todo esta parte metodológica mencionada anteriormente. Las exigencias de hoy entonces te piden desarrollar cosas “para ayer”. Durante los últimos años muchas empresas sobre la base de estándares java desarrollaban su Framework de Trabajo, lo que originaba tener un Arquitecto que daba mantenimiento a ese framework y llenarlo de todo lo que se necesitaba por proyecto creándose unos “Transformers” de arquitecturas para dar soporte a todas las necesidades.


Por suerte estos últimos años, toda esta onda ágil ha traído innovación e iniciativas open source para crear aplicaciones más rápidamente sin sacrificar buenas prácticas y performance. Iniciativas como Spring Roo (35), Grails (36), Play (37), Vaadin (38), Lift (39) han salido al mercado. Todas ellas open source, y dando soporte a nuevos lenguajes para la plataforma java como Groovy (40).
En particular he probado Spring Roo, que para entenderlo bien hay que conocer muchos de los proyectos de SpringSource.com, JPA.  Grails me pareció una muy buena idea como respuesta a Ruby (41) & Rails (42) que es otro mundo y no solo optar por JRuby (43), sino convertirse en un framework MVC para desarrollar con java y Groovy.
Play es como dice su traducción para desarrollar como jugando. Es muy sencillo de usar y basado en Scala (44) un lenguaje del cual también debes enterarte y que merece un artículo aparte. Está basado en Scala en su parte interna, pero puedes desarrollar con java. Permite recargar tus clases java sin bajar el contenedor.
Los otros no los he probado pero, puedes visitar los links que adjunto para enterarte por ti mismo estimado lector.  Aunque se puede criticar que solo sirve para hacer mantenimientos simples, para alguien que los ha usado y personalizado, les puedo asegurar que es una buena iniciativa y que no deberíamos desestimar. Hay buenos casos de éxito en países vecinos y en el extranjero. ¿Que esperamos? ¿Queremos sorprender al jefe? ¿Queremos destacarnos frente a la competencia con nuestra capacidad de delivery? Entonces te invito a leer más sobre ellos.
Espero les sea de utilidad y si se ha compartido mis datos personales, gustosamente podré colaborar con ustedes. Su colaborador José Díaz.


 

(1)       Pontificia Universidad Católica del Perú  http://www.pucp.edu.pe
(2)       NetBeans.org http://netbeans.org/
(3)       Eclipse.org http://eclipse.org/
(5)       http://tomcat.apache.org/
(6)       http://www.jboss.org/




 



 Elaborado para una revista en la universidad de Abancay.






Comentarios

  1. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  2. Es muy cierto, personalmente pienso que las metodologías ágiles son mucho mejores para desarrollar productos nuevos sobre todo startups. El "problema" podría estar intrínsecamente relacionado a la flexibilidad del contrato firmado con el cliente y que tan dispuesto está a trabajar con el framework Scrum. Puesto que el "cambio de chip" significa que el cliente tenga a su disposición la presencia de un Product Owner lo cuál va a representar un costo adicional.

    Saludos

    ResponderEliminar

Publicar un comentario

Entradas populares