La semana pasada tuve la oportunidad de impartir un taller de Scrum en AdejeTec 2012, no es el tipo de formación al que estoy acostumbrado, pero utilizando la experiencia de algunos gurús, mi propia experiencia en el uso de Scrum día a día y poniéndole un poco de empeño, parece que salió bastante bien. Por esta razón voy a explicar que es lo que hice, así podrás decirme si se puede mejorar de alguna manera o tal vez quieras organizar tu propio taller. Te aseguro que es aun más divertido de lo que yo pensaba.

Tenía libertad total para el desarrollo del taller, por lo que no quería que fuese una clase magistral en la que yo hablo 2 horas y los asistentes se duermen al fresco del aire acondicionado. Desde el principio quería que fuese una actividad en la que todo el mundo participase y los conceptos fuesen surgiendo durante la ejecución, de esta forma se entienden mucho mejor.

Como es inevitable, comencé con una pequeña presentación, al fin y al cabo, ninguno de los asistentes conocía lo que era Scrum. Eso sí, la intente hacer en 15 minutos o menos, porque yo soy de esas personas que cree que la teoría de Scrum no es para nada compleja, en realidad es muy sencilla. Lo realmente complicado es llevarla a la práctica.


Durante la presentación se explican los roles involucrados en Scrum, las actividades y "artefactos" de Scrum y algunos consejos relevantes así como una breve bibliografía. De esta manera se rompe un poco el hielo, los asistentes hacen unas cuantas preguntas y se ponen en situación, facilitando el taller posterior.

La verdad es que aunque me encantan los juegos para mostrar conceptos, mi favorito es The Marshmallow Challenge, en mis fuentes habituales, como TastyCupcakes, no encontraba nada que me convenciera. Así que tocó googlear un poco y llegué a dos páginas que me parecieron muy interesantes.

• Play the Scrum Simulation (based on XP Game) de Michael Sahota
• Training excercise: Scrum simulation de Karen Graves

La idea de Michael Sahota de utilizar las tarjetas de XP Game como historias de usuarios me pareció fantástica, porque en 2 horas hay muy poco tiempo para que los propios asistentes escriban sus historias de usuario. Y por otra parte las historias descritas en XP Game son increíblemente simples y divertidas, se trata de actividades muy sencillas, o quizás no tanto, como inflar 10 globos de un determinado tamaño o hacer 5 barquitos de papel. Además ya tienen un valor de negocio asignado que me parece bastante apropiado porque hace plantearse a los jugadores que historias son más convenientes y cuales son muy complejas para el valor de negocio que aportan.

Historias de usuario y tarjetas de roles utilizadas

Como al taller solo fueron 7 personas tuve la oportunidad de hacer un único equipo y estar con ellos todo el rato, creo que esto influyó en que fuese tan bien. Así que después de entregar las tarjetas de los roles al azar, y tuviésemos nuestro Scrum Master, el Product Owner y los miembros del Equipo, les entregué el taco de tarjetas con las historias de usuarios. Durante los primeros 20 minutos crearon un Product Backlog priorizado y estimado, y prepararon el primer Sprint.

Se pusieron manos a la obra, y cuando acabaron se dieron cuenta que la estimación no había sido tan buena como creían. Cada sprint lo realicé de 4 minutos, tiempo que creo que es bastante bueno, ni mucho ni poco. Algunas tareas habían llevado mucho más de lo que creían y otras menos, pero no lograron completar tantas tarjetas como habían estimado.

El equipo trabajando al 100% para completar su sprint

Ningún problema, durante 10 minutos se planificó el segundo sprint y posteriormente lo ejecutaron durante 4 minutos. Como muchos habréis adivinado, en esta ocasión acertaron mucho más, ya tenían cierta experiencia. En el tercer sprint fue mucho mejor aún, y ellos mismos se iban dando cuenta de estos detalles y haciendo preguntas sobre la organización del backlog, el uso de prototipos o spikes para estimar en la siguiente iteración, auto-organización del equipo, etc.

