Developing Frogtek

El blog del Departamento de Tecnología

Categoría: miscelánea (página 2 de 8)

Agile Open Space Zaragoza 2012

¿Qué es un Open Space?

La técnica del Open Space permite conseguir, de un grupo numeroso de personas y en un mínimo tiempo, las mejores ideas alrededor de una o varias materias (“tracks”) sobre un gran tema.

Definición y más explicación aquí.

¿Por qué “Agile“?

Porque gira en torno a las metodologías ágiles y es una de las dos reuniones anuales realizadas por la Comunidad Ágil en España.

¿Qué hace Frogtek hablando de este evento?

Desde la creacción de Frogtek, hemos valorado mucho la formación y la mejora continua a la hora de realizar nuestro trabajo. No hay mejor forma de aprender y mejorar que compartir tus experiencias y escuchar las de otros.  En un Open Space, se potencian esas dinámicas para permitirte obtener el mayor conocimiento y valor el tiempo que pases allí.

¿Os han servido de algo vuestras asistencias de otros años?

Siempre, de una forma u otra hemos sacado algo positivo. Del último, por ejemplo, obtuvimos ideas nuevas sobre Agile Testing o creación de User Stories. En el de 2010, compartimos nuestro modelo de organización y nos sacaron punta, ayudándonos a mejorar en la dirección correcta.

¿Recomendáis acudir al eventazo del año?

Por supuesto, ¿a qué esperas para apuntarte? Regístrate aquí y vente a compartir y aprender en un evento distinto.

 

Curso de introducción a Android en Zaragoza

Hace unas semanas anunciábamos un curso de Android en Walqa, pero su escasa participación nos obligó a cancelarlo. Ahora, volvemos a lanzar el curso en Zaragoza. Aquí están los datos sobre el curso para los que podáis estar interesados.

  • Orientado a: Desarrolladores con experiencia en lenguajes orientados a objetos
  • Plazas: 15
  • Fecha: Del 16 al 20 de abril. De 9 a 14 horas.
  • Lugar: Iniciativas Viables. C/ La Milagrosa 5-7. 50009 Zaragoza
  • Precio: 250€.
  • Inscripciones e información a: jose (arroba) frogtek (punto) org

Las buenas maneras de un programador

Ayer me encontré con el siguiente artículo, “The 10 commandments of good source control management” .  Había sido twiteado por @psluaces. Comencé a leerlo y no pude evitar que una sonrisa invadiera mi cara conforme iba leyendo. Aunque algunos de los mandamientos no son muy útiles o relevantes para mí (no he usado VSS nunca, por ejemplo). Otros los he cometido y sufrido con demasiada frecuencia como para dejar pasar la oportunidad de comentar al menos un par de ellos.

“Always inspect your changes before committing”

“Repasa tus cambios siempre antes de subirlos al repositorio”

Hazlo, no lo pienses. No te fíes ni de tu sombra. Al principio puede parecer una perdida de tiempo, pero es una de las costumbres que más agradezco. Porque soy despistado y humano. Por lo tanto me olvido que he cambiado algo que no quería subir o me equivoco en el código. Ese segundo vistazo me ayuda a eliminar muchos errores y problemas para mis compañeros desarrolladores.

“Remember the axe-murderer when writing commit messages”

“Recuerda al asesino del hacha cuando escribes tus mensajes de commit”

Y os preguntaréis quién coño es el “asesino del hacha“. Pues según el autor del artículo, existe un dicho que viene a decir lo siguiente: “Escribe tu siguiente comentario de commit como si el siguiente desarrollador que va a leerlo fuera un maníaco depresivo con un hacha que sabe donde vives”.

No lo cabrees, ¡por tu vida! Cosas como las que siguen probablemente lo pongan de muy mala leche:

#10 Mierda

#89 Fix tests

Opino que son dos ejemplos claros de pésimos comentarios para commits. Y eso que he escrito unos cuantos de esos, lo reconozco. El problema viene cuando tienes que volver sobre ellos porque estas revisando la historia de tu repositorio: te acuerdas del maldito día que naciste, os lo prometo.

