Mi espacio

Supongo que será difícil que coincidamos en la respuesta, pero de eso se trata, de conocer distintas opiniones. Cuando digo con experiencia no me estoy refiriendo a que hayan participado en varios proyectos a lo largo de 2, 3 o 4 años escribiendo código Java, PHP o C. Me estoy refiriendo a que profesionales desarrollen su carrera profesional como desarrolladores de software.

Desconozco la organización en roles/perfiles que existen, pero en mi anterior puesto de trabajo como responsable de departamento de desarrollo, puse en marcha la siguiente propuesta:

Obviamente, por el tamaño del departamento y otros factores, tuve que prescindir de algunos roles, pero de haber continuado y crecido en número, hubiéramos tendido a esta propuesta. Recomiendo la lectura de Cracking the Code: Breaking Down the Software Development Roles. Detrás de esta iniciativa había varios objetivos pero los principales eran:

1. Especialización. Dar la oportunidad de que cada uno pudiera desarrollar su carrera profesional desempeñando una actividad con responsabilidades claramente definidas y conociendo el papel que juega dentro del equipo.
2. Facilitar la ejecución de procesos internos del departamento. En muchos de los procesos internos intervienen varios roles y saber quién tiene que hacer qué no es una tarea sencilla.

Aunque no lo parezca tu organización interna se puede ver condicionada o afectada por tu cliente. Desde que comencé mi actividad profesional en el 2001 he tenido la oportunidad de conocer a muchas empresas del sector, lo cual se traduce en conocer a muchos profesionales. He de añadir que salvo en contadas ocasiones (esto ya está cambiando) las empresas eran andaluzas o con sede en Andalucía. Hoy por hoy me sigue resultando extraño comprobar que parece existir una evolución profesional:

1. Desarrollador. Compañeros de universidad, conocidos y amigos coinciden con que su primer trabajo fue participar en un desarrollo, comenzar algún pequeño proyecto desde cero o simplemente instalar una aplicación, probarla y hacer sus manuales.
2. Analistas. Estos mismos pasan a participar en reuniones con los clientes, redactar actas de reuniones, atienden peticiones de cambio, redactan documentos de análisis, pero también siguen desarrollando de puertas hacia dentro en su empresa.
3. Jefe de proyecto. Básicamente todo lo anterior pero se añaden otras responsabilidades, algunas impuestas por la cultura interna de la empresa y otras por el cliente. Obviamente participas en la preparación de ofertas.
4. Consultor. Aquí ya pueden entrar muchas otras cosas, pero la idea es transmitir experiencia, de puertas hacia fuera eres “experto en“.

¿Quién origina o alimenta esta evolución?

• Los profesionales. ¿Somos nosotros lo que queremos pasar por todos esos perfiles? ¿Lo hacemos porque para ser consultor hay que haber sido desarrollador?
• Las empresas. Desde los departamentos de recursos humanos se fomenta esta evolución porque se cree que debe ser así.
• Los clientes. Sí, sí, los clientes. ¿Cuántos clientes conocéis que son ellos mismos los que imponen la estructura del equipo y describen las funciones a desempeñar de cada rol/perfil? Y si lo pensamos un poco, incluso estipulan el precio / hora de cada rol/perfil.

No afirmo, simplemente reflexiono en voz alta:

Si los clientes pagan más ciertos perfiles, lo lógico y normal es que las empresas vean ahí margen económico. Las empresas intentarán que alguien con 5 años de vida laboral pase a ser jefe de proyecto de cara al cliente. Internamente cobrará lo que tenga que cobrar. A todos nos gusta evolucionar profesionalmente y que nuestro trabajo se valore, y una prueba de ello son (o deberían) nuestras retribuciones económicas. Si me gusta desarrollar nunca podré cobrar 35K anuales porque los clientes no pagan por las tareas de desarrollo ese precio.

Ahora sí afirmo:

Sólo hay que ver los portales de empleo especializados en el extranjero para comprobar que sí es posible que haya desarrolladores de software con experiencia.

Una vez más una situación particular que en pocas otras profesiones sucede.

Desde luego me siento más crítico que nunca, pero no puedo evitarlo. Está claro que este gobierno no sabe hacer las cosas de otra forma y ha recurrido a una subida de los impuestos. La cuota de la seguridad social para trabajadores autónomos ha vuelto a subir.

El mes anterior:

No si va a ser verdad que es mejor estar en el paro, especialmente para aquellos que tenemos 9 años cotizados. Desde luego así no hay quien ponga en marcha un proyecto.

Hoy me ha comentado el gerente y dueño de una empresa algo que me gustaría compartir con los que siguen este pequeño espacio. Resulta que hoy iban a entrevistar a candidatos para varios puestos de trabajo. El número y los puestos no son relevantes. Obviamente las entrevistas estaban concertadas previamente. Viendo que uno de los candidatos no se presentaba, lo llaman por teléfono para conocer qué había pasado. Resultado de la conversación:

Es que lo que me ofreceis no me compensa, prefiero seguir cobrando el paro

Supongo que hay gente que mira lo que percibe en su cuenta estando en el paro y si estando contratado ingresa 50 euros menos, prefiere seguir en el paro. ¿Puede ser esto verdad? Es cierto que cada persona es un mundo y tiene sus circunstancias, pero que un empresario esté intentando cubrir un puesto de trabajo y escuche algo así tiene que dejarte de piedra.

Tengo la sensación de que esta gente que está esperando a que llegue un día y abran los telediarios diciendo “la crisis ha pasado, ya no hay crisis”. Reconozco que nunca he creído en los políticos  (sí en la política) y tampoco tengo esperanza de que vayan implantar medidas inteligentes, pero si alguien puede hacerle frente a la crisis son los propios empresarios, los mismos que la provocaron.

Como ya dije una vez, no me gusta escribir entradas que sólo hagan referencia a otros contenidos, pero en esta ocasión vale la pena.

La verdad es que llevo más de un mes sin escribir en este blog y todo tiene su explicación. Es conocido prácticamente por todos aquellos que me conocen profesional y personalmente que el pasado 16 de octubre dejé GMV para dar paso a nuevos retos. Durante estos meses muchas opciones se han estado barajando, pero entre todas ellas, la creación de un empresa es la que más me apetecía. Es algo que intenté en el pasado pero que sólo quedó en palabras porque no había equipo. Ahora sí existe un equipo, mucha ilusión y ganas de sacar adelante un proyecto. Un proyecto que tiene dos objetivos que destacan por encima de todos los demás:

1. El bienestar del equipo
2. Seguir disfrutando de nuestra profesión

En ese proyecto se incluye crear nuestra propia empresa, que desde un punto de vista empresarial también tiene los objetivos claros:

1. No hacer nada que impida alcanzar los objetivos anteriores. Por encima de la empresa está el proyecto común.
2. Generar nuestros propios puestos de trabajo. Del crecimiento futuro ya hablaré, pero os puedo adelantar que el crecimiento de la empresa no va a venir determinado por el número de personas que formen el equipo.

El nombre de la empresa es klicap – ingeniería del puzle, ya están firmadas las escrituras de constitución y en los próximos días tendremos el CIF. Por ahora podéis seguirnos en el blog que hemos puesto en marcha. Más adelante, y como parte de los objetivos trimestrales, intentaremos publicar el sitio web de la empresa con su identidad corporativa.

Internamente estamos definiendo las líneas de negocio y el catálogo de servicios pero algunas cosas sí tenemos claras:

1. Estamos trabajando en un nuevo ecosistema software que hemos llamado “Clinker – Ecosistema Software”.
2. Seguiremos trabajando alrededor de los stacks tecnológicos Java, PHP y Python.
3. Ya lo hacíamos individualmente, pero ahora lo haremos como empresa. Apostar por el software libre.
4. Queremos trabajar en productos y ofrecer servicios alrededor de esos productos.
5. Nos gustaría ver alguno de nuestro productos fuera de España.

Seguimos en contacto.

Desde el próximo 1 enero de 2010, Opina pasa a ser un proyecto soportado y mantenido por la empresa “klicap – ingeniería del puzle“. Esto son sólo buenas noticias para el proyecto y el producto en sí. Desde klicap se garantizará:

1. Soporte de incidencias
2. Soporte de la lista de correo opina-users
3. Mantenimiento evolutivo de la rama 1.x
4. Continuidad de su licencia GNU/GPLv2
5. Construcción de la versión 2

Así es como se llamaba el taller que ayer se celebró en la Escuela Técnica Superior de Ingeniería Informática. El taller fue organizado por Joaquín Peña y estaba enmarcado dentro del Máster Ingeniería y Tecnología del Software (Universidad de Sevilla).

A continuación podéis encontrar las transparencias que utilicé en mi intervención “Ecosistemas Software”:

OpenPYME es una iniciativa que recoge una selección de aplicaciones de fuente abierta que conforman un catálogo orientado a las pymes. Detrás de esta iniciativa está la Oficina de Software Libre de la Universidad de la Laguna.

Cual ha sido mi sorpresa al ver a Opina: gestor de encuestas en dicha selección.

Para el plugin de Trac que estoy desarrollando (en los huecos que tengo) estoy desarrollando un pequeño cliente en python que me permita trabajar cómodamente con Alfresco REST API, especialmente con CMIS Web Reference. Uno de los métodos que necesitaba para este cliente es aquel que me permitiese comprobar si la configuración para trabajar con el API era correcta. Comprobar eso lleva implícito comprobar que Alfresco está disponible (se tiene acceso HTTP).

