What's happening

October 8, 2013

Scrum de Scrum Masters de septiembre

Tagged with

Comments 0

El pasado lunes 30 tuvo lugar la siguiente reunión de Scrum Masters de Kaleidos, tras el parón veraniego. En el orden del día, el repaso de conclusiones de la reunión anterior, y un punto importante, referido a las estimaciones de los trabajos de maquetación.

Repaso reunión anterior

Primera vez con menos asistentes

En la reunión anterior se decidió que asistiera sólo un Scrum Master por equipo, con la idea de agilizar el trabajo y reducir la carga de horas, sin perder demasiado en calidad y difusión de la información. La sensación ahora es que fue una decisión correcta.

Todos somos maquetadores

No entramos a valorar específicamente esta consigna surgida de la última vez, pero se percibe que es una cuestión que está progresando correctamente por ahora.

Scrum en equipos “grandes”

En el equipo que generó este debate, profundizando en la raíz de las causas, se ha visto que el problema no es tanto el tamaño del equipo, que parece que se va pudiendo gestionar bien con los mecanismos que se han ido implantando. Lo que está generando mayor estrés es el tener un cliente que, aparte de las tareas estables, requiere constantemente tareas urgentes, con prisa para salir a producción y que trastocan el ciclo de sprints y entregas planificadas.

Para afrontar la situación, el equipo ha decidido implantar lo que han llamado “Scrumban”. Es decir, se añade al backlog normal de Scrum un “canal Kanban”, una historia especial dentro de cada sprint donde puedan entrar estas tareas urgentes. Y se establecen varias restricciones para conciliar las expectativas del cliente con mantener la salud mental del equipo y la calidad del trabajo:

  1. Las tareas Kanban no se estiman, se ejecutarán ASAP teniendo en cuenta el tiempo de pruebas, Pirata Roberts y despliegue.
  2. Hay un límite en la cantidad de tareas que puede haber simultáneamente en el canal Kanban.
  3. Se acepta que el canal Kanban reduce la capacidad del equipo para historias normales, podrá haber historias del sprint que no se completen.
  4. Se han implantado varias técnicas para agilizar la gestión de ramas y los despliegues.

Esta estructura se acaba de implantar, en próximas reuniones iremos viendo si funciona.

Nuevos temas

Estimación de trabajos de maquetación

Hace pocos días se ha detectado un problema: desde que contamos con maquetadores propios de Kaleidos, integrados en los equipos, no estamos gestionando bien su trabajo. Parece que no tenemos claro cómo estimarlo, visibilizarlo, coordinarlo y calcular sus costes e incluirlos en los presupuestos. En cada equipo se está haciendo de forma distinta, lo cual desconcierta a los maquetadores, que están repartidos en más de un proyecto.

Tras un largo debate, llegamos a una propuesta que ofrecemos a todos los equipos para hacerlo así desde ahora:

  • Los maquetadores se van a gestionar como cualquier otro miembro del equipo, a todos los efectos, siendo su trabajo estimado en puntos, presupuestado y visibilizado con los mismos mecanismos que el de programación.
  • Esto implica que las historias tendrán puntos de maquetación y puntos de programación, sumados en un total. Se debe poder ver el desglose de ambos en algún sitio.
  • Según el proyecto, la estimación de maquetación se puede hacer como un % sobre la programación, o bien hacer una estimación más fina con la involucración del maquetador.
  • En historias en las que la maquetación y la programación caben enteras en un sprint, esto parece óptimo. La complejidad surge cuando no es así, teniendo en cuenta nuestra estructura de paralelismo, en los que los programadores pueden ir avanzando historias mientras se van maquetando las que entrarán en el sprint siguiente.
  • Se plantean dos posibles formas de hacerlo, según el tipo de proyecto:
    • a) Al llegar a la cima del backlog, la historia se parte en dos, una tiene la parte de maquetación y otra la de programación (para eso es necesario ver el desglose en puntos). En el sprint se mete la subhistoria de maquetación y la otra se deja en el backlog para el sprint siguiente. Esto vale en proyectos en los que las maquetas son percibidas por el cliente como algo con valor suficiente como entregable, para enseñar en la demo.
    • b) Las historias no se parten, y los maquetadores pueden trabajar en historias que están aún en el backlog. Cuando éstas entran en el sprint, se asume que los puntos correspondientes a maquetación ya están consumidos, y en el sprint se van a completar los de programación. Para esto, hay que congelar de alguna forma un fragmento superior del backlog, en un pseudo-próximo sprint o “sprint cocina”.
  • Se piensa en un futuro poder extender estas técnicas también a UX y diseño.

