Autor: Iñigo Serrano

Publicado el

Reducir gastos en movilidad con audioconferencias

Estamos en una época en la que el método Lean, directa o indirectamente, está a la orden del día, ya que hay que reducir gastos superfluos y centrarse en generar valor.

Hay una cosa que desde hace mucho tiempo me parece, en general, una pérdida de tiempo. Son las típicas reuniones en el cliente, en las que dedicas más tiempo en ir y volver que en la propia reunión, sobre todo para reuniones rutinarias. No me refiero a las reuniones en las que el cliente te quiere tener delante para metafóricamente partirte la cara.

Además el hecho de no dedicar tiempo a viajes te facilita que puedas incorporar a más personas a la reunión, personas que de otra manera no hubiesen asistido, porque significa duplicar el costo en horas improductivas.

En una empresa en la que trabajé pedí que comprasen un manos libres en condiciones, no el típico teléfono con función de manos libres, en el que tienes que estar acercándote al aparato para que te escuchen y que tu no escuchas a los otros del todo bien.

La verdad es que el aparato se escuchaba estupendamente y los otros también nos escuchaban muy bien. Era una comodidad y por un precio que para una empresa no es descabellado. En una docena de viajes que te ahorres ya lo has amortizado. En concreto era un Polycom SoundStation 2

Además para los clientes que venían a la oficina daba una cierta imagen de disposición de medios. Y esto también es importante.

Desde entonces a todos los sitios que voy a trabajar recomiendo el tener un buen manos libres.

Publicado el

Hasta los diez mandamientos estaban por escrito

Estaba leyendo el libro Negociar es fácil si sabe como, cuando me he encontrado con una reflexión que me ha parecido muy acertada, sobre todo para la gente que es reacia a dejar las cosas por escrito, como normativas, guías, etc.

«Moises no descendió del monte Sinaí con las manos en los bolsillo a contarnos los diez mandamientos. Los llevó escritos en las tablas sagradas.»

Esto me parece importante, sobre todo cuando te dedicas a temas como la industrialización del desarrollo del software o a la arquitectura de aplicaciones web. Ambas son cosas importantes porque fijan los criterios de todo un proyecto o toda una empresa. Estas cosas deben quedar por escrito en un lugar accesible, sino como dice la sabiduría popular, las palabras se las lleva el viento. De esta parte de la accesibilidad ya he hablado en la entrada sobre gestión del conocimiento.

Imagen obtenida de la Wikipedia
Publicado el

Industrialización del Software: Manual del paracaidista II

Una vez que tienes razonablemente controlado que la aplicación hace lo que tiene que hacer el siguiente paso es un poco más complicado.

La aplicación que tienes que reconducir cuando tiene que grabar lo hace correctamente, pero y cuando tienen que grabar 100 a la vez, ¿aguanta la carga funcionando bien?

Este debiera de ser el segundo punto en tu lista de objetivos. Pero es un punto delicado. Automatizar todo tu plan de pruebas para ver que la aplicación soporta la carga y que bajo esa carga funciona correctamente, puede consumirte mucho tiempo. Además probablemente te requiera de infraestructura para ejecutar esas pruebas.

Debieras de valorar si te merece la pena o por el contrario te conviene el dedicarte a arreglar otras áreas en las que puedas obtener una mejora más rápidamente.

En esta fase, puedes recurrir a herramientas como JMeter, JUnit o Selenium.

Publicado el

Industrialización del Software: Manual del paracaidista

Y en estas que de repente eres afortunado al caer cual paracaidista en un proyecto que va como el rosario de la aurora. Así que tienes que ponerte a industrializar el desarrollo del software, que es la forma «fina» de decir que tienes que empezar a poner orden.
 
Partimos de una situación en la que el proyecto es un caos, con lo que no podemos abordar todos los frentes a la vez, o corremos el riesgo de no conseguir reconducir ninguno. Para que el proyecto sea un caos y te llamen para reconducirlo es que probablemente ya tengan cosas entregadas o estén muy cerca de tener que entregar.
 
¿Por donde empezar?
 
Si hacemos caso a lo que propugnaba Bertran Meyer en su libro sobre Construcción de Software Orientado a Objetos, existen dos factores de calidad, los internos y los externos. 
 
Simplificando un poco, los factores de calidad externos son todos aquellos que ve el cliente y los internos son todos esos «palabros» que nos inventamos los técnicos, que si la modularidad, que si el polimorfismo, etc. 
 
Al final como el propio Meyer dice, lo importante son los factores de calidad externos, los internos son un medio para conseguirlos. Es decir, que lo que tenemos que conseguir es que el cliente esté contento, porque se han cumplido los requisitos, los plazos, los costes, etc. Un cliente normalmente no va a fijarse en que la complejidad ciclomática es mayor que 10.
 
¿Que es lo primero a asegurar?
 
Lo primero a mi modo de entender es asegurarse que se cumple el plan de pruebas y sino lo hay elaborarlo y luego cumplirlo. Es decir asegurar que cuando el cliente de a grabar la aplicación graba correctamente. Sin esto creo que lo demás da más o menos igual.
 
