Slicing: ¿Cómo aplicarlo?

Si vivir de la agilidad nos ha enseñado algo, es que todo siempre sonará muy bonito cuando comenzamos a aprenderlo. Y aquí no discriminamos si la lección vino de una ilustración de internet, de una profunda reflexión con tu amigo que se autodenominó Coach, o de esas viejas presentaciones que nos enviaron con la exclusiva condición de que no la compartiríamos con nadie (Y después igual la compartimos).

Todo es hermoso hasta que lo aterrizamos un poco y comenzamos a replantearnos algunas minucias que en la teoría no se logran asomar a la superficie de nuestra corteza, y que sólo cuando queremos ponernos a prueba surgen a flote ¿Y cómo aplico esto en la vida real? ¿Realmente puedo hacerlo?

Por lo mismo, como no nos gusta dejar las cosas a medias, y porque algunos de ustedes llevan un buen tiempo solicitándolo en nuestras redes, seguimos con la continuación de nuestro artículo de Slicing, esta vez enfocados completamente en el «cómo hacerlos«.

Pero antes, debemos dejar en claro que, para poder llegar a esto, es necesario entender que lo que intentamos es entregar valor de forma constante, y que, para logarlo, el concepto de Mínimo Producto Viable es algo que todos dentro del equipo deben tener en claro, y compartir. Aquí lo perfecto es enemigo de lo bueno. Con eso aclarado, vamos con las estrategias:

SLICING HORIZONTAL VS SLICING VERTICAL.

El Slicing Horizontal, es una división realizada por las capas técnicas de nuestro proceso. Equivale a realizar en primera instancia la capa de Diseño, luego la BACK, y luego capa FRONT (O a tostar 10 panes, y no ponerle mantequilla a ninguno). Hacemos el trabajo a medias de manera satisfactoria, pero no le estamos entregando valor a nadie hasta que hayamos finalizado el flujo completo, puesto que la otra mitad aún debe ser completada.

Esto nos lleva a generar pequeñas cascadas en nuestro trabajo, que, si bien nos ayuda a marcar las pequeñas etapas de este, no nos facilitan la priorización, la retroalimentación, ni la optimización de nuestro trabajo, ya que todo debe ser terminado para continuar. En el fondo, no estamos reduciendo nuestro trabajo, sólo lo marcamos para entenderlo mejor.

El Slicing Vertical, por otra parte, es un corte realizado por capas funcionales. No terminar todo el Front, ni el Back, pero sí integrar una parte de estos (Entregar 2 tostadas con mantequilla de las 10 prometidas). De esta manera si bien no estamos completando todas las tareas pendientes, estamos generando un valor temprano que facilita la retroalimentación, la priorización y la forma en la cual nos enfrentamos a la realidad cambiantes, y que por supuesto nos cuesta mucho menos terminar.

¿Suena sencillo? Claro, porque hablamos de pan tostado. Pero con Software u otros productos la cosa suele ser más complicada. Tranquilo, ahora vamos a ver cómo podemos aplicarlo.

MÉTODO SPIDR
Hablaremos de SPIDR como una sugerencia de criterios que se pueden aplicar con facilidad una vez que estás trabajando con historias de usuario, y contamos con que al menos dos de estos podrán servirte para gestionar mejor tu trabajo. SPIDR es el acrónimo de SPIKE, PATH, INTERFACES, DATA y RULES.

P de PATH
Caminos, rutas o flujos. Si nos imaginamos a nuestro usuario, sabremos que este cuando quiera realizar cualquier funcionalidad en nuestra aplicación, tendrá que seguir una serie de pasos ordenados con un inicio y un final marcado.

Hacer un Slicing por flujo o camino, indica que debemos priorizar la ruta más escogida o que más valor nos añada, y que trabajemos de manera separada las múltiples salidas o entradas que puedan surgir de este camino. Por ejemplo, en un flujo de pago online, una de las salidas puede ser el pago mediante WEBPAY, mientras que otra puede ser el pago con tarjeta de crédito.
¿Es necesario que nuestra aplicación contemple todos los casos bordes al momento de presentarla a nuestro usuario final?

I de INTERFACES