Profundizando en la involucración del Agile Coach

Dado el interés que tiene la figura y los buenos resultados que se van percibiendo, el Agile Coach sigue incrementando poco a poco su dedicación de tiempo. Aumenta también su presencia en reuniones de los equipos y su asistencia a congresos y actos relacionados con el agilismo. En algunos proyectos pequeños puede incluso ser él el Scrum Master aunque no participe en el desarrollo.

Se va tambien a plantear hacer más mediciones de parámetros de los equipos, para conocer mejor cómo están funcionando.

Felicidad del equipo

Se comentó también la situación de otro equipo en el que, a pesar de tener la sensación de estar realizando un buen producto al final, el proceso está siendo difícil. Esto provoca que la velocidad del equipo sea bastante menor de lo deseable, y genera cierta cantidad de estrés y frustración. Se informó de que ha habido una reunión en la que se han analizado las causas, tanto del lado de cliente y partners como internas del equipo, y se han establecido algunas medidas que se colocarán en un panel.

Open Space

Se decidió dar por fin el impulso definitivo al Open Space interno de Kaleidos, al que llevamos tiempo buscando hueco, y que se ha celebrado finalmente el día 4 de octubre, con interesantes resultados de los que esperamos hablar también pronto en este blog.

August 2, 2013

4ª Π WEEK – Post 1/2 con los resultados

Tagged with

Comments 0

Os presentamos el primero de los ¿dos? posts acerca de los proyectos de la IV PIWEEK de julio de 2013. Si alguien no sabe aún qué es la Π WEEK, aquí tiene dos enlaces explicativos.

Dwarven Tavern

Integrantes: Miguel de la Cruz, Juan Francisco Alcántara y Alonso Torres

La idea surgió porque queríamos desarrollar un entorno en el que desarrolladores pudieran programar diferentes estrategias para competir entre ellos. Después de darle bastante vueltas al problema, y buscar otros similares, surgió la idea de equipos compitiendo por un clásico “capturar la bandera” lo que terminó evolucionando a “Dwarven Tavern”.

Decidimos usar Node.js porque queríamos aprovechar para aprender esta tecnología y además pensábamos que era un problema que se adaptaba bastante bien a las características de node (rápido desarrollo de un servidor a medida, alta concurrencia, alta velocidad debido al tratamiento de eventos asíncronos, WebSocket….)

En la parte del visor también aprovechamos para investigar tecnologías que desconocíamos como WebSocket o canvas de HTML5.

Estamos muy orgullosos con el resultado obtenido en 1 semana de desarrollo y esperamos que ahora la gente se anime y programe bots :)

Todo el desarrollo está disponible en GitHub https://github.com/PIWEEK/dwarven-tavern con licencia MIT.

KOMUNUMO

Integrantes: Xavier Julián, Teresa de la Torre y Daniel Herrero.

Komunumo (“comunidad”, en esperanto) es una plataforma social y cultural cuyo propósito es hacer de altavoz de asociaciones vecinales y ser referencia de actividades en los barrios, dando visibilidad a movimientos alternativos y complementarios que no siempre tienen cabida en las administraciones.

Técnicamente, hemos utilizado en backend Grails que exponía datos a través de un API y un front con Backbonejs + Epoxy, LESS y HTML5. El objetivo del equipo era salir de su zona de confort y aprender manejando herramientas y lenguajes que no utiliza diariamente en su puesto de trabajo.

https://github.com/PIWEEK/komunumo/tree/develop

Intranet CLI

Integrantes: Yamila Moreno

Un command line interface hecho en python para imputar horas en la intranet hecha en Kaleidos desde la consola. Para quienes trabajamos sistemáticamente con el terminal, es una forma muy sencilla de imputar horas. Permite ir rellenando el parte mensual sin necesidad de tener que recordar cómo se han dispuesto las horas, ya que con una interfaz muy sencilla se va imputando periódicamente.

Requiere python3 y requests. Se liberará cuando se libere la propia Intranet de Kaleidos (esperamos que en un par de meses).

Comocomo

Integrantes: Andrés Moya

¿Es difícil transformar la forma en que comemos? Comocomo es una aplicación que permite ir haciendo seguimiento, de forma muy sencilla, de lo que comes cada día, el tipo de comida y su origen y distribución, y con ello analiza cómo es en tanto que sana y equilibrada pero también ecológica y socialmente justa, y obtiene un precio típico. Además compara todo ello con varios perfiles predefinidos, con lo que podemos saber si comer mejor es más caro, o cómo de lejos estamos de nuestra alimentación ideal.

