Un meilleur flux de travail de développement Web: Confluence, Airtable et plus

En tant que développeur front-end pendant près de deux ans, j'ai une expérience utile en faisant partie de plusieurs projets de développement Web d'agences de design / numériques.

Une leçon évidente mais précieuse que j'ai apprise est que collaborer entre chaque groupe avec un seul but mais des responsabilités et des buts distincts n'est pas facile. Il y a différents aspects et niveaux de difficultés en termes de collaboration, et la partie spécifique dont je voudrais aborder ici est le processus de flux de travail.

Sur la base de mon expérience et avec l'aide de mes amis concepteurs et développeurs, j'ai créé un flux de travail de développement de site Web conçu pour une petite équipe (5 à 15 personnes). Le système est composé de Confluence, Jira, Airtable et Abstract. Dans cet article, je vais partager le pourquoi et le comment de ce flux de travail.

Motivation pour créer un nouveau flux de travail

Pour fournir un site Web personnalisé sans utiliser de modèles fournis par les créateurs de sites Web, les exigences minimales en matière de talent incluent un concepteur, un développeur et un chef de projet. Après avoir participé à quelques cas, j'ai eu le sentiment qu'il y avait quelque chose qui n'allait pas dans le flux de travail que nous avions: les informations importantes n'étaient toujours pas alignées à la fois en interne entre les différents rôles et en externe avec le client. Cette communication inefficace ralentissait clairement le cycle de développement et nuisait à l'équipe.

J'ai donc commencé à résoudre ce problème.

J'ai recherché sur Google des ressources sur l'établissement et l'amélioration d'un flux de travail. Bien que j'aie beaucoup appris de toutes ces excellentes ressources, je n'en ai trouvé presque aucune pour des projets de développement Web dans une agence de design / numérique. Il s'agissait soit d'un système de conception ou de directives de codage qui concernaient la conception ou les rôles frontaux, soit un flux de travail conçu pour une équipe possédant son propre produit.

En conséquence, j'ai décidé de choisir les pièces dont j'avais besoin pour résoudre nos problèmes et de créer un flux de travail personnalisé pour le développement de sites Web.

Problèmes et objectifs

Voici les problèmes que j'ai inspectés à partir de notre flux de travail existant et les objectifs d'amélioration correspondants:

1. Méthodologie en cascade

Problème: Sur la base de mon expérience, les projets de site Web adoptent une approche en cascade car les clients n'ont pas le concept d'un produit minimum viable (MVP). Au lieu de séparer les fonctionnalités des vues et de la modulation, les clients ont tendance à penser au site de manière traditionnelle page par page, ce qui oblige les concepteurs et les développeurs à travailler page par page en séquence. Cela leur fait perdre une perspective universelle à travers le projet. Cette situation entraîne de nombreux va-et-vient de révisions redondantes entre les pages.

Objectif: Changer la mentalité des clients est à la fois arrogant et irréaliste. L'objectif est de trouver un moyen de séparer les exigences des vues le plus tôt possible et de se développer de la manière la plus modulable possible en interne en fonction du modèle page par page.

2. Jetons et composants de conception universels gérés par les concepteurs et les développeurs

Problème: il s'agit d'un problème courant sur lequel de nombreux articles ont partagé d'excellentes solutions, qui proposent principalement de créer un système de conception géré par des générateurs de guides de style / bibliothèques. Bien que ce soit une excellente solution, la gestion d'un site supplémentaire qui fournissait à peine l'autorisation de modification aux concepteurs n'était pas appropriée dans notre situation.

Objectif: à l' exception de la création de jetons de conception universels et de langages que les concepteurs, les développeurs et les gestionnaires peuvent tous comprendre, créer un système permettant à chacun de gérer les actifs de manière synchrone.

3. Tableau de bord de progression précis et mis à jour

Problème: bien que les outils de suivi des problèmes, les kanban et d'autres modèles de gestion de projet soient utiles et pratiques, la plupart d'entre eux n'ont pas réussi à servir de tableau de bord de progression simple, flexible et convivial. Ce type de tableau de bord permettrait à l'équipe de gagner beaucoup de temps car il empêcherait les membres de l'équipe de signaler activement ou de poser des questions sur la situation actuelle de tâches spécifiques. Cela facilite également la vie des managers s'ils ont une connaissance claire de l'ensemble du projet sans trop d'efforts.

