Resultado del Lean Coffe

Meetup «Ventajas y desventajas de Sylius como solución e-commerce PHP»

A english version of «Advantages and disadvantages of using Sylius as PHP e-commerce solution» is available at the end of the post.

Introducción

La semana pasada organizamos nuestro primer evento dentro del grupo de Meetup de Sylius. Antes de nada, agradecer la presencia de todas las personas que nos brindaron de su tiempo, vinieron a nuestras oficinas y aportaron sus puntos de vista enriqueciendo el evento, esperamos que pasaran un buen rato y se fueran con nuevos conocimientos y ganas de volver.

A modo de introducción, Sylius es, y cito la definición que aparece en su página web, «el primer framework adaptado a soluciones e-commerce». Desarrollado sobre Symfony y siguiendo los mejores estándares de calidad, contiene una serie de bundles que trabajan conjuntamente para facilitar el desarrollo de aplicaciones de comercio electrónico para programadores que estemos familiarizados con Symfony.

Sylius lanzó recientemente su primera versión (aunque ya lleva un tiempo entre nosotros en forma de beta), y nosotros decidimos realizar el primer proyecto con él para ver cómo es la experiencia, y aunque puede ser tema de otro post, adelantaré que ha sido un desarrollo muy interesante donde hemos aprendido y mejorado, y aunque aún es un MVP, os invitamos a que visitéis nuestro proyecto de cursos y formación: gravita.academy.

El evento

Volviendo al evento del grupo de Meetup, una vez más adoptamos el formato de mecánica Lean Coffee, que se adaptó bien en nuestro anterior evento, así que tras la ronda de presentaciones, dispusimos unos minutos para saber qué temas trataríamos durante la hora/hora y media que duró el debate, siguiendo un timebox marcado de 5 minutos con votación silenciosa de si seguíamos con el tema o pasábamos al siguiente.

 

Resultado del Lean Coffe

Temas que todos quisimos tratar

Temas

Temas priorizados

Temas tras la votación priorizados

Tras realizar la votación y priorización, hablamos sobre los siguientes temas:

¿Cómo va la generación de temas?

Una de las grandes ventajas que tienen otras soluciones de e-commerce son sus tiendas de temas, la facilidad de implantación y las ventajas que aportan con el consecuente ahorro de tiempo por la funcionalidad que tiene. Sylius tiene su propia página de temas y es interesante saber cómo desarrollar nuestro propio tema. Explicamos entonces nuestra experiencia desarrollando nuestro primer tema para nuestra tienda.

¿Disponemos de API para aplicaciones?

Con la división que estamos viviendo entre la parte frontoffice y backoffice de nuestras aplicaciones, surgió la duda de si el framework estaba preparado para que existiera una forma fácil de entablar comunicación si desarrollamos aplicaciones cliente con frameworks javascript como React, Angular, etc. La respuesta es que Sylius nos provee de las operaciones CRUD de nuestras entidades a través de una API si seguimos su forma de trabajar, además de permitirnos el uso de OAUTH ante operaciones que queremos blindar.

¿Qué ventajas tenemos con respecto otros frameworks?

Entramos en la comparación directa con soluciones que ya están más que consolidadas en el desarrollo de plataformas e-commerce. Aquí hablamos sobre nuestra experiencia, qué echamos de menos (YOAST SEO…), y las ventajas comparadas con los demás (disponemos de una base de código de muy buena calidad).

¿Cómo se integra con otros bundles (FOSUserBundle, SonataAdminBundle, …)?

Una de las grandes dudas es si el conjunto de la aplicación que desarrollemos dejará de funcionar en caso de sustituir o integrar otro Bundle externo. Una de las grandes ventajas de Sylius es la modularidad de la que dispone. Nos permiten trabajar con cualquiera de los bundles de los que se forma de manera individual para soluciones que no tienen por qué ser una tienda, además de poder sustituir uno de sus bundles por otro que deseemos, pero como siempre, con posterior trabajo de adaptación y seguramente pérdida de automatización por el camino.

¿Cómo configuramos despliegues automáticos?

La automatización del pase a los distintos entornos de nuestras aplicaciones siempre es un tema que suele ser interesante. Aquí describimos un poco nuestra experiencia al integrar, configurar dentro del proyecto el EasyDeployBundle, que es la alternativa que estamos usando tras pasar por Capifony y Deployer. Surgió también la necesidad de disponer de un modo de puesta en mantenimiento de Sylius.

¿Es fácil editar el proceso de compra?

Es algo muy común que desde el cliente nos soliciten que todo el proceso de compra se realice en un paso, o tener que adaptar nuestras aplicaciones a las distintas formas de pago y/o configuración de distintos TPV de bancos. El proceso de configuración básica para la puesta en marcha de una tienda es fácil gracias a que Sylius integra el PayumBundle.

 

¿Qué tal la comunidad? ¿Tendrá versiones LTS garantizadas?

Lamentablemente, no dio tiempo a tratar este tema, pero consideramos que es algo muy interesante que estaría bien discutir. Invitamos en cualquier caso a quien quiera que comente en este post.

 

Próximos pasos: Talleres

A modo de conclusión del evento, solicitamos a los presentes que decidieran el formato del siguiente evento (charla, debate, taller…), y el tema del que le gustarían que tratase, así que cada uno escribió en un post-it su apuesta para no influir en la opinión de los demás, y más tarde, entre todos, realizamos una votación para acordar el tema:

Claramente, existía una alineación en el formato, y tras la votación, acordamos que el siguiente evento será un taller sobre cómo desarrollar nuestro primer tema en Sylius.

Si quieres estar al tanto de próximos eventos y quieres formar parte del grupo, aquí tenéis el enlace del Meetup para poder registraros.

 


Meetup «Advantages and disadvantages of using Sylius as PHP e-commerce solution»

Introduction

Last week we had our first Sylius’s Meetup event. In order to introduce Sylius, is, and I only copy and paste the definition from his web, «The first framework for tailored e-commerce solutions». Developed over Symfony and following the best quality coding standards, Sylius contains bundles that works together to make easy the development of e-commerce applications for developers that are familiar with Symfony.

