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.

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

Book Review: How Google Works. Eric Schmidt

This book contains some interesting facts about how Google, as a company, works, but IMHO only the first half is interesting, the rest is a bit repetitive.

The book contains many anecdotes, but many of them are not interesting or simply repeat a concept already discussed previously.

Entertaining but I have not learned as much as intended.





https://www.goodreads.com/book/show/23158207-how-google-works

talks/podcast recomendations

This are my latests talks/podcast recomendations:

• Agile Revisited Dan North An updated version of the agile manifesto and principles (creative individuals, feedback loops, continious delivery, devops...)  A clear message about agile very far away from the Agile/Scrum/NoSense (tm). Real Agile...
• Hackers, the internet's immune system Keren Elazari
• Managing Containers at Scale with CoreOS and Kubernetes Kelsey Hightower The question is... how you design your infrastructure when you can't ssh to the servers? Part of the answer is in this talk :)
• SE-Radio Episode 238: Linda Rising on the Agile Brain An interview with Linda Rising about the Agile/Grow/Experimentation mindset. 

Enjoy

Podcasts/talks. Emptying the queue (III)

I continue empting the talks queue... Here is another small batch of interesting talks:

• Microservices: Software that Fits in Your Head Dan North. IMHO this is the more interesting talk I show this year. No spoilers :)   I agree one hundred per cent with the talk. Just show it.
• Functional_Data_-_Greg_Young-131636650 Greg Young. A practical example of the Event Sourcing implemented using a functional approach. With this approach the flow seems more easy than the OOP approach.
• se-radio-episode-234-barry-oreilly-on-lean-enterprise. A interesting interview about the book Lean Enterprise and the application of Lean and Agile principles to drive innovation and product creation at our "disruptive" era.
• Testing and Refactoring Legacy Code Sandro Mancuso. A very interesting refactoring session  conducted by Sandro. Lot of tips and tricks, some for Java and other for a lot of contexts and languages.
• RailsConf 2014 - All the Little Things Sandi Metz. A good session about OO design, refactoring and complexity using the GildedRose kata. Every Sandi's presentation is a learning experience. 
• No Estimates, Let's Explore the Possibilities Woody Zuill. A good and deep thoughts about the convenience of the estimates... The cost, the value... can we live without them?
• Principles of Microservices Sam Newman. A good presentation about microservices, some of the use cases, the dificults for the adoption and the relation with the DDD movement.
• Back to the Future: What Ever Happened to Being eXtreme? Rachel Davies. A interesting talk about their experience using and adapting XP. They drop some practices, adapted other and introduces new ones, but always without losing the XP exence. 

Podcasts/talks. Emptying the queue (II)

I continue empting the talks queue... Here is another small batch of interesting talks:

• Stroop, Whorf, And Elixir Dave Thomas. Interesting info about how the language we use shape our thinking process and the importance of learning very diferent programming languages.
• Why Everyone Needs DevOps Now: A Fourteen Year Study Of High Performing IT Organizations Gene Kim. Interesting examples about high performing IT organizations (importance of development + operations, continuous deployment, flow center process, etc).
• Testing the Hard Stuff and Staying Sane John Hughes A good aproximation to automatic check/testing for concurrent stuff (QuickChecks). Examples with the erlang version.
• Evolutionary Architecture and Microservices Rebecca Parsons.Informative talk about microservices and the Continuous Delivery as the central practice that allow the constant evolution of the apps and real agile development.
• Building Event-Driven Microservices with Scala, Functional Domain Models and Spring Boot Chris Richardson. A interesting and practical example of to create small independent services with event sourcing and CQRS. A Good explanation.

Coste basal del software vs capacidad infinita

En mi opinión, el coste de desarrollo por cada grupo de funcionalidades se puede dividir de la siguiente forma:

• Coste inicial de desarrollo
• Coste de existencia (coste basal):
• Coste de existencia / complejidad añadida
• Coste de existencia para otras funcionalidades

Coste inicial de desarrollo

Este es el coste/gasto en el que incurre el equipo durante el desarrollo inicial de la funcionalidad. Incluye desde que el equipo comienza a trabajar en la funcionalidad o grupo de funcionalidades hasta que el cliente la tiene disponible y comienza a usarla. Por supuesto este proceso debería incluir múltiples puestas en producción para ir obteniendo feedback y realizando los ajustes necesarios...

A partir de este momento, comienzan a producirse de forma continua y hasta el final de la vida de la funcionalidad o del producto, un coste de existencia o coste basal.

Coste de existencia o Coste basal

Este coste, continuado en el tiempo y que solo termina con la retirada de la funcionalidad o el fin de la vida del producto, es el coste en el que incurre el equipo por la existencia de ese código y esa funcionalidad en el producto.
Es importante tener en cuenta que este coste no se refiere al coste de realizar modificaciones a la funcionalidad o corregir errores, se refiere al coste que conlleva simplemente que el código esté ahí...

¿Por qué se produce este coste?

• El equipo tiene que conocer ese código (dónde está, qué dependencias tiene, con quien interactua, cómo está escrito...)
• El conocimiento y técnicas del equipo están en continua evolución. Cuando el equipo mejora en alguno de estos aspectos tiene que decidir si actualiza el código de la funcionalidad, si lo hace es un coste, si no lo hace, también puesto que será diferente que el resto de código de que dispone.
• Cuando aparezcan nuevas funcionalidades se debe ver dónde impactan y no es lo mismo tener que identificar esos impacto en una aplicación de un tamaño X que en una de un tamaño X más el tamaño de la funcionalidad.
• Lo mismo pasa cuando entra un nuevo miembro del equipo y tiene que conocer la base de código que existe.