Es una aplicación web maquetada para teléfono móvil. Usa Django en el servidor y jQuery Mobile + Backbone.js + CoffeeScript + Less en el cliente.

La aplicación es libre desde el primer momento, aunque por ahora no está terminada: https://github.com/PIWEEK/comocomo

Halisp λ

Integrantes: Alejandro Gómez

https://github.com/piweek/halisp

Para mi primera ΠWeek tenía ganas de desarrollar algo que no fuera un
sitio web y quería experimentar con dos lenguajes de programación que me
llaman mucho la atención: Haskell y Lisp. Para ello implementé un
pequeño intérprete de Scheme en Haskell siguiendo el libro
“Write yourself a Scheme in 48 hours”
.

Ha sido un ejercicio muy enriquecedor, he afianzado mis (escasos)
conocimientos de Haskell y descubierto la belleza y simplicidad de Lisp.
Una de las cosas más interesante del proyecto ha sido escribir una
pequeña librería estándar para el lenguaje. Aún quedan muchas cosas que
me gustaría añadir: más tipos de datos, soporte para macros, una mejor
sintaxis y entrada/salida. La ΠWeek ha terminado pero espero que el
experimento siga vivo.

Nora del editor: una captura de pantalla no procede en este caso :)

July 22, 2013

¡Feliz 2º cumpleaños Kaleidos!

Tagged with

Comments 6

Hemos cumplido dos años y es bueno hacer balance.

El primer año fue el de asegurar la superviviencia sin renunciar a nuestros principios (recogidos sucintamente en el Manifiesto). El balance fue bueno y se anotaron algunas mejoras.

Esas mejoras eran: darnos a conocer más (check), necesidad de más fuerza comercial (no check porque no se ha demostrado necesario pero check porque los resultados han llegado), trabajar con empresas (proveedoras) que compartan nuestra filosofía (medio check), plantar una bandera en otro país (no check).

Como nacimos en julio de 2011, nuestros años son segundo semestre y primer semestre de cada año.

Dicho esto, el final de 2012 fue aterrador, España podía salir del euro, el crédito de los bancos era nulo, la prima estaba por las nubes, se hablaba de corralito… y las empresas como la nuestra lo notaron. Fue como si se el apocalipsis se aproximara. Los clientes retrasaron decisiones, se cancelaron arranques, los ciclos de venta se alargaron… y nos pilló de sorpresa, como sorpresa ya es nuestro día a día en los tiempos en lo que hemos decidido crear esta empresa.

Le dimos una oportunidad a 2013 y no nos ha decepcionado. Hasta ahora está siendo un conjunto de buenas noticias. Hemos crecido en personas, en capacidades técnicas, en participación fuera de nuestros muros, en reconocimiento de profesionales y de clientes…

El secreto de nuestro éxito es un tándem bastante bueno; la labor comercial se afana en buscar proyectos chulos de clientes interesantes y que tengan un tamaño de más de 3-4 meses (normalmente 6-8 meses). A cambio de esa “selección”, los desarrolladores dan lo máximo sin hacer sacrificios personales. Para lograr unas buenas sensaciones en el avance de un proyecto tenemos una serie de magnitudes que tratamos de maximizar:

  1. Transparencia: nuestro cliente se entera de todo, incluso de si estamos haciendo el capullo, aunque normalmente lo que ve es un equipo motivado por buscar siempre la mejor solución.
  2. Anticipación: las malas noticias o las crisis a veces lo son porque nadie hizo nada para impedirlas. Con la información que ofrece ser transparentes, la capacidad para anticiparse a posibles problemas es impresionante. A mayor anticipación, menos situaciones que requieren heroicidades o broncas.
  3. Ritmo: cuando un equipo de trabajo trabaja con visibilidad e información de calidad y la comunicación fluye a buen ritmo con el cliente, lo que se consigue es una velocidad mantenida que “devora” el proyecto como estaba previsto.

En el apartado de crear productos/servicios propios tenemos puestas muchas esperanzas en Greenmine. Aún le queda algo de trabajo para una beta privada en septiembre pero promete ser el gestor online de proyectos ágiles 0-bullshit más práctico y divertido de usar que hayáis probado.

