Hay algo de negocio en tu código: (algunas) ideas para la entrega de valor

Es sábado por la mañana y Miren, frontend developer, entra a clase en nuestro Curso de Desarrollo de Software. El plan del día no es el esperado en un curso que promete ser técnico: Rubén y yo dinamizaremos una sesión sobre definición de historias de usuario. Como es habitual en la Biko School, abrimos boca con una introducción teórica para, acto seguido, poner en práctica lo aprendido.

Empezamos explicando que, para hacer bien nuestro trabajo, es fundamental un profundo conocimiento del negocio. En vez de limitarnos a ejecutar una solución, debemos participar en la definición de esta. Para ello, es necesaria una conversación entre las personas implicadas en el proyecto, desde perfiles de negocio hasta perfiles de desarrollo. Una conversación que se da en el dominio del problema, ahí donde solo se habla de las necesidades de la persona que utiliza nuestro software. Una vez entendidas estas necesidades es cuando pasamos al dominio de la solución, donde se definen y dibujan formularios, tablas y llamadas al API.

Esta conversación sobre las necesidades debe estar exenta de ambigüedades. Tenemos que huir de sinónimos, jergas y motes. El «bueno, ya me has entendido» no nos vale. Si surge un concepto de negocio, consensuamos una definición para este. Si surge una nueva palabra para referirnos a ese concepto de negocio, la descartamos o sustituimos la que teníamos. Nunca utilizamos la misma palabra para dos conceptos, ni dos palabras para un mismo concepto. De esta manera propiciamos el lenguaje ubicuo, pilar en el desarrollo de software.

¿Cuántas veces has visto parar un desarrollo por no tener claro qué ocurre en un escenario concreto? ¿Cuántas mañanas has perdido entre emails, llamadas y chats para aclarar una duda? ¿Te ha tocado ejercer de aguafiestas al tener que decir que un diseño es demasiado costoso (si no imposible) de implementar? ¿Has ejecutado una solución creyendo que podía haber sido mejor, sin tener posibilidad de cambiarla? Miren hace un gesto de complicidad. Lo ha vivido, ha estado ahí. Lo ha sufrido.

Aquello que Miren ha sufrido tiene nombre: aprendizaje accidental. El aprendizaje accidental es aquel que ocurre sin esperarlo, cuando todo debería estar claro. Nos frena, nos hace ser ineficientes y genera frustración en el equipo. Contra el aprendizaje accidental tenemos el aprendizaje deliberado, aquel que ocurre cuando todas las personas implicadas en el proyecto se alinean para entender cuál es la necesidad que se quiere cubrir. Solo así podemos sacar partido al verdadero potencial del equipo. Solo así podremos centrarnos en la entrega de valor.

El tiempo avanza, las transparencias se terminan y toca ponerse manos a la obra. Antes de eso, queda ver cómo llevar a la práctica estos principios de los que hemos hablado. Explicamos que, en uno de nuestros proyectos en Biko, nos está funcionando el enfoque Specification by Example que llevamos a cabo en talleres de Example Mapping. Explicamos en qué consisten (nota del autor: daría para otro post).

Arrancamos la práctica: Miren y su equipo harán un taller de Example Mapping para una aplicación en la que Rubén y yo asumimos el rol de negocio. No olvidemos los principios de los que hemos hablado: dominio del problema, evitar las ambigüedades y aprendizaje deliberado. Miren los tiene apuntados en su cuaderno, empiezan las conversaciones.

Durante el ejercicio, ocurre algo que Rubén y yo no esperamos. En el taller, el equipo de Miren descubre que nuestro planteamiento permite a algunas personas generar gastos de miles de euros. La idea con la que veníamos no solo no es la mejor posible, sino que puede hundirnos. Menos mal que Miren ha sabido evitarlo, proponiendo una nueva regla que hará que esto no ocurra. Como negocio nos parece bien, muchas gracias y adelante, buen trabajo.

Miren todavía no ha encendido su portátil. En ese momento entiende que, con un bolígrafo y un papel, ha aportado más valor del que hubiera aportado en mil líneas de código. Descubre que, su perfil de frontend developer, va mucho más allá de ejecutar una solución, de implementar un diseño. Su trabajo no es el código, el código es un resultado de su trabajo. Su responsabilidad es entender el negocio y hacerlo suyo.

Nosotros también nos llevamos una lección. Han pillado a Rubén y Aitor, ¿cómo puede ser? Bueno, no pasa nada, siempre podemos darle una vuelta para futuras ediciones del curso. Aunque, pensándolo mejor, creo que está bien así.

Si quieres profundizar en el tema

Puedes buscarme en Twitter o buscar a Rubén, gran conocedor de este enfoque. También te recomiendo el libro «The BDD Books – Discovery» escrito por Gáspár Nagy y Seb Rose. Lectura interesante, llena de ejemplos prácticos y anécdotas vividas por los autores.