abril 30, 2008

Escenarios ante "SpringSource Application Platform"

Tenemos una nueva plataforma de aplicaciones JAVA: SpringSource Application Platform. Es una plataforma que no cumple JEE completamente, y de hecho no parece que lo vayan a hacer. Soportan los módulos web como WAR, pero no se asoman los EJBs.
¿Necesitamos otra plataforma de aplicaciones en el mundo JAVA? Creo que no. El punto fuerte de esta nueva plataforma parece que va a ser la utilización de una plataforma OSGI. Esto puede ser un respaldo muy fuerte para esa arquitetura que no acaba de despegar en las aplicaciones reales. Pero tampoco es tan necesario, ni las ventajas que aporta son tan decisivas, nada que no se pueda hacer en el estandar JEE.
Como comenta Martín, esto podría ser un punto de inflexión en el mndo JAVA empresarial. Si se rompe la unidad sobre la plataforma JEE, podemos acabar con una de las ventajas más importantes: la interoperabilidad. Es cierto que ya hay muchas lineas de arquitecturas diferentes en JEE, pero la fuerza de Spring actualmente en muchos desarrollos pueden dar una fuerza muy importante a esta nueva plataforma.
De todas maneras, siempre es genial ver cómo hay gente que no se cansa nunca y tiene ideas novedosas y mejoras en un mundo en el que para algunos las cosas se han anquilosado demasiado. Y además, ahora ya tenemos un juguete nuevo para cacharrear :).

abril 29, 2008

Patrones y mejores prácticas

Una de las ideas que me rondaba la cabeza hace tiempo es cómo aprendemos, y cómo enseñamos. Los últimos libros que he leido plantean estas cuestiones en base al concepto de patrones. Y me gusta. Patrones de cómo hacer las cosas en determinados contextos, proponiendo determinadas soluciones. También puedes aprender las tareas a realizar para resolver algo, si alguien te dice qué pasos debes dar, los aplicas y listo.
Lo situo un poco en la linea de procesos vs. personas de las metodologías ágiles. Si quieres que alguien aprenda gestión de proyectos (¡de equipos!-tengo que hablar un día sobre "Software for your head"), ¿le das los procesos que debe seguir? ¿o le explicas las situaciones, las posibles soluciones, los problemas,...? Si quieres establecer cómo se deben de hacer las cosas, puedes establecer procesos, o puedes explicar las cosas, su porqué y su cómo, pero ¿cuando hacer una cosa u otra?
Acabo de leer un artículo que me parece muy clarificador, desde mi punto de vista, que solo llevo menos de un año con responsabilidades de jefe de proyecto, para aprender a enseñar y enseñar: Better Best Practices.
Plantea la evolución de las "buenas prácticas" en una empresa apoyándose en el modelo de Dreyfus del Aprendizaje. Este se basa en poner cinco etapas al aprendizaje, dónde cada etapa tiene unas necesidades para realizar bien sus tareas y aprender con ello. Hay cinco niveles, resumidos más o menos:
  • Novice - Needs to be told exactly what to do. Very little context to base decisions off of.
  • Advanced beginner - Has more context for decisions, but still needs rigid guidelines to follow.
  • Competent - Begins to question the reasoning behind the tasks, and can see longer term consequences.
  • Proficient - Still relies on rules, but able to seperate what is most important.
  • Expert - Works mainly on intuition, except in circumstances where problems occur.
La conclusión que he sacado después de leer el libro "Acerca de Internet" (que me compré por que ese artículo me picó la curiosidad), es que los procesos impiden la excelencia y la brillantez en los trabajos, pero que son necesarios para llegar a un nivel medio de desempeño, especialmente útiles en las fases de aprendizaje.
De aquí podemos llegamos a dos conclusiones de manera un poco más formal que creo ya he comentado otras veces, sobre las metodologías de desarrollo:
  • Sobre las metodologías ágiles, que es dificil integrar a gente más "novata" en ellas. No hay procesos, y la gente sin experiencia necesita una guía más centrada en qué hacer. No se desenvuelven bien en entornos que aún no controlan.
  • Sobre las metodologías basadas en procesos: Que impiden que la gente experta sobrepase el listón establecido de "media"(¿mediocridad?) en los procesos, y no sé aprovechan las experiencias completamente.

