El pasado Marzo, Christian Soronellas y yo estuvimos en A Coruña ayudando al equipo de Opositatest con algunos de sus retos. Me gustaría compartir con vosotros cómo ha sido el proceso de principio (contacto, precio, preparación, contenido y seguimiento) así como daros a conocer Opositatest. Si estáis buscando un equipo con retos interesantes, vivís por A Coruña o podéis trabajar en remoto, vale la pena que habléis con ellos. Podéis revisar la oferta aquí.

Un DM de Twitter con buena pinta

Es Martes noche y estoy haciendo la revisión semanal de emails de lectores, personas que piden soporte y privados en Twitter. El más interesante que tengo es de Pablo, COO y Cofounder de Opositatest, quizá la plataforma más importante para preparar oposiciones que tengamos en nuestro país. Al parecer necesitan un cable. Opositatest está creciendo fuertemente en tráfico y funcionalidades y se enfrentan a algunos dilemas importantes. Han decidido revisar su arquitectura actual y decidir cuál es la mejor estrategia a seguir para sus necesidades: unificar y tender hacia un monolito, continuar como hasta ahora (múltiple servicios con algunas dudas sobre el sentido de algunos de ellos) o proponer una reorganización de lo existente en base al negocio.

Éste es uno de los casos que nos gustan al Gremio del Rigor (Rigor Guild). Llamo a Christian, le digo que se reserve Febrero o Marzo que nos tocará volar a Galicia.

Primera llamada con Pablo y Borja

Pablo, el COO de Opositatest, y Borja, el CTO, (los títulos son un poco anecdóticos porque los dos son techies y desarrollan con el resto del equipo técnico) son de aquellos CXOs que me gustan. Pragmáticos, con un mindset abierto a considerar todas las opciones posibles, que les gusta ir al grano y que hacen las preguntas adecuadas. Les explico el tipo de consultorías y formaciones que más me piden: Refactoring to Hexagonal Architecture + Testing y Refactoring to CQRS + Domain Events. Su respuesta: "Prefiero que estés dos días con nosotros y nos ayudes en la definición de esa arquitectura y cómo llegar a ella". Considered done! Envío el NDA (Non Disclousure Agreement) para que nos puedan dar acceso al código y nos ponemos a organizar el workshop.

Precio

Mis ingresos personales provienen de mi trabajo como CEO y CTO de SEAT:CODE, así que las consultorías y formaciones son un hobby. ¿Por qué las hago, entonces? Me permiten varias cosas: ayudar a los demás, continuar conectado con la comunidad, ver otros problemas diferentes que no veo en mi día a día y mejoran mi marca personal. El hecho de no depender de ellas económicamente, me permite elegir los casos y ser 100% abierto con mi opinión sobre la solución. Me pongo en la piel de vuestro CTO y recomiendo como si la empresa fuera mía maximizando el resultado y minimizando el coste de las soluciones. Con algunos casos, he dicho que no necesitaban mi ayuda en la primera videoconferencia.

Dicho esto, por si teníais curiosidad, mi tarifa son 1.500 EUR/día + dietas y 100 EUR/hora + IVA por las horas de seguimiento en remoto. Considero que es muy buen precio teniendo en cuenta que normalmente en las formaciones y consultorías se benefician una media de 15 developers que aprenden durante más de 16 horas (nos va la marcha y siempre estiramos las horas a saco). 3000 EUR/16 horas/15 developers, el precio hora de formación por developer sale entre 12 EUR y 20 EUR. Es difícil encontrar mejores fuentes de formación al mismo precio o más baratas. Sin contar con los beneficios derivados a la empresa al aplicar los resultados de la consultoría.

En resumen, Opositatest ha invertido en su equipo y empresa, 4.000 EUR + IVA + más dietas por trabajo previo, 2 días in-situ y 10 horas de seguimiento en remoto. Adicionalmente, acordamos organizar algún meetup que ayude a compartir conocimiento e incrementar aún más el branding de Opositatest para ayudar con el hiring.

Objetivos de la Sesión

Establezcamos las expectativas: “Si Carlos Buenosvinos va a pasar dos días con el equipo técnico de Opositatest, qué objetivos (preguntas, dudas, consejos, aclaraciones, respuestas, artefactos, etc.) os gustaría tener cumplidos cuando salga por la puerta”. Esto es lo que pido que rellenen los developers de forma individual, así como los COO y CTO, para conocer sus expectativas. Es importante separar las del CTO porque a veces, puede ocurrir que las visiones de equipo técnico y CTO sobre las necesidades o el problema sean diferentes. Si coinciden, mejor. En este caso, todos estaban alineados, buena señal.

Revisando los objetivos y la arquitectura