La configuración del plugin en relación a Alfresco es muy simple:

• Usuario y contraseña (credenciales)
• URL base en la que se publica RESTful API

Dejo por aquí el fragmento de código:

def is_alive(self):
    isAlive_service = self.__url_api + '/login' +  '?u=dummy&pw=dummy'
    self.__log.debug('Restful Service: ' + isAlive_service)
    try:
        response, content = self.__http.request(isAlive_service, 'GET')
        if response.status == httplib.FORBIDDEN:
            self.__log.debug('Alfresco RESTful API is alive')
            return True
        else:
            self.__log.debug('Alfresco RESTful API is not alive')
            return False
    except:
        self.__log.debug('Alfresco RESTful API is not alive')
        return False

Cualquier sugerencia será bienvenida.

Están siendo unos días muy interesantes para Opina, como producto y como proyecto software de fuente abierta. Desde hace algún tiempo en IDEPA están usando Opina. Parece que su aceptación ha sido positiva y han decidido empujar aun más su adopción. IDEPA es el acrónimo con el que se conoce el Instituto de Desarrollo Económico del Principado de Asturias. Es una entidad pública que depende directamente de la administración regional asturiana.

Este empuje antes mencionado se ha traducido en la contratación de mis servicios para el desarrollo de nuevas funcionalidades que serán incluidas en la próxima versión, 1.5.0. En esta nueva versión se incluirán ciertas mejoras que han detectado y que pueden ser de interés general. Desde IDEPA no han puesto ninguna restricción, todo lo contrario. Ellos han sido los primeros en defender la libertad del proyecto y no ser intrusivos con su propósito principal.

Creo que es una forma muy inteligente de rentabilizar el dinero público.

Así es como comienza una de las canciones del grupo de música El canto del loco. El nombre de la canción es El sueño de mi vida, del álbum Personas. Esta es otra de las coñas que forman parte de esa lista interminable que poco a poco hemos ido conformando. Hace unos instantes he entrado por la puerta de casa. Mi intención era descansar tras haber disfrutado de una estupenda tarde-noche. Pero ha sido imposible, he roto a llorar. No tenía pensado escribir nada sobre mi marcha de la empresa, pero lo que ahora mismo siento necesito que quede recogido en forma de entrada en este blog para recordarlo cuando veces necesite.

Han sido dos años y medio muy intensos, llenos de felicidad y momentos para no olvidar. Tiempo suficiente para cometer muchos errores, pero con la esperanza de que quede tiempo para mejorar y pedir perdón si fuera necesario. Los últimos meses han sido muy duros para mi. La situación ha afectado a todos los aspectos de mi vida pero quiero ser positivo y pensar que las decisiones que he tomado son acertadas.

Puedo asegurar que el trayecto “Centro de Sevilla” – “Mi casa”, en el coche de mi compañero Fran, ha sido el más triste de los que hasta la fecha había hecho. Siento que dejo atrás muchas cosas y que el simple hecho de pensar que no las volveré a tener, hace que mis ojos se llenen de lágrimas. Por momentos hubiera deseado ser una máquina que reacciona perfectamente ante todas las situaciones y tiene soluciones para todos los problemas, pero estoy más cerca de ser un ser humano impulsivo y racional que se mueve por principios y que es consciente de que echará muchísimo de menos a quienes han compartido tantos momentos con él.

Aunque tengo un especial recuerdo de todos, no puedo evitar caer nuevamente en otro error de mi vida y reservar lo mejor de mi para Sergio, Dimas, José y Antonio. A vosotros, GRACIAS por todo lo que me habéis demostrado TANTAS veces. Ojalá siempre estemos juntos.

En la versión 1.4.0 de Opina se ha incorporado la exportación de resultados en formato Microsoft Excel (compatible con OpenOffice). Para aquellos que trabajen con Google Docs aquí va la siguiente captura:

Quizás una integración interesante sea exportar los datos directamente a Google Docs aplicando plantillas que proporcionen gráficas por defecto.

Se acaba de publicar la versión 1.4.0 de Opina: gestor de encuestas. Los principales cambios en esta nueva versión son:

Incidencias

1. La barra de progreso no funcionaba correctamente
2. El asistente de encuestas no mostraba los datos indicados cuando se accedía a páginas de la encuesta que ya habían sido cumplimentadas

Mejoras

1. Exportación de datos en formado Microsoft Excel. Totalmente compatible con OpenOffice
2. Exportación de datos en formato UTF-8
3. Soporte parcial a múltiples idiomas de la interfaz gráfica. Lenguajes soportados: inglés y portugués
4. Nuevo sistema de autenticación para las encuestas basado en identificadores (tokens)
5. Histórico de versiones. Acceso restringido al administrador a través de la propia aplicación
6. Acceso (lectura) a la configuración de la aplicación. Acceso restringido al administrador a través de la propia aplicación