abril 08, 2008

Testeo, cerdos y gallinas

¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...

abril 07, 2008

Usabilidad de los funcionarios

Biko2 ha publicado un informe sobre la usabilidad en webs de las Comunidades Autónomas. Podeis descargarlo en esta dirección de Biko2.

El equipo de consultoría y experiencia de usuario de Biko ha analizado los portales de las 17 Comunidades Autónomas españolas identificando aquellas que son punteras, presentando buenas prácticas e identificando los aspectos más críticos a mejorar.
Es un interesantísimo informe si te atrae el tema de la usabilidad o las administraciones públicas online. Lo que yo no sé es por qué nos preocupamos tanto por las situaciones online, cuando no sé si los de las ventanillas aprueban!
Veamos a la imagen típica de los funcionarios, tal y cómo es apreciada por multitud de nuevos aspirantes a un puesto "seguro para toda la vida", haciendo el paralelismos con lo que han aportado desde Biko2. :)
Posicionamiento. "Como me posicione en la silla con plaza fija no muevo el culo de ahí ni para levantarme al café... bueno, eso sí."
Servicios al ciudadano. "El ciudadano soy yo!"
Ventana al visitante. "Siempre y cuando no vengan a verme a la hora del café!"
Presencia Institucional. "Estaré presente siempre que venga el político de turno a llevarse las medallas"
Factores motivadores. "¿motivación? ¿para qué?"

Sé de buena tinta que la gran parte de los funcionarios curran de verdad, y lo que me preocupa no son los que ya están en el sistema sin pegar sello, si no la imagen que tienen muchos jóvenes de que irse de funcionario es el chollo, pero no por las buenas condiciones de trabajo o su interés, si no por que ya lo tienes todo hecho e incluso puedes aprovecharte de ello-forzando la situación-.

abril 06, 2008

Jornadas de testeo de software

El jueves estuve en el primer día de las jornadas sobre testeo de software JTS2008. La verdad que me han sorprendido la cantidad de conceptos que manejan en esta area, y que desconocía.
Hay varias cosas que tengo que analizar mejor. Me llama la atención que casi parece que son diferentes paralelos los procesos para la calidad mediante pruebas que la generada por los desarrolladores. Hablan de los testers por un lado, de sus pruebas, y no lo ligan demasiado a cómo eso afecta a los desarrolladores más que en que tienen que corregir los bugs que encuentran.
Y es curioso, por que yo tengo otro concepto más cíclico. Más que nada por que el concepto de fabricación con calidad, me resulta más atractivo que el de su control. Después de las pruebas, en algún momento se debería analizar lo que está pasando, para ver que se puede mejorar en el desarrollo que minimice en el siguiente ciclo de pruebas el número de errores.
Lo que sí coincido es que hace falta una persona (al menos) dedicada a diseñar/hacer pruebas de los sistemas en el equipo de un proyecto, y que no sea desarrollador.
¿Controlar la calidad, o fabricar con calidad? Yo que veo más cercano el equipo de desarrollo que el de testeo, me inclino a poner primero los medios en este primero para asegurar que hacemos software de calidad: lo que sea, pruebas unitarias, integraciones continuas, reuniones diarias, formación exhaustiva, mejores capturas de requerimientos, entregas iterativas,... y luego, pondría un equipo de test :)
Nos ha contado una persona de Google cómo tienen organizados los tests de sus apliciones: la palabra que más ha mencionado es "divertido". :) Curioso como cuenta que no tienen procesos establecidos, si no que cada uno es responsable de lo que hace y de cómo lo hace. Hay grupos de testeo en la empresa que apoyan a los creadores de productos, especializandose en las pruebas.

Anyway, bastante interesante la jornada, ya os daré más datos... o no,... :P os contaré más de la jornada del viernes, con más empresas contando sus experiencias. Idme contando, ¿teneis departamente de testeo de software?