Al final los tiempo elegidos estuvieron muy bien, 20 minutos para la planificación inicial, 10 minutos para cada planificación de sprint posterior, 10 minutos para cada revisión de sprint y 4 minutos para ejecutar cada sprint. Parece que puede sobrar mucho tiempo, pero no es así, primero necesitas dejar tiempo para una retrospectiva, y segundo necesitas responder dudas sobre el proceso que les van surgiendo poco a poco.

Conclusiones

Las conclusiones en un evento de este tipo siempre son subjetivas, pero creo que son unas buenas ideas de partida para mejorar la experiencia.

• Los asistentes me comentaron que posiblemente estaría bien llevar más documentación escrita, eso haría que la pudiesen consultar en cualquier momento y además serviría como apuntes para el futuro.
• En la retrospectiva detecté que hubiese sido interesante realizar algunas preguntas que les hubiese forzado a plantearse nuevas situaciones o problemas, de forma que surgiesen más dudas respecto al uso diario de Scrum.
• Mantener el proceso lo más simple posible y dejarles tomar decisiones hace que se esfuercen mucho y hagan sus propias preguntas. Siempre dentro de unos límites para que no se alejen de Scrum, al fin y al cabo primero tienen que aprender como funciona, antes de cambiar nada.
• Dejar algunas tareas definidas de manera poco específica hizo que al final de un sprint se dieran cuenta que quizás esa no era la solución deseada, eso está muy bien porque es algo que ocurre en la vida real continuamente.

Ideas

No lo tengo claro, pero quizás vosotros me podais dar una segunda opinión respecto a algunos temas.

• ¿Sería interesante aumentar el tiempo del taller para que los asistentes aprendan a crear historias de usuarios? Yo no tengo clara mi posición respecto a esta cuestión, aunque siempre he creído que las historias de usuario pueden ser un taller bastante largo por si solas. 
• El equipo en ningún momento creó tarjetas ni actualizó el scrum board durante la iteración, ¿habría sido interesante alargar el taller y que lo hicieran? Debido al límite temporal del taller decidí que dicha actividad no les habría aportado tanto como el resto, por lo tanto es algo que les expliqué y debatimos pero no se practicó.
• En vez de tener una única retrospectiva al final del taller, ¿sería interesante hacer una retrospectiva al final de cada sprint, teniendo en cuenta el coste temporal para el taller?

Hace ya algún tiempo que terminé de leer el libro Apprenticeship Patterns, y uno de los patrones que no he utilizado hasta ahora, entre otros muchos, es el denominado "Brekeable Toys". No se si es técnicamente lo mismo que un Pet Project o no, pero para mi se parecen lo suficiente.

No sabría como definir un Pet Project de forma académica, pero básicamente se trata de un proyecto personal, no comercial, en el que intentamos resolver un problema de un tamaño relativamente grande. Por ejemplo podemos implementar un blog, una wiki o cualquier otra herramienta que nos venga a la cabeza, su función principal es aprender. Al tratarse de un sistema que no están utilizando otras personas, podemos tomárnoslo con calma y cometer tantos errores como queramos, siempre que eso nos enseñe alguna lección. Incluso es aconsejable cometer errores y arriesgarse con el Pet Project, porque posiblemente no tengas dicha oportunidad en tu trabajo diario.


Personalmente veo bastantes ventajas en realizar este tipo de proyecto en nuestro tiempo libre.

• Practicar la base, sin prisas ni presión. Al no tener ningún plazo temporal podemos pasar un mes entero, o dos o los que quieras, leyendo sobre una determinada tecnología o implementando nuestro propio framework para usarlo en el Pet Project. Esto solo es añadir más trabajo al mismo, pero nos dará un conocimiento más profundo de las herramientas que utilizamos día a día en nuestro trabajo.
• Poder elegir la tecnología que desees. Es nuestro tiempo libre y no tenemos que rendir cuentas con nadie, por lo que podemos utilizar las herramientas que más nos gusten, alguna que no conocemos pero nos gustaría conocer mejor, o simplemente mejorar en las que ya conocemos pero tenemos más "oxidadas".
• Tendrás un "portafolio" que enseñar a tus clientes, en tus entrevistas de trabajo, etc. Es común que nos encontremos en casos en los que nuestros contratos nos impiden mostrar nuestro trabajo, ¿qué mejor que un Pet Project , o varios, para que nuestros futuros clientes puedan ver nuestro trabajo?.
• En unos pocos casos, el Pet Project se convierte en un producto "del mundo real" que utilizan otras personas e incluso que se puede monetizar. Pero no tengas esto en mente, son casos muy excepcionales.