Sylius’s guys just launched his 1.0.0 version (although Sylius have been a long time between us as beta), so we decided to develop our first project using it, and, even though it is material for another post, the first impressions are very good. The development process was very interesting and we’ve learned and improved our skills, and, though is an MVP yet, we invite you to visit our learning and courses platform project: gravita.academy.

 

The event

Returning to the Meetup’s event, another time we use the Lean Coffee format that fits very well in our last event, so, after the presenting round, we let a bit of minutes to know what topics people want to talk about the hour / hour and half that remains of the event, so following a 5 minutes timebox with simple vote about if we discuss about the next topic or continuing with the current topic.

Lean Coffee topics

Lean Coffee topics that people wanted to discuss

 

Topics

Temas priorizados

Prioritized topics after the vote

After voting and prioritization, we talked about the next topics:

How about theme management?

One of the advantages of other e-commerce solutions are his themes shops, the ease of implantation and the shortion of cost for functional development. Sylius has his own theme page and is interesting to know how to develop a custom theme. We talked about our experience developing our first theme for our shop.

Is there an API for client applications?

Some of we are used to develop client side applications with JS Frameworks like React, Angular, etc., and they wonder about if Sylius manages this communication. The answer is that Sylius allows to use CRUD operations of our entities if we work following the Sylius’s way. In addition, we have OAUTH for secure API functions.

What advantages has Sylius against other frameworks?

We put Sylius in front of other e-commerce solutions. Talked about our experience, what we would like to have in Sylius (YOAST SEO…), and the advantages compared with the others (we will have a great quality base code using Sylius).

 

How works other bundles integration (FOSUserBundle, SonataAdminBundle, …)?

One of greatest doubts is about the functionally lost in case we change or integrate third party Bundles in Sylius. One of the greatest advantages of Sylius is the modularity. We can use individually each Sylius bundle in our projects even if it’s not a shop. Also, we can change one of them with other of our preference, but like always, we need to adapt it a bit, losing part of its automatization.

How we automatize the deploy?

The deploy’s process automatization to each environment always is an interesting topic. Here we described a bit our experience installing and configuring the EasyDeployBundle inside our Sylius’s project, the tool we’re using after try Capifony and Deployer. We talked about the needs of a «maintenance mode» in Sylius too.

 

Is easy to edit the checkout?

Is ordinary that our clients needs to change the default checkout process, for example, using one step checkout, or to make our applications capable of using a variety of payment methods and / or setup any bank payment gateway. The basic configuration process for a standard shop is easy thanks to Sylius’s PayumBundle integration.

 

How about the community? Will exists an LTS version?

Although this is a great topic to discuss, we finished the meetup time without talk about it. But we invite to comment on the post to anyone.

 

Next steps: Workshop

At the end of the event, we asked everyone to decide the next event format (talk, discuss, workshop…), and the topic they would like to learn, so everyone wrote in a post-it his bet to not change the thoughts of the others, and later, between all, voted his preferences:

We can see everyone was interested in a workshop, and the votes made the topic will be about how to develop our first theme in Sylius.

If you are interested in next events and want to be part of the group, here is the link to Meetup.

Introducción

Antes de nada, sería pertinente comenzar por el por qué del grupo. Recientemente nos planteamos la certificación de Symfony para los desarrolladores de nuestra empresa, y en la documentación de los pasos a seguir, vimos que desde la página de academia de Sensiolabs tenían con frecuencia cursos y talleres de preparación, en Francia, Londres y Alemania. Cuando les preguntamos sobre la posibilidad de realizar la formación aquí en España al igual que en otros países, la respuesta que obtuvimos es que no hay tanta gente que lo solicite, por lo que no se lo plantean.

Queremos conseguir que todos los desarrolladores de Symfony que lo deseemos tengamos la posibilidad de tener un espacio en el que discutir inquietudes, apoyarnos y mejorar, sin tener que esperar a grandes eventos anuales como el deSymfony o Codemotion para ello, y por esas razones, creamos el grupo de Symfony.

Un poco de contexto

El pasado jueves tuvimos la suerte de poder organizar nuestro primer meetup, «Los retos de la comunidad Symfony«, y desde aquí quiero agradecerles a todos los asistentes que nos brindaron su tiempo. Desde el principio queríamos desmarcarnos de la clásica master class, que aunque no tiene nada de malo, no se ajustaba tanto a nuestra idea de generar comunidad en torno a Symfony, queríamos romper el hielo entre los participantes (que no oyentes), y queríamos debate.

 

Los retos de la comunidad Symfony

Como adelantaba antes, queríamos que el meetup fuera algo más comunicativo, que todos los presentes aportasen su visión, mostrasen sus inquietudes y pudieran ser ayudados. Pensamos usar Lean Coffee como método para obtener, priorizar y tratar temas de conversación que todos deseáramos discutir.

Para el que desconozca cómo funciona lean coffee, está dividido en tres grandes bloques de los que hicimos uso de la siguiente manera:

  • Obtención de temas: el primer paso era saber los temas sobre los que querían hablar los participantes. Para ello, planteamos las preguntas «¿Qué quiero aprender?», «¿Qué puedo aportar?», «Dudas existenciales». Repartimos una serie de post-its sobre los que escribir los temas que quisieran tratar y que posteriormente se colocaron bajo cada pregunta en un muro. Para tener mejor visibilidad de todo, dedicamos unos instantes en agrupar los temas similares o los que directamente eran iguales.
  • Priorización: una vez teníamos todos los temas, los priorizamos para hablar sobre los que pudiéramos dentro del tiempo que teníamos disponible, repartimos entre cada uno 5 puntos que usarían para votar los temas que les resultaran más interesantes, y de esa manera, ordenarlos y detectar los prioritarios.
  • Discusión: establecimos un timebox de 5 minutos para hablar por tema, llegando a la posibilidad de prorrogarlos con una votación hasta que todos pensásemos que el tema no daba más de sí.

Temas tratados

Tras realizar los primeros dos pasos del Lean Coffee, se nos quedó el siguiente muro con los temas que trataríamos en la siguiente hora:

Muro de temas a tratar sacados en el Lean Coffee

Muro del Lean Coffee

Como podéis ver, uno de las grandes preocupaciones que asaltaban a los participantes es la gestión de los assets del frontal de nuestras aplicaciones, cómo hacemos uso de Gulp y/o Webpack Encore. Este tema se llevo gran parte del tiempo asignado del meetup.

Otro tema que tratamos fueron sobre la forma en la que cada uno realizaba la subida a producción de los assets, el debate estaba en generarlos en local y copiarlos arriba, o generarlos directamente arriba. Cada uno defendió sus ventajas e inconvenientes dependiendo de lo que acostumbra a hacer.

Siguiendo con los frontales de nuestras aplicación, surgió la visión de cómo Symfony estaba alejándose de la alimentación del frontal para centrarse en el lado back de las aplicaciones, dando paso así a los clientes desarrollados con frameworks javascripts como React, Angular o Vue. Dedicamos un rato a discutir nuestras experiencias con cada uno, cómo realizamos las comunicaciones entre cada parte, y el manejo de datos sensibles de usuarios.

El último tema que nos dio tiempo a tratar fue el de la gestión de formularios en Symfony, la validación, creación de Constrains. Cada uno expusimos cómo trabajamos con los formularios.

Se quedaron fuera temas interesantes como Certificación, los cambios que se acercan con Symfony 4 o testing, uso de servicios para la lógica de la aplicación frente a custom events.

Cierre

Una vez más, me gustaría desde aquí mandar un saludo a todas las personas que quisieron y pudieron venir, esperamos que les resultase una experiencia enriquecedora y quieran repetir en el próximo. Por otro lado, a todos los que os interese apuntaros al grupo y estar al tanto de los próximos eventos que organicemos, dejo el enlace al registro en el grupo de Meetup.

Definición de hecho en Elemento115

Os voy a contar cómo llegamos a nuestra propia «Definición de hecho», «Definition of Done» o «DoD» en Elemneto115.

En la última retrospectiva ágil que hicimos el pasado 30/08/2017, aprovechamos para tratar un tema que veníamos necesitando desde hacía tiempo.

Un acuerdo sobre qué características debe tener un trabajo que realicemos para considerarlo como «hecho».

Un trabajo está hecho cuando se termina. Parece obvio. Y también puede parecer sencillo pensar en qué debemos tener en cuenta para considerarlo como tal. El problema reside en que habitualmente, distintas personas, pueden opinar diferente sobre qué características tiene algo que está hecho.

Y la cosa se complica si esas personas cumplen diferentes cometidos y tienen distintas responsabilidades durante el transcurso del trabajo.

Y ahí reside la necesidad de llegar a un acuerdo, y a ser posible con apoyo visual permanente.

¿Por qué es importante la Definición de Hecho?

Contémoslo con comida, que siempre es más fácil de explicar y entender. 

Pongamos que tenemos dos restaurantes especializados en vender hamburguesas, uno es un restaurante de comida rápida y otro uno de comida gourmet orgánica.

Hamburguesería de comida rápidaHamburguesería gourmet orgánica

En el restaurante de comida rápida se considera una hamburguesa como «vendida» (trabajo hecho) cuando:

  • Se ha cobrado al cliente antes de empezar a elaborarla.
  • Se ha registrado el evento «en preparación» asociado al número de pedido en el sistema.
  • Se ha colocado la hamburguesa con la bebida con hielo y las patatas fritas calientes sobre una bandeja.
  • Se ha entregado la hamburguesa en menos de 5 minutos después de cobrar.
  • Se ha entregado al cliente ketchup y si lo ha solicitado mostaza.
  • Se ha añadido a la bandeja un cupón descuento para la próxima compra.
  • Se ha deseado al cliente un buen día.
  • Se ha registrado el evento «entregado» asociado al número de pedido en el sistema.

En el restaurante de comida gourmet orgánica, en cambio consideran una hamburguesa como «vendida» cuando:

  • Se ha llevado el plato con la hamburguesa en el pan inferior únicamente, y el resto de ingredientes en una bandeja accesoria.
  • Por separado también se entregan las salsas y los vegetales dispuestos según indica el manual de sala.
  • Se ha verificado con el cliente el punto de cocción de la carne en el momento de la entrega.
  • Se comunica al cliente además la cantidad de calorías y alérgenos del plato que va a consumir.
  • Se ha ofrecido al cliente la posibilidad de que se cocine más la carne en caso de que el punto de cocción sea menor del deseado.
  • Se ha deseado al cliente que disfrute de la hamburguesa.
  • Se ha hecho una marca de «entregado» en la hoja de la comanda.

 

Como véis, las dos definiciones de hecho, son bastante claras en ambos casos. Y completamente diferentes.

Por otro lado, en los restaurantes hay personas con distintas responsabilidades (clientes, dueñx de negocio, jefx de sala, cocinerx, camarerx, etc) y que pueden dar más prioridad a unas características de la «definición de hecho» sobre otras dependiendo de algunos factores típicos:

  • Cantidad de trabajo acumulado.
  • Fecha o tiempos de entrega.
  • Experiencia de las personas en el proceso.
  • Confianza con el cliente.
  • Momento del día / nivel de cansancio.
  • etc.

Si no hay acuerdo explícito sobre la definición de hecho, distintas personas en cada momentos se ajustarán a la definición de hecho según su opinión y necesidades.

Una última complicación.

Ahora imaginad que un cocinero y una camarera del restaurante de comida rápida, deciden cambiar de trabajo e irse al restaurante gourmet. Pensad en cada uno de ellos y en qué problemas encontrarían a la hora de cumplir con su trabajo si no hubiera una «definición de hecho» claramente acordada y visualizable por todos en cada momento.

El acuerdo sobre la definición de hecho debe estar claramente visible y ser fácil de consultar y en su caso renovar cuando sea necesario.

Por suerte (o por desgracia para algunos), en Elemento115 no vendemos hamburguesas, si no servicios. Y la «definición de hecho» no es algo tan obvio.

Cómo hemos llegado a un acuerdo sobre la Definición de Hecho

