Un mejor flujo de trabajo de desarrollo web: Confluence, Airtable y más

Trabajando como desarrollador front-end durante casi dos años, tengo una experiencia útil al ser parte de varios proyectos de desarrollo web de agencias de diseño / digitales.

Una lección obvia pero valiosa que he aprendido es que no es fácil colaborar entre cada grupo con un objetivo pero con responsabilidades y propósitos distintos. Hay diferentes aspectos y niveles de dificultades en términos de colaboración, y la parte específica que me gustaría abordar aquí es el proceso de flujo de trabajo.

Basándome en mi experiencia y con la ayuda de mis amigos diseñadores y desarrolladores, creé un flujo de trabajo de desarrollo de sitios web diseñado para equipos pequeños (de 5 a 15 personas). El sistema está compuesto por Confluence, Jira, Airtable y Abstract. En este artículo, compartiré el por qué y el cómo de este flujo de trabajo.

Motivación para construir un nuevo flujo de trabajo

Para ofrecer un sitio web personalizado sin utilizar plantillas proporcionadas por los creadores de sitios web, los requisitos mínimos de talento incluyen un diseñador, desarrollador y director de proyecto. Después de participar en un par de casos, tuve la sensación de que algo andaba mal con el flujo de trabajo que teníamos: la información importante no siempre estaba alineada tanto internamente entre los diferentes roles como externamente al cliente. Esta comunicación ineficaz claramente ralentizaba el ciclo de desarrollo y perjudicaba al equipo.

Entonces comencé a resolver este problema.

Busqué en Google recursos sobre cómo establecer y mejorar un flujo de trabajo. Aunque aprendí mucho de todos los excelentes recursos, no encontré casi ninguno para proyectos de desarrollo web en una agencia de diseño / digital. Era un sistema de diseño o pautas de codificación que se enfocaban en roles de diseño o front-end, o un flujo de trabajo que se creó para un equipo con su propio producto.

Como resultado, decidí elegir cuidadosamente las partes que necesitaba para resolver nuestros problemas y formé un flujo de trabajo personalizado para el desarrollo de sitios web.

Problemas y metas

Los siguientes son los problemas que inspeccioné de nuestro flujo de trabajo existente y los objetivos de mejora correspondientes:

1. Metodología de cascada

Problema: Según mi experiencia, los proyectos de sitios web adoptan un enfoque en cascada porque los clientes no tienen un concepto de producto mínimo viable (MVP). En lugar de dividir las funcionalidades de las vistas y la modulación, los clientes tienden a pensar en el sitio de una manera tradicional página por página, lo que obliga tanto a los diseñadores como a los desarrolladores a trabajar página por página en secuencia. Esto les hace perder una perspectiva universal en todo el proyecto. Esta situación da como resultado muchas revisiones redundantes de ida y vuelta entre páginas.

Objetivo: Cambiar la mentalidad de los clientes es arrogante y poco realista. El objetivo es encontrar una manera de separar los requisitos de las vistas tan pronto como sea posible y desarrollarlo de la manera más modulada posible internamente basándose en el modelo página por página.

2. Componentes y tokens de diseño universales gestionados por diseñadores y desarrolladores

Problema: este es un problema común para el que muchos artículos han compartido excelentes soluciones, que en su mayoría proponen la construcción de un sistema de diseño administrado por generadores de guías de estilo / bibliotecas. Aunque es una gran solución, administrar un sitio adicional que apenas proporcionaba permiso de edición a los diseñadores no era apropiado en nuestra situación.

Objetivo: a excepción de la creación de lenguajes y tokens de diseño universales que los diseñadores, desarrolladores y gerentes puedan entender, construir un sistema que permita a todos administrar los activos de manera sincrónica.

3. Panel de progreso actualizado y preciso

Problema: aunque los rastreadores de problemas, kanban y más modelos de gestión de proyectos son útiles y prácticos, la mayoría de ellos no actúan como un panel de progreso sencillo, flexible y amigable. Este tipo de tablero le ahorraría mucho tiempo al equipo porque evitaría que los miembros del equipo informaran activamente o preguntaran sobre la situación actual de tareas específicas. También facilita la vida de los gerentes si tienen un conocimiento claro de todo el proyecto sin demasiado esfuerzo.