Este es el título del artículo escrito por Javier Rada en la revista Calle20 sobre la demoscene.

Amantes de la programación, la música y el diseño. La Demoscene es uno de los movimientos más underground y pujantes de la informática. Pequeñas piezas de arte en tiempo presente, competición y comunidad internacional son las señas de identidad de los sceners.

Y como no podía ser de otra forma, sale mi amigo David Domingo (alias SML), uno de los principales promotores de la demoscene en España.

Version Naming, Software Versioning o Sistemas de Versionado, es lo que se conoce como el proceso con el que identificamos de forma única el estado de los fuentes de un proyecto. Obviamente puede hacerse extensible no sólo al software, sino también a un documento de texto. Según los sistemas de gestión de la calidad debe incluirse un histórico de cambios.

¿Qué objetivos pretende cubrir un sistema de versionado?

1. Identificar de forma sencilla el estado de los fuentes. Esa identificación estará asociada a un instante de tiempo
2. Establecer una codificación que permita distinguir unas versiones de otras
3. Informar sobre qué contiene la versión

Existen muchas propuestas y cada una de ellas se adecua a unas necesidades. Nosotros hasta la fecha usábamos una muy conocida basada en:

• alpha
• beta
• Releases Candidate
• X.Y.Z

La versión alpha es una versión completa desde un punto de vista funcional. El equipo de proyecto debería ser capaz de justificar que los requisitos y expectativas detectadas se han alcanzado. Los que nos dedicamos a esto sabemos que es prácticamente imposible, especialmente en proyectos de más de 6 meses. La entrega oficial de una versión es un punto de inflexión en la relación entre el cliente y el proveedor. Está claro que el proveedor le está transmitiendo al cliente que para el proyecto se encuentra en su etapa final y que es el momento de ir cerrando los temas pendientes (artefactos documentales, sesiones de formación, etc).

La versión beta constituye otro momento importante en la vida del proyecto. Tras la entrega de la versión alpha se recoge comentarios, opiniones, peticiones de cambio, “…es que yo pensaba, yo creía que…” (por ambas partes), el departamento de sistemas añade sus “…esto lo quiero así, si hibernate te genera el DDL eso me da igual…“, y evidentemente si no quieres que el proyecto se te vaya en costes, negocias. Personalmente creo que es una -falsa- negociación porque como proveedor comienzas a ver el final y tu mayor deseo es implantar el proyecto y verlo como ayuda a los verdaderos usuarios finales.

Y luego vienen las versiones RCx, que junto con la versión beta, modelan las distintas iteracciones cliente-proveedor. Así, hasta llegar a la versión 1.0.0 donde se hace entrega oficial de los fuentes y corresponde con la versión que pasa a producción. A partir de ahí, comienza el soporte y mantenimiento que dará lugar a:

• 1.0.Z: Resolución de incidencias sobre la versión 1.0.0
• 1.Y.0: Si aumenta la Y, la Z se pone a cero e implica que se han incorporado mejoras y probablemente resolución de incidencias
• Z.0.0: Conlleva lo anterior pero además implica cambios importantes a múltiples niveles (diseño, funcionalidades, UI, etc..)

Esto es, de forma muy resumida, lo que venimos usando desde hace 2 años. Muy relacionado con otras prácticas de nuestra metodología nos hemos visto obligados a realizar una pequeña modificación e incorporar el concepto Partial Delivery:

1. No están reflejadas en el roadmap del proyecto, no constituyen ningún hito
2. Normalmente vienen originadas por una petición externa al equipo de proyecto
3. Están referenciadas en la herramienta de gestión de proyecto
4. Se podrían haber sustituido por conceptos como revisión propios de los S.C.M. pero resulta más sencillo trabajar con alpha-PD1 que con rev657.

Por aclarar algunos puntos:

1. En nuestro entorno de despliegue, y como parte de las actividades de integración continua, el estado de los fuentes es referenciado como 1.0.0-SNAPSHOT-r2203 o 1.0.0-DEV-r2203. Para la revisión usamos buildNumber.
2. Sólo versionados aquello que necesitamos referenciar.

En ciertos proyectos, por su diseño y base tecnológica, incorporamos otras prácticas. Por ejemplo, en aquellos con un alto índice de modularidad  cada módulo mantiene su propio versionado y las entregas incluyen un documento (o MasterBuild) en el que se detalla o define la entrega. Como ejemplo podemos ver aquellos que se basan en OpenCms o Drupal.

Y tú, ¿Cómo llevas a cabo este proceso?