Toca videoconferencia con Pablo y Borja. Me pasan diagramas arquitecturales. Revisamos cada uno de los servicios actuales, sus dificultades actuales y los objetivos que el equipo ha rellenado. El escenario no tiene mala pinta: Symfony entre 3.4 y 4, PHP 7 en todos los sitios, Sylius, EasyAdmin, algún Sonata, integraciones vía API REST y ya hay algún RabbitMQ. Incluso hay un servicio que se asemeja a un API Gateway aunque gestiona cierta lógica de negocio. El problema principal parece ser una Base de Datos común que les ha obligado a tener algunos modelos y bundles compartidos entre las aplicaciones y eso afecta a la velocidad de desarrollo. El equipo son 8 developers en total y tienen alrededor de 6 servicios.

Primeras impresiones y planificando la workshop

La primera impresión es que con un equipo tan pequeño, tantos servicios, y una única base de datos… algo pinta mal. Quizá un monolito bien arquitecturado y testeado sería lo más práctico, pero hay que ir con cuidado con combinar múltiples versiones de Sylius, EasyAdmins y Sonata.

El reto consiste en guiarles en el proceso de la toma de decisión, no imponer una visión. Vamos a usar behind-the-scenes una combinación de técnicas de Change Management y Decision Making: ADKAR (Awareness Desire Knowledge Ability Reinforcement) combinada con un Problem/Solution Space y un Extreme Case Analysis.

Desarrollo de la Workshop y 1er día

1. Revisión de Objetivos

Cada asistente comparte sus objetivos con el resto del equipo. Agrupamos.

2. Pain Points

Haremos lo mismo con los cuellos de botellas alrededor de acelerar velocidad y calidad. Dot Voting y Ranking.

3. KPIs

Qué KPIs deberíamos medir y ver mejorar si tomamos acciones para mejorar dicho Pain Points.

4. Planteando Soluciones

Considerando un espectro de soluciones, donde un extremo es tener un único monolito con todas las aplicaciones juntas y el otro extremo es ir a “DDD full-microservicios”, los asistentes plantean soluciones intermedias. Encontramos pros/cons para cada solución y que posibles medidas para mitigar los cons en cada solución. Identificamos qué información adicional necesitamos evaluar. De lo más interesante, es la importancia de poder externalizar alguno de los servicios no Core a empresas externas para acelerar el desarrollo.

Parece que no estamos tan lejos de DDD microservicios: Bounded Contexts con un o dos servicios por cada uno de ellos con bases de datos (o al menos schemas) separados pudiendo usar mensajería para convertir entre contenido generado y productos a vender. Pero necesitamos mirar en detalle con código delante dicho coste.

Vamos para Coruña centro que toca participar en el meetup. Hoy tenemos CQRS en el menú.

2º Día

1. Sprint Planning

Planteamos qué tareas serían necesarias para conseguir dicha separación de modelos, base de datos, etc. Estimamos qué tiempo necesitaríamos y qué dificultades encontraríamos. Qué workarounds encontramos. Vamos a practicar con algunos casos de uso reales.

2. Mob Programming

Escogemos alguna de las aplicaciones más compleja y refactorizamos hacia hexagonal y testeamos un caso de uso con 100% de coverage. Practicamos el GivenWhenThen, el uso de Mocks y algunos trucos más. El equipo parece sorprendido ya que el coste de trabajo es bastante menor del que parecía en su inicio.

3. Context Map

Revisamos el objetivo de negocio de cada uno de los servicios actuales y hacia dónde deberían evolucionar, incluso el nombre que deberían tener. Lo más interesante es que cuando pocos developers trabajan en múltiples Bounded Contexts, es difícil cambiar el “sombrero” cuando estás trabajando en un BC y pasas a trabajar en otro. Discutimos cómo aplicar ACLs entre un contexto de generación de contenido y otro de venta online. El equipo lo tiene muy claro. Acuerdan tener un developer representante de cada BC.

4. Cierre de la sesión

Repasamos los objetivos, las decisiones tomadas y el plan de acción. Estamos satisfechos.

Seguimiento

Una vez en casa, Christian y yo preparamos un documento resumen con conclusiones y recomendaciones. En las próximas semanas, evaluaremos cómo el equipo está avanzando y si las conclusiones post workshop se han podido aplicar tal y como todos esperábamos. Con reuniones de seguimiento vía conferencia es más que suficiente.

Necesitas Ayuda

Si tu equipo se encuentra en una situación similar y necesitáis ayuda en la toma de decisiones o incluso en bajar al detalle las implementaciones necesarias, no dudéis en contactarnos por mail directamente a carlos.buenosvinos@gmail.com.

• microservices
• monolith
• bounded contexts
• ddd
• context map
• php