Objetivo: crear un sistema de tablero que proporcione permisos de edición a las personas a cargo de tareas específicas.

Diagrama de flujo de trabajo

Antes de sumergirnos en la introducción detallada de la pila de herramientas de administración, echemos un vistazo al flujo de trabajo abstracto simplificado que organicé. Es más o menos una visualización de un flujo de trabajo normal que tienen la mayoría de las agencias, pero hay dos puntos que deben tenerse en cuenta aquí.

1. Evaluación del desarrollador

Primero, cuando los requisitos o problemas que provienen del cliente son aprobados y documentados por el gerente, con la excepción de enviar la tarea a un diseñador, también van a un desarrollador para su evaluación. En este proceso, el desarrollador revisa la especificación de la tarea, verificando si se incluyen funciones o características bastante complicadas. Si es positivo, el desarrollador podría comenzar a trabajar en él o notificar al diseñador sobre los posibles problemas de antemano.

2. Fuente única de verdad

También tenga en cuenta que después de que el cliente aprueba la entrega de diseño, y antes de entregar la tarea a la mano del desarrollador, se pasa por un proceso de registro / modificación / eliminación de la tienda de diseño realizado por el diseñador. Esto se debe a que el desarrollador siempre debe estar expuesto a una única fuente de tienda de diseño, que contiene activos mantenidos y actualizados constantemente y listos para el desarrollo.

Ahora podemos sumergirnos en la pila de herramientas de administración que preparé y ver cómo las herramientas nos ayudan a resolver nuestros problemas.

La pila de herramientas

Después de experimentar con varias opciones en el mercado, la pila que propongo aquí se compone de Confluence, Jira, Airtable y Abstract. Además de la introducción básica y algunos ejemplos de aplicaciones clave, no cubriré todos los detalles del uso de las herramientas.

Nota: el sistema asume que el equipo de desarrollo adopta la metodología de diseño atómico y el sistema de nombres ABEM.

1. Confluencia

Función: centro de información y recursos

Aunque es intimidante al principio, Confluence proporciona un espacio de trabajo poderoso que es fácil de organizar y tiene toneladas de funciones, integración de aplicaciones y plantillas personalizadas. Definitivamente no es una solución universal para todos los problemas, pero es perfecta para la documentación de especificaciones, requisitos, notas de reuniones y más.

Por lo tanto, Confluence en esta pila funciona como un centro de información y recursos, lo que significa que todos los enlaces y detalles relacionados con este proyecto deben documentarse correctamente aquí.

Mi ventaja favorita de Confluence es la capacidad de personalizar plantillas de documentos. Esta característica hace que sea realmente conveniente estandarizar el flujo de trabajo.

Ejemplo: componenterevisión de funcionalidad

Mencioné anteriormente el proceso de evaluación de desarrolladores , que en realidad es un trabajo complicado. Esto se debe a que este proceso incluye información básica del componente, una revisión de FSM del desarrollador (si es necesario), espacio de preguntas frecuentes y más. Pero la flexibilidad de la plantilla y las herramientas que proporciona Confluence hace que esto sea muy fácil. Simplemente cree una plantilla en los ajustes de configuración y estará listo.

2. Jira

Rol: seguimiento de problemas y gestión del tipo de acción

También miembro de la familia Atlassian, Jira es un software de planificación de proyectos y seguimiento de problemas muy potente. Mi parte favorita es crear flujos de trabajo de problemas personalizados. Dado que hay toneladas de excelentes tutoriales sobre cómo utilizar el poder de Jira, lo único que quiero señalar aquí es usar el tipo de problema como se menciona a continuación.

Ejemplo: actualizar el desarrollador sobre los cambios de la tienda de diseño por tipo de problema

Para asegurarse de que los desarrolladores estén construyendo los componentes en función de las vistas de diseño correctas, deben recibir una notificación cada vez que se actualice algo en la tienda de diseño, lo que incluye acciones como registrar, modificar y eliminar . Por lo tanto, a medida que se actualiza un componente, el diseñador debe abrir un problema con el desarrollador responsable asignado y seleccionar el tipo de problema / acción correcto.

