Un mejor flujo de trabajo de desarrollo web: Confluence, Airtable, Jira y Abstract

Confluence, Jira, Airtable and Abstract

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

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

Una lección obvia pero valiosa que aprendí es que colaborar entre cada grupo con un objetivo pero con responsabilidades y propósitos distintos no es fácil. Existen 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.

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

Motivación para construir un nuevo flujo de trabajo.

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

Entonces comencé a resolver este problema.

Recursos excelentes de flujo de trabajo de búsqueda de Google: características de sistemas de diseño, recursos de guía de estilo y definición de flujo de trabajo

Google buscó recursos sobre cómo establecer y mejorar un flujo de trabajo. Aunque aprendí mucho de todos los excelentes recursos, encontré que casi ninguno era 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 los 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 las partes que necesitaba para resolver nuestros problemas y formé un flujo de trabajo personalizado para el desarrollo del sitio 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 la cascada

modelo de cascada resumen demo

Problema: según mi experiencia, los proyectos de sitios web adoptan un enfoque en cascada porque los clientes no tienen el concepto de un producto mínimo viable (MVP). En lugar de dividir las funcionalidades de las vistas y la modulización, los clientes tienden a pensar en el sitio de una manera tradicional página por página, lo que obliga a los diseñadores y desarrolladores a trabajar página por página en secuencia. Esto hace que pierdan una perspectiva universal en todo el proyecto. Esta situación da como resultado muchas revisiones redundantes 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 desarrollar de la manera más modulada internamente según el modelo de página por página.

2. Fichas y componentes de diseño universal administrados por diseñadores y desarrolladores

fichas de diseño de Salesforce

Problema: Este es un problema común al 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: excepto crear tokens e idiomas de diseño universal que los diseñadores, desarrolladores y gerentes puedan comprender, crear un sistema que permita a todos administrar los activos de forma sincronizada.

3. Tablero de progreso preciso y actualizado

necesitamos un panel de progreso editable y accesible

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 pudieron actuar como un panel de progreso sencillo, flexible y amigable. Este tipo de tablero ahorraría mucho tiempo al equipo porque evitaría que los miembros del equipo informen activamente o pregunten 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 panel de control que proporcione permiso de edición para 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 simplificado abstracto que organicé. Es casi solo una visualización de un flujo de trabajo normal que tienen la mayoría de las agencias, pero hay dos puntos a destacar aquí.

diagrama de flujo de trabajo que diseñé

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 hay funciones o características bastante complicadas incluidas. 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

Observe también que después de que el cliente aprueba la entrega del diseño, y antes de entregar la tarea a la mano del desarrollador, pasa por un proceso de registro / modificación / eliminación en la tienda de diseño realizada por el diseñador. Esto se debe a que el desarrollador siempre debe estar expuesto a una y solo una fuente de la tienda de diseño, que contiene activos actualizados y mantenidos constantemente 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.

diseño atómico y ABEM

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

1. Confluencia

Rol: 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 características, 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.

etapa de evaluación del desarrollador

Ejemplo: revisión de funcionalidad de componentes

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

plantilla personalizada para revisión de componentes en Confluence

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

tienda de diseño de actualización de diseñador

Ejemplo: Actualizar desarrollador en cambios de tienda de diseño por tipo de problema

Para garantizar que los desarrolladores estén creando los componentes en función de las vistas de diseño correctas, deben ser notificados cada vez que se actualice algo en la tienda de diseño, que incluye acciones como registrar, modificar y eliminar. Entonces, a medida que se actualiza un componente, el diseñador debe abrir un problema con el desarrollador responsable asignado y el tipo correcto de problema / acción seleccionado.

Función de tipos de problemas de Jira

3. Airtable

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 admiten mi flujo de trabajo: cuatro tipos de transición de vista en una sola tabla y enlaces de contenido relacionados. Aquí mostraré dos ejemplos del uso de estas dos funciones.

el desarrollador comienza a trabajar en la tarea

Ejemplo 1: gestión de componentes

¿Cómo gestionas tu biblioteca de componentes? Elegimos no usar un generador de guía de estilo, porque los diseñadores no pueden acceder a él para editarlo. El uso de la biblioteca de componentes Sketch tampoco era 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í:

tabla de componentes

Una vez que una vista de diseño recién registrada que está lista para ser desarrollada programáticamente se envía al desarrollador, 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 el principio ABEM

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

3. Página vinculada: el enlace a la página contiene este componente

4. Componente secundario: el enlace a los componentes secundarios contiene este.

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

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

7. Estado del 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 desordenadas a medida que crece la escala. También tenga en cuenta que puede filtrar, ordenar y cambiar las vistas fácilmente.

Ejemplo 2: estado de desarrollo de la página

Dado que aquí se supone que evaluaremos inevitablemente 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 los equipos internos y compartirse con el cliente al mismo tiempo.

tabla de lista de páginas

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 diseño, el front-end y el estado de desarrollo del back-end al mismo tiempo.

4. Resumen

Rol: fuente única de control de versiones de activos de verdad y diseño

Abstract es GitHub para los activos de Sketch que salva a los diseñadores del infierno de copiar y pegar archivos. Está fuera del alcance de este artículo demostrar detalles sobre la administració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.

Plantilla de rama abstracta

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 mucha mano de obra 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!