Maqueta de la Escuela Politécnica de la Universidad de Alcalá, en los pasillos de la Escuela.

Detalle de la biblioteca de la Escuela Politécnica de la Universidad de Alcalá.

Edificio de la Unidad de Investigación en Telemedicina y e-Salud del Instituto de Salud Carlos III. Campus de Chamartin.

Laboratorio en la Escuela Politécnica Superior de Informática. Universidad de Alcalá.

Detalle del patio interior de la Escula Politécnica Superior. Universidad de Alcalá.

Mostrando entradas con la etiqueta Metodologías. Mostrar todas las entradas
Mostrando entradas con la etiqueta Metodologías. Mostrar todas las entradas

martes, 9 de agosto de 2011

Dar ánimos contribuye a la motivación

Los ánimos son buenos en todo proyecto. A nadie, al menos que yo conozca, le molesta que le den ánimos en el trabajo o en cualquier reto de la vida, pero de qué forma hay que dar ánimos?. En este sentido, Adrian gostick y Chester Elton en su libro "Buenos equipos, poroyectos imbatibles" identifican una serie de claves a tener en cuenta:
  • Reconocer un buen trabajo. Alentar comprotamientos que refuercen valores o metas clave, o talentos personales, es una buena forma de dar pie a que se copien por los demás integrantes del grupo.
  • Quedarse con lo positivo. Recordar una conducta negativa y hablar sobre lo mucho mejor que ha llegado a ser una persona, no es constructivo para dar ánimos. Es mejor mencionar sólo lo positivo, no la transformación que ha tenido el sujeto.
  • Reacción inmediata. Cuanto menos tiempo pase entre la acción en sí y el hecho de animar mejor será el efecto.
  • Dar ánimos de forma cercana. Gran parte de los ánimos provienen del reconocimiento y la apreciación, y la mejor forma de demostrarlo es en el ambiente habitual y entre los iguales de la persona en cuestión (no en un despacho a solas)
  • Ánimos horizonles y verticales. En muchos casos se da ánimos de arriba a abajo. Pero a veces el reconocimiento más efectivo proviene de los propios compañeros (son quienes mejor entienden las circunstancias con las que hay que lidiar).
Los ánimos, la motivación, el entusiasmo, la alegría en el trabajo, son conceptos que en muchos sitios se han olvidado, en otros ni se lo plantean por desgracia. Sería bueno re-educar a los responsables de proyectos, directores y demás mandos intermedios y superiores de algunas empresas y organismos públicos en la idea subyacente de la correspondencia directa entre estos conceptos y la productividad del grupo y que no estaría de más ponerlos en práctica, estoy seguro que los resultados serían inmediatos.

domingo, 12 de junio de 2011

Frameworks MVC de desarrollo. Propuesta de adopción de tecnologías de desarrollo web en la UITeS

Con el fin de establecer una arquitectura de desarrollo en la Unidad de Investigación en Telemedicina y e-Salud que permita una mayor eficiencia en el desarrollo de las aplicaciones en las que está inmersa la Unidad, el pasado 8 de junio presentamos un trabajo titulado "Frameworks MVC de desarrollo. Propuesta de adopción de tecnologías de desarrollo web en la UITeS" donde se analizaron diferentes patrones de diseño acordándose la adopción de alguno de ellos como principio de desarrollo en la Unidad. De los varios patrones que vimos, centramos nuestra atención en el patrón Modelo-Vista-Controlador identificándose las ventajas que nos aportaría desarrollar con este patrón como podrían ser las siguientes:
  • Desarrollo rápido
  • Reutilización de software
  • Diseño uniforme
Dentro de los frameworks que implementan o facilitan la implementación de este patrón o arquitectura MVC, analizamos algunos de ellos clasificándolos en dos grandes grupos atendiendo a los lenguajes de programación planteados en la Unidad. En UITeS existen dos grupos de investigación, cada uno de ellos con un lenguaje de programación atendiendo a diferentes criterios, por un lado el grupo de desarrollo en Java y por otro el grupo de desarrollo en PHP. Creemos que la existencia de dos grupos que codifiquen en diferentes lenguajes de programación y con la proyección que tienen tanto Java como PHP es positivo para la Unidad, teniendo además en cuenta que las aplicaciones existentes utilizan el protocolo SOAP para realizar peticiones a los distintos webServices que tanto un grupo como otro tienen desarrollados y publicados para toda la Unidad.