3. Mesa de aire

Rol: gestión de componentes y panel de progreso

Airtable, una mezcla de hoja de cálculo y base de datos, es lo que hace que esta pila funcione. Hay dos características sorprendentes que respaldan mi flujo de trabajo: cuatro tipos de transición de vista en una sola tabla y vinculación de contenido relacionado. Mostraré dos ejemplos del uso de estas dos funciones aquí.

Ejemplo 1: gestión de componentes

¿Cómo gestiona su biblioteca de componentes? Decidimos no utilizar un generador de guías de estilo porque los diseñadores no pueden editarlo. El uso de la biblioteca de componentes de Sketch tampoco fue apropiado, porque tiene demasiadas limitaciones si intentamos usarlo fuera del alcance del software en sí.

No diría que Airtable es una solución perfecta, pero es la opción más fácil y flexible que se me ocurre. Eche un vistazo a la plantilla de demostración de la tabla de administración de componentes aquí:

Una vez que se envía al desarrollador una vista de diseño recién registrada que está lista para ser desarrollada mediante programación, evaluarán la vista según el sistema ABEM y la registrarán en la tabla. Hay 9 columnas en la tabla, que incluyen:

1. Nombre: denominación del componente en principio ABEM

2. Vista previa: captura de pantalla o imagen exportada del componente

3. Página vinculada: el vínculo a la página contiene este componente.

4. Componente secundario: el vínculo a los componentes secundarios contiene este.

5. Modificador: comprueba si hay variaciones de estilo (por ejemplo: - activo, - rojo)

6. Categoría de componente: una clasificación de categoría general (por ejemplo, texto, héroe, barra lateral)

7. Estado de desarrollo : estado del progreso del desarrollo (pendiente, asignado, en progreso, completo, en revisión)

8. Cesionario: desarrollador responsable de este componente.

9. Nivel atómico : categoría atómica de este componente (átomo, molécula, organismo)

Lo mejor aquí es que puede hacer referencia a datos tanto en la misma tabla como en otras. Esta conexión de puntos evita que las cosas se vuelvan más complicadas a medida que crece la escala. También observe que puede filtrar, ordenar y cambiar vistas fácilmente.

Ejemplo 2: estado de desarrollo de la página

Dado que el supuesto aquí es que inevitablemente evaluaremos el progreso del desarrollo página por página, es necesaria una plantilla de tabla diseñada para este propósito. Esta tabla puede ser un panel de progreso para ambos equipos internos y compartirse con el cliente al mismo tiempo.

Aquí se puede organizar cualquier información sobre la página, incluida la fecha límite, el enlace del prototipo de InVision, el cesionario y el componente secundario. Tenga en cuenta que es muy conveniente documentar y actualizar el estado de desarrollo del diseño, el front-end y el back-end al mismo tiempo.

4. Resumen

Función: fuente única de control de versiones de activos de diseño y verdad

Abstract es GitHub para recursos de Sketch que salva a los diseñadores del infierno de copiar y pegar archivos. Está fuera del alcance de este artículo demostrar los detalles de la gestión del flujo de control de versiones. La conclusión clave aquí es que Abstract es la tienda de diseño que actúa como la única fuente de verdad . Los diseñadores deben seguir actualizando la rama maestra a la última versión del diseño confirmado y luego notificar a los desarrolladores. Por otro lado, los desarrolladores solo deben tomar los activos de diseño en la rama maestra como referencia.

Más trabajo por hacer

Desde mi propia experiencia, el desarrollo de todo el proyecto después de adoptar este nuevo flujo de trabajo ha sido al menos dos veces más rápido que antes. No es una solución perfecta, porque aún requiere mucho trabajo manual para actualizar y mantener.

Pero creo que podría ser una referencia útil para los equipos de desarrollo de sitios web que buscan un mejor flujo de trabajo, ¡y espero que más personas puedan compartir sus flujos de trabajo en el futuro!

? 中文版 連結 (versión china)  / Publicado originalmente en vinceshao.com