Objectif: créer un système de tableau de bord offrant des autorisations de modification aux personnes chargées de tâches spécifiques

Diagramme de flux de travail

Avant de plonger dans l'introduction détaillée de la pile d'outils de gestion, jetons un coup d'œil au flux de travail simplifié abstrait que j'ai organisé. C'est à peu près juste une visualisation d'un flux de travail normal que la plupart des agences ont, mais il y a deux points à noter ici.

1. Évaluation des développeurs

Premièrement, lorsque les exigences ou les problèmes provenant du client sont approuvés et documentés par le responsable, à l'exception de l'envoi de la tâche à un concepteur, ils sont également envoyés à un développeur pour évaluation. Dans ce processus, le développeur examine la spécification de la tâche, vérifiant si des fonctions ou fonctionnalités plutôt compliquées sont incluses. Si c'est positif, le développeur peut commencer à travailler dessus ou informer le concepteur des problèmes potentiels au préalable.

2. Source unique de vérité

Notez également qu'une fois que le livrable de conception est approuvé par le client, et avant de confier la tâche au développeur, il passe par un processus d' enregistrement / modification / suppression sur le magasin de conception mené par le concepteur. En effet, le développeur doit toujours être exposé à une et une seule source de magasin de conception, qui contient des actifs constamment maintenus et mis à jour prêts pour le développement.

Nous pouvons maintenant plonger dans la pile d'outils de gestion que j'ai préparée et voir comment ces outils nous aident à résoudre nos problèmes.

La pile d'outils

Après avoir expérimenté différentes options sur le marché, le stack que je propose ici est composé de Confluence, Jira, Airtable et Abstract. En plus de l'introduction de base et de quelques exemples d'application clés, je ne couvrirai pas tous les détails de l'utilisation des outils.

Remarque: le système suppose que l'équipe de développement adopte la méthodologie de conception atomique et le système de dénomination ABEM.

1. Confluence

Rôle: centre d'information et de ressources

Bien que cela soit intimidant au début, Confluence fournit un espace de travail puissant et facile à organiser, et il dispose de tonnes de fonctionnalités, d'intégration d'applications et de modèles personnalisés. Ce n'est certainement pas une solution universelle à tous les problèmes, mais c'est parfait pour la documentation des spécifications, des exigences, des notes de réunion et plus encore.

Par conséquent, Confluence dans cette pile fonctionne comme un centre d'informations et de ressources, ce qui signifie que tous les liens et détails relatifs à ce projet doivent être correctement documentés ici.

Mon avantage préféré de Confluence est la possibilité de personnaliser les modèles de documents. Cette fonctionnalité rend très pratique la normalisation du flux de travail.

Exemple: composantexamen des fonctionnalités

J'ai mentionné le processus d'évaluation des développeurs ci-dessus, qui est en fait un travail compliqué. En effet, ce processus inclut des informations de base sur le composant, une revue FSM d'un développeur (si nécessaire), un espace FAQ et plus encore. Mais la flexibilité du modèle et des outils fournis par Confluence rend cela très facile. Créez simplement un modèle dans les paramètres de configuration et vous êtes prêt à partir.

2. Jira

Rôle: suivi des problèmes et gestion des types d'actions

Également membre de la famille Atlassian, Jira est un logiciel de suivi des problèmes et de planification de projet très puissant. Ma partie préférée à ce sujet est la création de flux de travail personnalisés. Puisqu'il existe des tonnes d'excellents tutoriels sur la façon d'utiliser la puissance de Jira, la seule chose que je veux souligner ici est d'utiliser le type de problème comme mentionné ci-dessous.

Exemple: mettre à jour le développeur sur les changements de Design Store par type de problème

Pour s'assurer que les développeurs construisent les composants en fonction de vues de conception correctes, ils doivent être avertis chaque fois qu'un élément du magasin de conception est mis à jour, ce qui inclut des actions telles que l' enregistrement, la modification et la suppression . Ainsi, lors de la mise à jour d'un composant, le concepteur doit ouvrir un problème avec le développeur responsable affecté et le type de problème / action correct sélectionné.