Pero mi cliente no quiere mojarse
 
A veces resulta que, sobre todo cuando un proyecto va mal, las personas involucradas en vez de tener una actitud constructiva para sacar el proyecto adelante, pasan a un modo de supervivencia en el que lo que hacen es actuar para que la culpa no sea suya, ya que vislumbran que el proyecto no va a salir bien. ¿Que hacer en esos casos?
 
Yo lo que propongo es que independientemente de que el cliente no quiera validar los planes de pruebas los elabores, aunque sea para uso interno y se los hagas llegar al cliente, con el mensaje de «estas son las pruebas que vamos a realizar» y ejecutar estas pruebas nos llevan tantas horas. 
 
De esta forma, independientemente del cliente, empiezas a darle la vuelta a la situación. Empiezas a controlar el caos y les haces ver que si quieren que en cada traspaso se prueben más cosas eso va a suponer más tiempo, es decir más coste.
 
Técnicamente no es complejo, unos documentos de texto con una descripción de que es lo que hay que probar y un espacio para indicar si la prueba a ido bien o no es suficiente para empezar. Luego ya te podrás meter en herramientas que te ayuden a mecanizar el proceso.
 
Si os habéis visto en una de esta no dudéis en compartir vuestras experiencias.
Publicado el

La imposición de normativas

Cuando te dedicas a estos temas de la industrialización del desarrollo de software y temas de arquitectura de aplicaciones web, normalmente sueles elaborar muchas guías, procedimientos o en general «cosas» que se entienden como normativas. Algo que me obligan a cumplir.

Recuerdo que cuando implantamos el CMMI en una empresa en la que trabajé, el auditor me llamó para preguntarme sobre el repositorio de código. Me preguntó si teníamos algún criterio fijado de como utilizarlo. Le dije que no, que era la realidad, cada jefe de proyecto se lo gestionaba como quería. Me dijo muy respetuosamente que eso no podía ser, que debíamos juntarnos y decidir un criterio, luego plasmarlo en un documento y a partir de ahí seguir ese criterio.

Creo que esa es la actitud que se debe de tener con respecto a las normativas. Nadie, o por lo menos en mi caso, va a trabajar pensando en como va a hacer la vida más difícil a sus compañeros. Hay que buscar la forma de trabajo más efectiva, documentarla y a partir de ahí seguirla.

Las normativas deben responder a una forma de organizar el trabajo teniendo una visión completa de todo el proceso. Igual un compañero no entiende porque se le pide hacer algo, que probablemente le parezca una pérdida de tiempo, pero normalmente está ahí por algo. Probablemente porque esa información se necesite en un paso posterior que el no realiza. Y si sobra, ya se valorará el modificarlo, pero eso no debe ser escusa para saltárselo. Las cosas que hoy son adecuadas puede que no lo sean dentro de un tiempo. Pero hay que cumplir los compromisos, la anarquía suele llevarse mal con la eficiencia, y a todos nos interesa hacer las cosas lo más eficientemente posible.

Publicado el

Decálogo de la Industrialización del Software en los traspasos

A la hora de industrializar el software hay una paso que es importante. Se refiere al traspaso del trabajo realizado a la infraestructura del cliente. Asumiendo que estás trabajando en una subcontrata. Da igual lo que has hecho en tu empresa, lo que cuenta es lo que entregas al cliente.

En este caso de los traspasos de software yo normalmente parto de un decálogo de índole técnico, para centrar a los compañeros, sobre todo los que tienen menos experiencia, de cuales son los objetivos que tenemos que perseguir, sin incurrir en excesivos tecnicismos de índole CMMI y similares.

Es un decálogo con planteamientos un poco lapidarios puestos adrede porque es muy triste cuando llegas a un sitio y te encuentras que tienen completamente descontrolado su proceso productivo, ocasionando graves problemas de calidad y de coste. Sobre todo cuando es muy sencillo de conseguir el tener un control básico, que hace que todo el mundo pueda vivir un poco mejor.

El decálogo es el siguiente:

  1. Lo que no está en el repositorio de código no existe.
  2. El contenido del traspaso se genera a partir del contenido del repositorio de código y solo desde el repositorio de código.
  3. Los ficheros que se traspasan deben estar etiquetados en el repositorio de código con un número único identificador del traspaso.
  4. Las incidencias que se envían corregidas en el traspaso deben estar etiquetadas en el gestor de tareas con un número idéntico al número identificador del traspaso.
  5. Todas las tareas deben estar recogidas en el gestor de tareas.
  6. Los traspasos entre entornos deben estar automatizados completamente o realizarse lanzando un script o similar, nunca manualmente moviendo ficheros.
  7. Se debe poder realizar traspasos parciales de un proyecto.
  8. Cada tarea recogida en el gestor de tareas debe contener toda la información para realizar el traspaso.
  9. No se traspasa nada sin que se hayan superado los controles de calidad.
  10. No se traspasa ningún proyecto sin que haya sido aprobado por el responsable del proyecto.

