En casa de herrero, comida de perro

Hasta unas semanas internamente solíamos decir «en casa de herrero, cuchillo de palo«, cuando nos referiamos al hecho de que seguíamos usando algunas aplicaciones internas desarrolladas con Velneo 6.x.

Estas aplicaciones con más de 10 años de vida y con una exitosa trayectoria necesitaban una renovación para beneficiarse de las últimas tecnologías.

Gracias al impulso de mi compañero Domi, durante estas últimas semanas se ha dado un importante paso a la sustitución por aplicaciones desarrolladas con Velneo V7.

Llevábamos años usando aplicaciones desarrolladas con Velneo V7 en combinación con algunas antiguas con éxito, pero ya llegaba la hora de que comiéramos nuestra propia comida de perro de una forma general.

Nuestra filosofia es una combinación de Open Apps con adaptaciones con herencia.

Algunas de las Open Apps que estamos usando son :

El cambio no solo sirve para renovar las aplicaciones, sino que nos estamos mudando a la nube con todas las aplicaciones del grupo. Usamos un servidor en el Cloud de Velneo con lo que nos hemos liquidado todos los gastos de servidor, licencias, copias de seguridad, sais, AC, etc.

Normalmente tenemos una media de 75 enganches a 15 instancias distintas. Y hemos conseguido la felicidad de los maqueros y los linuxeros de la empresa que trabajan con las aplicaciones corporativas directamente desde su sistema operativo preferido.

Nuestro objetivo con este cambio no puede ser otro que «Evolucionar en tecnologías para innovar en software» 😉

Nos pasamos el 50% del tiempo escribiendo en el teclado

Cuando veo alguna persona escribiendo en el teclado con «dos» dedos en su puesto de trabajo solo se me ocurre pensar la cantidad de tiempo que estará perdiendo.

En nuestra sociedad los teclados han pasado a ser algo crítico, escribir con soltura en el teclado no se está convirtiendo en una ventaja, sino en una necesidad.

Ventajas:

  • Aprender a escribir en el teclado ahorra muchas horas al día, si pueden utilizar los diez dígitos. Esto les permite escribir mientras piensan y vaciar sus ideas directamente al ordenador, si  es posible escribir rápido, pueden pensar más rápido.
  • Aprender a utilizar las aplicaciones en menos del 40% del tiempo requerido, lo cual les proporciona la oportunidad de aprovechar al máximo los recursos.
  • Mejorar las perspectivas laborales, incluso si el trabajo no es formal, la paga será mejor si se tiene esta habilidad de por vida. Los gerentes de negocios de hoy reconocen que el escribir con sólo dos dedos, no es un método aceptable en esta era de la información – deben de ser usuarios expertos de la computadora y saber escribir utilizando todos los dedos en forma efectiva.
  • Utilizar todas las herramientas de un procesador de palabras.
  • Un estudio reciente realizado a familias con PC mostró que el 77% de los padres dijeron que era de vital importancia para sus hijos.
  • Puedes escribir largos documentos sin tener que romperte el cuello mirando si está bien lo que escribiste.

Si sigues teniendo dudas de la necesidad de escribir con los 10 dedos, puedes leer este post

Comprueba aquí tu velocidad http://www.typingstudy.com/es/speedtest

Control de cambios para Velneo 6.x con Perforce

Perforce como herramienta de control de cambiosCuando se trabaja en equipo es muy cómodo tener un lugar centralizado donde almacenar y gestionar las distintas modificaciones en tus desarrollos.

Los SCM o herramientas de control de cambios permiten centralizar y gestionar los cambios de un proyecto software.

Existen muchas herramientas para gestionar el control de cambios ( Git, Subversión, etc ). Nosotros llevamos usando Perforce durante años.

Ventajas que más nos gustan de Perforce:

  • Solución muy visual (P4V) que permite iniciarse rápidamente en la gestión de cambios
  • Multiplataforma
  • Servidor muy robusto
  • Fácilmente integrable con Jenkins
  • Configuración Cliente/Servidor por TCP
  • Muy útil para gestión de cambios en mapas de velneo 6.x, documentos, imágenes o cualquier tipo de archivo

Actualmente para pequeños equipos de desarrollo existe una versión gratuita para 20 usuarios / 20 workspaces, lo que permite disfrutar de la herramienta con todas sus funcionalidades.

Es importante crear una correcta estructura de tu repositorio (Branches (ramas) y Trunk (tronco) ) que te permitan controlar todas las versiones y parches para ayudar a tener un buen ciclo de desarrollo

Video de explicación de Perforce

Ventajas del doble monitor

