Aplicando ingeniería inversa a Trello

¿Quién no ha usado Trello para la gestión de tareas? Si no lo has hecho, vas tarde compañero.

Vamos a ver algunos puntos básicos que usaremos a modo de toma de requisitos para nuestra versión MVP de Trello:

  • Se trata de un gestor de tareas.
  • Existen distintos estados por los que pasarán las tareas. Estos estados deberán estar representados como columnas, lo cual ayudará de forma visual a ver las transiciones.
  • Las tareas podrán tener etiquetas, para poder agruparlas por distintos conceptos.
  • Las tareas deben poder asignarse a usuarios.
  • Las tareas podrán tener etiquetas para poder categorizarlas de distintas maneras.
  • Y por último, no olvidar, que las tareas pertenecerán a un tablón, que es la organización primaria que tiene el sistema.

Casos de uso 🧍

Basándonos en una versión reducida del proyecto, podemos entender que lo que los usuarios van a querer es crear, leer, actualizar o eliminar (CRUD) los distintos elementos que tenemos: tableros, tarjetas, etiquetas y estados.

Viendo a nivel de roles, podemos distinguir 3:

Admin: Serán los creadores de los tableros/tarjetas.

Por lo que podrán crear/leer/editar/eliminar sus tableros/tarjetas.

Miembros: Los usuarios «miembros» de un tablero, podrán crear/leer/editar/eliminar elementos de dicho tablero, aunque no editar/eliminar el tablero como tal.

Observador: Los usuarios «observadores» de un tablero, pueden leer sus elementos, pero no modificarlos.


Diagrama de clases 🧩

Haciendo una primera aproximación, podemos encontrar las siguientes entidades o clases, con una primera versión de atributos mínima.

Board: Representará a los tableros donde se encuentran las tarjetas.

  • id : int
  • title : string

Card: Serán las tarjetas, elemento principal de la app.

  • id . int
  • title : string
  • description : string

Status: Son las columnas de nuestros tableros. Aunque en principio parezca más razonable nombrarlas Columnas, lo vamos a dejar como Status, ya que esto nos permitirá en un futuro poder usar como columna otros tipos de categorizaciones, como podrían ser etiquetas o usuarios.

  • id : int
  • title : string

Tag: Son las etiquetas que podemos ponerle a las tareas, así tendremos otro punto de organización.

  • id : int
  • title : string
  • color : string

User: Serán los usuarios de la aplicación.

  • id : int
  • username : string
  • pass : string
  • email : string

Vamos a relacionar estas clases, analizando:

  • Un usuario puede tener 0 o más tableros, y un tablero puede tener 1 o más usuarios (los roles de momento lo dejamos pendiente)
  • Un tablero puede tener 0 o más tarjetas, y una tarjeta puede estar en un único tablero.
  • Una tarjeta tiene un único estado, y un estado puedo tener 0 o más tarjetas.
  • Una tarjeta puede tener 0 o más etiquetas, y una etiqueta puede estar en 0 o más tarjetas (vamos a permitir crear etiquetas sin estar asignadas inicialmente a alguna tarjeta)
  • Un tarjeta puede estar asociada a 0 o más usuarios, y un usuario puede estar asociado a 0 o más tarjetas.

Ciclo de vida de una tarjeta 🧬

Veamos el ciclo de vida de una tarjeta, como entidad más destacada del modelo.

Una vez una tarjeta es creada, y hasta que no es eliminada, pasa por distintos estados (funcionalidad que es el late motive de la app), es etiquetada, y recibe comentarios (funcionalidad que hemos sacado de esta primera versión de análisis de la aplicación).


PD: Que me perdonen los chicos de Trello 🙏🏻 por este análisis tan simplista de su aplicación, pero me he centrado en la funcionalidad principal para poder analizarla y así poder aplicar ingeniería inversa al producto.