Transcurridos dos años, el acuerdo de no agresión firmado con nuestra anterior “casa” ha expirado y aunque lo hemos cumplido sin mucho esfuerzo, supone una losa psicológica menos y una sensación de libertad mayor.

Tras 4 PIWEEKs, el formato está asentado y funciona muy bien. Para la de diciembre de este año, que ya podemos anunciar que será la del 16 al 20, prometemos llevarla al siguiente nivel :)

Las mejoras o retos previstos para este tercer año son para mí tres;

  • Asegurar que seguimos contratando a gente magnífica y que no cometemos errores por la presión del crecimiento.
  • Plantar una bandera (esta vez sí) fuera de España.
  • Lanzar un proyecto propio y para ello Greenmine va en cabeza.

“Científicos rusos afirman que” el tercer año es el que confirma si sobrevives o te quedas en el camino. En la fiesta por el segundo aniversario comentaba a todos que tenemos ahora cierta responsabilidad extramuros. Tenemos que demostrar a muchos que están expectantes que el modelo de compañía de Kaleidos es plenamente viable y animar a otros a que se lancen a la aventura.

Por cierto, si alguien se quiere pasar por nuestras oficinas, que escriba a hello@kaleidos.net y le hacemos la visita :)

July 9, 2013

Incoming Message: Django Developer Wanted

Tagged with

Comments 0

[Incoming Message. Source Anonymous] [Public Key Decription Complete]  OK, you asked, so I'll tell you. We have been following you closely. So closely that we know you're reading this from a Mesh-terminal in Elysium, Mars. Keep reading, it's OK.  You're curious, maybe too much for some other factions but we love that. We are a strong community devoted to open source and innovation and we rely on strong capable individuals to achieve our goals. Goals like freedom in what we deliver to our clients or professional satisfaction in our work. Things have to change, quickly.  It's the HOW, not just the WHAT. We're a minority in a sea of self-indulgence. We see transhumanity as a powerful opportunity, with nearly limitless potential, but we also face terrible dangers from our own species and now that the Pandora Gates have been discovered, alien encounter might occur anytime soon. We ask you to join us.  We need a Django Developer with real-world expertise (3yrs min). GIT is a must, Devops orientation, FOSS clearance. Nginx,  Redis, Celery, MongoDB,  some Javascript programming skills (ex: Angular or Backbone) will each count as valuable assets. Community contributions are a plus too.   Salary might vary but it ranges from 28.000 and 36.000 Europa-credits.  If interested, please contact us through our legacy hello@kaleidos.net, it's much more secure as it bypasses official screening, but of course you already know this.  BTW, we liked your job at the art auction last year, neat.  [End Message] [This Message Has Self-Erased]

You might also want to take a look at what awaits us next week.

July 4, 2013

4ª Π WEEK Personal Innovation Week de Kaleidos del 15 al 19 de julio

Tagged with ,

Comments 0

La semana del 15 al 19 de julio, Kaleidos vuelve a “cerrar por innovaciones”. Así es. Una semana al semestre, la denominada Π WEEK, todos los empleados aparcan unos días los proyectos en los que están inmersos para dar rienda suelta a su creatividad y vocación innovadora. En julio de este año celebramos la cuarta Π WEEK (y coincide con el segundo aniversario de Kaleidos).

La dinámica es relativamente sencilla. Cada empleado tiene la oportunidad de definir un proyecto para esa semana. Si considera que puede ser muy útil contar con otros empleados, puede ofrecer abrir el proyecto a otras personas que no tengan un proyecto claro. Esto genera un “mercado de talento” muy interesante y divertido, en donde los proyectos más atractivos pelean por “reclutar” a cuanto más, mejor.

La llamamos Π WEEK, pronunciado “pi week” porque es la semana de Personal Innovation y porque nos encantan los números irracionales como Π. Al ser una semana muy concreta, los resultados también deben ser concretos y presentables al término de la mañana del viernes.

Las condiciones para que un proyecto pueda tener cabida en la Π WEEK son:

  • Debe utilizar sólo tecnología libre.
  • Debe resolver un problema bien identificado.
  • Debe poder liberarse en fases posteriores de desarrollo.
  • Debe resultar una auténtico placer volcarse esa semana en ese proyecto.
  • El viernes a las 14h, debe poder presentarse un resultado concreto y tangible.

No hay, sin embargo, requerimientos como:

  • Ser útil para Kaleidos o la actividad empresarial que representa.
  • Tener un modelo de negocio viable.
  • Los participantes sólo pueden ser empleados de Kaleidos.

