Categoría: Evolucionar

El idioma de las aplicaciones

~ davidgu ~ 5 comentarios

Nuestra necesidad

Durante los últimos meses estamos implantando internamente nuevas aplicaciones desarrolladas en Velneo. Por otro lado necesitamos conectarlas con otras aplicaciones de terceros que usamos en diferentes departamentos ( Google Apps, WordPress, Twitter, Zendesk, etc ).

Esta situación nos obligaba a marcar una estrategia de futuro en la comunicación entre aplicaciones.

Debíamos buscar una forma de comunicar cualquier aplicación entre sí, da igual si está en web, en escritorio o en móvil. Buscábamos un solo idioma para que se comuniquen nuestras aplicaciones.

Idioma elegido

Después de evaluar las opciones existentes todas nos llevan hacia las siglas REST / JSON

Al ser un servicio tipo REST  tenemos la garantía de que funcionaremos sobre HTTP/HTTPS con todas las ventajas que ello conlleva.

Nos decantamos por JSON respecto a XML por varios motivos :

  • Es muy sencillo y ligero
  • Fácilmente legible por máquinas y humanos 😉
  • Parece el estándar del futuro para comunicación de aplicaciones (WordPress, Google Glass, Zendesk, Twitter )

Como creamos nuestro API

API-VERPLo primero que debíamos hacer era crear un API que permitiera que otras aplicaciones consumieran nuestras aplicaciones, para ello con el vJavascript de Velneo creamos una aplicación capaz de generar de forma dinámica todo el API en base a un proyecto de Velneo. Esta aplicación no solo nos genera los puntos de acceso, sino una web dinámica con toda la documentación del API

Para darle salida a la aplicación usamos el componente vModApache y configuramos el Apache para añadirle cache, compresión y encriptación.

Con este proyecto, cualquiera de nuestras aplicaciones de Velneo V7 tenían un API dinámico en base a las tablas y búsquedas ya creadas.

Como consumimos nuestro API

Necesitábamos obtener información de nuestras aplicaciones, en unos casos que Google Apps pudiera obtener diferente información de nuestro vERP, para ello desarrollamos scripts en Google Apps Script que acceden a nuestro API  y le consultan la información que necesita. El resultado devuelto en JSON se procesa de una forma muy sencilla y se realizan las operaciones necesarias.

Por otro lado nuestra web necesitaba mostrar información privada en los sitios que funcionan con WordPress. Desarrollamos un plugin en PHP que se conectaba a nuestro API para obtener información y mostrarla al visitante.

Desde los centros de soporte en Zendesk se consulta nuestro API para mostrar información de nuestro vERP en tiempo real

Desde Google Script se generan emails con los indicadores clave de la empresa calculados en diferentes aplicaciones

Que más cosas

Existen cientos de servicios web que ofrecen funcionalidades mediante sus APIs REST JSON

Nuestra idea es comunicar toda esta «nube» de aplicaciones con un mismo idioma, lo que nos permite ser más ágiles en cuanto a la implementación y mantenimiento de nuevos servicios.

No es un sprint es una maratón

~ davidgu ~ Deja un comentario

ZapatillaEn el desarrollo ágil de software, se habla de sprint al periodo de tiempo de una iteración, es la parte repetible y que debe ir mejorando poco a poco.
Pero cuando hablamos de un desarrollo de software podemos buscarle también una perspectiva mayor y hablar que esos sprints están dentro de una gran maratón.

  • Hay que dosificar las fuerzas, el desarrollo dura mucho tiempo.
  • Contar con el dinero o los recursos para llegar a meta ( o como repostar recursos en el camino )
  • Pensar bien a que grupo te unes para equiparar fuerzas.
  • El muro de los 30 km
  • Una estrategia de carrera clara pero flexible a las circunstancias.
  • Saber cuando has llegado a meta y no correr a lo Forest Gump.

¿Corres maratones o solo haces sprints?

Una vez quieras vender tu producto tendrás que correr otro maratón

Fechas fijas en tus iteraciones

~ davidgu ~ 2 comentarios

Las fecha de fin de iteración suele coincidir con la liberación del producto y sus entregables. Es una fecha en la que deben confluir el trabajo y resultados de mucha gente.

Si esta fecha no es fija tenderá a retrasarse, es una ley del universo.

Siempre existe algún motivo:

  • «No he probado esto, necesito dos días más»
  • «Con un par de días puedo añadir esta novedad»
  • «No me dio tiempo a acabar esa tarea, dame dos días más»
  • «Déjame un día más, puede salir tal funcionalidad sin probar»
  • «Necesito un día más para hacer un vídeo de las novedades»

Con una fecha fija e inamovible conseguirás:

  • Dejar menos cosas para última hora.
  • Todas los stakeholders tendrán información fiable de la liberación.
  • Perderás menos tiempo y conflictos en decidir si retrasar o no retrasar.
  • Por mucho que cambies la fecha, nunca tendrás una versión perfecta.
  • Generalmente las cosas importantes se hacen primero, nadie quiere quedarse pillado a última hora.
  • Unos días antes debe estar todo listo, lo que no este, saldrá en la siguiente iteración. No debe haber agobios de última hora por cosas planificadas.
  • Nadie se quedará sin vacaciones o sin fin de semana por un retraso.
  • Con el tiempo y experiencia los últimos días antes de la salida serán los más tranquilos.
  • Retrasar la fecha de esta iteración es el primer paso para destrozar la organización de la siguiente.
  • Cuanto antes puedas marcar las fechas de las siguientes iteraciones será más sencillo planificar cuando se solucionaran las incidencias pendientes.

