Definición de hecho, Definition of Done o “DoD” 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.

 

Manual de bienvenida a Elemento115

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…

Cómo entendemos la entrega de valor en Elemento115

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.

Cómo empezamos a hacer remoto en Elemento115

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

 

 

Symfony 2: Form Type y Prototypes

La gracia de un framework es poderte abstraer de muchos problemas complejos, como por ejemplo dar una manera sencilla de administrar los contenidos. Symfony2 nos provee de una potente herramienta de gestión formularios: su creación, su validación, su populación… y la pieza más importante en relaciones 1 a N: los Form Prototypes. Cuando realizamos un proyecto, […]

“El desksurfing es un win-win” Juan Vázquez, desarrollador Ruby y fundador de Sociack

Invitamos a Juan Vázquez, desarrollador Ruby y cofundador de Sociack, a que nos cuente sus sensaciones en su visita desksurfing a nuestras nuevas oficinas.

No fue mi primera vez, ni tampoco será la última que haga desksurfing. Si aún no sabes de qué va el tema, te sugiero que des una vuelta por Google y mires qué cosas más chulas ocurren en torno a este movimiento.

Como te decía, hace unas semanas los chicos de Elemento115 me invitaron a que pasara los días que me iba a quedar en Madrid, trabajando desde sus oficinas en Pirámides.

La idea era redonda: tenía sitio para trabajar como si se tratase de mi oficina, rodeado de “compañeros del metal” como diría Bonilla, internet, risas y lo más importante, aprender cómo funciona otro equipo aunque solo fuera por 2 días y medio. Fue un win-­win.

Yo estoy ahora mismo en Dublin, trabajando en un equipo similar en características pero con un entorno y una historia muy distinta.

Ellos son un estudio que da servicios de desarrollo mientras que yo estoy en el lado de la empresa de producto único.

El poder contrastar qué y cómo llevan a cabo el día a día te da un punto de vista de qué hay en común y qué se puede mejorar/cambiar en tu propio equipo.

Lo mismo en el sentido contrario.

El desksurfing es un win-win

Si tienes un equipo con oficina física (nada de remoto, este es otro tema), deberías unirte a ofrecer un puesto a visitantes como yo.

Piensa lo barato que sale el hecho de tener a un profesional que puede ver el funcionamiento de tu equipo y darte una idea que te permita mejorar tus procesos ahorrando costes, que ahora puedes invertir en algo que te haga falta y todo por el uso de una silla, un escritorio y acceso a tu wifi.

Como dije un win-­win.

Foto de la visita desksurfing de Juan Vázquez con el equipo de Elemento115

Un selfie de Juan con el equipo de Elemento115

Tanto si eres nuevo en esto del desksurfing como si eres veterano, si estás o pasas por Madrid tienes que hacerles una visita a los compañeros de Elemento115 para vivir el buen rollo que tienen siempre (mira que son majos los joios) y por descubrir que hay formas de vivir tranquilos y sin presiones, si se tiene todo planeado cómo debe ser.

¡Nos vemos en la siguiente visita a Madrid!

__

Juan Vázquez, desarrollador Ruby y cofundador de Sociack
@jnillo9

¿Y qué hacemos con jQuery? (parte 2)

jQuery vs JavaScript

Planteadas en nuestro artículo anterior las ventajas e inconvenientes de utilizar jQuery, llega la hora de decidir qué hacemos con él. Y para ello el primer paso es responderse a una pregunta:

¿Qué necesidades de JavaScript tengo como desarrollador?

Es difícil encontrar una respuesta que no requiera una explicación de miles de píxeles de longitud, así que vamos a tomar el caso de un estudio como Elemento115, y pensar en los proyectos más recientes que tengamos. Eso nos permitirá limitar los casos de estudio.

Para empezar debemos distinguir entre proyectos de webs puramente comerciales, como microsites o páginas clásicas de empresa tipo “quiénes somos-productos-servicios-contacto“, y web apps, que son algo más complejas, en funcionalidad, evolución y tecnología. La definición del tipo de proyectos que encontramos en internet es bastante más poliédrica que está simple categorización, pero como primer acercamiento nos puede servir.

Pueden servir como ejemplo, en nuestro caso, Titanio Estudio y Zio Rød Brand Consultants.

En el primer caso nos encontramos con unas necesidades de JavaScript muy básicas: mostrar/ocultar elementos, plegar/desplegar secciones, añadir algún efecto visual, validar formularios… en general acciones que tienen mucho que ver con el filtrado y manipulación de elementos del DOM, y la aplicación de animaciones sobre ellos.

Moviendo elementos en el DOM

¿Y lo bien que lo pasamos moviendo cosas por el DOM?

En el segundo, a lo anterior se le unen peticiones AJAX, preparación, envío, recepción y procesado de datos (que pueden llegar a ser bastante grandes y complejos), almacenamiento local de información, gestión dinámica del contenido, exportación del código a Mobile App… en definitiva, un conjunto de funcionalidades que requieren de una buena estructura del código que permita que sea robusto, escalable y testeable.

Código de un fichero JSON

El JSON. ese gran amigo

Definidas las necesidades, hay que pensar cuál es la mejor opción para satisfacerlas.

¿Es jQuery la alternativa que más me conviene?

Esta es la pregunta del millón, y el motivo de estos dos artículos. Y la respuesta es… depende.

Para proyectos muy sencillos, las ventajas de jQuery se ven potenciadas pues nos permiten alcanzar resultados muy óptimos en muy poco tiempo, y por la propia naturaleza del proyecto será raro que nos encontremos algunos de sus inconvenientes, o al menos no de forma que nos afecte demasiado. Por estos mismos motivos podemos llegar a plantearnos usarlo si es que seguimos una metodología en la existe una entrega rápida de prototipos funcionales de forma recurrente.

En el caso de web apps, podemos empezar a dudar, y con motivo. Si bien es cierto que muchos de ellos serían abordables y correctamente resolubles con una buena arquitectura basada en jQuery, puede que no sea lo más óptimo, pues nos obligará a hacer un trabajo extra para llevar la librería a los límites que queremos al no estar diseñada para ello, cuando usando Vanilla JS podríamos obtener los mismos resultados de forma más natural y con un código más fácil de testear y exportar.

Si a esto se le unen otros factores como el equipo de desarrollo con el que cuentes, el tiempo del que dispongaslos navegadores a los que tengas que dar soporte, la deuda técnica que seas capaz de asumir… hay tantos factores con tantas posibles alternativas que resulta imposible elaborar una respuesta absoluta. Para cada caso habrá que tener en cuenta las conclusiones anteriores y analizar, según los factores externos, qué es lo mejor.

¿Entonces?

Como hemos visto, el escenario que se nos presenta no es sencillo: multitud de situaciones iniciales distintas, y variedad de ventajas e inconvenientes de cada decisión, lo que nos lleva a la imposibilidad de encontrar una respuesta clara a la pregunta que nos hacíamos al inicio: ¿qué hacemos con jQuery?

Existiendo alternativas a muchas de las cosas para las que veníamos usándolo, quizá la mejor opción sea la de casi siempre: no tomar ninguna decisión radical, empezar a probar desde ya mismo a hacer proyectos sin jQuery y evaluar el proceso. Y poco a poco, sin abandonarlo del todo, ir añadiendo a nuestro repertorio técnico el Vanilla JS de la misma forma que en su momento hemos hecho con otras tecnologías, hasta llegar al punto de disponer de un elemento más con el que decidir cómo abordamos los proyectos.

Porque, que no se nos olvide en medio de esta vorágine tecnófila, lo importante en nuestra profesión es resolver problemas de la mejor forma posible. La herramienta que utilicemos para ello no importa.

El Grid que Gotham necesitaba

La semana pasada llegaba, de la mano de Firefox 52, la primera versión definitiva en producción de Grid Layout. Dos días más tarde le seguía Chrome 57, y es de esperar que Safari lo haga en breve, incluso han publicado ya un artículo en su blog con una introducción a Grid. A Edge de momento no se le espera, salvo soportando la anterior especificación.

La importancia, posibilidades e impacto que tendrá en la forma de trabajar, la poco habitual simultaneidad en el soporte de los principales navegadores, así como el largo y tortuoso camino seguido hasta llegar aquí, hacen de este lanzamiento uno de los eventos más importantes en la historia reciente de CSS.

Pese a que no han faltado los primeros bugs en Chrome, con extraño diagnóstico incluído, parece el momento adecuado para leer el estupendo tutorial de Rachel Andrew, esta guía tan completa o tal vez prefiramos empezar con el sencillo inicio que propone CSS-Tricks, en donde nos encotramos una cita de Jen Simmons que convendría no perder de vista:

We need to explore CSS Grid until we understand what it wants to do, what it can be forced into doing, and what it refuses to do. Many designers may not ever learn to code CSS, but you need to understand CSS well enough to understand our artistic medium.

No sería la primera vez que la llegada de una nueva tecnología, o incluso una forma totalmente nueva de abordar el trabajo, nos lleva a forzar los límites y caer en un uso incorrecto de la misma. Leamos, aprendamos, pongamos en práctica y disfrutemos. Se nos acaba de abrir un nuevo horizonte 🙂