Archivos de Categoría: Blog

Cuando ponemos una nueva features en producción o liberamos nueva release, aparecerán inevitablemente algunos errores de cuando en cuando. Si no los solucionamos sino que seguimos desarrollando nuevas features, seguirán habiendo un porcentaje nuevo de bugs. Llegará un momento en el que dedicaremos más tiempo a poner parches y solucionar errores urgentes en producción que a desarrollar nuevas features o historias de usuario, que es lo que mantiene a nuestro producto en el mercado.

Si llegamos a una nueva empresa, revirtamos esa tendencia. Enfoquémonos en solucionar deuda técnica eligiendo una lista de los principales dolores de cabeza y dediquemos un par de historias de usuario cada sprint a solucionarlas. Una vez solucionado, ataquemos el siguiente problema según el tormento que nos cause.

Cuando haya pasado un tiempo veremos que ya no hay tantas llamadas urgentes, que los desarrolladores no están todo el día apagando fuegos y tienen disponibilidad (además de concentración, foco, y menos interrupciones) para desarrollar nuevas funcionalidades, que ahora sí, aportarán valor al producto.

Pasado un tiempo, confiemos en que no mucho, deberíamos ver una gráfica como esta (si no la tienes, deberías creártela, te podría sorprender lo mucho que estás dedicando a waste, en lugar de a nuevo valor).

Mark Twain dijo una vez: si tu trabajo es comerte una rana, es mejor hacerlo a primera hora de la mañana. Y si tu trabajo es comerte dos ranas, es mejor comerse la más grande primero. Si quieres ser productivo y no dejarte las cosas esenciales detrás, haz las cosas más importantes o difíciles primero. Verás si eres capas, si el proyecto es viable. Luego tienes el resto del día (o del proyecto) libre para mejorar y con la tranquilidad de haber resuelto los principales problemas primero.

Al principio de la mañana, el proyecto o de la tarea, estás más despierto, más animado, más concentrado. Todavía tienes recursos por delante para reaccionar si es más difícil de lo esperado o se requieren otras acciones. Al final el mismo, estarás comprometido con las fechas de entrega, más estresado y con más prisas. No harás las cosas importantes bien o las dejarás a medio cerrar. Puede sucederte como en ese clásico meme de las redes sociales en las que se ven los cuartos traseros de un caballo dibujados con gran exactitud y precisión, pero a medida que el dibujante avanza hacia la parte delantera, debido a la presión por entregar, va eliminando trazos y simplificando los detalles hasta entregar solo una caricatura de la cabeza del caballo.

Siempre hay cosas en el trabajo que nos resistimos a hacer. Son más difíciles, requieren de más dedicación, o tenemos miedo de hacerlas mal y que seamos criticados por ello. Asegúrate de que en el equipo de trabajo hay «coraje» para enfrentarse a ellas y acometerlas de una vez. Coraje, entendido como en Extreme Programming, surge donde se ha creado un ambiente en el que no hay miedo a ser castigado o criticado por cometer un error.

A todos nos cuesta comernos las «ranas» de nuestro trabajo. Es algo completamente normal. ¿No has visto alguna vez, que cuando en el backlog hay diversas tareas y una de ellas es un trago más amargo que las demás, todas las historias de usuario se terminan excepto la más compleja? Pasará una y otra vez al siguiente sprint casi sin tocar donde volverá a suceder lo mismo con las nuevas tareas añadidas. Hasta que no eliminas las «distracciones» y los hitos fáciles de conseguir del sprint backlog, no conseguirás que se decidan a atajar el problema.

Una vez has acabado con sapos y culebras, todas las nuevas tareas en tu To-Do list te parecerán un plato mucho más fácil de digerir.

Hace algún tiempo quería actualizar un poco mi CV. Llevaba un par de años de añadir nada significativo y creo que todos debemos ir mejorando poco a poco nuestros conocimientos y habilidades. Si no me equivoco, era Asimov el que decía «Education isn’t something you can finish«. Por otro lado, los recruiters tienen lo que ellos llaman «un detector de gente poco motivada» y si ven perfiles que llevan dos años al paro sin hacer nada o actualizar su inglés, quizás consideren que vas a mostrar el mismo poco entusiasmo por aprender o mejorar en un nuevo puesto.

Me decidí a no hacerlo a tontas y a locas, y sumar el enésimo curso de introducción a Inteligencia Artificial o Ciberseguridad. Traté de realizar un estudio para ver qué conocimientos, certificados, o frameworks eran los más demandados en las ofertas de trabajo Indeed, LinkedIn o Glassdoor. También pregunté a varios colegas por la skill que me hiciese más valioso en una entrevista de trabajo. Después de repetir el estudio varias veces llegué a las siguientes conclusiones: en primer lugar debía mejorar mi inglés, tras eso, insitir con el inglés, y por último continuar mejorando el inglés. Todos los caminos me llevaban a que esa era la habilidad más demandada para mis circunstancias (y probablemente para la de muchos).

A lo largo de mi vida profesional, he tropezado varias veces con este idioma: en mi primer trabajo con clientes alemanes, el segundo ingleses, luego han venido americanos, suecos o luxemburgueses (en la mayoría estaba trabajando desde Canarias). No lo habría pasado tan mal intentando chapurrearlo si el inglés hubiese sido mi prioridad desde hace un par de décadas, además del gran número de puertas que se me habrían abierto a trabajar con salarios europeos.

