Dilemas del Slicing

Veníamos haciendo un muy buen trabajo slicing, en realidad no se si tan bueno pero yo me sentía muy cómodo. Primero definimos las stories, hacíamos alguna apertura en tarea y si nos parecía muy grande/complejo, abríamos una story. Finalmente hacíamos una puntuación a modo de doble validación. En términos de puntuación todas nuestras stories eran 1, 2 o 3.

Pero resulta que en la última planning, nos encontramos con una story puntuada en 5. ¡Recórchilis! Intentamos buscarle la vuelta para partirla pero no lo logramos. Entonces uno de los muchachos sugirió partir la story en front y back, ya que tan front como back son tecnología distintas, repos distintos y artefactos de runtime distintos.

He aquí el dilema:

  • Opción 1: planificar una story demasiado grande.

  • Opción 2: partir la story en dos stories donde cada una en forma independiente no agrega valor.

La opción 2 para mi no era válida, con lo cual decidimos ir por la opción 1. Personalmente me hacía mucho ruido el 5, pero internamente yo estaba convencido que la story estaba más cerca de un 3 que de un 5.

La semana próxima les cuento que tal nos fue.

La clave está en cortar finito: Slicing

La clave está en cortar finito: Slicing

Uno de los desafíos de mi proyecto actual está en lograr un entregable de valor en pocas semanas y la clave para lograr eso es poder cortar las funcionalidades bien “finitas”, lo que en la jerga agile suele denominarse slicing.

El tema con el slicing es que no es fácil de hacerlo y en ocasiones se lleva a cabo de forma inapropiada por no involucrar a todos los perfiles necesarios. En este sentido, para poder hacer un buen slicing es necesario:

  • Gente de negocio que conozca perfectamente el negocio y particularmente el subdominio de la aplicación en desarrollo
  • Gente técnica que sea capaz de entender las funcionalidades y pueda dimensionarlas en términos de complejidad y costo de implementación.
  • Gente con poder de decisión

La falta de cualquiera de estos tres grupos resulta riesgoso ya que uno podría terminar generando un incremento funcionalmente pequeño pero técnicamente demasiado grande o un incremento técnicamente manejable pero sin valor de negocio o incluso un incremente pequeño, tanto funcional como técnicamente, pero sin apoyo “respaldo político” para su realización.