Sunday, June 28, 2015

Un generador de deuda técnica o el mito del x10

Por todos lados dicen que un programador muy bueno puede ser hasta 10 veces más productivo que uno malo...

Yo creo que la relación no es exactamente así sino que uno bueno puede ser dos o tres veces más productivo que uno normal y uno malo, en realidad no es que tenga una productividad muy baja o nula, sino que genera más deuda técnica y problemas del valor que aporta (código de muy mala calidad, muchos bugs, diseños malos y no entendibles).

Normalmente no nos atrevemos a decirlo, pero hay gente que no la quieres en tu equipo ni aunque vengan con un supuesto "coste cero". En estos casos, realmente prefieres que esté parado y sin tocar un teclado. Por lo menos que no haga el mal.

Es un generador de deuda técnica...


Por eso es tan importante conseguir crear un buen equipo que trabaje coordinado y con una visión común. En estos casos cualquier problema de generación sistemática de deuda técnica se detectaría de inmediato y se podría solventar.

Por cierto que los humanos solemos ser muy malos evaluandonos a nosotros mismos (ya sabes, aquello de que el 90% piensa que conduce mejor que la media)... :-)

Wednesday, June 24, 2015

AOS 2015 Gijón



Este fin de semana pasado se ha celebrado el  AOS2015 en Gijón. El AOS (Agile Open Space) es un evento organizado por Agile Spain y reúne gran parte de la comunidad ágil nacional para compartir experiencias durante un par de días.
El formato usado es Open Space que es una conferencia auto organizada por los propios asistentes en el mismo momento del evento.

En esta ocasión he tenido la suerte de compartir la experiencia con gran parte del equipo de producto de Alea Soluciones. Sólo nos ha faltado dos personas para ir el equipo completo. Quizás el año que viene podamos ir todos.

Como siempre, vengo enchufado, con nuevas ideas y lleno de energía. Además tal y como hemos comentado dentro del equipo, esta sensación es compartida, por lo que es un fantástico momento para realizar experimentos en la forma de trabajar como equipo y continuar con nuestro proceso de mejora continua.

Por aquí dejo algunas notas y reflexiones de las sesiones a las que asistí durante el evento (no me acuerdo muy bien del nombre de algunas de las sesiones):

  • Creo que era Money Driven Development, o algo así. (Marc Florit) Esta sesión me gusto bastante y me quede con algunas ideas para experimentar dentro del equipo y de la empresa. Se hablo de autoorganización, modelos de recompensa, motivación, escalado de la autogestión para temas como la retribución. Salieron modelos como el de Semco, el tema de cooperativas liquidas, Morning Star, etc
  • Desescalado Radical (Jorge Uriarte) Creo que esta es la sesión que más me aporto. Llevo ya un par de años intentando limitar de forma sistemática y consciente la cantidad de trabajo realizado, intentando centrarme mucho en cómo maximizar la cantidad de trabajo no realizado. Esta sesión trataba exactamente de eso. Jorge comentaba como acostumbrarse y acostumbrar al cliente a necesitar lo mínimo, dedicar mucho esfuerzo a tener un cliente y un equipo focalizado en lo esencial. También hablaba del roadmap con rutas de escape, cruces y decisiones (a tomar en el último momento responsable) (al estilo de Gojko Adzic). Me quedo con la idea de implantar dentro del backlog una zona limbo y limitar el backlog de una forma radical (total, si algo es importante, volverá a aparecer). Software como inventario a limitar y con un coste basal importante.
  • Ship it Motherfucker (@mikelodeon) Muy centrada en el pipeline de entrega de valor que tienen montado en beBanjo y como se centraban en aportar valor real al cliente en vez de en seguir un proceso "agile" de libro. Mi opinión lo que describió es precisamente un proceso ágil de libro, es decir, un proceso ligero (lean), centrado en aportar valor real al cliente a un ritmo sostenible en el tiempo y basado en una cultura de excelencia técnica y de motivación del equipo. Como ya he comentado en alguna ocasión yo considero que la agilidad tiene dos pilares principales, la cultura y las prácticas técnicas, y el proceso que presentaron era precisamente eso. Me quedo con lo bien implementado que tenían el flujo kanban y como todo el proceso se había optimizado de forma global para maximizar el flujo. Además siempre tiraban de los items desde el final del tablón (es decir desde la puesta en producción), vamos, un sistema completamente pull. También me resulto curioso que habían abandonado el Pair Programming por la fricción que se generaba al intentarlo hacer en remoto.
  • Finanzas personales ágiles (@mikelodeon) Fue interesante ver cómo se organizaba en este sentido. Actualmente en mi familia estamos introduciendo algunas prácticas ágiles (tablón kanban y retrospectivas) y creo que nos va ha venir muy bien algunas de las cosas que se comentaron en esta sesión.
  • Enseñando a Programar (@devscola y senpaidevs) Esta sesión me pareció muy interesante aunque no sea algo que vaya a utilizar a corto plazo. En cualquier caso es un tema que me interesa y en el que veo mucho esfuerzo  por parte de la comunidad, así que salí contento.
  • Equipos autorganizados SI… pero en equipos (https://twitter.com/xav1uzz). Supongo que el mensaje era cuestionarse todo, incluido la organización en equipos, pero no llegue a pillarle el punto.
  • Aterrizaje de proyectos (@ujue)  Me pareció una mezcla fantástica entre la inception y otra serie de prácticas. Me gusto bastante, lo que no tengo muy claro es si sabre aplicar muchas de las cosas que comento. En cualquier caso, seguro que algo de poso dejó :) 