Y lo peor de todo es que este gastos es continuo hasta la "muerte" de la funcionalidad, es decir el fin de vida del producto, hasta que no la use ningún usuario o hasta el fin del mundo (lo que sea que ocurra antes).

Además, si se sobrepasa el punto de obsolescencia tecnológica (versión de lenguaje obsoleto, dependencias que desaparecen, etc) antes de la "muerte" de la funcionalidad el coste de mantenimiento se dispara y podemos entrar en una situación en que la capacidad del equipo quede ocupada al completo intentando mantener bajo control funcionalidades que ya han pasado el punto de obsolescencia tecnológica.

En mi experiencia, siempre me he encontrado que este coste se obvia y tanto los desarrolladores como los clientes y managers simulan que no existe, tomando decisiones (sin sentido) que no lo tienen en cuenta.

Capacidad no infinita

El problema es que la capacidad de un equipo de desarrollo no es infinita y aunque cambia (en positivo o negativo) con el tiempo debido a distintos factores (el conocimiento del negocio, de las técnicas...), existe una tendencia clara a que la capacidad usada en el coste basal de las funcionalidades ya hechas vaya mermando la capacidad disponible para nuevas funcionalidades.

Coste acumulado

Por tanto de forma general, independientemente de la calidad del software desarrollado, poco a poco la capacidad disponible de un equipo para nuevas funcionalidades disminuye con el tiempo.
Si el equipo desarrolla sin usar buenas prácticas y sin alta calidad, este colapso es prácticamente inmediato en el caso de tener muchos bugs o en unos pocos meses cuando aún no teniendo muchos bugs la calidad interna del software es baja.

Si el equipo es bastante bueno y se preocupa por la calidad esta tendencia será muchísimo menos pronunciada y se podría tener una capacidad "razonable" para nuevas funcionalidades durante años, pero por supuesto poco a poco iría disminuyendo y a la larga desaparecería.

A lo largo de los años las estrategias que he visto para lidiar con este problema son:

• Ignorarlo y esperar al colapso.
• Hacer crecer de forma constante tu equipo para mantener una capacidad para nuevas funcionalidades constante (este enfoque es el que parecen tener empresas de tecnología puntera que crecen en ingenieros de forma constante; google, amazon, netflix, spotify ...)
• Crear equipos de mantenimiento a los que pasar el producto despues del desarrollo inicial (por supuesto esto es similar al punto anterior).

Claramente este problema sólo afecta a los departamentos de desarrollo interno o a los equipos de desarrollo dedicados a producto. Para el caso de consultoras o equipos que trabajan en proyectos este tipo de problema no les afecta puesto que pasado el desarrollo inicial se suele entregar el proyecto y el mantenimiento es problema del cliente.

La solución

Y ahora viene cuando planteo la solución que he encontrado....

Pues no, no tengo ni idea de cómo solventarlo, como mucho se retrasar las consecuencias del problema, minimizarlo, pero no solventarlo.

Me encantaría opiniones sobre como tratar a medio largo plazo este problema. Lo único que se me ocurre es el crecimiento continuo de equipo o tener una política de "end of life" de los productos muy agresiva.

Se aceptan sugerencias, experimentos, opiniones, cualquier comentario será bienvenido.

Podcasts/talks. Emptying the queue (I)

I have a long queue of interesting talks, so I'll post the talks links in small batches. Here come the first one.

Interesting Agile/Lean related talks:

• Competing On The Basis Of Speed  (Mary Poppendieck)  Optimizing for speed, flow, and waste reduction. Lean Software Development
• The role of leadership in software development (Mary Poppendieck) Good talk, full of good advices.
• The Power of an Agile Mindset  (Linda Rising) Very good talk about the "Agile" mindset (aka experimentation or growth mindset)
• Experimentation Mindset (Michael Norton) Acomplement for the Linda Rising talks. Continious learning, experimentation Mindset, double loop learning, ...
• Curing Agile Hangover with Craftsmanship (Sandro Mancuso/Masook Badar) Story about the real agile process of continuous improvement, professionalism. No more "scrum but" agile :)
• The Nature of Software Development  (Chet Hendrickson / Ron Jeffries) Interesting talk with the same subject/ideas described in the Ron's book (with the same tittle). Current state of Agile and Agile's good ideas in a real context of common Agile misunderstandings.

Other development/systems related talks:

• Protocols - The Glue for Applications  (Torben Hoffmann) Very interesting, distributed systems, fault tolerant and the desing process for this kinds of systems (full of advices from the Erlang community).
• Keys to SRE (SREcon14)  (Ben Treynor) Good description about the term/role of SRE (from the google perspective).

When I empty the talks queue, I'll try the generate this kind of entries more often...

Ultimo post de la PiWeek VIII

El último día de la PiWeek es una mezcla de nervios para  algunos y de ambiente festivo... La verdad es que en toda la semana me lo paso muy bien, pero el viernes es el día más divertido.

Algunos equipos controlan mejor que otros los nervios y son capaces de trabajar en el proyecto hasta el último minuto, yo no soy de esos y siempre prefiero trabajar con margen y dejar las cosas cerradas el día anterior.

Durante un rato  estuve preparando la demo, aunque no había demasiado que hacer.
Luego comente las notas que tenia del libro ClojureScript Unraveled e incluso creo que Andrey ya comenzó a hacer ciertos cambios a partir de ese feedback.

También tuve algunas enriquecedoras conversaciones, principalmente con David, sobre el coste real de una funcionalidad cuando se trata de un producto software y no de un proyecto que se transfiere a un cliente. También comentamos como hacíamos en Alea Soluciones para poder desplegar con un buen ritmo en nuestras aplicaciones. Le comenté como usaban feature toggles la gente de etsy y de facebook para poder tener un tren continuo de despliegues a producción.

Espero que David me tenga informado de si alguna de las cosas les ha ayudado a mejorar :-)

Sobre la una de la tarde llego el climax de la PiWeek... las presentaciones... como en otras ediciones, las siguientes dos horas y media fueron de presentaciones de unos 10 minutos por proyecto.
El ambiente fue de completa fiesta y de asombro por la calidad de todos los proyectos.

Es una mezcla de fiesta geek, nervios por hacer la presentación del proyecto en el que te has dejado la piel durante esta semana y de tomar notas para investigar las cosas que han hecho en otros proyectos.

Hay que tener en cuenta, que no hablamos de presentaciones powerpoint o equivalente... hablamos de código funcionando o diseños, algo real, palpable, nada de documentos de buenas intenciones...

Todos los proyectos tienen un nivel impresionante, pero lo que más me ha impresionado es el proyecto uxbox, realizado en clojure script. Además de lo bien y fluido que queda el interfaz de usuario, la velocidad de desarrollo que han tenido ha sido impresionante, sobre todo teniendo en cuenta que varios de los miembros del equipo eran la primera vez que trabajaban con ese lenguaje.

Como otras veces, me he quedado impresionado por todo lo que tiene que ver con Frontend, UX, diseño y similar. Toda mi experiencia ha estado siempre centrada en software que no ha requerido parte visual importante (sistemas industriales, backends, telecomunicaciones, retail, ...) así que siempre alucino con los proyectos de la piweek (se nota la experiencia acumulada en software muy visual). En especial en estos temas, me han impresionado Guild Empire, Zombie Time!, Baoqu, Mineralis, etc..

Cada PiWeek es distinta y en cada edición consigues más o menos avances personales, noto que esta edición, junto con la primera a la que asistí, son las que más han aportado a mi avance personal como desarrollador.

Así que otra edición más, reto conseguido...

Referencias:

• http://piweek.tumblr.com/
• http://www.piweek.com/
• http://www.kaleidos.net/
• hashtag piweek
• http://www.eferro.net/search/label/PiWeek

PiWeek edición VIII (Cuarto Día)

Aunque lo escribo con retraso, este post corresponde al cuarto día (jueves) de esta edición de la piweek.

En el proyecto eventsview avanzamos hasta dejar una versión usable con búsqueda y los filtros activados. Estoy bastante contento, por que aunque no es nada vistoso nos va a valer como base para desarrollos que tenemos que hacer en Alea y que poco a poco voy cogiendo flujo en javascript y en la parte web. Hay que tener en cuenta que en mi día a día no suelo tocar para nada web, por lo que sólo puedo avanzar en este tipo de cosas con proyectos personales, así que algo como la piweek para mi es un "acelerador" para mi aprendizaje.
Una vez más, los consejos sobre usabilidad que  nos ha dado Esther han servido para hacer la interacción con el usuario mucho más sencilla.

En cuanto a expects ya conseguimos tener todos los tests en verde y Jaime se encargo de generar una nueva versión release candidate y de actualizar doublex-expects que depende de expects.

Expects 0.8.0rc1 is out with new and more descriptive failure messages https://t.co/bZXAzFW9Sy #piweek #tdd #bdd #python #testing cc @eferro

— Jaime Gil de Sagredo (@jaimegil) July 17, 2015

Como mis objetivos para la PiWeek eran darle un empujón a mi aprendizaje de javascript, disponer de una base para desarrollar un visualizador de eventos y ayudar a Jaime a generar una nueva versión de expects, la verdad es que para el jueves a media mañana los objetivos estaban cumplidos...
El truco como siempre es tener unas expectativas bajas y gestionarlas bien ;-)

El caso es que a partir de ese momento me dedique a investigar cosas que me parece que a medio plazo pueden resultar muy interesantes.
Entre otras cosas estuve trasteando con react y creo que puede tener su sitio para crear partes del frontend reusables para la arquitectura de servicios que estamos desarrollando en Alea Soluciones.

También curiosee con clojurescript y la verdad es que me pareció impresionante las cosas que se pueden conseguir. En este caso, creo que si ahora mismo quieres aprender algo sobre clojurescript, tu sitio es la oficina de kaleidos.
En concreto repase un capitulo del libro de  Andrey Antukh y Alejandro Gomez,  ClojureScript Unraveled y tome algunas notas para poder enviarles feedback y pequeñas correcciones.
También trastee con ayuda de Alonso hasta tener una versión de clojurescript decente en mi equipo. Podéis ver las notas de la instalación en https://github.com/eferro/clojurescriptnotes

Me quede bastante impresionado con cómo se puede trabajar con el entorno creado usando https://github.com/bhauman/figwheel-template para crear un proyecto. En concreto el flujo de desarrollo en un proyecto con reagent parece de lo más interesante y el proyecto uxbox de la PiWeek así parece confirmarlo.

Desde luego, para la tarde del jueves ya estaba completamente Agotado!!!! el ritmo de piweek es bastante demoledor.

Referencias:

• http://piweek.tumblr.com/
• http://www.piweek.com/
• http://www.kaleidos.net/
• hashtag piweek
• https://github.com/bhauman/figwheel-template
• ClojureScript Unraveled
• Clojurescript

PiWeek edición VIII (tercer día)

Ya estamos en el ecuador de la piweek y parece que todos los proyectos están muy encarrilados... Como siempre se ve un nivel espectacular y además de las cosas en las que estoy metido, suelo intentar curiosear, sobre todo en los proyectos realizados con clojurescript, que tienen muy buena pinta...

Tengo pendiente darle un empujón fuerte a ClojureScript Unraveled el fantástico libro que están escribiendo sobre clojurescript Andrey Antukh y Alejandro Gomez
Me he comprometido con Andrey a leer y dar feedback de la parte de instalación y tooling para ver si es adecuado para alguien que no tenga ni idea (como yo :-) )
Así que mañana le dedicaré unos cuantos pomodoros.

En cuanto a los dos proyectos en los que estoy metido con Jaime, la verdad es que vamos avanzando a buen ritmo.



Eduardo - Piweek from kaleidos on Vimeo.

Con expect ya volvemos a estar en verde después del cambio de diseño para mejorar los mensajes de error :-) (hacia tiempo que no pasaba tanto tiempo con los tests rotos)

En cuanto al visor de eventos, hoy hemos metido gran cantidad de eventos medio reales y hemos realizado las adaptaciones para comenzar con el filtrado. En este caso el avance es mucho más lento, pero como el objetivo en mi caso es aprender javascript y no tanto el resultado final, pues estoy bastante contento.

Una vez más, Esther Moreno nos ha echado una mano con el UX, ayudandonos a aclarar las ideas.
Además, me he aprovechado de estar rodeado de mucho conocimiento para hacer preguntas de novato de javascript y del entorno.

En concreto, creo que era la única persona en el planeta tierra que no sabia que se podia poner un punto de ruptura para arrancar el debugger en el chrome con solo poner "debugger;"

Gracias Alonso, solo por ese detalle puede que ya tenga amortizada la piweek!!!

En otro orden de cosas, hoy en kaleidos se ha hecho una comida especial de piweek, como siempre, ambiente festivo a tope.
El que no se divierte en la piweek es por que no quiere.

Referencias:

• http://piweek.tumblr.com/
• http://www.piweek.com/
• http://www.kaleidos.net/
• hashtag piweek

PiWeek edición VIII (primer y segundo día)

Una edición más me ha apuntado a la piweek. En esta ocasión me he apuntado a última hora puesto que en principio en estas fechas iba a estar de vacaciones.

En esta ocasión, del equipo de Alea Soluciones, he conseguido liar a https://twitter.com/jaimegil
Cómo sigo con mi cruzada personal por aprender algo de javascript, hemos decido implementar un pequeño visualizador de eventos https://github.com/aleasoluciones/eventsview
No tenemos muchas pretensiones en cuanto a las funcionalidades a realizar, el objetivo en mi caso es seguir aprendiendo, por lo que me importa mucho más tener la mente abierta que realmente tener una funcionalidad interesante.

De momento hemos realizado un pequeño listado de eventos que se va refrescando por ajax y lo hemos separado en dos objetos de vista, un presenter y un repositorio.
Estábamos planteándonos probar a implementarlo usando react (una vez más, sólo por aprender).

Una cosa muy interesante que he aprendido es lo importante que es tener acceso a alguien experto en UX. En este caso Jaime y yo teníamos la idea preconcebida de como queríamos hacer el visor de eventos, pero una conversación de unos 10/15 minutos con Esther Moreno (experta en UX de kaleidos) y hemos cambiado y simplificado la idea que teníamos.  Nos hemos ahorrado un montón de trabajo innecesario y gran cantidad de software a mantener :-)

En Alea Soluciones, nos vendría muy bien contar con algún tipo de "UX as a service" para mejorar la interacción con nuestras aplicaciones, que aunque no es mala, si que se nota que está pensada por un grupo de programadores con buenas intenciones pero a los que nos faltan conocimientos avanzados de UX y de diseño. Concretamente en mi caso, se nota mucho que siempre he trabajado en procesos de backend.

Además del visor de eventos, estamos dándole un empujón a la fantástica biblioteca de asertos expects que usamos al hacer TDD en python.
Está biblioteca creada por Jaime nos permite crear aserciones en los tests al estilo rspec y aunque es muy potente, Jaime  tenia algunas mejoras pendientes que no estaba pudiendo llevar adelante. Así que mejor ocasión que la piweek para darle un poco de cariño.

En esta ocasión hemos comenzado por un cambio interno de diseño para mejorar los mensajes generados cuando los asertos no se cumplen. Este cambio que puede parecer menor, en realidad es muy importante puesto que en este tipo de utilidades los mensajes son los que ayudan al desarrollador a identificar el problema lo antes posible, por lo que sucede como con los lenguajes en que los mensajes de error pueden ser una diferencia significativa en su facilidad de uso...


Esto es lo que han dado de si los dos primeros días de piweek... seguiremos informando

Referencias:

• http://piweek.tumblr.com/
• http://www.piweek.com/
• http://www.kaleidos.net/
• hashtag piweek

Bounded contexts en Domain Driven Design

En el AOS 2015 de Gijón me apunte a una 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. Después de la sesión, comente con Carlos la importancia que tiene comenzar a aprender DDD centrandose en la division en Bounded Contexts/subsistemas y en el lenguaje de domino de cada uno de estos Bounded Contexts, en vez de centrarnos en modelado estático (entidades y relaciones) que puede derivar en que intentemos modelar de forma global todo el dominio del sistema (con la complejidad que tiene y el riesgo de hacer una megaconstrucción que no se pueda mantener).

Carlos me propuso explicar mi punto de vista en un hangout público...

El hangout lo hicimos ayer y se puede consultar en la página del evento o en el video de youtube que subio Carlos a su canal:

• Video 
• Evento Google +

A continuación unas notas y referencias relacionadas...

Domain Driven Design

• Útil para dominios complejos
• Nos centramos en el negocio y intentamos modelar el comportamiento y los procesos de negocio con la ayuda de expertos del dominio
• Usamos el lenguaje de los expertos del dominio
• Dividimos en bounded contexts/subsitemas
• Cada bounded context se implementa con el modelo de dominio como parte central
• Se dispone de ciertos tácticas/patrones para facilitar la implementación de estos bounded contexts (ValueObjects, Agregados, Entidades, Repositorios, Eventos de Dominio,  etc…)

En el libro DDD Tackling Complexity in the heart of software Software en el que Eric Evans presentaba está forma de hacer software, la descripción de Bounded Contexts y otros conceptos para hacer el diseño estratégico aparecen en la segunda parte del libro.
Y entre que el libro es bastante pesado de  leer y que en la primera parte se tocan temas más "divertidos" para los desarrolladores de software, el mensaje general que ha transcendido está mucho más centrado en las tácticas y patrones con el que implementar (agregados, repositorios, etc).

Posteriormente, Eric Evans en varias entrevistas ha comentado que lo central de esta forma de diseño es el lenguaje ubiquo y los bounded contexts.

“Ubiquitous Language and Context Mapping and Core Domain are at the center, with aggregates in close orbit. Why, I ask myself, did I put context mapping in Chapter 14? Core domain in Chapter 15?!” Eric Evans (What I’ve learned about DDD since the book)

Subdomains y bounded contexts

En el DDD exchange de este año Eric Evans y Udi Dahan llegaban a la conclusión que subdomains y bounded contexts tienen un mapeo 1 a 1, siendo los bounded contexts del dominio de la implementación. Así que dicho esto, de forma pragmática se puede considerar como bounded context cada uno de los sub sistemas  que conforman la implementación de un sistema complejo.

Por supuesto cada uno de estos bounded context/subsistemas:

• tienen su propio lenguaje de dominio (una palabra puede tener distintos significados en cada uno de los bounded contexts)
• internamente tienen gran cohesión
• tienen un bajo acoplamiento con otros bounded contexts
• para implementar cada uno de los bounded contexts podemos tomar distintas decisiones
• tipo de arquitectura
• infrastructura usada
• incluso lenguaje de desarrollo

Por supuesto cada bounded context tiene sus propios datos, no están acoplados usando la misma BD compartida… (eso cae de cajón).

Esta forma de dividir los sistemas es muy compatible con un SOA bien entendido o lo que se está denominando como arquitectura de microservicios. En caso de crear bounded contexts que se comuniquen mediante eventos, también se facilita la creación de aplicaciones reactivas (http://www.reactivemanifesto.org/)

Ejemplo de descomposición en bounded contexts 

Supongamos que estamos encargados de implementar un sistema de venta online de viajes.
Durante el desarrollo nos centraremos en hablar con los expertos del dominio para ir extrayendo los comportamientos, acciones y eventos que se producen el sistema.
Por ejemplo podemos identificar las siguientes acciones:

• Añadir hotel al catalogo
• Realizar reserva en una cadena de hoteles
• Cobrar una reserva
• Recomendar un viaje a un viajero
• Registrar experiencia de un viajero en un hotel
• Generar billetes de avión
• Cobrar reservas
• etc...

De estas acciones, de los diversos departamentos de la empresa, de la información que necesita cada acción, de los eventos que se generan podremos ir identificando las los límites entre cada bounded context.
En el caso anterior puede que nos salgan bounded contexts como:

• Catalogo de vuelos/hoteles
• Sistema de recomendaciones
• Contabilidad
• red social de viajeros
• ...

La verdad es que como no tengo ni idea de ese dominio, no se si estos bounded contexts tienen sentido, pero para el ejemplo pueden valer. :-)

En cualquier caso debe quedar la clara la importancia de hacer esta división y de implementar cada uno de esos subsistemas de la forma más autonoma posible. Esto permitirá tomar decisiones de forma flexible puesto que lo podremos hacer independientemente para cada bounded context.

Tendremos que decidir el estilo de comunicaciones que vamos a usar entre los distintos bounded contexts y los  patrones generales que vamos a usar en el sistema.
Luego podremos coger cada bounded context e implementarlo con la arquitectura, herramientas y enfoque que sea adecuado al problema a solventar (en vez de forzar un mismo enfoque para todo el proyecto).

Recursos

• Definición de bounded contexts Martin Fowler  
• Polyglot Data (Greg Young) Buenos trucos relacionados con persistencia, entidades, eventos. También habla de las ventajas de poder tomar decisiones distintas para implementar la persistencia de cada uno de los bounded contexts. 
• Videos de Carlos Buenos Vinos sobre bounded contexts: 
• Domain-Driven Design: Bounded Context Integration (Spanish)  
• Domain-Driven Design: Domain Events and Bounded Context Integration (Spanish) 

Por cierto que el resto de videos de Carlos Buenos Vinos sobre DDD están muy bien.

Una última nota

Si os ha parecido interesante y tenéis preguntas no os cortéis a ponerlos en los comentarios o por twitter (@carlospeix @eferro)
Lo mismo si os parece interesante que se hiciesen más hangouts sobre el tema invitando a más gente.

Cualquier opinión será muy bienvenida.

Podcast y charla interesante (Junio 2015)

Dejo por aquí un par de referencias que me han parecido interesantes... Tengo muchas más pendientes de apuntar por aquí, pero estas las separo puesto que el resto están en inglés.

• Propiedad liquida en Agiles Mexico Alan Cyment Charla interesante sobre el concepto de Lean Coops propuesto por el propio Alan. Últimamente estoy bastante interesado en ver distintas formas de organización que permitan poner a las personas en el centro o que por lo menos tenga unos valores fuertes y centrados en el respeto por los miembros de la organización y sus relaciones (Semco, Valve,  k2kemocionando, Morning Star o incluso otros casos más cercanos como Kaleidos o Deiser).
• rantpod podcast 01x10 no estimates En este episodio del podcast rantpod comienzan por hablar del movimiento #noestimates y cómo se cuestiona si en proyectos/productos con una visión y un equipo comprometido las estimaciones aportan valor y deriba a una conversación sobre la importancia de los conocimientos de negocio en los equipos de desarrollo y de la implicación y compromiso del equipo de desarrollo con una visión y unos objetivos de empresa. Les ha quedado una discusión interesante de la que se pueden sacar varias posiciones y algunos detalles muy interesantes.

En el siguiente post pondré otras charlas y podcast que me han resultado útiles últimamente, pero en ese caso será en inglés.

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)... :-)

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!!!!

More interesting Podcasts/Talks

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

• Succeeding with TDD: Pragmatic Techniques for effective mocking Venkat Subramaniam. Some simple techniques that can help us be quite effective with mocking
• Radical Ideas from the Practice of Cloud Computing 
• SE Radio Episode 221: Jez Humble on Continuous Delivery 
• Simple Made Easy 2011  Rich Hickey. Great talk and a good excuse to study functional programming.
• Design and architecture for actors Lambda Jam 2014 - Martin Logan A reference talk about the design for concurrency using the actor model.
• Embracing Uncertainty Dan North Keynote. I show this this key note several times but I allways find new interesting details.
• Agile - You keep using that word Dan North Insparing key note
• Evolutionary Architecture and Microservices - A Match Enabled by Continuous Delivery Rebecca Parsons 
• http://www.agilealliance.org/resources/learning-center/strategies-for-agile-portfolio-management Goods advice to prioritize, focus on value and  portfolio management strategies.
• Pivotal - 3 Big Shifts: CloudFoundry & the future of enterprise IT James Watters Very insterestink talk about the cloud revolution, orchestration. It present the most disruptive techs for the cloud (OSS as a tech standard, software designed as cloud native and agile transformation (dev and ops))

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

Aplicación del principio DRY

Desde siempre he tenido claro que en desarrollo es muy importante que cada concepto este una sola parte del sistema. Por otro lado, también tengo muy presente que la duplicidad de código es un problema y que hay que intentar limitarla y en los casos que sea necesario (casi todos) eliminarla sistemáticamente.

Muchas veces se sigue el concepto DRY a ciegas, sin tener en cuenta que cada decisión tiene un coste, por lo que voy a exponer algunos puntos que pueden ayudar a decidir cuando debemos eliminar la duplicación y cuando podemos vivir con ella.

• Debemos diferenciar duplicación en conceptos de negocio, reglas, validaciones, flujos, etc y duplicación a nivel de implementación y código donde se pueden dar pequeñas duplicidades. 
• La duplicidad en conceptos de negocio se debe minimizar todo lo posible.
• La duplicidad a nivel de código, puede ser una pista de que hay una abstracción pidiendo ser descubierta, un comportamiento emergente del sistema o simplemente un patrón propio de nuestra aplicación. Es importante minimizarla, pero no es un drama si existe algo de duplicidad. Eso si, hay que tener mucho cuidado de no generar una abstracción prematura. En mi experiencia las abstracciones prematuras son mucho peores que la duplicidad.
• Si haces TDD lo mejor es duplicar el código para conseguir verde y una vez en verde y bien cubierto por los tests, refactorizar eliminando la duplicación.
• Dependiendo del lenguaje hay duplicidades que tienen un coste elevado de eliminación o que no tienen una solución idiomática en ese lenguaje. En esos casos debemos quitar la duplicidad, si el resultado es más sencillo de entender (no solo por ti, sino por todo el equipo). Ante la duda, debe primar siempre la legibilidad.
• Es importante saber que cuando eliminamos una duplicidad normalmente lo hacemos creando una clase común, una biblioteca, un método o cualquier otro artefacto que nos permite referenciarlo/usarlo desde varias partes de nuestro código. Esto es una dependencia entre el código cliente y el código a reusado. La dependencia es una de las relaciones más fuertes que se puede dar en el código y siempre es un coste importante así que hay que tener en cuenta este punto a la hora de evaluar si eliminamos la duplicidad o no.
• Siempre debemos dependender de artefactos que sean más estables que nosotros mismos, es decir si hemos sacado código común a una biblioteca, pero el api de esta biblioteca cambia constantemente es un indicador de que no hemos realizado una buena abstracción y que el coste de mantemiento se nos va a disparar.

Resumiendo:

• Es importante no tener duplicidad de conceptos de negocio (la duplicidad de bajo nivel es menos importante).
• Evaluar peligro de abstracción prematura.
• Evaluar coste añadir dependencia vs ventaja de eliminar duplicidad.
• Si al eliminar duplicidad se pierde legibilidad, lo estamos haciendo mal.
• Mejor seguir un proceso de usar, usar, reusar, abstraer (no ir directamente a generar una abstracción).

Si no te puedes permitir esperar un poco antes de hacer una abstracción o una vez que la haces, no te sientes capaz de eliminarla o modificarla en caso de que no se ajuste correctamente a lo que se necesita, tu problema es que estás generando deuda técnica mucho más compleja que la que generas por dejar una pequeña duplicidad.

Aunque el principio DRY puede parecer sencillo de entender, su aplicación, como siempre en el desarrollo de software, no es sencilla ni sistemática.

Presentación Golang design4concurrency GoMad Abril 2015

Estas son las diapositivas de la charla que Jaime Gil de Sagredo y yo presentamos ayer en el grupo GoMad:

• golang-design4concurrency

El código de ejemplo, las diapositivas y un mind map inicial se puede encontrar en:

• https://github.com/aleasoluciones/golang_design4concurrency_talk/

Y las referencias usadas son:

• Go concurrency patterns concurrency
• Advanced Go concurrency patterns advanced-go-concurrency-patterns
• Designing for Actor Based Systems designing-for-actor-based-systems
• Golang patterns for serving on-demand, generated content patterns-for-serving-on-demand-generated-content

El mensaje que queremos transmitir es:

• Debemos diseñar para la concurrencia desde el principio (centrándonos en identificar las actividades concurrentes y sus dependencias) (Ver verbos vs nombres y designing-for-actor-based-systems)
• Cada pequeña parte del estado de la aplicación tiene un solo propietario y no se debe compartir.
• Como opción por defecto se deben usar tantas goroutinas como actividades concurrentes (son gratis)

Creo que lo conseguimos transmitir sobre todo con los ejemplos de diseño. Los ejemplos de código nos podían haber quedado mejor... pero creo que el mensaje está transmitido :-)

Gracias a GoMad y en concreto a Máximo por organizarlo...

Opinión sobre la tecnología en educación primaria/secundaria

By OLPC Foundation [CC BY 2.5 (http://creativecommons.org/licenses/by/2.5)]
via Wikimedia Commons

En el podcast sobre agilidad, rantpod, dedicaron un capitulo la tecnología y su uso en el entorno educativo
Como orgulloso padre de una peque de tres años, es un tema que me interesa, asi que les deje el siguiente comentario en la web del podcast:

Lo primero a tener en cuenta es que solemos considerar tecnología o nueva tecnología a todo aquello que no estaba cuando nacimos, así que lo que para los profesores o padres es nueva tecnología, puede que para el niño no lo sea. Sobre todo teniendo en cuenta que seguramente le pusieron canciones en la móvil o veía sus dibujos animados preferidos en youtube. Para el niño un ordenador/tablet/móvil puede ser tan común como una pintura o un libro.

En cuanto al si introducir la programación o la robótica en edades tempranas, yo diría, que hay que transmitir a los niños al menos lo necesario para que puedan distinguirlo de la magia, puesto que ya es parte de su día a día.
Si no son capaces de distinguirlo de la magia, ya nos podemos olvidar del pensamiento crítico.
No hay más que ver el efecto que tiene que no tengamos ni idea de biología, química y otras ciencias... para empezar es la base de la que se aprovechan las pseudociencias.

No se qué opináis al respecto, pero como padre, le doy muchas vueltas a estas cosas y esas son las principales conclusiones a las que he llegado :-)

Me encantaría leer más opiniones al respecto.

Socrates Canaries 2015, experience and notes

Few weeks ago I attended to the first Socrates conference organized in spain (In Tenerife) Socrates Canaries. This posts summary some of the thinks I have learned, ideas to explore, techniques to use or tests, and notes about this open space.


Notes about Impact mapping:

• Very good fit with DDD or any business focus design process
• The "what" level can be use as a initial bounded context division
• All the vocabulary/terms used during the impact mapping is part of the ubiquitous language of each domain context
• Very powerful tool to improve the communication between business people and development

Interesting talk:
Crafted design / Iteration Driven Design by Sandro Mancuso, a pragmatic and evolutioned view of DDD,  very alined with outside-in TDD, XP and any kind of decoupled architecture focused on business domain (hexagonal, clean architecture, etc...). In our software we can extract explicit classes for actions / use cases.

Others deliveries of the same talk:

• At GeeCON 2014 https://vimeo.com/101106002
• At Lean Agile Scotland https://vimeo.com/107963074

Contract real experts when we have a prototype or a small system in production that use a new/unknown/unvalidated technology so the experts can validate or change all our assumptions (never contract this kind of experts at initial phases because we don't know what to ask).

Recruitment, "don't suspect when you select, don't select when you suspect".

Dreyfus model Interesting model on how acquire skills. As I understand the model, I consider myself an apprentice at all the topics/technologies I use, so I should be alert about the Dunning-Kruger effect :-)

OO TDD Outside-in design tips:

• Classes should only be created to either serve an existing class or an external need (app entry point, etc.)
• Classes always should be designed from the client's prespective. Never in isolation (tends to overengineering, accidental complexity and premature abstractions).

I have some ideas/notes about when to use classic or mockists tdd, but this will be another blog post.

Interesting technologies:

• Consumer-Driven Contracts (Contracts testing) Pact Pacto
• logspout to agreggate/dispatch containers logs
• codehale metric
• http://mesos.apache.org/
• https://mesosphere.github.io/marathon/
• https://github.com/mesos/chronos

Interesting books:

• Pragmatic thinking and learning

Homework:

• Improve my english
• Force pair programming
• Do not be shy :-)

Personal feelings and notes:

• With some difficulty, I can propose/present a session at open spaces / conferences like this... (challenge archived).
• I returned home full of energy.
• I love the open space format.
• The practices we are using and the software we are developing at Alea Soluciones, archieves a very good results and have high quality.
• As a team, I think that we can contribute our bit to the craftmanship comunity.
• New contacts, new friends, old friends, passión, fun time.

Without doubt, one of the best events I've attended. Kudos to the people who orginazed it, especially to Carlos Ble

Bibliografía y referencias Agilidad

En un comentario del post los dos pilares del desarrollo agil homominimus me solicitaba algo de bibliografía para aplicar las ideas ágiles a proyectos de consultoría (no relacionados con desarrollo de software).

La verdad es que no tengo unas referencias muy concretas que le pueda ayudar, pero creo que Lean mindset (ask the right question) es un muy buen libro para conseguir la mentalidad correcta.

Por otra parte, y tal como comento en auto notas para explicar la agilidad las presentaciones y charlas de Henrik Kniberg creo que aglutinan lo más interesante de la mentalidad ágil. Cabe destacar la presentación My passion for projects Keynote (slides) y los vídeos sobre cultura en spotify que tiene en su web (spotify engineering culture 1 spotify engineering culture 2)

Por último, ante cualquier duda, siempre vuelvo a los principios ágiles y al manifiesto ágil y si se trata de desarrollo de software, a las prácticas técnicas de Extreme Programming.

Y siempre hay que recordar, que La agilidad no es una receta para el éxito.

Actualización:
Menudo descuido, se me olvido mencionar esta key note de Linda Rising sobre el poder de el mindset agile que creo que es imprescindible...

Los dos pilares del desarrollo Ágil de software

Si, ya se, todo el mundo suele comentar que los pilares del desarrollo de software ágil son tres:

• La cultura, principios y valores
• Los métodos y artefactos de gestión (liturgias y procesos correspondientes a scrum, kanban, etc.)
• Las prácticas técnicas y la búsqueda de la excelencia técnica (Pair programing, TDD, collective code ownership, Integración continua, etc.)

Pero tengo la sensación que para un desarrollo de software que aporte valor a los clientes y que sea sostenido en el tiempo, principalmente nos hacen falta dos, y desgraciadamente nos son los valores que más suelo ver...

Como siempre, no todo es blanco o negro así en cada momento en el tiempo cada pilar lo podemos tener más o menos interiorizado, por lo que a continuación comento varias de las combinaciones que he visto y el efecto que creo que tienen.

Cultura ágil interiorizada, métodos ágiles conocidos y en uso, prácticas técnicas muy mediocres, suele derivar en bola de lodo inmantenible, eso si, en menos tiempo y con más eficiencia que sin métodos ágiles.

Cultura ágil no interiorizada, métodos ágiles conocidos y en uso, prácticas técnicas correctas o buenas, deriva en un buen flujo de funcionalidades, pero que será complicado de mantener en el tiempo, puesto que será difícil conseguir un equipo de desarrollo estable y cohesionado. Así que funciona en estos momentos, pero es difícil de mantener en el tiempo.

Cultura ágil no interiorizada, métodos ágiles conocidos y en uso y practicas técnicas muy mediocres, es lo que se conoce como Scrum de chichinabo (tm) y es un fiasco total, a muy corto plazo puede dar alguna pequeña victoria, pero suele derivar en situaciones peores que antes del intento de implantación del desarrollo ágil.

Cultura ágil interiorizada, métodos ágiles mínimos, prácticas técnicas correctas o buenas, deriva en en un buen flujo de funcionalidades que se pueden mantener en el tiempo con un ritmo sostenible.

Vamos, que si tengo que elegir dos pilares, elijo, sin duda alguna, Cultura ágil y prácticas técnicas. Por cierto, que ese espíritu creo que encaja muy bien con la Programación Extrema y con el movimiento de Artesania de Software.

Cultura Ágil

+

Prácticas Técnicas

Ni que decir tiene que con una buena cultura se puede conseguir todo lo demás, pero hay que saber hacia donde se quiere ir y dedicarle tiempo y esfuerzo...

Por supuesto, esto es mi opinión y sólo está basada en los contextos que he ido viviendo, pero para eso es mi blog, no? ;-)

Si alguien conoce implantaciones en las que con mal conocimiento y prácticas técnicas se ha conseguido un buen resultado a medio largo plazo que me lo comente que seguro que tiene muchas cosas de las que se puede aprender.