Nunca subestimes el poder de una buena configuración, a fin de cuentas el ser humano a nivel subatómico no se diferencia mucho de una roca. Al final todo es cuestión de configuración.
Creo que lo que peor llevo viviendo en Panamá es que no existe el cambio de estaciones como tal.
Si es cierto que los días se alargan y acortan un poco en función de la época del año (1 hora aproximadamente). Y también es cierto que existe la temporada de lluvias ( conocida como Invierno ), y la temporada de sol ( Verano ) , que suelen repartirse el año.
Pero la única diferencia es esa, porque calor y humedad hacen los 365 días del año.
En concreto Otoño siempre ha sido mi estación favorita. El calor sofocante del verano se va suavizando con los días, las tardes comienzan a ser algo más cortas y el viento comienza a soplar con más fuerza.
Imagino que habiéndome criado en Madrid, donde las estaciones suelen ser extremas, cueste más acostumbrarse a tener prácticamente el mismo clima durante todo el año.
Hubo un pasaje mientras leía A Wild Sheep Chase que me llamó la atención. Era una reflexión que hacía el protagonista en la que se daba cuenta de que “se había perdido el otoño”.
Aunque pueda parecer una tontería, entiendo perfectamente esa frase. Y es que cada estación tiene algo que merece la pena disfrutar.
Aquí os dejo algunas fotos que tomé durante estos días. Habitualmente cuando me bloqueo programando o tengo que diseñar algo salgo a dar un paseo para despejar las ideas y buscar inspiración. Y de paso aprovecho para tomar algunas fotos de San Lorenzo en Otoño
Mas fotos en aquí
Emulando vilmente este post de Kirai, aquí tenéis lo que viene siendo un típico viaje Panamá - Madrid.
Saliendo de Casa
Camino al Aeropuerto de Tocumen
Haciendo tiempo hasta que sale el avión a Miami
Welcome to Miami
Paseando por el Aeropuerto de Miami
Haciendo tiempo hasta que sale el avión a Madrid
Aterrizando en Madrid
T4 de Barajas
Metro…
Tren…
San Lorenzo de El Escorial
En total unas 28 horas de viaje (contando esperas), 1 coche, 2 aviones, 2 trenes, 1 metro y 1 autobús.
Desde hace ya unas semanas comencé a colaborar en tequilog.com junto con algunos de los programadores, diseñadores y, en general, geeks de panamá que pululan por el entorno 
La idea detrás de este blog es compartir consejos, trucos, o pedazos de código que puedan ayudar, informar o, en general, de lo que apetezca hablar.
Era algo que me apetecía hacer desde hace bastante tiempo pero no tenía el lugar adecuado para hacerlo.
En este mundillo resulta que hay poca información publicada en español sobre ciertas tecnologías o lenguajes de programación, y lo que pretendemos con esta iniciativa, es ampliar la información técnica disponible en nuestro idioma, y si lo podemos hacer de manera amena, pues mucho mejor.
Animaros y pasaros por ahí!
Si algo he aprendido en este tiempo es que no todas las horas tienen 60 minutos, no todos los días son de 24 horas, no todos los meses duran alrededor de 30 días y que 12 meses no siempre hacen un año.
En la metodología de desarrollo ágil se usan varias técnicas diferentes. Si habéis escuchado algo sobre Scrum o XP, todas esas técnicas, o metodologías tienen algunos puntos básicos en común.
Aquí os voy a hablar de alguno de ellos:
Imagen tomada usando Caimito One Team
El backlog es prioritizado por el Product Owner y los Stakeholders (clientes, usuarios finales, etc) de manera que los asuntos más importantes siempre están en la cabezera.
Si bien esta aproximación es muy básica, nos da una idea que sí es bastante importante. Al final de una iteración el software debe estar listo para correr en un entorno de producción.
Esto no quiere decir que lo que se entrega esté escrito en piedra, de hecho lo ideal es que el cliente pueda probar realmente el producto y proporcionar el feedback necesario para construir lo que realmente quiere.
Un ejemplo de una iteración sería esto:
Imagen tomada usando Caimito One Team
Como podéis ver, una iteración se compone de los mismos elementos que teníamos en el backlog. Cuando los stories están listos para comenzar a trabajar con ellos y se tiene el suficiente material como para abarcar una iteración de trabajo, se genera la iteración y todo el mundo comienza a trabajar.
Una iteración es un compromiso que el equipo de desarrollo establece con el cliente final. Se compromete a que todos esos puntos, que se han incluido en la iteración estarán listos y funcionando al final de la misma.
La idea de esto es encapsular pequeñas funcionalidades que sean entendibles por los programadores y rápidamente implementables. De manera que si es necesario modificar o descartar el story no se deba emplear o se haya perdido mucho tiempo.
Generalmente un story se compone de esta estructura:
Siendo un [ rol ]
Quiero que [ funcionalidad ]
Para que [ valor de negocio ]
De ahí el famoso As a… I want … so that … que seguramente ya habréis visto por internet.
Aquí podéis ver un ejemplo de un User Story:
Imagen tomada usando Caimito One Team
Como podéis ver, el story no entra en detalles de cómo debe ser la implementación ni engloba todos los posibles casos de uso. Simplemente define un concepto de manera que el programador que vaya a trabajar en ese story tenga una idea de por donde comenzar a trabajar.
A medida que comienza la implementación del story y surgen las dudas, el programador colaborará con el Product Owner para aclarar esas dudas, y finalizar exitosamente el story. (En el próximo post donde explicaré los roles dentro de un equipo ágil os explicaré que es esto del Product Owner, mientras tanto os puedo dar este link[ENG])
Escribir buenos stories es todo un arte, aquí tenéis algunos consejos para escribir buenos stories. [ENG]
En general un story debe ser lo suficientemente pequeño como para que un programador pueda realizarlo sin problemas durante una iteración, y lo suficientemente significativo como para que añada valor de negocio al producto. Es ese equilibro el que diferencia un buen story de otro no tan bueno.
Una vez escrito el story, el equipo de desarrollo lo lee, conversa sobre él para asegurarse de que todo el mundo entiende lo mismo y procede a estimarlo. Sobre la estimación de un story hablaré algo más adelante en este post.
Una vez ha sido estimado, está listo para ser introducido en la iteración y comenzar su implementación.
Es importante que exista un test para cada story que se implementa. De manera que dichos test por un lado validan el correcto funcionamiento de la implementación, y por otro sirven de documentación para el mismo.
Si al implementar un story nos vemos incapaces de realizar un test que lo cubra, probablemente estemos tratando de implementar un story demasiado grande.
Estos stories reciben el nombre de Épicos, y deben ser subdivididos en otros stories más pequeños.
Cuando se detecta un funcionamiento anómalo en el comportamiento de nuestro código se debe reportar y rellenar un reporte de error.
Ejemplo de un Bug Report:
Imagen tomada usando Caimito One Team
De acuerdo con la idea de tener código listo para producción, al planear una iteración, todos los Bugs Reports que tenemos en nuestro Backlog, pasan automáticamente a la iteración, ya que antes de desarrollar nuevos stories es fundamental que el código que ya existe funcione correctamente.
En cuanto a las tareas, podríamos definirlas como pequeños stories para los que no podemos realizar un test para verificar, o no tiene sentido estimarlas.
Ejemplo de una tarea:
Imagen tomada usando Caimito One Team
Las tareas son un arma de doble filo, por su similitud con los stories en ocasiones no resulta tentador “disfrazar” stories como tareas. Tal vez para ahorrarse escribir los test, o para ahorrarse el proceso de estimación… sin embargo es importante limitar el número de tareas con las que se trabaja.
Principalmente el hecho de que una tarea no tenga una estimación es peligroso, ya que el trabajo realizado no se refleja directamente en la velocidad del equipo a lo largo de la iteración. (hablaré de la velocidad más adelante)
La experiencia empírica demuestra que este proceso está errado. En general las estimaciones basadas en tiempo suelen ser bastante inexactas, suelen “recortarse” por parte de ciertos comerciales para competir por vender un proyecto y eso devienen en un sin fin de problemas que básicamente terminan con un equipo de programadores trabajando hasta altas horas de la noche, molestos, desmotivados y sacando el trabajo como buenamente pueden.
No hace falta ser un visionario para darse cuenta de que ese código no solo es propenso a errores, si no que un programador, trabajando en esas condiciones no puede dar lo mejor de sí.
Estimar en complejidad, al principio resulta bastante incierto, pero en mi experiencia personal ha demostrado ser una medida bastante más fiable a la hora de saber qué cantidad de trabajo semanal soy capáz de llevar a cabo.
Las métricas usadas dependen completamente del equipo o el software que se esté usando para estimar.
One Team, por ejemplo, utiliza los valores: 10, 20, 40, 80, 1000000, siendo éste último el valor asignado a stories épicos.
Al principio, para nuevos equipos, es bastante habitual que la velocidad del equipo (la suma de los valores asignados a los stories que se completan al final de la iteración) varíe. Pero con el tiempo, a medida que el equipo comienza a perfeccionar sus prácticas ágiles, es habitual tener una velocidad más o menos estable, permitiéndonos de esta manera, saber cuantas iteraciones nos hacen falta aproximadamente, para finalizar el proyecto (o al menos todos los asuntos que tenemos pendientes en en backlog).
Con estos conceptos básicos podemos comenzar a trabajar de manera ágil. Espero que os sirva de ayuda o de referencia para iniciaros en esta metodología 