Como decía antes, en la retrospectiva, facilité la sesión de co-creación de la «Definición de hecho» o «Definición de acabado» o «DoD», por sus siglas en inglés «Definition of Done».

La sesión está basada en un juego de cartas: DoD Kards preparadas por Thomas Whallet y Camilo Velasquez en Kleer.

El objetivo, para quien conozca la dinámica, es alcanzar un acuerdo sobre qué características debe reunir una tarea para que consideremos el trabajo como hecho, conseguir una mejor entrega de valor paliando y evitando los clásicos malentendidos y la desalineación de expectativas que se generan en este ámbito.

Durante el juego, separamos en tres columnas las diferentes recomendaciones:

  • La columna de «YA» para aquellas cosas que estamos haciendo ya.
  • En la sección de «MÁS ADELANTE» para aquellas que de momento no contemplamos pero que añadiremos pronto.
  • Por último, la del «NO» para aquellas que no aplican, en las que no llegamos a un acuerdo, o que no nos interesan en ningún caso.

Os dejo la foto donde reunimos todo, y os invito a que visitéis el post que hemos escrito desarrollando más ampliamente la explicación nuestra definición de hecho.

Definición de hecho en Elemento115

 

Cuál es la definición de hecho de Elemento115

Os dejo a continuación nuestra lista de características de la definición de hecho:

  • Revisión:
    • No se incrementa la deuda técnica  (sin justificación)
    • El product owner ha visto funcionando en algún entorno la historia de usuario y la ha aceptado.
  • Difusión:
    • Se notifica a las personas interesadas.
    • Se comunicó al resto del equipo la información relevante.
    • Se actualizan las entregas en Jira y los documentos de Confluence, que afectan a notificaciones slack y emails para hacer llegar las notificaciones a quien corresponda.
    • Se enseña a los usuarios involucrados el uso de las mejoras.
    • Se genera o actualiza la documentación relevante: manual del API, manual de usuario, control de versiones técnico y release notas de marketing .
    • Se justifica el desfase con respecto a la estimación tanta al alza como a la baja si canta a la vista (si, según el sentido común, el desfase es grande)
  • Entornos:
    • El entorno de entrega está preparado para hacer las pruebas y comprobaciones necesarias.
    • El código generado es almacenado en Bitbucket.
    • Se ha desplegado sin errores en el entorno de entrega con las pruebas definidas pasadas.
  • Calidad:
    • Se ejecutan las pruebas necesarias.
    • Se cumple con los estándares de código.

Una definición de hecho sujeta a revisión

Naturalmente nuestra definición de hecho no está escrita en piedra, y la revisaremos en unos meses, ya que hay cosas que hemos dejado para «después» o incluso acuerdos a los que hoy por hoy no hemos llegado.

Es junto con la definición de preparado para desarrollo (acuerdo pendiente en Elemento115) uno de los acuerdos más importantes a los que puede llegar un equipo.

Espero que os haya gustado el post y si tenéis cualquier duda o sugerencia, por favor, utilizad la sección de comentarios de más abajo.

 

En la última retro tratamos un tema importante, que condujo al trabajo de parte del equipo durante varios días, en lo que denominamos «Welcome project«.

El «Welcome project» es un manual de bienvenida diseñado en forma de proyecto, con sus tareas a completar que guiará, durante la primera semana, el aprendizaje y las experiencias de las personas que entren a trabajar con nosotros.

¿Qué buscamos?

Para reflexionar sobre la importancia de una nueva incorporación y sobre el proceso  y el plan de bienvenida y posterior acompañamiento, nace de una dinámica alrededor de  un mapa de empatía simplificado.

Pedí, por parejas que nos pusiéramos en el lugar de alguien nuevo que entra, alrededor de los siguiente factores:

Tasks:

  • ¿Qué preguntas necesita que le respondan?
  • ¿Qué tareas tiene que hacer?…

Feelings:

  • ¿Qué siente?
  • ¿Por qué es importante para él?

Pain points:

  • ¿Qué obstáculos y problemas se encuentra que espera superar?

Goals:

  • ¿Cuál es su último objetivo?
  • ¿Qué espera conseguir?

 

Mapa de empatía simplificado

 

Definición de etapas

Con el trabajo resultante, construimos, alrededor de una líena de tiempo (primera semana, primer trimestre, primer año) el plan de bienvenida básico, poniendo más hincapié en la primera semana.

Así es como salió, por ejemplo, que en la primera semana, consideremos importante haberle presentado los porqués de la cultura y forma de trabajar de Elemento115, o que en el primer trimestre haya superado el trance de romper producción de algún proyecto (ejem: ningún usuario de producción sufrirá graves consecuencias por esto).

Desmenuzando objetivos

Lo primero que hicimos fue dividir el proyecto en 3 grandes áreas que llamamos «Conoce tu empresa«, «Prepara tu entorno» y «Prepara tu equipo«, con las que pretendíamos cubrir todas las necesidades de conocimiento y logísticas que pudiera tener en esta primera semana.

Estas a su vez, se dividieron en áreas más pequeñas y abarcables, tales como «Metodología básica Elemento115«, «Misión, visión y valores de Elemento115«, «Roles y responsabilidades de cada uno«, etc. En las siguientes fotos se puede apreciar esos dos primeros niveles de jerarquía que nos permitió generar el esqueleto del proyecto.

Llegados a este punto hay que aclarar que nos parecía un poco denso y no muy tangible empezar hablando de pura metodología, así que decidimos posponer esta parte para las próximas semanas y enfocar el inicio más por su vertiente práctica, esto es, el conjunto de herramientas que caen bajo su paraguas y que nos permiten llevarla a cabo en el día a día.

Con el esquema preparado, faltaba ir al detalle de los aspectos concretos que debía ocuparse cada subárea.

Así, por ejemplo, para explicar cómo trabajamos nos parecía completamente necesario que la persona que se incorporase empezase a manejar JIRA y Toggl o conociese cómo funcionamos en las dailys y en el muro, pero no nos resultaba tan apremiante explicarle cómo son nuestras retros, ya que aún faltaban casi 3 semanas para la siguiente.

Se trataba de elegir entre aquello que necesitamos desde el minuto 1 y aquello que puede esperar. Y sí, el Late Cake, Spoiler Man y fregar los platos entraban en la primera categoría :-p

Este desglose generaba directamente tareas de JIRA, que posteriormente pusimos en su correspondiente muro y les añadimos una descripción, consistente en un resumen, unos criterios de validación, lo que queda fuera del alcance de la tarea y una estimación.

Con esto último podíamos calcular si la cantidad de trabajo que habíamos planeado estaba ajustada al tiempo disponible para completar esta primera fase del Welcome Project. No queríamos abrumar en el arranque, ni quedarnos cortos generando así una sensación de desorientación o abandono.

Reparto de apoyos

Un aspecto importante que se suele pasar por alto con las nuevas incorporaciones es el impacto que se provoca en el resto del equipo. Tener a una persona que posiblemente necesitará asistencia a menudo y del que estar pendiente porque a veces ni siquiera sabrá que la necesita, supone un gasto de tiempo y energías para los demás tan necesario como inevitable.

Para gestionarlo, asiganmos un responsable de cada tarea a un miembro del equipo, de forma que siempre hubiese alguien definido a quien acudir en caso de duda y que en la planificación inicial diaria que hacemos cada uno tuviese claro que debía reservar una cantidad de tiempo para que el resto de proyectos no se viesen afectados por la nueva incorporación.

Con este trabajo previo estábamos preparados para recibir a nuestro nuevo compañero con los brazos abiertos ¿Habríamos acertado? Lo sabremos en próximos episodios…

Entrega de valor

En la anterior retrospectiva reflexionamos sobre la entrega de valor en Elemento115, y de las conversaciones que tuvimos y los acuerdos a los que llegamos es de donde nace éste post.

¿Qué dice el manifiesto ágil de la entrega de valor?

Echemos un pequeño vistazo a lo que dice el manifiesto ágil:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

En mi opinión cuando hablamos de «software funcionando» estamos hablando de lo esencial del manifiesto ágil, estamos hablando de la ENTREGA DE VALOR.

Así que, en la restrospectiva, empezamos por el principio ¿Qué entendemos por valor?

¿Qué entendemos por «valor» en Elemento115?

Os dejo a continuación todas las ideas que salieron al respecto y que estuvimos poniendo en común:

  • Ahorro de tiempo
  • Ahorro de dinero
  • Aprendizajes
  • Ingresos
  • Flow
  • Superar expectativas
  • Resolverlas progemas
  • Cubrir necesidades
  • Validar pronto hipótesis
  • Validar modelo de negocio
  • Realizar entrega continua
  • Aportar la solución óptima (coste/tiempo/efectividad)
  • Maximizar y ajustar calidad/coste
  • «Algo mejor que otra cosa»
  • Opciones y propuestas alternativas para un problema
  • Cumplir acuerdos y compromisos

Como véis, puede haber otras definiciones u otras formas de verlo, pero desde luego ésta me dejó bastante contento.

¿Qué es «valor» para vosotrxs? Os agradecería mucho que dejárais un comentario más abajo con vuestra opinión.

También concretamos la entrega de valor que hacemos en las siguientes fases para buscar herramientas y estrategias en cada una:

  • Planificación
  • Compromiso
  • Foco
  • Demostración
  • Celebración
  • Visualización

A continuación os detallo cada una de las fases. No todas aplican para todos los proyectos o para todas los clientes. Y algunos de los puntos aún estamos incorporándolos. Pero en definitiva, y para que os hagáis una idea… ahí va:

¿Cómo planificamos la entrega de valor en Elemento115?

  • Acordamos entregas de valor con el cliente para el proyecto que alimenten el backlog con al menos dos semanas de antelación.
  • Reunimos toda la entrega de valor  que compone en el backlog en releases en Jira.
  • Tratamos que las releases se produzcan con una frecuencia mínima de una por/una semana.
  • Ponemos especial atención en consensuar con el cliente el «valor» de la release por encima del detalle funcional o técnico.
  • Documentando y poniendo a disposición del equipo la entrega de valor consensuada con el cliente en la release donde corresponda, ya sea subjetiva, sujeta a opiniones o sensaciones u objetiva, sujeta a datos y métricas  (normalmente en las historias y tareas en Jira)

¿Cómo nos comprometemos con la entrega de valor?

  • Acordamos cuál va a ser la entrega de valor al arranque del sprint (nuestro sprint es de tres semanas)
  • Acordamos cual va a ser nuestra entrega de valor semanalmente.

¿Cómo nos enfocamos en la entrega de valor?

  • Revisamos el avance de la entrega de valor semanalmente.
  • Revisamos el avance de la entrega de valor en la daily.
  • Utilizamos herramientas de visualización, tanto en el muro, como en un dashboard especial en JIRA enfocado en las entregas de valor.
  • Hacemos referencia siempre en las conversaciones con el Product Owner y con el cliente a la «entrega de valor».

¿Cómo demostramos la entrega de valor?

  • Hacemos demos de las entregas.
  • Enseñamos el avance de las entregas en cuanto podemos.
  • Añadimos información, documentando la versión y ampliando el manual de usuario cuando corresponda.
  • Separamos el histórico de versiones para el cliente, del control de versiones técnico y el manual de usuario del proyecto.
  • Informamos y coordinamos los despliegues con clientes y usuarios finales.

¿Cómo celebramos la entrega de valor?

  • En determinadas entregas, versiones importantes, grandes avances, o grandes proyectos, compramos un muñeco POP.
  • Cuando hacemos pleno de compromisos en un sprint, nos damos el lujo de una comida pagada por el estudio.

¿Cómo visualizamos la entrega de valor?

  • Los carriles en nuestro muro indican los proyectos en curso y las entregas de valor de ese sprint.
  • Hay un carril adicional para soporte, rellenado habitualmente con los imprevistos que quedan fuera de las entregas que había acordadas.
  • Hay un carril adicional para tareas propias del estudio.
  • En el muro, los postits de clientes que representan entregas de valor son amarillos. Los imprevistos naranjas y otras tareas inclasificables, verdes.
  • Tenemos una pizarra donde apuntamos los compromisos semanales que revisamos y vamos tachando.
  • Hemos configurado un dashboard en Jira para hacer el seguimiento de las entregas.
  • Vemos, en un monitor  con la visualización de ese dashboard.
  • Coleccionamos una estantería todos los muñecos POP.

Entrega de valor

En nuestro estudio no todo es desarrollo de software, por eso, el «Software funcionando» no siempre es la entrega de valor.

¿Cómo lo hacéis vosotrxs? Me interesa muchísimo conocer otras opiniones y experiencias. Dejadme vuestros comentarios más abajo.

Graaaciaaaas.

Esta es la narración de una historia de amor. Breve, intensa y que terminó de forma brusca, contra un muro.

Todo empezó con un encuentro tan casual como inevitable.

Por un lado un estudio digital buscando una herramienta que hiciese el desarrollo de aplicaciones web más eficaz, fiable y escalabale, y que abriese la puerta a exportar ese conocimiento para generar aplicaciones móviles.

Por otro, con uno de tantos frameworks de JavaScript ofreciéndose cual sandía abierta en la red de redes (saludos a los señores periodistas digitales de los mass media).

 

Qué inocente parece, tan sencillo, pulcro y fácil de instalar.

Dentro de las opciones disponibles, estaban los nombres habituales: Angular, React, Ember, Backbone

Pero uno llevaba desde hacía un tiempo llamando poderosamente la atención de todo aquel que se adentraba en este mundo: Vue.

Sus virtudes eran obvias: ligereza, rapidez, versatilidad y sobre todo una curva de aprendizaje de lo más agradable, en la que con un conocimiento previo de HTML/CSS/JavaScript podías obtener resultados muy vistosos de forma casi inmediata.

Para un estudio modesto, en el que la inversión en I+D no puede competir con la de grandes corporaciones al estilo Weyland-Yutani, era una verdadera tentación, imposible de resistir.

El tiempo es dinero, y si un 89% de los desarrolladores decían en 2016 estar tan satisfechos con él como para volver a usarlo, no había más que pensar.

Así, la relación nació llena de ilusión, con un primer acercamiento a la reescritura del Rand-o-matic muy rápida y vistosa.

Versión 0.1 del Rand-o-matic Vueizado. Jusqu’ici tout va bien.

El Tocstrap, como buen amigo, echó una mano en ello, y todo parecía ir sobre ruedas, pero ya sabemos que al principio la pasión lo tapa todo.

El problema vino, como tantas otras veces, con una tercera persona.

Llegó la hora del cambio, de dar el siguiente paso y comprometerse a ser capaces de hacer aplicaciones móviles.

Deberíamos haber empezado a sospechar cuando la elección del framework que debía ayudarnos a conseguirlo no se mostraba con claridad ¿Weex? ¿Cordova? ¿Phonegap? ¿Quasar? ¿Framework7? ¿Ionic? Cada uno tenías sus ventajas e inconvenientes, algunos ya los conocíamos y no nos convencían, otros estaban en un estado de desarrollo demasiado temprano, otros no estaban pensados para funcionar con Vue sino con Angular, otros eran de Adobe…

Con las dudas propias de quien da un like en Tinder a alguien que solo tiene una foto, optamos por Weex. Parecía la opción menos mala dentro de las posibles.

Weex.

Recordad ese nombre. Anotadlo junto al de Summer.

Los problemas empezaron a manifestarse desde el principio, una vez metido entre medias de la relación.

El hecho de tratar de hacerlo funcionar en un entorno Windows no hizo sino agravarlos ¿Pero qué clase de futuro podía esperarnos si no era capaz de resistir una prueba tan dura? Variables de entorno, actualización de Node, instalación de Android Studio, JDK y drivers del dispositivo, añadido de la plataforma de Android… todo lo que en el ecosistema Web App había sido fluidez y avance, aquí se volvía barricadas, retrocesos y desesperación.

Cuando creíamos haber logrado por fin deshacer el nudo, se volvía a enmarañar y había que volver a empezar.

Y para colmo, al ser un proyecto de Alibaba y estar poco extendido aún, gran parte de las dudas había que resolverlas en chino ¿Os imagináis Stack Overflow en chino en vuestro día a día? Intentadlo.

Gracias chicos, pruebo lo que decís y os cuento

El golpe definitivo vino cuando tuvimos que añadir estilos: instalación de paquetes de node (style-loader, css-loader), intentos de importación de ficheros externos, como si de un componente se tratase, intentos de carga asociados a <style>, intentos de carga de todo nuestro Tocstrap incrustado inline. Nada, que no había forma de que aquello cogiese los estilos. Estábamos intentando forzar algo que había nacido fracasado.

Y la culpa fue nuestra, por fiarnos. Por no leer la documentación y ver esto:

The CSS standard may support a lot of selectors, but now weex only support single-class selector.

The CSS standard can support many types of length units, but now weex only support pixel, and the px unit could be ignored, you can write number directly.

The styles of Weex cannot be inherited to children elements, this is different to the CSS standard, such as color and font-size.

The CSS standard contains a lot of styles, but weex only sopport few styles which include layouts such as box model, flexbox, positions.

¿En serio?

¿Y nos dices ahora que estás casado y tienes hijos?

¿De verdad no crees que es algo que deberías poner en tu página home para que, si empiezo algo contigo, sepa a que atenerme?

No sé, algo así como en letras mayúsculas, a tamaño 70 y en #f00. Está bien, no podíamos echarle la culpar, la información estaba ahí, algo escondida, pero estaba. Y nuestra obligación era habernos informado antes de tirarnos a la piscina del I+D.

No era momento de buscar culpables, sino soluciones.

Bien, bien… lo que se dice bien… ahora mismo no me caes mucho

Así que hicimos lo que hemos aprendido en tantas películas: cortar.

Asumir que aquello no iba a ningún lado, que no estábamos hechos el uno para el otro. Ta vez en dos años hubiese tenido más sentido, pero no ahora, nos habíamos equivocado con el momento.

