Últimamente la agilidad se lleva a cualquier ámbito de la vida.
En esta presentación de Bruce Feiler se puede ver como funciona una «familia ágil» ; -)
¿Cómo repercute la latencia en mis aplicaciones?
Lo que dice Wikipedia de la latencia:
En redes informáticas de datos se denomina latencia a la suma de retardos temporales dentro de una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro de la red.
En la era de las aplicaciones para internet hay que tener muy encuenta como la latencia puede ser nuestro enemigo.
Hasta hace poco tiempo el problema de una aplicación era el ancho de banda, que consiste en la cantidad de datos que podían viajar por segundo ( 1 Mb/s , 10 Mb/s ). Con el tiempo, en general, las conexiones ya permiten transmisiones de gran cantidad de datos por segundo.
Por otro lado la latencia es el tiempo que tarda en ir un paquete de un punto a otro.
¿Por qué es la latencia importante para las aplicaciones?
En las aplicaciones donde existe una parte cliente y servidora, la comunicación entre estos dos elementos es constante, enviandose y recibiendo datos para las distintas acciones del usuario. Si durante el desarrollo de la aplicación no se ha tenido en consideración la posible latencia, el usuario podrá llegar a odiar la aplicación ya que tendrá que sufrir constantes esperas entre una y otra acción.
¿Cuál es la latencia en red local?
Normalmente es menor a 1 ms, 50 veces más rapido que una conexión nacional y 100 veces más rápido que una conexión intercontinental.
¿Cómo podemos reducir la latencia entre el servidor y el cliente?
Esto está en manos de las redes de comunicaciones, y parece un problema complejo, porque nos encontramos con limites físicos ( Velocidad de la luz y esas cosas 😉 )
Siempre te queda la opción de poner el servidor más cerca de los usuarios.
¿Cómo puedo reducir los efectos de la latencia?
Existen muchas técnicas, pero basicamente debemos de buscar que los efectos de la latencia no afecten a las acciones del usuario.
- Evitar las multiples llamadas consecutivas al servidor.
- Utiliza procesos en segundo plano.
- Utiliza procesos en el servidor.
- Programa en un entorno hostil para detectar en desarrollo los pequeños detalles que hacen una gran aplicación.
Te recomiendo el post de Jarboleya sobre consejos para programar aplicaciones en la nube
No es un sprint es una maratón
En 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
¿El cliente prefiere que desarrolles con calidad o rapidez?
Generalmente son dos parámetros que se contradicen, si hago un producto más rápidamente lo hago con menos calidad y si lo hago con calidad requiere mayor tiempo de desarrollo.
Existe el factor coste, invierto más dinero y lo consigo con más calidad y menos tiempo. Pero en el mundo real con más dinero tendrás más gente, más gente es más tiempo, más gestión y posiblemente menos calidad.
Si le preguntamos al cliente te dira que lo quiere rápido, pero asume que tiene calidad, si no funciona bien, ¿para que le vale?
Una posible solución a este dilema es menos.
- Si entregas algo con menos funcionalidades, lo podrás hacer en menos tiempo y con más calidad
- Si tienes menos funcionalidades las podrás probar mejor
- Si tienes menos funcionalidades tendrás menos errores
- Si tienes menos funcionalidades tendrás menos código que mantener
Pero aunque la idea parece fácil, es extremadamente complicado saber cuales son las mínimas funcionalidades que conseguirán satisfacer las necesidades de tu cliente.
Menos, es más cálidad y más rapidez!
La calidad del software es responsabilidad de toda la empresa
Normalmente pensamos que la calidad de un software es responsabilidad exclusiva del departamento de desarrollo, ellos son los responsables de programar y de hacer un producto de calidad.
Pero en realidad el resto de departamentos son complices de la calidad del producto:
- Si el departamento de soporte presiona para cambios rápidos y sin probar, no esta ayudando a la calidad.
- Si la dirección estratégica de la empresa va en el camino de más y más funcionalidades, no esta ayudando a la calidad.
- Si los comerciales piden incorporar en tiempo record las nuevas funcionalidades que tiene la competencia, no esta ayudando a la calidad.
- Si el departamento de diseño exige que se incorporen imagen y videos super atractivos sin importar los recursos, no esta ayudando a la calidad.
¿Quien lucha por dedicar tiempo a la calidad de las apps?
Todo el equipo tiene que ser consciente que existen muchos trabajos relacionados con la programación que nos ayudan a tener un producto de calidad.
- Mejorar la usabilidad
- Refactorizar código
- Quitar código obsoleto
- Actualizar librerías
- Mejorar la velocidad de los procesos
- Realizar pruebas de carga
- Automatizar procesos de prueba
Estos trabajos consumen mucho tiempo y toda la empresa debe darse cuenta que son necesarios para que el producto mejore día a día.
La calidad de un producto debería nacer desde la estrategia de la empresa e ir descendiendo por los departamentos hasta su aplicación directa en los departamentos más técnicos. No es un trabajo aislado de unos locos de la programación.
Cuanto peor equipamiento tenga el desarrollador mejor rendimiento tendrá la aplicación
Según el test de Joel para el desarrollo de software, el desarrollador debe tener las mejores herramientas que se puedan pagar.
La experiencia me dice que en algunos casos esta regla es contraproducente para la calidad del producto resultante.
Mientras se desarrolla, la velocidad de ejecución de los procesos se miden en el tiempo que siente el desarrollador.
- Si en la máquina del desarrollador va bien, el código esta bien.
- Si en la máquina del desarrollador va lento, él mismo, se preocupará de hacer que vaya bien.
Muchas de las incidencias que conozco relacionadas con el rendimiento de las aplicaciones son derivadas de que las conexiones y rendimientos de las máquinas donde se programa son superiores a donde se ejecuta en producción.
Lo ideal es que el desarrollador ejecute sus pruebas con la peor máquina donde pueda correr en producción, de esta manera nos aseguraremos que en ejecución siempre funcionará muy rápido.
Esto es aplicable a procesador, tamaño de pantalla, memoria, velocidad de conexión al servidor, etc.
Un caso que conozco en Velneo que demuestra esta teoría, son las optimizaciones del protocolo VATP. Cuando se estaba desarrollando por parte de Juan Muñoz-Cobos y su equipo, se contaba con de una infraestructura de comunicación penosa, una latencia de 1 segundo. El resultado es un protocolo de comunicaciones muy optimizado y preparado para las peores circunstancias.
Cuando el desarrollador trabaja con un muy buen equipamiento suele ser más habitual escuchar «No se porque va lento, en mi equipo va bien» 😉
Life is soft 2012
Los pasados días 15 y 16 de Noviembre se realizó en Madrid el evento anual de software empresarial organizado por Velneo
Las sensaciones han sido geniales y he podido saludar a viejos amigos de la comunidad Velneo, compartir unos minutos y charlar de los proyectos en los que están involucrados.
Después de las 26 charlas ( Si! 26 charlas de 22 ponentes distintos ) me quedo con muchas cosas interesantes que espero ir desgranando y disfrutando durante los próximos meses.
Se ha hablado de Velneo, pero sobre todo de como hacer software empresarial sostenible, ganar dinero y disfrutar en el camino.
El viernes al llegar a casa me di cuenta que la palabra «crisis» no se nombro en todo el evento y no la escuche por ninguna de las personas de la comunidad. Todo el mundo esta motivado para empujar en estos tiempos que nos han tocado vivir.
Las ponencias no solo se han centrado en «programar», sino en todo lo necesario para que una empresa de software tenga éxito!
Dinero, diseño, rentabilidad, neuromarketing, reutilizar, comunicación, conectividad, agilidad, movilidad, interfaz, etc.
Enlaces interesantes para recordar el #lis2012
- Life is soft 2012. Jueves 15 (I parte) Resumen desde la web de Velneo
- Fotos del evento de cdominguez en Flickr
- Post sobre el evento de @maltranaen ticmedia.es
- http://tipesoft.com/por-la-manana-lis2012/
- http://tipesoft.com/por-la-tarde-lis2012/
Autohotkey, como herramienta de automatización de procesos
Hace años que empezamos a usar Autohotkey como herramienta para automatizar algunos procesos en aplicaciones.
Consiste en un ejecutable que lee un script donde se definen las tareas a realizar, cosas del tipo :
- Abre este programa tal.
- Dale a la tecla Alt+A
- Escribe el texto «hola»
- Dale al botón Guardar
- Cierra la aplicación
Parece una aplicación sencilla para cosas triviales, pero realmente sorprende la fiabilidad y las posibilidades que ofrece para la automatización de procesos.
Actualmente la usamos para distintas tareas:
- Pruebas de interfaz en la integración continua, para verificar las funcionalidades de interfaz de las aplicaciones
- Recopilación de información de Mapas de Velneo 6.x
- Tareas automáticas de integración
La herramienta tiene buena documentación y mucha información en internet y puedes hacer casi cualquier cosa que se te pase por la cabeza.
Junto a Jenkins se pueden hacer verdaderas viguerías en la integración continua, tanto para realizar automatizaciones como para realizar verificaciones.
Tiene un hermano ( autoit ), con el que comparten mucho código, no se cual de los dos es mejor, pero en nuestro caso autohotkey cubre nuestras necesidades.
La nube aporta mejoras en el desarrollo de software
Durante los últimos meses la nube entra por todos lados, cada rincón de la empresa de software es susceptible de viajar a la nube.
Hay muchos ámbitos donde puede aportarnos soluciones mejores y más económicas.
Pruebas
Una de las áreas donde el Cloud esta ayudando es el área de pruebas, ya que permite arrancar una máquina limpia de manera rápida, ejecutar las pruebas y eliminarla.
Todo el trabajo de instalación de sistemas operativos desaparece. El coste de una hora de una máquina incluyendo licencias de sistema operativo suele ser inferior al euro. Hacer eso en local lleva mucho más tiempo y dinero.
Esclavos en la nube
Si usas integración continua con Jenkins, es muy cómodo tener los esclavos en la nube. Estas máquinas son las encargadas de realizar la compilaciones, verificaciones, pruebas funcionales, etc. En nuestro caso usamos múltiples esclavos para los diferentes sistemas operativos y sus diferentes sabores.
El ahorro más importante viene en que podemos arrancar las máquinas esclavas a demanda, ahorrándonos el coste de tenerlas siempre encendidas. También es muy sencillo cambiar los recursos de las maquinas en función de las necesidades.
Más madera
Otro de los puntos fuertes son las pruebas de carga, estos proveedores te permiten contratar monstruos de la computación. Se pueden montar pruebas de carga con varios equipos de 64 núcleos con cientos de Gigas de RAM. Es posible probar el rendimiento en grandes infraestructuras por unos pocos euros.
Seguridad
En cuanto a la seguridad de las máquinas, es eficaz mantener una política dura en la configuración del firewall del proveedor de Cloud, con lo que no tendremos problema en la configuración o reconfiguración individual de cada máquina virtual.
Como alternativas tenemos experiencia en Amazon Ec2 y Arsys Cloud builder, pero existen decenas de proveedores que pueden ofrecer un buen API para la gestión de las máquinas.
Fechas fijas en tus iteraciones
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.
davidgu 