Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce)

10 min readNov 14, 2021

Tras la explicación más teórica de los conceptos de desarrollo iterativo e incremental y que esperamos de cada incremento ¿Cómo encontramos estos incrementos? En el post anterior hablamos del proceso que uso para facilitar hacer vertical slicing y voy a intentar ponerlo en práctica en varios ejemplos.

Disclaimer: Los ejercicios son ejemplos, más o menos reales, pero ni son ejercicios deterministas, ya que dependen del contexto, la tecnología, el código que tengamos, ni es la solución única de implementación. Es una aplicación práctica de los pasos del proceso a varios ejemplos. Si lo hacéis vosotros mismos, es muy posible que os puedan salir otros incrementos, otras actividades necesarias y otro tipo de implementación.

Ejemplo práctico — Checkout de e-commerce:

El primero de los casos es intentar encontrar los incrementos al crear una página de checkout de un e-commerce. La página donde vemos la lista de elementos que queremos comprar, añadimos los datos necesarios y pagamos con el medio que deseemos.

1. Preparar un primer problema grande

Este paso lo vamos a obviar, ya que para cerrar el contexto del ejercicio asumimos que entendemos y tenemos claro el porqué, el para quien es y el para qué lo necesita.

2. Encontrar las actividades necesarias (funcionalidades, capacidades o comportamientos)

¿Cuales son las actividades o comportamientos que necesitamos para solucionar el problema?. Las tres actividades o capacidades necesarias que identificamos en este caso son:

Ver resumen de compra.
Recoger los datos del usuario.
Seleccionar donde enviar
Pagar la compra.

3. Encontrar los conceptos de cada actividad que añadan complejidad

Si empezamos solo por Ver resumen de compra, los conceptos que pueden darnos dificultad o complejidad podrían ser.

Mostrar el coste de la compra.
Listar los artículos que vamos a comprar.
Que información de cada artículo vamos a mostrar.

4. Identificar todas las posibles variaciones

En este momento podemos usar toda la clase de patrones de splitting que muchas veces hemos visto — Por ejemplo aquí o aquí

Para el primer caso de mostrar el coste de la compra, las variaciones encontradas serían algo como: Podríamos no ver el coste → Podríamos ver el coste total de toda la compra → Podríamos mostrar el coste de cada artículo y luego la suma de estos

Para listar los artículos podríamos usar un patrón “0,1,many”: Podriamos no listarlos → Listar una compra de 1 solo artículo → Listar una compra de más de 1 artículo.

Finalmente, para splittear que información de los artículos mostrar, podríamos: Mostrar solo una lista con el nombre del artículo → Mostrar además una foto de cada artículo → Hacer que cada artículo tenga un link

Para el resto de las actividades haríamos lo mismo. Quedaría algo como el siguiente dibujo.

Para recoger datos del usuario, conceptos que nos añadirán complejidad pueden ser: si el usuario esta registrado o no, cómo vamos a recoger el nombre o como vamos a pedir el email.

Al igual que para pagar, conceptos como el tipo de pago o si aplicamos descuento, serán complejidades a las que tendremos que buscar patrones para sus variaciones.

5. Reducir todas las posibles variaciones a una — Vertical slicing

¿Cuál es el primero pequeño incremento? ¿Cuál es la primera versión básica de nuestro sistema al completo? El primer incremento de cada actividad que nos dará feedback de si vamos por buen camino o no

Para la primera actividad, obtener un resumen de compra donde solo veamos el coste total de una compra de 1 solo artículo y sin más información que la lista de 1 artículo.
Para los datos del usuario, de inicio, con solo recoger el e-mail de un usuario no registrado y únicamente 1 dirección nos valdrá.
Finalmente con probar como pagar con Paypal, sin tener en cuenta ningún descuento, puede ser una primera versión básica suficiente.

El conjunto de todos estos incrementos mínimos será nuestro primer incremento vertical.

El objetivo es tener una versión básica del sistema, con funcionalidades básicas — no las funcionalidades finales — que nos pueden dar feedback de la complejidad a la que nos vamos a enfrentar y que podamos ir haciendo crecer incremento a incremento.

6. Desarrollar en baby steps iterativos e incrementales

Ahora que tenemos un primer slice vertical, tendremos que implementarlo. Volveremos al paso 2, ahora con esta primera versión del sistema, para encontrar de nuevo pequeños incrementos o baby steps.

Esta vez tendremos que adentrarnos en la parte técnica, más cercana a la complejidad de la solución que la del problema. En esta parte considero buena opción empezar a hablar de diseño y arquitectura si hiciera falta. En este caso para ayudar al ejemplo, he supuesto un tipo de aplicación y servicios sobre la cual vamos a desarrollar este checkout.

Encontrar las actividades o tareas del sistema.

Creo importante advertir que no serán tareas de desarrollo, sino funcionalidades o comportamientos que mi sistema va a necesitar implementar para realizar lo que necesita. No va a ser nada como “implementar el endpoint del servicio”, sino algo funcional:

Una vez detectadas las actividades necesarias del sistema, pararíamos a encontrar los conceptos que nos van a añadir complejidad de cada actividad.

Encontrar los conceptos de cada actividad que añadan complejidad y sus variaciones

Si hablamos solo de la parte de mostrar una lista de una compra de 1 artículo y su coste total, los conceptos a trabajar serían seguramente:

Diseño visual de la lista: CSS básico → CSS más bonito
Mostrar la compra: Una compra hardcodeada → una compra recibida desde el servicio
Recibir la compra del servicio: No recibir ningúna compra (nos vale con la hardcodeada) → recibir una compra del servicio pero hardcodeada en el servicio → Recibir una compra real de la base de datos desde el servicio

Para el caso de recoger la información del usuario y decidir la dirección donde enviar, haremos el mismo proceso.

Nos surgirán algunas variantes como hardcodear la información y poco a poco ir implementando una funcionalidad más real recogiendo de alguna forma datos más reales. O bien, no checkear los posibles datos erroneos o no mostrar ningún error y poco a poco implementar más complejidad en cada variante.

Haremos lo mismo para la parte del pago y obtendremos algo parecido a esto.

Reducir todas las variaciones a una — Vertical Slicing y baby steps

Una vez tengamos identificado las variaciones, deberíamos seguir los mismos pasos que anteriormente. ¿Cuál es el mínimo incremento necesario para avanzar? ¿Cuál es el primer baby step a implementar?

Para encontrar el primer incremento, la pregunta más adecuada sería ¿Cuál es el feedback que buscamos? ¿Cuál es la incertidumbre que deseamos resolver cuanto antes? Siempre buscaremos resolver estas preguntas con software funcionando. Seguramente un software muy básico, pero software funcional.

Os expongo varios ejemplos:

Si primero quisiéramos conocer si nuestra lista de la compra encaja bien en el diseño de la APP, un primer incremento podría ser algo como esto:

Solo tener el CSS mínimo para obtener ese feedback y no pensar en ni cómo conectarnos al servicio, sino suplirlo con una compra hardcodeada. “Pero Abraham, ¡esto es solo frontend!”. Aquí lo que decide si es buen baby step o no, es el feedback que necesitamos. Puede ser que solo sea una parte de la funcionalidad supliendo el resto del sistema de forma muy básica.

Imaginemos que no nos interesa la parte más visual, sino realmente empezar a reducir incertidumbre respecto a la conexión y a como funciona el servicio de carrito. Ya sea porque no lo conocemos, porque es un servicio muy legacy o porque no lo hemos usado nunca. En este caso, un primer incremento puede ser algo así:

Con un CSS básico que nos muestre una compra recibida del servicio, sin embargo, esta compra será hardcodeada en el propio servicio, sin necesidad de ir a la base de datos ni implementar más que lo básico para saber cómo conectarnos al servicio. Recordad que es un primer incremento, para nada nos vamos a quedar en este paso.

El mindset que debemos tener es el mismo que para usar TDD. No te quedas en el primer test, vas avanzando en el desarrollo de la solución con muy pequeños nuevos tests que van completando la solución, pero no tratas de saltar a la solución final desde el inicio.

Los baby steps también van a variar dependiendo de ese conocimiento o incertidumbre que tengamos. Podríamos tener mucho conocimiento y considerar que es algo muy simple usar la base de datos para tener ya una compra real con la cual recibir feedback.

Mi recomendación aquí es que no pequemos de optimistas, detectemos bien en que modelo del Cynefin nos encontramos. Si es algo complejo, no dudemos en ir muy paso a paso sin dar grande saltos.

Haremos lo mismo para la parte de recoger datos y la dirección

El primer baby step nos dará feedback de cómo tenemos que trabajar con el servicio de usuario. Otro caso, igual de válido, puede ser tener un conocimiento de una librería que nos facilita varias de estas variaciones de una vez de forma simple. En este caso, puede que el siguiente baby step sea de varias variaciones a la vez. No obstante, pensad que es por la simpleza de utilizar esta librería, vuelvo a recomendar no pecar de optimismo en un entorno complejo.

Terminamos esta parte de encontrar los baby steps con la parte de pagos.

Un primer paso puede ser descubrir cómo funciona Paypal, hardcodeando un coste y mandándolo a la API de Paypal. Más adelante podemos empezar a ver cómo recoger un coste desde el servicio para desarrollar la conexión con este. Igualmente, puede que no necesitemos ni que sea de una compra real, sino un coste hardcodeado en el servicio. Todo dependerá de la incertidumbre, complejidad y desconocimiento que tengamos del sistema.

Una vez hayamos ido completando baby step a baby step, tendremos una versión básica del sistema al completo. Ahora es hora de seguir con siguientes incrementos.

Estos siguientes incrementos no tienen porque ser otro corte vertical de todo el sistema, sino pequeños avances del sistema básico ya creado y decidiremos cuál es el siguiente paso dependiendo de lo aprendido, del feedback y de la complejidad del problema a resolver.

En nuestro ejemplo, bien puede ser añadir el coste por artículo y mostrar una compra de más de un artículo para que tenga sentido el incremento. Bien puede ser empezar a recoger el nombre del usuario o también podemos seguir incrementando la parte de pago añadiendo un descuento por ejemplo.

Una recomendación es no intentar avanzar e incrementar una actividad sin ir incrementando las demás de forma más o menos equivalente, ya que podremos encontrarnos con problemas al tomar decisiones aislando una actividad del resto del sistema.

Os dejo también algunos links de patrones para splittear que se suelen utilizar. Pueden servirnos de igual forma para encontrar tanto actividades como variaciones en nuestra búsqueda de incrementos.

Vertical Slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental.
Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos.
Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce).
Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD).
Vertical Slicing (V) — Ejemplo práctico (Bot en Slack para traducir mensajes)
Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos
(Próximamente) Vertical Slicing (y VIII) — Facilitación del Workshop.
Slides del workshop.