Por otro lado hay una "desventaja" bastante evidente a la que recurren muchas personas.

• Has de utilizar tu tiempo libre para poder llevar a cabo dicho proyecto. Sí, así es, el conocimiento, como todas las cosas en la vida, tiene un precio, en este caso no es económico sino temporal. Que lo quieras pagar o no solo depende de tí, pero te aseguro que es posible compaginar tu vida privada con la realización de un Pet Project, siempre y cuando no trabajes más de 8 horas al día en la "oficina", claro.

En mi corta experiencia he recopilado algunos consejos que te pueden resultar de utilidad si quieres realizar un Pet Project.

• No es un proyecto comercial, así que ten calma, no te pongas fechas límite ni plazos. Si a tu novia (o novio) le apetece ir a cenar contigo, tus amigos te llaman para ir a hacer senderismo o simplemente quieres ver una película o leer un libro, ¡hazlo!. Trabaja en el Pet Project cuando realmente te apetezca.
• Escribe sobe tu errores, aciertos, cosas que has aprendido. Al fin y al cabo la razón de hacer un Pet Project es aprender y mejorar, por lo que escribir sobre ello te puede ayudar un poco más. Si además lo haces en un blog y lo compartes, ayudarás a más gente a parte de tí mismo, con lo cual mejorará tu karma :-)
• Elige un proyecto que te guste y pueda ayudarte en tú día a día, pero sin tener miedo de hacer cosas que ya existan. En mi caso personal, trabajar en una herramienta que yo mismo puedo utilizar me ayuda a mantener una mayor motivación. Por ejemplo, ahora mismo yo estoy trabajando en una pizarra de tareas compatible con dispositivos touch, como tablets, y que utiliza Jira como repositorio.
• No temas cometer errores. Investiga, toma decisiones arriesgadas que no tomarías "en la oficina", no vas a hacer daño a nadie y podrás sacar conclusiones muy interesantes.
• No des ningún paso sin entender profundamente lo que estás haciendo. En el día a día la presión es muy alta y tarde o temprano se toman decisiones sin tener todos los datos, ahora no tienes porque hacerlo.

Mucho se ha hablado sobre la reciente oferta de empleo de Atlassian y el proceso de selección que están llevando acabo, pero poco se sabe realmente de este proceso, razón por la que muchas personas están interesadas en conocer detalles. Y de eso mismo va esta entrada, de detalles sobre el Recruitment Roadshow de Atlassian. Eso sí, rociado de algunos pensamientos o reflexiones que me gustaría dejar por escrito para no olvidarlas.

El primer detalle que ya muchos saben es que yo participé en dicho proceso, y a la vista de la forma verbal que he usado, obviamente, no he pasado su code assessment. Las reacciones de la gente han sido muy diversas.

• Unos reaccionan con cara de asombro y pena, como si fuese un tremendo fracaso del que nadie se podría reponer. En serio, no pasa nada, es una oportunidad perdida, pero que me ha enseñado muchas cosas la verdad. Por otro lado, no es una cuestión de vida o muerte. Continúo trabajando para Avantic, en donde he sido muy feliz los últimos 4 años y medio y lo seguiré siendo a buen seguro.
• Otros han reaccionado de forma un poco menos sincera, y diría que ahora piensan que soy peor desarrollador que antes. Sinceramente sigo siendo el mismo ahora que hace 1 mes, no es la primera vez que suspendo un examen o no paso una prueba, ni será la última.
• Y por último los más cercanos a mi piensan - "Atlassian se lo pierde" - gracias chic@s. Sinceramente, no creo, seguro que encuentran a gente muy buena y preparada. Eso sí, sigo seguro de mi mismo y esta entrada en ningún caso intentará justificar el "fracaso", es algo que ha ocurrido y ha ocurrido porque no estaba suficientemente preparado, punto.

