Dimensional Planning en Agile

En los últimos años he notado que hablo cada vez más sobre el "Dimensional Planning". Conocí el Dimensional Planning a través de Koen van Exem, uno de los primeros agilistas belgas. Proviene de los inicios del movimiento Agile (belga) y lamentablemente ha caído un poco en el olvido.

Ayer estuve hablando con JB (Rainsberger) y Alistair (Cockburn) sobre ello y me di cuenta de que tengo una historia interesante al respecto.

Antes de contártela, primero explicaré brevemente los fundamentos del Dimensional Planning. La idea es que dividimos nuestras Stories en diferentes dimensiones de implementación. Lo hacemos porque muchos de nuestros clientes quieren tener un Lexus al final de la semana. Quizás no podamos lograrlo. Sin embargo, podemos ofrecerles un Toyota mañana mismo. A la mayoría de los clientes les parece genial esta oferta y pueden esperar hasta que podamos entregar el Lexus (es decir, ROI rápido).

Me gusta mucho la forma en que Koen explica el Dimensional Planning

Imagina que tu cliente quiere una autopista entre Ámsterdam y Heusden. Tú eres bastante bueno construyendo autopistas, así que empiezas directamente. Después de algunos meses has terminado y, lleno de orgullo, dejas que tu cliente use la autopista por primera vez. Llega a Heusden, pero no parece muy contento. Le preguntas si las gasolineras, las áreas de descanso y las salidas cada pocos kilómetros están bien. Aunque el cliente lo confirma todo, tus preguntas parecen irritarle aún más. Finalmente dice: "¡Este no es el lugar al que quería ir!"

Miras el letrero del pueblo: Heusden. ¿No quería ir a Heusden? Sí, quería.

Pero resulta que hay otro lugar con el nombre "Heusden".

Tus abogados y los del cliente ahora tienen largas discusiones sobre de quién es la culpa y quién debe pagar por la autopista equivocada. (Si tienes un buen abogado, tu cliente pagará y nunca volverá...)

En este caso, se podría trabajar bien con Dimensional Planning. Primero se construiría un camino de grava entre Ámsterdam y Heusden.

En menos de una semana ya habrías terminado y habrías descubierto que has llegado al lugar equivocado. Para ti eso no es un problema, porque sabías que habría algún que otro malentendido. Te informas, encuentras el otro Heusden y construyes un nuevo camino de grava. Después de otra semana, este camino también está terminado y descubres junto con tu cliente que sigue siendo el Heusden equivocado. Resulta que hay dos lugares con ese nombre en Bélgica y uno más en los Países Bajos. ¿Quién lo habría imaginado?

Después de otra semana, tu cliente está contento de tener finalmente un camino de grava entre Ámsterdam y el Heusden correcto. (Y eso mucho más rápido que los meses originales.)

Aunque aún no tiene todos los features, ya hay cierta ganancia, ya que el cliente puede desplazarse entre las dos sedes de su empresa. No es una gran carretera y no se puede conducir muy rápido, pero es mucho más rápido que con la carretera anterior y un desvío de 100 km.

Al día siguiente de completar el camino de grava, empiezas a trabajar en una versión de adoquines de la carretera, que terminas después de tres semanas. También puedes trabajar en una versión de asfalto, alquitrán o autopista. En la mayoría de los casos, los clientes ya no quieren la autopista una vez que pueden obtener beneficio de las versiones anteriores.

Todos sabemos que un cliente siempre dirá "sí" si le preguntamos si quiere una autopista, y que a los desarrolladores les encanta trabajar en todos los features de una autopista.

En nuestro ejemplo del coche, la mayoría de la gente también preferiría el Lexus al Toyota, hasta que llega el momento de pagar, porque entonces un Toyota de repente también es suficiente. Y de la misma manera, no todos los desarrolladores quieren estar pensando constantemente en todos los detalles que requiere el Lexus.

¿No es caro construir tres caminos de grava, una carretera de adoquines, una de asfalto y una autopista?

Por supuesto que es más caro que construir solo una autopista. Pero todos sabemos que se cometen errores y que sigue siendo más barato que tener que construir tres autopistas, como ocurre a menudo en el desarrollo de productos.

Con nuestro método nos preparamos tan bien que nunca cometemos errores...

Si estás seguro y quieres asumir el riesgo, por supuesto puedes hacerlo. Y aunque tengas razón (dudo que siempre sea así), estoy bastante seguro de que la mayoría de los clientes ya habrán cambiado de opinión cuando empieces a construir la autopista. Y meses antes de que siquiera hayas empezado a construir, nuestros caminos de grava ya estarán generando retorno de la inversión.

Suena bien en teoría. ¿Funciona realmente en la práctica?

¡Buena pregunta! Casi se me olvida; en este artículo quería presentar un buen ejemplo de la vida real:

He cambiado algunos detalles de la historia para proteger al cliente.