Pantallas, perfiles y formas de interactuar con nuestro producto. Puede referirse al tipo de dispositivo, de navegador, o aplicación que se utilice para acceder a nuestras funcionalidades. Para esto, se debe priorizar el más frecuentado o que más valor le entregue al negocio, añadiendo como mejoras o como nuevas historias aquellos que vayan quedando en segundo lugar.

El ejemplo clásico es el de un sistema que debe funcionar tanto en el navegador como en una aplicación Mobile. A nivel web será necesario dividirlo en los diferentes navegadores que se pueden utilizar, y a nivel Mobile por el tiempo de sistema operativo o incluso por los tipos de resolución que aportará. ¿Es necesario que al momento de lanzar nuestra aplicación funcione en absolutamente todos los dispositivos y navegadores?

D de DATOS
Y con datos nos referimos a todos esos campos o tipos de información que, si bien nos faciliten la vida en la interacción, sean complejos de implementar en un inicio. Lo ideal sería dar prioridad a lo más universal, para luego centrarnos en lo específico.

Un ejemplo sencillo son los campos de un formulario que en primera instancia podrían ser todos de tipo TEXTO, para luego en un incremento poner esos hermosos calendarios interactivos para rellenar las fechas, los filtros para buscar información entre varios formularios, o los campos específicos del negocio. ¿Es necesario que el formulario sea perfecto desde un inicio, o podemos ir añadiendo funciones que permitan completarlo más fácilmente a modo de incremento?

R de REGLAS DE NEGOCIO

Es decir, todos aquellos requerimientos o condiciones que deba tener una historia como factor diferenciador. Por lo mismo, es necesario hacer un buen trabajo de priorización (en este artículo te enseñamos como, y en este) para poder definir qué es lo que será integrado inicialmente, y qué puede ser incorporado como un incremento a lo largo del desarrollo.

En general suele ser mucho más sencillo cuando se trabaja con criterios de aceptación, ya que, si estos comienzan a ser demasiado complejos con respecto al alcance inicial de la historia, podrían ser la línea punteada perfecta para hacer el corte.

Como ejemplo clásico, tomaremos un Login de Usuario que además de ser funcional, mantiene las típicas reglas de seguridad: Formato de Password, cantidad de intentos, conexión con Google, etc. ¿Es necesario en su primera fase que todas esas reglas estén siendo completadas? ¿Podríamos crear alguna como una nueva historia de usuario?

S DE SPIKE

Y dejamos para el final aquella opción confiable a la que siempre podemos recurrir cuando lo demás ha fallado (A pesar de ser la primera dentro del acrónimo). Los Spikes son un término utilizado para definir pruebas de concepto, es decir: Elaboración de prototipos, validación de supuestos, factibilidad técnica o incluso reducción de incertidumbre.

En el fondo es generar una nueva historia de investigación que nos permita tomar las mejores decisiones para poder enfrentar una historia que ya de por sí es grande por su complejidad o incertidumbre, pudiendo generar planes de acción para abordarla de mejor manera en nuestras planificaciones o refinamientos, solidificando su alcance y añadiendo más detalles a su descripción.

Por ejemplo, el equipo debe sincronizar su desarrollo con un sistema legado con el que nunca ha trabajo, por lo que podría generar una historia bien pesada y cuyo éxito se encuentra lleno de riesgos, o podría generar una SPIKE de investigación para validar si dicho sistema es compatible con el desarrollo actual, y en caso contrario, permitirle al equipo evaluar cuál sería el mejor modo de abordar esta integración.

¡Y ya! Esperamos que te sean de utilidad para simplificar esos refinamientos interminables, para tener mejores planificaciones de Sprint, y para evitar ese carry over tan molesto que se genera por tomar cosas muy pesadas. Como ves, el tema del Slicing da para largo, y nosotros mismos decidimos cortar este artículo en dos partes para que así sea más sencillo de comprender y de elaborar. ¡Esperamos que te añada valor!

Si te interesa aprender más sobre Scrum como marco de trabajo, te recomendamos mucho «Scrum, el arte de hacer el doble de cosas en la mitad del tiempo«. Si quieres aprender sobre el principal mecanismo de mejora de Scrum, te recomendamos «Retrospectivas: Haciendo buenos equipos, mejores«. Y si te interesa contactarte con un equipo que apoye a tu organización a adoptar una cultura más agile, te recomendamos enviarle un mensaje a nuestro partner BlackHat y ver qué opciones tienen para ti.