lunes, enero 18, 2016

Desarrolladores motivados

Todas las experiencias de equipos que consiguen un éxito sostenido a medio y largo plazo desarrollando software tienen un nexo común.... Da igual que hablemos de Extreme programming, engineer culture, programmers anarchy o incluso éxitos de procesos waterfall...

Siempre se habla de desarrolladores muy motivados guiados o involucrados en el negocio y centrados en la excelencia técnica y la calidad.

Dado que siempre el nexo es los desarrolladores motivados, quizas debamos centrarnos en eso, y lo mismo resulta que en ese caso funciona todo (waterfall, agile, caos, anarchy, etc...)


Por cierto, desarrolladores motivados no implica mesas de ping pong y consola de videojuegos. No conozco ningun desarrollador (profesional) que esté motivado si no genera valor o resuelve problemas reales...

lunes, enero 11, 2016

Cultura y XP nos funciona

Siguiendo con el tema de las prácticas y métodos que nos funcionan como equipo, voy a intentar describir la experiencia que hemos tenido en los últimos casi 4 años en el equipo de producto en Alea Soluciones creando desde cero un equipo ágil con una cultura fuerte y usando XP.

¿De donde partíamos?

Partíamos de una situación precaria en la que por diversos motivos no existía equipo de desarrollo y producto. Sólo quedaba yo y casi de forma casual. 

¿Cual era el camino?

  • Crear un equipo ágil con una cultura fuerte.
  • Apostar por un ritmo sostenible (basado en la calidad) XP/crasftmanship.
  • Para hacerlo, centrarnos en el crecimiento organico del equipo mediante la mejora continua (en todos los aspectos).

¿Cuales son las prácticas y costumbres actuales?

  • Buscamos un conocimiento compartido, luchando contra los silos, intentando usar un lenguaje ubicuo compartido con negocio y haciendo un esfuerzo explicito por entender nuestro negocio y las necesidades de los clientes.
  • Postponemos todo lo que podemos las decisiones, para lo que necesitamos una arquitectura ágil que vamos evolucionando junto con el resto del producto.
  • El equipo es casi completamente autónomo, autogestionado y contiene todas las capacidades requeridas (sistemas, automatización, desarrollo, producto, cultura, etc).
  • Desde el punto de vista más técnico:
    • Hacemos TDD por defecto en toda la aplicación, menos en las partes de la aplicación en las que no obtenemos suficiente ROI.
    • Trabajamos en Master directamente integrando de forma continua.
    • Usamos por defecto Pair Programming y Mob Programming tanto para desarrollo como para algunas otras tarea de sistemas. Algunas tareas no las hacemos en pareja, pero es la excepción no la norma.
    • Nuestra arquitectura nos permite y facilita todas estas prácticas (algunos microservicios, arquitectura hexagonal, etc).
    • El código pertenece a todo el equipo y lo puede cambiar cuando quiera. De hecho la obligación es siempre dejar el código un poco mejor de cómo lo encontraste.
  • Se hace trabajo remoto hasta tres días a la semana y se tiene un horario flexible.
  • Existe una profunda sensación de pertenencia al equipo y de responsabilidad por el producto.
  • Desde el punto de vista de proceso:
    • Hacemos retrospectivas periódicas que nos tomamos muy en serio.
    • No estimamos o estimamos lo imprescindible para coordinarnos (https://twitter.com/eferro/status/630830101006053376).
    • Blameless postmortems ante problemas (sobre todo cuando son en producción).
    • Daily meetings para coordinarnos y decidir parejas/tríos, etc (no como reporte).
    • Reunión cada dos semanas de coordinación/planning (1-2 Horas) con Operaciones y CEO.
    • Nos gestionamos mediante un Kanban con el WIP limitado y en cuanto algo está disponible desplegamos producción (usamos feature toggles para poder tener caminos de la aplicación escondidos o que sólo están visibles en ciertos clientes).
Vamos, que creo que tenemos una cultura ágil muy sana que también se ha expandido en cierta medida al resto de la organización, aunque en ese sentido todavía nos queda mucho por avanzar.
Desde el punto de vista técnico, hacemos una especie de XP con alguna herramienta de Scrum.

¿A qué nos referimos con que nos funciona / Medida de éxito?

El éxito es muy subjetivo, pero si lo tengo que resumir, me quedo con:
  • CEO y otros departamentos contentos con nuestro trabajo. (Solictamos feedback periódico)
  • Ritmo sostenible y mejora continua como equipo.
  • Económicamente funciona (y tenemos la deuda técnica siempre bajo control).
  • Vamos los lunes contentos a trabajar :)