¿Por qué apostamos por la Π WEEK?

En primer lugar, porque ayuda a mantener un magnífico ambiente laboral. El talento hay que mimarlo y estas iniciativas son un gran aporte.

En segundo lugar, por responsabilidad con nuestros clientes. A pesar de que suspender una semana los proyectos en curso pueda parecer nocivo o contraproducente, es nuestra forma de garantizar que seguimos estando en la brecha de la tecnología e ideas más innovadoras. Tras cada Π WEEK podemos afrontar los mismos o nuevos proyectos con nuevas perspectivas.

Finalmente, existe la posibilidad de que alguna de las ideas desarrollada tenga el potencial de pasar a ser apoyada y financiada por Kaleidos y sea todo un éxito.

Se nos ha ido pasando un poco el arroz invitando a otras empresas a participar porque la verdadera “agenda oculta” de la Π WEEK es la celebración de una semana de innovación libre en toda España de la manos de muchas empresas o profesionales que quieran mezclarse y construir algo juntos. De todas formas, aún estamos aceptando propuestas de empresas que ofrezcan el 100% del tiempo de determinadas personas esa semana. Escríbemos a hello@kaleidos.net si quieres saber más :)

Podréis seguir la actividad de la piweek en el blog creado para ello.

June 28, 2013

Scrum de Scrum Masters de Junio (con algo de retraso)

Tagged with , ,

Comments 1

Este lunes 24 de junio tuvo lugar la última reunión de Scrum Masters de Kaleidos, muchos (cientos, millones de fieles seguidores) os habréis dado cuenta de que el mes pasado no hubo post, os pido disculpas pero una mezcla de carga de trabajo, procrastinación y astenia primaveral pudo conmigo, no volverá a suceder :) .

Esta vez tampoco teníamos un orden del día claro antes de la reunión (uno de los puntos en los que estamos trabajando), tener un orden del día permite que la gente pueda pensar en los temas a tratar y que estos sean mucho más productivas. La sesión se centró fundamentalmente en hacer una retro sobre nuestras propias reuniones y salieron varios puntos interesantes:

Relación entre Scrum Masters y Agile Coach

Una de las acciones que fijamos en la reunión anterior fue que el el Agile Coach hiciera una revisión por sprint con el Scrum Master de cada equipo. No se trata de una comprobación exhaustiva, es más un levantamiento de banderas a tiempo cuando algo “huele mal”, se comprueba por ejemplo si el backlog está razonablemente sano, el visual management, si las gráficas están actualizadas, a veces pega la oreja durante el Daily.

Los equipos y los Scrum Masters lo han recibido estupendamente y nos está siendo muy útil. Con el número de equipos que tenemos activos (cuatro actualmente) y el poco tiempo extra que le consume al Agile Coach está siendo un #win total

Reuniones de Scrum Masters VS Coaching de equipos

El formato de nuestras reuniones va a cambiar ligeramente. El número de asistentes a las reuniones estaba cerca del 50% de Kaleidos y hemos decido que únicamente asistan los Scrum Masters. Esta medida la disparó uno de nuestros equipos que cuenta con cuatro miembros de back con tres de ellos asistiendo a las reuniones. Con esto esperamos reducir el lucro cesante que tienen los equipos y agilizar un poco más las reuniones, por contra vemos el riesgo de que se pierda información de calidad, tendremos que ver cómo evoluciona.

Agile Coach en las retros de sprint

Esta medida surgió a raíz de un proyecto del tipo cliente pro-anti-scrum: “pro” porque en el proyecto Scrum era un requisito y “anti” porque es incapaz de seguir el ritmo que intentamos fijar. El equipo está trabajando sobre todo en la vía de hacer visible y medible la situación, tiempos de bloqueo, tiempo gastado “en B”, reuniones que agendan reuniones que agendan reuniones para tener otras reuniones… el objetivo es conseguir un cambio de actitud que se resiste a aparecer.

Un punto muy positivo fue cuando el Agile Coach asistió al último fin de sprint y pudo ver la situación en directo. Ayuda mucho el que una persona con autoridad ajena al equipo y al cliente ponga las cartas sobre la mesa, de un golpe de realismo y hable de lo que se está haciendo mal.

El resto de Scrum Masters están de acuerdo en que el Agile Coach pueda asistir cuando quiera a sus fin de sprints y que se sienta libre de opinar y de afirmar lo que vea, nadie lo interpreta como una amenaza o como un ruido innecesario sino todo lo contrario.