Trabajar con dos pantallas / monitores aporta muchas mejoras en el trabajoEn la empresa buscamos las mejoras herramientas para favorecer la máxima productividad y uno de los elementos que mayor impacto ha tenido ha sido la implantación del doble monitor.

Durante los últimos años se han ido implantando en diferentes departamentos y cada tipo de perfil le ha sacado beneficios en los distintos trabajos que realiza.

Por otro lado, las personas necesitan un proceso de adaptación al pasar de uno a dos monitores, al igual que si usaramos un solo brazo durante toda la vida, el día que nos implantan otro brazo, resulta difícil adaptarnos a la nueva situación y tardaríamos un tiempo en sacar todo el potencial.

Muchas de las tareas que se realizan a lo largo de la jornada pueden mejorarse con doble monitor:

  • Programar y depurar aplicaciones.
  • Escribir artículos mientras te documentas.
  • Realizas pruebas mientras introduces la incidencia.
  • Das soporte al cliente desde una pantalla mientras documentas la consulta.
  • Desarrollas tus tareas mientras chateas con tus compañeros para resolver dudas.

El coste actual de los monitores es reducido, además, la clave es que sean dos, no necesitan ser de gran formato o gran calidad.

Solemos poner pantallas de distinto tamaño, estéticamente no queda súper-cool, pero ayuda al desarrollador a probar el interfaz con distintos tamaños cómodamente.

Hay muchos estudios oficiales que indican que los dos monitores mejoran la productividad, en nuestro caso la experiencia nos ha confirmado que ha sido una buena decisión.

Enlaces:
http://research.microsoft.com/apps/mobile/News.aspx?post=/en-us/news/features/vibe.aspx
http://research.microsoft.com/apps/mobile/Publication.aspx?id=69718
http://www.codinghorror.com/blog/2008/03/does-more-than-one-monitor-improve-productivity.html

Los desarrolladores hablan klingon y los de soporte hablan esperanto

Los equipos de desarrollo y soporte suelen ser habituales en cualquier empresa de desarrollo de software. Y también es habitual que estos dos equipos tengan mucha colaboración y puntos de conflicto.

Realmente todos en la empresa suelen tener el mismo objetivo, satisfacción del cliente y un buen producto, el problema viene que cada departamento habla idiomas distintos, sin un idioma común es difícil comunicarse 😉

Los desarrolladores

Los desarrolladores viven en su planeta Kronos ( Departamento de desarrollo ), buscan el silencio, el reposo y la tranquilidad. Entre dos desarrolladores la comunicación es fluida y cordial, generalmente todo se puede explicar perfectamente en su idioma. Se sienten creadores del universo conocido y dicha creación se ha hecho en el idioma Klingon.

El equipo de soporte

El esforzado equipo de soporte vive en un planeta regido por el caos, las llamadas, los emails y las consultas de los clientes entran sin ningún criterio lógico. Los integrantes del equipo han tenido que  inventar un idioma universal para poder entender toda esta actividad. Entre ellos tienen su propia jerga comprendiéndose perfectamente, con un par de palabras saben referirse a cualquier situación. El idioma creado por el equipo de soporte es el Esperanto.

Cada equipo por separado trabaja en sintonia, el problema viene cuando la persona de soporte le comenta lo que esta sucediendo a un desarrollador. Uno le da la versión en esperanto de lo que le ha comentado el cliente y el otro espera una explicación en klingon. Lo que entiende cada uno de la misma situación puede ser algo como esto:

  • Consulta
    Usuario (Idioma sin especificar): Le doy al botón y no funciona
    Soporte (Esperanto) : Pulsa el botón de facturar desde el menu principal sin exito
    Desarrollador (Klingon) : Le manda un señal de click al widget
  • Respuesta
    Desarrollador (Klingon) : El IsEnabled del widget esta condicionado
    Soporte (Esperanto) : Solo se puede pulsar el botón si la factura tiene importe
    Usuario (Idioma sin especificar) : Solo funciona si le pongo algo

¿Como mejorar la comunicación de los dos equipos?
Es importante que alguna persona de soporte haya vivido en kronos y conozca algo de klingon. Por otro lado los programadores deben salir de vez en cuando de su planeta y ver que se hablan muchas lenguas a lo largo y ancho de la galaxia conocida 😉

El coste de un bug

bicho-bugCuando se desarrolla software se comenten errores (bugs), esto forma parte del trabajo. Cada uno de estos errores tiene un coste, normalmente cuando más tarde se detecta, más caro nos cuesta solucionarlo.