Mucho mejor algo así:

#89 Fixing the first UI test to work better, introducing new concept ClassSetup and ClassTearDown

Y no vale currarse uno largo y reutilizarlo durante los cinco siguiente commits, cada commit tiene que ser diferente; se debe poder saber qué se ha hecho en ese commit con solo leer el mensaje. La diferencia cuando leas tu log será brutal.

Os recomiendo que os leáis el artículo de arriba a abajo, es muy bueno.

PS: He encontrado varios de los mandamientos en otra fuente, el libro Continuous Delivery. No pueden estar equivocados los dos, ¿no?

 

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

  • El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
  • El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
  • El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

  • Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
  • No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
  • Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
  • Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro. 🙂

Curso de Iniciación a Android en Walqa, Huesca

Si habéis estado atentos al blog os habréis dado cuenta que de arriba, al lado del Disclaimer ha aparecido una nueva sección de nombre “Formación“. No son necesarias demasiadas explicaciones ¿verdad?.

Esto no es nuevo. En Frogtek ya llevamos tiempo dado cursos de Android, pero hemos decidido hacerlo de forma un poco más continua y con el tiempo añadir nuevos cursos con los que nos sintamos cómodos (todos, sin falta, son cursos sobre cosas con las que trabajamos en el día a día).

En este caso ofrecemos un Curso de Iniciación a la programación en Android que vamos a dar en Walqa, estos son los datos:

  • Duración: 25 horas en 5 días.
  • Fechas: Del 26 al 30 de Marzo.
  • Lugar: Sala de formación de AST en Walqa.
  • Precio: 250€
  • Número de alumnos: alrededor de 12.
  • Temario: click aquí.
  • Inscripciones e información sobre el pago: mandando un correo a walqa@ptwalqa.com

¡Os esperamos!.

Feedback público todos con todos

Hacía tiempo que tenía pendiente escribir sobre el feedback en una start-up. El feedback sí, bueno, hablando en cristiano, cuando te dicen las cosas que haces bien y las que no tanto. Un ejercicio de sinceridad que es muy necesario si se quiere mejorar en cualquier entorno, ya sea el trabajo o alguna otra faceta de la vida. Necesario pero incómodo. No siempre resulta fácil que tu jefe o que uno de tus compañeros resalte esas cosas que haces mal ya sea en privado en incluso en público.

Es por eso que alrededor del feedback hay mucho… ¿cómo decirlo?, ¿artificio?, ¿tontería?. Una de mis favoritas es esa que dice que para dar una mala noticia primero tienes que dar dos buenas, luego la mala y acabar con otra buena. La técnica del ++-+ (sí, existe, no me lo estoy inventando a mi me la contaron en Vodafone aunque no he encontrado rastro de ella en internet) ó “cómo dar feedback negativo y que nadie salga herido“, imagino que las más de las veces la persona que recibe el feedback entre tanta cháchara no se entera del problema, sí de las alabanzas que lo envuelven y sale de la sesión sin entender nada. Da hasta para un chiste malo:

“Era un programador tan malo, tan malo, tan malo que en lugar de programar en C, programaba en C++-+”.

En fin, antes de que se me aplique directamente el lanzamiento de pomodoro, por el chiste, seguiré con lo del feedback. Al final todo se reduce a acudir a una reunión de esas con actitud constructiva tanto por un lado como por el otro, ser respetuoso y sincero.

