¿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.