Estos son algunos de los momentos en los que la empresa puede detectar y solucionar estos errores :

  1. En el propio desarrollador
    Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Estos programadores cobran más, pero su código es más fiable.
  2. En la integración continua
    Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )
    Dentro de la integración continua es muy útil tener automatizadas todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.
    Coste*: 1 hora del desarrollador ver el log y arreglar el problema 
  3. En el equipo de desarrollo
    Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.
    Coste*: 2 h. del desarrollador que encuentra el problema y de quien lo soluciona 
  4. En el departamento de pruebas
    Si el error llega hasta el departamento de pruebas, este equipo tiene que ocuparse de detectarlo y entender como ocurre y como hacerlo reproducible. Otro elemento importante es describirlo al desarrollador que suele ser un punto de conflicto,  la comunicación debe ser muy eficaz para que el desarrollador pueda entenderlo y solucionarlo.
    Coste*:  1h. para encontrarlo y documentarlo + 1 h. en entenderlo + 1 h. para solucionarlo 
  5. Los betatesters
    Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester que si lo encuentra, deberá comunicarlo al departamento de pruebas, la solución a este bug debe pasar por varios departamentos e incurre en trabajo de mucha gente.
    Por otro lado, la solución al error, puede romper otro elemento, con lo que esa versión debe pasar de nuevo todas las fases previas.
    Coste*: 1h. del betatester + 1 h. para encontrarlo y documentarlo + 1 hora en entenderlo + 1 hora en solucionarlo 
  6. El usuario final
    Si el bug llega al usuario se sentirá frustrado porque la nueva versión no hace lo que debe. Del mismo modo quizá no informe correctamente al equipo. Si lo hace, debemos tener un canal por el equipo de soporte para ello. Este tipo de bugs generan mucho trabajo y mala imagen, incluso en ocasiones pueden generar un parche, con el enorme coste que esto provoca.
    Coste*: 1 h. del cliente final + 1 h. persona de soporte + 1 hora persona de pruebas + 1 h. para entenderlo + 1 h. solucionarlo 

Sacar un parche para muchos clientes no tiene precio 😉

*Coste: Es un tiempo medio, cada error es un mundo, unos se solucionan en minutos y otros en días.

¿Donde documentar mi proyecto de software?

Formas de documentarA lo largo de los años hemos intentado tener una documentación en cada proyecto que pueda servir a cualquier miembro del equipo en el momento que lo necesite.

Respecto a la cantidad de documentación, cada proyecto es un mundo pero en general siempre tenemos bastante información que tiene una relación directa con el proyecto.

Hemos probado técnicas, ubicaciones, wikis, documentos y otros sistemas, cada uno con distinto éxito.

A lo largo de los diferentes proyectos hemos comprobado  que cuanto más cerca estaba la documentación del código más ventajas teníamos y la información era más valiosa.

Entendemos por cerca, que la documentación este dentro de los mismos ficheros de código, en los mismos directorios o en el mismo repositorio de código.

Estas son algunas de las ventajas que existe cuando la documentación del proyecto esta cerca de los recursos :

-Más fácil tenerla actualizada

Al estar cerca del código es más sencillo actualizarla cuando realizamos un cambio.

-Más fácil tenerla localizada

No hay que preguntar a nadie donde esta el esquema de conexión el gŕafico de recursos o como acceder al wiki para ver tal objeto. Todo el equipo sabe donde está y donde debe estar.

-Organizada en base al proyecto

Los proyectos suelen tener una organización en base a módulos, componentes, áreas, etc. La documentación puede estar organizada de la misma manera, con lo que si te sabes mover por el código sabes moverte por la documentación

-La documentación y el código se apoyan, es bueno verlo con relación

Cuando tienes dudas en el código del proyecto necesitas ver la documentación que pueda estar relacionada. Cuando quieres ver como se aplica algo de la documentación, es bueno tener el código cerca.

-Si viaja el código que viaje la documentación

En ocasiones necesitas llevarte el código a una máquina sin conexión o cambiar de máquina. Si el código va junto a la documentación no tendrás que hacer dos pasos.

-Si tengo acceso al código tengo acceso a la documentación.

Si tienes unos privilegios de acceso al código, normalmente van parejos para el acceso a la documentación

Uno de los ejemplos prácticos de llevar la documentación cerca del código es la documentación de Qt, donde los ex-nokia y ex-trolltech documentaban en el código, su inmensa librería esta perfectamente documentada y actualizada.

Si tu documentación esta dentro del código existen herramientas que te ayudan a extraer esa documentación y compactarla de una forma muy accesible. Doxygen o JavaDoc son claros ejemplos.

En otros casos los IDEs de las plataformas te permiten crear directamente la documentación, en el caso de Velneo puedes crear esquemas directamente desde el vDevelop.