Pero bueno, no vamos a estar todo el día con esta sensiblería, vamos al turrón, a lo que la gente quiere saber, ¿cómo es el proceso?.

El comienzo de todo

En febrero de 2012, durante la fiesta de la Spring I/O organizada por Atlassian, anunciaron mediante su embajador en España la intención de contratar a 15 desarrolladores en Europa, y España es uno de los países por los que van a pasar. Si eso no hubiese sido suficiente publicidad, dicho embajador, más conocido por David Bonilla, empapeló la twitter-sfera con su entrada en el blog dando unos cuantos detalles más. Algunos un poco obscenos incluso :-P



Una vez anunciado, cada persona se lo plantea de forma totalmente diferente, pero después de darle muchas vueltas y con el apoyo incondicional de alguna que otra persona en especial (a quien agradezco su ayuda), decido presentarme. Total, como dijo David Bonilla, vivo en Canarias, ¿qué más da irme a Australia? ^_^

El resume y la cover letter

Para inscribirte en la oferta, tienes que tener preparada cierta documentación previa, llámese resume y cover letter. Algo muy similar al curriculum vitae, pero en cierta manera totalmente diferente. No soy un experto en este tipo de cosas, pero me documenté un poco y vi bastantes ejemplos para obtener este resultado. Lo peor de todo para un tornillo como yo, hacerlo en inglés :-S

Enlace a mi resume.

Enlace a mi cover letter.

Como se puede observar es algo un poco más enfocado al puesto exacto al que optas, y por lo que pude intuir, en la cultura anglosajona importa mucho las actividad paralelas que realizas, tu propio esfuerzo por mejorar y aprender, no solo el trabajo diario.

Una vez que tienes estos documentos listos, pues rellenas el formulario que Atlassian tiene preparado a tal efecto y te registras en el proceso. Inmediatamente te llega un mail de confirmación y a la mañana siguiente un mail de una persona de contacto en Atlassian, explicando los pasos que se seguirán y las fecha detalladas que llevará cada parte.

• Primero un code assessment.
• Luego, si pasas el code assessment, o así lo indican, se revisa tu resume, cover letter y otra información que hayas decidido enviar. Por ejemplo, se valorará muy bien que indiques repositorios de código con proyectos en los que hayas trabajado.
• Finalmente, si les interesas, se concertará una cita para una entrevista cara a cara de 2 horas.
• El resto, ya te lo imaginas :-)

Una pregunta que me han hecho recientemente es si los mails son respuestas automatizadas o no, no tengo ni idea, es posible que tengan un proceso automático, pero lo que es cierto es que siempre son enviados desde la cuenta de la persona responsable.

El code assessment

Aquí viene lo bueno, lo que todo el mundo quiere saber realmente. Antes de nada hay que aclarar que al menos hay dos pruebas diferentes, una para las solicitudes a desarrollador Java y otra para los de JavaScript. Tengo la sospecha de que incluso dentro de cada uno, hay más de una prueba, así que la experiencia de cada persona puede ser totalmente diferente a la mia.

Lo que yo esperaba es una prueba de código un poco más completa, un proyecto "real" a desarrollar durante un periodo de tiempo, algo similar a lo que solicita Autentia en sus entrevistas. Pero lo que realmente me encontré es una prueba más similar a un examen de certificación de Java. Aquí se puede debatir largo y tendido sobre si esto es mejor o peor, mi opinión personal es que no es la forma más directa de contratar talento, pero es una forma sencilla de verificar si la persona posee los "skills" que buscas.

En mi caso la primera pregunta era esta.



Puesto que Java utiliza UTF-16 como representación interna, la respuesta sencilla es 16 bit sin signo, pero hay un modificador de la JVM (-XX:+UseCompressedStrings) que permite usar un byte (en los casos posibles cuando se use ASCII puro). Por lo que la respuesta correcta imagino que es la que yo seleccioné, pero podría tener truco si nos ponemos tiskis-miskis :-) Según tengo entendido es raro una representación en memoria sin signo en Java, pero parece que para los char es así.

Tras ir contestando y enviando una a una, mi última pregunta fue esta otra.