Tendiendo en cuenta esta premisa, se presentaron diferentes frameworks para cada uno de los lenguajes presentes, por un lado se analizó el framework Symfony para el lenguaje PHP5. Este framework automatiza la mayoría de los elementos comunes de los proyectos web como la internacionalización, las plantillas y layouts, la validación, gestión de caché, etc.

Por otro lado, respecto al lenguaje Java, se analizaron distintos frameworks con el fin de hacer la elección final lo más acertada posible. En este sentido se analizaron frameworks como Struts, JSF o el framework Play. Este último aportaba diferencias substanciales con respecto a los anteriores como ser completamente stateless(es decir, sin estado) o su fundamentación en HTTP lo cual le hace muy aconsejable para los desarrollos de aplicaciones RESTfull, entre otras.

Finalmente y teniendo en cuenta la necesidad presente y sobre todo en un futuro cercano de realizar aplicaciones para dispositivos móviles se analizaron diferentes frameworks para el desarrollo de aplicaciones, siempre en un entorno web, para diferentes dispositivos móviles como son los basados en Android o bien los iPhone. En este sentido se analizaron framework como JQuery Mobile, Sencha Touch o DHTMLX Touch, siendo este último frameworks en el que se fijaron las miradas debido en gran parte a su simplicidad, basado en librerías de HTML5 y Javascript y en su entorno gratuito de programación visual, acordándose estudiar su uso con posterioridad.

lunes, 9 de mayo de 2011

SCRUM: Metodología Ágil a utilizar

Analizando unas cuantas metodologías ágiles creo haber encontrado con la que mejor se adapta a todos los proyectos en los que he participado y en donde las metodologías ágiles de desarrollo han brillado por su ausencia. Desde mi punto de vista y basándome en más de 15 años como profesional en el desarrollo de aplicaciones tanto en entornos empresariales como gubernamentales, la calidad de los desarrollos ha tenido que ver mucho con las metodologías utilizadas que, sinceramente, no han sido muchas.

Es por esto que durante el desarrollo de esas aplicaciones, aparecen factores negativos como la desmotivación del equipo, la falta de liderazgo, la falta de una visión global de la aplicación, etc. Todo esto influye notablemente en la calidad y en la duración de estos proyectos. No es de extrañar que ciertos proyectos atractivos desde la misma concepción de la idea se hayan tenido que abandonar por falta de liderazgo en el grupo, o por cambios producidos en el grupo de desarrollo o lo que considero más grave todavía, por desidia de la misma dirección del Departamento, empresa o Servicio.

En esta ocasión presento la metodología Scrum, una estrategia de gestión donde se aplican de manera regular un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestión de un proyecto software. Esta metodología permite la trazabilidad de los requerimientos que se establezcan pemitiendo identificar y registrar cada uno de ellos de forma que se pueda seguir su ciclo de vida tanto desde su origen hacia adelante como desde su entrega hacia atrás.

Scrum identifica 3 tipos de roles:

1. Product Owner: Propietario del producto
2. ScrumMaster: Responsable del correcto funcionamiento de Scrum en el proyecto
3. ScrumTeam: Equipo de desarrollo

Scrum divide el desarrollo global en una serie de hitos o Sprint que son reuniones en las que están presentes todos los roles establecidos y donde se acuerdan los requerimientos generales para esa parte del proyecto. De esta forma se puede modularizar el proyecto teniendo ya desde el primer Sprint una versión operativa del producto para que sea visualizado por el cliente. Este dato es muy importante si nos fijamos en el ROI (Retorno de inversión) que puede existir en un determinado desarrollo, pudiendo anticiparse al "time to market" del producto.

Sobre el intervalo entre cada Sprint algunos autores apuestan por los 60 días, en mi opinión esta frecuencia debe estar acorde con los objetivos que se marquen y aquí es donde el ScrumMaster debe hacer bien su trabajo, no hacer estimaciones vagas basadas en ningún dato objetivo, una posible solución durante los Sprint de un proyecto pueda ser la utilización de mecanismos para el cálculo de estimaciones como pueden ser los gráficos PERT para después, basándose en los datos obtenidos por los gráficos BurnDown hacer estimaciones basadas en el esfuerzo y logros del ScrumTeam, de este modo conseguimos un menor riesgo en la estimación de realización de tareas.

La siguiente presentación no tiene más de 30 diapositivas y creo que es muy interesante visualizar para adentrarse en esta metodología o estrategia de gestión de proyectos software.

Bye.

Introducción a la Metodología SCRUM

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites