Construyendo el Producto Correcto y Construyéndolo Correctamente: Extreme Programming y Atomic Design

Bienvenidos a esta charla, donde les contaré un poco sobre programación extrema y diseño atómico. Primero lo primero. Hola, mi nombre es Rita. Soy una apasionada de la tecnología y también me gusta practicar deportes. También soy madre, lo que significa que cuando no estoy con mi familia, probablemente esté trabajando. Trabajo en el Centro de Desarrollo de Software de Volkswagen aquí en Lisboa y estos son mis increíbles colegas y compañeros de equipo.

Así que en esta charla, intentaré contarles un poco sobre cómo construir el producto adecuado. Desde mi punto de vista, creo que un buen producto debe estar impulsado por el usuario y debe ser un producto digital, teniendo esto en cuenta. Y debe hacerse utilizando interfaces de usuario consistentes y de calidad, porque quieres que tus usuarios se involucren con él. ¿Y cómo puedes construirlo correctamente? Bueno, debes tener pruebas para ello. Las pruebas son una parte importante del desarrollo de software. Y de hecho, son tan importantes como la forma en que se realizan. Y para mí, la mejor manera de hacer pruebas es mediante el desarrollo guiado por pruebas. Esto significa escribir tus pruebas antes de comenzar a escribir cualquier tipo de código de producción. Por otro lado, y dado que esto es el React Summit, por supuesto que quieres pasar de los diseños a React. Entonces, quieres tener una forma fácil de traducir lo que tienes desde tus diseños a React. ¿Cómo podemos lograr esto? Esto es lo que me estoy preparando para contarles y hablarles. Así que el Centro de Desarrollo de Software en Lisboa. Se creó en 2018. Fue el primer centro de desarrollo que Volkswagen abrió fuera de Alemania. Y eligieron hacerlo en Lisboa. No lo hubiera pensado. Y les agradezco por eso, así que me uní. Ya conocía y ya había hecho desarrollo guiado por pruebas y solía trabajar en un marco ágil. Digamos que aportaron algo nuevo, algo diferente, que fue XP y equipos equilibrados. XP significa programación extrema y fue creado en 1996 por Kent Beck. Es una forma ágil de desarrollar software. Está dirigido principalmente a los desarrolladores, pero el resto del equipo de desarrollo también puede aprovechar mucho de lo que XP representa y lo que abarca en su núcleo y qué abarca en su núcleo. Está impulsado por cinco valores fundamentales, el valor de la comunicación, mantener el chat y la conversación en marcha dentro de tu equipo, porque con esto, puedes compartir información, puedes transferir conocimientos de una persona a otra,

independientemente del rol que tengan en tu equipo. La simplicidad, al construir el producto, constrúyelo de la manera más sencilla posible. ¿Por qué? Para que puedas obtener comentarios de manera realmente, realmente frecuente. No quieres estar desarrollando algo que los usuarios no necesiten, o que los usuarios no quieran, o que esté mal desarrollado e inutilizable. Así que obtén comentarios lo más rápido posible. Ten el coraje de desechar las cosas si no son lo que el usuario necesita o quiere, sin importar cuánto hayas invertido en ello. Y lo más importante, ten respeto entre tu equipo. Cada decisión que tomes para tu producto es una decisión de equipo. No es algo que hagas solo. La voz de todos es escuchada. La voz de todos es respetada. Las opiniones valen la pena.

y puedes expresarlos en voz alta. Sin embargo, estos valores, son un poco vacíos si no tienes algún tipo de prácticas en las que puedas aplicarlos. Por lo tanto, las dos prácticas que destacamos de XP son la programación en pareja y el desarrollo guiado por pruebas. La programación en pareja es importante porque te permite, nuevamente, compartir la comunicación y el conocimiento entre ustedes. Entonces, independientemente de tu rol en el equipo, trabajarás en pareja. Trabajarás con alguien que compartirá la información en la que te estás basando. El desarrollo guiado por pruebas, para que hagas solo lo necesario para poner en marcha tu funcionalidad. ¿Dónde hacemos esto? En equipos integrados y equilibrados. ¿Qué son entonces? Están compuestos por diseñadores, gestores de productos y desarrolladores, nosotros. ¿Qué aportan los diseñadores? Bueno, son el puente entre el equipo y los usuarios. Comprenden cuáles son los puntos problemáticos que tienen los usuarios y proponen soluciones para facilitarles la vida. ¿Qué hacen los gestores de productos? Bueno, se encargan del dinero y desglosan las funcionalidades que queremos construir para nuestro producto en historias que nosotros, los desarrolladores, podemos hacer. ¿Y qué hacemos nosotros? Bueno, además de programar, también somos los responsables de evaluar si algo es factible de hacer. Somos los guardianes de la tecnología, pero también somos los responsables de evaluar la viabilidad del producto. ¿Qué sucede cuando todos trabajamos juntos? Sucede la magia. Eso es lo que sucede. En el SDC, yo. Así que, me uní en 2018, como te dije. Y ahora es 2021. ¿Qué he hecho en el medio? Aparte de tener el kit, he trabajado en cuatro productos diferentes. Todos ellos tenían React como su framework de frontend. ¿Por qué elegimos eso? Porque, citando la documentación de React, se supone que React hace nuestra vida mucho más fácil. Se supone que facilita la creación de interfaces de usuario interactivas. Y deberías poder construir componentes encapsulados para hacer estas interfaces de usuario de una manera fácil y buena. Sin embargo, solíamos seguir el desarrollo impulsado por funcionalidades, al menos una adaptación suelta de ello. Lo que significa que para cada funcionalidad que queríamos desarrollar dentro de nuestro código o dentro de nuestro producto, tendríamos una carpeta para ello y luego comenzaríamos a anidar las cosas que son específicas de esa funcionalidad en ella. Y si teníamos componentes que se reutilizarían y compartirían en varias funcionalidades, los extraeríamos a la carpeta de componentes. Pero luego, a medida que los productos comenzaron a crecer, las funcionalidades se volvieron un poco demasiado abarrotadas, por así decirlo. Así que tuvimos que encontrar una forma diferente de organizar nuestro código

Ingresa al diseño atómico. ¿Qué es? Es una metodología de diseño que se utiliza para crear y mantener cualquier cosa en el sistema de diseño. Fue creado por Brad Frost en 2013. Está compuesto por cinco niveles diferentes de elementos.

Ten en cuenta que este es un marco de diseño, por lo que vamos a hacer una adaptación de un marco de diseño a React. ¿Cómo está estructurado? Hay átomos, que son los elementos más básicos de todos. Si combinas átomos, obtendrás moléculas. Si combinas moléculas con otros átomos, o eventualmente moléculas y organismos, obtendrás organismos. Y cuando defines, cuando construyes el diseño y decides dónde va cada cosa, tienes una plantilla. Y cuando seleccionas los organismos y los colocas en tu plantilla, obtienes páginas. Es un flujo lineal para construir tu interfaz de usuario y es bastante fácil. Teniendo esto en mente, te contaré la experiencia que estamos teniendo actualmente en el SDC. Estamos tratando de resolver un problema o lo que percibimos como un problema de los concesionarios que venden automóviles. Imagina que eres un concesionario, vendes un automóvil. Vendes otro automóvil mañana a un cliente diferente y mañana y mañana y mañana. Entonces, vendes muchos automóviles porque eres bueno en ello. En promedio, los concesionarios venden alrededor de 20 automóviles al mes y cada uno de estos automóviles, cada uno de estos pedidos, tarda alrededor de tres meses en completarse. Por lo tanto, dentro de este período de tiempo, el concesionario necesita realizar un seguimiento del estado del pedido. ¿El automóvil está aquí, está a punto de llegar? ¿Está retrasado? Bueno, si no te comunicas con tu cliente, es muy probable que el cliente recoja el teléfono y llame para preguntar: `Oye, ¿dónde está mi automóvil?`. Y eso es un problema porque entonces el concesionario tiene que poder encontrar la información sobre el pedido de ese cliente muy, muy rápido porque no quieres que se sientan frustrados. ¿Cómo puedo contarte todo esto? Porque hicimos muchas entrevistas con los concesionarios para comprender los puntos problemáticos y las necesidades que tienen. Con eso, nuestros diseñadores formularon tres suposiciones. La primera es que los concesionarios desean conocer el estado de sus pedidos. La segunda es que desean estar actualizados sobre ese estado. Y la tercera es que desean poder compartir esa información con los clientes. Dado eso, creemos que podemos idear algo. Nosotros, los desarrolladores, verificamos si sería posible obtener información de los pedidos. Sí, porque podemos integrarnos con sistemas que son realmente antiguos, pero podemos extraer información y proporcionarla a los concesionarios. ¿Podemos integrarlo en un producto que ya utilizan los concesionarios, para que esto no sea solo otra herramienta que tengan que usar? Sí,

también puede lograr eso. Entonces, estamos del lado correcto. En ese caso, corresponde a los diseñadores crear algo que llamamos el recorrido del usuario. El recorrido del concesionario, en este caso, porque el usuario es un concesionario. ¿Y qué es? Entonces, abres tu navegador, tienes un panel de control con información sobre todos los pedidos que tienes. De un vistazo desde arriba, puedes ver la información sobre los otros pedidos en un conjunto de pestañas. Debajo de las pestañas, tienes información sobre todos los pedidos que tienes disponibles. Imagina que Lisa Marie llama, hey, quiero saber qué le pasa a mi auto. El concesionario hace clic en el botón que dice Ver detalles y se lleva a una página diferente, la página de Detalles. En la página de Detalles, puedes ver los detalles de Lisa Marie. Entonces, toda la información sobre el pedido o la información que se consideró relevante sobre el pedido, y verificas el estado del pedido. ¿Cómo está? ¿El auto está retrasado? ¿Está en producción? ¿Está llegando al país, etc.? Dado esto, y teniendo un poco de retroceso al comienzo de esta charla, el hecho de que sea impulsado por el usuario y que queramos hacer desarrollo impulsado por pruebas para nuestro producto, esto significa, y el hecho de que quieras tener una forma fácil de pasar de design a código con interfaces de usuario coherentes, bueno, para el primero, usemos la biblioteca de pruebas de React. Es realmente, realmente buena, es sólida y hace lo que queremos. Para la parte de design, usemos el Marco Atómico que acabo de presentarte. Entonces, en realidad, no estamos haciendo más que usar XP con el Design Atómico. Veamos cómo va. Entonces, comencemos. ¿Y por dónde? Escribiendo una prueba fallida, porque así es como funciona el flujo de desarrollo impulsado por pruebas. Pero, ¿qué prueba vamos a escribir? Buena pregunta. Comencemos pequeño. ¿Qué puede ser más pequeño que los átomos? Nada, en este caso. Así que, tomemos el

panel de control. Desde el panel de control, intentemos identificar algunos átomos de los diseños. De acuerdo, ya sabemos que son componentes indivisibles y nos proporcionarán las baldosas base de la interfaz de usuario, lo que significa que podemos tener el botón de ver detalles como un átomo, una fecha formateada como un átomo, texto como átomos, iconos, por decir algunos. Luego, podemos implementar una prueba para ello. Renderizas el botón de ver detalles. Esperas que el texto esté en el documento. Y esperas que haya un enlace que nos lleve a otro lugar. En este caso, React Summit en Ámsterdam. ¿Por qué no? Luego, luego, luego ejecutas la prueba. Cuando ejecutas la prueba, por supuesto que fallará porque tu implementación no tiene nada. ¿Qué haces? Cumplimentas la implementación para poder ver un texto que diga ver detalles. Ahí lo tienes. Hay un párrafo con ver detalles, esa parte de la prueba ha pasado, pero aún obtienes un error para el enlace. Sí, somos un poco traviesos aquí. Hicimos trampa un poco en la prueba porque, bueno, no es hacer trampa, estábamos jugando un poco. Así que con la programación en pareja, usualmente una persona hace una prueba, otra persona hace el código. Se llama ping pong. Y a veces quieres que la persona que escribe la prueba sea más específica y lo más objetivo posible para que no te deje espacio para interpretaciones libres con tu prueba. Así que dicho esto, bien, te daré un enlace. Y cuando tienes un enlace, tada, la prueba pasa y estamos listos para continuar. Un pequeño detalle es que estoy usando, en la prueba anterior que te mostré, un componente simulado para el enrutador DOM de React, así que en lugar de usar el enlace real, lo simulé. ¿Por qué? Para no tener que envolver el componente que estoy renderizando con el enrutador de memoria. No hay correcto o incorrecto, no hay bueno o malo en medio de esto, necesitas entender qué tiene sentido para ti y para tu equipo y mantenerlo. Así que, sé tú mismo. No hay correcto o incorrecto, decides qué es lo mejor. Entonces el equipo habla entre ellos y ven qué es lo mejor para ellos. Pero sea lo que sea que hagas, sé consistente.

Subiendo en la escala atómica, tenemos las moléculas. Moléculas. ¿Qué son las moléculas? Las moléculas son átomos unidos. Entonces, hacen algo que aporta funcionalidad.

La barra de búsqueda, el progreso del pedido, por ejemplo. Entonces, el progreso del pedido, tiene dos elementos, tiene el texto en tránsito y tiene el icono de tránsito. Es decir, renderizas la cosa, esperas que el texto esté ahí, esperas que el icono esté ahí. Excelente. Veamos cómo va. Lo tienes ahí. Es realmente, realmente fácil, es realmente, realmente rápido. A partir de los diseños.

A continuación, en la jerarquía, los organismos. Los organismos son una combinación de átomos, moléculas e incluso otros organismos. Y lo más importante de todo, aportan valor al usuario. Entonces, con el valor del usuario, ¿qué tienes? Tienes estos dos elementos principales. Entonces, la lista de pestañas y la lista de pedidos. Pero luego, construyamos una prueba para ello. Entonces, la lista de pedidos, necesita tener el texto que dice 'todos los pedidos' y necesita tener los componentes para la barra de búsqueda, los filtros y la tabla de pedidos. Suena bien. Pero luego lo estás simulando. Así que en este momento, necesitas poder entender y decidir qué quieres hacer, si simular o no simular. Así que una lista de pros y contras. Cuando estás simulando, es realmente, realmente bueno porque puedes encapsular todo. No necesitas conocer los detalles de los elementos que estás utilizando debajo del árbol y obtienes una vista clara de lo que estás utilizando. No puedes hacer trampa. Entonces, si quieres tener un texto, necesitas tener un texto, no un párrafo que diga texto. Y es realmente, realmente fácil para que los nuevos miembros del equipo se familiaricen con los nuevos conceptos. Sin embargo, nos alejamos un poco de la user experience. Tenemos un poco de renderizado superficial. Y a veces las simulaciones pueden ser complicadas. Especialmente si estás utilizando bibliotecas de terceros. Nuevamente, es una decisión del equipo elegir lo que es mejor. Y lo que puedo recomendarte es que encontrarás tu equilibrio si sigues este camino. Por un lado, tendrás pruebas unitarias.

Por otro lado, tendrás pruebas de integración. Entonces, para las pruebas unitarias, debes simular todos ellos. Esto te permitirá asegurarte de que estás utilizando los componentes correctos para construir tu producto. Pero luego, por otro lado, para las pruebas de integración, debes renderizarlos todos, porque así estarás seguro de que los estás utilizando correctamente. Y esto se asemeja un poco, o esto nos lleva de vuelta a una cita de Ken C. Dodds, el creador de la biblioteca de pruebas de React. Así que cuanto más se asemejen tus pruebas a tu software, más confianza te darán. Y eso es totalmente cierto. ¿Y por qué? Porque ahora podemos crear una prueba para el organismo de la lista de pedidos, en la cual, okay, sabemos que en la ruta tenemos la lista de pedidos. Y sabemos que eventualmente, cuando tengamos el enlace que nos llevará al pedido, estaremos en la página de detalles. Entonces, cuando abrimos la página o cuando renderizamos la página, esperamos que esté el encabezado de todos los pedidos. Luego esperamos que se muestren los contenidos de las filas. Por ejemplo, si estoy comprando un auto, espero que haya un botón de enlace para ver los detalles, y luego hago clic en él. Y cuando hago clic en él, me redirigen a una página diferente. Así que esto es bueno. Esta es una prueba valiosa. Esto se asemeja a cómo el usuario interactúa con tu software. Para completar, y para resumir, las plantillas y páginas. Si defines el diseño, colocas los organismos allí, obtienes una página. No puede ser tan simple como eso. La otra página que tenemos en nuestro design es la página de detalles. Se ve así. Está compuesta también. Tiene átomos, tiene moléculas y tiene organismos. Perfectamente bien. No vamos a profundizar en eso. Volvamos al recorrido del concesionario. Podemos escribir una prueba para el recorrido del concesionario, y se vería algo así. Renderizaste el panel de control, esperas

Esperas que esté en el panel de control, por lo que esperamos que la región del panel de control esté allí. Esperas ver las pestañas. También está bien. Dentro del panel de control, esperas ver todas las órdenes, esperas tener la barra de búsqueda para buscar todas las órdenes, esperas tener los filtros, para que puedas lograrlo con la implementación del panel de control. Eventualmente, realmente te gustaría poder ver información de la tabla. Para obtener algo de la tabla, puedes obtener la etiqueta DRV para una fila dada y luego hacer clic en el botón de enlace y poder ir al resto. Cuando vas al resto, sabes que ya no estás en la página del panel de control, sino que ahora estás en la página de detalles. Finalmente, has visto todo lo que hay que ver, haces clic en el botón de retroceso y cuando haces clic en el botón de retroceso, vuelves a la página de todas las órdenes. Así que las cosas están limpias, las cosas están bien y esto completa el recorrido del usuario. Con una prueba, una prueba algo grande, puedes realizar el recorrido completo del usuario descrito de la manera más cercana posible a la forma en que el usuario va a interactuar con tu software. Para resumir, realmente creo, es mi opinión personal, que cuando usas XP con Atomic Design, obtienes un punto muy favorable. Y este punto favorable es que puedes entregar software de alta calidad con interfaces de usuario consistentes y sólidas más rápido que nunca. Cualquier día de la semana, incluyendo los viernes. Muchas gracias por asistir. Hablaremos pronto. Puedes encontrarme en cualquiera de las redes sociales. ¡Adiós!