Si realmente quieres marcar la diferencia, estudia inglés. Apúntate a alguna de las escuelas oficiales de idiomas que tenemos repartidas por las islas (y por el resto de España). En casi cada pueblo grande hay una sede abierta para estudiar por las mañanas o por las tardes, y por alrededor de 74€ al año puedes tener clases dos veces a la semana con profesores de alto nivel. Además podrás certificarte al final del curso en alguno de los niveles del marco europeo de referencia de las lenguas (A1, A2, B1, B2, C1 y C2). Certificados que, por otro lado, son muy valorados en el sistema de puntuaciones de múltiples oposiciones a gobiernos y ayuntamientos.

Ten en cuenta que los certificados no son lo más importante. Suponen un hito y una prueba de nivel que hará que te esfuerces para llegar a estar a la altura. Quizás incluso te consiga alguna entrevista si el recruiter ve tu certificado en el CV, pero será realmente en la entrevista donde tendrás que demostrar que entiendes y te haces entender bien. Y si no hablas el nivel requerido para el trabajo, ya puedes tener un C2 en tu currículum, que no serás contratado (ten por seguro que un hiring manager en una empresa americana o irlandesa no sabe qué carajo significa «C1». Él o ella solo sabe hablar inglés).

Para niveles altos, las 150-175 horas anuales de la EOI no son suficientes. Tendrás que complementarlas:

• Viendo series de televisión en inglés en cualquiera de las plataformas online (Netflix, HBO, Prime Video).
• Viendo la televisión o noticias en canales extranjeros (TVMucho).
• Escuchando la radio o podcasts (RadioGarden, BBC Sounds).
• Leyendo todo lo que puedas en el idioma de Shakespeare (si es posible, lee en alto para practicar la pronunciación). Compra todos tus libros en la versión original, y no en su traducción al español.
• Seguramente necesites encontrar un profesor particular para las clases de conversación (la asignatura eternamente pendiente para los hispanohablantes) y qué más difícil es de practicar por tu cuenta. Puedes probar en preply.com o encontrando alguna profesora online que te ayude y te cobre por sus clases a través de Zoom o similar.

Ánimo. Poco a poco todo te irá sonando. Lleva años y mucho esfuerzo mejorar el inglés, pero no abandones el curso de la EOI en diciembre, cuando se acerquen los primeros exámenes y se te haga cuesta arriba. Insiste que merecerá la pena. Persistence is paid off!

Hoy recibo una notificación de Google Alerts indicando que Amazon está mostrando mi libro, Gestión práctica de proyectos con Scrum, en la posición número 64 de los libros (ebooks y libros convencionales) más vendidos en la categoría de Internet y Web. Además está en la posición número 10 en ventas para la clasificación de ebooks sobre Programación y desarrollo de software.

Muy contento de que, después de más de siete años de haber sido publicado, siga alcanzando buenos puestos en la lista de ventas, pero aún más contento de las 288 opiniones y comentarios que el libro tiene. Leerlos siempre me supone un subidón de ego, pero hoy aún más al saber que el libro forma parte de la bibliografía de una de las asignaturas de la Universidad de Buenos Aires, una universidad con más de 200 años de experiencia formando a sus alumnos.

Aquí algunos de los ejemplos de las reseñas del libro:

Hablábamos la semana pasada de cómo entregar tu trabajo para ser revisado, curado, y hasta vapuleado por tus compañeros de equipo, logran grandes piezas de código. Líneas de texto que formarán parte de módulos capaces de resistir casi una década sin generar errores.

Vuelvo esta semana a comentar sobre el concepto de egoless programming de Gerald Weinberg y otro de los ejemplos reales de su libro: el incorruptible equipo de 10 programadores en una empresa aeronáutica.

Se trataba de un equipo que rechazó mudarse cuando su empresa anterior cerró sus instalaciones en la zona para moverse a otro lugar del país. Aunque tenían buenas ofertas individuales, ellos decidieron irse solo con quién los contratase a los diez a la vez.

Fue una el departamento de desarrollo de una empresa de fuselajes de avión la que los contrató y allí continuaron trabajando un tiempo. Cuando el director de desarrollo de esta empresa se encontró en una conferencia con el antiguo mánager de este grupo, le preguntó extrañado: «¿De dónde sacaste a esta gente? ¿Tienes a más gente como ellos? ¿Cuál es su secreto?». Le explicó que siempre que necesitaba que algo se hiciese bien y a tiempo, solo tenía que encargárselo a uno de estos diez. Deben ser algún tipo de genios, exclamó.

Nada había de particular en ellos, le contó, una de ellas era una recién graduada en italiano, otro había enseñado matemáticas en un instituto, un tercero era un ingeniero profesional y otra más se graduó en empresariales, trabajando después como secretaria ejecutiva y contable.

No eran seres sobrenaturales, simplemente, cuando uno de ellos recibía un trabajo, los diez trabajaban sobre él y lo revisaban entre todos hasta dejarlo perfecto. Cuando trataron de explicarle sus métodos, su nuevo mánager entendió que solo uno o dos hacían todo el trabajo y protegían al resto, que quedaban escondidos detrás de los genios de verdad.

Este director no fue tan obtuso como para llegar a disolver este grupo, pero no supo ver la eficacia de estas técnicas, y mucho menos aplicarlas al resto de sus 300 programadores. Un tiempo después estos diez programadores se volvieron a mover, otra vez en bloque, a una empresa más comprensiva con sus métodos.

Apuesta por los pull request, el pair programming, collective ownership, peer reviews y por los tests por todo el equipo. Es una de esas inversiones a largo plazo que se verán recompensadas cuando poco a poco empiezas a salir del caos, las prisas y de las llamadas de clientes enfadados por un bug en producción.

Si quieres saber más sobre egoless programming, echa un vistazo a mi post de la semana anterior: Programación sin ego.

Referencias:

• The Psychology of Computer Programming por Gerald Weinberg, Nueva York, Van Nostrand Reinhold, 1971.