Lecciones aprendidas

Recientemente hemos entregado a un cliente una aplicación software dentro de un proyecto que está a punto de terminar. Sólo queda cerrar algunos flecos que no dependen directamente de nosotros, sino del propio cliente. El proyecto era pequeño:

  • 5 meses en total
  • 4 meses desarrollando la aplicación
  • 1 Jefe de proyecto, 1 desarrollador del lado del cliente, 2 desarrolladores JEE y 1 asegurador de la calidad

Para la construcción hemos contado con:

  • Marco tecnológico Java: Spring framework, Eclipse Birt, Hibernate
  • ExtJS
  • DEIN – Ecosistema Software (de esto ya os hablaré)

Me gustaría contar algunas lecciones que hemos aprendido:

  1. Nos es conveniente homogeneizar los entornos de desarrollo local de todos los miembros del equipo. Aunque el cliente nos indique cuál es su entorno de producción y eso quede reflejado en los requisitos no funcionales del análisis, es altamente aconsejable la disparidad. Es una forma muy simple se disminuir riesgos y asegurar un mayor nivel de calidad. Concretamente en este proyecto hemos usado:
    1. Ubuntu, Eclipse, Jetty, JDK 1.5 (entorno de desarrollo local)
    2. Windows XP, Eclipse, Tomcat JDK 1.6 (entorno de desarrollo local)
    3. Debian, Tomcat, Apache, JDK 1.5 (entorno de despliegue virtualizado que DEIN proporciona)
  2. Las tareas de análisis nunca terminan. Cuando el analista decide que hay una versión estable de los requisitos y se ponen en marcha las tareas de implementación, se activa un proceso iterativo entre el diseño-implementación y el análisis. El objetivo final para el cliente es que lo que le entreguemos satisfaga sus espectativas, sin embargo, nosotros compartimos ese mismo objetivo y además tenemos que asegurarnos de que lo construido y lo analizado está sincronizado y se corresponden. ¿Por qué? Porque aunque sean desarrollos a medida (llave en mano) es probable que surjan ampliaciones, revisiones, etc. y por eso mismo tenemos que ser consecuentes con lo que hacemos. No es la primera vez que me encuentro un documento de análisis perfectamente maquetado con una página inicial en la que se indica que lo validó tal persona hace un año y recientemente se ha publicado una versión.
  3. Es importantísimo hacerle ver al cliente cuánto cuestan los cambios y todo lo que adicionalmente solicita. Entiendo que es una tarea complicada, pero ahí está la destreza de un buen jefe de proyecto. Lo que no podemos hacer es admitir cambios y mejoras durante la evolución del proyecto con el fin de mejorar la experiencia de los usuarios finales, y que luego, cuando el proyecto está terminando te inunden en procesos eternos llenos de burocracia.
  4. En tu planificación prioriza al máximo el obtener una primera release que puedas mostrar a los usuarios finales. Haz todas las entregar parciales que puedas y la disponibilidad del cliente permita. En este proyecto concretamente, el cliente ha tenido la oportunidad de ver todos los avances de forma diaria. DEIN se encargaba se desplegar todas las noches un SNAPSHOT del proyecto en el entorno de despliegue, que por supuesto estaba disponible para el cliente.
  5. Establece sesiones de trabajo (preferiblemente, semanalmente) con todos los miembros del equipo. Aprovecha esta sesiones de trabajo para hacer una puesta en común de perspectivas, dudas, aclaraciones, consideraciones, propuestas, etc…
  6. Procura que todos tus proyectos tengan algo de I+D+I. Disponer de un departamento de verdad de I+D+I no es sencillo y requiere inversión, pero cuando no se tiene esa opción, algo debemos hacer. Cuidado con los experiementos en proyectos pequeños, es muy sencillo incumplir en la planificación si algo no sale todo lo bien que esperábamos.

Supongo que la lista podría continuar, pero son los que puedo contar y pueden ser útiles. En cuanto me autoricen, publicaré algunas capturas de pantalla (y con suerte un screencast) sobre el proyecto.

5 thoughts on “Lecciones aprendidas

  1. Hola Manuel,

    Interesantes puntualizaciones.

    Si con algunas especialmente me identifico son con la 1, la 2 y la 4. Si al menos no es posible cumplir la 1 estrictamente, al menos si que haya variedad entre los entornos de desarrollo y el de integración / despliegue o como queramos designarle.

    Y llamémosle DEIN, Continuum, Cruise Control, Team System, … la IC es un concepto que aporta en mi opinión mucho a un proyecto. Por cierto no me sonaba de nada el nombre de DEIN.

    Un saludo

  2. Hola Javier:

    Es normal que no hayas oído hablar de DEIN, es la primera vez que lo menciono aquí.
    DEIN es el nombre que le hemos dado en el GMV a nuestra solución de Ecosistema Software. Llevamos tiempo trabajando en ella y con ella. Algunos de nuestros clientes la tienen implantada.

    Un saludo

  3. Muy interesante!
    El punto 2 es crítico… nos empeñamos todos en que nos “validen” un análisis, pero luego, todo sufre modificaciones, ni siquierea podemos estar seguros de que lo implementado cumple el análisis, que no hubo un telefonazoq ue cambio algo importante sin dejar rastro,…

    ¿de gestión del proyecto que hacíais?¿algo concreto como Scrum o RUP?

  4. Hola Joserra:

    Efectivamente, el punto 2 daría para hablar muchas horas. Nosotros lo que procuramos es confiar plenamente en el analista y que sea él quien -bajo sus criterios- determine cuando existe una primera versión estable del catálogo de requisitos. Tanto él como el resto del equipo saben que esa información no es un teorema y que muy probablemente sufrirá cambios. Como sabemos que eso es así lo que estamos haciendo es aprender a gestionar el cambio. Ahí tiene mucho que decir el marco tecnológico en el que trabajes, la experiencia del equipo y sobre todo la metodología.

    Me preguntas sobre nuestra metodología y no sé qué responderte. Reconozco que he leído bibliografía al respecto, sin embargo, mi mayor fuente de conocimiento viene de nuestro propio día a día y de grupos de trabajos como http://groups.google.com/group/ecosistemas-software. De forma bastante frecuente incorporamos nuevos conceptos a nuestra forma de trabajar. Recientemente hemos decidido que semanalmente, por proyecto, el equipo se reunirá -por las tardes y no más de 90 minutos- para hacer una puesta en común de ideas, resolución de ambigüedades, toma de decisiones, perspectivas, etc… Durante la semana, cualquier cosa que surja se comunica a través de una lista de correo que hay para cada proyecto. De esta forma, todo lo que se comente queda en conocimiento de todos los miembros del equipo. Evitamos así que el analista por ejemplo resuelva dudas de forma particular con situaciones como: “después de café te viene a mi mesa y vemos los requisitos de información sobre expedientes”.

    Lo que sí te podría asegurar es que nuestra metodología sería imposible (en términos de productividad y rentabilidad) llevar a cabo sin nuestro ecosistema software (DEIN).

    Un saludo

  5. Pingback: Mi espacio » ExtJS en nuestra caja de herramientas

Leave a Reply

Your email address will not be published. Required fields are marked *