El pasado Enero en Frogtek hicimos la primera sesión de feedback pública todos con todos. Consistió en lo siguiente, hacer una ronda en la que primero uno contaba de sí mismo cual era su rol en la empresa, que cosas se le daban bien y qué cosas se le daban mal. A continuación el resto del grupo hacía lo propio con la persona que había iniciado la ronda, es decir contarle cual pensábamos que era su rol, y cuales sus puntos fuertes y sus áreas de mejora. Al acabar la primera ronda una persona había recibido feedback de todo el resto de compañeros sobre su trabajo. Obviamente es importante que el feedback se traiga preparado de casa, ya que de lo contrario en seguida se cae en el “yo lo mismo que fulanito“. De hecho en Frogtek lo trajimos escrito en fichas de forma que al final de cada ronda la persona “objeto de análisis” se hacía con 7+1 (la propia) fichas con un buen surtido de ideas interesantes. Una vez recibido el feedback los “expertos” recomiendan tener a mano a SARAH y no, Sarah no es una encantadora señorita que nos consuele, si no las fases por las que vamos a pasar inevitablemente. A saber:

  • Fase 1: Shock “¿¡pero este tío qué dice!?”
  • Fase 2: Anger “¿¡pero este tío qué dice!?”
  • Fase 3: Resistance “¿¡pero este tío qué dice!?
  • Fase 4: Acceptance “mmmm
  • Fase 5: Help “oye tío, ¿me explicas cómo hacer eso tan bien?”

Después de un buen rato (hay que tomarse su tiempo, este ejercicio se lleva toda una mañana) y de las ocho rondas de rigor. Habíamos intercambiado 64 opiniones todos con todos en un ejercicio que, realizado con buen rollo, honestidad e interés (y con Sarah), resulta muy enriquecedor.

Además, para hacerlo todavía más interesante nosotros le pedimos a todo el mundo que se auto-clasificara y clasificara a sus compañeros de más identificado a menos identificado en las siguientes categorías (basado en el método de los 6 sombreros):

  • Orientación cooperadora (verde)
  • Orientación organizadora (azul)
  • Orientación emprendedora (rojo)
  • Orientación sociable (amarillo)

De forma que al final del día todos descubrimos cómo nos veíamos a nosotros mismos y cómo nos veía el resto del equipo. Afortunadamente en Huesca tenemos un equipo multicolor en el que no falta de nada.

Developing Frogtek Reloaded

Llevábamos unos meses sufriendo problemas de latencia en este blog, por lo que decidimos investigar el problema. Después de darle muchas vueltas, decidimos alojar el blog en un host dedicado.

Por ello, los visitantes asiduos habréis notado una mejora sustancial en la velocidad de carga de la web 🙂

¡Ah! También podéis notar esta mejora en nuestra web comercial: frogtek.org

Resumen del Global Day of Code Retreat en Aragón

El resumen es sencillo: lo pasamos muy bien.

Es toda una satisfacción ver como la gente responde ante eventos de estas características, y se puede juntar a 3o personas con ganas de aprender un sábado entero. Sebastián fue el maestro de ceremonias perfecto, proponiendo distintos retos cada vez más complejos e imaginativos. Creo que el que más gustó fue lo de hacer ping-pong programming en silencio.

También fue divertido contar con las dos programadoras más jóvenes de todas las localizaciones de este Global Day of Code Retreat y ver cómo alternan los pomodoros con el juego de la goma.

Os dejo un par de fotos del evento.

Hasta la próxima!

Teaser de Sebastián Hermida para el Code Retreat

Sin palabras. 🙂
Por si alguien tenía alguna duda,  lo pasaremos bien.

Teaser para el Global Code Retreat de Aragon 2011 from Sebastian Hermida on Vimeo.

El cambio comienza contigo

Henrik Kniberg autor de “Scrum and XP from the Trenches” publicó hace poco la presentación que realizó en el Tokyo Scrum Gathering. Me ha gustado mucho poder leerla y eso que son sólo slides, me habría encantado verla.

El cambio comienza contigo

Puede que no cuente nada nuevo, como suele pasar como estas cosas, pero me ha gustado  ver como él mismo aplica sus ideas a su familia y a su vida. ¡Y le funciona! Podéis verlo en la parte final de la presentación.

Tendré que hacerle caso y comenzar a cambiar 🙂

Antiguas entradas Recientes entradas