Llegamos a nuestra daily, y nos asignan una tarea, y al explicarla ves que es una gran funcionalidad que vas a tener que desarrollar de cero. De golpe, sin avisar. Te quedas paralizado ya que miles de casos de uso empiezan a cruzar a gran velocidad tu mente y no vamos ni por donde vas a empezar.
En este texto trato de dar unas ideas para que un programador se enfrente a una funcionalidad muy grande y no morir en el intento.
Permite que pueda darte unos consejos.
Lee y interioriza que objetivo final tiene la funcionalidad
Lo primero es leer y entender. Olvídate de todo lo que rodea esta funcionalidad. Te centras en el “que”, y olvida el “como”.
Si usas un sistema de tickets, tipo Jira, mi consejo es ir ampliando el texto explicativo de la tareas con las explicaciones que obtengas y que te logré centrar en que tienes que entregar. Céntrate en que aportas a la herramienta o al cliente final, no en que framework usar. Definir bien que entradas vas a tener, y que salidas se espera.
En ocasiones valdrá con un pequeño texto que describa que se espera de funcionalidad, en otros casos irá bien un prototipo de lo que se espera ver en el interfaz, o quizás un ejemplo de entrada y salida. Personalmente, en ocasiones unos gráficos de flujo de trabajo me suelen ayudar bastante.
En este paso es importante que hagas preguntas a las partes interesadas, no solo a la parte técnica, si no a los clientes.
No te quedes con dudas, y escribe todo la tarea.
Esto puede llevarte un tiempo, una horas, o incluso días y no pasa nada. Será tiempo ahorrado en un futuro.
En este paso es muy importante que definas el concepto de Hecho. ¿Qué hay que hacer para marcar esta tarea como terminado?, ¿qué tiene que cumplir?.
En esta fase tienes que tener unos criterios de aceptación que te definan cuando una tarea esta hecha.
Divide y vencerás
Si la funcionalidad es muy grande la definición de la tarea puede ser abrumadora o muy compleja, es posible que puedas dividirla en sub-tareas que te permitan hacer este proceso más sencillo.
Además de esta división, mira de las sub-tareas cuales son más importantes, o dicho de otra forma, sin las cuales no se podría decir que el tarea esta hecha.
Define unas tareas core que serán las que tienen que ser entregadas, y las secundarias.
Por ejemplo: guardar un registro en BBDD es core, pero enviar un correo al usuario de que se ha guardado puede ser secundaria.
KISS aplicado
Lo que trato de decir aquí es que trates de centrarte en lo realmente útil, y lo mantengas simple.
Uno de los mayores errores es fijarte en los casos extremos y tratar de desarrollarlos antes que la funcionalidad base. Esto es un poco polémico ya que hay mucha gente que te aconsejará que mantengas un ojo en los casos extremos. Mi consejo es que hagas un desarrollo inicial del caso básico y simple (o el happy path), logres hacer que funcione, y luego vayas a los casos extremos. Si no puedes montar una base de datos rápidamente, móntate un mock o usa SQLite. Hazlo simple, y trata de ir creciendo desde una base que funcione.
Evita el caso extremo guie el desarrollo porque es posible que el tiempo que pierdas en desarrollar ese caso extremos que solo ocurre un 1% de las veces haga que luego el core que ocurre el 90% no funcione correctamente.
Haz test para validar
Antes hemos dicho que hay que definir unas pruebas de aceptación, para marcar una tarea como hecha, y sin duda hacer tests es obligado.
Céntrate en las tareas core y cúbrelas de test unitarios. También recuerda que tienes que probar el happy path, pero también el bad path donde hay que controlar que el fallo se controle.
Es importante entender que hacer test tiene un objetivo claro: probar que la funcionalidad que se espera funciona. No hagas test repetidos, o que no cubran apenas código. Céntrate en la lógica del caso de uso, y deja las partes que son de infraestructura para test de integración finales.