Iré explicando el porque de cada una.

¿Tenéis alguna norma más que apliquéis a los traspasos ?

Publicado el

Ventajas de la nube para un desarrollador

Cuando diseñas la arquitectura de una aplicación web de un cierto volumen de visitas debes dedicar un tiempo bastante importante a pensar en como vas a gestionar los picos.

Los picos pueden ser previsibles, como por ejemplo la época de matriculaciones en un colegio o no serlo, por ejemplo debido a un fallo técnico.

Normalmente el problema con los picos no previstos es que tienes que pensar como los vas a gestionar, y normalmente no es fácil, porque dispones de una capacidad de máquina limitada. O igual no…

Una de las primeras referencias del uso de la nube que tuve fue la de un periódico estadounidense que quería pasar a PDF todas las ediciones viejas. Una de las primeras opciones que valoraron fue hacerlo a la forma tradicional, comprar dos servidores y tenerlos funcionando durante 6 meses para hacer la conversión. La otra, que fue la que usaron, fue usar la nube y tenerlo listo en 36 horas.

¿Y si como desarrolladores tuviésemos la posibilidad de no preocuparnos de estas cosas de picos y dejar que lo solvente la fuerza bruta de la nube de Google o Amazon?

Cuando Google anunció el cierre de Google Reader, el popular servicio de lectura de fuentes RSS, la competencia, como por ejemplo Feedly  rápidamente contrató un aumento de los límites de proceso y de ancho de banda para dar servicio a los usuarios que se pasaban del Google Reader.

Publicado el

Que le pido a una Arquitectura: Controlar el «patras»

Otro de los problemas típicos cuando defines una arquitectura para una aplicación web es controlar los botones de ir hacia atrás, hacia adelante o los favoritos.

Hay que tener en cuenta que los navegadores web estaban originalmente pensados para mostrar información básicamente textual, no para hacer aplicaciones con un estado entre página y página. Es por ello cuando haces aplicaciones web los dichosos botones son un fastidio.

Técnicas para resolverlas hay muchas, desde las más peregrinas que utilizaba hace mucho tiempo, de poner un numerito incremental en cada petición y en el servidor comprobar que siempre venia uno superior, hasta soluciones más elaboradas como las que se aplican en el GWT (Google Web Toolkit)

Publicado el

Que le pido a una Arquitectura: Controlar el temblor

Cuando defines una aplicación web una de las cosas a tener en cuenta es el control del temblor del dedo. Me refiero a los usuarios que pinchan sobre una opción varias veces, porque no están seguros de si han dado bien, o ven que la aplicación no responde y se creen que se no les ha hecho caso. Es lo que yo llamo «el temblor».

Antiguamente cuando no se hacían las aplicaciones AJAX esto se solía controlar de las formas más peregrinas, desde poniendo una capa de bloqueo mientras se procesaba la petición, con lo que se conseguía un doble efecto, eliminabas la posibilidad de pulsación múltiple y además dabas al usuario una indicación de que le habías recibido su petición y estabas trabajando en ella.

Hasta manteniendo un numero incremental por cada petición y controlando en el servidor que siempre te venia un valor superior al que tenias guardado.

Con la generalización de las aplicaciones AJAX esto se puede conseguir de una forma menos manual, ya que se dispone de la posibilidad de bloquear las peticiones hasta que se reciba la respuesta del servidor.

¿Utilizáis alguna otra técnica para controlar «el temblor»?

Publicado el

Ant + Maven + Script = Gradle

En esta entrada quiero comentaros una herramienta que he descubierto no hace mucho y que me está gustando bastante. Tiene relación con la industrialización del desarrollo del software y los scripts para el mundo Java, principalmente.

La mayoría hemos utilizado Ant para crear nuestros scripts. Está bien, pero tiene un inconveniente principal. Te tienes que crear tu los scripts y definir el flujo de trabajo que quieres, desde cero. Es decir es una herramienta muy versátil, pero costosa.

Existe otra opción, que es usar Maven, que te proporciona el flujo de trabajo ya definido, utilizable solo con definir un fichero de configuración, pero que tiene el inconveniente de si quieres modificar ese flujo porque no te sirve tal cual, ya que es bastante costoso.

Ambas herramientas tienen un inconveniente en común y es que se configuran mediante ficheros XML, lo cual no siempre es lo más adecuado. Son ficheros muy grandes, y para un entorno de programadores sería más adecuado el uso de notaciones más cercanas al script.

Existe una herramienta que conjuga lo bueno de estas dos herramientas, y además con una sintaxis de lenguaje de programación. Se llama Gradle. La conocí por esa actitud de sigue a los mejores que tengo, ya que es la que utilizan ahora en el proceso de construcción de aplicaciones Android.

Existe un plugin para eclipse, que solo he utilizado una vez, ya que me hacia algunas cosas «raras», parece que cacheaba el script de gradle. Tampoco le he vuelto a dedicar más tiempo, porque tenia que ejecutar el script en una máquina sin eclipse.