Además, propuse algunas otras sesiones  y colaboré en otras que no había propuesto yo, pero que por distintos motivos me interesaban.
  • el eXPerimento (yo mismo @eferro) Explicamos como llevamos más de dos años haciendo Extreme Programming y como hasta ahora estamos muy satisfechos con esa forma de hacer las cosas. Se intentaba transmitir:
    • que es posible hacer XP
    • la velocidad es muy buena pero que necesitas superar la barrera de entrada inicial (por ejemplo contratando o trabajando con expertos)
    • hay que centrarse en aportar valor de forma completa, por lo que tiene todo el sentido hacerlo todo, desde hablar con el cliente hasta conseguir tenerlo en producción y que lo usen (eso incluye sistemas, desarrollo, etc... full stack de verdad :) )
    • que el desarrollo ágil de software es completamente imposible a medio largo plazo sin prácticas técnicas como las que te da XP (ver los dos pilares del desarrollo ágil).
  • Sesión de Diseño con DDD (@carlospeix) Se uso un ejemplo del grupo de ddd-es  para iniciar una conversación sobre el posible diseño de un pequeño modelo. Aunque fue interesante no estoy muy conforme con el resultado, puesto que el ejemplo hizo que nos centrásemos en el modelado estático (entidades y relaciones) del sistema y creo que eso es MUY peligroso (ver Verbos vs Nombres). Espero que por lo menos se transmitiese bien que hay que centrarse en el uso de un lenguaje ubicuo y que ese lenguaje debe ser el usado por los expertos de negocio y no ese lenguaje técnico que solemos obligarles a usar (CRUD, tablas, transacciones, etc...).  También espero que quedase claro que casi lo más importante es el concepto de bounded contexts puesto que sin eso DDD se puede convertir en una disculpa para hacer sesiones interminables de modelado (al más puro estilo diseño upfront de todas la vida).
  • El Rol del Product Owner (@AlbertodlCG y ??) Me acerque a esta sesión para echar una mano a @AlbertodlCG puesto que es nuestro Producto Owner / Product Champion y aun siendo su primer AOS le echo narices para presentar una sesión (bravo!!!). El caso es que al final se apaño muy bien así que simplemente me quede para disfrutar de la sesión. Me quedo con tres cosas:
    • resulta más complicada la comunicación con los stake holders que con el equipo de desarrollo (al contrario de lo que yo suponía). 
    • cuesta mucho hacer historias de usuario que realmente aporten valor extremo a extremo (mucha gente seguía haciendo historias de usuario del tipo "login", lo que impide hacer historias independientes que entreguen valor).
    • me quede con la sensación de que muchos de los product owners allí presentes no estaban muy integrados en el equipo y estaban en una situación que no les permitía centrarse en el producto. Por suerte para nosotros nuestra situación es muy distinta.
Estuve en algunas otras sesiones pero no me lleve ideas muy claras... sólo pequeños apuntes que tendré que rumiar. De alguna otra no me lleve nada o incluso un poco de miedo :) pero bueno, tiene que haber de todo.
También fue interesante la conversación con @francholab y Apa sobre Retrospectivas en equipos distribuidos de la que me llevo alguna idea de dinámica como la de la retro en silencio (y sólo por chat).

Conclusiones del estado de la comunidad ágil 

A veces creo que se nos olvida un poco que la parte principal o al menos la original es entregar valor mediante software, creo que no es lo único, pero si lo central.
Se tiende a pensar que sin prácticas técnicas y sin ser profesionales en el desarrollo se puede aportar valor de forma sostenida, pero mi opinión es justo la contraria. Si no tienes ni idea, lo más que conseguirás, incluso siguiendo todos los principios, es exponer ese desconocimiento rápidamente y de forma transparente, que no es poco, pero que no te librará de hacer un producto/proyecto de mierda (agilidad no es una receta para el éxito). Esto está muy alineado con la sesión de Scrot presentada por los maños (@dani_latorre y @nestorsalceda) :-)
Por cierto que hemos aprovechado el AOS para conseguir nuestra certificación de equipo Scrot :-)



Me voy con la pena de ver que no hay mucha gente (porcentualmente al número de asistentes) haciendo Extreme Programming. Creo que eso nos impide avanzar como comunidad y que hace que la agilidad para el desarrollo de software muchas veces se quede en buenas intenciones (sesiones sobre el Fracaso Agile, Scrot, etc...).

Conclusiones, retro, organización

Con respecto a la organización y al evento en si, tengo que decir que le doy un 9, me encanto....
Para conseguir el 10 hubiésemos necesitado más espacios sin sillas, más diáfanos y planos, para facilitar el debate.
En la retro comente que quizás con menos tracks podría generarse más debate o más mezcla en las sesiones. La verdad es que pensándolo ahora creo que no tiene sentido... Para eso un open space es auto organizado y ya tiene reglas para facilitar la mezcla de asistentes.

Muy buena idea la del photocall, me ha permitido sacarme unas cuantas fotos y pasármelo pipa viéndolas con mi peque de tres años :)
También nos hemos podido sacar alguna foto de equipo que está para enmarcar.

Además como soy de Bilbao, todo el entorno me hacia sentirme como en casa, así que este AOS puntúa doble.

Felicitaciones a la organización, lo habéis hecho de 10. Muchas gracias!!!!

Monday, June 08, 2015

More interesting Podcasts/Talks

It took me long time, but these are the most interesting talks I saw/heard the last month:

I'll try to rescue the frenquency of this kind of posts :-)