Scrum en equipos “grandes”

Lo que arrancó como un posible problema de equipos grandes autogestionados mutó en una necesidad de cambio de mentalidad. Por poneros en contexto ahí van unas pequeñas pinceladas sobre cómo son y cómo funcionan los equipos en Kaleidos:

  • Los proyectos que tenemos actualmente en marcha son fundamentalmente web
  • Los tiempos de sprint son cortos, normalmente de dos semanas. A veces hay user stories que se maquetan y programan a la vez.
  • Hay un único perfil de maquetador “puro” por equipo
  • Hay entre cuatro y seis perfiles de backend por equipo
  • UX y Diseño van ligeramente adelantados al sprint en curso (además tenemos el handicap de que no son miembros de Kaleidos sino que normalmente son nuestros amigos de Secuoyas)

La discusión vino sobre si era posible o no en Kaleidos tener un equipo de ocho personas operativo. Después de hablar sobre ello lo que detectamos es que la situación actual es que el maquetador suele estar ahogado porque intenta alimentar al resto del equipo de back. Lo que vimos es que si el equipo tuviera un cambio de mentalidad podríamos no solo tener equipos más grandes sino hacer que los maquetadores vivan mejor en los equipos que ya están funcionando. El problema es que muchas veces la gente de back intenta estar lo más alejada posible del html y del javascript, esto para nosotros es un error, como hemos dicho la mayoría de nuestros proyectos son 100% web, no podemos estar lejos del html, todo lo contrario, tenemos que estar cerca por definición. La progresión de nivel de javascript en los proyectos va creciendo de manera exponencial, aparte del clásico jQuery nuestros proyectos tienen backbone, epoxy, angular, parsley, grunt…y el enfoque clásico de: “si se ejecuta en el navegador es front y por tanto maquetación”, ya no es válido. Sí que tenemos equipos en los que las tareas de maquetación y programación de javascript están diluidas entre los miembros del equipo y en los que el rol “maquetador puro” es más una guía y no un cuello de botella pero parece que este mensaje tiene que fluir a todos los equipos.

Y poco más, ¿qué os parece?, ya sabéis que todo el feedback que nos deis será bien recibido :)

June 19, 2013

Desk-surfing en Alea Soluciones

Tagged with

Comments 0

Cuando Eduardo (@eferro) me invitó a una sesión de desk-surfing en Alea Soluciones dije que sí sin dudar. Y sin tener mucha idea de qué era eso del desk-surfing. Consiste en ir un día a su oficina y trabajar con el equipo y asistir a las reuniones de su equipo. ¡Genial! Podría escaquearme un día de mi aburrida empresa e ir a otra a pasar un plácido día. Vacaciones.

Casi. El desk-surfing con Eduardo, Guillermo (@pasku1) y Alberto (@apa42) resultó ser una experiencia muy enriquecedora y gratificante. Y también agotadora.

Nada más llegar me hicieron una visita guiada por las oficinas, y me explicaron a qué se dedican en concreto: muy reveladora me pareció la visión del negocio desde el punto de vista de un desarrollador.

Y comenzamos la jornada: reunión diaria. De pie, frente a uno de los ordenadores, viendo el panel de tareas; se pusieron al día de los últimos avances, y se repartieron los objetivos del día. En total, 20 minutos máximo para poner la maquinaria en marcha.

Yo empecé mi desk-surfing haciendo pair programming con Eduardo; aquí mi intervención fue mínima, pero me dio la ocasión de aprender mucho sobre su modo de trabajar.

Después pasé a desarrollar una pequeña funcionalidad con Guillermo que fue mucho más temerario a la hora de dejarme el teclado. ¿La razón? TDD. Aquí no pican una línea que no tenga un test previo. Es una rutina complicada para el que siempre ha trabajado de otra forma, pero una vez más los resultados son abrumadores: el equipo trabaja rápido, con seguridad, reduce el bus factor… Demasiadas ventajas como para pasarlo por alto.

Merecido descanso a la hora de comer. Y más pair programming: un módulo similar al anterior, esta vez con Alberto. Tras pasar toda la mañana viendo código y la organización de módulos, me sentía sensiblemente más cómoda cuando me tocaba coger el teclado.

Cerramos la jornada debatiendo sobre si su sistema “no tomes ninguna decisión que puedas aplazar un día más” (implementado de forma extrema) es válido para otros escenarios donde el cliente final tiene más involucración.

