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