3. Airtable

Rôle: gestion des composants et tableau de bord de progression

Airtable, un mélange de feuille de calcul et de base de données, est ce qui fait fonctionner cette pile. Il existe deux fonctionnalités étonnantes qui prennent en charge mon flux de travail: quatre types de transition de vue dans une seule table et la liaison de contenu associée. Je vais présenter deux exemples d'utilisation de ces deux fonctionnalités ici.

Exemple 1: gestion des composants

Comment gérez-vous votre bibliothèque de composants? Nous avons choisi de ne pas utiliser de générateur de guide de style, car il n'est pas accessible aux concepteurs pour le modifier. L'utilisation de la bibliothèque de composants Sketch n'était pas non plus appropriée, car elle présente trop de limitations si nous essayions de l'utiliser en dehors du cadre du logiciel lui-même.

Je ne dirais pas qu'Airtable est une solution parfaite, mais c'est l'option la plus simple et la plus flexible à laquelle je puisse penser. Jetez un œil au modèle de démonstration de la table de gestion des composants ici:

Une fois qu'une vue de conception nouvellement enregistrée, prête à être développée par programme, est soumise au développeur, il évalue la vue en fonction du système ABEM et l'enregistre dans la table. Il y a 9 colonnes dans le tableau, dont:

1. Nom: dénomination du composant en principe ABEM

2. Aperçu: capture d'écran ou image exportée du composant

3. Page liée: le lien vers la page contient ce composant

4. Composant enfants: le lien vers les composants enfants contient celui-ci

5. Modificateur: vérifie s'il existe des variations de style (ex: - actif, - rouge)

6. Catégorie de composant: une classification de catégorie générale (ex: texte, héros, barre latérale)

7. État du développement: état d'avancement du développement (en attente, attribué, en cours, achevé, en révision)

8. Cessionnaire: développeur responsable de ce composant

9. Niveau atomique : catégorie atomique de ce composant (atome, molécule, organisme)

La meilleure chose ici est que vous pouvez référencer des données dans les mêmes tables et dans d'autres. Cette connexion de points empêche les choses de devenir plus salissantes à mesure que l'échelle augmente. Notez également que vous pouvez facilement filtrer, trier et modifier les vues.

Exemple 2: état de développement de la page

Puisque l'hypothèse ici est que nous évaluerons inévitablement la progression du développement page par page, un modèle de tableau conçu à cet effet est nécessaire. Ce tableau peut être un tableau de bord de progression pour les deux équipes internes et partagé avec le client en même temps.

Toutes les informations sur la page, y compris la date limite, le lien du prototype InVision, le cessionnaire et le composant enfant peuvent être organisées ici. Notez qu'il est très pratique de documenter et de mettre à jour l'état de développement de la conception, du front-end et du back-end en même temps.

4. Résumé

Rôle: source unique de vérité et contrôle de version des actifs de conception

Abstract est des ressources GitHub for Sketch qui évitent aux concepteurs de ne pas pouvoir copier et coller des fichiers. Il est hors de portée de cet article de montrer les détails de la gestion du flux de contrôle de version. La clé à retenir ici est que Abstract est le magasin de design qui agit comme la seule source de vérité . Les concepteurs doivent continuer à mettre à jour la branche principale avec la dernière version de la conception confirmée, puis informer les développeurs. D'autre part, les développeurs ne doivent prendre comme référence que les éléments de conception de la branche principale.

Plus de travail à faire

D'après ma propre expérience, le développement de l'ensemble du projet après l'adoption de ce nouveau flux de travail a été au moins deux fois plus rapide qu'auparavant. Ce n'est pas une solution parfaite, car sa mise à jour et sa maintenance nécessitent encore beaucoup de travail manuel.

Mais je pense que cela pourrait être une référence utile aux équipes de développement de sites Web à la recherche d'un meilleur flux de travail, et j'espère que plus de personnes pourront partager leurs flux de travail à l'avenir!

? 中文版 連結 (version chinoise)  / Publié à l' origine sur vinceshao.com