El día fue intenso pero se me pasó volando. En su pequeño despacho, tienen sus paneles por todas partes, comparten las decisiones y la responsabilidad y rápidamente se nota muy buen ambiente. Fueron excepcionales anfitriones y me dieron la oportunidad de aportar desde el minuto cero. ¡Ahora queremos la revancha!

May 24, 2013

Hired! Alejandro Gómez

Tagged with , ,

Comments 1

Tras Miguel y Alonso, hoy le toca el turno a Alejandro, otro nuevo fichaje reciente en Kaleidos que se presenta a sí mismo. Al final veréis las dos preguntas fuera de guion :)

Me llamo Alejandro y la semana pasada Alonso y yo nos unimos a Kaleidos para algún día conquistar el mundo. Voy a desarrollar con Python y Django, mi lenguaje de programación y framework web favoritos.

Nací y crecí en un pueblecito de Euskadi llamado Elorrio. Me fui a estudiar a Málaga donde conocí a algunos de mis mejores amigos y me aficioné (aún más) al flamenco. Tuve la oportunidad de pasar un año en Dinamarca gracias a la beca Erasmus y encontré un trabajo en Alemania el verano siguiente. Pudiendo quedarme en Berlín decidí hacer el macuto y volver a España con la que está cayendo, sin trabajo, y decidido a ganarme la vida utilizando tecnologías libres.

El software libre me ha dado mucho más de lo que yo nunca podré devolver: amigos, conocimiento, disciplina y humildad. A base de construir, publicar, fallar y escuchar _feedback_ he crecido como persona y profesional. Disfruto aprendiendo y viendo cómo otros aprenden y las comunidades FLOSS son el lugar perfecto para ello. Es un entorno donde se practica el modelo Academia.

Me encanta la literatura, tengo una permanente pila de libros sin leer y espero que sea así siempre. He pasado horas leyendo a Hesse y mirando en mi interior; contemplando las visiones de Blake; o escuchando a Whitman cantarse a sí mismo y a todo lo que le rodeaba. También soy muy aficionado al manga y estoy empezando a descubrir el cómic europeo. Viajo todo lo que las circunstancias me permiten. Sólo o en compañía. Me mueve la curiosidad.

Estoy contentísimo de formar parte de Kaleidos por el enorme talento del equipo, pasión por aprender y enseñar, el amor por la calidad y porque lo de conquistar el mundo va en serio. Tiempo al tiempo.

Pregunta bonus: Si tuvieras la opción ¿montarías un tablao flamenco xor una tienda de libros?

Uff… creo que me decantaría por montar un tablao flamenco pero fuera de España; me llevaría a mi padre de cocinero, mi madre para que gestione y mi hermano (proyecto de Diseñador) podría encargarse de que no falte el arte.

Pregunta malus: Tú que has vivido en el norte, en el sur y hasta en Dinamarca y Alemania… ¿dónde viste más bluff/postureo técnico?

En el norte no estuve mucho tiempo así que no puedo opinar. En Málaga eché de menos más software libre en la universidad, solía ir a hackathones en Granada a menudo porque allí tienen la Oficina de Software Libre, gente muy buena (tanto profesores como alumnos) haciendo cosas desde la universidad.

Dinamarca fue un poco decepcionante, la verdad es que me esperaba una educación mejor pero era una extensión de las cárnicas de allí. A pesar de que las clases giraban alrededor de tecnologías propietarias nos las apañamos para sacar adelante proyectos con Python, Arduino y Android.

Berlín ha sido sin duda la ciudad con más ambiente tecnológico: grupos de usuarios, conferencias, incubadoras, … el mundo estartapil está en auge allí. Es sin duda el sitio con más nivel de los que he estado, el problema es que “Winter is ALWAYS coming”.

Parece que he dado la vuelta a la pregunta maligna ^_^

May 23, 2013

Hired! Miguel de la Cruz

Tagged with , ,

Comments 1

Tras Alonso, hoy le toca el turno a Miguel, otro nuevo fichaje en Kaleidos se presenta a sí mismo y luego le hacemos dos preguntas fuera de guion :)

Soy Miguel de la Cruz, el de la foto. Con cuatro años me construía ordenadores doblando un papel y pintando las teclas en la parte de abajo, hasta que a los doce conseguí uno que se encendía. No tardé en “romperlo” instalándole el Mandrake (aún no era Mandriva) que venía con una revista, empezando a conocer así en el mundo de Linux y el Software Libre.