Hicimos limpieza, nos quedamos con la parte de Vue que aún podía salvarse para hacer Web Apps de forma rápida y ligera, y nos pusimos a buscar otra pareja con la que seguir recorriendo al camino.

¿Cuál fue nuestra elección? Solo adelantaremos que, como decía Hitchcock, «en caso de duda lo mejor es refugiarse en lo conocido«.

 

 

 

 

 

Este es el resumen de la reunión de restrospectiva de la iteración 24 en Elemento115.

Contexto y preparación de la retro

Me reuní con cada persona por separado para preparar la retrospectiva, tomando el pulso, y reuniendo la información, deseos, preocupaciones y objetivos de cada uno.

Siempre hay temas que preocupan en general a todo el mundo, y algunos particulares.

En general el tema de vacaciones, coordinación, equipo y personas, preocupa a todos, y de eso os contaré más adelante.

Por otro lado, hay muchos aspectos técnicos o de proceso en los que tenemos pendiente profundizar para mejorar, sin embargo decidimos dejar esos temas de lado hasta septiembre que ya estaremos todos.

La retrospectiva tenía como objetivos fundamentalmente resolver dudas en el ámbito de la alineación de la cultura entre las personas y reflexionar sobre los cambios que se está produciendo al respecto, entre ellos, el convertirnos en un equipo distribuido con dos sedes.

De los objetivos también salió un poco el formato, una retro, como la anterior, de toma de consciencia más que de búsqueda de acciones de mejora.

Os dejo a continuación la foto del Diseño A3 de la retro:

Diseño de la retrospectiva ágil de Elemento115 por Manuel Barroso Parejo.

Tema recurrente: Las vacaciones
Estamos terminando Julio, y junto con Agosto, son los meses en los que más gente coincide de vacaciones. Además, Septiembre es, junto a Enero, EL MES de puesta en marcha de iniciativas y proyectos por excelencia.

No lo digo yo, lo dicen los inicios de curso, los cambios y reorganizaciones en las empresas, los coleccionables de Planeta y hasta el catálogo de IKEA.

¿Qué quiero decir con este rollo?
Pues que sí, que hay mucha gente de vacaciones, hay muchos sectores y negocios que casi se paran y algunos hasta cierran en Agosto. Yo os puedo decir, que en el sector del desarrollo de productos y servicios de software, por mi experiencia, sucede lo contrario.

En definitiva, en nuestro contexto, el trabajo es mucho más intenso por los siguientes tres factores:

  • Jornada reducida: en Julio y Agosto nuestro horario orientativo es de de 8:00 a 15:00.
  • Personas de vacaciones: menos margen para imprevistos, y personas, internamente, y en el lado del cliente, entrando y saliendo de proyectos.
  • Lanzamientos en septiembre: mes muy popular «a la vuelta de vacaciones» para lanzar nuevas funcionalidades, productos o servicios.

Shit happens: nuestro primer despido

Los valores y la cultura en una organización, ¿nacen espontáneamente, se van construyendo, van emanando o es algo que hay que definir, fomentar y promover, o nada de lo anterior?

Aún no tengo clara la respuesta a esta pregunta, aunque la asistencia al último meetup de madridagil sobre principios y valores y escuchar experiencias al respecto, me ayudó a entender un poco mejor las claves.

Un equipo de trabajo como el nuestro: multidisciplinar, muy especializado y en pleno crecimiento a todos los niveles, está sometido a exigencias y tensiones continuas, en búsqueda constante del equilibrio entre el ritmo sostenible, el flujo de caja y la rentabilidad.

La mejora y la experimentación continua, conducen al crecimiento y al éxito, y son bases fundamentales de nuestra metodología de trabajo. Hay que añadir además, que el proceso tiene implícito errores y problemas de los que vamos aprendiendo.

Los peores problemas son los que afectan a personas y en empresas como la nuestra, en el que las personas son el bien más preciado, cuando esto pasa, sufrimos emocionalmente mucho.

Puede suceder que personas y organizaciones no encajen, en un momento dado, al ritmo que necesitan. Esto no incapacita a la empresa para seguir intentándolo, ni invalida a la persona para encajar mejor en otra ocasión.

En nuestro caso, ha sido una etapa extraordinariamente enriquecedora, y nos sentimos muy agradecidos por ambas partes. No sé lo que nos deparará el futuro, pero sí sé que hemos encontrado alguien valioso al que seguir de cerca. Y al que decir GRACIAS.

Los dos aprendizajes más importantes que me llevo son en forma de preguntas para el futuro:

  • ¿Cuánto estamos dispuestos a invertir en el proceso de contratación, de entrada y acompañamiento?
  • ¿Tenemos las herramientas, métricas y alertas adecuadas para entender el grado de «acoplamiento» y tomar decisiones?

One more thing: Nueva sede Elemento115 en Valencia

Además, en septiembre, empezamos otra gran aventura, la apertura de la sede de Elemento115 en Valencia, que os contaré con más detalle más adelante, y eso, en sí mismo, también es otro gran reto para el equipo.

Este es el contexto de Elemento115 en el que sucede la retro. Siento la chapa hasta ahora, era largo de explicar =)

BIENVENIDA / APERTURA

Empezamos con una dinámica de apertura tipo «citas rápidas», en la que por parejas, cada uno contó al otro aspectos positivos y negativos de las últimas tres semanas. De aquí nació la tira cómica de ésta retro que podéis ver al final del post.

Cambiando de pareja cada 5 minutos, estuvimos durante una media hora en una dinámica que para mí combina muy bien el juego, con la reflexión y la conversación cara a cara.

TOMA DE CONSCIENCIA Y ALINEACIÓN

Personas
Después, estuvimos durante una hora aproximadamente hablando de las personas, de nuestras expectativas los unos con los otros, y de los cambios que estamos viviendo en éste ámbito, como os contaba anteriormente en el contexto. Con el enfoque siempre puesto en indagar, comprender y mejorar nuestros comportamientos y procesos.