Se trata del sitio web de una empresa. Sin embargo, este se encontraba en una zona completamente desmilitarizada de la red corporativa. Allí se había creado un pequeño producto que se iba a vender por internet. El Director Financiero (CFO) era un gran defensor de este producto y quería recibir las cifras de ventas de forma regular. Para ello, sin embargo, habría que violar zonas de seguridad e insertar los datos de ventas en el sistema SAP.

En una gran empresa, esto es un proyecto bastante grande que necesita al menos seis meses de trabajo de desarrollo. Los preparativos comenzaron con reuniones de al menos 20 personas (expertos en seguridad, expertos en SAP, desarrolladores web y una gran cantidad de gerentes hasta el puesto justo por debajo del CFO).

En una reunión posterior, el CFO se quejó de la poca visibilidad de la evolución de las ventas del producto durante los importantes primeros seis meses. Así que recomendé subproyectos temporales utilizando Dimensional Planning (como en el ejemplo de la autopista).

La versión del camino de grava:

Cada día generábamos un informe PDF en el servidor web y lo guardábamos en un disquete. (Recordemos que gran parte de la red no estaba conectada al servidor.) Cada día imprimíamos este informe y llevábamos una copia de las cifras de ventas a la oficina del CFO, donde un becario introducía todos los datos en nuestro sistema SAP. El informe PDF fue creado por uno de nuestros desarrolladores el mismo día que el producto se lanzó. Al final del día ya teníamos los datos para el CFO.

El primer problema: el CFO quería algo adicional; algo que se debía preguntar al cliente en el sitio web. El desarrollador había mostrado orgulloso el informe al CFO y volvió a su puesto de trabajo. Media hora después, la información adicional se solicitaba en el sitio web y se había creado el nuevo informe (sin los datos del primer día). Ya al día siguiente apareció un artículo periodístico y muchos clientes compraron el producto. Al día siguiente empezaron a llegar las primeras cifras y nuestro becario intentó transferir los datos al sistema SAP. Aquí descubrimos nuestro segundo Heusden. Resulta que estábamos usando la tabla SAP equivocada. Tomó algunos días corregir este error. El CFO seguía recibiendo su informe, pero en la primera semana aún no se podía hacer con SAP. El viernes de la primera semana, el becario pudo cargar los datos. Sin embargo, era un trabajo bastante aburrido que no era en absoluto escalable. (Tuvimos varios miles de ventas en la primera semana.) Ahora era el momento de nuestra:

Versión de adoquines:

Esta vez creamos el informe en formato CSV. (Recuerda, esto fue antes de XML.) Así que cada mañana, el desarrollador que llegaba primero a la oficina iba al servidor web, generaba el informe y lo copiaba en un disquete. Luego tomaba el disco y cargaba los datos en nuestro sistema SAP. Esta versión era más escalable; sin importar cuánto vendiéramos el día anterior, el trabajo para nuestro desarrollador seguía siendo el mismo. Pero incluso en esta versión tuvimos un pequeño problema. Uno de los campos estaba formateado como texto en lugar de número. (Un bug totalmente normal.)

El trabajo tenía que ser realizado personalmente por alguien cada día. No estaba automatizado y solo se hacía una actualización al día (para el día anterior).

Luego comenzaron las reuniones para la versión autopista. Al final de una de esas reuniones, pregunté a un colaborador del CFO cómo usaban los datos y si estaban satisfechos con las cifras. Por pura casualidad noté que el CFO solo miraba los datos los viernes. (Es decir, no a diario.) Ni siquiera le importaba no tener las cifras de ventas completas del día o de la semana.

La versión autopista:

Afortunadamente, al día siguiente tenía de todos modos una reunión con el CFO y su colaborador. Hablamos sobre el progreso del proyecto autopista y sobre cómo en realidad estaba impidiendo que la gente trabajara en otro proyecto importante. Sugerí educadamente quedarnos con la versión de adoquines y poner el proyecto autopista en espera. Mucha gente en la empresa no estaba muy contenta con esto, porque querían trabajar en ese proyecto super genial. Sin embargo, el responsable de seguridad estaba encantado, ya que así el servidor web podía permanecer en la zona segura. Al final, la empresa se ahorró seis meses de trabajo de desarrollo para una autopista que habría puesto en peligro la red y que realmente no era necesaria.

Después de algunos años me encontré de nuevo con el CFO. Admitió que el proyecto autopista probablemente habría sido excesivo, ya que el producto nunca había generado ni remotamente tanto dinero como habría costado el proyecto autopista. Gracias al proyecto del camino de grava, pudieron descubrir bastante temprano que faltaban las direcciones de correo electrónico de los clientes, y eso fue lo mejor que les pudo pasar. Con esa lista de correos electrónicos pudieron vender varios servicios adicionales a los clientes en los años siguientes, lo que salvó a la empresa de la quiebra.

El siguiente texto proviene del blog de Yves Hanoulle y fue traducido al español.