No recuerdo que contesté en esta, es un poco comprometida, en principio todos los navegadores (más utilizados) entienden este bloque, pero su utilidad es indicarle al mismo el tipo de documento que viene a continuación. Dado que no pasé la prueba, no me hagáis mucho caso :-P

Vale, ¿y qué había en medio?. Pues tres preguntas de código y 7 más de elegir la respuesta correcta. Obviamente habían preguntas mucho más complejas, incluso relacionadas con el funcionamiento interno de la JVM. Respecto a las de código, dos de ellas eran asequibles, la otra me descolocó un poco. Aquí va.


Sencillo, ¿verdad?. Recorrido primero profundo con recursividad y ya lo tenemos. Aquí os dejo las clases que había que utilizar.

flatten/Couple.java
flatten/Either.java
flatten/FlattenTree.java
flatten/Function.java
flatten/Tree.java

Ahora os haréis una última pregunta. ¿Cuánto tiempo tienes para hacer esto?, pues todo el que tu quieras dentro del plazo indicado que era más de una semana, puedes parar cuando quieras y volver. Ellos estiman que la prueba es para aproximadamente una hora y media. Ahí reside uno de mis fallos, lo intenté hacer seguido y aunque no lo creas siempre es mejor tomar el fresco un rato, FAIL. Mejor hacerlo poco a poco y si tienes que pensar una pregunta más, pues lo haces, es mejor que contestar mal, mi otro fallo (obviamente) :-S A mi personalmente me llevó más de 3 horas en total.

Algunas personas me han preguntado, cuál es la puntuación de cada pregunta o cómo se evalúa, no tengo ni idea. Pasados unos días te mandan un mail indicando el resultado y en mi caso que no deseaban continuar con el proceso. Esa es otra cosa que me ha gusta mucho, sea automática o no, siempre te envían una comunicación, muy educada, informándote del proceso. Algo que nunca me ha gustado cuando he buscado trabajo aquí en España, si no están interesados en tí, ni un correo para decirte que te han descartado, con todo el esfuerzo que has puesto en ello, sobretodo cuando eres novato :-(

Conclusiones

Cada cual puede sacar conclusiones totalmente diferentes, las mias son las siguientes.

• Me guste más o menos el tipo de test, fallé y lo hice yo solito, no hay más donde buscar. Lo mejor, de todos esos errores puedes aprender cosas muy interesantes. Sinceramente, creo que la experiencia me ha hecho mejor desarrollador, aunque no tenga pruebas empíricas de ello.
• En este tipo de empresas es muy importante presentar código hecho por tí, un pet project o colaboración con proyectos de software libre que demuestren tus habilidades. No es nada nuevo y en Atlassian no son unos genios por saber esto, lo son por otras cosas, es algo que ya me dijo Xavi Gost que debo hacer. También lo puedes leer en Apprenticeship Patterns, en fin ya ireis viendo cual es mi próximo PetProject :-) (ya esta en marcha)
• Cuando tengas dudas, pregunta, en Atlassian también se pueden equivocar al desarrollar el test. Pero hazlo durante la prueba, al menos es lo que yo creo, no es ético hacerlo a toro pasado. Si cuando estas haciendo algo notas algo raro, confía en tu instinto ... aunque te recomiendo contrastes un poco tu instinto antes también :-P
• Sí, voy a seguir usando los productos de Atlassian en mi día a día, es una pregunta que ya me han hecho :-) ¿por qué iba a dejar de usarlos?, es una de las razones de que quisiera trabajar allí.
• Por último, no es la única oportunidad de tu vida, ¿realmente quieres trabajar en Atlassian?, están contratando como locos, presentate de nuevo, mejora, aprende y vuelve a intentarlo, no te ponen trabas al respecto ... eso sí me han indicado que el tiempo óptimo para notar una mejoría son 12 meses :-) Por otro lado no es la única empresa del mundo, es buena, pero hay otras igual de buenas.

Material de referencia 

Para aquellas personas que deseen saber como es el proceso de contratación en este tipo de empresas. Si alguien me envía más enlaces los colgaré aquí :-)

Enlace al blog de Jeff Atwood sobre su forma ideal de contratar programadores.