Nuestras conclusiones son:

  • Ahora somos más conscientes de los ritmos que siguen las personas, el equipo y la empresa y el por qué debemos estar más pendientes de mantenerlos alineados.
  • Por mucho que los temas más importantes siempre parezcan los proyectos, la tecnología, la metodología… en las retros conviene siempre estar alerta al tema «personas».
  • El equipo debe ser un motor de mejora y cambio en ese ámbito y se le debe dar la responsabilidad y herramientas para su desempeño

Remoto

Indagamos sobre la nueva problemática que se nos presenta, al arrancar la Sede Valencia, nos convertimos en equipo en remoto sí o sí.

Así que para hacerlo más vivencial, y adelantarnos a lo que ocurrirá en unas semanas, propuse una pequeña dinámica de roles, y separé al equipo en dos salas, dando instrucciones a cada persona por separado.

Todos partían de la misma información:

  • Acabábamos de terminar la daily.
  • Ya eramos remotos, pero desde hacía poco tiempo.
  • A continuación, a cada uno les di unas indicaciones sobre lo que tenía que hacer, que normalmente requerían preguntar, o coordinarse con los demás, presentes o en remoto.

Al cabo de 30 minutos, nos volvimos a juntar para analizar y sacar conclusiones de lo ocurrido desde las siguientes dimensiones:

  • Problemas y necesidades
  • Canales de comunicación
  • Herramientas y soporte de información
  • Prácticas y técnicas

Como es un tema muy específico, os contaré las conclusiones por separado, en un post dedicado a cómo empezamos a hacer remoto en Elemento115.

AGRADECIMIENTOS Y CIERRE

Para cerrar la retrospectiva, pedí una ronda de aspectos positivos que repetir en otras ocasiones y aspectos negativos que evitar.

Como positivos salieron:

  • Ayuda mucho ser consciente de los tiempos de cada fase y dinámica y que haya alguien facilitando los plazos y trasnsiciones.
  • Ayuda mucho haber establecido un plan previo en común.
  • Ayuda mucho usar dinámicas de roles

Como negativos:

  • Entorpece tratar temas demasiado sesudos durante demasiado tiempo.

Por terminar, solo quiero recordaos que os paséis por aquí de vez en cuando para conocer cómo crecemos y mejoramos.

Os dejo con la viñeta de la retro, en este caso, resumen de una conversación en la dinámica de citas rápidas ;D

Viñeta cómica de la retrospectiva

Viñeta cómica de la retrospectiva de Elemento115. 19/07/2017

 

Manuel Barroso Parejo
Co-fundador Elemento115
@manubarpar

 

 

En septiembre de 2017 abrimos nueva sede Elemento115 en Valencia y empezamos a hacer trabajo remoto.

Es nuestra primera experiencia como empresa en la que estaremos distribuidos en dos lugares, y a hacer trabajo remoto.

Una gran apuesta y un gran síntoma del buen momento de evolución y cambio que estamos viviendo, pero por otro lado va contra el trabajo coubicado que buscamos bajo la filosofía Lean UX.

No queremos que la distancia perjudique a las personas, al trabajo en equipo y al desempeño de los proyectos, así que nos hemos dado una serie de pautas para evitarlo en lo posible desde el primer momento.

Por supuesto, no están escritas en piedra, este primer acercamiento es fruto de una retrospectiva ágil. Naturalmente e iremos evaluándolas y cambiándolas cuando sea necesario.

Problemas y miedos del trabajo remoto

  • Riesgo de sentirse aislados unos de otros.
  • Problemas de motivación al trabajar solos.
  • «Me olvido de que está trabajando fulanito o menganito»
  • Riesgo a perder el pulso, y la información del día a día.
  • Peligro de ruido y caos al usar varios canales y herramientas de comunicación.
  • Perder el espíritu de equipo

Canales de comunicación

  • Online: utilizaremos muchas herramientas y todas dependen de internet y de una buena conexión. Inicialmente, la sede en Valencia operará desde un espacio de Co-working, hasta que validemos su viabilidad, y deberá ser un espacio compatible con estar hablando en alto, ya que muchas de las herramientas online que usaremos conllevan voz.
  • Teléfono: tendremos un teléfono de empresa para facilitar y economizar la comunicación para temas que lo requieran.
  • Presencial: una semana de cada tres, coincidiendo con la semana de la retro, el equipo de Valencia estará en Madrid.

Herramientas

  • Email: para temas más formales con clientes.
  • Wiki confluence: para documentar y compartir información
  • Jira: para el seguimiento de tareas
  • Team viewer / hipchat / skype / appear.in / slack: para la comunicación y reuniones del día a día. Elegiremos una en concreto, cada una de ellas tiene pros y contras para lo que necesitamos:
    • Compartir escritorio, pantalla, ratón y teclado
    • Hacer video y audio conferencia
    • Enviar mensajería y chat
  • Por otro lado, también estamos valorando la posibilidad de mantener una herramienta con canal de audio permanentemente abierto como en los MMO tipo WOW o LOL.

 

Buenas prácticas / técnicas

  • Doble ckeck: asegurarse en la medida de lo posible de transmitir el acuse de recibo cuando recibimos un mensaje.
  • Decir si no estoy: mantener actualizado el estado en slack o la herrmamienta correspondiente.
  • Avisar si me voy en el caso de que tenga que salir o dejar de estar disponible durante una conversación.
  • Mantener blog de reuniones y actividad de proyectos en confluence, para conservar en la medida de lo posible la información disponible del día a día.
  • Calendarios compartidos y diferentes para cada sede y temática: Tendremos calendarios además de los calendarios comunes, el calendario de reuniones por sede.
  • Pair programing y sesiones de co-creación en remoto: haremos especial inversión en sesiones de pair-programming y de co-creación para fomentar más el contacto de lo habitual.

 

Hasta aquí los temas que queremos poner en marcha o tener en la cabeza para empezar.

Pronto los iremos evaluando, y seguro que se nos ocurren mejoras que os iré contando.

¿Tienes algún consejo, buena práctica o sugerencia? Cuéntanos en los comentarios que nos interesa conocer qué otras cosas está haciendo la gente. GRACIAAAS.

Manuel Barroso Parejo
Co-fundador Elemento115
@manubarpar