Comencé a estudiar Informática en la Universidad Carlos III donde aprendí a programar y entré en el Grupo de Usuarios de Linux. Este grupo y las personas que conocí allí me ayudaron a disfrutar más con la comunidad, a ampliar mis conocimientos y horizontes y a consolidar mis ideales.

Mientras estudiaba estuve trabajando en varios puestos relacionados con la administración de sistemas, pero lo que de verdad me gustaba era la programación, así que acabé introduciéndome en el mundo del desarrollo web y di el salto a Groovy y Grails. Ahora no me imagino haciendo otra cosa que no sea escribir código.

Me gusta leer, jugar al rol, los videojuegos y la ciencia ficción. Mi máxima es simple: espero ser capaz de aportar al menos la mitad de lo que aprenda, y seré feliz si la mitad de lo que aporte llega, además, a ser de utilidad a la mitad de la mitad de los que me rodean.

Pregunta bonus: ¿Cuál es ese trocito de conocimiento que te enseñaron en la universidad que vuelve constantemente a tu cabeza para explicar algo o aplicarlo en tu día a día?

Me acuerdo constantemente de un profesor fantástico que me enseñó que la teoría, muchas veces y más en el mundo de la programación, debe quedarse en los libros. Me contraponía diversas formas de abordar problemas y algoritmos que eran correctas teóricamente e inútiles en la vida real con prácticas incorrectas a nivel teórico que convertían nuestro código en algo mucho más legible y mantenible. Esto y que “a programar se aprende leyendo código” son las dos enseñanzas que más presentes tengo.

Pregunta malus: ¿Cuál es la flamewar que te gustaría ganar por aplastamiento si se te diera ese poder?

Si tuviera una oportunidad como esa, sin duda terminaría con la legendaria batalla entre KDE y Gnome. Al principio, ambos tenían sus puntos fuertes y flojos, los titanes del mundo del software libre escogieron su bando y los flames llenaron los foros. En los últimos años, los dos proyectos han evolucionado con tendencias muy marcadas, que dejan bien claro quién es el ganador. Larga vida a dwm!

May 22, 2013

Hired! Alonso Torres

Tagged with , ,

Comments 1

Hoy dejamos que Alonso, nuevo fichaje en Kaleidos se presente a sí mismo y luego le hacemos dos preguntas fuera de guion :)


¡Me presento! Mi nombre es Alonso Torres: geek, madrileño, ingeniero y apasionado del desarrollo y las nuevas tecnologías.

Lo que más me gusta de mi profesión es el reto que supone buscar la mejor solución a un problema a la vez que intento aprender cada día algo nuevo.

Me encanta el diseño orientado a objetos y la definición de arquitecturas software. Considero que un software no sólo tiene que ser funcional para que esté bien desarrollado, conceptos “internos” que el cliente muchas veces no puede apreciar (mantenibilidad, modularidad …) a menudo marcan la diferencia.

Otro de mis intereses son los automatismos y todas las facilidades que se pueden dar día a día al desarrollador para disminuir el ruido e intentar facilitar su vida. Proporcionar herramientas e interfaces para realizar las tareas con más facilidad o mejorar los procesos de desarrollo sólo puede llevar a mejorar la calidad del software y la vida de los desarrolladores.

Los ratos que me aparto del ordenador me encanta la literatura de fantasía y ciencia ficción. Mi otra gran afición es el Go el cual os animo a probar a todos los que no lo conozcáis :)

Pregunta bonus: ¿En qué proyecto de crowdfunding te meterías de cabeza si fuera para liberar un proyecto de juego de ordenador de tu infancia? ¿cuánto pondrías?

“El Día del Tentáculo. Pocos juegos recuerdo con tanto cariño y además ¡¡Incluía dentro el Maniac Mansion!!. La cantidad dependería de los bonus, pero me gustaría que uno fuera recuperar los sistemas “anti-piratería” que tenían los juegos de Lucas Arts por esa época. Como el círculo con caras del Monkey Island.”

Pregunta malus: ¿Qué gadget te compraste como early adopter y te arrepentiste en la primera semana?

La primera semana me arrepentí de comprarme la PSP. Tenía un catalogo horrible de juegos y se demostró que su invento de los UMD fue un fiasco monumental. Del gadget que me arrepentí más de haber sido “early adopter” fue del iPhone. Me lo compré y se quedó enseguida obsoleto. Al poco tiempo ni actualizaban el software. Sin entrar en debate Android vs iPhone estas cosas ahora no me pasan con mi Android :)

1 2 3 5