Valores y notas finales

Estos son los valores que como equipo más apreciamos, aunque por supuesto, no son los únicos
  1. Empatía
  2. Colaboración
  3. Confianza
  4. Respeto
  5. Transparencia
Ver Valores Bifer

Podemos decir sin lugar a dudas, que apostar por XP y por una cultura ágil sana nos ha salido a cuenta. Por supuesto, esto no implica que en otro contexto, con otras personas, con otros valores hubiese funcionado aunque puedo dar muchos ejemplos de resultados muy mediocres cuando no se ha conseguido una cultura sana o cuando no se ha apostado por la calidad (prácticas técnicas).

Por cierto, esta forma de trabajar nos ha permitido atraer talento de forma inmediata cuando hemos necesitado crecer y ya se sabe que es algo más sencillo de decir que de hacer. Por no hablar de la facilidad de incorporación de un desarrollador a un equipo con prácticas de XP (pairing, mob, tdd).

Así que para mi, personas, cultura y calidad es la apuesta por defecto para los retos que me vayan surgiendo...

De forma sincera es el mejor equipo en el que he estado (cultura, aportación valor real, práctica técnicas, autonomía) y lo mejor es que mejora y crece de forma continua.
Se nota que estoy muy orgulloso de este equipazo, no?
Agradezco enormemente a todos los miembros del equipo, pasados y actuales y al resto de Alea haber hecho esto posible.
El producto es el equipo y todo lo demás es un efecto colateral

Otros Posts relacionados:




lunes, enero 04, 2016

Interesting talks from the craft conf 2015

These days I've finished watching all presentations Craftconf 2015, and IMHO these are the most interesting:

Equipos de desarrollo / No Rock Stars


No sirve el programador solitario. No sirve el "programador bueno pero..." (aka no trabaja en equipo).
Ni siquiera sirven las prácticas técnicas que te aporten individualmente pero que no sean compartidas con el equipo.

No existen desarrollos para una sola persona. Hace mucho que esto se convirtió en un trabajo de equipo, donde la colaboración, comunicación y la empatía son MUCHO más importantes para el resultado final que las capacidades individuales de cada miembro del equipo.

Teniendo en cuenta esta premisa, me sorprende que muchos de los debates sobre las prácticas técnicas en metodologías ágiles se centran en si a cada UNO le funcionan o no. Eso no tiene importancia, lo importante es si al EQUIPO le funcionan o no. De forma individual, cada uno tenemos que conocer las prácticas técnicas para poder usarlas dentro del equipo.
Muchas de las prácticas técnicas de XP (extreme programming) están orientadas a crear equipos de alto rendimiento. En especial el "Collective Ownership" y el "Pair Programming" o actualmente el "Mob Programming", fuerzan la colaboración, comunicación y la empatía.

En esta profesión NO se necesitan Rock Stars, ni Ninjas, ni Magos... Se necesitan EQUIPOS (mínimo parejas) profesionales, que dominen las herramientas y prácticas que les funcionen y que sistemáticamente traten de mejorarlas o aprender nuevas.



lunes, diciembre 21, 2015

Felicidades (me voy de vacaciones)

Feliz solsticio de invierno para todos

Para los ateos: Felices días de Vacaciones.
Para los cristianos: Felices Navidades.
Para los satánicos: Lo siento tíos.... a soportar otras Navidades.
Para el resto: Felicidades sin especificar.


jueves, diciembre 17, 2015

Book Review. The Phoenix Project. Gene Kim


The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

Entertaining and instructive. The cult novel for the DevOps movement. It have a very ops related point of view, but is also very interesting for the software development, in fact, nowadays there is no so much difference.

Great book with lots of information on the development of Lean and DevOps software and great lessons on how to implement it.
I'm not used to this format for a highly technical book, but I must admit that a novel is a very good way to remember the concepts (and even, to empathize with the characters).

Recommended for anyone in a business with a strong technology base (almost every business today).

Very funny, entertaining... A must...

https://www.goodreads.com/book/show/17255186-the-phoenix-project