En la teoría marcar una fecha y cumplirla es fácil, en la práctica todos los integrantes del equipo tienen que estar involucrados en que la fecha es inamovible.

La excelencia en este aspecto es tener la fecha fija, pero saber que ante una fuerza mayor podrás cambiarla.

Evalúa tu iteración

~ davidgu ~ Deja un comentario

Evalúa tus cartas antes de la siguiente iteración - http://www.lafotodeayer.com/Una de las claves del éxito de las iteraciones en los equipos de desarrollo es que la organización y las personas aprenden a realizar las cosas de una forma mejor y más eficiente.

Sin una evaluación posterior de cada iteración, el aprendizaje desaparece y el ciclo iterativo pierde su sentido.

Lo más adecuado es evaluarte, decir en voz alta y clara que te ha gustado de tu trabajo y lo que se puede mejorar.

La evaluación no pretende castigar

La evaluación no es un examen para castigarnos, se trata de ser un poco mejores. El equipo tiene que ir sintiendo que en cada iteración se hacen las cosas mejor, con más calidad y en menos tiempo.

Evalúame!

Se puede evaluar cualquier cosa

  • La asignación de tiempos
  • La propia metodología
  • Las reuniones
  • Los desarrollos
  • Las herramientas
  • Los entregables

Se trata de revisar las cosas «repetibles», para hacerlas un poquito mejor en cada paso.

Miedo a reconocer los errores

Lo primero que tenemos que quitarnos de la cabeza es el miedo a reconocer los errores y que nuestros compañeros nos examinen. Si no reconocemos las cosas mejorables será difícil conseguir nuevos logros.

Una evolución no una revolución

Del mismo modo que evaluamos muchos elementos, en la siguiente iteración debemos centrarnos en  solucionar los más importantes o los que más nos han perjudicado. No esperes que tu siguiente iteración solucione todos tus problemas.

Los cambios masivos pueden causar una revolución y pueden provocar daños colaterales en tu equipo.

Las iteraciones infinitas

Siempre tendrás cosas que evaluar o mejorar, quizá tu equipo ya funciona bien, pero el entorno ha cambiado y realizando las cosas de otra manera podrás tener un mejor resultado.

Si no ves mejoras en tus procesos, es hora de que cambies de trabajo y busques algo que te estimule más 😉

En casa de herrero, comida de perro

~ davidgu ~ 2 comentarios

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» 😉

Los desarrolladores hablan klingon y los de soporte hablan esperanto

~ davidgu ~ 3 comentarios

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

~ davidgu ~ Deja un comentario

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.

Revisión por pares

~ davidgu ~ 2 comentarios

Como bien comenta jgarzas, en su post Beneficios del pair programming, que dos desarrolladores compartan el editor y hagan el desarrollo de forma conjunta puede aportar un plus de calidad a nuestro proyecto.

Del mismo modo, la puesta en marcha es complicada, por la sensación de pérdida de productividad.

Hace tiempo pusimos en práctica la revisión por pares, consiste en definir unos pares de desarrolladores donde cada uno verá el trabajo realizado por su compañero el día anterior.

Un script nocturno en la herramienta de integración continua captura del control de cambios el resumen de las modificaciones realizadas el día anterior por su compañero. Con la información se compone un email y se envía a cada par correspondiente.

El desarrollador lo primero que hace en el día es ver y entender lo que ha realizado su compañero, ante cualquier duda respecto al código, al formato o los comentarios, el desarrollador le consulta a su par e inician un diálogo para aclarar dudas.

Con la revisión por pares conseguimos una serie de beneficios:

  • Aprendizaje de trucos y el buen hacer de los compañeros
  • Amplio conocimiento de todo el proyecto
  • Solución a problemas de estilo de código
  • Solución a problemas de código detectado por un compañero
  • Unificación de criterios en la forma de desarrollar

No es tan eficaz como la programación por pares, pero ayuda al trabajo en equipo.

Es llevar a la práctica la ley de Linus en un equipo de desarrollo de una forma que no invertimos mucho tiempo en la revisión.

Lo que el cliente no pide, pero exige

~ davidgu ~ Deja un comentario

En desarrollo de software es habitual que los usuarios pidan más y más funcionalidades, si fuera por ellos una aplicación crecería en «sus» funcionalidades hasta el infinito.

Pero por otro lado el cliente asume que la aplicación será rápida, estable y segura, pero eso no se suele pedir, se asume que es así.

Muchos de los trabajos relacionados con la calidad de tu software, son trabajos ocultos para el usuario, pero que son igual o más importantes que añadir más funcionalidad.

Es labor de todo el equipo dedicarle tiempo a la calidad del producto, ya que llegado un momento nuestra deuda técnica es tan grande que empezamos a sufrir distintos problemas relacionados con la falta de calidad.

Todos estos trabajos relacionados con añadir más calidad a nuestro producto deben ir incluidos en cada una de nuestras iteraciones, no debe ser un trabajo puntual cuando las cosas vayan mal.